classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cp-patches] Fix For Bug #11545 -- Locale Regression


From: Michael Koch
Subject: Re: [cp-patches] Fix For Bug #11545 -- Locale Regression
Date: Tue, 11 Jan 2005 23:48:03 +0100
User-agent: KMail/1.7.1

Am Dienstag, 11. Januar 2005 23:20 schrieb Andrew John Hughes:
> On Tue, 2005-01-11 at 16:30, Jeroen Frijters wrote:
> > Andrew John Hughes wrote:
> > > I'm committing the following patch which fixes the
> > > NullPointerException being thrown.
> >
> > You didn't include the patch,
>
> Sorry, I wrote the mail and forgot to actually attach... :(
>
> >  but I have a comment anyway ;-)
> >
> > Sun uses a magic currency "XXX" to solve this problem, please at
> > least consider taking this approach instead of inventing another
> > scheme. Tests for this behavior are already in Mauve.
> >
> > Thanks.
> >
> > Regards,
> > Jeroen
>
> Yes, I've seen this Mauve testcase (which, IIRC, now fails).
> Personally, I feel that copying obscure parts of Sun's
> implementation is not right for GNU Classpath.  The above is not
> documented (AFAICS) in the specification, and only occurs in Sun's
> VM.  In fact, the documentation for setCurrency() suggests that
> null is a perfectly valid value for the currency attribute.  I
> haven't invented a new scheme, but followed the spec. (and common
> sense) as much as possible. getCurrency() returning null is a lot
> clearer than obscure "XXX" strings getting into your programs
> anyway, IMO.  Generally, if you want the currency symbols, I would
> imagine you would ensure that they are available.

As long as there are no real world applications depending on the "XXX" 
we should leave it like it is.

> This has already been discussed generally on a recent
> address@hidden thread about Mauve, where I believe it was noted
> that following obscure parts of Sun's implementation should be
> considered a buggy test.

I wouldn't consider this a buggy test. It just tests for unspecified 
behavior. Some real world applications depend on unspecified 
behaviors. Thats quiet common, unfortunately. Having a testcase for 
this helps us to find out when SUN changes its behavior and when we 
break the "unspecified" behavior.


Michael
-- 
Homepage: http://www.worldforge.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]