> A agree with you that JVM is "the" strong point of Java, so
> when do we make our AVM then ?  (Ada Virtual Machines) huh?

It already exists.

Here at R.R. Software, we designed a virtual machine (called JCode, for
"Janus/Ada code") back in 1984/5. We had three uses in mind:

1) To be the intermediate form in a traditional compiler. That meant it had
to support optimizations.

2) To be directly interpreted. That meant it had to be complete. JCode
includes a exception handling, tasking, and even 'Image.

3) To be the intermediate form in a hybrid compiler, which would essentially
create the interpretable program, then optimize and generate code for it at
link-time. (The most important optimizations there being inlining and
partial evaluation).

(3) was essentially killed because the machines (PSs) at the time weren't
powerful enough to handle the whole program at once for any meaningful
program.

(2) was killed by marketing. At the time, our primary competition for
educators was Ada-Ed. Ada-Ed was an interpreter, and marketing emphasized
that Janus/Ada was a true native compiler. Having an introductory version
that wasn't a true native compiler would have made it harder to sell (at
least, that was the theory).

We did use JCode for (1), and it has evolved to include many Ada 95 features
(such as protected types). Building an interpreter for it would be
relatively easy, but it seems pointless. The primary advantage of the JVM is
its ubiquity; a JCode interpreter would be available only on machines for
which it was created (probably a set similar to that which support Ada
compilers).

If I was designing JCode today, I would do a variety of things differently
(mainly eliminating implicit conversions, which as much trouble at this
level as they are in a programming language). And I suppose it would have to
have some form of dynamic loading (JCode doesn't have things that would
conflict with uses (1) and (2), of course).

                        Randy Brukardt.