7 ms·

Excelsior JET did that 25 years ago: https://en.wikipedia.org/wiki/Excelsior_JET https://en.wikipedia.org/wiki/Excelsior_JET It's a shame that Sun/Oracle never

Excelsior JET did that 25 years ago: https://en.wikipedia.org/wiki/Excelsior_JET https://en.wikipedia.org/wiki/Excelsior_JET It's a shame that Sun/Oracle never partnered with them to bring native apps. This could have saved Java on the desktop.

patwolf 6d ago
IBM's J9 had AOT for a long time too. I wonder how JEP 544 compares.
- samus 5d ago
  IMHO the most interesting feature of OpenJ9 is the compile server. One node decides to optimize, sends over the traces, and the compile server sends optimized native code to all nodes. Or a new node joins and could be brought up to speed within a very short time.
  - pjmlp 4d ago
    Azul also has a similar feature, as added info.
wahern 6d ago
Don't forget GCJ. It wasn't removed from GCC until about 2016, a nearly 20-year long run, though interest had waned many years prior. I don't remember if GCJ supported loading and running code dynamically with a built-in JIT or interpreter. I think it was just pure AOT, which caused some compatibility headaches.
- java-man 6d ago
  GCJ was great - I wrote a handset UI entirely in java for a startup in the early 2000's, basically android before android existed, using GCJ. I remember their native interface was somewhat more convenient to use than JNI. I wish we had GCJ resurrected, now that the java libraries are GPL'd.
  - alex7o 6d ago
    Just ask claude to port it to latest gcc :P, pls don't
- cyberax 6d ago
  Yeah! I used it around 2003 to integrate a Java PDF parsing library into our C++ app. Its biggest downside was the use of Boehm GC that had some issues with large heaps.
- atgreen 6d ago
  I worked on this years ago. Gcj did support loading and interpreting bytecode alongside the AOT-compiled code. libffi's closures were originally implemented to support calling interpreted methods from AOT-compiled code, because a class's vtable could include a mix of AOT-compiled and interpreted methods. You could also compile jar files directly into .so files, which would get loaded and used at runtime if a classloader ever loaded the corresponding jar.
pjmlp 6d ago
They were not the only ones, see PTC, Aicas, IBM, and a few others. The big difference until GraalVM and OpenJ9 became available as open source, was that all those vendors made AOT compilation a commercial feature, and thus most devs never cared they existed. In fact GraalVM was one of the main reasons Excelsior JET eventually closed doors.
DonHopkins 6d ago
The only thing that could possibly save Java on the desktop would require Oracle not owning it.
- pjmlp 5d ago
  Had it not been for Oracle, Java would have died in version 6.
misja111 5d ago
The JRockit JVM had it already 20 years ago, and the company was even bought by Oracle shortly afterwards.
- pjmlp 4d ago
  Some of the features have been added to JDK or GraalVM.

patwolf 6d ago

IBM's J9 had AOT for a long time too. I wonder how JEP 544 compares.

samus 5d ago
IMHO the most interesting feature of OpenJ9 is the compile server. One node decides to optimize, sends over the traces, and the compile server sends optimized native code to all nodes. Or a new node joins and could be brought up to speed within a very short time.
- pjmlp 4d ago
  Azul also has a similar feature, as added info.

wahern 6d ago

Don't forget GCJ. It wasn't removed from GCC until about 2016, a nearly 20-year long run, though interest had waned many years prior. I don't remember if GCJ supported loading and running code dynamically with a built-in JIT or interpreter. I think it was just pure AOT, which caused some compatibility headaches.

java-man 6d ago
GCJ was great - I wrote a handset UI entirely in java for a startup in the early 2000's, basically android before android existed, using GCJ. I remember their native interface was somewhat more convenient to use than JNI. I wish we had GCJ resurrected, now that the java libraries are GPL'd.
- alex7o 6d ago
  Just ask claude to port it to latest gcc :P, pls don't
cyberax 6d ago
Yeah! I used it around 2003 to integrate a Java PDF parsing library into our C++ app. Its biggest downside was the use of Boehm GC that had some issues with large heaps.
atgreen 6d ago
I worked on this years ago. Gcj did support loading and interpreting bytecode alongside the AOT-compiled code. libffi's closures were originally implemented to support calling interpreted methods from AOT-compiled code, because a class's vtable could include a mix of AOT-compiled and interpreted methods. You could also compile jar files directly into .so files, which would get loaded and used at runtime if a classloader ever loaded the corresponding jar.

pjmlp 6d ago

They were not the only ones, see PTC, Aicas, IBM, and a few others. The big difference until GraalVM and OpenJ9 became available as open source, was that all those vendors made AOT compilation a commercial feature, and thus most devs never cared they existed. In fact GraalVM was one of the main reasons Excelsior JET eventually closed doors.

DonHopkins 6d ago

The only thing that could possibly save Java on the desktop would require Oracle not owning it.

pjmlp 5d ago
Had it not been for Oracle, Java would have died in version 6.

misja111 5d ago

The JRockit JVM had it already 20 years ago, and the company was even bought by Oracle shortly afterwards.

pjmlp 4d ago
Some of the features have been added to JDK or GraalVM.