Congrats to the GraalVM team on all their hard work
GraalVM for JDK 21
21–30 of 80 posts
Re: GraalVM for JDK 21
#22I am more interested in this proposal
https://openjdk.org/jeps/8313278
It is "Ahead of Time Compilation for the Java Virtual Machine". The proposal details of using AOT code at startup and then JIT taking over. So you get best of both worlds with fast application launch and then throughput once things are warmed up.
Graal is cool, but it will not be as throughput performant compared to JIT. Only for fast startup, serverless or low memory environments.
Re: GraalVM for JDK 21
#23GraalVM is a hugely under-appreciated piece of technology. A lot of my initial interest came from being able to blend different languages into a single runtime via the polyglot APIs, but the combination of performance, strong sandboxing support, and multi-language support has helped it emerge as a key primitive for anyone wishing to build extensible platforms without sacrificing speed, security, or developer ergonomi…
It's fascinating technology, but in my opinion too little, too late. Compiling with GraalVM is still a pain and will not work out-of-the-box without modifications for any non-trivial project. This is mostly, I believe, not GraalVM's fault, because it can only do so much within the confines of the existing ecosystem. If only AoT compilation to native code would have been taken seriously from the start, if only gcj wou…
> my prediction is that in a few years it will be in the same state gcj has been quite some years now
I'll take that bet.
GraalVM has only gotten more and more popular.
There are a lot of situations (large server applications) that don't benefit much from AOT.
But others do. Android is (partially) AOT.
Re: GraalVM for JDK 21
#24We tried to use it to improve AWS lambda startup times but desisted as it was a pain to use it with an existing app. It required too many tweaks as there are waay too many things that rely on reflection :( Things that broke include: JSON (de)serialization using Jackson, validations using hibernate, validator, AWS SDK, and even simpler libs like picocli... It could be quite useful for a set of simpler apps though
Picocli allows using a compiler annotation processor to generate classes at compile time instead [0].
[0]: https://github.com/remkop/picocli/blob/main/picocli-codegen/...
Re: GraalVM for JDK 21
#25We tried to use it to improve AWS lambda startup times but desisted as it was a pain to use it with an existing app. It required too many tweaks as there are waay too many things that rely on reflection :( Things that broke include: JSON (de)serialization using Jackson, validations using hibernate, validator, AWS SDK, and even simpler libs like picocli... It could be quite useful for a set of simpler apps though
Yes, Jackson really was a bummer. To this day I can't understand how a project like Springboot advertises Graalvm readiness when Jackson is not supported without tweaks. What do the Springboot devs think we are using Springboot for, Hello World blog posts?
Re: GraalVM for JDK 21
#26GraalVM is a hugely under-appreciated piece of technology. A lot of my initial interest came from being able to blend different languages into a single runtime via the polyglot APIs, but the combination of performance, strong sandboxing support, and multi-language support has helped it emerge as a key primitive for anyone wishing to build extensible platforms without sacrificing speed, security, or developer ergonomi…
We use Graal to sandbox a scripting language based on EcmaScript 6 for our app. It’s great.
Can you say more on this? We're trying to do something similar and curious to know more
Re: GraalVM for JDK 21
#27Earlier quoted context omitted.
It's fascinating technology, but in my opinion too little, too late. Compiling with GraalVM is still a pain and will not work out-of-the-box without modifications for any non-trivial project. This is mostly, I believe, not GraalVM's fault, because it can only do so much within the confines of the existing ecosystem. If only AoT compilation to native code would have been taken seriously from the start, if only gcj wou…
> [...] my prediction is that in a few years it will be in the same state gcj has been quite some years now. You make it sound like GraalVM is just for ahead-of-time compiling like gcj, but there's more to it than native image. It's possible GraalVM will be openjdk's jit compiler, for example.
This is one of my challenges with the branding of the project - it's not super clear to me what folks are talking about when they mention Graal related tech.
That alone I think can muddy the waters and can even hurt adoption. I wish they had clear and meaningful names for the specific distinct pieces of tech (even if there is some shared underpinnings).
Re: GraalVM for JDK 21
#28GraalVM is a hugely under-appreciated piece of technology. A lot of my initial interest came from being able to blend different languages into a single runtime via the polyglot APIs, but the combination of performance, strong sandboxing support, and multi-language support has helped it emerge as a key primitive for anyone wishing to build extensible platforms without sacrificing speed, security, or developer ergonomi…
It's fascinating technology, but in my opinion too little, too late. Compiling with GraalVM is still a pain and will not work out-of-the-box without modifications for any non-trivial project. This is mostly, I believe, not GraalVM's fault, because it can only do so much within the confines of the existing ecosystem. If only AoT compilation to native code would have been taken seriously from the start, if only gcj wou…
Were talking enterprise java, it's a behamouth and changing it takes forever.
I think in today's ecosystem of microservices and serverless etc, AOT will be taken pretty seriously.
Re: GraalVM for JDK 21
#29We tried to use it to improve AWS lambda startup times but desisted as it was a pain to use it with an existing app. It required too many tweaks as there are waay too many things that rely on reflection :( Things that broke include: JSON (de)serialization using Jackson, validations using hibernate, validator, AWS SDK, and even simpler libs like picocli... It could be quite useful for a set of simpler apps though
this was our experience as well. Both with GraalVM/Quarkus and .NET CrossGen/Native/CoreRT. It's almost a different platform that's far less supported and less stable. Even if you put in the work to make things work, they'll eventually break. Quarkus tries to give a full experience like Kotlin Native, but both are also not really there.
It's really unfortunate how Java and C# are perceived as slow because of their painful startup time.
Re: GraalVM for JDK 21
#30From 5 years ago, but still fascinating: Ten Things You Can Do With GraalVM by Chris Seaton
https://gist.github.com/chrisseaton/535e0e80ea19803d5529c623...