classpath
[Top][All Lists]
Advanced

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

RE: Contributions of work on Jikes RVM with GNU Classpath


From: Jeroen Frijters
Subject: RE: Contributions of work on Jikes RVM with GNU Classpath
Date: Mon, 16 Dec 2002 16:43:35 +0100

Mark Wielaard wrote:
> I would like to take the same approach as we are doing (or 
> going to do)
> for the VM glue classes in java.lang (e.g. Throwable and VMThrowable).
> For every class that contains native methods rewrite them so 
> they call a Helper/State class. But unlike the VM glue classes
> GNU Classpath comes with a standard JNI based implementation
> of these Helper/State classes for GNU or POSIX based machines
> but VMs like libgcj (CNI), IK.VM.NET (Managed C++) or JRVM
> (Java) can provide a different implementation.

I'm very much in favor of this approach. The reason that I like to implement
the classpath native methods in Java (calling .NET library methods). To be
clear, I don't use Managed C++ for native methods, I only use Managed C++ to
implement JNI, but I never implement the classpath native methods using JNI.

Here is an example of what I do at the moment: I changed
PlainSocketImpl.java to store a reference to a .NET socket
(System.Net.Sockets.Socket) instead of the native_fd int and I implemented
all the native methods by redirecting to the appropriate .NET socket method.
The downside to this approach is obvious, whenever someone changes the
non-native methods, I have to manually merge those changes back in. It would
be great if the native methods (and the handle!) would be abstracted away in
a different class, so that I only had to change that class.

Regards,
Jeroen




reply via email to

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