 {@code ... } 
 (originally ) to {@code
- Replaced StringTokenizer with String.split()
- Eliminated RuntimeException

Thanks,
Masayoshi

On 7/23/2014 8:12 AM, Masayoshi Okutsu wrote:
> Thank you for catching it! I forgot to restore "return null;".
>
> Masayoshi
>
> On 7/23/2014 3:44 AM, Naoto Sato wrote:
>> Okutsu-san,
>>
>> I have one question. It looks like if the user specifies the 
>> additional era syntactically incorrect, it throws a RuntimeException. 
>> Should it just be ignored, as the spec reads "If the given era is 
>> invalid, such as the since value before the beginning of the last 
>> predefined era, the given era will be ignored"?
>>
>> Naoto
>>
>> On 7/22/14, 12:06 AM, Masayoshi Okutsu wrote:
>>> Hello,
>>>
>>> Please review the change for JDK-8048123. This change removes all the
>>> era definitions in ${java.home}/lib/calendars.properties. (The property
>>> file will eventually be gone later.) The major change is that any new
>>> era of the Japanese calendar should now be defined using new property
>>> "jdk.calendar.japanese.supplemental.era".
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8048123
>>>
>>> Webrev includes some unrelated cleanups.
>>>
>>> http://cr.openjdk.java.net/~okutsu/9/8048123/webrev.00/
>>>
>>> Thanks,
>>> Masayoshi
>

From Alan.Bateman at oracle.com  Wed Jul 23 13:23:11 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Jul 2014 14:23:11 +0100
Subject:  [9] RFR: 8048123: Replace calendars.properties with
 another mechanism to specify a new Japanese calendar era
In-Reply-To: <53CF7668.4070104@oracle.com>
References: <53CE0D8C.7060803@oracle.com>
	<53CEB102.3000705@oracle.com>	<53CEEFD3.8070106@oracle.com>
	<53CF7668.4070104@oracle.com>
Message-ID: <53CFB73F.7080507@oracle.com>

On 23/07/2014 09:46, Masayoshi Okutsu wrote:
> Revised the webrev:
> http://cr.openjdk.java.net/~okutsu/9/8048123/webrev.01
>
> The changes from the previous one are:
> - Changed  (originally ) to {@code
> - Replaced StringTokenizer with String.split()
> - Eliminated RuntimeException
The use of {@code ..} and replacing the usage of StringTokenizer look 
good me.

I'm not so sure about silently ignoring errors in the property value, 
mostly because it would lead to incorrect behavior that is likely to be 
very difficult to track down. If there area used logging then there 
might be some hope of finding it but this isn't the case.

-Alan

From naoto.sato at oracle.com  Wed Jul 23 16:44:00 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 23 Jul 2014 09:44:00 -0700
Subject:  [9] RFR: 8048123: Replace calendars.properties with
 another mechanism to specify a new Japanese calendar era
In-Reply-To: <53CFB73F.7080507@oracle.com>
References: <53CE0D8C.7060803@oracle.com>	<53CEB102.3000705@oracle.com>	<53CEEFD3.8070106@oracle.com>	<53CF7668.4070104@oracle.com>
	<53CFB73F.7080507@oracle.com>
Message-ID: <53CFE650.20605@oracle.com>

Although I believe the incorrect behavior would be very obvious ("era" 
specified in the property would simply be not used), I would agree the 
failed property be better logged.

Naoto

On 7/23/14, 6:23 AM, Alan Bateman wrote:
> On 23/07/2014 09:46, Masayoshi Okutsu wrote:
>> Revised the webrev:
>> http://cr.openjdk.java.net/~okutsu/9/8048123/webrev.01
>>
>> The changes from the previous one are:
>> - Changed  (originally ) to {@code
>> - Replaced StringTokenizer with String.split()
>> - Eliminated RuntimeException
> The use of {@code ..} and replacing the usage of StringTokenizer look
> good me.
>
> I'm not so sure about silently ignoring errors in the property value,
> mostly because it would lead to incorrect behavior that is likely to be
> very difficult to track down. If there area used logging then there
> might be some hope of finding it but this isn't the case.
>
> -Alan

From masayoshi.okutsu at oracle.com  Thu Jul 24 00:35:27 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 24 Jul 2014 09:35:27 +0900
Subject:  [9] RFR: 8048123: Replace calendars.properties with
 another mechanism to specify a new Japanese calendar era
In-Reply-To: <53CFE650.20605@oracle.com>
References: <53CE0D8C.7060803@oracle.com>	<53CEB102.3000705@oracle.com>	<53CEEFD3.8070106@oracle.com>	<53CF7668.4070104@oracle.com>	<53CFB73F.7080507@oracle.com>
	<53CFE650.20605@oracle.com>
Message-ID: <53D054CF.5010309@oracle.com>

The expected property usage, which hasn't changed from the properties 
file, is that we will provide the correct property value of any new era 
probably with a test program which will verify the given values. For JDK 
6 to 8, the updated property file will need to be provided by us with a 
test program. I don't expect that users regularly and randomly define 
their own eras. The Japanese government defines eras by decrees [1][2].

I could change the spec, which requires another CCC cycle, and add error 
logging. But I believe that's overkill for the functionality and its 
usage (basically only once every several ten years for the limited 
number of users). In addition, the syntax isn't complicated at all. And 
if any wrong values are given, such as a typo in the given name, there 
will be no way to detect it in the API anyway.

BTW, I tend to avoid use of logging (and some other APIs) in the 
date-time API. It could create inter dependencies leading to an infinite 
loop to use some APIs from the date-time API. IIRC Sherman and I have 
worked on such bug reports. It's far more difficult to diagnose inter 
dependencies than syntax errors of the simple property value.

If it's necessary to report any syntax errors, I think throwing an 
exception should be a solution. So, should I start over from the spec?

Thanks,
Masayoshi

[1] http://law.e-gov.go.jp/htmldata/S64/S64SE001.html
[2] http://www.mext.go.jp/b_menu/hakusho/nc/k19890107001/k19890107001.html

On 7/24/2014 1:44 AM, Naoto Sato wrote:
> Although I believe the incorrect behavior would be very obvious ("era" 
> specified in the property would simply be not used), I would agree the 
> failed property be better logged.
>
> Naoto
>
> On 7/23/14, 6:23 AM, Alan Bateman wrote:
>> On 23/07/2014 09:46, Masayoshi Okutsu wrote:
>>> Revised the webrev:
>>> http://cr.openjdk.java.net/~okutsu/9/8048123/webrev.01
>>>
>>> The changes from the previous one are:
>>> - Changed  (originally ) to {@code
>>> - Replaced StringTokenizer with String.split()
>>> - Eliminated RuntimeException
>> The use of {@code ..} and replacing the usage of StringTokenizer look
>> good me.
>>
>> I'm not so sure about silently ignoring errors in the property value,
>> mostly because it would lead to incorrect behavior that is likely to be
>> very difficult to track down. If there area used logging then there
>> might be some hope of finding it but this isn't the case.
>>
>> -Alan

From naoto.sato at oracle.com  Tue Jul 29 17:17:12 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 29 Jul 2014 10:17:12 -0700
Subject:  [9] RFR: JDK-8048515: Read outside array bounds in
	jdk/src/solaris/native/java/lang/java_props_md.c
Message-ID: <53D7D718.8000303@oracle.com>

Okutsu-san,

Please approve this retroactive fix on this open alias, in order for 
backporting the fix into 8u release. Changeset is here and is already 
integrated per the previous review.

http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2b7bf1d63a9c

Naoto

From masayoshi.okutsu at oracle.com  Tue Jul 29 22:54:43 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 30 Jul 2014 07:54:43 +0900
Subject:  [9] RFR: JDK-8048515: Read outside array bounds in
	jdk/src/solaris/native/java/lang/java_props_md.c
In-Reply-To: <53D7D718.8000303@oracle.com>
References: <53D7D718.8000303@oracle.com>
Message-ID: <53D82633.1040003@oracle.com>

Approved.

Masayoshi

On 7/30/2014 2:17 AM, Naoto Sato wrote:
> Okutsu-san,
>
> Please approve this retroactive fix on this open alias, in order for 
> backporting the fix into 8u release. Changeset is here and is already 
> integrated per the previous review.
>
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2b7bf1d63a9c
>
> Naoto

From masayoshi.okutsu at oracle.com  Thu Jul 31 14:16:37 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 31 Jul 2014 23:16:37 +0900
Subject:  [9] RFR: 8048123: Replace calendars.properties with
 another mechanism to specify a new Japanese calendar era
In-Reply-To: <53D054CF.5010309@oracle.com>
References: <53CE0D8C.7060803@oracle.com>	<53CEB102.3000705@oracle.com>	<53CEEFD3.8070106@oracle.com>	<53CF7668.4070104@oracle.com>	<53CFB73F.7080507@oracle.com>	<53CFE650.20605@oracle.com>
	<53D054CF.5010309@oracle.com>
Message-ID: <53DA4FC5.4070700@oracle.com>

I've decided to follow the current spec -- ignoring any invalid property 
values. This way applications can still run without removing the 
property even after installing a fixed update release.

Thanks,
Masayoshi

On 7/24/2014 9:35 AM, Masayoshi Okutsu wrote:
> The expected property usage, which hasn't changed from the properties 
> file, is that we will provide the correct property value of any new 
> era probably with a test program which will verify the given values. 
> For JDK 6 to 8, the updated property file will need to be provided by 
> us with a test program. I don't expect that users regularly and 
> randomly define their own eras. The Japanese government defines eras 
> by decrees [1][2].
>
> I could change the spec, which requires another CCC cycle, and add 
> error logging. But I believe that's overkill for the functionality and 
> its usage (basically only once every several ten years for the limited 
> number of users). In addition, the syntax isn't complicated at all. 
> And if any wrong values are given, such as a typo in the given name, 
> there will be no way to detect it in the API anyway.
>
> BTW, I tend to avoid use of logging (and some other APIs) in the 
> date-time API. It could create inter dependencies leading to an 
> infinite loop to use some APIs from the date-time API. IIRC Sherman 
> and I have worked on such bug reports. It's far more difficult to 
> diagnose inter dependencies than syntax errors of the simple property 
> value.
>
> If it's necessary to report any syntax errors, I think throwing an 
> exception should be a solution. So, should I start over from the spec?
>
> Thanks,
> Masayoshi
>
> [1] http://law.e-gov.go.jp/htmldata/S64/S64SE001.html
> [2] 
> http://www.mext.go.jp/b_menu/hakusho/nc/k19890107001/k19890107001.html
>
> On 7/24/2014 1:44 AM, Naoto Sato wrote:
>> Although I believe the incorrect behavior would be very obvious 
>> ("era" specified in the property would simply be not used), I would 
>> agree the failed property be better logged.
>>
>> Naoto
>>
>> On 7/23/14, 6:23 AM, Alan Bateman wrote:
>>> On 23/07/2014 09:46, Masayoshi Okutsu wrote:
>>>> Revised the webrev:
>>>> http://cr.openjdk.java.net/~okutsu/9/8048123/webrev.01
>>>>
>>>> The changes from the previous one are:
>>>> - Changed  (originally ) to {@code
>>>> - Replaced StringTokenizer with String.split()
>>>> - Eliminated RuntimeException
>>> The use of {@code ..} and replacing the usage of StringTokenizer look
>>> good me.
>>>
>>> I'm not so sure about silently ignoring errors in the property value,
>>> mostly because it would lead to incorrect behavior that is likely to be
>>> very difficult to track down. If there area used logging then there
>>> might be some hope of finding it but this isn't the case.
>>>
>>> -Alan
>

From tanin47 at yahoo.com  Fri Jul 11 21:25:53 2014
From: tanin47 at yahoo.com (Tanin Na Nakorn)
Date: Fri, 11 Jul 2014 21:25:53 -0000
Subject:  How is thai_dict generated?
Message-ID: <1405113951.82017.YahooMailNeo@web140303.mail.bf1.yahoo.com>

Hi All,

I would like to understand how BreakIterator for Thai language works and am stuck at the file thai_dict.

I would like to learn how it is generated. Here is the file:?https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/sun/text/resources/thai_dict

Also, where is the code that generates this file? Where is the original data source for it?

Please help me.

Thank you,
Tanin Na Nakorn