Re: Trying to merge java.lang.Float, java.lang.Double with Classpath -- help wanted

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

On Monday, Sep 22, 2003, at 11:56 Pacific/Auckland, Nathanael Nerode 
wrote:

> I believed that the GCJ plan was to merge as much as was reasonable 
> with
> upstream Classpath so that Classpath could be a simple upstream
> provider.  This seemed to be a good plan to me.  If this is not the
> plan, the web pages need to be changed to explain this; and GCJ_LOCAL
> markers should be put into dozens of classes (such as Double and Float)
> to indicate that these are not going to be merged with Classpath.

I am of absolutely in favour of merging, like you say, as much as is 
reasonable. However, in my opinion replacing perfectly good, core 
classes with ones that are less efficient and more complex crosses the 
line of what is reasonable.

The GCJ_LOCAL marker is a good idea.

> > I think the VMxxx design is a good one for many situations -
> > but not here. Classpath would be better off providing a default
> > java/JNI implementation of Float/Double and allow VM developers to
> > implement optimized versions themselves if desired. I suspect most 
> > VMs will not
> > want/need to do this though - is there anything thats actually
> > VM-specific about Float/Double?
>
> Did you read the patch?  The three moved methods in each class are
> inherently platform-specific in implementation.

They are only GCJ-specific because they use CNI. There is nothing that 
is specific to any given VM implementation, ie a JNI implementation in 
classpath should work anywhere. This is quite different from things 
like Thread and Object which may be very different in the way they are 
implemented internally by the VM.

The differences for Double/Float arise because JNI is typically less 
efficient than CNI, so other VMs (and classpath) may prefer to 
implement things in Java where possible to avoid the JNI overhead, 
while in GCJ we can use a faster native implementation.

Regards

Bryce.