🚀 go-pugleaf

In article <4dogst$2jd@fnnews.fnal.gov>, waller@adcon.fnal.gov (Alex
Waller) wrote:

> Greetings all!
> 
>  I have seen that recently there have been posts about possible Java
> usage ala Oberon and, on a seperate thread, questions about OMI.
> Although the threads are unrelated at the current time, I found it
> interesting that interest in both topics seem to coincide in time.
>  J. Marais has a document in his Spirit of Oberon release having to
> do with self contained documents, including any necessary code to
> drive specialized Gadgets within the document. Also M. Franz for
> several years has been telling us about OMI (Object Module
> Interchange??) where a compact description of an application is
> totally platform independant and compiled to native code on the
> target machine *ON THE FLY*! In fact the latest release of Oberon
> System 3 for the Mac has been distributed in these OMI "slim
> binaries"!
>  The folks at ETHZ have many fantastic ideas but yet as the topic of
> a previous thread stated "whither OMI?". I also add "whither self
> contained documents?". The many good ideas coming from the halls of
> ETHZ echo hollow as everyone whispers "Java" and it becomes the
> defacto "standard". I realize that those in the know know that Java
> actually does have its roots in Oberon but it sure would be nice if
> Java can have a worthy competitor from the very people that gave Java
> some of its "spirit".
> 
>   Anyway, seeing simultaneous posts on OMI and Java just made me
> think of the connection between the two topics. The latest versions
> of System 3 have a very nice seamless integration bewteen opening
> Oberon docs and Web docs. Shall OMI (perhaps ala self contained
> documents??) be added within the next System 3 release?? ...Just a
> thought while I'm musing on the topic.
> 
>     -Alex-
> 
> ---------------------------------------------------------------
>                                |
>   Alex M. Waller               |  Internet address:
>   FermiLab                     |     waller@adcon.fnal.gov
>   M.S. 360                     |
>   P.O. Box 500                 |
>   Batavia, Il 60510            |
>                                |
> ---------------------------------------------------------------

I think I was the one who started the (brief) thread entitled "Whither
OMI?".  You may be surprised to find out that this question occurred to me
after reading the Java Virtual Machine Specification.

Quoting from its Preface:  "This document describes ... the Java Virtual
Machine and its instruction set."

"The Java Virtual Machine is an imaginary machine that is implemented by
emulating it in software on a real machine.  Code for the Java Virtual
Machine is stored in .class files, each of which contains the code for at
most one public class."

"Simple and efficient emulations of the Java Virtual Machine are possible
because the machine's format is compact and efficient bytecodes. 
Implementations whose native code speed approximates that of compiled C
are also possible, by translating the bytecodes to machine code, although
Sun has not released such implementations at this time."

The current Jave emulators are said to be 10 to 20 times slower than native C.

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.

I also wonder whether, for a given program, the size of OMI-based class
files would be smaller that those produced by Sun's current approach.  If
so, this would be beneficial when such "applet" files are loaded from a
network by a WWW browser.

I wonder whether anyone at Sun was aware of OMI when they came up with Java?