From sean.coffey at oracle.com  Wed Sep  5 13:10:49 2012
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Wed, 05 Sep 2012 21:10:49 +0100
Subject: <i18n dev> Review request : 7180362: RFE: Implement date
 cutover functionality for currency.properties file
In-Reply-To: <503F921F.30800@oracle.com>
References: <503CCC2E.80907@oracle.com>
	<CACzrW9Auapa6x5WA6vWpST4ALO-WBHuSJkFfNY_HiFz1zG5Q=w@mail.gmail.com>
	<503F921F.30800@oracle.com>
Message-ID: <5047B1C9.2020401@oracle.com>

Latest webrev is available here : 
http://cr.openjdk.java.net/~coffeys/webrev.7180362.3.jdk8/ 
<http://cr.openjdk.java.net/%7Ecoffeys/webrev.7180362.3.jdk8/>

I've changed code so that ISO 8601 format is now expected.

regards,
Sean.

On 30/08/2012 17:17, Se?n Coffey wrote:
> Stephen,
>
> just see your mail now (damn filters)
>
> Yes - this makes sense. I'll make the modification and run some more 
> tests to ensure all is ok.
> Updated webrev to follow. I'll also follow up with getting new change 
> approved with the
> compatibility/conformance team.
>
> regards,
> Sean.
>
> On 29/08/2012 22:00, Stephen Colebourne wrote:
>> I object to the implementation of this change, specifically the date 
>> format -
>> "The format of date must be {@code 'yyyy-MM-dd-HH-mm-ss'}"
>>
>> There seems to be no reason not to use the standard ISO-8601 format
>> here - yyyy-MM-dd'T'HH:mm:ss
>>
>> Stephen
>> co-spec lead JSR-310
>>
>>
>> On 28 August 2012 14:48, Se?n Coffey <sean.coffey at oracle.com> wrote:
>>> 7180362 deals with an enhancement to allow the JRE specify cutover 
>>> dates
>>> when currency.properties file is provided. I've added the required 
>>> syntax to
>>> the new javadoc comments in Currency class.
>>>
>>> bug report :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7180362
>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7180362.1.jdk8/
>>> <http://cr.openjdk.java.net/%7Ecoffeys/webrev.7180362.1.jdk8/>
>>>
>>> I hope to port an almost identical change to 7u shortly. (minus API 
>>> javadoc
>>> comments)
>>>
>>> I've kept the testcase logic different to the JRE logic around how 
>>> the new
>>> property is parsed to better
>>> test the golden result expectations. (both approaches should be equal)
>>>
>>> Regards,
>>> Sean.
>


From michael.fang at oracle.com  Wed Sep  5 14:08:54 2012
From: michael.fang at oracle.com (Michael Fang)
Date: Wed, 05 Sep 2012 14:08:54 -0700
Subject: <i18n dev> [8] Review request for 7196354 check-in jdk.tbom file to
 openjdk repo
In-Reply-To: <50338B45.4050906@oracle.com>
References: <737597189.4451353.1344937908713.JavaMail.root@redhat.com>
	<84F7A368-1206-4D3C-A79F-9F2C6F8EC719@oracle.com>
	<5032706A.8060007@oracle.com> <50338B45.4050906@oracle.com>
Message-ID: <5047BF66.7080704@oracle.com>

Hello,

Please help to review the new JDK8 file for the following CR:
7196354 check-in jdk.tbom file to openjdk repo

The webrev is located at:
http://cr.openjdk.java.net/~mfang/7196354/webrev.00/

Build-dev:
The file will be pushed to the top level openjdk repository 
http://hg.openjdk.java.net/jdk8/build. This file is to be used as 
translation bill of material file for automated translation drop system 
to zip up the list of English resource files to be delivered to 
translation team.

Mark:
Since the dev team will need to maintain this file in the future 
(modifying it if you add or delete resource files), I temporarily put 
down your name as contact for the file. Please figure out the proper 
owner and we can update it again.

Core-libs-dev:
I believe most of the resource files are used for your product area. 
Please take a look and let me know if you have any concerns, or know of 
any files to be added or deleted at this time.

In the future, if any bug/rfe requires adding/deleting resource files, 
the dev work should include updating this file to reflect the correct 
resource file list. (and please ask me to review it).

I18n-dev:
Also included the group mailing list since this is part of l10n team's 
deliverable.

thanks,

-michael

From mark.reinhold at oracle.com  Thu Sep  6 13:29:23 2012
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 06 Sep 2012 13:29:23 -0700
Subject: <i18n dev> [8] Review request for 7196354 check-in jdk.tbom
	file to openjdk repo
In-Reply-To: michael.fang@oracle.com; Wed, 05 Sep 2012 14:08:54 PDT;
	<5047BF66.7080704@oracle.com>
Message-ID: <20120906202923.834A7856@eggemoggin.niobe.net>

2012/9/5 14:08 -0700, michael.fang at oracle.com:
> Please help to review the new JDK8 file for the following CR:
> 7196354 check-in jdk.tbom file to openjdk repo
> 
> The webrev is located at:
> http://cr.openjdk.java.net/~mfang/7196354/webrev.00/

This file needs a more descriptive name, especially if it's going to be
in the root of the source tree.  Suggestion: translated-files.xml .

Is there a DTD or a schema for this file?  I can guess what most of it
means, but I might guess incorrectly.

[line 8] "OpenJDK" isn't a component, it's a community.  I think you mean
"JDK" here.

The "JDK" / "JRE" division in this file is somewhat artificial and likely
to become incorrect over time -- not every developer knows exactly which
files are in the JRE vs. the full JDK.  I suggest doing away with that
division and simply sorting the file-set elements by source file name.

At a glance it looks like the source and target attributes for any given
file are identical.  Do you expect there to be cases where they're
different?

> ...
> 
> Mark:
> Since the dev team will need to maintain this file in the future (modifying it
> if you add or delete resource files), I temporarily put down your name as
> contact for the file. Please figure out the proper owner and we can update it
> again.

We don't put contact names in source code.  Please remove my name, and do
not add another.

> ...
> 
> In the future, if any bug/rfe requires adding/deleting resource files, the dev
> work should include updating this file to reflect the correct resource file
> list. (and please ask me to review it).

