Hi,
Mon, 6 Dec 2010 23:19:56 +0200 Pekka Enberg <penb...@kernel.org>: > 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 but also taking > >> real-world wrinkles into account. > > > > I agree with you but: > > 1. today we have an opportunity to hack (influence) OpenJDK (what should > the correct behavior of setMaximumDigits() be in the future JDK releases?); > > 2. The current Classpath implementation of DecimalFormat.parse() > (returning 4 digits in the above test case) is anyway broken, so it's ok > to fix it somehow now (nothing prevents to remove stop position in the code to > match the RI later). > > Yes, I agree that current GNU Classpath behavior is broken and your > new behavior seems to be the correct one. However, I'd still go for > bug to bug compatibility with OpenJDK until there's a _released > version_ of OpenJDK available that implements the desired behavior. I agree with you (just repeat again). > > 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 would - is broken now. The patch would make it "less" broken. (returning 4 digits for the test case is definitely wrong here) Why not to fix this first (a long with the other bugs fixed by the proposed patch) and then think (discuss with the community) should we remove "stop" position calculation or not (if yes then prepare a separate small patch for it). > > Pekka
