From naoto.sato at oracle.com  Mon Mar 10 22:32:26 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 10 Mar 2014 15:32:26 -0700
Subject: <i18n dev> Request for 2 draft JEPs
Message-ID: <531E3D7A.2030101@oracle.com>

Hello,

I am planning to submit these two JEPs for JDK9. Before submitting these 
proposals to JEP submit alias, I would appreciate your 
comments/suggestions on these:

UTF-8 .properties (http://cr.openjdk.java.net/~naoto/jep/utf8props.md, 
https://bugs.openjdk.java.net/browse/JDK-8027607)
Enable CLDR LocaleProviderAdapter by default 
(http://cr.openjdk.java.net/~naoto/jep/enablecldr.md, 
https://bugs.openjdk.java.net/browse/JDK-8008577)

Note that these are still just proposals, so no APIs/Specifications are 
provided as of now, (let alone implementations).

Naoto

From aleksej.efimov at oracle.com  Wed Mar 12 15:05:28 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 12 Mar 2014 19:05:28 +0400
Subject: <i18n dev> RFR: 8037012: (tz) Support tzdata2014a
Message-ID: <532077B8.3030605@oracle.com>

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


From aleksej.efimov at oracle.com  Wed Mar 12 15:06:48 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 12 Mar 2014 19:06:48 +0400
Subject: <i18n dev> RFR: 8037180: [TEST_BUG]
 test/sun/util/calendar/zi/Zoneinfo.java incorrectly calculates raw GMT
 offset change time
Message-ID: <53207808.4090107@oracle.com>

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=7200000,dstSavings=3600000,useDaylight=true,transitions=171,offsets=5,checksum=-508379603,gmtChanged=false
[NG]offset=7200000,dstSavings=3600000,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:
Zone    Europe/Istanbul 1:55:52 -       LMT     1880
                         1:56:56 -       IMT     1910 Oct # Istanbul 
Mean Time?
                         2:00    Turkey  EE%sT   1978 Oct 15
                         3:00    Turkey  TR%sT   1985 Apr 20 # Turkey Time
                         2:00    Turkey  EE%sT   2007
                         2:00    EU      EE%sT   2011 Mar 27 1:00u
                         2:00    -       EET     2011 Mar 28 1:00u
                         2:00    EU      EE%sT   2014 Mar 30 1:00u
                         2:00    -       EET     2014 Mar 31 1:00u
                         2:00    EU      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

From sean.coffey at oracle.com  Thu Mar 13 12:18:20 2014
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Thu, 13 Mar 2014 12:18:20 +0000
Subject: <i18n dev> RFR: 8037012: (tz) Support tzdata2014a
In-Reply-To: <532077B8.3030605@oracle.com>
References: <532077B8.3030605@oracle.com>
Message-ID: <5321A20C.808@oracle.com>

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
>


From sean.coffey at oracle.com  Thu Mar 13 12:19:51 2014
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Thu, 13 Mar 2014 12:19:51 +0000
Subject: <i18n dev> RFR: 8037180: [TEST_BUG]
 test/sun/util/calendar/zi/Zoneinfo.java incorrectly calculates raw GMT
 offset change time
In-Reply-To: <53207808.4090107@oracle.com>
References: <53207808.4090107@oracle.com>
Message-ID: <5321A267.6050101@oracle.com>

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=7200000,dstSavings=3600000,useDaylight=true,transitions=171,offsets=5,checksum=-508379603,gmtChanged=false 
>
> [NG]offset=7200000,dstSavings=3600000,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:
> Zone    Europe/Istanbul 1:55:52 -       LMT     1880
>                         1:56:56 -       IMT     1910 Oct # Istanbul 
> Mean Time?
>                         2:00    Turkey  EE%sT   1978 Oct 15
>                         3:00    Turkey  TR%sT   1985 Apr 20 # Turkey Time
>                         2:00    Turkey  EE%sT   2007
>                         2:00    EU      EE%sT   2011 Mar 27 1:00u
>                         2:00    -       EET     2011 Mar 28 1:00u
>                         2:00    EU      EE%sT   2014 Mar 30 1:00u
>                         2:00    -       EET     2014 Mar 31 1:00u
>                         2:00    EU      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


From masayoshi.okutsu at oracle.com  Thu Mar 13 12:25:38 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 13 Mar 2014 21:25:38 +0900
Subject: <i18n dev> RFR: 8037012: (tz) Support tzdata2014a
In-Reply-To: <5321A20C.808@oracle.com>
References: <532077B8.3030605@oracle.com> <5321A20C.808@oracle.com>
Message-ID: <5321A3C2.3010505@oracle.com>

+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
>>
>


From masayoshi.okutsu at oracle.com  Thu Mar 13 12:31:24 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 13 Mar 2014 21:31:24 +0900
Subject: <i18n dev> RFR: 8037180: [TEST_BUG]
 test/sun/util/calendar/zi/Zoneinfo.java incorrectly calculates raw GMT
 offset change time
In-Reply-To: <5321A267.6050101@oracle.com>
References: <53207808.4090107@oracle.com> <5321A267.6050101@oracle.com>
Message-ID: <5321A51C.4020108@oracle.com>

+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=7200000,dstSavings=3600000,useDaylight=true,transitions=171,offsets=5,checksum=-508379603,gmtChanged=false 
>>
>> [NG]offset=7200000,dstSavings=3600000,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:
>> Zone    Europe/Istanbul 1:55:52 -       LMT     1880
>>                         1:56:56 -       IMT     1910 Oct # Istanbul 
>> Mean Time?
>>                         2:00    Turkey  EE%sT   1978 Oct 15
>>                         3:00    Turkey  TR%sT   1985 Apr 20 # Turkey 
>> Time
>>                         2:00    Turkey  EE%sT   2007
>>                         2:00    EU      EE%sT   2011 Mar 27 1:00u
>>                         2:00    -       EET     2011 Mar 28 1:00u
>>                         2:00    EU      EE%sT   2014 Mar 30 1:00u
>>                         2:00    -       EET     2014 Mar 31 1:00u
>>                         2:00    EU      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
>


From xueming.shen at oracle.com  Thu Mar 13 15:09:19 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 13 Mar 2014 08:09:19 -0700
Subject: <i18n dev> RFR: 8037012: (tz) Support tzdata2014a
In-Reply-To: <532077B8.3030605@oracle.com>
References: <532077B8.3030605@oracle.com>
Message-ID: <5321CA1F.3000004@oracle.com>

looks good.

On 3/12/14 8:05 AM, 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
>


From naoto.sato at oracle.com  Thu Mar 20 17:31:35 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 20 Mar 2014 10:31:35 -0700
Subject: <i18n dev> Request for 2 draft JEPs
In-Reply-To: <531E3D7A.2030101@oracle.com>
References: <531E3D7A.2030101@oracle.com>
Message-ID: <532B25F7.9090200@oracle.com>

Ping. Unless I hear any objection, I will post them to the JEP submit 
alias tomorrow.

Naoto

On 3/10/14, 3:32 PM, Naoto Sato wrote:
> Hello,
>
> I am planning to submit these two JEPs for JDK9. Before submitting these
> proposals to JEP submit alias, I would appreciate your
> comments/suggestions on these:
>
> UTF-8 .properties (http://cr.openjdk.java.net/~naoto/jep/utf8props.md,
> https://bugs.openjdk.java.net/browse/JDK-8027607)
> Enable CLDR LocaleProviderAdapter by default
> (http://cr.openjdk.java.net/~naoto/jep/enablecldr.md,
> https://bugs.openjdk.java.net/browse/JDK-8008577)
>
> Note that these are still just proposals, so no APIs/Specifications are
> provided as of now, (let alone implementations).
>
> Naoto

From yuka.kamiya at oracle.com  Wed Mar 26 07:10:51 2014
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Wed, 26 Mar 2014 16:10:51 +0900
Subject: <i18n dev> Request for a JEP for JDK9 (Unicode support)
Message-ID: <53327D7B.4050607@oracle.com>

Hello,

This is a JEP to support the latest version of Unicode in JDK 9.
I'd appreciate your comments/suggestions on:
http://cr.openjdk.java.net/~peytoia/JEPs/Unicode.Next.txt

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

If I don't receive objections within this month, I'll submit this JEP
to JEP submit alias.

Note that this is still a draft, and no detailed information about spec
is included at this moment.

Thanks,
--
Yuka


From Alan.Bateman at oracle.com  Wed Mar 26 07:26:51 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 26 Mar 2014 07:26:51 +0000
Subject: <i18n dev> Improve timezone mapping for AIX platform
In-Reply-To: <CAC-GWLc1KLNSqzr4h5uYwC6R+JxmgRkCmKv7LUVmw_LzhPEbHw@mail.gmail.com>
References: <CAC-GWLc1KLNSqzr4h5uYwC6R+JxmgRkCmKv7LUVmw_LzhPEbHw@mail.gmail.com>
Message-ID: <5332813B.8090501@oracle.com>


Adding i18n-dev to the thread as i18n-dev is where the TZ code is 
maintained.

On 26/03/2014 06:47, 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


From iris.clark at oracle.com  Wed Mar 26 18:23:03 2014
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 26 Mar 2014 11:23:03 -0700 (PDT)
Subject: <i18n dev> Request for a JEP for JDK9 (Unicode support)
In-Reply-To: <53327D7B.4050607@oracle.com>
References: <53327D7B.4050607@oracle.com>
Message-ID: <443260df-b119-4d59-8524-f2756648845d@default>

Hi, Yuka.

Looks good as the expected follow-on to the equivalent work in JDK 8 (JEP 133: Unicode 6.2 [1]).

My only minor recommendation is that you consider adding a link to unicode.org [2] in the Summary.  As an example see lines 27-28 here [3].  (See [4] for additional MarkDown syntax.)

Thanks,
iris

[1]: http://openjdk.java.net/jeps/133
[2]: http://www.unicode.org/standard/standard.html
[3]: http://hg.openjdk.java.net/jep/jeps/file/tip/jep-133.md
[4]: http://daringfireball.net/projects/markdown/syntax

-----Original Message-----
From: Yuka Kamiya 
Sent: Wednesday, March 26, 2014 12:11 AM
To: i18n-dev
Subject: <i18n dev> Request for a JEP for JDK9 (Unicode support)

Hello,

This is a JEP to support the latest version of Unicode in JDK 9.
I'd appreciate your comments/suggestions on:
http://cr.openjdk.java.net/~peytoia/JEPs/Unicode.Next.txt

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

If I don't receive objections within this month, I'll submit this JEP to JEP submit alias.

Note that this is still a draft, and no detailed information about spec is included at this moment.

Thanks,
--
Yuka


From yuka.kamiya at oracle.com  Thu Mar 27 06:43:00 2014
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Thu, 27 Mar 2014 15:43:00 +0900
Subject: <i18n dev> Request for a JEP for JDK9 (Unicode support)
In-Reply-To: <443260df-b119-4d59-8524-f2756648845d@default>
References: <53327D7B.4050607@oracle.com>
	<443260df-b119-4d59-8524-f2756648845d@default>
Message-ID: <5333C874.1040902@oracle.com>

Hi Iris,

Thank you for your comment on my JEP.

I've revised the draft to reflect it. And also, all the Unicode versions ("x.y.0") in the JEP were replaced with "x.y" in passing, because they are official abbreviations for "x.y.0".

New draft is:
http://cr.openjdk.java.net/~peytoia/JEPs/Unicode.Next.md

Thanks in advance,
--
Yuka


(2014/03/27 3:23), Iris Clark wrote:
> Hi, Yuka.
>
> Looks good as the expected follow-on to the equivalent work in JDK 8 (JEP 133: Unicode 6.2 [1]).
>
> My only minor recommendation is that you consider adding a link to unicode.org [2] in the Summary.  As an example see lines 27-28 here [3].  (See [4] for additional MarkDown syntax.)
>
> Thanks,
> iris
>
> [1]: http://openjdk.java.net/jeps/133
> [2]: http://www.unicode.org/standard/standard.html
> [3]: http://hg.openjdk.java.net/jep/jeps/file/tip/jep-133.md
> [4]: http://daringfireball.net/projects/markdown/syntax
>
> -----Original Message-----
> From: Yuka Kamiya
> Sent: Wednesday, March 26, 2014 12:11 AM
> To: i18n-dev
> Subject: <i18n dev> Request for a JEP for JDK9 (Unicode support)
>
> Hello,
>
> This is a JEP to support the latest version of Unicode in JDK 9.
> I'd appreciate your comments/suggestions on:
> http://cr.openjdk.java.net/~peytoia/JEPs/Unicode.Next.txt
>
> https://bugs.openjdk.java.net/browse/JDK-8032446
>
> If I don't receive objections within this month, I'll submit this JEP to JEP submit alias.
>
> Note that this is still a draft, and no detailed information about spec is included at this moment.
>
> Thanks,
> --
> Yuka
>


From masayoshi.okutsu at oracle.com  Thu Mar 27 15:36:50 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 28 Mar 2014 00:36:50 +0900
Subject: <i18n dev> Improve timezone mapping for AIX platform
In-Reply-To: <CA+3eh100td-WaqbMq9JbaVTGvRV=Csr8qdHzBsde5sqJ5PvLDA@mail.gmail.com>
References: <CAC-GWLc1KLNSqzr4h5uYwC6R+JxmgRkCmKv7LUVmw_LzhPEbHw@mail.gmail.com>	<53329D98.6040002@oracle.com>
	<CA+3eh100td-WaqbMq9JbaVTGvRV=Csr8qdHzBsde5sqJ5PvLDA@mail.gmail.com>
Message-ID: <53344592.90508@oracle.com>

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.okutsu at 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
>>


From iris.clark at oracle.com  Fri Mar 28 22:06:06 2014
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 28 Mar 2014 15:06:06 -0700 (PDT)
Subject: <i18n dev> Request for a JEP for JDK9 (Unicode support)
In-Reply-To: <5333C874.1040902@oracle.com>
References: <53327D7B.4050607@oracle.com>
	<443260df-b119-4d59-8524-f2756648845d@default>
	<5333C874.1040902@oracle.com>
Message-ID: <f54e267b-b0d6-437c-b9ee-a4cf5b10fb17@default>

Hi, Yuka.

Looks great!

iris

-----Original Message-----
From: Yuka Kamiya 
Sent: Wednesday, March 26, 2014 11:43 PM
To: Iris Clark; i18n-dev
Subject: Re: <i18n dev> Request for a JEP for JDK9 (Unicode support)

Hi Iris,

Thank you for your comment on my JEP.

I've revised the draft to reflect it. And also, all the Unicode versions ("x.y.0") in the JEP were replaced with "x.y" in passing, because they are official abbreviations for "x.y.0".

New draft is:
http://cr.openjdk.java.net/~peytoia/JEPs/Unicode.Next.md

Thanks in advance,
--
Yuka


(2014/03/27 3:23), Iris Clark wrote:
> Hi, Yuka.
>
> Looks good as the expected follow-on to the equivalent work in JDK 8 (JEP 133: Unicode 6.2 [1]).
>
> My only minor recommendation is that you consider adding a link to unicode.org [2] in the Summary.  As an example see lines 27-28 here [3].  (See [4] for additional MarkDown syntax.)
>
> Thanks,
> iris
>
> [1]: http://openjdk.java.net/jeps/133
> [2]: http://www.unicode.org/standard/standard.html
> [3]: http://hg.openjdk.java.net/jep/jeps/file/tip/jep-133.md
> [4]: http://daringfireball.net/projects/markdown/syntax
>
> -----Original Message-----
> From: Yuka Kamiya
> Sent: Wednesday, March 26, 2014 12:11 AM
> To: i18n-dev
> Subject: <i18n dev> Request for a JEP for JDK9 (Unicode support)
>
> Hello,
>
> This is a JEP to support the latest version of Unicode in JDK 9.
> I'd appreciate your comments/suggestions on:
> http://cr.openjdk.java.net/~peytoia/JEPs/Unicode.Next.txt
>
> https://bugs.openjdk.java.net/browse/JDK-8032446
>
> If I don't receive objections within this month, I'll submit this JEP to JEP submit alias.
>
> Note that this is still a draft, and no detailed information about spec is included at this moment.
>
> Thanks,
> --
> Yuka
>


From volker.simonis at gmail.com  Wed Mar 26 17:48:26 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 26 Mar 2014 18:48:26 +0100
Subject: <i18n dev> Improve timezone mapping for AIX platform
In-Reply-To: <53329D98.6040002@oracle.com>
References: <CAC-GWLc1KLNSqzr4h5uYwC6R+JxmgRkCmKv7LUVmw_LzhPEbHw@mail.gmail.com>
	<53329D98.6040002@oracle.com>
Message-ID: <CA+3eh100td-WaqbMq9JbaVTGvRV=Csr8qdHzBsde5sqJ5PvLDA@mail.gmail.com>

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.okutsu at 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
>
>