Re: RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era

[Masayoshi Okutsu]

Thank you for the review comments. I realized that only TextStyle.NARROW 
and NARROW_STANDALONE should return the abbreviation to be consistent 
with locale data. I've changed the implementation, which should have 
"fixed" the NPE issue, and added more test cases.


Revised webrev:
http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.01/

While I was testing more, I realized the default implementation of 
Era.getDisplayName doesn't work with non-IsoChronology. I filed new bug 
report JDK-8171049.


Thanks,
Masayoshi

On 12/8/2016 5:55 PM, Masayoshi Okutsu wrote:

Hi,

Please review the fix for JDK-8054214. It was necessary to override 
Era::getDisplayName to get era names from the specified property. This 
one fixes getAbbreviation() as well.


Issue:
https://bugs.openjdk.java.net/browse/JDK-8054214

Webrev:
http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.00/

Thanks,
Masayoshi

RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era

[Masayoshi Okutsu]

Hi,

Please review the fix for JDK-8054214. It was necessary to override 
Era::getDisplayName to get era names from the specified property. This 
one fixes getAbbreviation() as well.


Issue:
https://bugs.openjdk.java.net/browse/JDK-8054214

Webrev:
http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.00/

Thanks,
Masayoshi

Re: RFR: JDK-8075577: java.time does not support HOST provider

[Masayoshi Okutsu]

Looks good to me.

Masayoshi


On 11/22/2016 6:30 PM, Rachna Goel wrote:

Hi,

Please review fix for JDK-8075577.

Bug : https://bugs.openjdk.java.net/browse/JDK-8075577

webrev : http://cr.openjdk.java.net/~rgoel/JDK-8075577/webrev.01/

Fix is to introduce new private spi 
"sun.text.spi.JavaTimeDateTimePatternProvider.java"  to retrieve 
LocaleProvider specific Date/Time Patterns for "java.time" .


Thanks,
Rachna

Re: RFR: 8169191: (tz) Support tzdata2016j

[Masayoshi Okutsu]

Sorry, but I was confused with the wrong bug ID in Subject...

Looks good to me.

Masayoshi


On 11/29/2016 4:28 AM, Martin Buchholz wrote:

Thanks as always for keeping the tzdata pipeline moving!
Looks good to me.

On Mon, Nov 28, 2016 at 1:24 AM, Ramanand Patil 
wrote:


Hi all,
Please review the latest TZDATA integration (tzdata2016j) to JDK9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8170316
Webrev: http://cr.openjdk.java.net/~rpatil/8170316/webrev.00/

All the TimeZone related tests are passed after integration.

Regards,
Ramanand.

Re: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module

[Masayoshi Okutsu]

+1

Masayoshi


On 11/15/2016 1:07 AM, Naoto Sato wrote:

+1

Naoto

On 11/13/16 11:12 PM, Rachna Goel wrote:

Hi,

Kindly review fix for JDK-8168906.
https://bugs.openjdk.java.net/browse/JDK-8168906

Patch :http://cr.openjdk.java.net/~rgoel/JDK-8168906/webrev/

fix: As jdk.localedata module does read any system properties, tightened
permissions for same.

Thanks,
Rachna

Re: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module

[Masayoshi Okutsu]

test/sun/util/locale/provider/Bug8152817.java is a test with a 
SecurityManager. I18n SQE should have some.


Masayoshi


On 11/14/2016 11:59 PM, Sean Mullan wrote:
Looks good. Are there any regression tests for this component that run 
with a SecurityManager? If not, it would be useful to add some to 
ensure that the proper permissions are being granted to this module.


--Sean

On 11/14/16 2:27 AM, Rachna Goel wrote:

sorry, correction to typo

As jdk.localedata module does  *not* read any system properties,
tightened permissions for same.


On 14/11/16 12:42 PM, Rachna Goel wrote:

Hi,

Kindly review fix for JDK-8168906.
https://bugs.openjdk.java.net/browse/JDK-8168906

Patch :http://cr.openjdk.java.net/~rgoel/JDK-8168906/webrev/

fix: As jdk.localedata module does read any system properties,
tightened permissions for same.

Thanks,
Rachna

Re: RFR: jdk8u-dev Backport of 8169191: (tz) Support tzdata2016i

[Masayoshi Okutsu]

+1


On 11/11/2016 1:48 AM, Martin Buchholz wrote:

Looks good!

On Thu, Nov 10, 2016 at 1:48 AM, Ramanand Patil 
wrote:


Hi all,
Please review the latest TZDATA integration (tzdata2016i) to JDK8U.
Since tzdata is cumulative, this bug fix backports both the tzdata
versions(tzdata2016h+tzdata2016i) into jdk8u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8169191
Webrev: http://cr.openjdk.java.net/~rpatil/8169537/webrev.00/

Jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7f7091c1dd33

For reference:
Jdk9 changeset for tzdata2016h integration(JDK-8168512):
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3192d7aa428d

All the TimeZone related tests are passed after integration.


Regards,
Ramanand.

Re: RFR: 8169191: (tz) Support tzdata2016i

[Masayoshi Okutsu]

+1

On 11/8/2016 1:36 AM, Martin Buchholz wrote:

Looks good to me!

On Mon, Nov 7, 2016 at 2:43 AM, Ramanand Patil 
wrote:


Hi all,
Please review the latest TZDATA integration (tzdata2016i) to JDK9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8169191
Webrev: http://cr.openjdk.java.net/~rpatil/8169191/webrev.00/

All the TimeZone related tests are passed after integration.

Regards,
Ramanand.

Re: RFR: 8168512: (tz) Support tzdata2016h

[Masayoshi Okutsu]

+1

Masayoshi


On 10/24/2016 11:14 PM, Martin Buchholz wrote:

Looks good to me!

On Mon, Oct 24, 2016 at 12:28 AM, Ramanand Patil 
wrote:


Hi all,

Please review the latest TZDATA integration (tzdata2016h) to JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8168512

Webrev: http://cr.openjdk.java.net/~rpatil/8168512/webrev.00/



All the TimeZone related tests are passed after integration.



Regards,

Ramanand.

Re: RFR: JDK-8146750:java.time.Month.getDisplayName() return incorrect narrow names with JRE provider on locale de,de_DE,en_US.

[Masayoshi Okutsu]

Looks good to me.

Masayoshi


On 10/20/2016 5:27 PM, Rachna Goel wrote:

Hi,

Please review fix for JDK-8146750.

Bug : https://bugs.openjdk.java.net/browse/JDK-8146750

webrev : http://cr.openjdk.java.net/~rgoel/JDK-8146750/webrev.09/

Fix is to retrieve Narrow and Narrow_Standalone Month names and Day 
names one by one, as they can be duplicate.


Thanks,

Rachna

Re: RFR: 8166875: (tz) Support tzdata2016g

[Masayoshi Okutsu]

Hi Ramanand,

I don't think it's appropriate to add the bug ID to 
test/sun/util/resources/cldr/Bug8134384.java. This test doesn't verify 
the TimeZoneNames*.java changes of this fix. Otherwise, the change looks 
OK to me.


Thanks,
Masayoshi


On 10/4/2016 7:22 PM, Ramanand Patil wrote:

Hi Martin,
Thank you for your review and explanation of "Yangon". I liked the translation "End 
of Strife".

Looking at the description of the ZoneNames.java:
* The zid<->metazone mappings are based on CLDR metaZones.xml.
  * The alias mappings are based on Link entries in tzdb data files.

I had thought to not update this file because the CLDR metaZones.xml file 
doesn’t have this entry updated.
But I think you are correct, since Link entry has this alias mentioned, there 
is no harm in adding these entries to zidMap and aliasMap arrays.
Here is the updated Webrev: 
http://cr.openjdk.java.net/~rpatil/8166875/webrev.01/

Changes done:
- Updated src/java.base/share/classes/java/time/format/ZoneName.java to include 
"Yangon" entry.
- Removed unused imports from 
src/java.base/share/classes/java/time/format/ZoneName.java
- Updated ZoneName.java in the test package as well to include 
"Yangon". [test/java/time/test/java/time/format/ZoneName.java]
- Updated the bugID for 
test/java/time/test/java/time/format/TestZoneTextPrinterParser.java since this uses the 
"ZoneName.java" defined in test package.

Also, looks like ZoneName.java is trying to maintain a comprehensive list of zone names. Though I found very 
few zone names are missing from this file like: "Europe/Busingen", "America/Fort_Nelson", 
"Antarctica/Troll" etc...


Regards,
Ramanand.

From: Martin Buchholz [mailto:marti...@google.com]
Sent: Monday, October 03, 2016 8:55 PM
To: Ramanand Patil 
Cc: i18n-...@openjdk.java.net; core-libs-dev 
Subject: Re:  RFR: 8166875: (tz) Support tzdata2016g

Hi Ramanand,
Pleased to meet you!

I expected to see Yangon added to ZoneName, because of the existing reference 
to Rangoon

java/time/test/java/time/format/ZoneName.java:179:"Asia/Rangoon", "Myanmar", 
"Asia/Rangoon",

Is ZoneName.java trying to maintain a comprehensive list of zone names?

"""Yangon (ရန်ကုန်) is a combination of the two words yan (ရန်) and koun (ကုန်), which mean "enemies" and 
"run out of", respectively. It is also translated as "End of Strife"."""


On Mon, Oct 3, 2016 at 5:27 AM, Ramanand Patil 
 wrote:
HI all,
Please review the latest TZDATA integration (tzdata2016g) to JDK9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8166875
Webrev: http://cr.openjdk.java.net/~rpatil/8166875/webrev.00/

All the TimeZone related tests are passed after integration.
[BugID is updated for tests TimeZoneTest.java and Bug8134384.java, since they verify the 
renamed TZID "Asia/Yangon"].

Regards,
Ramanand.

Re: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files

[Masayoshi Okutsu]

Looks good to me. Thank you for fixing this bug!

Masayoshi


On 9/13/2016 11:49 PM, Thomas Stüfe wrote:

Hi Christoph, thanks for your review! Yes, I can remove the blank.

Kind Regards, Thomas

On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph 
Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching
timezone info files

Dear all,

please take a look at this small change:

Bug: https://bugs.openjdk.java.net/browse/JDK-8165936
Webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8165936-

Potential-Heap-buffer-

overflow-when-seaching-timezone-info-files/webrev.00/webrev/

readdir_r is used to iterate over the content of a system directory, but
the buffer passed to it is too small: Its size should include the size of
the dirent structure itself (minus the d_name member).

The fix also now checks the return code of pathconf(), and if pathconf()
returns an error, falls back to the NAME_MAX compile time constant.
Finally, it imposes a minimum size for the buffer, because on older

System

V systems NAME_MAX may be surprisingly small and readdir_r will not check
the output buffer size. I think it is better to err on the safe side

here.

Kind Regards, Thomas

Re: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base

[Masayoshi Okutsu]

Is it just a matter of an extra step, new File(path).getName()?

Masayoshi


On 9/9/2016 12:00 AM, Naoto Sato wrote:
Well, actually I tried this approach first, then found out that the 
data files are also used by the GenerateBreakIteratorData build tool 
which has some implicit assumption of the value being the file name 
w/o path. So I ended up with the fix.


Naoto

On 9/8/16 5:46 AM, Alan Bateman wrote:



On 08/09/2016 03:51, Masayoshi Okutsu wrote:

I thought Mandy suggested that the dictionary names in a
ResourceBundle contain path names rather than base names, something
like this:

In BreakIteratorInfo_th.java:

{"WordDictionary", "thai_dict"},
to
{"WordDictionary", "sun/text/resources/ext/thai_dict"},

I haven't checked any side effects of this change, though.

That would be cleaner, assuming it doesn't cause issues.

-Alan

Re: JDK 9 RFR of problem listing of IncludeLocalesPluginTest.java

[Masayoshi Okutsu]

On 6/2/2016 3:31 PM, Alan Bateman wrote:
It's possible that the CLDR update added more languages and pushed 
this test over the edge. Excluding it temporarily should be fine while 
it is tracked down.


The test doesn't detect any failures caused by the additional locales, 
which may or may not be related to this timeout issue.


Masayoshi

Re: RFR: 8151876: (tz) Support tzdata2016d

[Masayoshi Okutsu]

The CheckDisplayNames.java change is different from what I suggested and 
doesn't make sense. But we no longer need the test. I'd suggest 
CheckDisplayNames.java be removed. Otherwise, the fix looks OK to me.


Masayoshi


On 5/31/2016 3:03 AM, Ramanand Patil wrote:


Hi Masayoshi and All,

Here is the updated Webrev: 
http://cr.openjdk.java.net/~rpatil/8151876/webrev.01/ 
<http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.01/>


As suggested by Masayoshi, I have kept the existing names unchanged.


Also, this patch contains extra test case fixes for


1./java/util/TimeZone/CheckDisplayNames.java/


2.java/util/TimeZone/Bug8149452.java

The exclusion for the *newly* added TimeZones is added in these test 
cases where the entries are not present in the resources and the 
Short/Long display names fallback to the GMT±hh:mm format.


Regards,

Ramanand.

*From:*Masayoshi Okutsu
*Sent:* Saturday, May 28, 2016 10:58 AM
*To:* Seán Coffey; Ramanand Patil; i18n-...@openjdk.java.net; 
core-libs-dev@openjdk.java.net

*Subject:* Re: RFR: 8151876: (tz) Support tzdata2016d

CLDR locale data defines time zone names, like this (in en.xml):


 
 Almaty Time
 Almaty Standard 
Time
 Almaty Summer Time
 
 

The CLDR converter tool tries to fill in the missing short names from 
the legacy TimeZoneNames data. Removing existing names causes some 
unexpected behavior. I think JDK-8157814 is an example of the 
unexpected behavior. And the suggested fix in JDK-8157814 looks to me 
like a workaround.


I still think the existing names should be kept unchanged for this fix.

Thanks,
Masayoshi

On 5/28/2016 12:04 AM, Seán Coffey wrote:

I guess there's a low risk of timezone not being identified if
being parsed in through a formatter. Isn't such an approach
discouraged though ? short IDs were already subject to change in
tzdata releases. Ramanand found one issue by removal of these
resource strings (so far) and that's captured in JDK-8157814

There's a decision to be made about how to use the GMT±hh:mm
format for new releases given IANA's new short ID identifier
mechanism. I think that could be discussed as a separate issue.
I'd like to see us follow a similar approach to IANA and use GMT
identifiers on new timezones and perhaps even consider using the
IANA long name format also for the getDisplayName(..) calls that
can be made. e.g. "Asia/Almaty" instead of "Alma-Ata Time"

Regards,

Sean.

On 27/05/16 15:24, Masayoshi Okutsu wrote:

This change seems to beyond my proposal that the "GMT±hh:mm"
format is used for *new* zones with the "±hh" format. But this
change removes *existing* zones which have changed to use the
"±hh" format in tzdata. Can this cause any compatibility issues?

And have we agreed to use the "GMT±hh:mm" format?

Thanks,
Masayoshi


On 5/27/2016 10:19 PM, Seán Coffey wrote:

Looks fine to me Ramanand. the recent 2016d changes have
introduced some boundary issues for JDK rule parsing and those
issues can be followed up in separate issues like you say.

Regards,
Sean.

On 26/05/16 14:22, Ramanand Patil wrote:

HI all,

Please review the latest TZDATA integration (tzdata2016d) to
JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151876

Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
<http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.00/>

Patch Contains:

1.   IANA tzdata2016d integration into JDK. [It also
includes tzdata2016b and tzdata2016c which was not integrated].

2.   "GMT[+ -]hh:mm" is used for formatting of the
modified or newly added TimeZones in tzdata2016d.

[This is done to accommodate the IANA's new system where the
zones use numeric time zone abbreviations like "+04" instead
of invented abbreviations like "ASTT".]

3.   Test case:
java/time/test/java/time/format/TestZoneTextPrinterParser.java
is updated to include the failures because of GMT[+ -]hh:mm
format names.

4.   Few other failing tests: For few other failing tests,
new linked bugs are created and will be addressed in a
separate patch.


Regards,

Ramanand.

Re: RFR: 8151876: (tz) Support tzdata2016d

[Masayoshi Okutsu]

CLDR locale data defines time zone names, like this (in en.xml):

   

Almaty Time
Almaty Standard 
Time
Almaty Summer Time



The CLDR converter tool tries to fill in the missing short names from 
the legacy TimeZoneNames data. Removing existing names causes some 
unexpected behavior. I think JDK-8157814 is an example of the unexpected 
behavior. And the suggested fix in JDK-8157814 looks to me like a 
workaround.


I still think the existing names should be kept unchanged for this fix.

Thanks,
Masayoshi

On 5/28/2016 12:04 AM, Seán Coffey wrote:
I guess there's a low risk of timezone not being identified if being 
parsed in through a formatter. Isn't such an approach discouraged 
though ? short IDs were already subject to change in tzdata releases. 
Ramanand found one issue by removal of these resource strings (so far) 
and that's captured in JDK-8157814


There's a decision to be made about how to use the GMT±hh:mm format 
for new releases given IANA's new short ID identifier mechanism. I 
think that could be discussed as a separate issue. I'd like to see us 
follow a similar approach to IANA and use GMT identifiers on new 
timezones and perhaps even consider using the IANA long name format 
also for the getDisplayName(..) calls that can be made. e.g. 
"Asia/Almaty" instead of "Alma-Ata Time"

Regards,
Sean.
On 27/05/16 15:24, Masayoshi Okutsu wrote:
This change seems to beyond my proposal that the "GMT±hh:mm" format 
is used for *new* zones with the "±hh" format. But this change 
removes *existing* zones which have changed to use the "±hh" format 
in tzdata. Can this cause any compatibility issues?


And have we agreed to use the "GMT±hh:mm" format?

Thanks,
Masayoshi


On 5/27/2016 10:19 PM, Seán Coffey wrote:
Looks fine to me Ramanand. the recent 2016d changes have introduced 
some boundary issues for JDK rule parsing and those issues can be 
followed up in separate issues like you say.


Regards,
Sean.

On 26/05/16 14:22, Ramanand Patil wrote:

HI all,

Please review the latest TZDATA integration (tzdata2016d) to JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151876

Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/

Patch Contains:

1.   IANA tzdata2016d integration into JDK. [It also includes 
tzdata2016b and tzdata2016c which was not integrated].


2.   "GMT[+ -]hh:mm" is used for formatting of the modified or 
newly added TimeZones in tzdata2016d.


[This is done to accommodate the IANA's new system where the zones 
use numeric time zone abbreviations like "+04" instead of invented 
abbreviations like "ASTT".]


3.   Test case: 
java/time/test/java/time/format/TestZoneTextPrinterParser.java is 
updated to include the failures because of GMT[+ -]hh:mm format names.


4.   Few other failing tests: For few other failing tests, new 
linked bugs are created and will be addressed in a separate patch.



Regards,

Ramanand.

Re: RFR: 8151876: (tz) Support tzdata2016d

[Masayoshi Okutsu]

