🚀 go-pugleaf

<< I think the point you missed is that the Java Virtual machine is really
at the level of the instruction set of a microprocessor.
Compiling to the Java VM is really like compiling to machine code:
a processor has in general no notion of objects, records and so on...
The compiler has to implement that.

Porting to the Java VM would be just like porting to a new microprocessor
(maybe a little easier: there is a garbage collected heap). >>

The Java virtual machine is not just like any other microprocessor. It's
instruction set does include the notion of objects. At the same time, it
has no instructions for taking addresses of areas within heap blocks or on
the stack. In fact, it has no concept of addresses other than the
addresses of heap blocks. You could, of course, muck with these by
treating them as integers but the Java loader is supposed to detect that
and reject such code and the runtime is also supposed to check object
references in instructions that use them. The Java VM is not a general
purpose machine. It is a machine designed for executing Java's semantics
and it is exactly in those areas where Oberon's semantics conflict with
Java's that the port becomes complicated.

Mark