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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,99bdf14f233488c4,start X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,99bdf14f233488c4,start X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,12f4d07c572005e3 X-Google-Attributes: gid103376,public From: cjames@cec-services.com (The Right Reverend Colin James III) Subject: Re: Java Risks (should be Java mis-speak) Date: 1996/05/31 Message-ID: <31ae412e.505845747@snews.zippo.com>#1/1 X-Deja-AN: 157759810 references: <4o56db$p66@ns1.sw-eng.falls-church.va.us> organization: CEC Services, LLC reply-to: cjames@cec-services.com newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.eiffel Date: 1996-05-31T00:00:00+00:00 List-Id: [groups trimmed to relevant *.lang. ones] Richard Riehle posted with deletions: | The Java code could certainly be produced by an Ada compiler or | an Eiffel compiler, etc. No argument with that. In fact, Intermetrics | has a product which does this, and ISE is working on an Eiffel compiler | that will do this. 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.) Therefore for Ada or Eiffel to produce bytecode is silly. 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. Riehle's general observations below make it clear that he does not understand Java at all. | Interpreted code is relatively easy to reverse-engineer. Consequently, | it is harder to protect proprietary algorithms. | : | One of Java's premier virtues is is portability. Another is its ease | of use. Neither of those features should be weakened. However, both | features make it easier to reverse-engineer applications written in | Java. Let me emphasize that I do not see this as a bad thing. | | On the other hand, for publishers of commercial software products, there | is greater security of the intellectual property for compiled code than | for interpreted code. | | In many ways, Java is BASIC for the next century. In time, Java will be | offerred as a compiled language, clever people will add new features to | make it more secure, and others will tack on features to make it more | incomprehensible. Already, feature-creep is beginnning to manifest | itself as self-enlightened software gurus conclude that Java would be | even better if it just had this one or two more features. | | I like Java. I hope it can survive long enough in its present form long | enough to resist the wide-spread temptation to "make it better." Let it | mature. Let its users mature. Then, later (much later) revisit the | language design. One of the problems with C++ is that it is evolving | beyond Stroustop's original vision into a collection of features in | which seem to be on a collsion course with each other. Somehow, the | ISO Ada 95 standard managed to improve on the ISO Ada 87 standard | without mangling the language. | | Anyway, my main point is that Java's very benefits for interactive | software are also its drawbacks for secure software. It is a simple | trade-off. But it needs to be recognized. |