From mandy.chung at oracle.com  Tue Jun 15 15:40:22 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 15 Jun 2010 15:40:22 -0700
Subject: <i18n dev> Review request: TEST_BUG:
 ResourceBundle/Bug4168625Test.java and TestBug4179766.java fails in samevm
 mode
Message-ID: <4C180156.5020804@oracle.com>

Naoto,

Can you review this test fix:

Fixed 6961506: TEST_BUG: ResourceBundle/Bug4168625Test.java and 
TestBug4179766.java fails in samevm mode

Webrev at:
   http://cr.openjdk.java.net/~mchung/6961506/webrev.00/

This fixes the tests to set the parent class loader of Loader and 
SimpleLoader to the class loader that loads the test.  jtreg samevm uses 
its own URLClassLoader to load classes that are compiled in the work 
directory and the system class loader will no longer be able to find them.

Thanks
Mandy

From naoto.sato at oracle.com  Tue Jun 15 16:46:34 2010
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 15 Jun 2010 16:46:34 -0700
Subject: <i18n dev> Review request: TEST_BUG:
 ResourceBundle/Bug4168625Test.java and TestBug4179766.java fails in samevm
 mode
In-Reply-To: <4C180156.5020804@oracle.com>
References: <4C180156.5020804@oracle.com>
Message-ID: <4C1810DA.6010004@oracle.com>

Looks good to me.

Naoto

(6/15/10 3:40 PM), Mandy Chung wrote:
> Naoto,
>
> Can you review this test fix:
>
> Fixed 6961506: TEST_BUG: ResourceBundle/Bug4168625Test.java and
> TestBug4179766.java fails in samevm mode
>
> Webrev at:
> http://cr.openjdk.java.net/~mchung/6961506/webrev.00/
>
> This fixes the tests to set the parent class loader of Loader and
> SimpleLoader to the class loader that loads the test. jtreg samevm uses
> its own URLClassLoader to load classes that are compiled in the work
> directory and the system class loader will no longer be able to find them.
>
> Thanks
> Mandy


From y.umaoka at gmail.com  Wed Jun 23 14:31:01 2010
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Wed, 23 Jun 2010 17:31:01 -0400
Subject: <i18n dev> TimeZoneNameProvider
Message-ID: <4C227D15.8050601@gmail.com>

Hi there,

We have our own TimeZoneNameProvider implementation. It looks Java does 
not pick up localized names from our implementation when long standard 
name translation is not available for the ID and locale (in other words, 
getDisplayName(ID, false, TimeZone.LONG, locale) returns null).  That 
means, you cannot provide only short name translation by an SPI 
implementation.

If this behavior is intended, the API documentation should clearly state 
the condition.  I personally think that Java should pick up names even a 
provider supports a subset although.

Should I file a bug for this problem?

Thanks,
Yoshito Umaoka

From naoto.sato at oracle.com  Thu Jun 24 10:43:11 2010
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 24 Jun 2010 10:43:11 -0700
Subject: <i18n dev> TimeZoneNameProvider
In-Reply-To: <4C227D15.8050601@gmail.com>
References: <4C227D15.8050601@gmail.com>
Message-ID: <4C23992F.3070403@oracle.com>

Looks like a bug to me. Please go ahead and file a bug.

Thanks,
Naoto

(6/23/10 2:31 PM), Yoshito Umaoka wrote:
> Hi there,
>
> We have our own TimeZoneNameProvider implementation. It looks Java does
> not pick up localized names from our implementation when long standard
> name translation is not available for the ID and locale (in other words,
> getDisplayName(ID, false, TimeZone.LONG, locale) returns null). That
> means, you cannot provide only short name translation by an SPI
> implementation.
>
> If this behavior is intended, the API documentation should clearly state
> the condition. I personally think that Java should pick up names even a
> provider supports a subset although.
>
> Should I file a bug for this problem?
>
> Thanks,
> Yoshito Umaoka