1. Introduction
2. Command line syntax
2.1. Options
2.2. Type names
2.3. Command file
3. Selecting Java members
4. Mapping of Java to Eiffel
4.1. Names
4.1.1. Identifiers
4.1.2. Name scoping
4.2. Types
4.2.1. Primitive types
4.2.2. Rerefence types
4.2.2.1. Classes
4.2.2.1.1. Strings
4.2.2.1.2. Other classes
4.2.2.2. Interfaces
4.2.2.3. Arrays
4.3. Type members
4.3.1. Fields
4.3.2. Methods
4.3.3. Constructors
4.4. Exceptions
4.5. Threads
The utility may be used as a bridge between Java and Eiffel code to access Java objects from the programs written in Eiffel. While Visual Eiffel JNI library provides the same possibilities, using Java to Eiffel converter significantly simplifies the integration by hiding the low-level implementation details implied by the JNI library. Java objects look much closer to their original form and may be used in Eiffel in a natural way.
Command line syntax:
j2e [options] [java_types] [@command_file]
where:
options | options for j2e |
---|---|
java_types | one or more fully qualified names of Java types |
command_file | the name of the file, containing options and/or Java class names |
Options for j2e should begin with '-' or '/' character.
The following options are supported by j2e:
-nologo | do not display j2e logo |
---|---|
-out:<filename> | set the name of the output file to the given one (the default value is "j2e_stub.e ") |
-split | generate one Eiffel source text per one Java class (by default the output goes to a single text file) |
Java classes and interfaces should be listed in a dot notation which conforms to Java
naming conventions. All class and interface names should appear in a fully qualified form,
including a package name if any (e.g., java.lang.Class
, java.lang.reflect.Member
).
The command file may be used to specify options and to list Java classes. This is a text file every line of which contains exactly one option or a class name starting from the first position.
Java types (classes and interfaces) and their members are selected for use in Eiffel accordingly to the following rules:
Example.
Assuming the following class structure
class Point { int x, y; void move(int dx, int dy) {...} } class Rect { Point upper_left, lower_right; void move(int dx, int dy) {...} }
the converter will produce Eiffel classes with the following interfaces:
class interface Rect feature move (dx: INTEGER; dy: INTEGER) end interface -- class Rect
when only Rect
class is specified and
class interface Point feature x: INTEGER y: INTEGER move (dx: INTEGER; dy: INTEGER) end interface -- class Point class interface Rect feature upper_left: Point lower_right: Point move (dx: INTEGER; dy: INTEGER) end interface -- class Rect
when both Point
and Rect
classes are specified. Members that
are inherited in the classes Point
and Rect
are not shown for
simplicity.
All Java types are mapped into the corresponding Eiffel classes. The standard Eiffel classes are used to represent Java types when it is appropriate. A single class inheritance and a multiple interface inheritance of Java is supported by the multiple class inheritance of Eiffel.
The generated Eiffel code incorporates features to provide safe manipulations with Java objects relying on the Eiffel garbage collector. No special management is required to free Java objects.
The resulting Eiffel code is not a subject for use in the inheritance structures other than it incorporates accordingly to the Java structure. In other words, these classes should be used only as suppliers.
The Eiffel differs from Java in the following respects:
Only valid Eiffel identifiers are allowed to appear in Java. Usage of letter-case different identifiers is not allowed.
The converter does not check for collisions caused by
Eiffel does not support the notion of packages. The names of the reference types are fully qualified Java type names where every dot was replaced with an underscore.
E.g., Java class java.lang.Class
will be named java_lang_Class
in Eiffel.
Primitive types are directly supported by the converter and should not be specified for processing.
The following mapping is used for primitive Java types:
Java type | Eiffel class |
---|---|
boolean | BOOLEAN |
byte | CHARACTER |
short | INTEGER |
int | INTEGER |
long | JAVA_LONG |
char | JAVA_CHAR |
float | JAVA_FLOAT |
double | DOUBLE |
Mappings labeled with "-" are not currently supported.
All these Eiffel classes are expanded and have the same size as the corresponding Java types.
The reference types except strings and arrays are a subject for the specification for the converter. Strings and arrays are directly supported by the converter.
Class java.lang.String
is mapped into the class STRING. The value is
stored in the UTF-8 format accordingly to the Java specification.
Note, that the Eiffel site manipulates with a copy of the Java string, so any changes in this string would not be reflected for the Java site.
Next release of the converter may map java.lang.String
into JAVA_STRING
class which will be provide all the features.
Every specified Java class is mapped into the corresponding Eiffel class using naming conventions described above.
Every specified Java interface is mapped into the corresponding Eiffel class using naming conventions described above.
Java arrays are mapped into properly instantiated ARRAY classes. Only one-dimension arrays of the reference type can be used.
Note, that Eiffel site manipulates with a copy of the Java array, so any changes in this array would not be reflected for the Java site.
All type members are mapped into the features with the same name except the cases noted in the previous sections.
The Java fields are mapped into the Eiffel functions. An additional procedure prefixed by "set_" is generated for every Java variable. It is used to change the variable value.
The current version does not generate "set_" procedures.
Non-overloaded methods results are mapped into the corresponding features without any special changes in their names. Every overloaded method gets a postfix which lists parameter type names prepended with an underscore, except the STRING parameter, when "_str" is used instead.
At the moment overloaded methods are not supported.
Example.
The Java class
class Point { move(int dx, int dy) { ... } move(Point other) { ... } }
would result in the Eiffel class with the following interface
class interface graph_Point feature move_int_int (dx: INTEGER; dy: INTEGER) move_graph_Point (other: graph_Point) end interface -- class graph_Point
where "graph" is the name of the package containing the class Point.
A non-overloaded constructor results in the creation procedure with the same name as the name of the containing class. Overloaded constructors result in the creation procedures with the names starting with the name of the containing class and followed by the parameter type names, prepended with an underscore, except the STRING parameter, when "_str" is used instead.
Example.
The Java class
class Point { Point() { ... } Point(int x, int y) { ... } Point(Point other) { ... } }
would result in the Eiffel class with the following interface
class interface package_Point creation package_Point, package_Point_int_int, package_Point_Point feature { NONE } -- Creation package_Point package_Point_int_int (x: INTEGER; y: INTEGER) package_Point_package_Point (other: package_Point) end interface -- class package_Point
where "package" is the name of the package containing the class Point.
Exceptions raised in Java are not propagated to the Eiffel code.
The Java site may create as many treads it requires, but the Eiffel site should work only with one Java thread. Synchronized Java methods are not supported properly.