Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraalVM for JDK 21

medium.com

Post reply on HN
Print view View original

11–20 of 80 posts

Re: GraalVM for JDK 21

#11

Post by mlinksva »

mgdev wrote: post #4

GraalVM 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…

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?

Re: GraalVM for JDK 21

#12

Post by weinzierl »

shellac wrote: post #10
weinzierl wrote: post #6

Earlier 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.

Good point. It is fascinating technology, but to get development resources in the long run it needs management/sponsor attention and for that it needs a practical use case today. That, I think is AoT compilation and I believe that, unfortunately, it doesn't cut it there.

Re: GraalVM for JDK 21

#13

Post by foobarbazetc »

mgdev wrote: post #4

GraalVM 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.

Re: GraalVM for JDK 21

#14

Post by aseipp »

weinzierl wrote: post #6
mgdev wrote: post #4

GraalVM 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…

I think the reality is that faster startup, smaller deployments, and lower memory usage is considered much more valuable today than it was when GCJ was an actively maintained project. It simply did not offer things people needed at that time. But now, the tradeoffs are different, and so the effort of going back and modifying existing code to support AOT compilation has a greater overall payoff than it did in the past, which is why people are pursuing it. It's the same reason .NET is adding full AOT support - because people want it now, and they want it now more than they did before.

Re: GraalVM for JDK 21

#15

Post by gavinray »

mlinksva wrote: post #11
mgdev wrote: post #4

GraalVM 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…

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?

Many of the configuration settings set by a sandboxing policy are available when creating Polyglot contexts with the Community Edition.

Re: GraalVM for JDK 21

#16

Post by mike_hearn »

weinzierl wrote: post #6
mgdev wrote: post #4

GraalVM 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…

gcj had a lot of problems beyond needing configuration of reflection metadata. It used a full reimplementation of the standard library, and it was never adopted by the wider Java community being largely just Red Hat's strategy for creating a fully open source Java implementation rather than something offering specific benefits to Java developers. In particular people thought it'd lead to faster code, but GCC was never designed for Java and the results were actually a fair bit slower iirc.

Native image is quite different. With this new release the compiled images can not only be faster than JIT compiled Java (wow) but also use way less memory and start instantly. At a stroke this is resolving one of the biggest complaints people have always had against JVM languages.

And as a consequence you're seeing adoption by the wider community. All the modern Java web frameworks support it now, and there's a metadata repository where it's collected for projects that haven't accepted it upstream yet [1].

[1] https://github.com/oracle/graalvm-reachability-metadata

Re: GraalVM for JDK 21

#17

Post by gzalo »

We 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

Re: GraalVM for JDK 21

#18

Post by pjmlp »

weinzierl wrote: post #6
mgdev wrote: post #4

GraalVM 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…

It was taken seriously, as commercial 3rd party offering, from which PTC and Aicas are the surviving vendors.

Also Android uses a mix of AOT and JIT since version 5.

Re: GraalVM for JDK 21

#19

Post by grashalm »

mlinksva wrote: post #11
mgdev wrote: post #4

GraalVM 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…

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!

Post reply on HN