Comment by weinzierl
11 hours ago
It's nice they acknowledge and confirm the need for small, fast native executables.
Having followed the story for this in Java over the decades I'm skeptical about the practicality. GCJ existed in the 90s and the technology was good, but there was no ecosystem support.
After many small steps between GraalVM Native finally tackled the problem more holistically and the ecosystem followed. All the major libraries and frameworks put effort into being GraalVM compatible.
And, still it's a major pain to make even simple existing applications run flawlessly natively.
I'm glad something like scriptc exists but I'm afraid until this is of practical use it will be s long thorny way.
I think the Graal team was also trying to take a meta-interpreter approach like this too. For cases where you need to dynamically load bytecode or do reflection where native couldn't handle it they would try to interpret with their espresso java implementation.
GCJ was always a prototype kind of.
Anyone serious would be paying for Excelsior JET, BEA JRockit, or the myriad of other commercial JDKs wihth AOT tooling.
In fact most likely one reasons why Excelsior is not more, is that now GraalVM and OpenJ9 exist as free bear.
PTC and Aicas still have it good, because few care about their embedded and real time customers.