Java-Eiffel bridge (j2e) v1.1 beta

Contents

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

1. Introduction

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.

2. Command line syntax

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.

2.1. Options

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)

2.2. Type names

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).

2.3. Command file

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.

3. Selecting Java members

Java types (classes and interfaces) and their members are selected for use in Eiffel accordingly to the following rules:

  1. The type name is explicitly specified.
  2. Signatures of type members (constructors, methods, fields) contain only supported primitive types, String class, specified types or an array of them.
  3. No other Java types and members are available.

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.

4. Mapping of Java to Eiffel

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.

4.1. Names

4.1.1. Identifiers

The Eiffel differs from Java in the following respects:

  1. Only ASCII alphanumeric characters and underscore are allowed while Java uses alphanumeric UNICODE characters, including $ and characters beyond ASCII codes.
  2. Letters are treated as being case insensetive while Java makes a distinction in letter case.

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

4.1.2. Name scoping

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.

4.2. Types

4.2.1. Primitive types

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.

4.2.2. Rerefence 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.

4.2.2.1. Classes
4.2.2.1.1. Strings

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.

4.2.2.1.2. Other classes

Every specified Java class is mapped into the corresponding Eiffel class using naming conventions described above.

4.2.2.2. Interfaces

Every specified Java interface is mapped into the corresponding Eiffel class using naming conventions described above.

4.2.2.3. Arrays

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.

4.3. Type members

All type members are mapped into the features with the same name except the cases noted in the previous sections.

4.3.1. Fields

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.

4.3.2. Methods

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.

4.3.3. Constructors

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.

4.4. Exceptions

Exceptions raised in Java are not propagated to the Eiffel code.

4.5. Threads

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.


Copyright © Object Tools -- info@object-tools.com
Last updated: 2005/02/02 11:51:35