logoalt Hacker News

wahernyesterday at 6:45 PM3 repliesview on HN

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.


Replies

atgreentoday at 2:24 AM

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.

java-manyesterday at 7:00 PM

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.

show 1 reply
cyberaxyesterday at 7:30 PM

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.