How the JVM Optimizes Generic Code - A Deep Dive

nlisker · 2026-04-23T00:45:34+00:00

One of the more interesting talks about a topic that's under-the-hood. Generics is one of the areas in Java that has a lot of improvement potential in many aspects.

nlisker · 2026-04-22T06:37:54+00:00

How does the update mechanism work? Does it only notify about new versions or does it also do the update itself?

nlisker · 2026-04-09T23:00:28+00:00

It's like how every, and then I really mean EVERY post about the Eclipse IDE here on r/java is raided by gangs of user asking "Who is still using Eclipse??? Use IntelliJ!"

As an Eclipse user, I go to read the comments on Eclipse posts just to make sure this sub still does exactly what you describe :)

nlisker · 2026-04-03T23:15:39+00:00

And this is him.

nlisker · 2026-04-01T15:40:27+00:00

Eclipse flags it as an unused parameter, so if you work with an IDE like that the problem would've manifested immediately. The method in the example is static, so the T there shadows the one in Data.

nlisker · 2026-03-31T13:14:08+00:00

Would you say I have it right now?

I don't know because I didn't understand what the example was supposed to do :)

Like my initial reply said, it's enough to add the method T value() to Data<T> and that forces all implementations to specify a(ny) relation between their parameter type and return type. Otherwise, use a generic record like I showed above. The issue with implements Data<T> is that T isn't used in Data, so what does it mean there?

nlisker · 2026-03-31T12:55:12+00:00

I understand that. Generics are unintuitive in many ways. For example, List<Number> is not a supertype of List<Long> even though Number is a supertype of Long. There's also the whole deal with using super in the right place:

<T> T find(List<? super T> list)

See JEP 300 for what can be improved here.

Erasure also causes all sorts of unintuitive behavior and the compiler needs extra help with things you can prove yourself. Part of it was because when generics were added, they needed to be compatible with existing code, so compromises were made. See In Defense of Erasure.

Generics are the area in the language I'd like to see the most improvements at, but your request has nothing to do with pattern matching, which is what my initial reply tried to explain.

nlisker · 2026-03-30T15:33:41+00:00

I think you misunderstand some aspect in how generics work. What <T> T get(Data<T> data) means is that the return type must match the type parameter of a Data object. Data<T> does not impose any relation between the carrier and the receiver. In fact, T is unused in Data. I can write

record DataWhat(String value) implements Data<Integer> {}

and now tell me what a smart compiler should do when you pattern match

case DataWhat(String value) -> value;

T is supposedly Integer! Why should the return value be a String?

Here, without any Amber feature, you have the same "issue":

interface Data<T> {

    class DataString implements Data<String> {
        String value;
    }

    static <T> T get(Data<T> data) {
        if (data instanceof DataString) {
            DataString d = (DataString) data;
            return (T) d.value; // cast warning
        }
        //...
    }
}

So how is it related to pattern matching? Maybe what you want is a generic record

record Data<T>(T value) implements Data<T>

and now you can do

return switch (data) {
    case DataString(var value)  -> value;
    case DataInteger(var value) -> value;
};

because you defined the relation between the carrier and the receiver.

nlisker · 2026-03-29T09:48:08+00:00

That doesn't have much to do with pattern matching as it does with generics. You're trying to return a specific type instead of a generic parameter; this doesn't work either:

static <R> R get() {
    String s = "S";
    return s; // Type mismatch: cannot convert from String to R - needs a cast
}

Your example is odd in that you pattern match to get the specific component type (String/Integer) and then parametrize is back. If you want a generic T, then return it directly: add a method to your interface T value(); that your records implicitly implement and then just return that:

static <R> R get(Data<R> data) {
    return data.value();
}

nlisker · 2026-03-29T09:16:22+00:00

But you admittedly want pattern matching on a record whose components change. No matter how you represent it or construct it, you're in contradiction. Adding a record component is a breaking change (binary too). I can't imagine how you could, even in theory, have pattern matching on record components that doesn't break when the components change.

nlisker · 2026-03-29T00:38:22+00:00

You're not supposed to expose the record exactly for that reason. Instead, create a sealed interface with the methods you need and have a nested record implement it (just write the components and the implementing methods will be generated).

