Java Risks (Was: Ada News Brief - 96-05-24

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

Andreas,

Thanks for you commentary on my observations regarding the potential risks
associated with Java for proprietary software products.

On 29 May 1996, Andreas Zeller wrote:

> I don't get the point in here.  If I have some compiled code, where's
> the difference in whether the source code was written in Java or Ada?
> If I have some bytecode for the Java virtual machine, couldn't it have
> been produced by some Ada compiler as well?

  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.

> 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.

  Interpreted code is relatively easy to reverse-engineer. Consequently,
  it is harder to protect proprietary algorithms.

> 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.

  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.

  Richard Riehle