|
How Jazillian Translates C++ To Java Code
Jazillian takes the source files
that you provide and applies a series of transformation rules
to translate various C constructs and patterns into their Java
equivalents, generating “natural” code. For more information,
see How Jazillian Translates Legacy Code to Java Code . Because C++
is roughly a superset of the C language, when translating C++ code to Java
code, Jazillian applies all the same rules that it applies when translating
C code to Java code. Therefore, the discussion on the
How Jazillian Translates C To Java page also applies
to C++.
C++, like the Java language, supports object oriented programming.
Jazillian translates each C++ class to a Java class.
C++ structs that have methods within them also become Java classes.
C++ class declarations (typically within .h files) are intelligently combined with
class definitions (typically in .cpp files). The class hierarchy is preserved.
While we won't go into details here, we can outline generally how some of the
major C++ features map to Java language features. C++ templates become Java
generics. C++ operator overloading is replaced with "normal" Java methods.
C++ namespaces are replaced by Java packages.
Calls to standard library classes are mapped to Java library equivalents.
Next, we'll give an overview of how Jazillian handles a few of the
major C++ features that do not map directly to Java equivalents.
Multiple Inheritance
C++ allows a class to have more than one superclass, but the Java language
does not allow this. Very often, all but one of the superclasses can be
translated into interfaces, and Java does allow a class to implement multiple
interfaces. Jazillian has a configuration file that allows us to specify which
classes should become interfaces rather than classes. In cases where
multiple inheritance is still unresolved after using this configuration file,
Jazillian simply produces a warning.
Destructors
One of the benefits of the Java language is that it automatically performs
memory management. There usually is no need to free up memory when objects
are no longer used, as the JVM will do this automatically. However, there are
cases where resources may need to be freed (such a closing a file) when an object
is no longer needed. C++ destructors accomplish this, and there is no Java equivalent.
The Java programmer must explicitly write code to free up resources, and be sure
to invoke that code at just the right places.
In order to ensure that the translated Java application works just like this original
C++ version, Jazillian translates all destructors into Java methods, and attempts to
call the destructor method at all the right places. This requires sophisticated
understanding of the flow of control of the original C++ code, and it's not possible
for it to always perfect.
As always, Jazillian does all the things a person would do:
if a constructor is simply freeing up memory, the destructor is just removed along with
all calls to it. Inside an class's destructor, calls to destructors for any fields are
added as appropriate.
Automatic Constructor Calls
In C++, you may have a method call where the argument types do not quite match
the parameter types of the method. For example, we may have this call:
f(1, "hello");
...while the function declaration actually looks like this:
void f(MyNumber n, string s) { ...
The call is passing arguments of type "int" and "char *", while the function actually
takes parameters of type "MyNumber" and "string". The C++ compiler will "see" this mismatch
and look around for constructors to make them match up. It will see that the MyNumber class
has a constructor that takes an "int" argument, and the string class takes a "char *" argument,
and automatically "wrap" the passed arguments in constructor calls.
Jazillian does the exact same thing, changing the function call to this:
f(new MyNumber(1)l, new string("hello"));
|
Home
The Jazillian Solution
