java frontend

Hi Folks,
Is a java frontend still being developed for llvm?

George

Hi Folks,
  Is a java frontend still being developed for llvm?

Closest thing I know is gcj + dragonegg, but it is a lot of work to be
done in gcj before it works with dragonegg.

George

Cheers,
Rafael

the main issue I know about is that gcj wants to output constructors and
destructors directly to the assembly file, and completely bypasses gcc's
generic machinery for this (probably because gcj predates that machinery).
This is one reason why you can't do link-time optimization with gcc (which
relies on everything going through the generic gcc machinery) and is also why
java compiled with dragonegg doesn't work (generated assembler lacks
constructors/destructors). In my opinion this wouldn't be too hard to fix.

Another issue with gcj is that it's unmaintained (AFAIK), which probably also
explains why it was never updated to support LTO.

Ciao, Duncan.

What about javac + vmkit (J3)?

I've been investigating this some today, and I've been able to get a small Java program (a fairly simple sketch made in the Processing environment), compiled with gcj using DragonEgg, to run on an x86_64 system running CentOS 5 (this is with llvm-3.1, DragonEgg-3.1, and gcc 4.7.0).

I'm attaching the hacked gcc-4.7.0/gcc/java/class.c file, in case anyone's interested. The issue I encountered is that my program's Java classes weren't getting registered with the VM (indeed for the reasons presented above). class.c has a pathway that generates calls to libjava's _Jv_RegisterClass function; these calls evidently do get preserved in DragonEgg's output, and will register the classes when the program is run. So my version of class.c just forces this pathway to be executed by gcj no matter what.

-- Alex

class.c (98.4 KB)