TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Ben Brosgol <[log in to unmask]>
Reply To:
Ben Brosgol <[log in to unmask]>
Fri, 29 Oct 1999 13:06:27 -0400
text/plain (92 lines)
Mark Lundquist wrote:

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

Not necessarily.

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

Here are a few others:
1) In Java there are no uninitialized variables.  There is a default
initialization for fields and array elements, and the program is illegal if
the compiler cannot convince itself that a local variable is assigned before
it is referenced.
2) "Elaboration order" is more precisely defined in Java than in Ada.  In
Ada one often has to use elaboration pragmas to avoid
access-before-elaboration exceptions or uninitialized variables.  The Java
analog to Ada's package elaboration is the initialization phase of dynamic
class loading.  When a class is initialized is defined by the language
3) Java uses IEEE 754 for floating point semantics.
4) Java does not supply unchecked deallocation or unchecked conversion
5) Java does not contain "11.6" surprises; an optimizer cannot apply a code
transformation that would result in an exception being thrown elsewhere than
what the language semantics requires.

Of course the higher degree of implementation independence does not come for
free; there will often be a cost (perhaps significant) in run-time

Also, several Java features do have an implementation-dependent effect:
* The effect of priorities on thread scheduling is not completely specified.
Java threads  are typically mapped to native threads on an underlying OS or
RTOS, so the effect of priorities will be whatever the native thread model
* Native methods can do anything
* The effect of the Finalize() method is fuzzy, since it is called when an
object is garbage collected but there is no way to know when (if at all)
this will occur
* The absence of the "volatile" modifier on fields of a shared object can
cause some surprises (this is the same situation as in Ada)

>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
>high-integrity systems.
>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.

It's all but impossible to avoid the use of Standard types; for example,
Integer is the index type for String (a bad decision made in Ada 83).

>    - 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?

It's unclear if trying to retrofit Ada into Java's portability model is
possible or worthwhile.  For High Integrity systems one must know what a
given program will do when it runs on a given platform, but one does not
need to have a completely portable program to achieve this effect.  Indeed,
that is the purpose of the various documentation requirements in Annex H, so
that the programmer will know which choices the implementation has made for
those points that are not specified in the RM.


[log in to unmask]