Re: Java Risks (should be Java mis-speak)

[Richard Riehle <rriehle@nunic.nu.edu>]

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 <rriehle@nunic.nu.edu> 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