classpath
[Top][All Lists]
Advanced

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

Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI librari


From: John Leuner
Subject: Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI libraries
Date: 03 Dec 2002 19:05:46 +0000

On Tue, 2002-12-03 at 18:32, Etienne M. Gagnon wrote:
> On Tue, Dec 03, 2002 at 07:17:53PM +0100, Artur Biesiadowski wrote:
> > 
> > Maybe an acceptable solution for that would be to create indirection 
> > layer on top of all offending function (open,close,read,write,maybe few 
> > more) ?
> 
> I don't see why we should add overhead to all JVMs because of a single
> JVM that does not correctly implements JNI.

It's not JNI that is the problem, it is the GC mechanism.
 
> The whole idea of using JNI for classpath libraries was to provide
> JVM-independent libraries.
> 
> If Kissme-specific libraries are required, why not do like the CNI
> code and provide separate source files for its libraries (in a
> distinct file hierarchy in the Classpath CVS repository)?

This is possible, but then we risk divergence of code.

> I really do not think that modifying Classpath's native interface to
> add more VM ties is a good approach.  JNI was designed specifically to
> allow for VM independence.  Even Sun's HotSpot VM assumes "pure" JNI
> native libraries.  We should not deviate from such an approach only to
> accomodate "temporary" design flaws in one specific Free VM.

I agree that any changes shouldn't require VM developers to do
additional work to match the native interface. It also shouldn't have
implications for what kind of JNI libraries will work with VMs.

John Leuner

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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