From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f3f9104dada53163 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: An interesting quote on Java and C++ Date: 1997/09/12 Message-ID: #1/1 X-Deja-AN: 271935534 References: <5ujjvq$t4s@drn.zippo.com> <34160feb.36797713@news.mindspring.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-09-12T00:00:00+00:00 List-Id: In article , Robert Dewar 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