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: 10db24,12f4d07c572005e3 X-Google-Attributes: gid10db24,public X-Google-Thread: 1108a1,12f4d07c572005e3 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,12f4d07c572005e3 X-Google-Attributes: gid103376,public X-Google-Thread: ff6c8,12f4d07c572005e3 X-Google-Attributes: gidff6c8,public X-Google-Thread: f43e6,12f4d07c572005e3 X-Google-Attributes: gidf43e6,public From: Richard Riehle Subject: Re: Java Risks (Was: Ada News Brief - 96-05-24 Date: 1996/06/02 Message-ID: X-Deja-AN: 158098324 references: <4o56db$p66@ns1.sw-eng.falls-church.va.us> to: Jon S Anthony content-type: TEXT/PLAIN; charset=US-ASCII organization: National University, San Diego mime-version: 1.0 newsgroups: comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu Date: 1996-06-02T00:00:00+00:00 List-Id: I realize that I am out on a limb with this thread. But it may be worth exploring just a little further. On 31 May 1996, Jon S Anthony wrote: > 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??? 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. 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. In certain Pacific-Rim countries, software piracy is a way-of-life; at least a way of doing business. Anyone who believes that this is going to change is dreaming, or needs to change brands of peanut butter. Any model for the sale and distribution of commercial software that fails to acknowledged this fact, will have to endure its consequences. Additionally, the more a competitor can learn about the internal structure of your application, the easier it will be to make incremental improvements and being them to market quickly. If this were only a domestic U.S. issue, we would simply engage the services of the hordes of underemployed lawyers. > > 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. I agree with the latter sentence. However, bytecode is interpreted as if it were a kind of universal machine code. All one needs is a bytecode intepreter. Historically, machine code programs have been translated or emulated so they will run on new hardware. This is usually not as efficient as running in native mode. If one writes a native mode bytecode interpreter, I would guess that there would be a somewhat more satisfactory outcome. > This > 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. > 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? > > > 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. This analogy does not hold. It is close to an apples and oranges thing. > > One of Java's premier virtues is is portability. > 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. Still not the same thing. You cannot port your executable Ada program from VMS to Win/NT. Once I publish an application and license it to you for your Win/NT, I defy you to execute it, without considerable trouble, on a VMS machine. 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 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? 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. Richard Riehle