From: Ben Brosgol <[log in to unmask]>
> "Vanilla" Java clearly has a number of problems with respect to determinstic
> real-time performance [...] Nevertheless the language's very high
> degree of portability and safety (more than Ada's in > fact) have
> sparked interest from the real-time community.
Java and Ada offer rather different approaches to "portability", and
it's possible that the Java flavor is more closely aligned to the needs
of real-time/high-integrity system designers.
First, the Ada case:
1) In the original DoD Ada effort, the portability benefits were mainly
- the language being well-defined
- the definition being codified as a standard
The language definition itself also built in a certain amount of
target independence, but perhaps more importantly, these
surrounding provisions secured portability across compilers.
In those days, compiler dependencies apparently were a bigger
problem than they are today, when other languages have "caught
up", at least to some degree, in terms of standardization.
Compiler dependencies are still a problem. Right now I'm writing
some C++ code and I keep running into things that the Sun
compiler doesn't grok. One advantage Ada still has is the high
degree of stability of its standards: one revision in the 16
years so far since the original standard. Other languages have
"cycle times" that are much shorter. For C++, the reasons for
this should be fairly obvious to anyone familiar with the
language. For Java, the reasons are more complex.
2) The choices of things Ada allows to be implementation dependent
reveals a bias toward compiler targetability. It was important
that it be possible to make an Ada compiler for anything from a
Cray to a Nintendo Game Boy. It wouldn't have been acceptable
for the language to be defined in such a way that broad classes
of target architectures would turn out to be unsuitable for Ada.
This value of the Ada design has sometimes been mistakenly spoken
of as "portability". From the implementor's point of view,
there is an appearance of "portability" because it is easier to
port the compiler to novel architectures. It's really the
compiler that is made more "portable", not application code.
This ease of targetability actually competes against
"deterministic" cross-target portability at the application
level. With consolidation of architecture features, the trend
toward COTS in defense, etc., there are fewer truly weird
architectures around, so ease of targetability begins to have
less value. (The x86 is pretty weird all right, but ubiquity has
to count for something :-)
In Java, very little if anything is left to the implementation. One
reason is that the language is designed for just one target: the JVM.
So things like the size of types and the floating point model are
pegged. Native code Java compilers are a relative innovation, and there
you're really emulating the JVM in native code. Another factor is the
philosophy that what you see at the source text level is very close to
the run time model, which might account for such things as order of
evaluation being specified. I'm trying to think of things that Ada
leaves up to the implementation but are pegged in Java... what else is
there? Parameter passing is by copy for primitive-type objects, and N/A
for class objects due to Java's by-reference semantics.
In Ada, it's very clear what things you are and are not allowed to
depend on. That's good as far as it goes, but the real trouble is that
you might be depending on something without knowing it. The advantage
of having everything nailed down is in the abatement of the Law of
Unintended Consequences, and this is certainly a good thing for
So, what are the issues involved in putting Ada on equal footing with
Java in the areas where Java has the lead in portability?
- Standard sized types. They are already there, of course -- in
package Interfaces. Unfortunately, they're kind of "buried" there
in keeping with the philosophy that sized integer types are of
value for interfacing to hardware or other languages. Regardless
of where sized types are declared, code rule checkers can be used
to check that integer types from Standard are not used.
- Could there be a standardized "profile" of certain
implementation-specifics (e.g. some Annex M stuff + ?)
- Standard storage pools?
- How would all this relate to Annex H?
Senior Software Engineer
Development Solutions Business Unit
UNIX Suites Group
Aloha, OR, USA