Limitations

What JFE and Jcore Won't Do: The JFE is not suitable for translation of Java source code into maintainable C or C++ code. (Someone could develop a product to do that, using our product, but it's not a capability we provide.) The generated C code is not pretty; it's being used only as a way to get object code generated by a C compiler. It contains runtime routine calls, generated variables with cryptic names, and long convoluted lines making extensive use of the "," and "?" operators.

The JFE and Jcore will not, in all cases, allow one to take an existing Java application and run it as a native application. Jcore does not provide the full set of Java libraries, and the set it does provide is not genericized (it's a pre-java 5 version). If an application uses libraries other than those provided by Jcore, one would need to have those libraries in Java source code form, and even then they would be usable only if they have no native methods, because the runtime environment for JFE/Jcore is incompatible with the JNI environment.

The code generated by JFE will also not, in general, interoperate well with C and C++ libraries, or with C or C++ code not written specifically for the JFE/Jcore environment, because of differences in the runtime environment (e.g., calling conventions and data representations). So one could not, for example, translate an algorithm in Java into a piece of C code and expect to drop that C code into an existing C or C++ application.

The JFE cannot at present generate object code that will execute alongside byte code in a JVM environment. (It can, of course, generate byte code to be used in that way.) In other words, it can't be used as a sort of ahead-of-time version of a JIT compiler.