tags:

views:

555

answers:

6

I'm looking for a compiler to translate Java bytecode to platform-independent C code before runtime (Ahead-of-Time compilation).

I should then be able to use a standard C compiler to compile the C code into an executable for the target platform. I understand this approach is suitable only for certain Java applications that are modified infrequently.

So what Java-to-C compilers are available?

+3  A: 

Why do that? The Java virtual machine includes a runtime Java-to-assembly compiler.

Compilation at runtime can yield better performance, since all information about runtime values is available. While ahead-of-time compilation has to take assumptions about runtime values and thus may emits less fast code. Please refer to Java vs C performance by Cliff Click for more details.

Adrian
Compilation at runtime *can* yield[] better performance. Depends on your use case, just like it says in the link. Not that that is a reason to compile java to c.
dmckee
@dmckee true enough, added weasel worlds :)
Adrian
"Why do that?". One possible reason could be that GCC, and other C compilers, target more platforms and architectures than any JIT, and probably more than the union of all JITs in existence. That said, if your target doesn't have a suitable JIT-enhanced JVM, that might be because it's too feeble for any practical Java code, and the Java->C->native route won't actually work either.
Steve Jessop
If your platform doesn't support Java, you're probably better off writing it in C or C++ than relying on a Java-to-native compiler. It'll run faster and be easier to work with. Also, I've heard of **no case** where a Java-to-native compiler beats Hotspot in anything but startup time. I don't think you need the weasel words.
BobMcGee
@bobmcgee also never heard of that. In any case, the weasel words cover the case of equals speed, don't they? :)
Adrian
Except the native-compiled Java is *slower*, rather than equal... :P
BobMcGee
"you're probably better off writing it in C or C++ than relying on a Java-to-native compiler" - sure, but the questioner is asking how to compile Java bytecode (not Java source). Re-writing Java bytecode by hand in C doesn't sound much fun to me.
Steve Jessop
I may stand corrected about performance... but the differences usually aren't that huge, anyway, barring startup times. As for rewriting: Java and C++ aren't *that* different, and the C++ result has more room for hand optimizations, assembly, etc. If you're that focused on speed, you should do it the right way rather than relying on a java-to-native AOT compiler.
BobMcGee
A: 

AFAIK, there is no such product but you have two options:

  • Implement your own byte-code to C transpiler. Byte-code is pretty simple, this isn't too hard.

  • If you just want a native binary (i.e. when you don't need the C source code), then give GCJ a try.

Note: If you're doing this for performance reasons, then you're going to be disappointed. Java is generally as fast as C/C++. Moreover, improvements to the VM will make all Java code faster but not your native binary. Compiling the code will just give you a little better startup time.

Aaron Digulla
I believe this is one of the modes for GCJ, although it is normally compiled from source to bytecode or source to native. I agree about the poor performance though.
BobMcGee
+3  A: 

GCJ has this capability, but it hasn't got great support for Java features past 1.4, and Swing support is likely to be troublesome. In practice though, the HotSpot JIT compiler beats all the ahead-of-time compilers for Java. See benchmarks from Excelsior JET. To clarify: GCJ converts java source/bytecode to natively compiled code

Toba will convert (old) Java bytecode to C source. However, it hasn't been updated since Java 1.1. It may be helpful to partially facilitate the porting, but it just can't handle all the complex libraries Java has.

BobMcGee
A: 

There used to be a product called TowerJ, which was essentially a "via C" static compiler for Java, but it is long gone.

I was told that Sun Labs has created something like this as part of the Sun SPOT project, but I am not sure if it is public.

@BobMcGee: In the benchmarks you refer to, GCJ indeed loses, but Excelsior JET (which is a 32-bit AOT compiler) beats the 32-bit HotSpot on all three test systems, so I am not sure what was your point.

But, after all, there are lies, damn lies, and benchmarks. :)

Dmitry Leskov
Oh, damn. I could have sworn Excelsior JET was just doing a bytecode optimizer and proprietary JIT VM for that test. This is what you get for not reading carefully enough.
BobMcGee
@BobMcGee: No problem. :) By the way, many customers buy Excelsior JET to protect their apps against Java decompilers; they do not care about performance as long as it is about the same as on HotSpot.
Dmitry Leskov
A: 

Not really an answer to my own question, but how does Oracle do it?

http://download.oracle.com/docs/cd/B28359%5F01/java.111/b31225/chone.htm#BABCIHGA

Rudiger
+1  A: 

I could suggest a tool called JCGO (ivmaisoft.com/jcgo/) which is a Java source to C translator. If you need to convert bytecode then you can decompile the class files by some tool (e.g., JadRetro+Jad) and pass the source files to JCGO. The tool translates all the classes of your java program at once and produces C files (one .c and .h for each class), which could, further, be compiled (by third-party tools) into highly-optimized native code for the target platform. Java generics is not supported yet. AWT/Swing and SWT are supported.

ivmai
I'll take a look; I'm glad to see a recent product for this.
Rudiger