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

41–50 of 80 posts

Re: GraalVM for JDK 21

#41

Post by atgreen »

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 worked on gcj (and GNU Classpath) for a number of years. gcj's origins are in the embedded systems space, where our customers valued the small memory footprint and portability across processor architectures that were unlikely to get performant JITs. As we eased out of the embedded space, it was clear that jumping on the OpenJDK train was the right choice for Free Software-minded gcj/Classpath devs, as Sun adopted the GPL and GNU Classpath exception license. gcj was unlikely to ever catch up, and many of us were motivated by the idea of a Free Software Java solution, which Sun just handed to us.

Re: GraalVM for JDK 21

#42

Post by JacobiX »

AndyPa32 wrote: post #25
gzalo wrote: post #17

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

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?

From my understanding, Spring Boot takes care of providing the JSON metadata for many libraries, including Jackson. So in practice, it can be more straightforward to use it in a Spring Boot project.

Re: GraalVM for JDK 21

#43

Post by emptysongglass »

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…

As someone on the outside looking at GraalVM with curiosity, is it even possible to use something like Poetry to manage the Python part? Would you do that? Would I even need a venv anymore? Where would its edges be? What are the limits?

How are we people practically putting this polyglot stuff into action?

Re: GraalVM for JDK 21

#44

Post by refset »

The linked sibling post on "New Truffle and GraalVM Languages release" feels rather exciting too https://medium.com/graalvm/new-truffle-and-graalvm-languages...

Specifically:

> GraalVM language runtimes (for JavaScript, Python, Ruby, Java on Truffle, WebAssembly, and LLVM) can now be [...] installed as Maven/Gradle dependencies [...] which will work for GraalVM JDK and any other compatible JDK

Polyglot experimentation just got a whole lot easier! Kudos to everyone involved in pushing the JVM ecosystem forwards.

Re: GraalVM for JDK 21

#45

Post by uticus »

switchbak wrote: post #27
shellac wrote: post #10

Earlier quoted context omitted.

> [...] 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).

I agree, from an outside perspective it is bewildering. Especially when GraalVM itself becomes a platform for other languages, ie Truffle https://www.graalvm.org/latest/graalvm-as-a-platform/

Re: GraalVM for JDK 21

#46

Post by uticus »

alberth wrote: post #8

What’s the latest on Truffle/Ruby supporting Rails? Wouldn’t this provide massive gains for the Rails ecosystem once delivered? (And with the GraalVM licenses changes to be more favorable/permission, I have to imagine there would be significant adoption)

GitHub page has some info: https://github.com/oracle/truffleruby#current-status

My question is, how viable is TruffleRuby vs JRuby?

Re: GraalVM for JDK 21

#47

Post by dig1 »

tombert wrote: post #34

I'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 uberja…

The recurring problem I've seen that would cause slow startup is cramming many (require) and (import) in the project core.clj file - for non-clojure devs here, this means including a lot of dependencies in the file called on the startup.

By reordering things to be loaded smartly or lazily, startup speed can be improved a lot.

Another reason for a slow startup is that Clojure must load its own runtime every time. The current compiler is not a tree shaker, nor can it rewrite complex expressions in compile-time, although many clojure.core functions were rewritten over time to accommodate JVM optimizers. However, Graal is here precisely to do at the bytecode level, as long as you take care of all type hint warnings and avoid things Graal can't see during compilation (e.g. deferring evaluation of some expressions for runtime).

Re: GraalVM for JDK 21

#48

Post by kaba0 »

adra wrote: post #33
jabradoodle wrote: post #28

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

You can try to use Graal as a JIT compiler as well, in case of Scala for example that has a bit more indirection on average it can cause some speedups.

Otherwise, it trades blows with hotspot.

Re: GraalVM for JDK 21

#49

Post by logicchains »

mike_hearn wrote: post #16
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…

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

>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

Does this mean that once Project Valhalla lands, Java via Graal will be a viable competitor to C++ for tasks requiring extremely high performance?

Re: GraalVM for JDK 21

#50

Post by kaba0 »

_ea1k wrote: post #5

I just wish the compile times weren't so painfully slow. It makes it really difficult to work with.

You can generally develop with the JDK, and only compile from time to time.
Post reply on HN