This change seems to beyond my proposal that the "GMT±hh:mm" format is 
used for *new* zones with the "±hh" format. But this change removes 
*existing* zones which have changed to use the "±hh" format in tzdata. 
Can this cause any compatibility issues?


And have we agreed to use the "GMT±hh:mm" format?

Thanks,
Masayoshi


On 5/27/2016 10:19 PM, Seán Coffey wrote:
Looks fine to me Ramanand. the recent 2016d changes have introduced 
some boundary issues for JDK rule parsing and those issues can be 
followed up in separate issues like you say.


Regards,
Sean.

On 26/05/16 14:22, Ramanand Patil wrote:

HI all,

Please review the latest TZDATA integration (tzdata2016d) to JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151876

Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/

Patch Contains:

1.   IANA tzdata2016d integration into JDK. [It also includes 
tzdata2016b and tzdata2016c which was not integrated].


2.   "GMT[+ -]hh:mm" is used for formatting of the modified or 
newly added TimeZones in tzdata2016d.


[This is done to accommodate the IANA's new system where the zones 
use numeric time zone abbreviations like "+04" instead of invented 
abbreviations like "ASTT".]


3.   Test case: 
java/time/test/java/time/format/TestZoneTextPrinterParser.java is 
updated to include the failures because of GMT[+ -]hh:mm format names.


4.   Few other failing tests: For few other failing tests, new 
linked bugs are created and will be addressed in a separate patch.



Regards,

Ramanand.

Re: RFR: 8151876: (tz) Support tzdata2016c

[Masayoshi Okutsu]

Looks good to me. But I'd like someone from java.time to review the 
changes to see if it's OK for java.time.


Masayoshi

On 4/4/2016 6:50 PM, Ramanand Patil wrote:

Hi all,

Please review the latest TZDATA (tzdata2016c) integration to JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151876

Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/

All the TimeZone related tests are passed after integration.

  


Please note that this patch includes both tzdata2016b and tzdata2016c 
integration. The tzdata2016b review was abandoned because tzdata2016c was 
already released.

As suggested by Masayoshi, changes are made such that,  "GMT+hh:mm" is used for 
formatting of the newly added TimeZones in tzdata2016b.

[This is done to accommodate the IANA's new trial system where the new zones use numeric time zone 
abbreviations like "+04" instead of invented abbreviations like "ASTT".]

  


Regards,

Ramanand.

Re: RFR: 8151876: (tz) Support tzdata2016b

[Masayoshi Okutsu]

Hi Ramanand,

What I meant is to remove those new resources so that "GMT+hh:mm" is 
used for formatting. There may be some tests that require changes.


Thanks,
Masayoshi

On 3/28/2016 7:31 PM, Ramanand Patil wrote:

Hi Masayoshi,

Currently I have not defined the new TimeZoneNames with +hh format, instead I 
have defined them as per the earlier convention like:

+{"Asia/Barnaul", new String[] {"Barnaul Time", "BAT",
+   "Barnaul Summer Time", "BAST",
+   "Barnaul Time", "BAT"}},

+{"Europe/Astrakhan", new String[] {"Astrakhan Time", "ASTT",
+   "Astrakhan Summer Time", 
"ASTST",
+   "Astrakhan Time", "ASTT"}},

+{"Europe/Ulyanovsk", new String[] {"Ulyanovsk Time", "ULT",
+   "Ulyanovsk Summer Time", "ULST",
+   "Ulyanovsk Time", "ULT"}},



Please let me know if this is fine.


Regards,
Ramanand.

-Original Message-
From: Masayoshi Okutsu
Sent: Wednesday, March 23, 2016 7:22 PM
To: Ramanand Patil; i18n-...@openjdk.java.net
Cc: core-libs-dev@openjdk.java.net
Subject: Re: RFR: 8151876: (tz) Support tzdata2016b

Sorry for this belated response.

I prefer to follow the tzdata abbreviations, like "+04". But that would require 
some major changes. An option would be not to define time zone names for the new zones 
with the +hh format.

Thanks,
Masayoshi

On 3/17/2016 4:38 AM, Ramanand Patil wrote:

Hi all,

Please review the latest TZDATA (tzdata2016b) integration to JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151876

Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/

All the TimeZone related tests are passed after integration.

   


Please note that, as per the release notes: As a trial of a new system that needs less information 
to be made up, the new zones use numeric time zone abbreviations like "+04" instead of 
invented abbreviations like "ASTT".

Since this is a trial system, I have ignored this in the current patch which 
adds 3 new timezones. But I think it's worth discussing this new system along 
with this bug and get the experts opinion on this.

Do you think that JDK should also follow these IANA timezone naming system for zone 
abbreviations in future ?  Will it be convenient to use such numeric time zone 
abbreviations ? (Also, it looks like the abbreviations similar to "+03/+04" 
will be used for the zones linked to the rule set with changing letters like: EST/EDT for 
US, MSK/MSD for RU, etc..).

   


Regards,

Ramanand.

   

Re: RFR: 8151876: (tz) Support tzdata2016b

[Masayoshi Okutsu]

Sorry for this belated response.

I prefer to follow the tzdata abbreviations, like "+04". But that would 
require some major changes. An option would be not to define time zone 
names for the new zones with the +hh format.


Thanks,
Masayoshi

On 3/17/2016 4:38 AM, Ramanand Patil wrote:

Hi all,

Please review the latest TZDATA (tzdata2016b) integration to JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151876

Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/

All the TimeZone related tests are passed after integration.

  


Please note that, as per the release notes: As a trial of a new system that needs less information 
to be made up, the new zones use numeric time zone abbreviations like "+04" instead of 
invented abbreviations like "ASTT".

Since this is a trial system, I have ignored this in the current patch which 
adds 3 new timezones. But I think it's worth discussing this new system along 
with this bug and get the experts opinion on this.

Do you think that JDK should also follow these IANA timezone naming system for zone 
abbreviations in future ?  Will it be convenient to use such numeric time zone 
abbreviations ? (Also, it looks like the abbreviations similar to "+03/+04" 
will be used for the zones linked to the rule set with changing letters like: EST/EDT for 
US, MSK/MSD for RU, etc..).

  


Regards,

Ramanand.

  

Re: RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the constructor

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 2/24/2016 4:40 PM, Ramanand Patil wrote:

Hi all,
Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8087104
Bug Description: DateFormatSymbols caches its own instance and calls 
this.clone() in the constructor. Because of this, any subclass implementation 
(which expects a field is always initialized to non-null in the constructor) 
will throw NPE in its overridden clone() method while using any instance 
variables which it assumed are initilaized in its contructor.
Webrev: http://cr.openjdk.java.net/~rpatil/8087104/webrev.00/
Fix: Instead of using its own instance for caching and calling clone in 
DateFormatSymbols, a nested class SymbolsCacheEntry is introduced.
  


Regards,

Ramanand.

Re: RFR: 8148446: (tz) Support tzdata2016a

[Masayoshi Okutsu]

Hi Ramanand,

I noticed that the zones in Yakutsk Time [1] seem to have their own 
names, such as "Khandyga Time" for Asia/Khandyga, and you seem to follow 
that convention for Asia/Chita. That causes some mismatch between the 
long names and abbreviations.


I dag out some past tzdata fixes to see how that happened. What I found 
out is that the 2013b fix [2] used "Yakutsk Time", but that the 2013c 
[3] fix used "Khandyga Time". 2013b went to JDK 7 updates and earlier 
ones and 2013c went to 8. JDK 9 inherits the 8 fix.


I prefer to restore the 2013b convention for Asia/Yakutsk, Asia/Chita, 
and Asia/Khandyga to have:


{"Yakutsk Time", "YAKT",
 "Yakutsk Summer Time", "YAKST",
 "Yakutsk Time", "YAKT"}

Thanks,
Masayoshi

[1] https://en.wikipedia.org/wiki/Yakutsk_Time
[2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/b8009df64dc8
[3] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/ae35fdbab949

On 2/2/2016 8:00 PM, Ramanand Patil wrote:

HI all,

Please review the latest TZDATA integration (tzdata2016a) to JDK9.

Bug  - https://bugs.openjdk.java.net/browse/JDK-8148446

Webrev - http://cr.openjdk.java.net/~rpatil/8148446/webrev.00/

  


All the TimeZone related tests are passed after integration.

  


Regards,

Ramanand.

Re: RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale

[Masayoshi Okutsu]

Looks OK to me. But I'd like some java.time people to review this change 
to see if the intention of this test is to run only in English.


Thanks,
Masayoshi

On 1/27/2016 1:51 PM, Ramanand Patil wrote:

Hi all,

  


Please help me in reviewing this test fix.

  


Regards,

Ramanand.

From: Ramanand Patil
Sent: Monday, January 25, 2016 1:05 PM
To: i18n-...@openjdk.java.net
Cc: core-libs-dev@openjdk.java.net
Subject: RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of 
java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale

  


Hi all,
  
Please review the trivial test bug fix for: https://bugs.openjdk.java.net/browse/JDK-8147912
  
Bug Description: Since the test case "parseWithZoneWithoutOffset" is using hard code as input data it will fail on some non-English locales (de_DE locale).
  
Webrev: http://cr.openjdk.java.net/~rpatil/8147912/webrev.00
  
Fix: Even though hardcoded data is not preferred in compatibility test cases, this case was exception. English is provided as the default locale data for DateTimeFormatter in this testcase.
  
Regards,

Ramanand.

Re: RFR: JDK-8144988: Unexpected timezone returned after parsing a date

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 1/16/2016 12:31 AM, Ramanand Patil wrote:

Hi Masayoshi,

Thank you for pointing that out. I have removed line 29 from the test.

Please review the updated Webrev: 
http://cr.openjdk.java.net/~rpatil/8141243/webrev.01/


Regards,
Ramanand.

-Original Message-
From: Masayoshi Okutsu
Sent: Friday, January 15, 2016 8:18 AM
To: Ramanand Patil; i18n-...@openjdk.java.net
Cc: core-libs-dev@openjdk.java.net
Subject: Re: RFR: JDK-8144988: Unexpected timezone returned after 
parsing a date

Hi Ramanand,

test/java/text/Format/DateFormat/Bug8141243.java:

28  * @run main Bug8141243
29  * @run main/othervm -Djava.locale.providers=COMPAT Bug8141243

"COMPAT" is a new name of "JRE" in JDK 9. It's not supported in 8u. I think 
COMPAT is slightly ignored and that it becomes the same thing as line 28. Line 29 should be removed.

Otherwise, the fix looks OK to me.

Masayoshi

On 1/14/2016 9:21 PM, Ramanand Patil wrote:

Hi all,
   
Please review the fix for bug:

https://bugs.openjdk.java.net/browse/JDK-8144988
   
Webrev: http://cr.openjdk.java.net/~rpatil/8141243/webrev.00
   
This is basically a backport of JDK9 bug:

https://bugs.openjdk.java.net/browse/JDK-8141243
   
JDK9 changeset(for reference):

http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a1aa2671f281
   
Reason for the review request is because of:

i) Changes present in ResourceBundleGenerator.java file.
ii)   The patch from JDK9 does not automatically apply as is after using 
unshuffle_patch script. Few paths are adjusted as per the jdk8.
   
Since CLDR became the default locale data in JDK9 leading incompatible behavior with prior releases, the relevant code in ResourceBundleGenerator is also backported in this patch.

Even though JDK8 has CLDR locale provider disabled by default, the code change is done to 
be on safer side for cases where CLDR may be supporting "UTC" ID in the future.
   
   
Regards,

Ramanand.

Re: RFR: JDK-8144988: Unexpected timezone returned after parsing a date

[Masayoshi Okutsu]

Hi Ramanand,

test/java/text/Format/DateFormat/Bug8141243.java:

  28  * @run main Bug8141243
  29  * @run main/othervm -Djava.locale.providers=COMPAT Bug8141243

"COMPAT" is a new name of "JRE" in JDK 9. It's not supported in 8u. I 
think COMPAT is slightly ignored and that it becomes the same thing as 
line 28. Line 29 should be removed.


Otherwise, the fix looks OK to me.

Masayoshi

On 1/14/2016 9:21 PM, Ramanand Patil wrote:

Hi all,
  
Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8144988
  
Webrev: http://cr.openjdk.java.net/~rpatil/8141243/webrev.00
  
This is basically a backport of JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8141243
  
JDK9 changeset(for reference): http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a1aa2671f281
  
Reason for the review request is because of:

i) Changes present in ResourceBundleGenerator.java file.
ii)   The patch from JDK9 does not automatically apply as is after using 
unshuffle_patch script. Few paths are adjusted as per the jdk8.
  
Since CLDR became the default locale data in JDK9 leading incompatible behavior with prior releases, the relevant code in ResourceBundleGenerator is also backported in this patch.

Even though JDK8 has CLDR locale provider disabled by default, the code change is done to 
be on safer side for cases where CLDR may be supporting "UTC" ID in the future.
  
  
Regards,

Ramanand.

Re: Code Review for JDK-8141243: Unexpected timezone returned after parsing a date

[Masayoshi Okutsu]

Hi Ramanand,

I don't think this fix is correct. This change mixes up time zone IDs 
and display names. SimpleDateFomat should parse only display names.


There's no perfect solution on the issue because the short display names 
(abbreviations) can't be unique. So, I'd suggest that the UTC display 
names in all resource bundles (all TimeZoneNames*.java under 
sun.util.resources) move up to the compatibility group.


BTW, the symptom is reproducible in JDK 9 with the legacy time zone 
names (run java with -Djava.locale.providers=COMPAT). So, the fix should 
be done in JDK 9 first.


Thanks,
Masayoshi

On 11/16/2015 10:38 PM, Ramanand Patil wrote:

Hi all,

  


Please review a fix for Bug Id - HYPERLINK 
"https://bugs.openjdk.java.net/browse/JDK-8141243"JDK-8141243.



  


Issue - When parsing the virtual timezone "UTC" with java.text.SimpleDateFormat, the 
timezone is set to the first timezone that matches an actual timezone in the UTC group, which is 
Antarctica/Troll. When comparing this timezone with the result of 
TimeZone.getTimeZone("UTC"), we fail.

  


Webrev - http://cr.openjdk.java.net/~aefimov/8141243/webrev.00/

  

  


Regards,

Ramanand.

  

Re: [9] RFR: 8072600: Unicode 8 support

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 10/16/2015 9:41 PM, Yuka Kamiya wrote:

Hello,

Please review a small change for   8072600: Unicode 8 support.
Mainly date update from Unicode 7.

JEP:   http://openjdk.java.net/jeps/267
Issue:   https://bugs.openjdk.java.net/browse/JDK-8072600
webrev:   http://cr.openjdk.java.net/~peytoia/8072600/

Thanks,
--
Yuka

Re: [9] RFR: 8133321: (tz) Support tzdata2015f

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 8/13/2015 10:54 PM, Aleksej Efimov wrote:

Hello,

Please review latest tzdata (2015f)  integration into JDK9:
http://cr.openjdk.java.net/~aefimov/tzdata/2015f/9/00

Testing shows no TZ related failures on all platforms.

Thanks,
Aleksej

JBS: https://bugs.openjdk.java.net/browse/JDK-8133321

Re: i18n dev RFR: 8032446: Support Unicode 7.0.0 in JDK 9

[Masayoshi Okutsu]

Looks OK to me too.

Masayoshi

On 7/15/2015 8:16 AM, Naoto Sato wrote:
 Looks good to me.

 Naoto

 On 7/13/15 1:20 AM, Yuka Kamiya wrote:
 Hello,

 Please review the fix for 8032446 to support Unicode 7 in JDK 9.

 https://bugs.openjdk.java.net/browse/JDK-8032446
 http://cr.openjdk.java.net/~peytoia/8032446/webrev.00/

 - Internal review for both open  closed parts has been completed.
 - Changes in sun.text.* packages are mostly porting from ICU4J. (Thank
 you very much, ICU4J project.)
 - Because Unicode 8 was released last month, this fix will be
 overwritten (partially) in near future.

 Thanks,
 --
 Yuka

Re: RFR: 8098547: (tz) Support tzdata2015e

[Masayoshi Okutsu]

+1

Masayoshi

On 6/24/2015 9:58 PM, Seán Coffey wrote:

Looks fine.

Regards,
Sean.

On 24/06/15 12:05, Aleksej Efimov wrote:

Hello,

Please, review the latest tzdata (2015e) [1] integration to JDK9: 
http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0

Testing shows no TZ related failures on all platforms.

With Best Regards,
Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-8098547

Re: i18n dev RFR JDK-8042125: Japanese character converters incompatible between Java 7 and Java 8

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 5/24/2015 9:26 AM, Xueming Shen wrote:

Hi

Please help the change for 8042125

issue: https://bugs.openjdk.java.net/browse/JDK-8042125
webrev: http://cr.openjdk.java.net/~sherman/8042125

It's a regression caused by the changes of JDK-6653797. The direct 
triggers are
(1) the .c2b mapping table for ms932/0208is missing (regardless the 
comment in

 JIS_X_0208_MS932.map says we need one)
(2) mapping entry for those non-roundtrip code points are mistakenly 
commented

out in jis_x_0212_solaris.map and jis_x_0208_ms932.map.

thanks!
-Sherman

Re: i18n dev RFR: 8077685: (tz) Support tzdata2015d

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 4/29/2015 11:37 PM, Aleksej Efimov wrote:

Hi,

Please, review the fix for adding the latest tzdata2015d to JDK9.
The JTREG and JPRT tests were executed.
No failures were observed.

Thank you,
Aleksej

[1] JBS: https://bugs.openjdk.java.net/browse/JDK-8077685
[2] Webrev: http://cr.openjdk.java.net/~aefimov/tzdata/2015d/9/00

Re: i18n dev RFR: 8075667: (tz) Support tzdata2015b

[Masayoshi Okutsu]

Looks good except that data changes keep requiring additional workaround 
to the run-time code. We do need a fix for JDK-8014468.


Masayoshi

On 3/27/2015 12:47 AM, Aleksej Efimov wrote:

Hi,

Please review the fix for adding the latest tzdata2015b to JDK9.
The JTREG and JPRT tests were executed.
No failures were observed, except one:
test/sun/util/calendar/zi/TestZoneInfo310.java
The failure was caused by the following tzdb rule addition to 
make/data/tzdata/asia:
+Rule Palestine2015max-MarlastFri24:00 
 1:00S
And it was addressed by addition of another piece of workaround code 
to src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.

After this changes the test showed the PASS result.

Thank you,
Aleksej

[1] JBS: https://bugs.openjdk.java.net/browse/JDK-8075667
[2] Webrev: http://cr.openjdk.java.net/~aefimov/tzdata/2015b/9/00

Re: i18n dev [9] RFR: 8072042: (tz) Support tzdata2015a

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 2/4/2015 12:59 AM, Aleksej Efimov wrote:

Hi,

Could I have a review the latest tzdata2015a integration fix to JDK9, 
please. The regression tests run and JPRT testing (jdk_other,jdk_util, 
jdk_text, jdk_time test sets) shows no TZ related JDK9 failures.


Thank you,
Aleksej

