🚀 go-pugleaf

Ron Kreuzenstein wrote:
> 

> 
> After looking at the format of the .class files and the bytecodes of the
> JVM instruction set, it struck me that OMI (aka slim binaries, SDE-encoded
> files) might be an even more efficient way of conveying code in a
> machine-independent manner (machine independence is one of Java's goals).
> 
> Let's say that, if Sun had done this, there would be OMI-based ".class"
> files.  Using this approach, the code in such files would be translated to
> the host machine's native instruction set on-the-fly as the file was being
> loaded (from disk or, even better, from a network).  There would be no
> need for an emulator -- ever!  This surely seems to be a better choice
> than Sun's bytecodes.

Well, I fully agree and have to admit I had exactly the same thoughts when I
read the Java manual. But I'm afraid we wouldn't see the  current success
of Java with lots of different implementations on different operating systems. 
The bytecode approach has one big advantage: you can take the virtual 
machine reference manual and hack in an interpreter very quickly; this is
enough to get things going, and I'm sure native code translators for the 
bytecode will appear soon. For SDE-encoded files you would have to rewrite 
the back-end for each architecture plus the run-time environment.

I guess it's the same reason why the simple HTTP protocol plus HTML is more 
successful than e.g. the Hyper-G work done at Graz. I remember that my first WWW
server was a 20 line perl program...

Of course, a SDE-like approach would be much more flexible: the java vm has been
defined for the Java language and misses some things needed for other languages.
A front-end for a SDE encoded file would kind of 'create' the virtual machine it
needs in its dictionary. 
But you are not forced to use Java: use an existing
server which returns a 'Content-Type: application/omi', then modify one of the
browsers for which the source is available to understand this MIME type, then
write back-ends for all popular architectures, then convince Netscape that is
is something worth to support in their browser as well, etc. pp....

-- 
Reiner Hauser
CERN, Division CN
Email: Reiner.Hauser@cern.ch  Tel.:    +41 22 767 7759 
CERN - CN, CH-1211 Geneva 23, Switzerland