On Thursday 30 April 2026 I went to an Amsterdam Java User Group evening. The room had a Trifork banner next to the screen, and the first talk walked through what it called Java’s epic refactor, Project Valhalla, after a run through some long-standing Java annoyances. A second talk, about career reputation, followed. I could not read either speaker’s name on the slides, so I do not name them.
Starting with the pain points
The first slide I photographed carried a quote attributed on the slide to James Gosling: “As sort of a design principle for something lots of people were going to use, I’d rather keep the hole with a label on it than do something I know is wrong.” It set the tone for a talk about trade-offs in the language design.
Opening quote slide, attributed on the slide to James Gosling.
Next came a slide titled “10 things I hate about Java”, styled after the film poster, on both the main screen and the side monitor.
“10 things I hate about Java”: the talk’s framing slide.
Checked exceptions in streams
One complaint was shown in code. Two methods, one throwing SchoolParseException and one throwing IOException, were then used inside a stream pipeline.
Two methods with different checked exceptions, before they go into a stream.
The next slide showed the result: each map step needs its own try/catch that rewraps the checked exception in a RuntimeException, before filter and count.
The stream version: one try/catch per lambda, each rethrowing a RuntimeException.
My take: this is the everyday cost of mixing checked exceptions with lambdas, and it is a good reason the language has more to fix than performance.
Project Valhalla
The Valhalla section started from an InfoWorld article titled “Project Valhalla: A look inside Java’s epic refactor”, whose standfirst reads that Valhalla is “nothing short of a Java language overhaul, promising to correct longstanding performance issues”.
The InfoWorld article the talk used as its starting point.
The slide that followed, “Project Valhalla Deliverables: 10 years, *4 JEPs”, listed:
- JEP 401 (Preview): Value Classes and Objects: objects that lack identity, and consequently have optimised encodings.
- JEP 402 (Preview): Enhanced Primitive Boxing: allows primitives to be treated more like objects.
- JEP Draft: Null-Restricted Value Class Types: better performance for fields and arrays with null-restricted value class types.
- JEP Draft: Null-Restricted and Nullable Types: language support for null-aware types and runtime enforcement of null restrictions.
Project Valhalla Deliverables: ten years, four main JEPs.
Where it stands now
I checked these against OpenJDK. The Project Valhalla page states the goal as augmenting the Java object model with value objects, “combining the abstractions of object-oriented programming with the performance characteristics of simple primitives”. JEP 401 is now titled “Value Objects (Preview)” and the page lists it as integrated, targeting Java 28. It describes immutable objects without identity, distinguished only by their field values, so == compares values and the JVM can optimise their layout. JEP 402, Enhanced Primitive Boxing (Preview), is still a draft. The Valhalla page also lists “Null-Restricted Value Class Types” as a draft. Titles and status change as the work progresses, so treat the OpenJDK pages as the source of truth over the slide.
My take: for most application code, value objects matter where you hold large arrays of small immutable types, such as money, coordinates or ids. That is where identity-free layouts can save memory.
A second talk: career reputation
Later in the evening a different speaker presented a talk on career reputation. One slide quoted Heinz Kabutz: “If you position yourself as an expert, you get called to solve the hardest problems. And when you solve the hard problems, you become the expert.” The name appears on the slide as the quote’s attribution, not as the speaker.
A quote slide from the career talk, attributed on the slide to Heinz Kabutz.
The talk also showed a “Reputation Formula” slide and a “Gift: Grow Beyond Senior” slide advertising an online programme. I have not looked at the programme, so I make no claim about it.
Going by my recording of the Q and A part, the speaker described several routes for growing beyond the senior level. Some are positions inside a company, such as manager, director, VP and staff or principal engineer; people can move between them over a career, though it is hard to hold more than one at once. Others are more independent paths, such as running a consulting business or building a product, which can run in parallel with a job and be repeated. The point was that beyond senior you are not just a better-paid senior: the work changes, and so does the impact. As an example, the speaker said a change to a widely used Java specification such as JPA has to be implemented by every vendor, so a specification author’s work reaches everyone using it. My take: that is a useful way to think about choosing between depth and breadth, and I would add that the independent paths need their own skills such as sales and communication.