Bug link: https://bugs.openjdk.java.net/browse/JDK-8072042
Webrev with changes: 
http://cr.openjdk.java.net/~aefimov/tzdata/2015a/9/00/
Regression tests executed: test/sun/util/calendar\ 
test/java/util/Calendar\ test/sun/util/resources/TimeZone\ 
test/java/util/TimeZone\ test/java/time\ test/java/util/Formatter

Re: RFR: 8065159: AttributedString has quadratic resize algorithm

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 11/20/2014 11:20 AM, Naoto Sato wrote:

OK, fine by me.

Naoto

On 11/19/14 4:37 PM, Martin Buchholz wrote:

Thanks Naoto!

Yeah, I noticed that too, but I'm not comfortable enough with this
code to suggest a really good naming scheme.
There are 3 levels of pluralization here - Attribute Attributes
Attributeses [sic]!?

On Wed, Nov 19, 2014 at 3:41 PM, Naoto Sato naoto.s...@oracle.com 
wrote:

Hi Martin,

The fix looks good to me. Although it is not inherently related to 
your fix,

there are two separate declarations of newRunAttributes and
newRunAttributeValues in ensureRunBreak() method and their usages are
different! It would be desirable to correct it.

Naoto


On 11/19/14, 3:00 PM, Martin Buchholz wrote:


Hey Naoto and Masayoshi,

I haven't sent you a friendly code review in a while.


http://cr.openjdk.java.net/~martin/webrevs/openjdk9/AttributedString-optimization/ 


https://bugs.openjdk.java.net/browse/JDK-8065159

(AttributedString could also independently see some testing and code
hygiene love)

Re: i18n dev RFR: 8064560: (tz) Support tzdata2014j

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 11/17/2014 9:13 AM, Aleksej Efimov wrote:

Hi,

Please, review [1] tzdata2014j integration to JDK9 [2]. It is a 
straight-forward tzdata update, but new data caused a tzdb.dat build 
failure.
It was reported under different bugId [3], there is a possible fix for 
that and request for review was sent [4].

Testing:
JPRT: jdk_other jdk_util jdk_text jdk_time
JTREG tests: test/sun/util/calendar test/java/util/Calendar 
test/sun/util/resources/TimeZone test/sun/util/calendar 
test/java/util/TimeZone test/java/time test/java/util/Formatter 
test/closed/java/util/Calendar test/closed/java/util/TimeZone 
test/closed/java/text/Format/DateFormat


Thank you,
Aleksej

[1] Webrev: http://cr.openjdk.java.net/~aefimov/8064560/9/webrev.00/
[2] Bug URL: https://bugs.openjdk.java.net/browse/JDK-8064560
[3] Build failure bug: https://bugs.openjdk.java.net/browse/JDK-8064914
[4] Build failure RFR: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029677.html 

Re: RFR: 8059206: (tz) Support tzdata2014i

[Masayoshi Okutsu]

Hi Aleksej,

src/java.base/share/classes/sun/util/resources/TimeZoneNames*.java:

+{Pacific/Bougainville, new String[] {Bougainville Standard Time, 
BST,
+   Bougainville Summer Time, 
BST,
+   Bougainville Time, BT}},


I'd use Daylight Time instead of Summer Time because of the recent 
move from Summer to Daylight. No daylight saving time is observed in 
Bougainville, though.


Otherwise, all the changes look good to me.

Thanks,
Masayoshi

On 10/28/2014 8:57 PM, Aleksej Efimov wrote:

Hi,

Can I ask for review of new tzdata - 2014i integration fix to JDK9. 
One change in this release is that new time zone was added - 
Pacific/Bougainville. The localized names still needs to be 
translated - the appropriate comment was added to JDK-8057004.


Testing results:
JPRT tests: jdk_other jdk_util jdk_text jdk_time - no failures
JTREG tests: test/sun/util/calendar test/java/util/Calendar 
test/sun/util/resources/TimeZone test/sun/util/calendar 
test/java/util/TimeZone test/java/time test/java/util/Formatter 
test/closed/java/util/Calendar test/closed/java/util/TimeZone 
test/closed/java/text/Format/DateFormat - no failures


Thank you,
Aleksej

[1] Bug: https://bugs.openjdk.java.net/browse/JDK-8059206
[2] Webrev: http://cr.openjdk.java.net/~aefimov/8059206/9/webrev.00

Re: RFR: 8049343: (tz) Support tzdata2014g

[Masayoshi Okutsu]

The fix looks OK to me.

Thanks,
Masayoshi

On 9/2/2014 10:41 PM, Aleksej Efimov wrote:

Masayoshi,
Sorry for the confusion - for some reason (most probably this change 
was added after webrev generation) I forgot to include it. Now it's in 
place: http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04


Thank you,
Aleksej

On 09/02/2014 10:03 AM, Masayoshi Okutsu wrote:

Aleksej,

I don't see the America/Grand_Turk change in webrev.04. I wonder if 
the webrev wasn't updated correctly.


Thanks,
Masayoshi

On 9/1/2014 11:10 PM, Aleksej Efimov wrote:

Masayoshi,

I have addressed all your comments with proposed resolution. Thank 
you for such thorough analysis of this changes.


Also the new tzdata is out (2014g) - I have updated the JBS bug by 
adding 2014g related change notes and renamed this bug appropriately 
+ I'm renaming this thread.

The new webrev contains new changes related to 2014g:
-{America/Grand_Turk, EST},
+{America/Grand_Turk, AST},


The 2014e/f related changes, discussed previously, are still in place.

New webrev can be found here: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04


The bug for the incomplete localization of new/updated time zone 
names was filed: https://bugs.openjdk.java.net/browse/JDK-8057004


With Best Regards,
Aleksej

On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote:

 src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:

 239 String SLST[] = new String[] {Greenwich Mean Time, 
GMT,
 240   Sierra Leone Summer 
Time, SLST,
 241   Sierra Leone Time, 
SLT};


 251 String WART[] = new String[] {Western Argentine 
Time, WART,
 252   Western Argentine 
Summer Time, WARST,
 253   Western Argentine 
Time, WART};


It seems these are no longer used.

