ResourceBundle variants and child variants

ResourceBundle variants and child variants

[Mark Wielaard]

Hi,

Mauve contains a couple of java.util.ResourceBundle checks that test for
"child variants". The Java Class Libraries, Volume 1, Second Edition
explains these things and gives some examples. e.g
ErrorResources_de_CH_WIN_95 and ErrorResources_de_CH_WIN_311 are both
child variants of ErrorResources_de_CH_WIN. Mauve even contains some
tests to check that these child variants are correctly searched for.

The API Spec as found online however does not talk about child variants
at all. And a quick test against the Sun JDK 1.4.1 implementation seems
to suggest that it does not implement support for these child variants.

Which specification should we take as normative?
Do the different class libraries implementations implement it?
(GNU Classpath and libgcj don't support them, kaffe does.)
Should these tests be removed from Mauve?

Cheers,

Mark

ResourceBundle variants and child variants

[Andrew Haley]

Mark Wielaard writes:
 > Mauve contains a couple of java.util.ResourceBundle checks that test for
 > "child variants". The Java Class Libraries, Volume 1, Second Edition
 > explains these things and gives some examples. e.g
 > ErrorResources_de_CH_WIN_95 and ErrorResources_de_CH_WIN_311 are both
 > child variants of ErrorResources_de_CH_WIN. Mauve even contains some
 > tests to check that these child variants are correctly searched for.
 > 
 > The API Spec as found online however does not talk about child variants
 > at all. And a quick test against the Sun JDK 1.4.1 implementation seems
 > to suggest that it does not implement support for these child variants.
 > 
 > Which specification should we take as normative?
 > Do the different class libraries implementations implement it?
 > (GNU Classpath and libgcj don't support them, kaffe does.)
 > Should these tests be removed from Mauve?

I would think so.  There's no way that Mauve should be testing
anything outside the specifications.

Andrew.

Re: ResourceBundle variants and child variants

[Mark Wielaard]

Hi,

On Mon, 2002-12-09 at 12:27, Andrew Haley wrote:
> Mark Wielaard writes:
>  > Mauve contains a couple of java.util.ResourceBundle checks that test for
>  > "child variants". The Java Class Libraries, Volume 1, Second Edition
>  > explains these things and gives some examples. e.g
>  > ErrorResources_de_CH_WIN_95 and ErrorResources_de_CH_WIN_311 are both
>  > child variants of ErrorResources_de_CH_WIN. Mauve even contains some
>  > tests to check that these child variants are correctly searched for.
>  > 
>  > The API Spec as found online however does not talk about child variants
>  > at all. And a quick test against the Sun JDK 1.4.1 implementation seems
>  > to suggest that it does not implement support for these child variants.
>  > 
>  > Which specification should we take as normative?
>  > Do the different class libraries implementations implement it?
>  > (GNU Classpath and libgcj don't support them, kaffe does.)
>  > Should these tests be removed from Mauve?
> 
> I would think so.  There's no way that Mauve should be testing
> anything outside the specifications.

But the question is, what is considered The Specification?
I use The Java Class Libraries books a lot when implementing classes.
And since it describes the child variants it could also be argued that
the online API doc (and most implementations except for Kaffe) is
flawed.

Cheers,

Mark

P.S. The Java Class Libraries supplemental does not cover the 1.2
changes to ResourceBundle :{

Re: ResourceBundle variants and child variants

[Andrew Haley]

Mark Wielaard writes:
 > Hi,
 > 
 > On Mon, 2002-12-09 at 12:27, Andrew Haley wrote:
 > > Mark Wielaard writes:
 > >  > Mauve contains a couple of java.util.ResourceBundle checks that test for
 > >  > "child variants". The Java Class Libraries, Volume 1, Second Edition
 > >  > explains these things and gives some examples. e.g
 > >  > ErrorResources_de_CH_WIN_95 and ErrorResources_de_CH_WIN_311 are both
 > >  > child variants of ErrorResources_de_CH_WIN. Mauve even contains some
 > >  > tests to check that these child variants are correctly searched for.
 > >  > 
 > >  > The API Spec as found online however does not talk about child variants
 > >  > at all. And a quick test against the Sun JDK 1.4.1 implementation seems
 > >  > to suggest that it does not implement support for these child variants.
 > >  > 
 > >  > Which specification should we take as normative?
 > >  > Do the different class libraries implementations implement it?
 > >  > (GNU Classpath and libgcj don't support them, kaffe does.)
 > >  > Should these tests be removed from Mauve?
 > > 
 > > I would think so.  There's no way that Mauve should be testing
 > > anything outside the specifications.
 > 
 > But the question is, what is considered The Specification?
 > I use The Java Class Libraries books a lot when implementing classes.
 > And since it describes the child variants it could also be argued that
 > the online API doc (and most implementations except for Kaffe) is
 > flawed.

What version of Java is The Java Class Libraries, Volume 1, Second
Edition supposed to document?

Andrew.

Re: ResourceBundle variants and child variants

[Mark Wielaard]

Hi,

On Mon, 2002-12-09 at 19:38, Andrew Haley wrote:
> Mark Wielaard writes:
>  > But the question is, what is considered The Specification?
>  > I use The Java Class Libraries books a lot when implementing classes.
>  > And since it describes the child variants it could also be argued that
>  > the online API doc (and most implementations except for Kaffe) is
>  > flawed.
> 
> What version of Java is The Java Class Libraries, Volume 1, Second
> Edition supposed to document?

The 1.1 version of the Class libraries. The Supplemental gives that
changes for 1.2.

Cheers,

Mark

Re: ResourceBundle variants and child variants

[Andrew Haley]

Mark Wielaard writes:
 > Hi,
 > 
 > On Mon, 2002-12-09 at 19:38, Andrew Haley wrote:
 > > Mark Wielaard writes:
 > >  > But the question is, what is considered The Specification?
 > >  > I use The Java Class Libraries books a lot when implementing classes.
 > >  > And since it describes the child variants it could also be argued that
 > >  > the online API doc (and most implementations except for Kaffe) is
 > >  > flawed.
 > > 
 > > What version of Java is The Java Class Libraries, Volume 1, Second
 > > Edition supposed to document?
 > 
 > The 1.1 version of the Class libraries. The Supplemental gives that
 > changes for 1.2.

Right, so the child variants haven't been mentioned in any 1.3 or 1.4 spec?

If so, that's a slam-dunk, IMO.

Andrew.

Re: ResourceBundle variants and child variants

[Dalibor Topic]

--- Mark Wielaard <mark@klomp.org> wrote:
> Hi,
> 
> On Mon, 2002-12-09 at 12:27, Andrew Haley wrote:
> > Mark Wielaard writes:
> >  > Mauve contains a couple of
> java.util.ResourceBundle checks that test for
> >  > "child variants". The Java Class Libraries,
> Volume 1, Second Edition
> >  > explains these things and gives some examples.
> e.g
> >  > ErrorResources_de_CH_WIN_95 and
> ErrorResources_de_CH_WIN_311 are both
> >  > child variants of ErrorResources_de_CH_WIN.
> Mauve even contains some
> >  > tests to check that these child variants are
> correctly searched for.
> >  > 
> >  > The API Spec as found online however does not
> talk about child variants
> >  > at all. And a quick test against the Sun JDK
> 1.4.1 implementation seems
> >  > to suggest that it does not implement support
> for these child variants.
> >  > 
> >  > Which specification should we take as
> normative?
> >  > Do the different class libraries
> implementations implement it?
> >  > (GNU Classpath and libgcj don't support them,
> kaffe does.)
> >  > Should these tests be removed from Mauve?
> > 
> > I would think so.  There's no way that Mauve
> should be testing
> > anything outside the specifications.
> 
> But the question is, what is considered The
> Specification?
> I use The Java Class Libraries books a lot when
> implementing classes.
> And since it describes the child variants it could
> also be argued that
> the online API doc (and most implementations except
> for Kaffe) is
> flawed.

I think I remember the time when there were child
variants for *Locales* in wide useage in the EU, due
to pending conversion to a new currency. de_DE_EURO
anyone? 

I don't know if that means anything to ResourceBundle
support, but I'd expect it to match Locale's rules for
resolution. I think one of the examples for Locale in
Java Class Libraries 2n Ed Volume 1 mentions a
norwegian Locale with the child variant "bookmal".

As I understand the spec for Locale, it says "Where
there are two variants, separate them with an
underscore, and put the most important one first." ,
so it is possible to have child variants. They also
give an example in the next sentence,
"Traditional_WIN" . See
http://java.sun.com/j2se/1.4/docs/api/java/util/Locale.html
, the paragraph just below the country code link.

best regards,

dalibor topic

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: ResourceBundle variants and child variants

[Mark Wielaard]

Hi,

On Tue, 2002-12-10 at 17:45, Dalibor Topic wrote:
> I think I remember the time when there were child
> variants for *Locales* in wide useage in the EU, due
> to pending conversion to a new currency. de_DE_EURO
> anyone? 

Actually that is a "normal variant".
A Locale with a child variant would be de_DE_EURO_POSIX or
de_DE_POSIX_EURO. (Hmmm, makes you think, what is more important,
EURO or POSIX?)

> As I understand the spec for Locale, it says "Where
> there are two variants, separate them with an
> underscore, and put the most important one first." ,
> so it is possible to have child variants. They also
> give an example in the next sentence,
> "Traditional_WIN" . See
> http://java.sun.com/j2se/1.4/docs/api/java/util/Locale.html
> , the paragraph just below the country code link.

So they do exist :) I think what happened is that ResourceBundle got
rewritten so many times (the Sun bug database has a lot of bug reports
about it being rewritten once again) that the original algorithm that
just chopped off a '_' at a time somewhere got lost. And that the new
specification now just explains what this new algorithm does (take the
Locale variant as one string).

Sigh, I really wish there was a real Java standard.

But I didn't find any bug reports about people missing the child variant
support in the first place so maybe it just wasn't a very useful feature
in the first place.

I don't think that it is such a slam-dunk as Andrew says but removing
(or disabling) these tests does make sense. Does anybody disagree?

Cheers,

Mark

Re: ResourceBundle variants and child variants

[Tom Tromey]

Mark> Sigh, I really wish there was a real Java standard.

Yeah.  Though then we'd spend hundreds of hours in committee meetings :-)

Mark> I don't think that it is such a slam-dunk as Andrew says but removing
Mark> (or disabling) these tests does make sense. Does anybody disagree?

Is there any way to test the 1.4 JDK and see what Sun is up to?  I
realize that isn't always normative, but it seems like in this case it
could be.

Tom

Re: ResourceBundle variants and child variants

[Mark Wielaard]

Hi,

On Tue, 2002-12-10 at 23:17, Tom Tromey wrote:
> Mark> I don't think that it is such a slam-dunk as Andrew says but removing
> Mark> (or disabling) these tests does make sense. Does anybody disagree?
> 
> Is there any way to test the 1.4 JDK and see what Sun is up to?  I
> realize that isn't always normative, but it seems like in this case it
> could be.

It fails the tests current in Mauve (just like gcj).

FAIL: gnu.testlet.java.util.ResourceBundle.getBundle: book sample (number 2)
FAIL: gnu.testlet.java.util.ResourceBundle.getBundle: book sample (number 5)

They only reason I ask is because I know that kaffe succeeds on these
tests. (And as the test name implies, The Book descibes them.)

Cheers,

Mark

Re: ResourceBundle variants and child variants

[Andrew Haley]

Tom Tromey writes:
 > Mark> Sigh, I really wish there was a real Java standard.
 > 
 > Yeah.  Though then we'd spend hundreds of hours in committee meetings :-)
 > 
 > Mark> I don't think that it is such a slam-dunk as Andrew says 

I agree; I was guilty of hyperbole.  And not for the first time, nor
probably the last!  :-)

 > Mark> but removing
 > Mark> (or disabling) these tests does make sense. Does anybody disagree?
 > 
 > Is there any way to test the 1.4 JDK and see what Sun is up to?  I
 > realize that isn't always normative, but it seems like in this case it
 > could be.

Um, I guess.

Andrew.

Re: ResourceBundle variants and child variants

[Mark Wielaard]

Hi,

On Tue, 2002-12-10 at 23:31, Mark Wielaard wrote:
> On Tue, 2002-12-10 at 23:17, Tom Tromey wrote:
> > 
> > Is there any way to test the 1.4 JDK and see what Sun is up to?  I
> > realize that isn't always normative, but it seems like in this case it
> > could be.
> 
> It fails the tests current in Mauve (just like gcj).
> 
> FAIL: gnu.testlet.java.util.ResourceBundle.getBundle: book sample (number 2)
> FAIL: gnu.testlet.java.util.ResourceBundle.getBundle: book sample (number 5)
> 
> They only reason I ask is because I know that kaffe succeeds on these
> tests. (And as the test name implies, The Book descibes them.)

Since nobody complained I "fixed" these two tests. Kissme, gcj and Sun
JDK 1.4.1 now succeed all the getBundle() tests. Kaffe still has some
failures, but those seem to be real failures in the Kaffe ResourceBundle
implementation.

Cheers,

Mark