On 00:19 Tue 07 Dec , Pekka Enberg wrote:
2010/12/6 Ivan Maidanski iv...@mail.ru:
Googling around doesn't seem to bring anything on the topic which
makes me think this is an old bug that nobody really cares about but
there can be applications out there that rely on the current behavior
On Tue, Dec 7, 2010 at 3:25 PM, Dr Andrew John Hughes
ahug...@redhat.com wrote:
I meant applications relying on the current behavior of OpenJDK so
it's probably not worth it to make the behavior correct in either of
the projects. But sure, I do think your patch is an improvement as-is
so I'm
[ Sorry for the delay. ]
On Sat, 27 Nov 2010, Ivan Maidanski wrote:
Sorry for the provided test below - it doesn't test the things that are fixed
by the attached patch. In fact, the test is for a bug that has been already
fixed since Classpath v0.93 (by not relying on setMaximumIntegerDigits
Hi Ivan,
2010/12/6 Ivan Maidanski iv...@mail.ru:
Sorry for the provided test below - it doesn't test the things that
are fixed by the attached patch. In fact, the test is for a bug that has been
already fixed since Classpath v0.93 (by not relying on
setMaximumIntegerDigits
implementation).
2010/12/6 Ivan Maidanski iv...@mail.ru:
I'm bit surprised, though, that we'd want behavior that doesn't
match
Sun JRE. To me, any API behavior (even if it's a bug) that has lived
long enough in Sun JRE is what Classpath ought to aim at.
Compatibility is not just following the specification
2010/12/6 Ivan Maidanski iv...@mail.ru:
Googling around doesn't seem to bring anything on the topic which
makes me think this is an old bug that nobody really cares about but
there can be applications out there that rely on the current behavior
that would be broken under GNU Classpath.
Not