Re: JVM as UNCOL, was ANDF/TDF

Greg C <gmc444@yahoo.com> wrote:
> "Joachim Durchholz" <joachim_d@gmx.de> wrote:
> > 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.


Multiple inheritance is actually just a minor problem here. Eiffel's
MI can be mapped 1:1 to Java's interfaces; the compiler just need to
generate the appropriate wrapper classes. The downside is that things
might have different names on the Java side than they used to have on
the Eiffel side, which can be confusing and requires tool support - so
there *is* a problem here, and I think it can become annoying.


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


That's true but actually just a minor point.


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


Eiffel programs can't be fully typechecked unless you have all classes
available. (A consequence of an unlucky design decision that cannot be
easily reversed today.)


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


Yes, there are ways around every single problem that I mentioned.
However, every work-around requires some contortions: interoperating
with Java code becomes a bit more difficult, translation of class and
function names may become a little more indirect, etc. etc.
The final result is that the specific advantages of the JVM (run-time
class loading, introspection, etc. etc.) may be difficult or impossible
to utilitze from Eiffel.


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


No. SmallEiffel needs a recompilation, and it doesn't support run-time
checking on a per-subroutine basis as the other compilers do.
The other compilers generally don't require a recompilation; it's just a
few flags that are switched on and off during start-up.


> > [Problems of Eiffel on MSIL]
> 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.)


I don't know either. But if more languages have simlar problems, this
just means that MSIL is even less of an UNCOL than I had thought of.


Regards,
Joachim

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