comp.lang.ada
 help / color / mirror / Atom feed
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: An interesting quote on Java and C++
Date: 1997/09/12
Date: 1997-09-12T00:00:00+00:00	[thread overview]
Message-ID: <EGEq96.2H6@world.std.com> (raw)
In-Reply-To: dewar.873989964@merv


In article <dewar.873989964@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
><<>...  But it's clear from the Java language documents that two
>>goals of Java are (1) avoid security flaws, and (2) portability
>>at the cost of efficiency.
>>
>>Ada meets neither of those goals.>>
>
>be careful not to compare the reality of Ada with the Sun (and other) hype
>on Java. In the current state of things, Java is nowhere NEAR as portable
>as Ada, it is almost the normal case that an applet of any complexity
>written on one platform is likely not to work on another platform.

OK, OK, everybody's beating me up about Java's supposed goals.  I must
admit I was wrong as far as practise goes.  I was talking about the
language *definitions*: Ada's language definition allows all kinds of
non-portable stuff, whereas Java's language definition allows extremely
little implementation-definedness.

But I admit that this is theory, and not practise.  In practise,
compiler bugs, and deliberate language modifications by compiler
writers, can both damage portability.  (I'd say that happens for both
languages, by the way.)

My claim is just that if all implementations of Ada and Java obeyed
their language definitions, then Java would be more portable than Ada.
And I admit that you can counter with, "But that's irrelevant --
implementations of Java do *not* obey the Java standard."  (And there
are interesting non-technical (marketting) reasons for compiler writers
to modify the Java language!)  I also admit that "the Java standard" is
perhaps a bogus term, since the standard changes rather often.

>As a further indication of the gap between reality and hype, I am corresponding
>with a student in Europe who is looking at portability of IEEE floating-point
>between compilers for the same language. He wrote to me that "Ada is doing
>very well, things seem to be extremly portable between one implementation
>and another ........" but  "Java seems a complete mess, I can't get any
>of my IEEE fpt examples to port between Java implementations."

Interesting.

>And this from a language that supposedly requires IEEE (although this
>requirement is the subject of controversy in the ISO standards committee).

Also interesting.

How about integers?  The Java standard nails down integers pretty
precisely (exactly 8, 16, 32, and 64-bit arithmetic, with wraparound on
overflow).  Does anybody know whether Java implementations obey this?
Are there any Java implementations on machines where the word size would
make this inconvenient?

>Of course you can say, well that's because the implementations are decrepit,
>just wait and see, but then we are back to talking about implementatins
>and not languages.

I'd say that's backwards.  I argued that the Java *language* is
portable, whereas you and others argue (correctly) that, in practise,
Java *implementations* cause nonportability.

I certainly don't believe the "just wait and see" part.  For
money-making reasons, Java implementations will diverge, I would guess!

>As for security, this is a matter of implementation, not the language.

I disagree.  A correct implementation of Ada allows dangling pointers,
whereas a correct implementation of Java does not.

>Indeed, there are all kinds of Java restrictions that must be adhered
>to for secure applet delivery that are not enforced by Java itself.
>And of coruse if you use an Ada->JVM system, then by definition this
>has the same level of security, since the security is implemented at
>the JVM level, not at the Java level.

No, the Java *language* disallows dangling pointers -- not the JVM.
Yes, I agree you can write Ada implementations that have the same level
of security.

By the way, one case in which the Ada standard nails things down more
precisely than the Java standard is in the area of tasking
(e.g. scheduling of tasks).  But both languages fail to nail this down
completely -- because it's not feasible.

- Bob




  reply	other threads:[~1997-09-12  0:00 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-09-03  0:00 An interesting quote on Java and C++ Nasser
     [not found] ` <01bcb881$915526a0$d7000064@sim01.amst.co.at>
1997-09-03  0:00   ` Robert Munck
1997-09-05  0:00     ` Joachim Schroeer
1997-09-06  0:00     ` Robert Dewar
1997-09-24  0:00     ` Shmuel (Seymour J.) Metz
1997-09-08  0:00   ` Robert A Duff
1997-09-09  0:00     ` Robert Munck
1997-09-10  0:00       ` Robert A Duff
1997-09-10  0:00         ` Stephen Leake
1997-09-11  0:00           ` Roy Grimm
1997-09-12  0:00             ` Robert A Duff
1997-09-10  0:00         ` Robert Munck
1997-09-11  0:00           ` Robert Dewar
1997-09-12  0:00             ` Robert A Duff [this message]
1997-09-18  0:00               ` Shmuel (Seymour J.) Metz
1997-09-19  0:00                 ` Robert A Duff
1997-09-20  0:00                   ` Robert Dewar
1997-09-20  0:00                 ` Robert Dewar
1997-10-03  0:00                   ` Robert I. Eachus
1997-09-20  0:00                 ` Robert Dewar
1997-09-22  0:00                   ` Robert A Duff
1997-09-12  0:00             ` Jon S Anthony
1997-09-12  0:00         ` Jon S Anthony
1997-09-11  0:00       ` Robert Dewar
1997-09-12  0:00         ` Jon S Anthony
1997-09-12  0:00           ` Robert A Duff
1997-09-03  0:00 ` Samuel Mize
  -- strict thread matches above, loose matches on Subject: below --
1997-09-25  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1997-09-25  0:00 ` Shmuel (Seymour J.) Metz
1997-09-26  0:00   ` Tucker Taft
1997-10-07  0:00   ` Robert I. Eachus
1997-11-19  0:00     ` Shmuel (Seymour J.) Metz
1997-10-08  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1997-10-09  0:00 ` Shmuel (Seymour J.) Metz
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox