From:  Ben Brosgol <[log in to unmask]>
)

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

Very true.  This is precisely my answer to "Ada isn't portable because
you don't even know how big an Integer is" (for instance).  Portability
doesn't mean identical behavior, it means that you can deploy under a
different implementation of the language system without changes to the
source text and the requirements of the system continue to be met.  If I
say (to continue the example)

    X: Integer;

instead of using an implementation-independent integer type, this is an
implicit statement that "I do not care about the range of values of this
object"; that is, it has no bearing on the system requirements.  You
should be able to say that, because there are a lot of times when you
really don't care (so for instance, the fact that you run out of
integers sooner on some platform is no more of a "portability" concern
than when you run out of memory or disk space! :-)


> Indeed,
> that is the purpose of the various documentation requirements in Annex H,

...and Annex M...

> so
> that the programmer will know which choices the implementation has made for
> those points that are not specified in the RM.

Right.  Do you have any general opinions on which portability approach
(Ada's or Java's) is a better fit to the needs of high-integrity
programmers?  Is it even possible to generalize, or can you offer some
heuristics?  If it turns out that the Java portability model addresses
perceived needs rather than (or even at the expense of) real needs, then
the task (speaking from an Ada advocate stance) for gaining mindshare
over Java in the high-integrity arena is to convince developers that the
Java approach is a wild goose chase, or insufficient, too costly or
whatever.  On the other hand if this is not the case, then there might
be some ways to "close the gap" without trying to fully adopt all the
elements of the Java approach (which was not my idea anyway...)


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

Good point.

To stray from the topic for a bit -- the low level of abstraction of
String does seem to cause some problems, beginning in Ada95.


--

Mark Lundquist
Senior Software Engineer
Rational Software
Development Solutions Business Unit
UNIX Suites Group
Aloha, OR, USA