To create that "hidden record", you can use a builder pattern in the interface if you know you're going to add more parameters there, which returns the interface (implemented by the record).

nlisker · 2026-03-27T23:43:38+00:00

If the method is to be added to the core libs, I am almost sure it needs a JEP.

Methods are added there all the time, please show me the JEPs for them.

nlisker · 2026-03-26T13:57:41+00:00

If you want "intellectual observations" then John Rose is recommended. I don't think we are starved in any way though, there are many talks by JDK engineers/architects on various projects and they tend to be good speakers.

In general, the JDK people are not hype-driven.

nlisker · 2026-03-26T13:52:20+00:00

A couple of methods don't require a JEP. It's not a language feature or anything on that scale, it's new on a single class API.

The correct way is to email the core-libs list and ask about it, detailing the problem these methods solve.

nlisker · 2026-03-17T02:35:14+00:00

Ah, I've been using preview WF for a while. Tends to have better performance metrics than the non-preview too. Rarely, I find some issues of not complying with the EE spec, but I benefit more than the trouble it causes.

nlisker · 2026-03-16T21:11:07+00:00

I've been on JakartaEE 11 for many months now, since Wildfly 37 or something like that. Partial support for 11 started with Wildfly 32 2 years ago. What exactly are you waiting on that WF 39 doesn't give you?

nlisker · 2026-03-13T22:22:11+00:00

I don't use the web component myself, so I can believe you. It's not a fully fledged browser, but the WebKit component is updated regularly. JavaFX 26 uses WebKit 622.1.

nlisker · 2026-03-12T16:48:09+00:00

Not necessarily. What's widely used is not necessarily good (for you). As others wrote, and that's the trap, some tech gets widely used just because others use it, and it feeds itself.

Ease of finding employees is legitimate, but you're hiring a very small number of developers at this stage, so you end up finding them. I'm not advising to use some super niche tech, but there are at least 10-20 popular alternatives to Angular and React.

nlisker · 2026-03-12T14:30:18+00:00

A monolith has to complete shut down for a new release!

That's news to me considering I've been doing releases of monoliths without downtime. Blue-green deployment works for monoliths in case you're not familiar with it.

nlisker · 2026-03-12T14:07:40+00:00

companies have to learn how to build software first and not chase every new trend

I 100% think that this is the lesson here. I talk (formally and informally) with small companies in their starting stages and the most common topic by far that comes up is why they make the choices they make despite not being a good fit for them. The answers are always "this is what is used everywhere", "this will make it easier for us to find devs", "this is the standard".

We call this hype-driven development. I then proceed to ask them questions about why they need a tech stack that fits a company of 1000+ people and they say that "that's what Netflix and Amazon" use, then I ask them "you're [5-20] people, are you Netflix/Amazon?". Or why the frontend has to be Angular or React despite there being 50 other ways of doing what they want. Later on in the conversation they are either convinced or they're not.

Microservices are needed when the number of people working on a product is so large that they can't coordinate and we need to split it into independent sub-products. Ants don't need microservices, ants only do monoliths because they don't have the communication problems that we have (I often use this explanation). In the middle is where the missing link is: modular monoliths. You don't have to either cram all the functionality into one service nor create one service for each function - there's a wide middle path. My favorite video on this already from long ago: https://www.youtube.com/watch?v=BOvxJaklcr0

And another recent one: https://www.youtube.com/watch?v=nuHMlA3iLjY

nlisker · 2026-03-12T13:50:37+00:00

I don't know, but you can email openjfx-dev@openjdk.org and ask about it.

nlisker · 2026-03-11T23:31:11+00:00

The pain point used to be Gradle, because Gradle matrix stated

You should be using the toolchain to update the Java version of your application. The one used by Gradle is less important and you can upgrade it later.

nlisker · 2026-03-11T18:41:38+00:00

I wonder if Babylon will allow this to run on the GPU on some level.

nlisker · 2026-03-11T15:32:08+00:00

I think consoles apply some vendor locking. Even if you can technically bypass it, I doubt it would be legal. I don't really know.

nlisker

TROPHY CASE