Ada Programming/Platform/VM/Java


Ada. Time-tested, safe and secure.
Ada. Time-tested, safe and secure.

Ada and the JVM edit

The 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 edit

AppletMagic 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 Foo is

   type Foo_Obj is 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 Foo is

   type Typ is tagged ...

   ...

end Foo;

Java Uses References, So Does Ada, Then edit

The 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 Foo is
  
     type Foo_Obj is tagged null record;
     type Foo_Ptr is 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 Foo is
  
      --  pragma Preelaborate; -- uncomment where possible
      type Foo_Obj is new Object with null record;
      type Foo_Ptr is 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 edit

To be continued.

Further reading edit