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

[neroden at twcny dot rr dot com (Nathanael Nerode)]

Brye McKinlay wrote:
>Yes, and eventually GCJ will be able to do this. However it still comes 
>at a cost of extra space for all the extra methods and classes 
>(significant if someone wants to construct a very minimal, J2ME-type 
>runtime), and adds maintenance burden by making the code more layered & 
>complex.

You are quite wrong here.  The structure reduces the 
maintenance burden on GCJ maintainers by allowing as many classes and 
methods as possible to be pure upstream Classpath implementations, 
rather than being partly-Classpath and partly-GCJ.  The current 
situation makes merges from upstream tediously manual, with every change 
needing to be checked to see whether it's to a GCJ-specific part or not.

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 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.

-- 
Nathanael Nerode  <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html