-{Antarctica/Macquarie, new String[] {Macquarie 
Island Time, MIST,

- Macquarie Island Summer Time, MIST,
+{Antarctica/Macquarie, new String[] {Macquarie 
Island Standard Time, MIST,

+ Macquarie Island Daylight Time, MIST,

The daylight saving time abbreviation should be MIDT.

Thanks,
Masayoshi

On 8/27/2014 10:53 PM, Aleksej Efimov wrote:

Masayoshi,
Thank you for a detailed review - I tried to address all your 
comments. Please, see the updated review: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03
About the workarounds - I will start discussion with Sherman when 
the tzdata2014f (and I suppose the 2014g - it will be available 
soon according to tzdata mail-list [1]) integration will be complete.


-Aleksej

[1] tzdata2014g is coming: 
http://mm.icann.org/pipermail/tz/2014-August/021528.html


On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote:

Here are additional comments.

src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java:

I'm concerned about the workarounds. It's not new in this update, 
but this problem would make tzupdater data void until the 
workaround is added to the next update release. Could you please 
work with Sherman to eliminate the workaround (outside of this 
2014f update)?


src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:

 String LORD_HOWE[] = new String[] {Lord Howe Standard 
Time, LHST,
-   Lord Howe Summer 
Time, LHST,
+   Lord Howe Summer 
Time, LHDT,


The S-D convention is applied to Lord Howe as well.

 567 {Antarctica/Macquarie, new String[] 
{Macquarie Island Time, MIST,

 568 Macquarie Island Summer Time, MIST,
 569 Macquarie Island Time, MIST}},

This one should also follow the S-D convention, although this 
time zone doesn't observe daylight saving time.



+String XJT[] = new String[] {China Standard Time, XJT,
+ China Daylight Time, XJDT,
+ China Time, XJT};

Should the long names be based on Xinjiang?

Africa/Freetown is now a link to Africa/Abidjan. Those should be 
the same time zone.


-{America/Metlakatla, new String[] {Metlakatla 
Standard Time, MeST,

- Metlakatla Daylight Time, MeDT,
- Metlakatla Time, MeT}},
+{America/Metlakatla, new String[] {Metlakatla 
Standard Time, PST,

+ Metlakatla Daylight Time, PDT,
+ Metlakatla Time, PT}},

-{Europe/Volgograd, new String[] {Volgograd Time, 
VOLT,

- Volgograd Summer Time, VOLST,
- Volgograd Time, VOLT}},
+{Europe/Volgograd, new String[] {Volgograd Time, 
MSK,

+ Volgograd Summer Time, MSK,
+ Volgograd Time, MSK}},


The long names should be changed accordingly.

Thanks,
Masayoshi

On 8/22/2014 9:17 PM, Aleksej Efimov wrote:

Masayoshi,
You're right that the root names should be changed as part of 
this update. The names were changed according to Australian 
official document here: 
http://australia.gov.au/about-australia/our-country/time
The fixed

Re: RFR: 8049343: (tz) Support tzdata2014g

[Masayoshi Okutsu]

Aleksej,

I don't see the America/Grand_Turk change in webrev.04. I wonder if the 
webrev wasn't updated correctly.


Thanks,
Masayoshi

On 9/1/2014 11:10 PM, Aleksej Efimov wrote:

Masayoshi,

I have addressed all your comments with proposed resolution. Thank you 
for such thorough analysis of this changes.


Also the new tzdata is out (2014g) - I have updated the JBS bug by 
adding 2014g related change notes and renamed this bug appropriately + 
I'm renaming this thread.

The new webrev contains new changes related to 2014g:
-{America/Grand_Turk, EST},
+{America/Grand_Turk, AST},


The 2014e/f related changes, discussed previously, are still in place.

New webrev can be found here: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04


The bug for the incomplete localization of new/updated time zone names 
was filed: https://bugs.openjdk.java.net/browse/JDK-8057004


With Best Regards,
Aleksej

On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote:

 src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:

 239 String SLST[] = new String[] {Greenwich Mean Time, GMT,
 240   Sierra Leone Summer 
Time, SLST,

 241   Sierra Leone Time, SLT};

 251 String WART[] = new String[] {Western Argentine Time, 
WART,
 252   Western Argentine Summer 
Time, WARST,
 253   Western Argentine Time, 
WART};


It seems these are no longer used.

-{Antarctica/Macquarie, new String[] {Macquarie Island 
Time, MIST,
-   Macquarie Island 
Summer Time, MIST,
+{Antarctica/Macquarie, new String[] {Macquarie Island 
Standard Time, MIST,
+   Macquarie Island 
Daylight Time, MIST,


The daylight saving time abbreviation should be MIDT.

Thanks,
Masayoshi

On 8/27/2014 10:53 PM, Aleksej Efimov wrote:

Masayoshi,
Thank you for a detailed review - I tried to address all your 
comments. Please, see the updated review: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03
About the workarounds - I will start discussion with Sherman when 
the tzdata2014f (and I suppose the 2014g - it will be available soon 
according to tzdata mail-list [1]) integration will be complete.


-Aleksej

[1] tzdata2014g is coming: 
http://mm.icann.org/pipermail/tz/2014-August/021528.html


On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote:

Here are additional comments.

src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java:

I'm concerned about the workarounds. It's not new in this update, 
but this problem would make tzupdater data void until the 
workaround is added to the next update release. Could you please 
work with Sherman to eliminate the workaround (outside of this 
2014f update)?


src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:

 String LORD_HOWE[] = new String[] {Lord Howe Standard 
Time, LHST,
-   Lord Howe Summer 
Time, LHST,
+   Lord Howe Summer 
Time, LHDT,


The S-D convention is applied to Lord Howe as well.

 567 {Antarctica/Macquarie, new String[] {Macquarie 
Island Time, MIST,

 568 Macquarie Island Summer Time, MIST,
 569 Macquarie Island Time, MIST}},

This one should also follow the S-D convention, although this time 
zone doesn't observe daylight saving time.



+String XJT[] = new String[] {China Standard Time, XJT,
+ China Daylight Time, XJDT,
+ China Time, XJT};

Should the long names be based on Xinjiang?

Africa/Freetown is now a link to Africa/Abidjan. Those should be 
the same time zone.


-{America/Metlakatla, new String[] {Metlakatla 
Standard Time, MeST,

- Metlakatla Daylight Time, MeDT,
- Metlakatla Time, MeT}},
+{America/Metlakatla, new String[] {Metlakatla 
Standard Time, PST,

+ Metlakatla Daylight Time, PDT,
+ Metlakatla Time, PT}},

-{Europe/Volgograd, new String[] {Volgograd Time, 
VOLT,
-   Volgograd Summer 
Time, VOLST,
-   Volgograd Time, 
VOLT}},
+{Europe/Volgograd, new String[] {Volgograd Time, 
MSK,
+   Volgograd Summer 
Time, MSK,
+   Volgograd Time, 
MSK}},



The long names should be changed accordingly.

Thanks,
Masayoshi

On 8/22/2014 9:17 PM, Aleksej Efimov wrote:

Masayoshi,
You're right that the root names should be changed as part of 
this update. The names were changed according to Australian 
official document here: 
http://australia.gov.au/about-australia/our-country/time
The fixed version of the webrev can be found here: 
http://cr.openjdk.java.net/~aefimov/8049343/9

Re: RFR: 8049343: (tz) Support tzdata2014f

[Masayoshi Okutsu]

Here are additional comments.

src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java:

I'm concerned about the workarounds. It's not new in this update, but 
this problem would make tzupdater data void until the workaround is 
added to the next update release. Could you please work with Sherman to 
eliminate the workaround (outside of this 2014f update)?


src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:

 String LORD_HOWE[] = new String[] {Lord Howe Standard Time, LHST,
-   Lord Howe Summer Time, LHST,
+   Lord Howe Summer Time, LHDT,

The S-D convention is applied to Lord Howe as well.

 567 {Antarctica/Macquarie, new String[] {Macquarie Island Time, 
MIST,
 568Macquarie Island Summer Time, 
MIST,
 569Macquarie Island Time, 
MIST}},

This one should also follow the S-D convention, although this time zone 
doesn't observe daylight saving time.



+String XJT[] = new String[] {China Standard Time, XJT,
+ China Daylight Time, XJDT,
+ China Time, XJT};

Should the long names be based on Xinjiang?

Africa/Freetown is now a link to Africa/Abidjan. Those should be the 
same time zone.


-{America/Metlakatla, new String[] {Metlakatla Standard Time, 
MeST,
- Metlakatla Daylight Time, 
MeDT,
- Metlakatla Time, MeT}},
+{America/Metlakatla, new String[] {Metlakatla Standard Time, 
PST,
+ Metlakatla Daylight Time, 
PDT,
+ Metlakatla Time, PT}},

-{Europe/Volgograd, new String[] {Volgograd Time, VOLT,
-   Volgograd Summer Time, 
VOLST,
-   Volgograd Time, VOLT}},
+{Europe/Volgograd, new String[] {Volgograd Time, MSK,
+   Volgograd Summer Time, MSK,
+   Volgograd Time, MSK}},
 


The long names should be changed accordingly.

Thanks,
Masayoshi

On 8/22/2014 9:17 PM, Aleksej Efimov wrote:

Masayoshi,
You're right that the root names should be changed as part of this 
update. The names were changed according to Australian official 
document here: http://australia.gov.au/about-australia/our-country/time
The fixed version of the webrev can be found here: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02


Thanks,
Aleksej


On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote:
We used to make name changes in the root (base) bundle as part of 
time zone data maintenance and deter only translations. But if you 
want to handle name changes later, that would be fine. It's your call.


Thanks,
Masayoshi

On 8/21/2014 5:05 PM, Aleksej Efimov wrote:

Masayoshi,
I agree that we should change the long names to match the new short 
names introduced by tzdata.
But I suggest to log a different CR for such activity to handle long 
name changes and their translations (this activity is slightly out 
of tzdata update scope). Does it make sense?


-Aleksej

On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
I think the long names of the Australia time zones should be 
revisited to be consistent with the abbreviation changes. The new 
abbreviations follow the S[tandard] and D[aylight saving] 
convention rather than the S[tandard] and S[ummer time] one. The 
long names, such as Eastern Summer Time (Queensland), no longer 
make sense.


On the other hand, you will need to access impact of the name 
changes, including abbreviations. Also, if you change the long 
names, their translations will need to be changed as well.


Thanks,
Masayoshi

On 8/20/2014 11:59 PM, Aleksej Efimov wrote:

Hi,

Please, review the tzdata2014f integration (with tzdata2014e 
related changes included too) [1] fix to JDK9: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/


The tzdata2014f changes are extensive and relates mostly to 
timezone short names changes + Asia/Srednekolymsk time zone were 
added.
Almost complete list of changes can be found in the JBS bug 
description [1], plus some changes wasn't documented in tzdata 
release notes - for such cases raw tzdata diff was used for the 
names modifications.


Two issues with JSR310 implementation were discovered during 
integration process:
First issue is related to the internal representation of the 
'24:00' value. The JSR310 implementation treats this value as a 
next day 00:00 time. The workaround already exists in JSR310 code 
for similar entries and this failure is resolved in similar way 
[2] as part of this update.
For the second issue JDK-8051641 [3] was filled and 
'sun/util/calendar

Re: RFR: 8049343: (tz) Support tzdata2014f

[Masayoshi Okutsu]

 src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:

 239 String SLST[] = new String[] {Greenwich Mean Time, GMT,
 240   Sierra Leone Summer Time, SLST,
 241   Sierra Leone Time, SLT};

 251 String WART[] = new String[] {Western Argentine Time, WART,
 252   Western Argentine Summer Time, 
WARST,
 253   Western Argentine Time, WART};

It seems these are no longer used.

-{Antarctica/Macquarie, new String[] {Macquarie Island Time, 
MIST,
-   Macquarie Island Summer Time, 
MIST,
+{Antarctica/Macquarie, new String[] {Macquarie Island Standard Time, 
MIST,
+   Macquarie Island Daylight Time, 
MIST,

The daylight saving time abbreviation should be MIDT.

Thanks,
Masayoshi

On 8/27/2014 10:53 PM, Aleksej Efimov wrote:

Masayoshi,
Thank you for a detailed review - I tried to address all your 
comments. Please, see the updated review: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03
About the workarounds - I will start discussion with Sherman when the 
tzdata2014f (and I suppose the 2014g - it will be available soon 
according to tzdata mail-list [1]) integration will be complete.


-Aleksej

[1] tzdata2014g is coming: 
http://mm.icann.org/pipermail/tz/2014-August/021528.html


On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote:

Here are additional comments.

src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java:

I'm concerned about the workarounds. It's not new in this update, but 
this problem would make tzupdater data void until the workaround is 
added to the next update release. Could you please work with Sherman 
to eliminate the workaround (outside of this 2014f update)?


src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:

 String LORD_HOWE[] = new String[] {Lord Howe Standard 
Time, LHST,
-   Lord Howe Summer Time, 
LHST,
+   Lord Howe Summer Time, 
LHDT,


The S-D convention is applied to Lord Howe as well.

 567 {Antarctica/Macquarie, new String[] {Macquarie 
Island Time, MIST,

 568 Macquarie Island Summer Time, MIST,
 569 Macquarie Island Time, MIST}},

This one should also follow the S-D convention, although this time 
zone doesn't observe daylight saving time.



+String XJT[] = new String[] {China Standard Time, XJT,
+ China Daylight Time, XJDT,
+ China Time, XJT};

Should the long names be based on Xinjiang?

Africa/Freetown is now a link to Africa/Abidjan. Those should be the 
same time zone.


-{America/Metlakatla, new String[] {Metlakatla 
Standard Time, MeST,
- Metlakatla 
Daylight Time, MeDT,
- Metlakatla Time, 
MeT}},
+{America/Metlakatla, new String[] {Metlakatla 
Standard Time, PST,
+ Metlakatla 
Daylight Time, PDT,
+ Metlakatla Time, 
PT}},


-{Europe/Volgograd, new String[] {Volgograd Time, 
VOLT,
-   Volgograd Summer 
Time, VOLST,
-   Volgograd Time, 
VOLT}},

+{Europe/Volgograd, new String[] {Volgograd Time, MSK,
+   Volgograd Summer 
Time, MSK,
+   Volgograd Time, 
MSK}},



The long names should be changed accordingly.

Thanks,
Masayoshi

On 8/22/2014 9:17 PM, Aleksej Efimov wrote:

Masayoshi,
You're right that the root names should be changed as part of this 
update. The names were changed according to Australian official 
document here: http://australia.gov.au/about-australia/our-country/time
The fixed version of the webrev can be found here: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02


Thanks,
Aleksej


On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote:
We used to make name changes in the root (base) bundle as part of 
time zone data maintenance and deter only translations. But if you 
want to handle name changes later, that would be fine. It's your call.


Thanks,
Masayoshi

On 8/21/2014 5:05 PM, Aleksej Efimov wrote:

Masayoshi,
I agree that we should change the long names to match the new 
short names introduced by tzdata.
But I suggest to log a different CR for such activity to handle 
long name changes and their translations (this activity is 
slightly out of tzdata update scope). Does it make sense?


-Aleksej

On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
I think the long names of the Australia time zones should be 
revisited to be consistent

Re: RFR: 8049343: (tz) Support tzdata2014f

[Masayoshi Okutsu]

We used to make name changes in the root (base) bundle as part of time 
zone data maintenance and deter only translations. But if you want to 
handle name changes later, that would be fine. It's your call.


Thanks,
Masayoshi

On 8/21/2014 5:05 PM, Aleksej Efimov wrote:

Masayoshi,
I agree that we should change the long names to match the new short 
names introduced by tzdata.
But I suggest to log a different CR for such activity to handle long 
name changes and their translations (this activity is slightly out of 
tzdata update scope). Does it make sense?


-Aleksej

On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
I think the long names of the Australia time zones should be 
revisited to be consistent with the abbreviation changes. The new 
abbreviations follow the S[tandard] and D[aylight saving] convention 
rather than the S[tandard] and S[ummer time] one. The long names, 
such as Eastern Summer Time (Queensland), no longer make sense.


On the other hand, you will need to access impact of the name 
changes, including abbreviations. Also, if you change the long names, 
their translations will need to be changed as well.


Thanks,
Masayoshi

On 8/20/2014 11:59 PM, Aleksej Efimov wrote:

Hi,

Please, review the tzdata2014f integration (with tzdata2014e related 
changes included too) [1] fix to JDK9: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/


The tzdata2014f changes are extensive and relates mostly to timezone 
short names changes + Asia/Srednekolymsk time zone were added.
Almost complete list of changes can be found in the JBS bug 
description [1], plus some changes wasn't documented in tzdata 
release notes - for such cases raw tzdata diff was used for the 
names modifications.


Two issues with JSR310 implementation were discovered during 
integration process:
First issue is related to the internal representation of the '24:00' 
value. The JSR310 implementation treats this value as a next day 
00:00 time. The workaround already exists in JSR310 code for similar 
entries and this failure is resolved in similar way [2] as part of 
this update.
For the second issue JDK-8051641 [3] was filled and 
'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one 
that fails with this tzdata.

Other time zone related tests [4] passes without failures.

Thank you,
Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-8049343
[2] 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch

[3] https://bugs.openjdk.java.net/browse/JDK-8051641
[4] TZ related test sets: test/sun/util/calendar 
test/java/util/Calendar test/sun/util/resources/TimeZone 
test/sun/util/calendar test/java/util/TimeZone test/java/time\ 
test/java/util/Formatter test/closed/java/util/Calendar 
test/closed/java/util/TimeZone

Re: RFR: 8049343: (tz) Support tzdata2014f

[Masayoshi Okutsu]

I think the long names of the Australia time zones should be revisited 
to be consistent with the abbreviation changes. The new abbreviations 
follow the S[tandard] and D[aylight saving] convention rather than the 
S[tandard] and S[ummer time] one. The long names, such as Eastern 
Summer Time (Queensland), no longer make sense.


On the other hand, you will need to access impact of the name changes, 
including abbreviations. Also, if you change the long names, their 
translations will need to be changed as well.


Thanks,
Masayoshi

On 8/20/2014 11:59 PM, Aleksej Efimov wrote:

Hi,

Please, review the tzdata2014f integration (with tzdata2014e related 
changes included too) [1] fix to JDK9: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/


The tzdata2014f changes are extensive and relates mostly to timezone 
short names changes + Asia/Srednekolymsk time zone were added.
Almost complete list of changes can be found in the JBS bug 
description [1], plus some changes wasn't documented in tzdata release 
notes - for such cases raw tzdata diff was used for the names 
modifications.


Two issues with JSR310 implementation were discovered during 
integration process:
First issue is related to the internal representation of the '24:00' 
value. The JSR310 implementation treats this value as a next day 00:00 
time. The workaround already exists in JSR310 code for similar entries 
and this failure is resolved in similar way [2] as part of this update.
For the second issue JDK-8051641 [3] was filled and 
'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one that 
fails with this tzdata.

Other time zone related tests [4] passes without failures.

Thank you,
Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-8049343
[2] 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch

[3] https://bugs.openjdk.java.net/browse/JDK-8051641
[4] TZ related test sets: test/sun/util/calendar 
test/java/util/Calendar test/sun/util/resources/TimeZone 
test/sun/util/calendar test/java/util/TimeZone test/java/time\ 
test/java/util/Formatter test/closed/java/util/Calendar 
test/closed/java/util/TimeZone

Re: RFR: 8042126: DateTimeFormatter MMMMM returns English value in Japanese locale

[Masayoshi Okutsu]

The root cause of this problem is the semantic difference between the 
legacy JRE resources and the CLDR-drived resources. The root CLDR 
resources have the narrow month names as numbers to be language-neutral, 
while the JRE root resources have them as English. If you specify 
Locale.ROOT, you will get the English ones rather than the numbers. That 
is somehow an intended behavior (or a known restriction).


The narrow names are supported only in java.time due to compatibility 
constraints with java.text. So the narrow month names should go to 
src/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java 
rather than FormatData_ja.java. There should be more locales which have 
the same problem.


Thanks,
Masayoshi

On 8/7/2014 7:42 AM, Naoto Sato wrote:

Looks good to me.

Naoto

On 8/5/14, 3:41 AM, dmeetry degrave wrote:

Hello,

Please review a simple fix (jdk 8 and 9) for

8042126: DateTimeFormatter M returns English value in Japanese 
locale


bug: https://bugs.openjdk.java.net/browse/JDK-8042126
fix: http://cr.openjdk.java.net/~dmeetry/8042126/webrev.01

thanks,
dmeetry

Re: RFR: 8042126: DateTimeFormatter MMMMM returns English value in Japanese locale

[Masayoshi Okutsu]

Sorry, I forgot about Calendar.getDisplayName. Perhaps the JRE semantic 
(Locale.ROOT is English) support for all narrow names should be given up.


I will take over this one because it will require some changes to the 
locale service provider framework.


Thanks,
Masayoshi

On 8/7/2014 11:38 AM, Masayoshi Okutsu wrote:
The root cause of this problem is the semantic difference between 
the legacy JRE resources and the CLDR-drived resources. The root CLDR 
resources have the narrow month names as numbers to be 
language-neutral, while the JRE root resources have them as English. 
If you specify Locale.ROOT, you will get the English ones rather than 
the numbers. That is somehow an intended behavior (or a known 
restriction).


The narrow names are supported only in java.time due to compatibility 
constraints with java.text. So the narrow month names should go to 
src/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java 
rather than FormatData_ja.java. There should be more locales which 
have the same problem.


Thanks,
Masayoshi

On 8/7/2014 7:42 AM, Naoto Sato wrote:

Looks good to me.

Naoto

On 8/5/14, 3:41 AM, dmeetry degrave wrote:

Hello,

Please review a simple fix (jdk 8 and 9) for

8042126: DateTimeFormatter M returns English value in Japanese 
locale


bug: https://bugs.openjdk.java.net/browse/JDK-8042126
fix: http://cr.openjdk.java.net/~dmeetry/8042126/webrev.01

thanks,
dmeetry

Re: RFR: 8044671: NPE from JapaneseEra when a new era is defined in calendar.properties

[Masayoshi Okutsu]

The copyright year range should be updated. Otherwise, the fix looks 
good to me.


Masayoshi

On 7/23/2014 11:51 PM, dmeetry degrave wrote:

Hello,

Please review a simple fix (jdk 8 and 9) for

8044671: NPE from JapaneseEra when a new era is defined in 
calendar.properties


bug: https://bugs.openjdk.java.net/browse/JDK-8044671
fix: http://cr.openjdk.java.net/~dmeetry/8044671/webrev.01

No automated regression test, unfortunately, it would require to 
modify private static final Era[] eras; in 
java/util/JapaneseImperialCalendar.java, though it's easy to test it 
by calling 'JapaneseDate date = JapaneseDate.of(2100,1,1);' with a new 
era added via JAVA_HOME/jre/lib/calendars.properties (test and 
calendars.properties are attached to the bug).


thanks,
dmeetry

Re: i18n dev 8037343 Ready for review

[Masayoshi Okutsu]

Looks good to me.

Thanks,
Masayoshi

On 5/15/2014 4:37 PM, Alan Bateman wrote:


Forwarding to i18n-dev as that it usually the list where changes to 
the locale and resources are maintained.


-Alan

On 15/05/2014 04:45, Sandipan Razzaque wrote:

Hi all,

Please find below the webrev for bug 8037343.

http://www.sandipan.net/public/webrevs/8037343/webrev.00

Thanks in advance -

Cheers,
SR

Sandipan Razzaque | www.sandipan.net

Re: i18n dev RFR: 8043012: (tz) Support tzdata2014c

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 5/15/2014 7:59 AM, Aleksej Efimov wrote:

Hello,

Can I have a review for the tzdata2014c integration to JDK9. This is a 
standard release of tzdata (except the hurry with Egypt rules - the 
main part in this release).

The following set of tests was executed with no failures:
test/sun/util/calendar test/java/util/Calendar 
test/sun/util/resources/TimeZone test/sun/util/calendar 
test/java/util/TimeZone

 test/java/time test/java/util/Formatter test/closed/java/util/Calendar

Webrev: http://cr.openjdk.java.net/~aefimov/8043012/9/webrev.00
Bug: https://bugs.openjdk.java.net/browse/JDK-8043012

Thank you,
Aleksej

Re: i18n dev Improve timezone mapping for AIX platform

[Masayoshi Okutsu]

 me try that  and also build/test on
Windows platform.


 3. regarding the changes proposed by Masayoshi: I agree
that we should
 put the AIX timezone mapping code in its own function, but
I don't
 think that getPlatformTimeZoneID() would be the right
place. As far as
 I understand, getPlatformTimeZoneID() is used to get a
platform time
 zone id if the environment variable TZ is not set. I
don't know a
 way how this could be done on AIX (@Jonathan: maybe you
know?). If
 there would be a way to get the time zone from some system
files or
 so, then we should put this code into the AIX version of
 getPlatformTimeZoneID().

 I guess we may try to use /etc/envrionment file, which is
basic setting
 for
 all processes,
 see



http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm
 The implementation of  getPlatformTimeZoneID() has been
updated.

 That's good!

 But the current AIX code contributed by Jonathan, actually
uses the
 time zone id from the TZ environment variable and just
maps it to a
 Java compatible time zone id. So I'd suggest to refactor
this code
 into a function like for example static const char*
 mapPlatformToJavaTimzone(const char* tz) and call that from
 findJavaTZ_md(). I think that would make the code easier to
 understand.

 Agree, and have split the code into a separate static
method to do the
 mapping work.

 Good. But there's still one error in findJavaTZ_md():

  706 #ifdef _AIX
  707 javatz =
mapPlatformToJavaTimezone(java_home_dir, tz);
  708 #endif

 This should read:

  706 #ifdef _AIX
  707 javatz =
mapPlatformToJavaTimezone(java_home_dir, javatz);
  708 #endif

 because in line 703 you free 'tz' via its alias 'freetz' if
'tz' came
 from getPlatformTimeZoneID().


 Right, but with the second approach, there may be a minor
memory leak
 here,
 as javatz was not freed before being overwritten on AIX.
will post another
 patch on this soon.


 With the above fixed I'll push this one we get one more
review from a
 reviewer (I'm currently not an official reviewer).

 Regards,
 Volker


 @Masayoshi: what do you think, would you agree with such a
solution.

 4. I agree with Masayoshi that you should use the existing
 getGMTOffsetID()

 Updated in new patch to eliminate duplication.

 5. Please notice that your change breaks all Unix builds
except AIX
 because of:

  759 }
  760 tzerr:
  761 if (javatz == NULL) {
  762 time_t offset;
 ...
  782 }
  783 #endif

 I think that should read:

  759
  760 tzerr:
  761 if (javatz == NULL) {
  762 time_t offset;
 ...
  782 }
  783 #endif
  784 }

 Refactoring the code in an extra function will make that
error more
 evident anyway.

 But please always build at least on one different platform
(i.e.
 Linux) to prevent such errors in the future.

 My fault, sorry for the failure, should take no chance
after any manual
 alteration.

 Regards,
 Volker


 On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu
 masayoshi.oku...@oracle.com
mailto:masayoshi.oku...@oracle.com wrote:

 Hi Jonathan,

 The AIX specific code looks OK to me. But I'd suggest the
code be moved
 to
 getPlatformTimeZoneID() for AIX, which just returns NULL
currently. Also
 there's a function for producing a fallback ID in GMT±hh:mm,
 getGMTOffsetID() which can be called in tzerr.

 Thanks,
 Masayoshi


 On 3/26/2014 3:47 PM, Jonathan Lu wrote:

 Hi ppc-aix-port-dev, core-libs-dev,

 Here's a patch for JDK-8034220,

 http://cr.openjdk.java.net/~luchsh/JDK-8034220/
http://cr.openjdk.java.net/%7Eluchsh/JDK-8034220/

 It is trying to add the a more complete timezone mapping
mechanism for
 AIX

Re: i18n dev RFR: 8038306: (tz) Support tzdata2014b

[Masayoshi Okutsu]

Another option would be Troll Station Time and TST. But your 
invention is fine with me.


Thanks,
Masayoshi

On 4/4/2014 9:19 PM, Aleksej Efimov wrote:

Masayoshi,

The new webrev with proposed generic names for Antarctica/Troll can be 
found here: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.01


Thank you,
Aleksej

On 04/03/2014 06:29 PM, Aleksej Efimov wrote:

Masayoshi,
How about Troll Time and ATT for generic long and short names 
across all locales? The TT is used as generic name for 
Asia/Taipei in zh_TW locale, because of that I propose ATT (A - 
for Antractica) - it's not used anywhere.


Thanks,
Aleksej

On 04/03/2014 06:21 PM, Masayoshi Okutsu wrote:

Hi Aleksej,

Sorry, but I forgot about the generic names. Coordinated Universal 
Time and UTCshouldn't be the generic names. You will need to 
invent the names, something like Troll Time.


Thanks,
Masayoshi

On 4/2/2014 7:55 PM, Aleksej Efimov wrote:

Hello,

Can I have a review for the latest (2014b) TZ data integration to 
JDK9. The webrev can be located here [1].


The following set of tests were executed without failures:
test/sun/util/calendar test/java/util/Calendar 
test/sun/util/resources/TimeZone test/sun/util/calendar 
test/java/util/TimeZone test/java/time test/java/util/Formatter 
test/closed/java/util/Calendar\ test/closed/java/util/TimeZone


Thank you,
Aleksej

[1] Webrev: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.00/
[2] BUG: https://bugs.openjdk.java.net/browse/JDK-8038306

Re: i18n dev RFR: 8038306: (tz) Support tzdata2014b

[Masayoshi Okutsu]

Hi Aleksej,

Sorry, but I forgot about the generic names. Coordinated Universal 
Time and UTCshouldn't be the generic names. You will need to invent 
the names, something like Troll Time.


Thanks,
Masayoshi

On 4/2/2014 7:55 PM, Aleksej Efimov wrote:

Hello,

Can I have a review for the latest (2014b) TZ data integration to 
JDK9. The webrev can be located here [1].


The following set of tests were executed without failures:
test/sun/util/calendar test/java/util/Calendar 
test/sun/util/resources/TimeZone test/sun/util/calendar 
test/java/util/TimeZone test/java/time test/java/util/Formatter 
test/closed/java/util/Calendar\ test/closed/java/util/TimeZone


Thank you,
Aleksej

[1] Webrev: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.00/
[2] BUG: https://bugs.openjdk.java.net/browse/JDK-8038306

Re: Improve timezone mapping for AIX platform

[Masayoshi Okutsu]

Hi Volker,

You are right. The `tz' value needs to be given to 
getPlatformTimeZoneID() or the getenv() call should be moved to the 
function. Your mapPlatformToJavaTimzone(const char* tz) sounds good to me.


In any case TimeZone_md.c has become too messy by accumulating 
platform/release-specific code. I guess it's time to clean up...


Thanks,
Masayoshi

On 3/27/2014 2:48 AM, Volker Simonis wrote:

Hi Jonathan,

thanks for doing this change. Please find some comments below:

1. please update the copyright year to 2014 in every file you touch

2. in CopyFiles.gmk you can simplify the change by joining the windows
and aix cases because on Windows OPENJDK_TARGET_OS is the same like
OPENJDK_TARGET_OS_API_DIR. So you can write:

ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), )

   TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib

   $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings
 $(call install-file)

   COPY_FILES += $(LIBDIR)/tzmappings

endif

3. regarding the changes proposed by Masayoshi: I agree that we should
put the AIX timezone mapping code in its own function, but I don't
think that getPlatformTimeZoneID() would be the right place. As far as
I understand, getPlatformTimeZoneID() is used to get a platform time
zone id if the environment variable TZ is not set. I don't know a
way how this could be done on AIX (@Jonathan: maybe you know?). If
there would be a way to get the time zone from some system files or
so, then we should put this code into the AIX version of
getPlatformTimeZoneID().

But the current AIX code contributed by Jonathan, actually uses the
time zone id from the TZ environment variable and just maps it to a
Java compatible time zone id. So I'd suggest to refactor this code
into a function like for example static const char*
mapPlatformToJavaTimzone(const char* tz) and call that from
findJavaTZ_md(). I think that would make the code easier to
understand.

@Masayoshi: what do you think, would you agree with such a solution.

4. I agree with Masayoshi that you should use the existing getGMTOffsetID()

5. Please notice that your change breaks all Unix builds except AIX because of:

  759 }
  760 tzerr:
  761 if (javatz == NULL) {
  762 time_t offset;
...
  782 }
  783 #endif

I think that should read:

  759
  760 tzerr:
  761 if (javatz == NULL) {
  762 time_t offset;
...
  782 }
  783 #endif
  784 }

Refactoring the code in an extra function will make that error more
evident anyway.

But please always build at least on one different platform (i.e.
Linux) to prevent such errors in the future.

Regards,
Volker


On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu
masayoshi.oku...@oracle.com wrote:

Hi Jonathan,

The AIX specific code looks OK to me. But I'd suggest the code be moved to
getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also
there's a function for producing a fallback ID in GMT±hh:mm,
getGMTOffsetID() which can be called in tzerr.

Thanks,
Masayoshi


On 3/26/2014 3:47 PM, Jonathan Lu wrote:

Hi ppc-aix-port-dev, core-libs-dev,

Here's a patch for JDK-8034220,

http://cr.openjdk.java.net/~luchsh/JDK-8034220/

It is trying to add the a more complete timezone mapping mechanism for AIX
platform.
the changes are primarily based on IBM's commercial JDK code, which
includes:

- A new timezone mapping file added under directory jdk/src/aix/lib/
- Code to parse above config file, changed file is
src/solaris/native/java/util/TimeZone_md.c
- And also makefile change in make/CopyFiles.gmk to copy the config file

Could you pls help to review and give comments ?

Cheers
- Jonathan

Re: Improve timezone mapping for AIX platform

[Masayoshi Okutsu]

Hi Jonathan,

The AIX specific code looks OK to me. But I'd suggest the code be moved 
to getPlatformTimeZoneID() for AIX, which just returns NULL currently. 
Also there's a function for producing a fallback ID in GMT±hh:mm, 
getGMTOffsetID() which can be called in tzerr.


Thanks,
Masayoshi

On 3/26/2014 3:47 PM, Jonathan Lu wrote:

Hi ppc-aix-port-dev, core-libs-dev,

Here's a patch for JDK-8034220,

http://cr.openjdk.java.net/~luchsh/JDK-8034220/

It is trying to add the a more complete timezone mapping mechanism for AIX
platform.
the changes are primarily based on IBM's commercial JDK code, which
includes:

- A new timezone mapping file added under directory jdk/src/aix/lib/
- Code to parse above config file, changed file is
src/solaris/native/java/util/TimeZone_md.c
- And also makefile change in make/CopyFiles.gmk to copy the config file

Could you pls help to review and give comments ?

Cheers
- Jonathan

Re: i18n dev RFR: 8037012: (tz) Support tzdata2014a

[Masayoshi Okutsu]

+1

Masayoshi

On 3/13/2014 9:18 PM, Seán Coffey wrote:

Looks good to me.

regards,
Sean.

On 12/03/2014 15:05, Aleksej Efimov wrote:

Hello,

Can I have a review for a tzdata2014a [1] integration to JDK9: 
http://cr.openjdk.java.net/~aefimov/8037012/9/webrev.00

The following test sets were executed on the build with latest tzdata:
test/sun/util/calendar test/java/util/Calendar 
test/sun/util/resources/TimeZone test/sun/util/calendar 
test/java/util/TimeZone test/java/time test/java/util/Formatter 
test/closed/java/util/Calendar test/closed/java/util/TimeZone


One test failure was observed - see the bug report for details: [2]. 
The review for this test failure fix will be sent in a few moments.

Other tests passes.

Thank you,
Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-8037012
[2] https://bugs.openjdk.java.net/browse/JDK-8037180

Re: i18n dev RFR: 8037180: [TEST_BUG] test/sun/util/calendar/zi/Zoneinfo.java incorrectly calculates raw GMT offset change time

[Masayoshi Okutsu]

+1

Masayoshi

On 3/13/2014 9:19 PM, Seán Coffey wrote:
Looks good Aleksej. A future rule change doesn't necessarily mean a 
new GMT offset change. Original test logic seemed buggy.


regards,
Sean.

On 12/03/2014 15:06, Aleksej Efimov wrote:

Hello,

Can I have a review for a 'test/sun/util/calendar/zi/Zoneinfo.java' 
test bug failure [1] related to the latest tzdata2014a integration [2].

The test failure message:
Asia/Istanbul : Asia/Istanbul
offset=720,dstSavings=360,useDaylight=true,transitions=171,offsets=5,checksum=-508379603,gmtChanged=false 

[NG]offset=720,dstSavings=360,useDaylight=true,transitions=171,offsets=5,checksum=-508379603,gmtChanged=true 


--System.err:(13/732)--
java.lang.RuntimeException:   FAILED:  Asia/Istanbul
at TestZoneInfo310.main(TestZoneInfo310.java:170)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:484)
at 
com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)

at java.lang.Thread.run(Thread.java:744)

This failure caused by the following entry in test tzdata files:
ZoneEurope/Istanbul 1:55:52 -   LMT 1880
1:56:56 -   IMT 1910 Oct # Istanbul 
Mean Time?

2:00Turkey  EE%sT   1978 Oct 15
3:00Turkey  TR%sT   1985 Apr 20 # Turkey 
Time

2:00Turkey  EE%sT   2007
2:00EU  EE%sT   2011 Mar 27 1:00u
2:00-   EET 2011 Mar 28 1:00u
2:00EU  EE%sT   2014 Mar 30 1:00u
2:00-   EET 2014 Mar 31 1:00u
2:00EU  EE%sT

The raw GMT offset here is constant=2:00 and not changed since 1985 
Apr 20. But the test code 'test/sun/util/calendar/zi' shows that 
there will be a future raw GMT offset change. The following fix 
resolves this problem: 
http://cr.openjdk.java.net/~aefimov/8037180/9/webrev.00/


-Aleksej


[1] https://bugs.openjdk.java.net/browse/JDK-8037180
[2] https://bugs.openjdk.java.net/browse/JDK-8037012

Re: i18n dev RFR: 8030822: (tz) Support tzdata2013i

[Masayoshi Okutsu]

Looks good.

Masayoshi

On 1/30/2014 5:31 AM, Aleksej Efimov wrote:

Masayoshi, Sean,
Thank you for the review and your comments.

I have prepared a second version of the fix [1] without the 
.properties files. These files are used in 
test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java 
test and because of that this test was removed also.


Thank you,
Aleksej

[1] http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.01/ 
http://cr.openjdk.java.net/%7Eaefimov/8030822/9/webrev.01/



On 01/23/2014 08:43 AM, Masayoshi Okutsu wrote:

Hi Aleksej,

I think this one is the first tzdata change for JDK9. So I'd suggest 
that all the TimeZoneNames*.properties files, which were temporarily 
created for the translation work, be removed.


Thanks,
Masayoshi

On 1/21/2014 10:17 PM, Aleksej Efimov wrote:

Hi,
Can I have a review for 2013i timezone data integration [1] to JDK9.
There is one change in tzdb that affects naming for Asia/Amman 
timezone:
The Jordan switches back to standard time at 00:00 on December 
20, 2013.
All changes in TimeZoneNames*.java and TimeZoneNames*.properties 
files are related to this one tzdb change.


The list of executed regression test sets: test/sun/util/calendar 
test/java/util/Calendar test/sun/util/resources/TimeZone 
test/sun/util/calendar test/java/util/TimeZone test/java/time 
test/java/util/Formatter test/closed/java/util/Calendar 
test/closed/java/util/TimeZone

All tests gave PASS result.

Webrev location: 
http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.00/


Thank you,
Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-8030822

Re: i18n dev RFR: 8030822: (tz) Support tzdata2013i

[Masayoshi Okutsu]

Hi Aleksej,

I think this one is the first tzdata change for JDK9. So I'd suggest 
that all the TimeZoneNames*.properties files, which were temporarily 
created for the translation work, be removed.


Thanks,
Masayoshi

On 1/21/2014 10:17 PM, Aleksej Efimov wrote:

Hi,
Can I have a review for 2013i timezone data integration [1] to JDK9.
There is one change in tzdb that affects naming for Asia/Amman 
timezone:
The Jordan switches back to standard time at 00:00 on December 
20, 2013.
All changes in TimeZoneNames*.java and TimeZoneNames*.properties files 
are related to this one tzdb change.


The list of executed regression test sets: test/sun/util/calendar 
test/java/util/Calendar test/sun/util/resources/TimeZone 
test/sun/util/calendar test/java/util/TimeZone test/java/time 
test/java/util/Formatter test/closed/java/util/Calendar 
test/closed/java/util/TimeZone

All tests gave PASS result.

Webrev location: http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.00/

Thank you,
Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-8030822

Re: i18n dev RFR: 8025051: Update resource files for TimeZone display names

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 12/23/2013 3:14 AM, Aleksej Efimov wrote:

Hi,
The new version of patch for TimeZone display names update is 
available. Previous webrev contains incorrect naming for Acre timezone 
generic name (ACT[] array) across all non-root locales. The name was 
corrected and test TimeZoneNames_*.properties files were modified 
accordingly.
The new webrev: 
http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.02/ 
http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.02/


-Aleksej

On 12/20/2013 03:39 PM, Aleksej Efimov wrote:

Masayoshi,
Thank you for the detailed review and your comments. I tried to 
address all of them. The responses are below. The new webrev can be 
found here: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.01/ 
http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.01/


Michael,
As Masayoshi mentioned, we have a list of inconsistent translations 
in translation files. I suggest two approaches to resolve it: 1. Log 
different bug with all problems in translation files. 2. Wait for the 
next resource file translation update to address these problems.


-Aleksej

On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote:

On 12/18/2013 6:43 PM, Aleksej Efimov wrote:

Hi,

Please help to review a fix [1] for 8025051 bug [2]. The following 
fix includes:


Common to all modified files:
- All year ranges in the copyright header should be modified 
accordingly.


Fixed.



 - The translation of time zone generic names were added to all 
locales.


I haven't fully reviewed translations, especially all \u 
strings. But I noticed the following.


Common to all TimeZoneNames_*.java:
- The same generic abbreviation is used for the long name in MET. I 
thought this was fixed in the root properties...


No, the MET is used in root properties both for generic long and 
short names. I will update these names when new translation update 
will be available.


- Some generic names don't match the style of their standard and/or 
daylight time names.


The same as previous. This is a first large update for generic names 
and latest translations. All inconsistency in translations will be 
fixed during next translation update.




src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
- Some generic names use Normalzeit. Is that OK?


It's not good. But the resolution is same as previous two.



src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
- Chuuk Time isn't translated.


I think it will be translated in next translations update.




 - Time Zone names were updated according to the latest translations.
 - Added tz names regression test 
(test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone 
names across all locales. This test compares short/long 
standard/daylight/generic names with translations stored in 
.properties files.


test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:

- lines 33, 34: unused imports?


Removed


- line 75: Should it be detected as an error?


Agree, now the test will fail if there is some incorrect entries in 
the test .properties files.


- line 108: IOException should be used as a cause. (OK to assume 
not found?)


The IOException cause is added. Currently, the test will stop with 
RuntimeException, because the test file is not found.


- lines 118 -121: Locale.getDefault() has to be replaced with 
Locale.ROOT. Regression tests are run in different locales.


Thank you for catching this one. Fixed.



 - Tests updates to address current changes ( 
GenericTimeZoneNamesTest.sh and Bug6317929.java).


The TODO comment in GenericTimeZoneNamesTest.sh should fully been 
removed.


Removed





The following fix was tested with JPRT build and the 'jdk_util' 
test set succeeded (new test is included in this test set).


Have you executed all date-time related regression tests (including 
java.time and java.text)?


Yes, I have executed the following set of tests via JTREG:
test/sun/util/calendar test/java/util/Calendar 
test/sun/util/resources/TimeZone test/sun/util/calendar 
test/closed/java/util/TimeZone test/java/util/TimeZone

 test/java/time  test/java/util/Formatter test/closed/java/util/Calendar
All tests gave PASS results.
Please, let me know if you think that some other tests should be 
executed.





Thanks,
Masayoshi



[1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
[2] https://bugs.openjdk.java.net/browse/JDK-8025051

Re: i18n dev RFR: 8025051: Update resource files for TimeZone display names

[Masayoshi Okutsu]

On 12/18/2013 6:43 PM, Aleksej Efimov wrote:

Hi,

Please help to review a fix [1] for 8025051 bug [2]. The following fix 
includes:


Common to all modified files:
- All year ranges in the copyright header should be modified accordingly.


 - The translation of time zone generic names were added to all locales.


I haven't fully reviewed translations, especially all \u strings. 
But I noticed the following.


Common to all TimeZoneNames_*.java:
- The same generic abbreviation is used for the long name in MET. I 
thought this was fixed in the root properties...
- Some generic names don't match the style of their standard and/or 
daylight time names.


src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
- Some generic names use Normalzeit. Is that OK?

src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
- Chuuk Time isn't translated.


 - Time Zone names were updated according to the latest translations.
 - Added tz names regression test 
(test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone names 
across all locales. This test compares short/long 
standard/daylight/generic names with translations stored in 
.properties files.


test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:

- lines 33, 34: unused imports?
- line 75: Should it be detected as an error?
- line 108: IOException should be used as a cause. (OK to assume not 
found?)
- lines 118 -121: Locale.getDefault() has to be replaced with 
Locale.ROOT. Regression tests are run in different locales.


 - Tests updates to address current changes ( 
GenericTimeZoneNamesTest.sh and Bug6317929.java).


The TODO comment in GenericTimeZoneNamesTest.sh should fully been removed.



The following fix was tested with JPRT build and the 'jdk_util' test 
set succeeded (new test is included in this test set).


Have you executed all date-time related regression tests (including 
java.time and java.text)?


Thanks,
Masayoshi



[1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
[2] https://bugs.openjdk.java.net/browse/JDK-8025051

Re: i18n dev RFR: 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing

[Masayoshi Okutsu]

The test detected the translation changes as regression, but that was 
unnecessary? I prefer to remove this test rather than changing the data.


Thanks,
Masayoshi

On 10/24/2013 12:12 AM, Michael Fang wrote:

Hi Masayoshi,

At that time I was asked to have regression test to validate each 
translation changes.


With our new translation process for TimeZoneNames and new planned 
regression tests from Aleksej for JDK-8025051 
https://bugs.openjdk.java.net/browse/JDK-8025051, I believe we can 
remove those unnecessary tests in the future (probably together with 
JDK-8025051 https://bugs.openjdk.java.net/browse/JDK-8025051).


For now,  webrev [2] looks fine to take care of the short term 
regression failure.


thanks,

-michael

On 13?10?22? 09:29 ??, Masayoshi Okutsu wrote:

Hi Michael,

  27  *@summary Test case for tzdata2005m support for 9 locales

What's the purpose of this test? Do we really need to keep this one?

Thanks,
Masayoshi

On 10/22/2013 8:13 PM, Aleksej Efimov wrote:

Hi,
Can I have a review for 8026772 [1] fix.
The webrev link: [2]
The timezone test is failed because of the changed TimeZone names 
introduced in 8025255 [3].
This timezone names were changed according to updated translation 
resource files introduced by 8025215 [4].


The fix changes the hard-coded time zone names for 
Australia/Currie to the values specified in 8025215.


Thanks in Advance,
Aleksej

[1] http://bugs.sun.com/view_bug.do?bug_id=8026772
[2] http://cr.openjdk.java.net/~aefimov/8026772/webrev.00/
[3] http://bugs.sun.com/view_bug.do?bug_id=8025255
[4] http://bugs.sun.com/view_bug.do?bug_id=8025215

Re: i18n dev RFR: 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing

[Masayoshi Okutsu]

Hi Michael,

  27  *@summary Test case for tzdata2005m support for 9 locales

What's the purpose of this test? Do we really need to keep this one?

Thanks,
Masayoshi

On 10/22/2013 8:13 PM, Aleksej Efimov wrote:

Hi,
Can I have a review for 8026772 [1] fix.
The webrev link: [2]
The timezone test is failed because of the changed TimeZone names 
introduced in 8025255 [3].
This timezone names were changed according to updated translation 
resource files introduced by 8025215 [4].


The fix changes the hard-coded time zone names for Australia/Currie 
to the values specified in 8025215.


Thanks in Advance,
Aleksej

[1] http://bugs.sun.com/view_bug.do?bug_id=8026772
[2] http://cr.openjdk.java.net/~aefimov/8026772/webrev.00/
[3] http://bugs.sun.com/view_bug.do?bug_id=8025255
[4] http://bugs.sun.com/view_bug.do?bug_id=8025215

Re: i18n dev RFR: 8025255: (tz) Support tzdata2013g

[Masayoshi Okutsu]

Hi Aleksej and Michael,

TimeZoneNames_de.java:

-String DARWIN[] = new String[] {Zentrale Normalzeit (Northern Territory), 
CST,
+String DARWIN[] = new String[] {Central Normalzeit (Northern Territory), 
CST,

Is this change correct?

BTW, is there any reason to change lower case to upper case for the 
\u notation?


Thanks,
Masayoshi

On 10/14/2013 6:36 PM, Aleksej Efimov wrote:

Hi,
The second item is dropped - I was informed in a parallel review 
thread, that I can have one approval from a Reviewer and another 
approval[s] from members.
The hg patch was updated and located here: 
http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch 
http://cr.openjdk.java.net/%7Eaefimov/8025255/8/8025255_jdk8.patch


Can I ask for a sponsor help to push this fix?

Thank you and Best Regards,
Aleksej

On 10/13/2013 02:23 PM, Aleksej Efimov wrote:

Michael, Masayoshi,

Looks like, we can commit this changes with following items in mind:
1. Generic names in TimeZoneNames_*.java should be added as part of
JDK-8025051 resolution.
2. I need another one approval from a JDK 8 reviewer for this one.

Anyway, the hg changeset patch can be found here:
http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch

Best Regards,
Aleksej

On 10/12/2013 12:43 AM, Michael Fang wrote:

Hi Aleksej,

Yes, you are right. They can be handled separately. Thanks!

Regards,

Michael
Sent from my iPhone

On Oct 11, 2013, at 12:20 PM, Aleksej Efimovaleksej.efi...@oracle.com  wrote:


Hi Michael,
As I can see this topic was touched a little 
here:http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html.
 AFAIU from the above discussion the CLDR generic names were translated in all 
locales, but the legacy JRE time zone names doesn't contain this translations.  
And actually we already have opened bug for this 
task:https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right 
after the tzdata update and it will include this changes.
But anyway, it's not highly related to tzdata updates. I think, this two 
processes can go separately. Do you agree?

Thanks and Best Regards,
Aleksej

On 11.10.2013 21:41, Michael Fang wrote:

Hi Aleksej,

I took a look at the localized TimeZoneNames_*.java files. They do not contain 
generic time zone names for JSR310...

I think we can file a separate bug to track that issue.

thanks,

-michael

On 13年10月10日 09:54 下午, Masayoshi Okutsu wrote:

Hi Aleksej,

Here are my review comments.

- The copyright header of the data files shouldn't be removed.

- TimeZoneNames.java:

- Middle Europe Time, MET}},
+ MET, MET}},

I don't think the long name should be changed.

I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK 
with them, I'm fine.

Thanks,
Masayoshi

On 10/10/2013 10:30 PM, Aleksej Efimov wrote:

Hi,

Please, review the changes [1] needed to address the tz data update in JDK 8 
from tzdata2013d to tzdata2013g.

The brief list of changes:
1. tzdata2013g data was integrated to tzdb data files 
(make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files 
(test/sun/util/calendar/zi/tzdata/* changes).
2. a) Updates to long time zone names
b) Updates to short name changes to address corresponding changes in 
tzdata2013e(WIT/CIT/EIT/WARST - WIB/WITA/WIT/ART)
c) Removed unused ACT[] array
d) Added Europe/Busingen time zone name
All this changes a)-d) relates to 
src/share/classes/sun/util/resources/TimeZoneNames*.java files

The following tests were executed on JDK 8 with fix:
test/java/util/TimeZone
test/java/util/Calendar
test/java/util/Formatter
test/sun/util/calendar
test/java/time

Testing result: All test passed

Thanks!
Aleksej

[1]http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/  
http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/

Re: RFR: 8025255: (tz) Support tzdata2013g

[Masayoshi Okutsu]

Hi Aleksej,

Here are my review comments.

- The copyright header of the data files shouldn't be removed.

- TimeZoneNames.java:

-  Middle Europe Time, MET}},
+  MET, MET}},

I don't think the long name should be changed.

I didn't review the localized TimeZoneNames_*.java files. If L10N Team 
is OK with them, I'm fine.


Thanks,
Masayoshi

On 10/10/2013 10:30 PM, Aleksej Efimov wrote:

Hi,

Please, review the changes [1] needed to address the tz data update in 
JDK 8 from tzdata2013d to tzdata2013g.


The brief list of changes:
1. tzdata2013g data was integrated to tzdb data files 
(make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data 
files (test/sun/util/calendar/zi/tzdata/* changes).

2. a) Updates to long time zone names
b) Updates to short name changes to address corresponding changes 
in tzdata2013e(WIT/CIT/EIT/WARST - WIB/WITA/WIT/ART)

c) Removed unused ACT[] array
d) Added Europe/Busingen time zone name
All this changes a)-d) relates to 
src/share/classes/sun/util/resources/TimeZoneNames*.java files


The following tests were executed on JDK 8 with fix:
test/java/util/TimeZone
test/java/util/Calendar
test/java/util/Formatter
test/sun/util/calendar
test/java/time

Testing result: All test passed

Thanks!
Aleksej

[1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ 
http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/

hg: jdk8/tl/jdk: 6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010

[masayoshi . okutsu]

Changeset: 914c29c10bce
Author:okutsu
Date:  2013-10-02 15:31 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/914c29c10bce

6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010
Reviewed-by: peytoia

! src/share/classes/java/util/GregorianCalendar.java
+ test/java/util/Calendar/Bug6902861.java

hg: jdk8/tl/jdk: 8022666: java.util.Calendar.set(int, int, int, int, int, int) documentation typo

[masayoshi . okutsu]

Changeset: 82e3150778e0
Author:okutsu
Date:  2013-10-02 17:57 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82e3150778e0

8022666: java.util.Calendar.set(int,int,int,int,int,int) documentation typo
Reviewed-by: peytoia

! src/share/classes/java/util/Calendar.java

hg: jdk8/tl/jdk: 8024141: Unexpected timezone display name

[masayoshi . okutsu]

Changeset: 13ee370ee8b3
Author:okutsu
Date:  2013-09-11 15:29 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13ee370ee8b3

8024141: Unexpected timezone display name
Reviewed-by: peytoia

! src/share/classes/sun/util/locale/provider/LocaleResources.java
+ test/sun/util/locale/provider/Bug8024141.java

Re: i18n dev java.util.Locale changes

[Masayoshi Okutsu]

I took a look at the implementation. The matcher code just iterates the 
given priority list. isEmpty() is used, but it shouldn't be a problem. 
As far as an Iterable gives an Iterator which consistently iterates 
elements based on the priority or weight, the Iterable works.


Use of Iterable does give more flexibility, but I'm not sure how much it 
would add value to the API use. You can implement your own Iterable, but 
would many developers implement an Iterable to give a language priority 
list?


Masayoshi

On 2013/08/29 5:42, Alan Bateman wrote:

On 28/08/2013 14:25, Masayoshi Okutsu wrote:

(adding core-libs-dev)

Hi Christian,

RFC 4647 defines The Language Priority List [1]. The use of 
java.util.List would be a natural fit, which is the reason why List 
is used. But use of Iterable does work (as API design). The parameter 
name `priorityIterable' sounds a bit odd, though.


Does use of Iterable add much value to the API? (Please note that 
List is also used in Locale.LanguageRange.)


It depends on the usages but Iterable would be a bit more flexible. 
Does the locale matcher require to do anything except iterate over the 
elements? The return could be looked at it but it depends on the 
typical usage -- would the user of the API typically just iterate over 
the matched Locales?


-Alan.

Re: i18n dev java.util.Locale changes

[Masayoshi Okutsu]

(adding core-libs-dev)

Hi Christian,

RFC 4647 defines The Language Priority List [1]. The use of 
java.util.List would be a natural fit, which is the reason why List is 
used. But use of Iterable does work (as API design). The parameter name 
`priorityIterable' sounds a bit odd, though.


Does use of Iterable add much value to the API? (Please note that List 
is also used in Locale.LanguageRange.)


Thanks,
Masayoshi

[1] http://tools.ietf.org/html/rfc4647#section-2.3

On 2013/08/28 18:31, Christian Beikov wrote:

Hello there,

I have just seen the changes you want to apply to java.util.Locale in 
JDK 8 and was wondering why you are forcing the use of a 
java.util.List in the lookup and filter methods. The related methods 
of java.util.Locale are


public static Locale lookup(ListLocale.LanguageRange priorityList, 
CollectionLocale locales)
public static String lookupTag(ListLocale.LanguageRange 
priorityList, CollectionString tags)
public static ListString filterTags(ListLocale.LanguageRange 
priorityList, CollectionString tags)
public static ListString filterTags(ListLocale.LanguageRange 
priorityList, CollectionString tags, Locale.FilteringMode mode)
public static ListLocale filter(ListLocale.LanguageRange 
priorityList, CollectionLocale locales)
public static ListLocale filter(ListLocale.LanguageRange 
priorityList, CollectionLocale locales, Locale.FilteringMode mode)


which could be changed to

public static Locale lookup(IterableLocale.LanguageRange 
priorityIterable, CollectionLocale locales)
public static String lookupTag(IterableLocale.LanguageRange 
priorityIterable, CollectionString tags)
public static ListString filterTags(IterableLocale.LanguageRange 
priorityIterable, CollectionString tags)
public static ListString filterTags(IterableLocale.LanguageRange 
priorityIterable, CollectionString tags, Locale.FilteringMode mode)
public static ListLocale filter(IterableLocale.LanguageRange 
priorityIterable, CollectionLocale locales)
public static ListLocale filter(IterableLocale.LanguageRange 
priorityIterable, CollectionLocale locales, Locale.FilteringMode mode)


The use of java.util.Collection would also be ok.
One could also use a java.util.Set or something similar to represent 
the language ranges. I just wanted to provide that feedback if anyone 
cares. I am also ok with java.util.List but since you are only relying 
on the iteration order of the priorityList I was curious about the 
reason.

Re: i18n dev Additional source to guess the local timezone ID on linux

[Masayoshi Okutsu]

Hi Omair,

/etc/sysconfig/clock used to be supported, but it was removed in JDK 7. 
The problem is discussed in bug #6456628.


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

Have you tested your fix on all Red Hat-like distros, including some 
older releases, with all the time zone IDs?


Thanks,
Masayoshi

On 8/26/2013 5:40 PM, Alan Bateman wrote:


Including i18n-dev on this discussion because that is where this code 
is maintained.



On 23/08/2013 22:09, Omair Majid wrote:

Hi,

The algorithm that OpenJDK uses to guess the local timezone ID on Linux
goes like this:

1. If TZ environment variable is set, use that
2. If /etc/timezone is readable, read the time zone from there
3. If /etc/localtime is a symlink, resolve that, and use the name to
guess the time zone.
4. Scan /usr/share/zoneinfo for a file whose contents match the contents
of /etc/localtime.

Step 4 (if it is ever reached) is probably going to lead to incorrect
results since there are a number of timezones that have the same
zoneinfo data (such as Europe/London and Europe/Belfast). So it seems
sensible to me to try and use additional sources to guess the timezone
ID before resorting to file content comparisons.

The webrev adds a step between 2 and 3 that reads and parses
/etc/sysconfig/clock to extract the timezone:

http://cr.openjdk.java.net/~omajid/webrevs/timezone-read-sysconfig-clock/00/ 



This file exists on some Red Hat Enterprise Linux (and derivative)
distributions and contains contents that look this:

# The time zone of the system is defined by the contents of 
/etc/localtime.
# This file is only for evaluation by system-config-date, do not 
rely on its

# contents elsewhere.
ZONE=Europe/Zurich

With this, we should be able to identify the exact timezone ID.

Thanks,
Omair

Re: RFR: 6614237: missing codepage Cp290 at java runtime

[Masayoshi Okutsu]

Looks good.

Masayoshi

On 8/9/2013 4:19 AM, Xueming Shen wrote:

Thanks Masayoshi, good catch, yes, those two aliases should be included.
Webrev has been updated according.

webrev:
http://cr.openjdk.java.net/~sherman/6614237/webrev/

-Sherman

On 08/04/2013 10:17 PM, Masayoshi Okutsu wrote:

Hi Sherman,

IANA seems to define the following aliases for IBM290.

cp290
EBCDIC-JP-kana
csIBM290

The alias table should include EBCDIC-JP-kana and csIBM290 as well?

Otherwise, the changes look good to me.

Thanks,
Masayoshi

On 8/3/2013 5:53 AM, Xueming Shen wrote:

Masayoshi,

Would you please help review this change? The changeset also adds 
the requested Cp300.


webrev:
http://cr.openjdk.java.net/~sherman/6614237/webrev/

original mapptables:
http://cr.openjdk.java.net/~sherman/6614237/290/
http://cr.openjdk.java.net/~sherman/6614237/300/

regression tests:
http://cr.openjdk.java.net/~sherman/6614237/closed

Thanks!
-Sherman

hg: jdk8/tl/jdk: 8015986: Incorrect Localization of HijrahChronology

[masayoshi . okutsu]

Changeset: 0beaa65c90c8
Author:okutsu
Date:  2013-08-08 13:51 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0beaa65c90c8

8015986: Incorrect Localization of HijrahChronology
Reviewed-by: naoto
Contributed-by: scolebou...@joda.org, roger.ri...@oracle.com

! make/tools/src/build/tools/cldrconverter/CLDRConverter.java
! make/tools/src/build/tools/cldrconverter/CalendarType.java
! src/share/classes/sun/text/resources/FormatData.java
! src/share/classes/sun/text/resources/ar/FormatData_ar.java
! test/java/time/test/java/time/format/TestNonIsoFormatter.java

Re: RFR: 6614237: missing codepage Cp290 at java runtime

[Masayoshi Okutsu]

Hi Sherman,

IANA seems to define the following aliases for IBM290.

cp290
EBCDIC-JP-kana
csIBM290

The alias table should include EBCDIC-JP-kana and csIBM290 as well?

Otherwise, the changes look good to me.

Thanks,
Masayoshi

On 8/3/2013 5:53 AM, Xueming Shen wrote:

Masayoshi,

Would you please help review this change? The changeset also adds the 
requested Cp300.


webrev:
http://cr.openjdk.java.net/~sherman/6614237/webrev/

original mapptables:
http://cr.openjdk.java.net/~sherman/6614237/290/
http://cr.openjdk.java.net/~sherman/6614237/300/

regression tests:
http://cr.openjdk.java.net/~sherman/6614237/closed

Thanks!
-Sherman

Re: RFR: java.time test bug

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 7/30/2013 11:57 AM, Roger Riggs wrote:

Please help review (and commit to jdk-tl or jdk) this java.time test bug

8021767 http://bugs.sun.com/view_bug.do?bug_id=8021767: 
test/java/time/tck/java/time/format/TCKFormatStyle.java failing

  Correct to use fixed locale; not locale of test environment

The test incorrectly uses the locale of the test environment and thus
fails in some environments.

Please review the webrev:
http://cr.openjdk.java.net/~rriggs/webrev-8021767-fixedlocale/

Thanks, Roger

hg: jdk8/tl/jdk: 7177315: SimpleDateFormat parses wrong 2-digit year if input contains spaces

[masayoshi . okutsu]

Changeset: 6975eea0b458
Author:okutsu
Date:  2013-06-07 17:07 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6975eea0b458

7177315: SimpleDateFormat parses wrong 2-digit year if input contains spaces
Reviewed-by: peytoia

! src/share/classes/java/text/SimpleDateFormat.java
+ test/java/text/Format/DateFormat/Bug7177315.java

hg: jdk8/tl/jdk: 7064270: java/text/Format/DateFormat/WeekDateTest.java fails on OEL5.6 hi_IN.UTF-8

[masayoshi . okutsu]

Changeset: a286ed046116
Author:okutsu
Date:  2013-06-07 17:37 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a286ed046116

7064270: java/text/Format/DateFormat/WeekDateTest.java fails on OEL5.6 
hi_IN.UTF-8
Reviewed-by: peytoia

! test/java/text/Format/DateFormat/WeekDateTest.java

Re: i18n dev RFR JDK-8013386: (tz) Support tzdata2013c

[Masayoshi Okutsu]

On 5/10/2013 3:30 PM, Xueming Shen wrote:

On 5/9/13 9:57 PM, Masayoshi Okutsu wrote:
Do we still need to keep the old javazic code in JDK8? It's a 
maintenance burden to maintain both, isn't it?




While it's a burden, but somehow it serves as a test case pretty well. 
The transitions are
being built the old jdk way and threeten way, if the transition does 
not match, something
might be wrong. This time, it's in the old code, maybe next time 
it's in the threeten. So
it might be still worth keeping a while, to remove in jdk9? Btw, the 
Rule.java fix might need
go into the tzdb update tool as well, I believe the transitions for 
2011 Palestine are wrong in

the updated tzdb updator.


Yes, the Rule.java fix needs to go to older JDKs and TZ updater (build 
system).


Masayoshi



I'm concerned about the 24:00 fix. Is there any way to produce the 
correct rules without hard coding time zone IDs?


I don't know how to do it, yet. I definitely can have a RFE for it and 
spend some time on

it later.

-Sherman



Masayoshi

On 5/10/2013 8:24 AM, Xueming Shen wrote:

Hi Sean,

Thanks for the review. It appears I missed 
jdk/test/sun/util/calendar/zi/tzdata,

webrev has been updated to include the test data update.

http://cr.openjdk.java.net/~sherman/8013386/webrev

I will update TCKZoneRulesProvider.java separately in JSR310 repo, 
this def is

actually is not being used by anyone anymore, just need to be removed.

jdk/makefiles/GendataTimeZone.gmk is no longer used, need to be 
removed, I

will remove it separately later.


Masayoshi,

The update also included the two changes needed to fix/workaround 
the following 2

issues found during running the regression test

 jdk/test/sun/util/calendar/zi/TestZoneInfo310.java,

due to the changes for Rule Palestine and the corresponding Zone 
Asia/Gaza and

Asia/Hebron [1].

(1) Now the Rule Palestine has the def of lastThu 24:00, similar 
to Asia/Amman, so
these two zones need to be handled specially in ZoneInfoFile as well 
[2]


(2) Rule Palestine has 2 day-saving changes in 2011, so it has 4 
transitions for 2011
when returned from Rule.getRules(int year). Unfortunately it appears 
the Comparator
for Arrays.sorting is incorrectly implemented when comparing two 
longs [3]. The directly
consequence of this decade-old bug is that the returned list has the 
wrong order for

2011/08/01/xxx and 2011/08/30/xxx

Please help review.

Thanks!
-Sherman

[1] 
http://cr.openjdk.java.net/~sherman/8013386/webrev/make/sun/javazic/tzdata/asia.sdiff.html
[2] 
http://cr.openjdk.java.net/~sherman/8013386/webrev/src/share/classes/sun/util/calendar/ZoneInfoFile.java.sdiff.html
[3] 
http://cr.openjdk.java.net/~sherman/8013386/webrev/test/sun/util/calendar/zi/Rule.java.sdiff.html


On 05/09/2013 02:06 AM, Seán Coffey wrote:
Thanks for taking care of this Sherman. I was wondering what sort 
of impact JSR 310 would make on tzdata updates. The 
Atlantic/Stanley display name issue mentioned is a regular one, we 
should log a bug against the test file generation scripts.


I just had a quick grok of the jdk8 repo. The following files need 
updating also :


jdk/test/sun/util/calendar/zi/tzdata/*
jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java 
(line 85)

jdk/makefiles/GendataTimeZone.gmk (line 29)

It looks like jdk/makefiles/GendataTimeZone.gmk still has a 
dependency on reading files from jdk/make. That'll all have to 
change too once the old build system is removed from jdk8. I think 
the new tzdata sources should be moved into a directory under 
makefiles rather than keeping them in make.


The GENDATA_TIMEZONE_VERSION := tzdata2012i line in 
jdk/makefiles/GendataTimeZone.gmk  should be removed if we know 
that the version string can be read from the VERSION file stored 
with tzdata.


Above points are not necessarily related to 2013c update and should 
be cleaned up separately perhaps.


regards,
Sean.

On 08/05/2013 23:20, Xueming Shen wrote:

Hi,

Please help review the proposed change to update the tz data
in JDK8 from 2012i to 2013c.

Other than the tzdb data file update under make/sun/javazic/tzdata,
corresponding updates have also been made in TimeZoneNames***.java
for the newly added zones, Asia/Khandyga and Ust-Nera, and updated
zone display names (from EET to CET) for Africa/Tripoli (and its 
alias Libya)


test/java/util/TimeZone/tools/share/Make has been run to generate the
new test data at TimeZoneData.

# I have to update the displaynames.txt manually to undo the change
for Atlantic/Stanley from FKST (which is defined in 
southamerica.txt both
in 2012i and 2013c, there is no change for Stanley from 2012i to 
2013c)
back to FKT FKST to keep Bug6329116.java passed. I'm not sure 
why the
definition in TimeZoneNames.java (which has FKT as the standard 
name and
FKST as the summer name) does not match the tz data file (which 
suggests
that Stanley has moved to use only summer zone), but since this 
appears
to be an existing issue that not related

Re: i18n dev RFR JDK-8013386: (tz) Support tzdata2013c

[Masayoshi Okutsu]

Do we still need to keep the old javazic code in JDK8? It's a 
maintenance burden to maintain both, isn't it?


I'm concerned about the 24:00 fix. Is there any way to produce the 
correct rules without hard coding time zone IDs?


Masayoshi

On 5/10/2013 8:24 AM, Xueming Shen wrote:

Hi Sean,

Thanks for the review. It appears I missed 
jdk/test/sun/util/calendar/zi/tzdata,

webrev has been updated to include the test data update.

http://cr.openjdk.java.net/~sherman/8013386/webrev

I will update TCKZoneRulesProvider.java separately in JSR310 repo, 
this def is

actually is not being used by anyone anymore, just need to be removed.

jdk/makefiles/GendataTimeZone.gmk is no longer used, need to be 
removed, I

will remove it separately later.


Masayoshi,

The update also included the two changes needed to fix/workaround the 
following 2

issues found during running the regression test

 jdk/test/sun/util/calendar/zi/TestZoneInfo310.java,

due to the changes for Rule Palestine and the corresponding Zone 
Asia/Gaza and

Asia/Hebron [1].

(1) Now the Rule Palestine has the def of lastThu 24:00, similar to 
Asia/Amman, so

these two zones need to be handled specially in ZoneInfoFile as well [2]

(2) Rule Palestine has 2 day-saving changes in 2011, so it has 4 
transitions for 2011
when returned from Rule.getRules(int year). Unfortunately it appears 
the Comparator
for Arrays.sorting is incorrectly implemented when comparing two longs 
[3]. The directly
consequence of this decade-old bug is that the returned list has the 
wrong order for

2011/08/01/xxx and 2011/08/30/xxx

Please help review.

Thanks!
-Sherman

[1] 
http://cr.openjdk.java.net/~sherman/8013386/webrev/make/sun/javazic/tzdata/asia.sdiff.html
[2] 
http://cr.openjdk.java.net/~sherman/8013386/webrev/src/share/classes/sun/util/calendar/ZoneInfoFile.java.sdiff.html
[3] 
http://cr.openjdk.java.net/~sherman/8013386/webrev/test/sun/util/calendar/zi/Rule.java.sdiff.html


On 05/09/2013 02:06 AM, Seán Coffey wrote:
Thanks for taking care of this Sherman. I was wondering what sort of 
impact JSR 310 would make on tzdata updates. The Atlantic/Stanley 
display name issue mentioned is a regular one, we should log a bug 
against the test file generation scripts.


I just had a quick grok of the jdk8 repo. The following files need 
updating also :


jdk/test/sun/util/calendar/zi/tzdata/*
jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java (line 
85)

jdk/makefiles/GendataTimeZone.gmk (line 29)

It looks like jdk/makefiles/GendataTimeZone.gmk still has a 
dependency on reading files from jdk/make. That'll all have to change 
too once the old build system is removed from jdk8. I think the new 
tzdata sources should be moved into a directory under makefiles 
rather than keeping them in make.


The GENDATA_TIMEZONE_VERSION := tzdata2012i line in 
jdk/makefiles/GendataTimeZone.gmk  should be removed if we know that 
the version string can be read from the VERSION file stored with tzdata.


Above points are not necessarily related to 2013c update and should 
be cleaned up separately perhaps.


regards,
Sean.

On 08/05/2013 23:20, Xueming Shen wrote:

Hi,

Please help review the proposed change to update the tz data
in JDK8 from 2012i to 2013c.

Other than the tzdb data file update under make/sun/javazic/tzdata,
corresponding updates have also been made in TimeZoneNames***.java
for the newly added zones, Asia/Khandyga and Ust-Nera, and updated
zone display names (from EET to CET) for Africa/Tripoli (and its 
alias Libya)


test/java/util/TimeZone/tools/share/Make has been run to generate the
new test data at TimeZoneData.

# I have to update the displaynames.txt manually to undo the change
for Atlantic/Stanley from FKST (which is defined in 
southamerica.txt both

in 2012i and 2013c, there is no change for Stanley from 2012i to 2013c)
back to FKT FKST to keep Bug6329116.java passed. I'm not sure why the
definition in TimeZoneNames.java (which has FKT as the standard name 
and
FKST as the summer name) does not match the tz data file (which 
suggests

that Stanley has moved to use only summer zone), but since this appears
to be an existing issue that not related to this update, I keep the 
test data for

Stanley untouched.

Tests list below have been run and passed.

java/util/TimeZone
java/util/Calendar
java/util/Formatter
java/time
closed/java/util/TimeZone
closed/java/util/Calendar

webrev:

http://cr.openjdk.java.net/~sherman/8013386/webrev/
http://cr.openjdk.java.net/~sherman/8013386/test.closed/

Thanks!
Sherman

Re: Please review: surrogate fiddle

[Masayoshi Okutsu]

Thank you for catching this bug. AbstractStringBuilder.codePointAt(int) 
should have called Character.codePointAt(char[], int, int).


As for duplicating code, I originally duplicated similar code everywhere 
for performance. But someone told me probably during code review that 
hotspot inlining was as good as C/C++ macros, and I agreed to replace 
the duplicated code with method calls.


Masayoshi

On 3/19/2013 7:13 AM, Martin Buchholz wrote:

It does change the behavior.  The existing behavior is clearly a bug, since
it reads a char that should be inaccessible.  I don't believe AIOOBE
exception is thrown, with or without my fix.


On Mon, Mar 18, 2013 at 3:08 PM, Mike Duigou mike.dui...@oracle.com wrote:


This change would seem to change the result when a high surrogate is the
last char in the String/StringBuilder/StringBuffer.

Rather than throwing an ArrayIndexException it will return the high
surrogate char.

I am going to defer to Sherman on this. I don't know that returning the
character is the right thing to do.

Sherman?

Mike

On Mar 18 2013, at 14:28 , Martin Buchholz wrote:

Hello Jim, Mike,

I'd like you to do a code review:

http://cr.openjdk.java.net/~martin/webrevs/openjdk8/surrogate-fiddle/

Re: JDK 8 request for review: two javadoc warning fixes, on in DateTimeFormatterBuilder, another in TimeZone

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 2/19/2013 3:58 PM, Joe Darcy wrote:

Hello,

Please review these two simple fixes for javadoc warnings I noticed 
during a build (I'll file a bug after getting a review):


diff -r bcde0486261e 
src/share/classes/java/time/format/DateTimeFormatterBuilder.java
--- a/src/share/classes/java/time/format/DateTimeFormatterBuilder.java 
Mon Feb 18 08:14:18 2013 +
+++ b/src/share/classes/java/time/format/DateTimeFormatterBuilder.java 
Mon Feb 18 22:55:56 2013 -0800

@@ -1007,7 +1007,7 @@
  * is used, with {@code IsoChronology} as the fallback.
  * p
  * Note that this method provides similar functionality to 
methods on
- * {@code DateFormat} such as {@link 
DateFormat#getDateTimeInstance(int, int)}.
+ * {@code DateFormat} such as {@link 
java.text.DateFormat#getDateTimeInstance(int, int)}.

  *
  * @param dateStyle  the date style to use, null means no date 
required
  * @param timeStyle  the time style to use, null means no time 
required

diff -r bcde0486261e src/share/classes/java/util/TimeZone.java
--- a/src/share/classes/java/util/TimeZone.javaMon Feb 18 08:14:18 
2013 +
+++ b/src/share/classes/java/util/TimeZone.javaMon Feb 18 22:55:56 
2013 -0800

@@ -534,7 +534,7 @@
 /**
  * Gets the {@code TimeZone} for the given {@code zoneId}.
  *
- * @param zoneid a {@link ZoneId} from which the time zone ID is 
obtained
+ * @param zoneId a {@link ZoneId} from which the time zone ID is 
obtained
  * @return the specified {@code TimeZone}, or the GMT zone if the 
given ID

  * cannot be understood.
  * @throws NullPointerException if {@code zoneId} is {@code null}

Thanks,

-Joe

Re: [Review Request] 8008161: Regression: j.u.TimeZone.getAvailableIDs(rawOffset) returns non-sorted list

[Masayoshi Okutsu]

The change is fine. But it's neither the spec nor guaranteed in the 
previous implementation to return a sorted list. The caller needed to 
sort the return value if a sorted list is required.


Masayoshi

On 2/14/2013 4:02 AM, Xueming Shen wrote:

Hi,

This is the regression triggered by my changeset
8007572: Replace existing jdk timezone data at java.home/lib/zi with 
JSR310's tzdb.


While the specification does not specify that the returned list from
j.u.TimeZone.getAvailableIDs(rawOffset) should be sorted, this has
been the implementation for years. It appears there are at least some
tests may have dependency on this.

Here is the webrev to restore the existing behavior.

http://cr.openjdk.java.net/~sherman/8008161/webrev

Please help review.

Thanks!
-Sherman

hg: jdk8/tl/jdk: 4745761: (cal) RFE: Support builder for constructing Calendar

[masayoshi . okutsu]

Changeset: 6ca6b6f07653
Author:okutsu
Date:  2013-01-21 12:04 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ca6b6f07653

4745761: (cal) RFE: Support builder for constructing Calendar
Reviewed-by: peytoia

! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/JapaneseImperialCalendar.java
+ test/java/util/Calendar/Builder/BuilderTest.java
! test/java/util/Calendar/CalendarTypeTest.java

hg: jdk8/tl/jdk: 8004489: Add support for Minguo and Hijrah calendars to CalendarNameProvider SPI; ...

[masayoshi . okutsu]

Changeset: 3c1a440a1e12
Author:okutsu
Date:  2013-01-21 15:41 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c1a440a1e12

8004489: Add support for Minguo and Hijrah calendars to CalendarNameProvider SPI
8006509: Add more calendar symbol names from CLDR
Reviewed-by: peytoia

! make/tools/src/build/tools/cldrconverter/Bundle.java
! make/tools/src/build/tools/cldrconverter/CLDRConverter.java
! make/tools/src/build/tools/cldrconverter/CalendarType.java
! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java
! src/share/classes/java/util/spi/CalendarNameProvider.java
! src/share/classes/sun/text/resources/FormatData.java
! src/share/classes/sun/text/resources/ar/FormatData_ar.java
! src/share/classes/sun/text/resources/be/FormatData_be.java
! src/share/classes/sun/text/resources/bg/FormatData_bg.java
! src/share/classes/sun/text/resources/ca/FormatData_ca.java
! src/share/classes/sun/text/resources/cs/FormatData_cs.java
! src/share/classes/sun/text/resources/da/FormatData_da.java
! src/share/classes/sun/text/resources/de/FormatData_de.java
! src/share/classes/sun/text/resources/el/FormatData_el.java
! src/share/classes/sun/text/resources/es/FormatData_es.java
! src/share/classes/sun/text/resources/et/FormatData_et.java
! src/share/classes/sun/text/resources/fi/FormatData_fi.java
! src/share/classes/sun/text/resources/fr/FormatData_fr.java
! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java
! src/share/classes/sun/text/resources/hr/FormatData_hr.java
! src/share/classes/sun/text/resources/hu/FormatData_hu.java
! src/share/classes/sun/text/resources/is/FormatData_is.java
! src/share/classes/sun/text/resources/it/FormatData_it.java
! src/share/classes/sun/text/resources/iw/FormatData_iw.java
! src/share/classes/sun/text/resources/ja/FormatData_ja.java
! src/share/classes/sun/text/resources/ko/FormatData_ko.java
! src/share/classes/sun/text/resources/lt/FormatData_lt.java
! src/share/classes/sun/text/resources/lv/FormatData_lv.java
! src/share/classes/sun/text/resources/mk/FormatData_mk.java
! src/share/classes/sun/text/resources/ms/FormatData_ms.java
! src/share/classes/sun/text/resources/mt/FormatData_mt.java
! src/share/classes/sun/text/resources/nl/FormatData_nl.java
! src/share/classes/sun/text/resources/pl/FormatData_pl.java
! src/share/classes/sun/text/resources/pt/FormatData_pt.java
! src/share/classes/sun/text/resources/ro/FormatData_ro.java
! src/share/classes/sun/text/resources/ru/FormatData_ru.java
! src/share/classes/sun/text/resources/sk/FormatData_sk.java
! src/share/classes/sun/text/resources/sl/FormatData_sl.java
! src/share/classes/sun/text/resources/sr/FormatData_sr.java
! src/share/classes/sun/text/resources/sv/FormatData_sv.java
! src/share/classes/sun/text/resources/th/FormatData_th.java
! src/share/classes/sun/text/resources/tr/FormatData_tr.java
! src/share/classes/sun/text/resources/uk/FormatData_uk.java
! src/share/classes/sun/text/resources/vi/FormatData_vi.java
! src/share/classes/sun/text/resources/zh/FormatData_zh.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java
! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java
! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/LocaleResources.java
+ test/java/util/Calendar/CldrFormatNamesTest.java
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

hg: jdk8/tl/jdk: 8005471: DateFormat: Time zone info is not localized when adapter is CLDR

[masayoshi . okutsu]

Changeset: 4ad38db38fff
Author:okutsu
Date:  2012-12-28 14:13 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ad38db38fff

8005471: DateFormat: Time zone info is not localized when adapter is CLDR
Reviewed-by: peytoia

! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java
+ test/java/util/TimeZone/CLDRDisplayNamesTest.java

hg: jdk8/tl/jdk: 8005561: typo in Calendar

[masayoshi . okutsu]

Changeset: f3ac419e2bf0
Author:okutsu
Date:  2012-12-28 16:39 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3ac419e2bf0

8005561: typo in Calendar
Reviewed-by: peytoia

! src/share/classes/java/util/Calendar.java

Re: i18n dev RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo

[Masayoshi Okutsu]

I was wondering if you plan to address the review comment by David. If 
that part gets addressed, I think the test case change is no longer 
required. Otherwise, your change to the test program is fine with me.


Thanks,
Masayoshi

On 2012/11/28 21:59, Staffan Larsen wrote:

Did we conclude that my original change was good, or was there an alternative?

Thanks,
/Staffan

On 27 nov 2012, at 17:02, Seán Coffey sean.cof...@oracle.com wrote:


I suspect this test will fail with java agents too, say when doing code 
coverage during test runs.

It might be better to just change the @run tag to specify -D user.timezone= 
Asia/Tokyo, assuming this solves the problem too.

This test runs in othervm mode by default. Any java agents calling into this 
would already have been causing an issue. Right ?
Is this outside the scope of the fix we need in 7155168 ?

regards,
Sean.

On 27/11/2012 11:02, Alan Bateman wrote:

On 27/11/2012 10:22, Staffan Larsen wrote:

Please review this fix for the java/util/TimeZone/Bug6912560.java test.

The problem with the test is that it fails when running with Java Flight 
Recorder enabled. This is because JFR will call TimeZone.getDefault() when it 
starts up, before the main() method is called. This will cause TimeZone to 
cache the value so that when the test calls TimeZone.getDefault() it will get 
the old value. The solution here is to reset the value in the beginning of the 
test.

Webrev: 
http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html


I suspect this test will fail with java agents too, say when doing code 
coverage during test runs.

It might be better to just change the @run tag to specify -D user.timezone= 
Asia/Tokyo, assuming this solves the problem too.

-Alan.

hg: jdk8/tl/jdk: 8000986: Split java.util.spi.CalendarDataProvider into week parameters and field names portions

[masayoshi . okutsu]

Changeset: 5d3f8f9e6c58
Author:okutsu
Date:  2012-11-12 11:12 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d3f8f9e6c58

8000986: Split java.util.spi.CalendarDataProvider into week parameters and 
field names portions
Reviewed-by: naoto

! make/java/java/FILES_java.gmk
! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/spi/CalendarDataProvider.java
+ src/share/classes/java/util/spi/CalendarNameProvider.java
! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java
! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java
+ src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java
! 
src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! test/java/util/PluggableLocale/CalendarDataProviderTest.java
! test/java/util/PluggableLocale/CalendarDataProviderTest.sh
+ test/java/util/PluggableLocale/CalendarNameProviderTest.java
+ test/java/util/PluggableLocale/CalendarNameProviderTest.sh
! test/java/util/PluggableLocale/GenericTest.java
! test/java/util/PluggableLocale/barprovider.jar
! test/java/util/PluggableLocale/fooprovider.jar
! test/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java
+ test/java/util/PluggableLocale/providersrc/CalendarNameProviderImpl.java
! test/java/util/PluggableLocale/providersrc/Makefile
+ test/java/util/PluggableLocale/providersrc/java.util.spi.CalendarNameProvider

hg: jdk8/tl/jdk: 6380549: (rb) ResourceBundle.Control global binding support

[masayoshi . okutsu]

Changeset: 4419c8f0b2f2
Author:okutsu
Date:  2012-06-19 16:21 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4419c8f0b2f2

6380549: (rb) ResourceBundle.Control global binding support
Reviewed-by: naoto

! make/java/java/FILES_java.gmk
! src/share/classes/java/util/ResourceBundle.java
+ src/share/classes/java/util/spi/ResourceBundleControlProvider.java
+ test/java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.java
+ test/java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.sh
+ test/java/util/spi/ResourceBundleControlProvider/providersrc/Makefile
+ 
test/java/util/spi/ResourceBundleControlProvider/providersrc/UserControlProvider.java
+ 
test/java/util/spi/ResourceBundleControlProvider/providersrc/UserXMLControl.java
+ test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB.xml
+ test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB_ja.xml
+ 
test/java/util/spi/ResourceBundleControlProvider/providersrc/java.util.spi.ResourceBundleControlProvider
+ test/java/util/spi/ResourceBundleControlProvider/rbcontrolprovider.jar

Re: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled

[Masayoshi Okutsu]

Hi Deven,

Sorry. I didn't review the test case...

You can use applet to write a manual test. You will find some manual 
tests under test/java/awt such as:


test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.{html,java}

Thanks,
Masayoshi

On 5/25/2012 4:41 PM, Deven You wrote:

Hi Alan,

Thanks for your reminder, I was going to point that this a manual test 
case and need someone guide me how to configure it as manual with 
jtreg. But I missed it by chance.


So Masayoshi or someone else, I'd very appreciate if you could guide 
me how to configure a test case as manual in the jtreg?


Thanks a lot!

On 05/25/2012 03:27 PM, Alan Bateman wrote:

Deven,

The test with this fix seems to be a manual test but doesn't seem to 
be tagged as such (/manual). I assume this means it will fail on all 
platforms. Do you mind re-examining it? Masayoshi may have some 
advice on how configuration like this can be tested. It may be that 
it's just not possible to test this in an automated way, in which 
case the path of least pain may be to just remove it.


-Alan.

On 25/05/2012 06:31, litt...@linux.vnet.ibm.com wrote:

Changeset: 71cf74329a9e
Author:youdwei
Date:  2012-05-25 13:28 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71cf74329a9e

7094176: (tz) Incorrect TimeZone display name when DST not 
applicable / disabled

Reviewed-by: okutsu

! src/windows/native/java/util/TimeZone_md.c
+ test/java/util/TimeZone/DstTzTest.java

Re: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled

[Masayoshi Okutsu]

On 5/25/2012 6:37 PM, Alan Bateman wrote:

On 25/05/2012 10:32, Masayoshi Okutsu wrote:

Hi Deven,

Sorry. I didn't review the test case...

You can use applet to write a manual test. You will find some manual 
tests under test/java/awt such as:


test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.{html,java} 



Thanks,
Masayoshi
Masayoshi - I think we need to strongly discourage adding any manual 
tests to the java/util/ tree.


Another option would be to write a native program to change the system 
setup and run a Java program to detect the change. But it requires the 
administrator privilege and is a bit risky. A test failure may leave a 
test machine in an unusual state.


Any other options?

Thanks,
Masayoshi

Re: i18n dev RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

[Masayoshi Okutsu]

fd needs to be closed when fstat or malloc failed?

Thanks,
Masayoshi

On 3/13/2012 12:22 AM, Alan Bateman wrote:

On 12/03/2012 15:11, Seán Coffey wrote:
Yes - good catch. I hadn't tested the sym link being a relative path. 
We should always open whatever is pointed to from 
DEFAULT_ZONEINFO_FILE. This simplifies the code. Tested and looks good.

I assume this is the latest:
  http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.3/

and it looks fine to me.

-Alan.

Re: i18n dev RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 3/13/2012 6:38 PM, Seán Coffey wrote:

Update made. Hopefully the last iteration ;)

http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.4/

regards,
Sean.

On 13/03/2012 05:59, Masayoshi Okutsu wrote:

fd needs to be closed when fstat or malloc failed?

Thanks,
Masayoshi

On 3/13/2012 12:22 AM, Alan Bateman wrote:

On 12/03/2012 15:11, Seán Coffey wrote:
Yes - good catch. I hadn't tested the sym link being a relative 
path. We should always open whatever is pointed to from 
DEFAULT_ZONEINFO_FILE. This simplifies the code. Tested and looks 
good.

I assume this is the latest:
  http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.3/

and it looks fine to me.

-Alan.

Re: RFR: 7133138 Improve io performance around timezone lookups

[Masayoshi Okutsu]

The fix looks good.

Thanks,
Masayoshi

On 2/22/2012 3:19 AM, Seán Coffey wrote:
I've worked with Masayoshi on this issue. Hoping to push to JDK8 and 
backport to 7u and a jdk6 once baked for a while.


Some windows boxes were showing performance issues when attempting to 
iterate through all available timezones available in the JRE. Changes 
made here should reduce the amount of file stat calls made on 
jre/lib/zi/* files.  Tweaks are made to the alias table also to reduce 
number of aliases that require lookup.


All TZ regression tests run without issue. I've seen a 20-30% speed up 
on iteration of timezones on windows as a result. Unix doesn't appear 
to suffer as badly from such a file IO hit.


http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133138
http://cr.openjdk.java.net/~coffeys/webrev.7133138/

regards,
Sean.

Re: i18n dev Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7

[Masayoshi Okutsu]

I tend to agree with Sherman that the real problem is the 
OutputStreamWriter API which isn't good enough to handle various 
encodings. My understanding is that the charset API was introduced in 
1.4 to deal with the limitations of the java.io and other encoding 
handling issues.


I still don't think it's correct to change the flush semantics. The 
flush method should just flush out any outstanding data to the given 
output stream as defined in java.io.Writer. What if Writer.write(int) is 
used write UTF-16 data with any stateful encoding? Suppose the stateful 
encoding can support supplementary characters which require other G0 
designations, does the following calling sequence work?


writer.write(highSurrogate);
writer.flush();
writer.write(lowSurrogate);
writer.flush();

Of course, this isn't a problem with iso-2022-jp, though.

I think it's a correct fix, not a workaround, to create a filter stream 
to deal with stateful encodings with the java.io API. If it's OK to 
support only 1.4 and later, the java.nio.charset API should be used.


Thanks,
Masayoshi

On 2/10/2012 4:12 AM, Xueming Shen wrote:

CCed Bill Shannon.

On 02/09/2012 11:10 AM, Xueming Shen wrote:


CharsetEncoder has the flush() method as the last step (of a series 
of encoding steps) to
flush out any internal state to the output buffer. The issue here is 
the the upper level wrapper
class, OutputStreamWriter in our case, doesn't provide a explicit 
mechanism to let the
user to request a flush on the underlying encoder. The only 
guaranteed' mechanism is the
close() method, in which it appears it not appropriate to invoke in 
some use scenario, such

as the JavaMail.writeTo() case.

It appears we are lacking of a close this stream, but not the 
underlying stream mechanism
in our layered/chained streams, I have similar request for this kind 
of mechanism in other area,
such as in zip/gzip stream, app wraps a outputstream with zip/gzip, 
they want to release the
zip/gzip layer after use (to release the native resource, for 
example) but want to keep the
underlying stream unclosed. The only workaround now is to wrap the 
underlying stream with
a subclass to override  the close() method, which is really not 
desirable.


The OutputStreamWriter.flush() does not explicitly specify in its API 
doc if it should actually
flush the underlying charset encoder (so I would not argue strongly 
that this IS a SE bug) but
given it is flushing it's buffer (internal status) and then the 
underlying out stream, it's
reasonable to consider that the internal status of its encoder also 
needs to be flushed.

Especially this has been the behavior for releases earlier than 1.4.2.

As I said,  while I have been hesitated to fix this problem for a 
while (one it has been here
for 3  major releases, two, the API does not explicitly say so) but 
as long as we don't have a
reasonable close-ME-only mechanism for those layered streams, it 
appears to be a
reasonable approach to solve the problem, without having obvious 
negative impact.


-Sherman

PS: There is another implementation detail that the original 
iso-2022-jp c2b converter
actually restores the state back to ASCII mode at the end of its 
convert method, this makes
the analysis a little complicated, but should not change the issue we 
are discussing)



On 02/09/2012 12:26 AM, Masayoshi Okutsu wrote:
First of all, is this really a Java SE bug? The usage of 
OutputSteamWriter in JavaMail seems to be wrong to me. The writeTo 
method in the bug report doesn't seem to be able to deal with any 
stateful encodings.


Masayoshi

On 2/9/2012 3:26 PM, Xueming Shen wrote:

Hi

This is a long standing regression from 1.3.1 on how 
OutputStreamWriter.flush()/flushBuffer()
handles escape or shift sequence in some of the charset/encoding, 
for example the ISO-2022-JP.


ISO-2022-JP is encoding that starts with ASCII mode and then 
switches between ASCII andJapanese
characters through an escape sequence. For example, the escape 
sequence ESC $ B (0x1B, 0x24 0x42)
is used to  indicate the following bytes are Japanese (switch from 
ASCII mode to Japanese mode), and

 the ESC ( B (0x1b  0x28  0x42) is used to switch back to ASCII.

In Java's sun.io.CharToByteConvert (old generation charset 
converter) and the nio.io.charset.CharsetEncoder
usually switches back forth between ASCII and Japanese modes based 
on the input character sequence
(for example, if you are in ASCII mode, and your next input 
character is a Japanese, you add the
ESC $ B into the output first and then followed the converted input 
character, or if you are in Japanese
mode and your next input is ASCII, you output ESC ( B first to 
switch the mode and then the ASCII) and
switch back to ASCII mode (if the last mode is non-Japanese) if 
either the encoding is ending or the

flush() method gets invoked.

In JDK1.3.1,  OutputStreamWriter.flushBuffer() explicitly invokes 
sun.io.c2b's flushAny() to switch
back to ASCII mode every time the flush

Re: i18n dev Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7

[Masayoshi Okutsu]

First of all, is this really a Java SE bug? The usage of 
OutputSteamWriter in JavaMail seems to be wrong to me. The writeTo 
method in the bug report doesn't seem to be able to deal with any 
stateful encodings.


Masayoshi

On 2/9/2012 3:26 PM, Xueming Shen wrote:

Hi

This is a long standing regression from 1.3.1 on how 
OutputStreamWriter.flush()/flushBuffer()
handles escape or shift sequence in some of the charset/encoding, for 
example the ISO-2022-JP.


ISO-2022-JP is encoding that starts with ASCII mode and then switches 
between ASCII andJapanese
characters through an escape sequence. For example, the escape 
sequence ESC $ B (0x1B, 0x24 0x42)
is used to  indicate the following bytes are Japanese (switch from 
ASCII mode to Japanese mode), and

 the ESC ( B (0x1b  0x28  0x42) is used to switch back to ASCII.

In Java's sun.io.CharToByteConvert (old generation charset converter) 
and the nio.io.charset.CharsetEncoder
usually switches back forth between ASCII and Japanese modes based on 
the input character sequence
(for example, if you are in ASCII mode, and your next input character 
is a Japanese, you add the
ESC $ B into the output first and then followed the converted input 
character, or if you are in Japanese
mode and your next input is ASCII, you output ESC ( B first to switch 
the mode and then the ASCII) and
switch back to ASCII mode (if the last mode is non-Japanese) if either 
the encoding is ending or the

flush() method gets invoked.

In JDK1.3.1,  OutputStreamWriter.flushBuffer() explicitly invokes 
sun.io.c2b's flushAny() to switch
back to ASCII mode every time the flush() or flushBuffer() (from 
PrintStream) gets invoked, as
showed at the end of this email. For example, as showed below, the 
code uses OutputStreamWriter
to write a Japanese character \u6700 to the underlying stream with 
iso-2022jp,


ByteArrayOutputStream bos = new ByteArrayOutputStream();
String str = \u6700;
OutputStreamWriter osw = new OutputStreamWriter(bos, iso-2022-jp);
osw.write(str, 0, str.length());

Since the iso-2022-jp starts with ASCII mode, we now have a Japanese, 
so we need to
switch into Japanese mode first (the first 3 bytes) and then the 
encoded Japanese

character (the following 2 bytes)

0x1b 0x24 0x42 0x3a 0x47

and then the code invokes

osw.flush();

since we are now  in Japanese, the writer continues to write out

 0x1b 0x28 0x 42

to switch back to ASCII mode. The total output is 8 bytes after 
write() and flush().


However, when all encoidng/charset related codes were migrated from 
1.3.1's sun.io based to
1.4's java.nio.charset based implementation (1.4, 1.4.1 and 1.4.2, we 
gradually migrated from
sun.io to java.nio.charset),  the c2b.flushAny() invocation 
obviously was dropped in
sun.nio.cs.StreamEncoder. It results in that the switch back to ASCII 
mode sequence is no longer
output when OutputStreamWriter.flush() or PrintStream.write(String) is 
invoked.


This does not trigger problem for most use scenario, if the stream 
finally gets closed
(in which the StreamEncoder does invoke encoder's flush() to output 
the escape sequence
to switch back to ASCII) or PrintStream.println(String) is used (in 
which it outputs a \n character,
since this \n is in ASCII range, it accidentally  switches the mode 
back to ASCII).


But it obviously causes problem when you can't not close the 
OutputStreamWriter after
you're done your iso2022-jp writing (for example, you need continue to 
use the underlying
OutputStream for other writing, but not this osw),  for 1.3.1, these 
apps invoke osw.flush()
to force the output switch back to ASCII, this no longer works when we 
switch to java.nio.charset
in jdk1.4.2. (we migrated iso-2022-jp to nio.charset in 1.4.2). This 
is what happened in JavaMail,

as described in the bug report.

The solution is to re-store the flush the encoder mechanism in 
StreamEncoder's flushBuffer().


I have been hesitated to make this change for a while, mostly because 
this regressed behavior
has been their for 3 releases, and the change triggers yet another 
behavior change. But given
there is no obvious workaround and it only changes the behavior of the 
charsets with this
shift in/out mechanism, mainly the iso-2022 family and those IBM 
EBCDIC_DBCS charsets,  I

decided to give it a try.

Here is the webreview

http://cr.openjdk.java.net/~sherman/6995537/webrev

Sherman


-1.3.1 
OutputStreamWriter---

/**
 * Flush the output buffer to the underlying byte stream, without 
flushing
 * the byte stream itself.  This method is non-private only so 
that it may

 * be invoked by PrintStream.
 */
void flushBuffer() throws IOException {
synchronized (lock) {
ensureOpen();

for (;;) {
try {
nextByte += ctb.flushAny(bb, nextByte, nBytes);
}
catch (ConversionBufferFullException x) {
nextByte = ctb.nextByteIndex();
 

hg: jdk8/tl/jdk: 7130335: Problem with timezone in a SimpleDateFormat

[masayoshi . okutsu]

Changeset: 7aa5ddfa3c9d
Author:okutsu
Date:  2012-01-27 14:58 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7aa5ddfa3c9d

7130335: Problem with timezone in a SimpleDateFormat
Reviewed-by: peytoia

! src/share/classes/java/text/SimpleDateFormat.java
+ test/java/text/Format/DateFormat/Bug7130335.java

hg: jdk8/tl/jdk: 7122054: (tz) Windows-only: tzmappings needs update for KB2633952

[masayoshi . okutsu]

Changeset: 1c4fffa22930
Author:okutsu
Date:  2011-12-21 17:09 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c4fffa22930

7122054: (tz) Windows-only: tzmappings needs update for KB2633952
Reviewed-by: peytoia

! src/windows/lib/tzmappings

hg: jdk8/tl/jdk: 7117487: Warnings Cleanup: some i18n classes in java.util and sun.util

[masayoshi . okutsu]

Changeset: f2a5d0001f15
Author:okutsu
Date:  2011-12-03 10:58 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2a5d0001f15

7117487: Warnings Cleanup: some i18n classes in java.util and sun.util
Reviewed-by: lancea, naoto

! src/share/classes/java/util/Date.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/JapaneseImperialCalendar.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/sun/util/calendar/BaseCalendar.java
! src/share/classes/sun/util/calendar/CalendarSystem.java
! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java
! src/share/classes/sun/util/calendar/ZoneInfo.java
! src/share/classes/sun/util/calendar/ZoneInfoFile.java
! src/share/classes/sun/util/resources/OpenListResourceBundle.java
! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java

hg: jdk8/tl/jdk: 2 new changesets

[masayoshi . okutsu]

Changeset: cd6d236e863b
Author:okutsu
Date:  2011-11-16 12:57 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd6d236e863b

7111903: (tz) Windows-only: tzmappings needs update for KB2570791
Reviewed-by: peytoia

! src/windows/lib/tzmappings

Changeset: 1266e72f7896
Author:okutsu
Date:  2011-11-16 13:17 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1266e72f7896

Merge

Re: Patch to expand tz checking scope in TimeZone_md.c

[Masayoshi Okutsu]

Probably the difference isn't documented. I tried Solaris 10 and Ubuntu 
10.03. The difference still exists.


Solaris 10:
$ unset TZ
$ date
Fri Nov  4 13:04:45 JST 2011
$ TZ= date
Fri Nov  4 13:04:53 JST 2011

Ubuntu 10.04:
$ unset TZ
$ date
Fri Nov  4 13:05:50 JST 2011
$ TZ= date
Fri Nov  4 04:05:55 UTC 2011

When the TZ value is an empty string, Ubuntu uses UTC while Solaris 
still looks up the system default.


Thanks,
Masayoshi

On 11/3/2011 4:16 PM, Jonathan Lu wrote:

Hi Masayoshi,

I did find some references about date-time related functions / TZ 
variables on Linux but got only a few about Solaris, so could not see 
any differences between those two platforms about the changes 
described in my patch. Have you got any links or references about 
these differences? I'm interested in it and may update the patch again 
after reading them.


Thanks a lot!
- Jonathan

On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote:

Hi Jonathan,

IIRC, the difference came from some behavioral difference between the 
Linux and Solaris libc date-time functions and/or the date command, 
and TimeZone_md.c tries to follow the difference. But the code was 
written long ago. The difference may no longer exist.


Thanks,
Masayoshi

On 11/2/2011 8:39 PM, Jonathan Lu wrote:

On 11/02/2011 07:00 PM, David Holmes wrote:

On 2/11/2011 7:01 PM, Jonathan Lu wrote:

On 11/02/2011 04:56 PM, Jonathan Lu wrote:

Hi core-libs-dev,

In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from 
line

626, I found that the scope of #ifdef __solaris__ might be too
narrow, since it also works for some kind of OS which I'm currently
working on, such as AIX.
So I suggest to just remove the '#ifdef __solaris__' and leave the
#else to accommodate more conditions, see attachment 
'patch.diff'. I

think this may enhance the cross-platform ability, any ideas about
this modification?

Regards
- Jonathan Lu
I'm not sure why the attachment got filtered, here paste it to the 
mail

content directly.

diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c
--- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 19:06:53
2011 -0700
+++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 13:43:47
2011 +0800
@@ -626,10 +626,8 @@
#ifdef __linux__
if (tz == NULL) {
#else
-#ifdef __solaris__
if (tz == NULL || *tz == '\0') {
#endif
-#endif
tz = getPlatformTimeZoneID();
freetz = tz;
}


I'm unclear why any of that code needs to be platform specific - is 
an empty TZ string somehow valid on linux? I would have thought the 
following would be platform neutral:


   if (tz == NULL || *tz == '\0') {
tz = getPlatformTimeZoneID();
freetz = tz;
}


Hi David,

getenv(TZ) returns NULL when TZ environment variable is not set at 
all and returns '\0' when TZ was exported as empty string. After 
more checking for both cases, I agree with you, nothing useful can 
be retrieved from that environment variable.

So I changed the patch to this,

diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c
--- a/src/solaris/native/java/util/TimeZone_md.cThu Oct 20 
10:32:47 2011 -0700
+++ b/src/solaris/native/java/util/TimeZone_md.cWed Nov 02 
19:34:51 2011 +0800

@@ -623,13 +623,7 @@

 tz = getenv(TZ);

-#ifdef __linux__
-if (tz == NULL) {
-#else
-#ifdef __solaris__
 if (tz == NULL || *tz == '\0') {
-#endif
-#endif
 tz = getPlatformTimeZoneID();
 freetz = tz;
 }


David
-


Regards
- Jonathan Lu

Regards

- Jonathan

hg: jdk8/tl/jdk: 7092679: (tz) Java getting wrong timezone/DST info on Solaris 11; ...

[masayoshi . okutsu]

Changeset: 2bc80ba6f4a4
Author:okutsu
Date:  2011-10-05 15:13 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2bc80ba6f4a4

7092679: (tz) Java getting wrong timezone/DST info on Solaris 11
6984762: Invalid close of file descriptor '-1' in findZoneinfoFile
Reviewed-by: coffeys, ohair, naoto, peytoia

! make/common/Defs-linux.gmk
! make/common/Defs-solaris.gmk
! make/java/java/Makefile
! src/solaris/native/java/util/TimeZone_md.c