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