Oracle Releases GraalVM 22.3, GraalVM CE Java Code Going To OpenJDK

[phoronix]

Phoronix: Oracle Releases GraalVM 22.3, GraalVM CE Java Code Going To OpenJDK

GraalVM 22.3 is now available as Oracle's quarterly feature release to this high performance Java JVM/JDK that also supports additional programming languages and execution models...

https://www.phoronix.com/news/GraalVM-22.3-Released

[linuxgeex]

When I hear "CE" I still automatically think WinCE for Compact Embedded, but without looking I would guess in this context it's Community Edition. Usually I would research it, but it's Oracle, and Java - two things I don't care enough about to research.

So yeah, this is for awkward comedy value only. Anyone else thought CE as in WinCE?

[Degra]

GraalVM is one of the biggest things that happened to Java in the past decade, adding it to the JDK will drive adoption up by a lot!

Excited for what the future will bring.
The Spring Framework is adding native support for GraalVM's AOT compilation with their next version as well!

Anyone else thought CE as in WinCE?

Nah, CE is a common abbreviation for Community Edition.

[brucethemoose]

Now, if only they would contribute the EE compiler optimizations.


Imagine if Oracle owned LLVM or something, and you had to sign up and agree to some massive TOS to enable stuff like auto vectorization or better inlining :/.

[zexelon]

When I hear "CE" I still automatically think WinCE for Compact Embedded, but without looking I would guess in this context it's Community Edition. Usually I would research it, but it's Oracle, and Java - two things I don't care enough about to research.

So yeah, this is for awkward comedy value only. Anyone else thought CE as in WinCE?

Yup, CE is always going to be 100% linked to WinCE in my mind! Lets be honest, it was probably the only Windows mobile product that could have been something... if they didnt dump it

[69Y69]

The Spring Framework is adding native support for GraalVM's AOT compilation with their next version as well!

AOT is cool for small strictly curated projects. A single dependency living somewhere deep in the dependency tree using some reflection tricks in a dynamic way under its hood would simply make using AOT impossible.

You can try to workaround it with 'capturing' the reflection usage and feeding that back to the AOT but that still covers only the tested/known paths. Any change triggering a new reflection usage which was not covered would break the AOT again. Pretty tedious for systems heavily driven by data.

My take is that it is pretty hard to actually use it real-world business.

[brucethemoose]

AOT is cool for small strictly curated projects. A single dependency living somewhere deep in the dependency tree using some reflection tricks in a dynamic way under its hood would simply make using AOT impossible.

You can try to workaround it with 'capturing' the reflection usage and feeding that back to the AOT but that still covers only the tested/known paths. Any change triggering a new reflection usage which was not covered would break the AOT again. Pretty tedious for systems heavily driven by data.

My take is that it is pretty hard to actually use it real-world business.

It would be great if graal could use AOT code with the JIT.

Compile ahead of time and use that code instead of interpreting everything as it comes. Recompile the hot paths, just as it normally does. And if it encounters unknown reflection or something like that, fall back to interpreting + the JIT.


(I realize graal cant really do this, and what Azul is doing is much closer to that).

[Michael_S]

Anyone else thought CE as in WinCE?

Yes, but that probably only means we're both old.

[ari55]

Anyone else thought CE as in WinCE?

Never used it, but yes.

Yes, but that probably only means we're both old.

Add me too to the list.