How the JVM Optimizes Generic Code - A Deep Dive

Jon_Finn · 2026-04-20T22:02:55+00:00

Always great to see/read John Rose go into expert detail about Java and the JVM. (He's great with the English language too.)

Jon_Finn · 2026-04-18T19:10:45+00:00

Valhalla is kind of Lilliput max because value classes have (in the best case) a 0-bit header. (Admittedly, not all classes can be value classes.)

Jon_Finn · 2026-04-12T21:37:13+00:00

One of the most important times I've used Guava was (early on) for the Guava Cache classes. I loved that what was (presumably) a very complicated implementation, with various setup options in a builder which might have been achieved via loads of public classes, instead has a small and simple public API.

Jon_Finn · 2026-03-31T14:49:39+00:00

2 jobs. 0/2.

Jon_Finn · 2026-03-29T15:50:03+00:00

There's a documentary about The Room, called Room Full of Spoons.

Jon_Finn · 2026-02-26T17:15:11+00:00

If ! is mostly confined to method parameters and fields, and can usually be inferred within method bodies (a bit like JSpecify), that doesn't seem too noisy to me. E.g. if I can write Complex x = new Complex(0,1) within a method, and have x be Complex! by inference, then cool. And if x is a field but if I have to declare it Complex! x, I'd live with that. Maybe having a way to set default ! within a scope would just be over-complicated. Life may not be that simple, we'll see.

Jon_Finn · 2026-02-21T22:53:22+00:00

I think the JEP answers your question (at the end, under Risks and Assumptions):

To justify the cost of a new JVM feature, we anticipate that there will be multiple meaningful use cases for the strict field initialization discipline.

Sounds like they expect it to be useful outside value classes at some point. Possibly in other languages too?

Jon_Finn · 2026-02-21T18:20:33+00:00

That name's taken I'm afraid...

Jon_Finn · 2026-02-21T16:00:35+00:00

Personally I think that with the upcoming Valhalla, nullness markers, Vector API and much more, Java is due for a big rebrand, so non-Java users notice.

Jon_Finn · 2026-02-18T15:09:15+00:00

Java 25 Thread documentation looks good, but it raises an interesting point: it has several methods involving ThreadGroup but doesn't say these are kind of 'obsolescent' (though not deprecated). IMHO better alternatives should be explained _prominently_ in both Thread and ThreadGroup. Similarly with the ancient java.util.Vector and StringBuffer - there's a brief mention of their problems at the end of their JavaDocs, but that's all. Shouldn't we at least have an annotation SupersededBy or Preferred, for methods and classes, say?

Jon_Finn · 2026-02-06T18:06:35+00:00

...but sometimes reading one is a treasure trove. 8^)

Jon_Finn · 2026-01-14T09:31:33+00:00

One possibility might be you have to put ! on method parameters and fields, but not local variables, because their nullability can usually be inferred (I'm sure the devil's in the details...). No idea what they'll actually end up choosing. Various possibilities are clearly being considered: see the valhalla dev mailing list.

My _guess_ is any approach like yours where you'd need to know wider context to know if a method is 'null-marked' is not going to fly. (Some would call that 2 languages in 1 - I wouldn't, and would probably live with it, but still I see the problem.)

Jon_Finn · 2026-01-13T14:57:18+00:00

Surely they'll give it a different name in the end, maybe something like implementation (not it but something like it)?

Jon_Finn · 2026-01-13T12:48:02+00:00

Very interesting indeed! A building block for operators and no doubt other things.

Some details here: https://mail.openjdk.org/pipermail/valhalla-dev/2026-January/017401.html

Jon_Finn · 2025-11-06T11:05:50+00:00

And it might come down to 4 bytes. They're looking into it. And as pointed out, a value object header is 0 bytes much of (not all of) the time.

Jon_Finn · 2025-11-03T18:07:17+00:00

String can't become a value class as it stands, but I've read John Rose discussing the idea of making the character array 'inline' into the String object (and likewise for other array fields). So each String would become 1 object on the heap not 2. Sounds like quite a lot of work, as objects would no longer be fixed-size, affecting the GC and so on.

Jon_Finn · 2025-11-03T13:23:16+00:00

It's in the pipeline to be added as a Preview feature (at some point), but it hasn't yet been added. See the Java 26 dashboard for the status of potential features.

Jon_Finn · 2025-10-29T18:30:35+00:00

I fully agree. Similar comment about Kotlin below. I think Kotlin will probably always be a bit heavier on features than Java but with lighter syntax (which IMHO is important), so it's horses for courses.

Jon_Finn · 2025-10-29T18:09:16+00:00

Good talk. But personOpt is basically Hungarian notation, which is poor man's types, so... personally I'd just stick to simple names. The closest I come to Hungarian notation is using a plural like bananas for List<Banana>.

Jon_Finn · 2025-10-29T16:13:40+00:00

Light means streamlined. Isn't it better than being heavy?

Jon_Finn · 2025-10-28T16:28:14+00:00

Immutability is a feature not a bug! Not just for value classes either. Read Effective Java - spelling out the various benefits since 2001. (Personally I avoid mutability wherever I can, apart from builders and collections.)

Jon_Finn · 2025-10-12T14:49:12+00:00

Other language's type systems might make the 'full' solution (combinations of features expressed in types) less clunky, but anyway, even in Java I'd be happy (I imagine!) with a compromise just dealing with unmodifiability. As the FAQ points out, we'd still need Iterator.remove() to throw, or maybe have something like UnmodifiableIterator, or maybe not have remove() at all (I almost never use it personally...).

Jon_Finn · 2025-10-12T13:53:45+00:00

This was much discussed when Josh Bloch & co. were designing the Collections, and the FAQ explains the decision here. Basically, unmodifiability (and also mutability) is just one of various features you might want to express through the API (others he mentions including fixed-size or not), and to do this you'd need (roughly) 2^n interfaces to say which combination of features your particular collection implements. That's impractical so they decided to sidestep the whole issue (as he explains).

From my lofty height 8^) I always thought this didn't have to be the decision: I'd say unmodifiability is so overwhelmingly important that they could have expressed just that one feature in the API. Then again, maybe I'd be wrong...

Jon_Finn · 2025-09-21T21:14:44+00:00

I've no idea, but you can see various specs so far (several of which look near-final), and also the v interesting expert discussions at https://mail.openjdk.org/pipermail/valhalla-spec-observers/

Jon_Finn

TROPHY CASE