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: 10db24,12f4d07c572005e3 X-Google-Attributes: gid10db24,public X-Google-Thread: ff6c8,12f4d07c572005e3 X-Google-Attributes: gidff6c8,public X-Google-Thread: f43e6,12f4d07c572005e3 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,12f4d07c572005e3 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,12f4d07c572005e3 X-Google-Attributes: gid1108a1,public From: jsa@organon.com (Jon S Anthony) Subject: Re: Java Risks (Was: Ada News Brief - 96-05-24 Date: 1996/05/31 Message-ID: #1/1 X-Deja-AN: 157781887 sender: news@organon.com (news) references: <4o56db$p66@ns1.sw-eng.falls-church.va.us> organization: Organon Motives, Inc. newsgroups: comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu Date: 1996-05-31T00:00:00+00:00 List-Id: In article Richard Riehle writes: > > Although there are many Java interpreters and Ada compilers, neither > > the Java language nor the Ada language impose a particular model of > > program execution (compiler, interpreter, distribution, etc.) > > I think you may have identified a key difference in the opening > lines of the preceding paragraph. Compiled source code is usually > optimized, and passed through other processes (linkers, binders, etc.) > which makes applications a bit more difficult to unravel back to their > original source code. Ada adds an additional layer in the form of an > RTE which varies from one compiler publisher to another. Sorry, this just plain does not make any sense. All languages add an RTE, including (and in some sense, especially) Java. What do you think the JVM is??? > Interpreted code is relatively easy to reverse-engineer. Consequently, > it is harder to protect proprietary algorithms. Really? Presumably this is relative to machine code, but it is just plain not true. If for no other reason than one implementation's "interpreted" code could become another's "machine" code. This actually happened with P-code and there has even been some talk about it with respect to J-code. 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. > > Saying that one language has a greater risk in disclosing intellectual > > property is just as misleading than saying that one language is more > > efficient than another. These are properties of the programming and > > execution environment, not of the language itself. I don't see why > > choosing Ada or Java should make a difference here. > > 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. He's right. In this respect there is absolutely no difference. I have Ada code that ports without changing a single character between VMS, UNI*, and Win/NT. With no "preprocessor" crap either. The same code. That's pretty damn portable. I could also just use AdaMagic and get the exact same portability you mention via J-code/JVM as Java. Really, Richard, you are completely in the weeds here. > 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. Yes, I think we understand that is your point, it's just that it is completely wrong. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com