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

[Andrew Haley <aph at redhat dot com>]

Nathanael Nerode writes:
 > 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 understand this hand have some sympathy with it, but it does not
override the need to avoid performance regresions in libgcj.

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

There is no doubt at all that libgcj has benefited greatly from
Classpath.  Many classes were previously incomple and in some cases
incorretc, and Classpath saved the day.

Look at the pros and cons of this change for a moment.  This new
version of the code is:

Cons:

  Slower.
  Bigger
  More compilcated.

Pros:

  Compatible with Classpath.

Therefore, on balance, it is a regression whether it reduces
maintenance cost or not.

 > If this is not the plan,

It is the plan.  We want to merge as much as is reasonable with
Classpath.  This change falls outside that scope.

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

Yes, we know that.  But that the moment libgcj has a clean, simple,
and fairly fast solution.

Andrew.