This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Trying to merge java.lang.Float, java.lang.Double with Classpath -- help wanted
- From: Tom Tromey <tromey at redhat dot com>
- To: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- Cc: Mark Wielaard <mark at klomp dot org>, Nathanael Nerode <neroden at twcny dot rr dot com>, java-patches at gcc dot gnu dot org
- Date: 22 Sep 2003 12:31:09 -0600
- Subject: Re: Trying to merge java.lang.Float, java.lang.Double with Classpath -- help wanted
- References: <6F08F312-EC8E-11D7-BA2F-003065F97F7C@mckinlay.net.nz>
- Reply-to: tromey at redhat dot com
>>>>> "Bryce" == Bryce McKinlay <bryce@mckinlay.net.nz> writes:
Bryce> I think the VMxxx design is a good one for many situations but
Bryce> not here.
For Float/Double, I'm inclined to agree with this. We can just mark
these methods "GCJ LOCAL" -- something we've been pretty lax about --
and move on. Maybe we can even revert the isNaN change in Math (a pet
peeve of mine) while we're at it.
Bryce> Classpath would be better off providing a default
Bryce> java/JNI implementation of Float/Double and allow VM developers to
Bryce> implement optimized versions themselves if desired. I suspect most VMs
Bryce> will not want/need to do this though - is there anything thats
Bryce> actually VM-specific about Float/Double?
My understanding is that JNI code isn't that great for IKVM, and
marking a method "native" isn't the desired approach there. So there
really is a conflict here. Presumably IKVM sets the standard, and not
us, since we're more willing and able to maintain divergences.
Tom