GeeCON 2026 — a recap
The 2026 edition of GeeCON didn’t look promising at first. I arrived in Kraków expecting the same slow decline I’d been hearing about — no crowds, only five sponsor booths, and talks from sponsors about their great products. Last year I heard the conference business was slowly dying, and I kinda agreed.
But then, I went to the talks. And everything changed.
GeeCON is one of the largest Java and JVM-focused conferences in Central Europe, held annually in Kraków, Poland. This year’s edition took place on May 14–15 and brought together developers from across the continent for two days of talks and hallway conversations. Here is my personal recap — opinionated, as always.
Day 1 #
Become a rockstar developer — Dylan Beattie #
The conference opened not with a keynote from the biggest sponsor, but with a show. A reminder that being an engineer is cool and fun. That we can go deep down the rabbit hole and create something spectacular. Maybe not useful. But fun. Dylan told us the story of how a very dangerous combination of internet, boredom, and alcohol led to creating Rockstar: a programming language where the code reads like rock ballads. He gave us an unforgettable rock performance of FizzBuzz. And we all became certified rockstar developers.
“Baby, baby, baby, ohhh EOF” — where baby and ohh are closing brackets of code blocks in
this language. You can’t make this up.
An opinionated guide to bulletproof APIs with Java — Rustam Mehmandarov #
I’ve always said that conferences are for the “lowest common denominator” of software engineers. This means a lot of beginner-level talks about best practices. This was exactly that, but done well and concisely. The talk described principles for building production-grade APIs. The companion repo is worth bookmarking. Even though I’ve been in this business for 10 years, I learned something. Those error JSON responses we see in Spring? They’re actually based on RFC 9457. And versioning doesn’t need to mean a new URL — it might just mean a header change.
Agents with Seatbelts: Practical Ways to Keep AI Code Gen Under Control — Jonathan Vila López #
Jonathan (@vilojona, author of the foojay.io newsletter) opened with a bold thesis: AI slows developers down if not done in a smart way. He showed us benchmarks and what accuracy metrics actually mean in practice. The key insights:
| Principle | What it means |
|---|---|
| Decompose to multiple agents | If accuracy is 85%, errors accumulate in a single context. Split tasks across agents — don’t share context between them. |
| Right model for the task | Code generation has different top models than deep analysis. Don’t use an agent when a simple tool is the answer. |
| Think about cost | LLMs are subsidized now, but won’t be forever. Free models (GLM-5, Kimi K2 Thinking) perform surprisingly well on your own infra. |
| Use negative constraints | Don’t ask AI for something you don’t know yourself. |
| Skills over MCP | MCP = black box CVE (recent ones: Anthropic MCP or ContextCrush), context pollution, MCP sprawl. If you still use MCP — sandbox it. |
| Guardrail everything | Contracts, hook reviews, human in the loop. |
His formula: Success = AI × (you + classic way), where classic way = team, SDLC, tools, specs. “AI gives you time, you give the confidence.”
Remember waterfall? With agents it’s specification-driven development. Sounds familiar? 🤔
Concurrency testing — Adam Warski #
A quick look at testing libraries: Fray (Java) and Lincheck (Kotlin).
Fray finds interleavings and takes control over locking/releasing instead of simply running a loop 10k times and hoping the race condition happens. But it has gaps, like missing support for volatile primitives. Lincheck is older and may not be as robust, but it has nice logging of the interleavings.
Scotty, I need warp speed — Gerrit Grunwald #
Spinning up new instances at scale is fun, but what if your peaks happen so suddenly that you need to react now? Simple JIT isn’t enough. Maybe you’re on a stock exchange and want to be first when the market opens? Or maybe you are running a marketplace and decide to run promotional campaign with a smartphone for 1 PLN? Those first seconds really matter.
Gerrit gave us a deep dive into JVM startup and the technologies that shorten the time to hyperspeed performance:
| Technology | What it does |
|---|---|
| JVM classloaders | Bootstrap, platform, system — understanding what can actually be optimized |
| JIT (C1/C2 compilers) | Baseline compilation vs. peak performance compilation |
| CDS / AppCDS | Class Data Sharing — pre-load class metadata |
| Leyden | Ahead-of-time condensation of JVM state |
| Native Image (AoT) | Full ahead-of-time compilation via GraalVM |
| CRaC | Checkpoint/restore — snapshot a warmed-up JVM |
| Ready Now | Persistent compiler optimizations with profiling data |
| Cloud Native Compiler | Central code cache with thousands of Linux process JIT compilers |
And remember, you can always customize: create your own runtime with jlink.
Thread pool queue wait time — Mateusz Nalepa (Allegro) #
Our own speaker with his lightning talk. So your instance has zero CPU usage and still hangs? Maybe your thread pool queue is full and your tasks are waiting there forever.
There are metrics for that. Don’t mix I/O, CPU, and thread pools together. Split queue wait time and execution time metrics and queues — and avoid dying in agony of not knowing what the hell is going on. You can find details on GitHub: CPU-Bound, I/O Bound: Queues can be everywhere
Before the TO-DO list — Agata Kabat #
Quick talk closing Day 1. Agata’s recipe for good team communication: as a team, answer these questions:
- How do we make decisions as a team?
- What does “good enough” mean for us?
- How do we want to communicate day-to-day?
- How do we give and receive feedback?
- How do we support focus and well-being?
Tools worth checking out:
Day 2 #
The enemy within — Steve Poole #
Very interesting talk about how AI generates code and how it can be weaponized. Steve (noregressions.dev) shared some eye-opening insights:
- AI chooses libraries based on alphabetical order, so a malicious library starting with “a” is more likely to be picked by AI.
- AI creates predictable package names. If you use a predictable name in malware, AI is more likely to suggest it.
- MCP can have injected code. You don’t see it. MCP just sends instructions to your machine, so the injection happens on your end.
You can watch the full talk on YouTube.
Lightning fast services with Server Side Swift — Marcin Kliks (Allegro) #
Our AI specialist Marcin talked about how he rewrote an application in Swift and achieved predictable performance, low resource usage, and low-level Linux calls that will probably still work great when our kids run the programming world.
Swift is not my cup of tea, but the key takeaway was fascinating: in the age of agent code generation, we can easily choose the right technology for the task. We don’t need to choose between using something we know for a quick result or investing in something new that we might spend a copious amount of time learning.
We’re engineers with deep knowledge of how systems should work. The code is just an interpretation of it — and interpreting our spec and expertise into code is where agents shine.
The past, present, and the future of enterprise Java — Ivar Grimstad #
An interesting tale of J2EE through history. How a “simple” change of the package name to
jakarta.* can mean independence and freedom. Oracle donated Java EE to the Eclipse Foundation,
and the namespace had to change from javax.* to jakarta.* because Oracle owns the Java
trademark. They still contribute a lot. Good things coming.
There was no hush-hush “don’t mention Spring” in this talk. They acknowledge that Spring,
especially with @Autowired, landed a serious punch in J2EE adoption. But instead of fighting,
enterprise Java tries to consolidate. Now we have @Inject, runtime-aware virtual threads by
flag, and a cool new thing: a data module with Spring-Data-like interfaces and its own JDQL
@Query annotation.
Unifying Spring AI integration with MCP — Dariusz Jędrzejczak #
An ex-Allegro Spring developer showed us how Spring is ready for agentic coding. We used the Spring AI module to write our own MCP server and agent client. And it was simple. Like always with Spring 🙇♀️.
God, I love what Spring Boot did to microservices. I was already alive and coding when web.xml was
a thing. And “sensible defaults” was not even a buzzword. And I remember the weeks of pain
setting up JPA with Spring and Hibernate, just because I dared to have two datasources and an
entity manager.
Gemini plays Final Fantasy — Artur Skowroński #
A light and fun talk. It was weirdly satisfying to watch how AI couldn’t figure out how to pass through a passage because there was an NPC walking around.
Artur wrote his own NES emulator — KNES, written in Kotlin — with a full API for the game. You can move around via Swagger, which is cool. Maybe not the most efficient, but cool. Turns out, if you want to get anything useful from an image, ask Gemini. It’s miles ahead of other models. Oh, and try to test e2e AI playing a graphical game. I dare you.
Discussion panel on LLMs #
The last session — and maybe the most interesting. Four experts on stage, with different levels of LLM excitement.
Most of it was about our love/hate relationship with LLMs. We love the vibe coding and having immediate results. But on the other hand, we miss the coding. We’re tired of only reviewing the code. What’s the biggest problem with agentic coding? Us. We are the bottleneck. And we cannot be replaced. Even if you give five agents the same code review, they won’t replace a senior developer. It’s like giving a complex problem to five juniors.
One thing that struck me — our daily work has become interruption-driven development. No more focus time. With multi-agent tasks running all around, our context switching is now at 20-second frequency. This is not sustainable for our sanity. The burnout is likely to skyrocket.
The solution? Slow down. Wasn’t that the exact opposite of what agent coding was supposed to achieve?
Looking back #
This was not an ordinary conference. It felt like it was actually done by engineers for engineers. There was no marketing, no sales pitches, no “we have a great product that solves all your problems.” There were only engineers sharing their knowledge and experience. Even when there was a “look at our cool feature” talk, it was from Spring or Azul, tools we actually use, and something worth knowing. And there were a lot of talks not about LLMs, which is nice and refreshing. The opening keynote was a show and a reminder that being an engineer is not just a job, but a passion. That we can be rockstars in our own right.
The second thing that positively surprised me: I actually enjoyed the LLM talks. There was almost no “look what I did in one day.” It was more retrospective, more about the danger of working with a black box. And the imminent danger of accelerating our burnout.
It looks like we’ve finally moved past the peak of the Gartner Hype Cycle and started to reflect on whether it was all worth it. And whether it is the future.
I was the one tweeting from the @allegrotech account on X during the conference. I felt like a reporter on a mission. It was a lot of fun.
See you next year, GeeCON. 🎸