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 16:48:14 -0400
text/plain (67 lines)
Tucker Taft wrote:

> Ben Brosgol wrote:
>> 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
>> analog to Ada's package elaboration is the initialization phase of
>> class loading.  When a class is initialized is defined by the language
>> rules.
>This is a bit misleading.  In fact, Java "solves" the elaboration order
>problem by ignoring it.  Access before elaboration is permitted in Java.
>If you read the JVM definition carefully, what you will find is that
>it does *not* require that class initialization be *completed* before
>you reference a field or call a method of a class.  It simply requires
>that class initialization be *started*.  So if two classes depend on
>each other cyclically, and reference each other during their elaboration,
>one is certain to not be fully initialized when referenced by the other.

I am aware that this is how Java addresses the cyclic elaboration problem,
but I believe that such examples are pathological rather than normal, and as
I understand the rules the effect is still deterministic.  Indeed that was
the point of my list, to answer Mark Lundquist's question about areas where
Ada left the effect implementation dependent but where Java specified the

>> 3) Java uses IEEE 754 for floating point semantics.
>Java *specifies* IEEE 754.  Most implementations just use whatever
>the hardware provides.  Ada implementations also use whatever the
>hardware provides, so this difference is really a bit of a red herring.

So be it.  I was going by the language spec, not current implementation

>> 5) Java does not contain "11.6" surprises; an optimizer cannot apply a
>> transformation that would result in an exception being thrown elsewhere
>> what the language semantics requires.
>I speculate that once native-code compilation becomes more common, many of
>the "guarantees" provided by the Java specification will be ignored
>by optimizers.

It will be interesting to see whether the Java Compatibility Kit tests such

>> ... 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.
>Given that the original discussion of real-time, the fact that Java's
>real-time guarantees are much weaker than Ada's is certainly more
>significant than whether order of evaluation is specified.  In general
>it is only a buggy program that would depend on order of evaluation for
>reaching the correct answer, whereas it is quite common for a real-time
>system to have strong dependence on the scheduling guarantees of the
>language to achieve correct timing.

The ongoing real-time Java efforts are trying to address such issues.

Ben Brosgol
[log in to unmask]