Re: JVM as UNCOL, was ANDF/TDF

Jürgen Kahrs <kahrs@iSenseIt.de> wrote:
> Jürgen Kahrs wrote:
>
> > [I wouldn't call JVM an UNCOL since it has only a single source
> > language and isn't intended to express all the warts of every
> > possible target.
>
> I dont like Java and also dont want to do too much nitpicking, but
> take a look at this:
>
> Programming Languages for the Java Virtual Machine
> http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html


You can port everything to the JVM - it's Turing-complete after all.
The question is how well other things than executing code work, and
it's here where the problems start.


I know a bit about the Eiffel ports. Eiffel compilation requires
full-system analysis, which is impossible to combine with the JVM's
"load and inspect classes as they are needed" approach. (More a
problem of Eiffel than anything else.) In other words, you can't
extend a running Eiffel program with classes that weren't known at
compile time, but the JVM expects exactly this. Or you force it into
loading classes, which means you'll get type cast exceptions where a
true Eiffel compiler wouldn't throw an exception.


Then Eiffel wants a very special flavor of exceptions; they don't
easily map to the JVM exeption handling. Eiffel strings are different
from Java strings. etc. etc.


Eiffel has a very elaborate support for run-time checking. It is
intended to be switched on and off on a by-method basis; the JVM
doesn't support this, so you have to recompile if you want a different
checking configuration.


I'm pretty sure that there are more issues; these are just those that
I know of.


Of course, given enough resources (in terms of programmer time), all
these problems can be overcome. But the JVM is not a real UNCOL
platform.


The Eiffel# effort for MSIL suffers from similar problems. AFAIK the
company that's porting Eiffel to the .net environment had serious
problems with getting everything to run (though this may be attributed
to other factors, like lack of documentation, ambitiousness of the
project, and some non-technical issues). Well, their public
announcements sound as if they're confident that all problems can be
overcome, but I don't hold my breath - I'm pretty sure that they'll
have to pay a hefty price in terms of engineering trade-offs.


Regards,
Joachim
--
[This is exactly where UNCOLs always fail, every language needs to
support some wacky detail, and the wacky details overwhelm the common
part. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.