Re: Warning: Flame Bait

[Tom Robinson <robinson@gdesystems.com>]

Robert Dewar wrote:
> 
> Bob Duff says
> 
> "I'm not a big fan of Java, but I don't see how anyone can say that Ada
> is more portable than Java.  The Java language definition nails down all
> kinds of things that are "implementation defined" or "unspecified" in
> Ada."
> 
> Portability is MUCH more than just a question of the language definition, it
> is about being able to practically port a wide range of applications from
> one machine to another over a wide range of machines. Java does not yet
> begin to meet either of these criteria. We have to wait to see whether
> it can in the future, but right now, Java is quite limited in its reasonable
> application domain in practice, and I don't see too many Java compilers for
> the 1750A, let alone the 8051 :-)

I know virtually nothing about the Java language or the JVM.  But in
the early 80's I worked for a company called Softech Microsystems, which
had acquired the rights to a system called UCSD Pascal.  Everything I
have read about the JVM leads me to believe that JVM has its roots in
the old "p-Machine", which was the virtual machine that UCSD Pascal
was compiled for.

UCSD Pascal was very portable.  We had it on a wide variety of 
platforms and processors Z80, 8086, 68k, TI9900, HP-87, etc. etc.
etc.  You could compile on one platform and run the  object code
on another platform (sound familiar?).  Towards the end we had even
defined a local area network system to which allowed one system to
run the software resident on another systems disk.

There were some questionable business decisions that killed the
product (one was the pricing which allowed Borland Pascal to
become the dominant Pascal product).  But also there were some basic
technology problems:

  o Speed - No matter what you do, an interpreted system will never
            execute code as a direct object code execution system.  This
            removes the system from that class of applications that
            requires speed.  The p-System attempted to address this
            by introducing native code generators.  However, even the
            code generated by these tools required some of the VM
            codes to remain.  And of course, once you go native you
            are no longer portable.

  o Architecture Limitations -

            The p-System was limited by the very thing that made it
            incredibly portable, the basic architecture of the 
            p-Machine.  It was defined as a 16 bit architecture.  When
            the first set of 32 bit machines hit the market, the 
            virtual machine definition kept programs from taking
            advantage of the underlying hardware.  We were addressing
            with a 32 bit definition, but we did not give it enough
            priority.

These two issues became critical with the emergence of the IBM PC
and the standard PC architecture.  All of a sudden portability was
much less important than performance on the IBM PC.  The fact that
the p-System could make limited use of memory beyond 64k was critical.

Anyway my two cents.  It would be interesting for someone who knows both
the Java technology and something about what happened to UCSD Pascal
to compare the two, both from a technology and business standpoint. 
Since
Java is targeting a different application set the things that caused
UCSD Pascal to dissappear might be irrelevant.  It could also be that
the limitations of using an interpreted Virtual Machine are also 
irrelavant to Java.  But it does seem like it would make an interesting
study (if one has not already been done).

Tom Robinson