back
19 comments
Related from 2 weeks ago: https://news.ycombinator.com/item?id=25838364
This is pretty exciting. I have tried to build a native image using GraalVM for Jenkins as mentioned in this article and it was not possible due to Jenkins relying on reflection. Hopefully this helps with resource usage, I always feel a bit of OCD with Java applications tending to require tons of resources and developers being okay with it. Sure, companies have more money to spend and can afford larger instances but it takes away some of the spirit of hobby, DIY, and projects outside of work.

This should also mean that you can build Jython and JRuby static binaries/executables, but it will probably be a large binary.

Interesting but I would be reluctant to touch anything controlled by Oracle. They don't have a good track record of treating developers nicely. E.g. trying to claim copyrights on APIs. Or, recent Java licensing changes. Bit like sticking your hand in a lawn mower, IMHO.
Amazon, IBM, Red-Hat, SAP, Microsoft, Azul, Alibaba, Twitter, Azul, PTC, Aicas, microEJ are doing perfectly fine.

The day will come for Google's J++.

It's not like what Google did with "java" on Android was good for developers OR for Java. It's amazing that they don't also look like bad guys here. I get why Oracle gets ill will, I don't understand why Google gets good will.
The AOT stuff is cool, but honestly if we had compelling needs for that we'd just use another language. The scripting engine is incredible, though, and I think a real differentiator for the JVM.
Or just pay for one of the commercial JDKs that have been around with AOT and JIT caches support, like JRockit or IBM in the pre-OpenJ9 days.

All this Java in Java, that traces back to Maxime and Rikes is cool for compiler nerds, and we get to have free beer AOT/JIT caches as well.

Green fielding on a new language is really not an option for the vast majority of software. To that point you are not really a target user for this if you can just up and switch stacks like that.
This isn't a defense of greenfield -- my point is that if we haven't had a need for AOT for the past ten years, we don't have one now. I imagine 99% of big Java apps are in a similar position. Getting a legacy Java app to compile AOT isn't trivial either.
Let alone that almost no other language has the JVM ecosystem.
Most of the JVM ecosystem doesn't work with AOT due to issues with reflection.
"Most" is a bit hyperbolic, and reflection can be supported in the VM for AOT code, as evidenced by the Android Runtime (pre-JIT).
Yet commercial Java vendors with AOT tooling have been in business since around 2000, so plenty of projects do just fine.
Good thing espresso can support both!
Reminds me the Jikes Research Virtual Machine (Jikes RVM) project https://en.m.wikipedia.org/wiki/Jikes_RVM
And there are also Squawk and Maxime from Sun.
It seemed pretty funny back then, too.
Curious to know if this would allow me to run client submitted java at runtime similar to how you can execute javascript in a sandbox ( ok i know it is not fully secure) using graaljs or nashorn?
Like how Squeak was written in Squeak. Cool!