Re: JVM as UNCOL, was ANDF/TDF

"Joachim Durchholz" <joachim_d@gmx.de> wrote in message news:01-10-016...
> 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.


I don't think this is really true. If a class follows a specific
interface and doesn't muddle things with multiple inheritance, its
quite possible to dynamically load it in a program that expects
conformance to the same interface. You'll lose some of the
optimizations that are possible with full compilation, for example if
the class uses generics it may be restricted to references only. If
the client program and the class being loaded agreed to a conforming
interface, why would a type exception be thrown in what would
otherwise be correct code?


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


True, but I believe at least two Eiffel compilers support JVM; issues
such as exceptions and incompatible data formats must have been worked
out somehow.


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


Isn't this true whether or not Eiffel is targeting a JVM?


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


Check me if I'm wrong, but the .Net version of Eiffel# has been
shipping for three months now. Yes they faced some serious challenges
getting everything to run, but I don't know that their problems were
any different than those faced by other compiler vendors (including
MSoft.)

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