[Top][All Lists]
[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