The Edison Design Group JFE reads and parses source code written in the Java™ programming language.
Language Supported: The JFE accepts the full Java language as defined by "The
Java Language Specification," Java SE 7 Edition, by Gosling, Joy, Steele, Bracha, and Buckley.
This is the language usually described as the "Java 7" version, which includes inner
classes, generics, enumerations, annotations, variable argument lists, boxing/unboxing, Unicode source code, binary literals, underscores in numeric literals, string values in switch statements, type inference in generic instance creation, the
Translation to Intermediate Language: The JFE reads source code in the Java programming language, does full syntax and semantic analysis of the source code, and produces a representation of the source program in the form of a high-level, tree- structured intermediate language. The intermediate language attempts to accurately represent the meaning of the source program in Java terms; implicit operations (e.g., conversions) are made explicit in the IL tree, but constructs are not otherwise added, removed, reordered, or flattened. The intermediate language is not machine dependent (e.g., it does not specify registers or dictate the layout of stack frames). It does not use byte codes.
Error Detection and Diagnosis: The JFE does complete error detection and issues detailed diagnostics. Diagnostics always display the source line with a caret indicating the exact position of the error. The level of diagnostic output can be controlled in various ways.
Use of the JFE as a Compiler: The JFE can be used as part of a compiler for the Java language. One can write a back end that translates the intermediate language to object code, or a converter to the intermediate language used by an existing optimizer/code generator.
There is, however, an alternative that can reduce development cost and time. The JFE includes a component (called "C IL Generation") that translates the Java intermediate language (JIL) to the C intermediate language (CIL) used by EDG's C++/C front end. The CIL can then be fed into a code generator (the CIL is a lower-level description than the JIL and thus is easier to generate code for) or, using the C-generating back end provided with the JFE, output as C source code. This code can then be compiled to object code using any C compiler.
The JFE can also translate JIL to class files. In that mode, it can be used as a drop-in replacement for a "traditional" Java compiler: it translates source code to class files.
Use of the JFE for Source Analysis: The JFE can be used for source analysis, e.g., as part of a CASE (Computer-Aided Software Engineering) tool. The intermediate language contains detailed information about the declarations and statements of the source program, including file/line/column source positions.
In addition, the front end maintains additional, even more detailed information during the parse process, which may be of interest in source analysis tools. For example, the parse information contains lists of all references to a given name and the associated source positions, which allows generation of cross-reference or browsing information.
Automatically Finding all Necessary Code: The front end starts from a set of one or more source files specified on the command line. Those files will include references to classes, variables, and methods defined elsewhere, either in language libraries (e.g., java.lang) or in other user-written code. The JFE will automatically find and process as much of that environmental code as is required, given command-line options or environment variables that indicate where the code is to be found. In the source-analysis mode, the JFE can read class files, either individually or collected in JAR or ZIP files. In any mode, the JFE can read source files.
JIL Files: The JFE can write files containing the Java intermediate language (JIL). Such files -- functionally similar to class files, but in the JFE's own format -- contain full information about the declarations and executable code of a given class. When the JFE searches for the code for a given class, it will check for and use an up-to-date JIL file instead of reading the corresponding source file. This can speed compilation, especially for code like library code that is seldom modified. JIL files can also be read from JAR or ZIP files.
Fast Compilation: The JFE is written in C. It is not an interpreted Java program. It compiles Java source code very quickly (often 10 times faster than the Oracle javac), and it reads JIL files even more quickly.
Libraries: The JFE is a complete implementation of the Java language, but it does not include any libraries. For source analysis, or when generating class files, one can use whatever libraries are otherwise available in the environment, e.g., those provided with the Oracle Java distribution. The libraries can be used in source form or class file/archive form. For other applications, one must have libraries in source form.
The Dinkumware Connection: EDG has collaborated with Dinkumware, Ltd. to produce a full Java language product composed of EDG's JFE combined with Dinkumware's Jcore library.
The Jcore library implements the core libraries required by the Java language (java.lang, java.util, and java.io), plus java.math, and all runtime support required to run Java programs (e.g., garbage collection, thread support, exception handling). These are, however, not generic; they match the pre-java 5 language.
Java Execution Without a JVM: The product is designed to allow native execution of Java code without a Java Virtual Machine. The user source code is compiled to object code (perhaps by generating C code and compiling that) and the object code is linked into an executable, much as would be done for a program in a language like C or C++. The executable includes library code that handles all the features usually handled by a JVM.
Faster Execution: The generated native code is potentially much faster than interpreted code, particularly for code that is computationally intensive.
Smaller Footprint: Because no JVM is needed in memory, and only those parts of the library that are referenced need to be linked in, a native executable can potentially run in environments (e.g., embedded processors) where the Java language might otherwise be too big.
Code Optimization and Configurability: The code generation process can be configured for the application. Certain checks that involve an overhead can be turned off if not needed. For example:
The interface with the garbage collector can be adjusted as well. The default generated code maintains data structures that allow the garbage collector to find all active pointers. If one wanted to use a conservative garbage collector instead, one could turn off the garbage-collector-support code.
As an option, the code generation process can be told to generate a single file containing the entire program (all user-written classes and all referenced library classes). This allows certain program-wide optimizations, e.g., optimization of virtual function tables.
Portability: The JFE is highly portable, and can be made to run on any host computer that has an ANSI/ISO C compiler. Host and target configuration issues are separated, so the JFE can be run as a cross-compiler. The configuration of the JFE for the target machine is fairly minimal. The Jcore library must, of course, be ported to the target environment (e.g., the thread support must be made to work with the native thread support), but it too has been designed with portability in mind.
Independent (Non-Sun/Oracle) Implementation: The JFE and Jcore are independent implementations of the Java programming language based on the published specifications. They are not based on the Sun implementations, and do not include any source code or documentation from Sun Microsystems, Inc. or Oracle Corporation. No license is required from Sun or Oracle.