Oracle Releases GraalVM 20.1 Virtual Machine With Some Big Improvements

[bug77]

Not tough, impossible. You’re talking about the difference being compile-time and run-time. The only thing you can do, other than rewrite libraries not to use dynamic features, is to provide the information ahead of time. An example is PGO, where the profiles are given rather than determined at runtime. For reflection, they have a tool called Tracing Agent which does something similar, but I have no idea how effective it is. It seems like a pain considering you’d have to run with different inputs to test all the code paths. Makes more sense to refactor libraries.

Correct, that's the best we can hope for: identifying a subset of reflection usage that can be treated more or less automatically. Between that and libraries and frameworks starting making use of annotation processors where it makes sense, there may a chance to crack this nut

[cynical]

Second, this article is about GraalVM (and native tool), so I was specifically asking whether the native tool itself was improved in any way wrt to reflection handling (admittedly, a tough nut to crack).

Not tough, impossible. You’re talking about the difference being compile-time and run-time. The only thing you can do, other than rewrite libraries not to use dynamic features, is to provide the information ahead of time. An example is PGO, where the profiles are given rather than determined at runtime. For reflection, they have a tool called Tracing Agent which does something similar, but I have no idea how effective it is. It seems like a pain considering you’d have to run with different inputs to test all the code paths. Makes more sense to refactor libraries.

[cynical]

Too many libraries and frameworks use and abuse reflection (I'm looking at you, Spring), for it to be anything but a toy.

Spring will support native image this year.

[bug77]

Yes, it will compile and work. See the Jackson support here: https://quarkus.io/extensions/#serialization

And it's not wrappers. It's adding build-time support for things that are normally done on-the-fly at runtime.
And as for suitability in microservice environments, there are examples where native Graal + Quarkus is beating Go in terms of code size and memory usage, which is pretty awesome.
You really should read up on it before dissing it further.

First, I'm not dissing anything. I was just describing how things were last I checked (try as I may, I can't keep up with everything that's going on) and asking whether anything was done about the elephant in the room.
Second, this article is about GraalVM (and native tool), so I was specifically asking whether the native tool itself was improved in any way wrt to reflection handling (admittedly, a tough nut to crack). Kudos to Quarkus for coming up with a solution, but I was hoping for a common solution in GraalVM rather than a framework specific one.
Third, beating Go is nothing to brag about, Go was only meant to yield Java performance at Python development speed

[quintesse]

I think there's a misunderstanding here: when my code depends on Jackson and Jackson is reflection-heavy, it will not compile into native code, no matter what I wrap it into.
Throwing yet another wrapper on top is a lame solution anyway, further highlighting how unsuitable Java (or any JVM based language) really is for a microservices world. Luckily, it's not all microservices. At least not yet.

Yes, it will compile and work. See the Jackson support here: https://quarkus.io/extensions/#serialization

And it's not wrappers. It's adding build-time support for things that are normally done on-the-fly at runtime.
And as for suitability in microservice environments, there are examples where native Graal + Quarkus is beating Go in terms of code size and memory usage, which is pretty awesome.
You really should read up on it before dissing it further.

[bug77]

Well, first of all, no we won't have to rewrite almost any library and framework because there are ways to adapt existing code to work within the limitations set by the native image tool. In Quarkus for example it's being done by their extension system (https://www.baeldung.com/quarkus-extension-java , https://quarkus.io/guides/writing-extensions), And there are already lots of extensions for many of the popular libraries and frameworks, but if the one you need isn't there you can create one yourself.

Now the system of course isn't perfect and there will be cases where upstream changes need to be made to make things work. But the Quarkus team has been doing a lot of that. So the future isn't as dark as you suppose.

Also because improving the native tool to support all (dynamic) things that are possible in Java might likely never happen. At least not without removing all the advantages compiling to native code give you in the first place. Which means developers have a good reason to want to make sure their code can run on Graal.

I think there's a misunderstanding here: when my code depends on Jackson and Jackson is reflection-heavy, it will not compile into native code, no matter what I wrap it into.
Throwing yet another wrapper on top is a lame solution anyway, further highlighting how unsuitable Java (or any JVM based language) really is for a microservices world. Luckily, it's not all microservices. At least not yet.

[quintesse]

And therein lies the problem: you fixed it in Quarkus. And one I pull in a dependency that makes use of reflection, the native tool will still fail to compile my project into native code.
The solution needs to come from the native tool itself, otherwise we'll be forced to rewrite almost any library and framework under the sun.

Well, first of all, no we won't have to rewrite almost any library and framework because there are ways to adapt existing code to work within the limitations set by the native image tool. In Quarkus for example it's being done by their extension system (https://www.baeldung.com/quarkus-extension-java , https://quarkus.io/guides/writing-extensions), And there are already lots of extensions for many of the popular libraries and frameworks, but if the one you need isn't there you can create one yourself.

Now the system of course isn't perfect and there will be cases where upstream changes need to be made to make things work. But the Quarkus team has been doing a lot of that. So the future isn't as dark as you suppose.

Also because improving the native tool to support all (dynamic) things that are possible in Java might likely never happen. At least not without removing all the advantages compiling to native code give you in the first place. Which means developers have a good reason to want to make sure their code can run on Graal.

[Sin2x]

Some benchmarks against OpenJ9 and other Java VMs would be nice to see.

[bug77]

We solved the "Reflection problem" - and many others - systematically in Quarkus; that's actually why the new platform was designed like it is: embrace such limitations and actually take advantage of them: it's a feature as it comes with amazing optimisation potential. Maybe you should have another look at it.

We're all very happy with how this is designed and I don't expect that to change, it's certainly not a reason to disregard it or consider it experimental or a toy.

And therein lies the problem: you fixed it in Quarkus. And one I pull in a dependency that makes use of reflection, the native tool will still fail to compile my project into native code.
The solution needs to come from the native tool itself, otherwise we'll be forced to rewrite almost any library and framework under the sun.

[sanne]

Good to know it works with ARM, but until it figures out what to do about reflection, it will stay experimental. Too many libraries and frameworks use and abuse reflection (I'm looking at you, Spring), for it to be anything but a toy.

We solved the "Reflection problem" - and many others - systematically in Quarkus; that's actually why the new platform was designed like it is: embrace such limitations and actually take advantage of them: it's a feature as it comes with amazing optimisation potential. Maybe you should have another look at it.

We're all very happy with how this is designed and I don't expect that to change, it's certainly not a reason to disregard it or consider it experimental or a toy.