The most general multiarray type signature is:
In standard Java, arrays are not considered to be objects, but they effectively have a class--a class representing an array type. We prefer to avoid making the statement ``multiarrays have a class''. If we made this statement it would probably commit us to either:
Option B has its own problems. Presumably the associated class types should capture the rather complicated system of array types we have described for HPJava. Because there is an infinite number of multiarray types, the associated classes would certainly have to be created on demand by the translator. Does the translator have to create class files for these automatically generated classes? If so how should these files be managed? Distributed array types have a rather complex, multiple-inheritance-like lattice of subtype relations, illustrated in Figure A.1. This kind of type-lattice can be reproduced in Java by using interface types. But then, when we generate a new array class, we have to make sure all the interfaces it implements directly and indirectly are also defined.
To avoid these problems an HPJava multiarray is not considered to have any class. Multiarray types are treated as a new kind of reference type in HPJava, separate from standard Java reference types.
The fact that a multiarray is not a member of any Java class
has a real impact on how a multiarray can be used.
For example, a multiarray cannot be an element of an
ordinary Java array, nor can a multiarray reference be stored
in a standard library class like Vector, which expects an Object. In practice this is not such a drastic limitation as it sounds,
because the programmer can always create wrapper classes for particular
types of multiarray. For example suppose we need a ``stack''
of two-dimensional multiarrays of floating point numbers. We can
set this up along these lines: