John replies:
>>It's a programming language.  You write programs in it :-)
>
>Duh!

Of course, but a lot of people are still confused about what exactly
Java is.  At the core, there is simply a programming language.  But
layered on top of this are the portability of the bytecode/virtual
machine combination, and the incredibly vast set of class libraries
available.

>>Also don't forget that learning to design and write Object
>>Oriented systems is not a skill that's trivial to acquire.
>
>Being a MsVB, MsVC++ programmer in addition to C/iX, COBOL,
>HPBB, etc. that's not a problem.

Perhaps not for you, but a large percentage of MsVB and MsCV++
programmers couldn't OO Design their way out of a wet paper bag.
Using a language that *allows* OO can be different from using a
language that *requires* OO.  You can still write a lousy/non-OO C++
application, even if you are using something like MFC that forces you
to use objects at least some of the time.

The difference between OO and traditional design is that a common
"traditional" technique is to just sit down and start coding.  With OO,
much more of the work is pushed into the up-front design of what
objects you are going to have and how they are going to interoperate.
If you skip this phase you'll usually end up with an unsalvageable mess.
In OO, the design actually *is* part of the implementation as it is
expressed directly in code via the various hierarchies (class, package,
containment, reference, etc.) that you create.

>         Yes, but why would I want to as opposed to GCC. I thought that
> Java was similar to C++ but without the pointers. Is this correct?

No, Java is a completely different language from C++.  There is some
syntactic similarity since Java derives much of its fundamental syntax
from C.  Java is not a derivative of C++.  Also Java *has* pointers,
it's just that they are *safe* pointers, as opposed to C/C++ which
let you point a pointer at any old memory address you want to make up.

As far as why you would want to use Java *on the 3000* today over GCC,
it would either be because you want interoperability with some other
entity (another server or a client) that's also written in Java, or
because you think that Java is a superior programming language/system/
environment.

Today you wouldn't do it because of performance or MPE-specific
functionality.  The truth is that *today* Java will run slower and
can't access as much native MPE functionality as other languages.
The functionality issue will be solved as people start writing the
interfaces that let you get to the underlying MPE functionality.
Anyone could provide this today, using the current version of Java.
HP is working to make Java run as fast as any other language on both
HP-UX and MPE.  They may or may not meet this goal, and they could
very well exceed it.  There is more brain power being spent today on
Java performance than probably all other languages combined.

Java already performs well enough on Win32 PCs to consider it for
serious PC application development.

>         So if I write a program in Java/iX now and 200 people are
> running it at the same time, that's 200 separate compiles and 200
> separate program images, no code sharing. Right?

Yes.  That's correct, and the #1 reason why you probably don't want
to write a Java application that will require 200 instances of the
Java VM to execute.  The JIT compile overhead and "code sharing" are
not really big issues.  It's more the startup overhead and resource
requirements of the VM at the moment.  These should be addressed
adequately some time this year.

>         So maybe by Mpe/iX 6.0 Java will be better?

6.0 will be, I believe, the first release that ships with Java
included as part of FOS on every system.  How old that version of
Java will be after all of HP's manufacturing, packaging, testing,
beta testing, and shipping, and customer installing time I don't
know.  There will probably be improved versions of Java available
between now and the 6.0 customer ship time frame, but you will
probably always have to download from Jazz to get the best
available version.  The Java porting operation inside HP is just
cranking out new ports (as Sun creates new versions) faster than
the MPE release cycle can keep up with.  One possibility is that
once Java is shipping on 6.0, they may be able to release new
versions as patches, which would provide a more official method
of acquiring them than downloading from Jazz.

G.