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: fac41,99bdf14f233488c4 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,12f4d07c572005e3 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,99bdf14f233488c4 X-Google-Attributes: gid109fba,public From: Richard Riehle Subject: Re: Java Risks (should be Java mis-speak) Date: 1996/06/02 Message-ID: X-Deja-AN: 158102036 references: <4o56db$p66@ns1.sw-eng.falls-church.va.us> <31ae412e.505845747@snews.zippo.com> to: The Right Reverend Colin James III content-type: TEXT/PLAIN; charset=US-ASCII organization: National University, San Diego mime-version: 1.0 newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.eiffel Date: 1996-06-02T00:00:00+00:00 List-Id: On Fri, 31 May 1996, The Right Reverend Colin James III wrote: Colin, I appreciate your taking the time to post a reply to my comments. > Richard Riehle posted with deletions: > > Apparently Riehle does not understand that bytecode produced by Java is > exactly what FORTH produces. (Remember that the bootstrap in Sun computers > is ROM code written in FORTH, and hence a FORTH system.) I did not know that you were one of those few practitioners who is experienced with Forth. My memory of Forth must be a little ragged since I do not recall that Forth produces code indentical to Java bytecode. However, I do have a hazy recall that Forth code is relatively easy to re-engineer. Also, if my memory is not playing tricks on me, Forth has fewer facilities for encapsulation than Java. OTOH, Forth does allow one to create abstractions from primitives, create new abstractions from existing abstractions, and so on. It is a powerful language for designing on the notion of succesive levels of abstraction. It is new information for me that the bootstrap in the Sun Rom was written in Forth, but it does not surprise me. Forth is particularly useful for that kind of thing. Thanks for that littl tidbit of information. > Therefore for Ada or Eiffel to produce bytecode is silly. If I implied that Ada or Eiffel should produce bytecode, I apologize. That was never my intention. However, there are already Ada products, and, I believe, Eiffel products in development, that will generate either Java code or some intermediate Java representation that will ultimately be translated into bytecode. I am not qualified to comment on the virtue of this approach, but some of our more emminent colleagues seem to see some benefit in it. Too soon to tell, really, whether this is appropriate or not. > If Riehle means that Ada or Eiffel produce Java code, which in turn is > compiled by Java compilers into bytecode, then that is possible but may be > a wasted abstraction because Ada or Eiffel would be better suited to > producing wrappers and interfaces to Java rather than being expensive code > generators for Java, as Riehle apparently advocates. As noted in my repsonse to your previous paragraph, this is exactly what some software publishers are doing. Make sense? I have no idea. But it is interesting that such products are emerging in the marketplace. It also enhances the long-term credibility of Java. > Riehle's general observations below make it clear that he does not > understand Java at all. I defer to your superior knowledge on this subject. My study of Java has been limited to reading two books and about a dozen articles. So far, I have not written any Java applets. It is my intention to do so in the not too distant future, but you are clearly ahead of me on this. > | Interpreted code is relatively easy to reverse-engineer. Consequently, > | it is harder to protect proprietary algorithms. If, indeed, Java is interpreted rather than compiled, I stand by this. OTOH, if bytecode is somehow better protected than I suggest, I am willing to acknowledge the error of my ways. I have been wrong many times before. I expect to be wrong many times in the future. This is one of those times I would rather be wrong. However, my comments regarding the requirement for the protection of intellectual property in published software, in the paragraphs that followed this, highlight concerns shared by most software publshers who have an interest in protecting their investment. As a publisher of software, I know you also have some concerns about this issue. The overriding question, regarding Java, is, if we develop proprietary software in this language, license that software through some commercial distribution channel, and hope to remain competitive, will our more resourceful competitors find us easy targets? Robert Dewar, in a separate communication on this topic, makes a compelling argument in favor of Java's safety. I think it is still an open question. Once again, Colin, thanks for your observations on this issue. Richard Riehle