If you expect other people to update this file over time then you need
to document that expectation somewhere and, as importantly, you need to
document the syntax and semantics of the file.  Fortunately we have a
way to do that, namely the JEP process (http://openjdk.java.net/jeps/).
I suggest you draft a JEP for this and circulate it for review along
with the webrev.

- Mark

From michael.fang at oracle.com  Thu Sep  6 16:46:08 2012
From: michael.fang at oracle.com (Michael Fang)
Date: Thu, 06 Sep 2012 16:46:08 -0700
Subject: <i18n dev> [8] Review request for 7196354 check-in jdk.tbom
 file to openjdk repo
In-Reply-To: <20120906202923.834A7856@eggemoggin.niobe.net>
References: <20120906202923.834A7856@eggemoggin.niobe.net>
Message-ID: <504935C0.30705@oracle.com>

Hi Mark,

Thanks for the review and feedback.

Please see my comments inline below.

thanks,

-michael

On 12?09?06? 01:29 ??, mark.reinhold at oracle.com wrote:
> 2012/9/5 14:08 -0700, michael.fang at oracle.com:
>> Please help to review the new JDK8 file for the following CR:
>> 7196354 check-in jdk.tbom file to openjdk repo
>>
>> The webrev is located at:
>> http://cr.openjdk.java.net/~mfang/7196354/webrev.00/
> This file needs a more descriptive name, especially if it's going to be
> in the root of the source tree.  Suggestion: translated-files.xml .
The translation drop system is now an Oracle-wide translation system and 
we are strongly recommended to follow the standard naming convention for 
all Oracle products, which is component-name.tbom.

I have checked with the team and we can move the file away from the root 
of the source tree to, for example, jdk/make/jdk.tbom.

>
> Is there a DTD or a schema for this file?  I can guess what most of it
> means, but I might guess incorrectly.
The XSD is available in NLSTOOLS ADE label.
nlstools/lights2/Extractor/src/java/xsd/tbom.xsd
It's internal information. I will find it and forward it to you separately.
>
> [line 8] "OpenJDK" isn't a component, it's a community.  I think you mean
> "JDK" here.
Yes, JDK.
>
> The "JDK" / "JRE" division in this file is somewhat artificial and likely
> to become incorrect over time -- not every developer knows exactly which
> files are in the JRE vs. the full JDK.  I suggest doing away with that
> division and simply sorting the file-set elements by source file name.
JDK and JRE are translated into different sets of languages. 2 languages 
for JDK and 10 for JRE. We used to divide the files this way in order to 
translate the files into the correct set of languages. But it's not 
necessary now. Sorting by groups or projects may be fine. Whatever is 
easy for the groups/teams to find and maintain their files.
>
> At a glance it looks like the source and target attributes for any given
> file are identical.  Do you expect there to be cases where they're
> different?
In jdk.tbom, source and target are the same for all files. But on 
jdkclosed.tbom, the man page files have different source and target 
directories.
>
>> ...
>>
>> Mark:
>> Since the dev team will need to maintain this file in the future (modifying it
>> if you add or delete resource files), I temporarily put down your name as
>> contact for the file. Please figure out the proper owner and we can update it
>> again.
> We don't put contact names in source code.  Please remove my name, and do
> not add another.
OK, I will remove it.
>
>> ...
>>
>> In the future, if any bug/rfe requires adding/deleting resource files, the dev
>> work should include updating this file to reflect the correct resource file
>> list. (and please ask me to review it).
> If you expect other people to update this file over time then you need
> to document that expectation somewhere and, as importantly, you need to
> document the syntax and semantics of the file.  Fortunately we have a
> way to do that, namely the JEP process (http://openjdk.java.net/jeps/).
> I suggest you draft a JEP for this and circulate it for review along
> with the webrev.
I will look into it.
>
> - Mark


From naoto.sato at oracle.com  Fri Sep  7 09:44:45 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 07 Sep 2012 09:44:45 -0700
Subject: <i18n dev> Review request : 7180362: RFE: Implement date
 cutover functionality for currency.properties file
In-Reply-To: <5047B1C9.2020401@oracle.com>
References: <503CCC2E.80907@oracle.com>
	<CACzrW9Auapa6x5WA6vWpST4ALO-WBHuSJkFfNY_HiFz1zG5Q=w@mail.gmail.com>
	<503F921F.30800@oracle.com> <5047B1C9.2020401@oracle.com>
Message-ID: <504A247D.70800@oracle.com>

Looks good to me.

Naoto

On 9/5/12 1:10 PM, Se?n Coffey wrote:
> Latest webrev is available here :
> http://cr.openjdk.java.net/~coffeys/webrev.7180362.3.jdk8/
> <http://cr.openjdk.java.net/%7Ecoffeys/webrev.7180362.3.jdk8/>
>
> I've changed code so that ISO 8601 format is now expected.
>
> regards,
> Sean.
>
> On 30/08/2012 17:17, Se?n Coffey wrote:
>> Stephen,
>>
>> just see your mail now (damn filters)
>>
>> Yes - this makes sense. I'll make the modification and run some more
>> tests to ensure all is ok.
>> Updated webrev to follow. I'll also follow up with getting new change
>> approved with the
>> compatibility/conformance team.
>>
>> regards,
>> Sean.
>>
>> On 29/08/2012 22:00, Stephen Colebourne wrote:
>>> I object to the implementation of this change, specifically the date
>>> format -
>>> "The format of date must be {@code 'yyyy-MM-dd-HH-mm-ss'}"
>>>
>>> There seems to be no reason not to use the standard ISO-8601 format
>>> here - yyyy-MM-dd'T'HH:mm:ss
>>>
>>> Stephen
>>> co-spec lead JSR-310
>>>
>>>
>>> On 28 August 2012 14:48, Se?n Coffey <sean.coffey at oracle.com> wrote:
>>>> 7180362 deals with an enhancement to allow the JRE specify cutover
>>>> dates
>>>> when currency.properties file is provided. I've added the required
>>>> syntax to
>>>> the new javadoc comments in Currency class.
>>>>
>>>> bug report :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7180362
>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7180362.1.jdk8/
>>>> <http://cr.openjdk.java.net/%7Ecoffeys/webrev.7180362.1.jdk8/>
>>>>
>>>> I hope to port an almost identical change to 7u shortly. (minus API
>>>> javadoc
>>>> comments)
>>>>
>>>> I've kept the testcase logic different to the JRE logic around how
>>>> the new
>>>> property is parsed to better
>>>> test the golden result expectations. (both approaches should be equal)
>>>>
>>>> Regards,
>>>> Sean.
>>
>


From scolebourne at joda.org  Fri Sep  7 09:50:27 2012
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 7 Sep 2012 17:50:27 +0100
Subject: <i18n dev> Review request : 7180362: RFE: Implement date
 cutover functionality for currency.properties file
In-Reply-To: <5047B1C9.2020401@oracle.com>
References: <503CCC2E.80907@oracle.com>
	<CACzrW9Auapa6x5WA6vWpST4ALO-WBHuSJkFfNY_HiFz1zG5Q=w@mail.gmail.com>
	<503F921F.30800@oracle.com> <5047B1C9.2020401@oracle.com>
Message-ID: <CACzrW9BFn02FRraemYfLxix7HQTEso4HVNA6JJe-uynGD73hjw@mail.gmail.com>

Thanks for changing to ISO-8601.
Stephen

On 5 September 2012 21:10, Se?n Coffey <sean.coffey at oracle.com> wrote:
> Latest webrev is available here :
> http://cr.openjdk.java.net/~coffeys/webrev.7180362.3.jdk8/
> <http://cr.openjdk.java.net/%7Ecoffeys/webrev.7180362.3.jdk8/>
>
> I've changed code so that ISO 8601 format is now expected.
>
> regards,
> Sean.
>
>
> On 30/08/2012 17:17, Se?n Coffey wrote:
>>
>> Stephen,
>>
>> just see your mail now (damn filters)
>>
>> Yes - this makes sense. I'll make the modification and run some more tests
>> to ensure all is ok.
>> Updated webrev to follow. I'll also follow up with getting new change
>> approved with the
>> compatibility/conformance team.
>>
>> regards,
>> Sean.
>>
>> On 29/08/2012 22:00, Stephen Colebourne wrote:
>>>
>>> I object to the implementation of this change, specifically the date
>>> format -
>>> "The format of date must be {@code 'yyyy-MM-dd-HH-mm-ss'}"
>>>
>>> There seems to be no reason not to use the standard ISO-8601 format
>>> here - yyyy-MM-dd'T'HH:mm:ss
>>>
>>> Stephen
>>> co-spec lead JSR-310
>>>
>>>
>>> On 28 August 2012 14:48, Se?n Coffey <sean.coffey at oracle.com> wrote:
>>>>
>>>> 7180362 deals with an enhancement to allow the JRE specify cutover dates
>>>> when currency.properties file is provided. I've added the required
>>>> syntax to
>>>> the new javadoc comments in Currency class.
>>>>
>>>> bug report :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7180362
>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7180362.1.jdk8/
>>>> <http://cr.openjdk.java.net/%7Ecoffeys/webrev.7180362.1.jdk8/>
>>>>
>>>> I hope to port an almost identical change to 7u shortly. (minus API
>>>> javadoc
>>>> comments)
>>>>
>>>> I've kept the testcase logic different to the JRE logic around how the
>>>> new
>>>> property is parsed to better
>>>> test the golden result expectations. (both approaches should be equal)
>>>>
>>>> Regards,
>>>> Sean.
>>
>>
>

From Alan.Bateman at oracle.com  Sat Sep  8 02:14:28 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 08 Sep 2012 10:14:28 +0100
Subject: <i18n dev> hg: jdk8/tl/jdk: 7180362: RFE: Implement date
 cutover functionality for currency.properties file
In-Reply-To: <20120907202017.7A46347999@hg.openjdk.java.net>
References: <20120907202017.7A46347999@hg.openjdk.java.net>
Message-ID: <504B0C74.60400@oracle.com>

On 07/09/2012 21:19, sean.coffey at oracle.com wrote:
> Changeset: fffbb33df102
> Author:    coffeys
> Date:      2012-09-07 21:22 +0100
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fffbb33df102
>
> 7180362: RFE: Implement date cutover functionality for currency.properties file
> Reviewed-by: naoto
>
> ! src/share/classes/java/util/Currency.java
> ! test/java/util/Currency/PropertiesTest.java
> ! test/java/util/Currency/PropertiesTest.sh
> ! test/java/util/Currency/currency.properties
>
A post push comment but this looks very strange:

private static boolean isPastCutoverDate(String s)
        throws IndexOutOfBoundsException, NullPointerException, 
ParseException {

I assume this should declare ParseException only as the other two are 
runtime exceptions.

Also shouldn't the parsing be made more robust so that 
replaceCurrencyData doesn't need to catch and ignore IOOBE and NPE?

-Alan.








From sean.coffey at oracle.com  Sat Sep  8 05:33:25 2012
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Sat, 08 Sep 2012 13:33:25 +0100
Subject: <i18n dev> hg: jdk8/tl/jdk: 7180362: RFE: Implement date
 cutover functionality for currency.properties file
In-Reply-To: <504B0C74.60400@oracle.com>
References: <20120907202017.7A46347999@hg.openjdk.java.net>
	<504B0C74.60400@oracle.com>
Message-ID: <504B3B15.7000507@oracle.com>


On 08/09/2012 10:14, Alan Bateman wrote:
> On 07/09/2012 21:19, sean.coffey at oracle.com wrote:
>> Changeset: fffbb33df102
>> Author:    coffeys
>> Date:      2012-09-07 21:22 +0100
>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fffbb33df102
>>
>> 7180362: RFE: Implement date cutover functionality for 
>> currency.properties file
>> Reviewed-by: naoto
>>
>> ! src/share/classes/java/util/Currency.java
>> ! test/java/util/Currency/PropertiesTest.java
>> ! test/java/util/Currency/PropertiesTest.sh
>> ! test/java/util/Currency/currency.properties
>>
> A post push comment but this looks very strange:
>
> private static boolean isPastCutoverDate(String s)
>        throws IndexOutOfBoundsException, NullPointerException, 
> ParseException {
>
> I assume this should declare ParseException only as the other two are 
> runtime exceptions.
good point Alan. I think a low priority bug can be logged to track this.
>
> Also shouldn't the parsing be made more robust so that 
> replaceCurrencyData doesn't need to catch and ignore IOOBE and NPE?
Looks like I should be checking for IAE rather than IOOBE. 
http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html#SimpleDateFormat(java.lang.String, 
java.util.Locale) 
<http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html#SimpleDateFormat%28java.lang.String,%20java.util.Locale%29>

I would never expect these exceptions to materialize (pattern checks 
syntax first) but figured that the multicatch block in 
replaceCurrencyData was suitable as a catch all since that's where we do 
most of the logging of INFO messages if we do encounter errors with 
currency.properties file.

There could be more bug fixes to Currency class in coming weeks & months 
for JDK8 - we can probably tidy this up then.

regards,
Sean.
>
> -Alan.
>
>
>
>
>
>
>


From michael.fang at oracle.com  Mon Sep 10 14:26:13 2012
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 10 Sep 2012 14:26:13 -0700
Subject: <i18n dev> [8] Review request for 7196354 check-in jdk.tbom
 file to openjdk repo
In-Reply-To: <504935C0.30705@oracle.com>
References: <20120906202923.834A7856@eggemoggin.niobe.net>
	<504935C0.30705@oracle.com>
Message-ID: <504E5AF5.2070302@oracle.com>

Hi Mark and all,

I have updated the webrev:
http://cr.openjdk.java.net/~mfang/7196354/webrev.01/

It includes the following changes:

- removed component division and contact names
- removed redundant "target" attributes


I am also moving the file from root of source tree to jdk/make/jdk.tbom. SGT strongly recommends we follow the standard file naming convention used by the translation system, which is component-name.tbom. This is followed by all Oracle products requiring translation.


We currently have no plan to publish the syntax and semantics to the 
openjdk community through JEP process. We would like to keep the syntax 
internal. When I review dev team's changes related to resource files, I 
will keep an eye on the files to be translated and translation language 
scope.

thanks,

-michael
Server Globalization Technology

On 12?09?06? 04:46 ??, Michael Fang wrote:
> Hi Mark,
>
> Thanks for the review and feedback.
>
> Please see my comments inline below.
>
> thanks,
>
> -michael
>
> On 12?09?06? 01:29 ??, mark.reinhold at oracle.com wrote:
>> 2012/9/5 14:08 -0700, michael.fang at oracle.com:
>>> Please help to review the new JDK8 file for the following CR:
>>> 7196354 check-in jdk.tbom file to openjdk repo
>>>
>>> The webrev is located at:
>>> http://cr.openjdk.java.net/~mfang/7196354/webrev.00/
>> This file needs a more descriptive name, especially if it's going to be
>> in the root of the source tree.  Suggestion: translated-files.xml .
> The translation drop system is now an Oracle-wide translation system 
> and we are strongly recommended to follow the standard naming 
> convention for all Oracle products, which is component-name.tbom.
>
> I have checked with the team and we can move the file away from the 
> root of the source tree to, for example, jdk/make/jdk.tbom.
>
>>
>> Is there a DTD or a schema for this file?  I can guess what most of it
>> means, but I might guess incorrectly.
> The XSD is available in NLSTOOLS ADE label.
> nlstools/lights2/Extractor/src/java/xsd/tbom.xsd
> It's internal information. I will find it and forward it to you 
> separately.
>>
>> [line 8] "OpenJDK" isn't a component, it's a community.  I think you 
>> mean
>> "JDK" here.
> Yes, JDK.
>>
>> The "JDK" / "JRE" division in this file is somewhat artificial and 
>> likely
>> to become incorrect over time -- not every developer knows exactly which
>> files are in the JRE vs. the full JDK.  I suggest doing away with that
>> division and simply sorting the file-set elements by source file name.
> JDK and JRE are translated into different sets of languages. 2 
> languages for JDK and 10 for JRE. We used to divide the files this way 
> in order to translate the files into the correct set of languages. But 
> it's not necessary now. Sorting by groups or projects may be fine. 
> Whatever is easy for the groups/teams to find and maintain their files.
>>
>> At a glance it looks like the source and target attributes for any given
>> file are identical.  Do you expect there to be cases where they're
>> different?
> In jdk.tbom, source and target are the same for all files. But on 
> jdkclosed.tbom, the man page files have different source and target 
> directories.
>>
>>> ...
>>>
>>> Mark:
>>> Since the dev team will need to maintain this file in the future 
>>> (modifying it
>>> if you add or delete resource files), I temporarily put down your 
>>> name as
>>> contact for the file. Please figure out the proper owner and we can 
>>> update it
>>> again.
>> We don't put contact names in source code.  Please remove my name, 
>> and do
>> not add another.
> OK, I will remove it.
>>
>>> ...
>>>
>>> In the future, if any bug/rfe requires adding/deleting resource 
>>> files, the dev
>>> work should include updating this file to reflect the correct 
>>> resource file
>>> list. (and please ask me to review it).
>> If you expect other people to update this file over time then you need
>> to document that expectation somewhere and, as importantly, you need to
>> document the syntax and semantics of the file.  Fortunately we have a
>> way to do that, namely the JEP process (http://openjdk.java.net/jeps/).
>> I suggest you draft a JEP for this and circulate it for review along
>> with the webrev.
> I will look into it.
>>
>> - Mark
>


From naoto.sato at oracle.com  Mon Sep 10 16:50:05 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 10 Sep 2012 16:50:05 -0700
Subject: <i18n dev> [8] Review request for CR 7196799: CLDR adapter can not
 be invoked when region code is specified in Locale
Message-ID: <504E7CAD.2010800@oracle.com>

Hello,

Please review the proposed fix for the subject bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7196799

The webrev for the fix is located at:

http://cr.openjdk.java.net/~naoto/7196799/webrev.00/

The fix is basically limit the implicit fallback to JRE's locale data 
only for the root locale, in order to honor the CLDR's fallback.

Naoto

From naoto.sato at oracle.com  Mon Sep 10 22:57:14 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 10 Sep 2012 22:57:14 -0700
Subject: <i18n dev> [8] Review request for 7196354 check-in jdk.tbom
 file to openjdk repo
In-Reply-To: <504E5AF5.2070302@oracle.com>
References: <20120906202923.834A7856@eggemoggin.niobe.net>
	<504935C0.30705@oracle.com> <504E5AF5.2070302@oracle.com>
Message-ID: <504ED2BA.1070508@oracle.com>

Hi Michael,

Looks like the list does not reflect the recent changes introduced by 
the re-organization of the locale data (sun/util/resources).

To me, just keeping an eye on the files sounds error prone. Would it be 
possible to add some automated check, say in "jcheck"?

Naoto

On 9/10/12 2:26 PM, Michael Fang wrote:
> Hi Mark and all,
>
> I have updated the webrev:
> http://cr.openjdk.java.net/~mfang/7196354/webrev.01/
>
> It includes the following changes:
>
> - removed component division and contact names
> - removed redundant "target" attributes
>
>
> I am also moving the file from root of source tree to jdk/make/jdk.tbom.
> SGT strongly recommends we follow the standard file naming convention
> used by the translation system, which is component-name.tbom. This is
> followed by all Oracle products requiring translation.
>
>
> We currently have no plan to publish the syntax and semantics to the
> openjdk community through JEP process. We would like to keep the syntax
> internal. When I review dev team's changes related to resource files, I
> will keep an eye on the files to be translated and translation language
> scope.
>
> thanks,
>
> -michael
> Server Globalization Technology
>
> On 12?09?06? 04:46 ??, Michael Fang wrote:
>> Hi Mark,
>>
>> Thanks for the review and feedback.
>>
>> Please see my comments inline below.
>>
>> thanks,
>>
>> -michael
>>
>> On 12?09?06? 01:29 ??, mark.reinhold at oracle.com wrote:
>>> 2012/9/5 14:08 -0700, michael.fang at oracle.com:
>>>> Please help to review the new JDK8 file for the following CR:
>>>> 7196354 check-in jdk.tbom file to openjdk repo
>>>>
>>>> The webrev is located at:
>>>> http://cr.openjdk.java.net/~mfang/7196354/webrev.00/
>>> This file needs a more descriptive name, especially if it's going to be
>>> in the root of the source tree.  Suggestion: translated-files.xml .
>> The translation drop system is now an Oracle-wide translation system
>> and we are strongly recommended to follow the standard naming
>> convention for all Oracle products, which is component-name.tbom.
>>
>> I have checked with the team and we can move the file away from the
>> root of the source tree to, for example, jdk/make/jdk.tbom.
>>
>>>
>>> Is there a DTD or a schema for this file?  I can guess what most of it
>>> means, but I might guess incorrectly.
>> The XSD is available in NLSTOOLS ADE label.
>> nlstools/lights2/Extractor/src/java/xsd/tbom.xsd
>> It's internal information. I will find it and forward it to you
>> separately.
>>>
>>> [line 8] "OpenJDK" isn't a component, it's a community.  I think you
>>> mean
>>> "JDK" here.
>> Yes, JDK.
>>>
>>> The "JDK" / "JRE" division in this file is somewhat artificial and
>>> likely
>>> to become incorrect over time -- not every developer knows exactly which
>>> files are in the JRE vs. the full JDK.  I suggest doing away with that
>>> division and simply sorting the file-set elements by source file name.
>> JDK and JRE are translated into different sets of languages. 2
>> languages for JDK and 10 for JRE. We used to divide the files this way
>> in order to translate the files into the correct set of languages. But
>> it's not necessary now. Sorting by groups or projects may be fine.
>> Whatever is easy for the groups/teams to find and maintain their files.
>>>
>>> At a glance it looks like the source and target attributes for any given
>>> file are identical.  Do you expect there to be cases where they're
>>> different?
>> In jdk.tbom, source and target are the same for all files. But on
>> jdkclosed.tbom, the man page files have different source and target
>> directories.
>>>
>>>> ...
>>>>
>>>> Mark:
>>>> Since the dev team will need to maintain this file in the future
>>>> (modifying it
>>>> if you add or delete resource files), I temporarily put down your
>>>> name as
>>>> contact for the file. Please figure out the proper owner and we can
>>>> update it
>>>> again.
>>> We don't put contact names in source code.  Please remove my name,
>>> and do
>>> not add another.
>> OK, I will remove it.
>>>
>>>> ...
>>>>
>>>> In the future, if any bug/rfe requires adding/deleting resource
>>>> files, the dev
>>>> work should include updating this file to reflect the correct
>>>> resource file
>>>> list. (and please ask me to review it).
>>> If you expect other people to update this file over time then you need
>>> to document that expectation somewhere and, as importantly, you need to
>>> document the syntax and semantics of the file.  Fortunately we have a
>>> way to do that, namely the JEP process (http://openjdk.java.net/jeps/).
>>> I suggest you draft a JEP for this and circulate it for review along
>>> with the webrev.
>> I will look into it.
>>>
>>> - Mark
>>
>


From mark.reinhold at oracle.com  Tue Sep 11 08:09:46 2012
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 11 Sep 2012 08:09:46 -0700
Subject: <i18n dev> [8] Review request for 7196354 check-in jdk.tbom
	file to openjdk repo
In-Reply-To: michael.fang@oracle.com; Mon, 10 Sep 2012 14:26:13 PDT;
	<504E5AF5.2070302@oracle.com>
Message-ID: <20120911150946.25E47491@eggemoggin.niobe.net>

2012/9/10 14:26 -0700, michael.fang at oracle.com:
> I have updated the webrev:
> http://cr.openjdk.java.net/~mfang/7196354/webrev.01/
> 
> ...
> 
> I am also moving the file from root of source tree to
> jdk/make/jdk.tbom. SGT strongly recommends we follow the standard file
> naming convention used by the translation system, which is
> component-name.tbom. This is followed by all Oracle products requiring
> translation.
> 
> We currently have no plan to publish the syntax and semantics to the openjdk
> community through JEP process. We would like to keep the syntax internal. When
> I review dev team's changes related to resource files, I will keep an eye on
> the files to be translated and translation language scope.

Thanks for the update.

A file whose syntax and semantics are not publicly documented, whose
content can only be validated by an employee of one company, and whose
very name is dictated by that company has no place in an OpenJDK code
repository.

Please work with other Oracle engineers to find a place for this file
in one of Oracle's related internal repositories.

- Mark

From michael.fang at oracle.com  Tue Sep 11 08:11:37 2012
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 11 Sep 2012 08:11:37 -0700
Subject: <i18n dev> [8] Review request for 7196354 check-in jdk.tbom
 file to openjdk repo
In-Reply-To: <20120911150946.25E47491@eggemoggin.niobe.net>
References: <20120911150946.25E47491@eggemoggin.niobe.net>
Message-ID: <504F54A9.1020104@oracle.com>

Thanks Mark for the comment. Yes, we will do that.

thanks,

-michael

On 12?09?11? 08:09 ??, mark.reinhold at oracle.com wrote:
> 2012/9/10 14:26 -0700, michael.fang at oracle.com:
>> I have updated the webrev:
>> http://cr.openjdk.java.net/~mfang/7196354/webrev.01/
>>
>> ...
>>
>> I am also moving the file from root of source tree to
>> jdk/make/jdk.tbom. SGT strongly recommends we follow the standard file
>> naming convention used by the translation system, which is
>> component-name.tbom. This is followed by all Oracle products requiring
>> translation.
>>
>> We currently have no plan to publish the syntax and semantics to the openjdk
>> community through JEP process. We would like to keep the syntax internal. When
>> I review dev team's changes related to resource files, I will keep an eye on
>> the files to be translated and translation language scope.
> Thanks for the update.
>
> A file whose syntax and semantics are not publicly documented, whose
> content can only be validated by an employee of one company, and whose
> very name is dictated by that company has no place in an OpenJDK code
> repository.
>
> Please work with other Oracle engineers to find a place for this file
> in one of Oracle's related internal repositories.
>
> - Mark


From olivier.lagneau at oracle.com  Wed Sep 12 10:19:24 2012
From: olivier.lagneau at oracle.com (Olivier Lagneau)
Date: Wed, 12 Sep 2012 19:19:24 +0200
Subject: <i18n dev> Review Request for CR : 7050528 Improve performance of
 java.text.DecimalFormat.format() call stack
Message-ID: <5050C41C.8010009@oracle.com>

Please review The implementation of a fast-path algorithm for optimizing 
the DecimalFormat.format(double, ...) call stack.

The webrev is here :
http://cr.openjdk.java.net/~olagneau/7050528/webrev.02/

As described in the CR evaluation and suggested fix, the speed-up on a 
dedicated micro-benchmark
is more than x10 on either SPARC or x86 architectures. The footprint 
cost is ~6kbytes from a static
char array constant data to collect digits from integer values.

There is an associated regression test, together with a micro-benchmark 
that may be run optionally.

-- 
Olivier Lagneau, olivier.lagneau at oracle.com
Oracle, 180 Av. de l'Europe,
ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE
Phone : +33 4 76 18 80 09 Fax : +33 4 76 18 80 23

From naoto.sato at oracle.com  Wed Sep 12 14:55:11 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 12 Sep 2012 14:55:11 -0700
Subject: <i18n dev> [8] Review request for CR 7196799: CLDR adapter can
 not be invoked when region code is specified in Locale
In-Reply-To: <504E7CAD.2010800@oracle.com>
References: <504E7CAD.2010800@oracle.com>
Message-ID: <505104BF.5090501@oracle.com>

I updated the webrev to include another fix to a test bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197573

Since the fix is to correct some wrong assumption on the platform 
default locale in the same test case with 7196799, I just combined two 
fixes in one changeset. The code changes for 7197573 remain intact.

The combined new webrev is located at:

http://cr.openjdk.java.net/~naoto/7196799/webrev.01/

Naoto

On 9/10/12 4:50 PM, Naoto Sato wrote:
> Hello,
>
> Please review the proposed fix for the subject bug:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7196799
>
> The webrev for the fix is located at:
>
> http://cr.openjdk.java.net/~naoto/7196799/webrev.00/
>
> The fix is basically limit the implicit fallback to JRE's locale data
> only for the root locale, in order to honor the CLDR's fallback.
>
> Naoto


From yiming.wang at oracle.com  Thu Sep 13 00:26:36 2012
From: yiming.wang at oracle.com (Eric Wang)
Date: Thu, 13 Sep 2012 15:26:36 +0800
Subject: <i18n dev> [PATCH] Review Request: Add bug 7196199 into ProblemList
Message-ID: <50518AAC.3020203@oracle.com>

Hi,

We want to add the bug 7196199 
<http://monaco.us.oracle.com/detail.jsf?cr=7196199> into 
ProblemList.txt. Can you please be my sponsor to review the patch 
attached and push it into repo if it is OK?

Thanks,
Eric
-------------- next part --------------
diff -r f8c1cf072ba6 test/ProblemList.txt
--- a/test/ProblemList.txt	Wed Sep 12 15:21:46 2012 -0400
+++ b/test/ProblemList.txt	Thu Sep 13 15:09:05 2012 +0800
@@ -348,6 +348,8 @@
 
 # jdk_text
 
+# 7196199
+java/text/Bidi/Bug6665028.java                                  generic-all
 ############################################################################
 
 # jdk_tools

From naoto.sato at oracle.com  Thu Sep 13 13:23:35 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 13 Sep 2012 13:23:35 -0700
Subject: <i18n dev> [PATCH] Review Request: Add bug 7196199 into
	ProblemList
In-Reply-To: <50518AAC.3020203@oracle.com>
References: <50518AAC.3020203@oracle.com>
Message-ID: <505240C7.4010108@oracle.com>

Hi Eric,

I can be your sponsor, but have one question. Looking at the bug report, 
the bug is only reproducible on solaris/linux x86. Does it have to 
disable the test on all the platforms with "generic-all"?

Naoto

On 9/13/12 12:26 AM, Eric Wang wrote:
> Hi,
>
> We want to add the bug 7196199
> <http://monaco.us.oracle.com/detail.jsf?cr=7196199> into
> ProblemList.txt. Can you please be my sponsor to review the patch
> attached and push it into repo if it is OK?
>
> Thanks,
> Eric


From yiming.wang at oracle.com  Thu Sep 13 18:35:42 2012
From: yiming.wang at oracle.com (Eric Wang)
Date: Fri, 14 Sep 2012 09:35:42 +0800
Subject: <i18n dev> [PATCH] Review Request: Add bug 7196199 into
	ProblemList
In-Reply-To: <505240C7.4010108@oracle.com>
References: <50518AAC.3020203@oracle.com> <505240C7.4010108@oracle.com>
Message-ID: <505289EE.5090105@oracle.com>

Hi Naoto,

Thank you to be my sponsor. I have checked the nightly results, this 
error also occurred on Linux as well.
http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=98081.CORELIBS-JDK8-NIGHTLY-JTREG-16

Thanks,
Eric
On 2012/9/14 4:23, Naoto Sato wrote:
> Hi Eric,
>
> I can be your sponsor, but have one question. Looking at the bug 
> report, the bug is only reproducible on solaris/linux x86. Does it 
> have to disable the test on all the platforms with "generic-all"?
>
> Naoto
>
> On 9/13/12 12:26 AM, Eric Wang wrote:
>> Hi,
>>
>> We want to add the bug 7196199
>> <http://monaco.us.oracle.com/detail.jsf?cr=7196199> into
>> ProblemList.txt. Can you please be my sponsor to review the patch
>> attached and push it into repo if it is OK?
>>
>> Thanks,
>> Eric
>


From naoto.sato at oracle.com  Thu Sep 13 23:40:44 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 13 Sep 2012 23:40:44 -0700
Subject: <i18n dev> [PATCH] Review Request: Add bug 7196199 into
	ProblemList
In-Reply-To: <505289EE.5090105@oracle.com>
References: <50518AAC.3020203@oracle.com> <505240C7.4010108@oracle.com>
	<505289EE.5090105@oracle.com>
Message-ID: <5052D16C.8040304@oracle.com>

Yes, and not on Windows, Mac, nor 64 bit systems, right?

Naoto

On 9/13/12 6:35 PM, Eric Wang wrote:
> Hi Naoto,
>
> Thank you to be my sponsor. I have checked the nightly results, this
> error also occurred on Linux as well.
> http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=98081.CORELIBS-JDK8-NIGHTLY-JTREG-16
>
>
> Thanks,
> Eric
> On 2012/9/14 4:23, Naoto Sato wrote:
>> Hi Eric,
>>
>> I can be your sponsor, but have one question. Looking at the bug
>> report, the bug is only reproducible on solaris/linux x86. Does it
>> have to disable the test on all the platforms with "generic-all"?
>>
>> Naoto
>>
>> On 9/13/12 12:26 AM, Eric Wang wrote:
>>> Hi,
>>>
>>> We want to add the bug 7196199
>>> <http://monaco.us.oracle.com/detail.jsf?cr=7196199> into
>>> ProblemList.txt. Can you please be my sponsor to review the patch
>>> attached and push it into repo if it is OK?
>>>
>>> Thanks,
>>> Eric
>>
>


From Alan.Bateman at oracle.com  Fri Sep 14 02:29:09 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 14 Sep 2012 10:29:09 +0100
Subject: <i18n dev> [PATCH] Review Request: Add bug 7196199 into
	ProblemList
In-Reply-To: <505289EE.5090105@oracle.com>
References: <50518AAC.3020203@oracle.com> <505240C7.4010108@oracle.com>
	<505289EE.5090105@oracle.com>
Message-ID: <5052F8E5.3050605@oracle.com>

On 14/09/2012 02:35, Eric Wang wrote:
> Hi Naoto,
>
> Thank you to be my sponsor. I have checked the nightly results, this 
> error also occurred on Linux as well.
> http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=98081.CORELIBS-JDK8-NIGHTLY-JTREG-16 
>
These links are Oracle internal links and so aren't accessible here. It 
might be better to just inline the .jtr file in the mail so that others 
can see the test failure too.

Anyway, from a quick read of the bug reports then this looks like an 
issue in the vectorization support that was added to C2 in hs24-b21. It 
looks like it doesn't reproduce with hs24-b22 but more investigation is 
required. As hs24-b22 is in jdk8/jdk8 then I should we get jdk8/tl 
sync'ed up to see if this issue goes away (leaving 7196199 open of 
course as cause is not clear yet).

Lana - jdk8/tl is currently at jdk8-b54, do you plan to sync it up to 
b56 soon?

In any case, you were right to propose adding the test to the exclude 
list. I see Naoto questions "generic-all" and that is a good topic to 
discuss. In this case the issue seems to be specific to C2 on x86 but 
that is too fine grained for the platform matching that jtreg supports. 
As I understand it, jtreg can only exclude tests that match the 
operating system name and architecture. For such cases I would tend to 
just add the test with "generic-all", otherwise you are into multi-lines 
excludes trying to exclude everywhere except sparc in this case.

-Alan







From naoto.sato at oracle.com  Fri Sep 14 09:38:00 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 14 Sep 2012 09:38:00 -0700
Subject: <i18n dev> [PATCH] Review Request: Add bug 7196199 into
	ProblemList
In-Reply-To: <5052F8E5.3050605@oracle.com>
References: <50518AAC.3020203@oracle.com> <505240C7.4010108@oracle.com>
	<505289EE.5090105@oracle.com> <5052F8E5.3050605@oracle.com>
Message-ID: <50535D68.6010009@oracle.com>

On 9/14/12 2:29 AM, Alan Bateman wrote:
> In any case, you were right to propose adding the test to the exclude
> list. I see Naoto questions "generic-all" and that is a good topic to
> discuss. In this case the issue seems to be specific to C2 on x86 but
> that is too fine grained for the platform matching that jtreg supports.
> As I understand it, jtreg can only exclude tests that match the
> operating system name and architecture. For such cases I would tend to
> just add the test with "generic-all", otherwise you are into multi-lines
> excludes trying to exclude everywhere except sparc in this case.

I questioned this because of the following comment line in ProblemList.txt

# More than one label is allowed but must be on the same line.

Which suggests that we could express the line like,

java/text/Bidi/Bug6665028.java solaris-all linux-all

But I could not find any detail about the syntax other than the above 
comment line for multiple labels, and there is no precedent in the 
actual list, I am not sure we could do this. In that case, I am fine 
with "generic-all"

Naoto



From Alan.Bateman at oracle.com  Sat Sep 15 03:41:10 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 15 Sep 2012 11:41:10 +0100
Subject: <i18n dev> [PATCH] Review Request: Add bug 7196199 into
	ProblemList
In-Reply-To: <50535D68.6010009@oracle.com>
References: <50518AAC.3020203@oracle.com> <505240C7.4010108@oracle.com>
	<505289EE.5090105@oracle.com> <5052F8E5.3050605@oracle.com>
	<50535D68.6010009@oracle.com>
Message-ID: <50545B46.6070902@oracle.com>

On 14/09/2012 17:38, Naoto Sato wrote:
>
> I questioned this because of the following comment line in 
> ProblemList.txt
>
> # More than one label is allowed but must be on the same line.
>
> Which suggests that we could express the line like,
>
> java/text/Bidi/Bug6665028.java solaris-all linux-all
>
> But I could not find any detail about the syntax other than the above 
> comment line for multiple labels, and there is no precedent in the 
> actual list, I am not sure we could do this. In that case, I am fine 
> with "generic-all"
>
> Naoto
As it happens I had a failure with hs24-b22 so I think it should be 
excluded until the fix gets to jdk8/jdk8 at least. I see Vladimir has a 
review in progress:

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-September/008408.html

so I don't expect it will need to be excluded for long.

On the syntax then I agree it is not clear, I think this may be because 
the Makefile used to originally process the file for jtreg but now jtreg 
can consume it directly. So where you want to exclude on more than more 
specific platform then we use more than one line, here's an example from 
the current tip:

sun/security/pkcs11/ec/TestECDSA.java                           solaris-all
sun/security/pkcs11/ec/TestECDSA.java                           linux-all

but for the Bidi test then I don't think this worth it and "generic-all" 
should be fine.

-Alan.





From joe.darcy at oracle.com  Sun Sep 16 08:34:37 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 16 Sep 2012 08:34:37 -0700
Subject: <i18n dev> Review Request for CR : 7050528 Improve performance
 of java.text.DecimalFormat.format() call stack
In-Reply-To: <5050C41C.8010009@oracle.com>
References: <5050C41C.8010009@oracle.com>
Message-ID: <5055F18D.9030605@oracle.com>

Looks fine; approved.

Thanks,

-Joe

On 9/12/2012 10:19 AM, Olivier Lagneau wrote:
> Please review The implementation of a fast-path algorithm for 
> optimizing the DecimalFormat.format(double, ...) call stack.
>
> The webrev is here :
> http://cr.openjdk.java.net/~olagneau/7050528/webrev.02/
>
> As described in the CR evaluation and suggested fix, the speed-up on a 
> dedicated micro-benchmark
> is more than x10 on either SPARC or x86 architectures. The footprint 
> cost is ~6kbytes from a static
> char array constant data to collect digits from integer values.
>
> There is an associated regression test, together with a 
> micro-benchmark that may be run optionally.
>


From naoto.sato at oracle.com  Mon Sep 17 14:53:28 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 17 Sep 2012 14:53:28 -0700
Subject: <i18n dev> [PATCH] Review Request: Add bug 7196199 into
	ProblemList
In-Reply-To: <50545B46.6070902@oracle.com>
References: <50518AAC.3020203@oracle.com> <505240C7.4010108@oracle.com>
	<505289EE.5090105@oracle.com> <5052F8E5.3050605@oracle.com>
	<50535D68.6010009@oracle.com> <50545B46.6070902@oracle.com>
Message-ID: <50579BD8.2050700@oracle.com>

OK, I filed a CR 7198984 for this and intend to push Eric's fix as it 
is. Alan, will you be a reviewer for this?

Naoto

On 9/15/12 3:41 AM, Alan Bateman wrote:
> On 14/09/2012 17:38, Naoto Sato wrote:
>>
>> I questioned this because of the following comment line in
>> ProblemList.txt
>>
>> # More than one label is allowed but must be on the same line.
>>
>> Which suggests that we could express the line like,
>>
>> java/text/Bidi/Bug6665028.java solaris-all linux-all
>>
>> But I could not find any detail about the syntax other than the above
>> comment line for multiple labels, and there is no precedent in the
>> actual list, I am not sure we could do this. In that case, I am fine
>> with "generic-all"
>>
>> Naoto
> As it happens I had a failure with hs24-b22 so I think it should be
> excluded until the fix gets to jdk8/jdk8 at least. I see Vladimir has a
> review in progress:
>
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-September/008408.html
>
>
> so I don't expect it will need to be excluded for long.
>
> On the syntax then I agree it is not clear, I think this may be because
> the Makefile used to originally process the file for jtreg but now jtreg
> can consume it directly. So where you want to exclude on more than more
> specific platform then we use more than one line, here's an example from
> the current tip:
>
> sun/security/pkcs11/ec/TestECDSA.java solaris-all
> sun/security/pkcs11/ec/TestECDSA.java linux-all
>
> but for the Bidi test then I don't think this worth it and "generic-all"
> should be fine.
>
> -Alan.
>
>
>
>


From Alan.Bateman at oracle.com  Tue Sep 18 01:40:00 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 18 Sep 2012 09:40:00 +0100
Subject: <i18n dev> [PATCH] Review Request: Add bug 7196199 into
	ProblemList
In-Reply-To: <50579BD8.2050700@oracle.com>
References: <50518AAC.3020203@oracle.com> <505240C7.4010108@oracle.com>
	<505289EE.5090105@oracle.com> <5052F8E5.3050605@oracle.com>
	<50535D68.6010009@oracle.com> <50545B46.6070902@oracle.com>
	<50579BD8.2050700@oracle.com>
Message-ID: <50583360.9060304@oracle.com>

On 17/09/2012 22:53, Naoto Sato wrote:
> OK, I filed a CR 7198984 for this and intend to push Eric's fix as it 
> is. Alan, will you be a reviewer for this?
>
> Naoto
That's fine.

-Alan

From sean.coffey at oracle.com  Tue Sep 18 10:37:47 2012
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Tue, 18 Sep 2012 18:37:47 +0100
Subject: <i18n dev> [7u10] Request for approval: 7174233: Openjdk is
 missing some key maps on the Japanese keyboards
In-Reply-To: <5056CC4C.3010501@linux.vnet.ibm.com>
References: <5056CC4C.3010501@linux.vnet.ibm.com>
Message-ID: <5058B16B.8060609@oracle.com>

cc'ing i18n-dev alias here also. i18n fixes can be difficult to test. 
Was it possible to verify this fix on jdk7u Shi Jun ?

Any thoughts from i18n reviewers on this one being backported to 7u ?

regards,
Sean.

On 17/09/2012 08:07, Shi Jun Zhang wrote:
> Hi all,
>
> I'd like to request for approval to push the following change into 7u10.
>
> Changeset in jdk8
> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6694d9e99716
>
> Webrev
> http://cr.openjdk.java.net/~zhangshj/jdk7u/7174233/webrev.00/
>
> Reviewed by anthony, naoto
>
> Review thread
> http://mail.openjdk.java.net/pipermail/awt-dev/2012-June/002919.html
>


From naoto.sato at oracle.com  Tue Sep 18 11:03:35 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 18 Sep 2012 11:03:35 -0700
Subject: <i18n dev> [PATCH] Review Request: Add bug 7196199 into
	ProblemList
In-Reply-To: <50583360.9060304@oracle.com>
References: <50518AAC.3020203@oracle.com> <505240C7.4010108@oracle.com>
	<505289EE.5090105@oracle.com> <5052F8E5.3050605@oracle.com>
	<50535D68.6010009@oracle.com> <50545B46.6070902@oracle.com>
	<50579BD8.2050700@oracle.com> <50583360.9060304@oracle.com>
Message-ID: <5058B777.1070509@oracle.com>

The fix has been pushed to T/L repository.

Naoto

On 9/18/12 1:40 AM, Alan Bateman wrote:
> On 17/09/2012 22:53, Naoto Sato wrote:
>> OK, I filed a CR 7198984 for this and intend to push Eric's fix as it
>> is. Alan, will you be a reviewer for this?
>>
>> Naoto
> That's fine.
>
> -Alan


From naoto.sato at oracle.com  Tue Sep 18 12:11:37 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 18 Sep 2012 12:11:37 -0700
Subject: <i18n dev> [7u10] Request for approval: 7174233: Openjdk is
 missing some key maps on the Japanese keyboards
In-Reply-To: <5058B16B.8060609@oracle.com>
References: <5056CC4C.3010501@linux.vnet.ibm.com> <5058B16B.8060609@oracle.com>
Message-ID: <5058C769.2050005@oracle.com>

While I think fix looks good (that's why I approved the change in jdk8), 
I don't find any reason for backporting this change into 7u line. Is 
there any strong reason for backport?

Naoto

On 9/18/12 10:37 AM, Se?n Coffey wrote:
> cc'ing i18n-dev alias here also. i18n fixes can be difficult to test.
> Was it possible to verify this fix on jdk7u Shi Jun ?
>
> Any thoughts from i18n reviewers on this one being backported to 7u ?
>
> regards,
> Sean.
>
> On 17/09/2012 08:07, Shi Jun Zhang wrote:
>> Hi all,
>>
>> I'd like to request for approval to push the following change into 7u10.
>>
>> Changeset in jdk8
>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6694d9e99716
>>
>> Webrev
>> http://cr.openjdk.java.net/~zhangshj/jdk7u/7174233/webrev.00/
>>
>> Reviewed by anthony, naoto
>>
>> Review thread
>> http://mail.openjdk.java.net/pipermail/awt-dev/2012-June/002919.html
>>
>


From naoto.sato at oracle.com  Thu Sep 20 15:25:40 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 20 Sep 2012 15:25:40 -0700
Subject: <i18n dev> [8] Review request for CR 7196799: CLDR adapter can
 not be invoked when region code is specified in Locale
In-Reply-To: <505104BF.5090501@oracle.com>
References: <504E7CAD.2010800@oracle.com> <505104BF.5090501@oracle.com>
Message-ID: <505B97E4.7000805@oracle.com>

I revised the fix again to catch up with the internal comments, i.e., 
correcting the behavior when a bogus adapter is specified, it won't fall 
back to JRE locale data. The revised webrev is located here:

http://cr.openjdk.java.net/~naoto/7196799/webrev.02/

Naoto

On 9/12/12 2:55 PM, Naoto Sato wrote:
> I updated the webrev to include another fix to a test bug:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197573
>
> Since the fix is to correct some wrong assumption on the platform
> default locale in the same test case with 7196799, I just combined two
> fixes in one changeset. The code changes for 7197573 remain intact.
>
> The combined new webrev is located at:
>
> http://cr.openjdk.java.net/~naoto/7196799/webrev.01/
>
> Naoto
>
> On 9/10/12 4:50 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the proposed fix for the subject bug:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7196799
>>
>> The webrev for the fix is located at:
>>
>> http://cr.openjdk.java.net/~naoto/7196799/webrev.00/
>>
>> The fix is basically limit the implicit fallback to JRE's locale data
>> only for the root locale, in order to honor the CLDR's fallback.
>>
>> Naoto
>


From yuka.kamiya at oracle.com  Thu Sep 27 15:19:30 2012
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Fri, 28 Sep 2012 07:19:30 +0900
Subject: <i18n dev> Review request: 7069824: Support for BCP47 locale
	matching
Message-ID: <5064D0F2.4060406@oracle.com>

Hi,

Please review the change for BCP 47 locale matching.

http://cr.openjdk.java.net/~peytoia/7069824/webrev.00/
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7069824

Thanks,
--
Yuka

From yuka.kamiya at oracle.com  Thu Sep 27 20:14:10 2012
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Fri, 28 Sep 2012 12:14:10 +0900
Subject: <i18n dev> Review request: 7069824: Support for BCP47 locale
	matching
In-Reply-To: <5064D0F2.4060406@oracle.com>
References: <5064D0F2.4060406@oracle.com>
Message-ID: <50651602.8040209@oracle.com>

Updated based on internal comments.

  http://cr.openjdk.java.net/~peytoia/7069824/webrev.01/

Thanks,
--
Yuka

(12/09/28 7:19), Yuka Kamiya wrote:
> Hi,
> 
> Please review the change for BCP 47 locale matching.
> 
> http://cr.openjdk.java.net/~peytoia/7069824/webrev.00/
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7069824
> 
> Thanks,
> --
> Yuka
> 

From masayoshi.okutsu at oracle.com  Thu Sep 27 21:43:56 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 28 Sep 2012 13:43:56 +0900
Subject: <i18n dev> Review request: 7069824: Support for BCP47 locale
 matching
In-Reply-To: <50651602.8040209@oracle.com>
References: <5064D0F2.4060406@oracle.com> <50651602.8040209@oracle.com>
Message-ID: <50652B0C.9020306@oracle.com>

Looks good to me.

Masayoshi

On 9/28/2012 12:14 PM, Yuka Kamiya wrote:
> Updated based on internal comments.
>
>   http://cr.openjdk.java.net/~peytoia/7069824/webrev.01/
>
> Thanks,
> --
> Yuka
>
> (12/09/28 7:19), Yuka Kamiya wrote:
>> Hi,
>>
>> Please review the change for BCP 47 locale matching.
>>
>> http://cr.openjdk.java.net/~peytoia/7069824/webrev.00/
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7069824
>>
>> Thanks,
>> --
>> Yuka
>>