TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To:
Ben Brosgol <[log in to unmask]>
Date:
Fri, 29 Oct 1999 15:42:18 -0400
Reply-To:
Tucker Taft <[log in to unmask]>
Subject:
From:
Tucker Taft <[log in to unmask]>
Content-Transfer-Encoding:
7bit
Content-Type:
text/plain; charset=us-ascii
Organization:
AverStar (formerly Intermetrics) Burlington, MA USA
MIME-Version:
1.0
Parts/Attachments:
text/plain (66 lines)
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 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
> 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.

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

> 4) Java does not supply unchecked deallocation or unchecked conversion

Java also provides no direct access to machine-level data, so it
is essentially to write something like Direct_IO in "pure" Java.

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

I speculate that once native-code compilation becomes more common, many of
the "guarantees" provided by the Java specification will be ignored
by optimizers.

> ... 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.  In general, Java's attempt to
achieve completely portable "sequential" semantics seems like the drunk
who searches under the lamppost for his keys because that's where the
light is...  Specifying order of expression evaluation is irrelevant
for most real-time programs.  Guaranteeing that priority inversion
is bounded, e.g., is much more important.


> Regards,
>
> Ben
> [log in to unmask]

--
-Tucker Taft   [log in to unmask]   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

ATOM RSS1 RSS2