Table of Contents
The translator is designed to be easily integrated in the normal Java development process. Modifications must be made at three steps in the process.
-
When writing the source files, select and annotate some fields and methods (or list them in a text file).
-
After the Java source files have been compiled to class files (and possibly put into a jar file), run the translator.
-
Test the transformed application; a virtual coprocessor is provided so that automated tests can be run without having to plug a hardware coprocessor.
Given the nature of the transformations performed by the translator, several constraints must be obeyed to ensure that the transformed code is consistent. For example:
-
if a class A has at least one secured field, all the classes derived directly or indirectly from
Amust be modified -
if a method
mis call secured, all the sites from whichmcould be called must be modified
Therefore, when transforming an application, the translator must be able to check whether it is allowed to modify a given class or not. Since a Java application can execute the bytecode from a collection of jar files, directories, or other sources using specialized class loaders and since the translator processes only a single jar or directory at a time, the definition of that input jar or directory is not sufficient. To address this problem, the translator defines three domains:
- application
-
the classes of the application.
- library
-
the classes in thirdparty libraries used by the application.
- system
-
the classes from the Java runtime (found by default in the boot class path and the extension directories).
The translator accepts three options to specify three associated class paths: the application path, the library path, and the system path. When searching for a class, the translator searches the application path first, then the library path, and finally the system path. If the class is found, its domain corresponds to the path in which it was found. This search order is different from the one used by the Java virtual machine. When an application is executed, the boot class path and the extension directories are searched first. However, if an application redefines a class of the Java runtime, the boot class path must be modified for the new definition to be picked up and searching the application path first at transformation time is appropriate.
Warning
To verify the constraints mentioned above, the translator must
examine the extends and implements
relationships between classes and interfaces in order to build the
class and interface hierarchies and the virtual method tables. To
shorten this process by limiting it to application classes, the
translator assumes that system and library classes do not depend on
application classes. If this assumption is not verified in practice,
incorrect code might be generated.
The translator up to version 1.0.5 was limited to the definition
of a single path, the class path (option -c for
the translator or pclasspath for the Ant task).
The use of the class path is now deprecated. The option can still be
used and now sets the library path but the use of the application,
library, and system paths is preferred.
In the present version, the translator actually only cares about application classes vs. non application classes. However, defining the system and library paths correctly is advised, should future versions of the translator use them.