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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,12f4d07c572005e3 X-Google-Attributes: gid103376,public X-Google-Thread: 10db24,12f4d07c572005e3 X-Google-Attributes: gid10db24,public X-Google-Thread: 1108a1,12f4d07c572005e3 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,12f4d07c572005e3 X-Google-Attributes: gidf43e6,public X-Google-Thread: ff6c8,12f4d07c572005e3 X-Google-Attributes: gidff6c8,public From: jsa@organon.com (Jon S Anthony) Subject: Re: Java Risks (Was: Ada News Brief - 96-05-24 Date: 1996/06/03 Message-ID: X-Deja-AN: 158310136 sender: news@organon.com (news) organization: Organon Motives, Inc. newsgroups: comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu Date: 1996-06-03T00:00:00+00:00 List-Id: In article Richard Riehle writes: Richard, I sent you an extended version of this in email, but here are a few bits for public consumption... > > All languages add an RTE, > > including (and in some sense, especially) Java. What do you think the JVM > > is??? > > OK. Now, when I distribute an application in bytecode, what is it that > i am providing? If I understand correctly, my bytecode is portable and > can be executed by any platform with a bytecode interpeter. If the > standard for a bytecode interpreter is consistent from one platform > to another, my application is truly portable. No compilation required. This is equally true for any single platform (OS/HW combination, JVM, etc.) > As new platforms, new processors, come on-line, all we need to do is > write a new Java bytecode interpreter to run the existing application. > Sounds good to me. I have no need to buy a license for your new version > the application that you have targeted to the new platform. Yes, but then how do you get the JVM for the new platform? As things are currently going it looks like this will thrown in as a kind of loss leader. Just like Windoze/X is for Intel based machines. Again in this respect there really is no difference. Now for completely new HW, it is true that JVM has an upper hand because it is a lot simpler to build a new JVM (as software thing) than a new piece of HW - of course it prolly has a lot more bugs in it too! :-) > translated or emulated so they will run on new hardware. This is > usually not as efficient as running in native mode. If one writes First, emulation is just another word for interpreted. Second, the efficiency issue depends on several things. For example, there are cases where Alpha boxes running NT can "emulate" x486 Windoze code about as fast and sometimes faster than the real thing. Lastly, J-code is in the same boat. If "emulated" it will always be slower, but if cast in silicon it will be just another HW architecture. > > actually happened with P-code and there has even been some talk about > > it with respect to J-code. > > Yes, I do recall P-Code. Interesting point. Not sure if it applies to > this argument, though. The only reason it does is that it gives a another indication that "interpretation" has nothing to do with any of the issues you raise. None. Is the silicon P-code machine code somehow harder to decode than the interpreted version? Don't see how. > > Again, this just plain makes no sense. > > Now, you _can_ make an argument that the particular "interpreted" > > code, viz. J-code, itself has some interesting aspects where it > > maintains more "source" level type information than some other low > > level architecture (oh, say, a SPARC). But even then, what you're > > claiming is a real stretch. > > So, can I write a bytecode interpreter for a brand X machine without > permission from the author of the Applet? Can't make out what you're asking here: are you asking about a JVM for a new HW? or a new interpreter for a Applet? what applet? If Sun licenses the JVM architecture for peanuts or nothing, then sure you can hack a new JVM for arbitrary new HW. The main point of my quoted comment here is that you can make a claim that the architecture evinced by J-code *is* higher level than your standard RISC HW. To *that* extent you *can* claim that J-code is *easier* to work with when attempting a "decompile". But it would still be a pain. Besides, which actual code are you going to attempt to reconstruct? The Ada? Java? Eiffel? X? What do you have anyway? You're not going to find it much easier getting at algorithms here than from straight machine code. > At the source code level, Ada is emminently portable. No argument. > So is Java. Nor argument. Java goes one step further and makes the > executable portable But the JVM is *not* tied to Java the language. If you really want an example of apples to apple pickers just compare Ada (or Eiffel or Java the language or ...) to the JVM (or J-code). > becuase it can be interpreted by bytecode. > Argument? OK. Now, which proprietary software product is more > secure, the executable created from Ada source code, or the > interpretable bytecode originating in Java? The executable generated from Ada source that runs on the JVM? The standard SPARC executable from Java (I seem to recall that there *is* a native Java compiler available from a house in England, but in any event they are surely coming)? Or how about the available just in time native compilation of J-code to native code? > Jon, thanks for your ideas on this topic. At some point, we will start > to bore the others on this forum, and we can take it private. Meanwhile, > I am still not certain that an interpreted language such as Java is as > low-risk as a compiled language such as Ada, or even Eiffel. The key point is that Java *the language* is no more interpreted (via byte code or what-have-you) than Ada or Eiffel. And the JVM has only a peripheral connection to Java the language. Just as there turned out to be compilers for P-code and the PVM for all sorts of languages, there will be for J-code and the JVM. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com