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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
