[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Thoughts on 'reference classes'

From: Mark Wielaard
Subject: RE: Thoughts on 'reference classes'
Date: 01 Mar 2003 19:14:47 +0100


On Wed, 2003-02-26 at 10:14, Jeroen Frijters wrote:
> I'm a VM implementer too and I have a few comments. One general point
> is that the current GNU Classpath version is 0.05, this suggests that
> it isn't mature yet so I think VM implementers should expect that the
> VM interface isn't yet stable. BTW, personally I think that 0.05 is a
> way too low number for the current state of affairs, but maybe I'm
> just reading too much into the number ;-)

Maybe we should just take the TeX approach and just converge to some
non-rational number like e, so we can say that we are now at version
2.7182 :)

> Some random points (all IMHO):
> * I don't mind changes to the Classpath <-> VM interface, if they
> improve the situation. I'd love to hear what other VM implementers
> have to say about this, but I agree with Archie sometimes there is too
> much inertia.

Note that there also just is the Not Enough Time thing... :{

> * The use of native code should be limited. Preferrably to primitive
> operations that cannot be performed from within Java

What do you exactly mean when you say native code here? Do you mean the
use of JNI code? Or just VM specific interface code?. I don't think we
should restrict it to much.

I believe that if something cannot be done in Java, but can be done
through JNI (+POSIX) then GNU Classpath should provide a native
(reference) implementation.

Also when something can be done in java, but there is an possibility for
the VM to do something more efficient (like for example the
getCurrentClass(Loader) methods) then they should be moved into the VM
interface code (with a default java implementation so VM implementers
don't have to implement them "natively" if they don't want to).

> * I really like Mark's approach of introducing the VMxxx classes. The
> interface between xxx and VMxxx should be well defined and we should
> try to minimize changes too it, but we also have to recognize that
> this is a hard problem. Not all VMs have the same
> requirements/trade-offs.

Glad you like it. It is really meant to make the differences between
implementing the VM interface in either java, JNI, CNI, C# or even
Active Oberon - see - more
transparent. I want to use it much more (in principle for everything
that is JNI/CNI/VM specific) but just don't have enough time...

> And finally, here is an example of how some of the requirements can be
> very different: My VM ( is built on top of .NET, so I
> want to use the .NET class libraries for I/O [...]

That is why I like IKVM.NET so much. It is just so weird ;)

BTW. Are you going to point people to the latest Mono 0.20 release notes
anytime soon? You really should shout this from the highest roof you can
find. Hint, hint...



P.S Why the HTML email with font size=tiny?
Did someone complain that they couldn't read the plain text version?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]