Ada Programming/Platform/VM/Java
Ada and the JVM
editThe Ada→J-Code compilers translate Ada programs directly to Java bytecode for the Virtual Machine. Both Ada programmers and Java programmers can use each other's classes almost seamlessly, including inheritance. Ada adds desirable language features like a strong base type system and full generics, Java VMs add garbage collection and a rich set of libraries.
“Almost every Ada 95 feature has a very direct mapping using J-code, and almost every capability of J-code is readily represented in some Ada 95 construct.”—Taft, 1996
There are (at least) two compilers that support this: AppletMagic and JGNAT. The following example assumes AppletMagic. Changes required to make them work with JGNAT should be minimal. Some are explained in due course.
Ada programs for JVMs (see for example Programming:J2ME) appear to be surprisingly smooth. Unlike creating, and sometimes using, a binding to some library, using Ada→J-code compilers will make binding issues disappear.
Naming Conventions
editAppletMagic and JGNAT use naming conventions for deciding how to distribute compiled code across Java class files. When a (tagged) type together with its surrounding package should be mapped to one Java class file, AppletMagic requires the type name to have a known suffix, and otherwise to be the same as the package name:
package
Foois
type
Foo_Objis
tagged
... ...end
Foo;
Similarly, JGNAT has some conventions that effectively turn type names into
key words. These names tend to be short, and general, here is Typ:
package
Foois
type
Typis
tagged
... ...end
Foo;
Java Uses References, So Does Ada, Then
editThe mapping of Java's primitive types to corresponding Ada types is straightforward. (The semantics of integer types differ between the languages when the values approach a subtype's limits. JVM integers can jump from positive to negative when adding in excess of the maximum integer, Ada programs should not permit this. The compiler docs will explain to what extent Ada semantics will be preserved on the JVM.)
For reference types—everything is allocated in the heap—there is another convention.
package
Foois
type
Foo_Objis
tagged
null
record
;type
Foo_Ptris
access
all
Foo_Obj'Class;procedure
Op(x:access
Foo_Obj);end
Foo;
(JGNAT sources use Ref instead of Foo_Ptr.)
The classwide pointers can be used just like Java references.
Notice that primitive operations can have access
parameters. This is a natural choice when interfacing to Java.
When Ada programmers wish to use Java objects in their programs, they will see the Java classes as normal packages, and the objects following the conventions outlined above. The compilers offer tools for creating Ada packages from Java .class files. Given the Java class Foo, the Ada package will be as show below.
public class Foo
{
public void op() {};
}
with
java.lang;use
java.lang;package
Foois
-- pragma Preelaborate; -- uncomment where possibletype
Foo_Objis
new
Objectwith
null
record
;type
Foo_Ptris
access
all
Foo_Obj'Class;function
new_Foo(this : Foo_Ptr :=null
)return
Foo_Ptr;procedure
op(this :access
Foo_Obj);pragma
Import (Java, op);pragma
Import (Java_Constructor, new_Foo);end
Foo;
- new_Foo
- This is a constructor function corresponding to the default constructor of the Java type. (Usually you won't be concerned with default constructors.) There is a special convention identifier for constructors, Java_Constructor.
pragma
Import- As both the constructor and the op method are defined in the Java class, they will be imported just like when importing C, or Fortran functions, using convention identifiers Java_Constructor, and Java, respectively.
Constructors
editTo be continued.
Further reading
edit- S. Tucker Taft (1996). Programming the Internet in Ada 95
- Cyrille Comar, Gary Dismukes, and Franco Gasperoni (1997). Targeting GNAT to the Java Virtual Machine