Lots of comments about issues with dependencies and Graal. I suggest looking into Quarkus. Have had great success with and mandrel (a patched version of Graal for Quarkus). Quarkus focuses on creating Web APIs so wont cover it all but if thats what you want to do its great and builds native images quite easily.
GraalVM for JDK 21
31–40 of 80 posts
Re: GraalVM for JDK 21
#32Earlier quoted context omitted.
https://www.graalvm.org/latest/security-guide/polyglot-sandb... looks very interesting though enterprise (not open source I assume?) only and maybe only for executing javascript? Or do I misunderstand, or is there other sandboxing support?
The Polyglot sandbox is licensed under GFTC: https://www.oracle.com/downloads/licenses/graal-free-license... ISOLATED and UNTRUSTED require GFTC CONSTRAINED is also available under open-source licenses. Only for JavaScript right now. We are working hard on supporting all the other languages! Developer here. So, if you have more questions, let me know!
Thanks for explaining and for your work!
Not sure I have questions, just generally interested in making it easier/lighter weight/built-in to constrain ambient authority (for example, to mitigate supply chain risks), thus have it be done more.
The Polyglot sandfox feels very loosely analogous to Deno per process (and thus subprocess) permissions, though it looks like ISOLATED and UNTRUSTED can limit a bunch of things not possible with Deno.
Re: GraalVM for JDK 21
#33Earlier 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…
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.
Everything has a cost though. The one thing we lose is the ability for hotspot to change its mind and recompile code based on usage patterns I've toyed with graalvm for some uses and ended up with lost performance. Also a key note is that it only supports a pretty naive serialgc right now which is a big limitation. Bellsoft has a parallelgc which probably plays a little better, but we're always going to need to play trade-offs until they can support the more robust GC impls
Re: GraalVM for JDK 21
#34I've only done one project with GraalVM and I've been pretty happy with it in regards to faster startup time.
I was doing stuff in Clojure. Clojure is a great language but it tends to have very slow startup times, even by JVM standards (it's not weird for a large Clojure program to take 5-6 seconds to start. Even a "hello world" can take upwards of a second or two). Graal mostly Just Worked with the standalone uberjar produced by Leiningen and created an executable that started in about 3 milliseconds. It was amazing.
While the lack of proper reflection support was a little annoying, it actually wasn't as horrible with Clojure as you might think; most problems were fixed with basic type hinting, and all but one Clojure library I used (http-kit) worked flawlessly.
Re: GraalVM for JDK 21
#35I 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, ser…
Not sure if you are aware of it, but Graal is also a JVMCI-comparible JIT compiler.
Also, there was a proposal (not yet JEP though) on condensers and that model could also make great use of GraalVM.
Re: GraalVM for JDK 21
#36Earlier quoted context omitted.
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.
Everything has a cost though. The one thing we lose is the ability for hotspot to change its mind and recompile code based on usage patterns I've toyed with graalvm for some uses and ended up with lost performance. Also a key note is that it only supports a pretty naive serialgc right now which is a big limitation. Bellsoft has a parallelgc which probably plays a little better, but we're always going to need to play…
The serial GC is a limitation of the community (OSS) edition. The enterprise proprietary version has G1 support.
I hope Oracle will let it drip it down to the CE, but it's their project, their monetization strategy.
Re: GraalVM for JDK 21
#37We 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?
What's wrong with it? Genuinely curious. I've using Graal with spring/Jackson for a long time and haven't noticed any issue.
Re: GraalVM for JDK 21
#38I 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, ser…
The linked post shows the AoT compiler ahead of the JIT one, it seems like PGO really closes the gap :)
Re: GraalVM for JDK 21
#39Earlier quoted context omitted.
The Polyglot sandbox is licensed under GFTC: https://www.oracle.com/downloads/licenses/graal-free-license... ISOLATED and UNTRUSTED require GFTC CONSTRAINED is also available under open-source licenses. Only for JavaScript right now. We are working hard on supporting all the other languages! Developer here. So, if you have more questions, let me know!
Thanks for explaining and for your work! Not sure I have questions, just generally interested in making it easier/lighter weight/built-in to constrain ambient authority (for example, to mitigate supply chain risks), thus have it be done more. The Polyglot sandfox feels very loosely analogous to Deno per process (and thus subprocess) permissions, though it looks like ISOLATED and UNTRUSTED can limit a bunch of things…
We do not do process isolation yet, although we have plans to implement that as well as a fallback strategy.
The advantage of the native-image-isolate-based isolation is that it is much more lightweight. For example, calls from and to the host application are much faster. There is no copying or expensive synchronization necessary. The disadvantage is that we need to do our own protections against attacks, as the OS protections between processes don't apply to such isolates. By default, we deploy software/compiler-based protections but are also very close to supporting hardware like Intel MPK.
If you have more questions, you can also drop by on Slack; we are a friendly bunch: https://www.graalvm.org/slack-invitation/
Re: GraalVM for JDK 21
#40We 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
ye even less relevant for that usecase with snapstart.