Javatrans: Java byte-code to C++ translator

Chris Greenhalgh, 2006-03-29; last updated 2006-05-05


  1. Introduction
  2. Building_and_testing
  3. Usage
    1. Output_files
    2. Compiling_output
  4. Known_Issues
  5. Change_Log
See also:

1. Introduction

Javatrans is a general-purpose Java to C++ translator, that has been developed to allow the (Java-based) EQUIP2 system to be automatically ported to C++, and in particular to C++ for Windows, Linux and the Symbian OS used on many mobile phones (partial).

Javatrans itself is written in Java, the main javatrans application being javatrans.GenerateCPP.

I have not attempted to translate any of the built-in Java packages or classes, since Javatrans cannot do anything to translate native methods and also because these constitutes reverse engineering and may be in breach of license(s) for Java. However I have provided partial from scratch C++ implementations of the core classes and methods used (so far) by the code which I have translated. This includes quite a few java.lang classes and a small number of and java.util classes (see ../src.cpp/).

Javatrans is used to translate groups of related classes into a C++ DLL, library or application.

2. Building and testing

2.1. Getting Javatrans

At present Javatrans is in CVS accessible as:

This is likely to move, e.g. to sourceforge, before too long. Before then the copyright boilerplates will be added, probably (so called) modified BSD.

Building Javatrans

There is an Apache ANT build.xml file for Javatrans. Current build targets include:

The C++ support library and generated code is currently built using batch files (windows) or symbian projects. The top-level targets/ directory has target platform specific subdirectories with build scripts:


So a basic test for Windows would be (starting in the top-level javatrans directory):
> ant jar
> ant test
[now with a visual studio shell...]
> cd targets\win32
> buildlib-win32.bat
> buildexample-win32.bat

If successful this will compile all of the generated and hand-crafted support files as described above, and leave a single executable, dist/win32/example.exe, and supporting dll dist/win32/javasupport.dll, which can be used more or less equivalently to the java command (both must be in the shell path).


Equivalently for Unix (you might need to set execute permissions on the batch files):

> ant jar
> ant test
> cd targets\unix
If successful this will compile all of the generated and hand-crafted support files as described above, and leave a single executable, dist/unix/example, and supporting (currently static) library dist/unix/libjavasupport.a, which can be used more or less equivalently to the java command (both must be in the shell path).

Testing Javatrans

Running generated/example.exe with no arguments will list the available classes that can be run with it; for example, for the examples the output would be:

> dist/win32/example.exe [or dist/unix/example]
Usage: <classname> ...
Known classes:

For example:

> dist/win32/example.exe example.Print
Hello world!
0 = 0

3. Usage

Command-line usage of the translator is:

java javatrans.GenerateCPP [-m(ain)] [-d <dependencies-directory>] [-l <library-name>]
[-L <dependent-library-name>]* <output-directory> <input-classfile1> ...

Where the options are:

Because of the supporting files generated (see below) it is currently best to convert all class files in one invocation of javatrans.

If the input class files were compiling with debugging information then this will be used to determine the names of method arguments and local variables, otherwise default names will be used (e.g. "arg1", ...).

3.1. Output files

This application reads the specified java .class files (i.e. Java bytecode files) and generates a corresponding set of C++ header (.h) and body (.cpp) files. The C++ file name is (usually - see below) the same as the name of the generated C++ class, which is derived from the package-qualified Java class name, except that:

For example, the java input class example.PrintTest will be converted to the C++ class example_PrintTest, declared in the C++ header file example_PrintTest.h and defined in the C++ body/implementation file example_PrintTest.cpp. The exception referred to above is that Symbian and/or the tool chain for ARM development has a relatively limited maximum path name, so currently filenames longer than 40 characters are shortened to 40 characters. The current heuristic used is to preserve the last word of the filename - usually the class name - and to truncate the package name, inserting an integer to avoid clashes with other converted files (during the same conversion run).

Javatrans will only translate specifically identified class files. However, where these class files include references to other classes or their methods or fields it will optionally generate stub C++ headers and body files for which implenentations must be provided if the translated code is to compile; this option is enabled by the '-d <directory>' option.

It also generates some additional files containing common functions/fields for all processed files:

3.2. Compiling output

Output files should be compiled in the usual way for the target OS. The only non-standard requirement is that the target OS must be defined by setting a compiler definition, currently one of:
In addition, javatrans presumes that (like Java) unicode will be supported rather than a single-byte character set; on windows and symbian this requires the definition of:
Source-code and headers for a subset of java support classes (from java.lang, and java.util) are included in the src.cpp/ and src.cpp/include directories. These can be compiled to a library for each supported platform as described above. Compiling generated files will depend on at least a subset of these header files, and will need to be linked with the compiled library/DLL.

4. Known Issues

Change Log