From luchsh at linux.vnet.ibm.com  Tue Apr  1 14:52:27 2014
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Tue, 1 Apr 2014 22:52:27 +0800
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: <CAC-GWLcoK6oSAcFhXkLUDYxGW64snDzwNm9Rrk2PdSWbGOAbzg@mail.gmail.com>

Hi Volker, Masayoshi,

Thanks a lot for your review, here's the updated patch, could you pls take
a look?

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


On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis <volker.simonis at gmail.com>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
>

Updated in new patch.


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

I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris'
as I observed on my AIX box,
solaris/lib is not the directory where tzmappings was stored for AIX.
So I'm keeping this change, please fix me if I was wrong about the config.


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


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


>
> @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.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
> >
> >
>

Many thanks
Jonathan

From aleksej.efimov at oracle.com  Wed Apr  2 10:55:10 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 02 Apr 2014 14:55:10 +0400
Subject: <i18n dev> RFR: 8038306: (tz) Support tzdata2014b
Message-ID: <533BEC8E.8080106@oracle.com>

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

From sean.coffey at oracle.com  Wed Apr  2 11:26:39 2014
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Wed, 02 Apr 2014 12:26:39 +0100
Subject: <i18n dev> RFR: 8038306: (tz) Support tzdata2014b
In-Reply-To: <533BEC8E.8080106@oracle.com>
References: <533BEC8E.8080106@oracle.com>
Message-ID: <533BF3EF.6060904@oracle.com>

Looks fine to me.

regards,
Sean.

On 02/04/14 11:55, 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


From luchsh at linux.vnet.ibm.com  Wed Apr  2 16:34:02 2014
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 3 Apr 2014 00:34:02 +0800
Subject: <i18n dev> Improve timezone mapping for AIX platform
In-Reply-To: <CA+3eh124zbpaCO_H49QFTJsx7R8LsxWgMiv0h2WTpz3vfuRNUg@mail.gmail.com>
References: <CAC-GWLc1KLNSqzr4h5uYwC6R+JxmgRkCmKv7LUVmw_LzhPEbHw@mail.gmail.com>
	<53329D98.6040002@oracle.com>
	<CA+3eh100td-WaqbMq9JbaVTGvRV=Csr8qdHzBsde5sqJ5PvLDA@mail.gmail.com>
	<CAC-GWLcoK6oSAcFhXkLUDYxGW64snDzwNm9Rrk2PdSWbGOAbzg@mail.gmail.com>
	<CA+3eh124zbpaCO_H49QFTJsx7R8LsxWgMiv0h2WTpz3vfuRNUg@mail.gmail.com>
Message-ID: <CAC-GWLfVdcJc3Vi+A6x+4P6TaoT-o5g79e9QiHuqk6M7AMg73g@mail.gmail.com>

 Hi Volker,

On 2014?04?02? 23:07, Volker Simonis wrote:

Hi Jonathan,

thanks for updating the change. Please find my comments inline:

On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu
<luchsh at linux.vnet.ibm.com> <luchsh at linux.vnet.ibm.com> wrote:

 Hi Volker, Masayoshi,

Thanks a lot for your review, here's the updated patch, could you pls take a
look?
http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/


On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis
<volker.simonis at gmail.com> <volker.simonis at gmail.com>
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

 Updated in new patch.


 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

 I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris'
as I observed on my AIX box,
solaris/lib is not the directory where tzmappings was stored for AIX.
So I'm keeping this change, please fix me if I was wrong about the config.


 Yes, but my point was to actually use OPENJDK_TARGET_OS for the
construction of  TZMAPPINGS_SRC as shown in the code snippet above.
OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX
and that should be just enough here.


That's right, let 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,
seehttp://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.okutsu at oracle.com> <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

  Many thanks
Jonathan

 Regards
Jonathan

From masayoshi.okutsu at oracle.com  Thu Apr  3 14:21:57 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 03 Apr 2014 23:21:57 +0900
Subject: <i18n dev> RFR: 8038306: (tz) Support tzdata2014b
In-Reply-To: <533BEC8E.8080106@oracle.com>
References: <533BEC8E.8080106@oracle.com>
Message-ID: <533D6E85.3030108@oracle.com>

Hi Aleksej,

Sorry, but I forgot about the generic names. "Coordinated Universal 
Time" and "UTC"shouldn'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


From aleksej.efimov at oracle.com  Thu Apr  3 14:29:00 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 03 Apr 2014 18:29:00 +0400
Subject: <i18n dev> RFR: 8038306: (tz) Support tzdata2014b
In-Reply-To: <533D6E85.3030108@oracle.com>
References: <533BEC8E.8080106@oracle.com> <533D6E85.3030108@oracle.com>
Message-ID: <533D702C.50100@oracle.com>

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 "UTC"shouldn'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
>


From luchsh at linux.vnet.ibm.com  Fri Apr  4 08:18:32 2014
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Fri, 4 Apr 2014 16:18:32 +0800
Subject: <i18n dev> Improve timezone mapping for AIX platform
In-Reply-To: <CAC-GWLfVdcJc3Vi+A6x+4P6TaoT-o5g79e9QiHuqk6M7AMg73g@mail.gmail.com>
References: <CAC-GWLc1KLNSqzr4h5uYwC6R+JxmgRkCmKv7LUVmw_LzhPEbHw@mail.gmail.com>
	<53329D98.6040002@oracle.com>
	<CA+3eh100td-WaqbMq9JbaVTGvRV=Csr8qdHzBsde5sqJ5PvLDA@mail.gmail.com>
	<CAC-GWLcoK6oSAcFhXkLUDYxGW64snDzwNm9Rrk2PdSWbGOAbzg@mail.gmail.com>
	<CA+3eh124zbpaCO_H49QFTJsx7R8LsxWgMiv0h2WTpz3vfuRNUg@mail.gmail.com>
	<CAC-GWLfVdcJc3Vi+A6x+4P6TaoT-o5g79e9QiHuqk6M7AMg73g@mail.gmail.com>
Message-ID: <CAC-GWLeJEh3cyFPNTijdiAUnxS7iAUT=GYNeBo2xej_kCYT9Kw@mail.gmail.com>

Hi Volker, Masayoshi,

I made another  patch which fixed the problems mentioned in last mail,

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

Could you pls help to take a look?

Many thanks
Jonathan



On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com>wrote:

>  Hi Volker,
>
>
> On 2014?04?02? 23:07, Volker Simonis wrote:
>
> Hi Jonathan,
>
> thanks for updating the change. Please find my comments inline:
>
> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu <luchsh at linux.vnet.ibm.com> <luchsh at linux.vnet.ibm.com> wrote:
>
>  Hi Volker, Masayoshi,
>
> Thanks a lot for your review, here's the updated patch, could you pls take a
> look?
> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/
>
>
> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis <volker.simonis at gmail.com> <volker.simonis at gmail.com>
> 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
>
>  Updated in new patch.
>
>
>  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
>
>  I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris'
> as I observed on my AIX box,
> solaris/lib is not the directory where tzmappings was stored for AIX.
> So I'm keeping this change, please fix me if I was wrong about the config.
>
>
>  Yes, but my point was to actually use OPENJDK_TARGET_OS for the
> construction of  TZMAPPINGS_SRC as shown in the code snippet above.
> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX
> and that should be just enough here.
>
>
> That's right, let 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,
> seehttp://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.okutsu at oracle.com> <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
>
>   Many thanks
> Jonathan
>
>  Regards
> Jonathan
>

From aleksej.efimov at oracle.com  Fri Apr  4 12:19:03 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Fri, 04 Apr 2014 16:19:03 +0400
Subject: <i18n dev> RFR: 8038306: (tz) Support tzdata2014b
In-Reply-To: <533D702C.50100@oracle.com>
References: <533BEC8E.8080106@oracle.com> <533D6E85.3030108@oracle.com>
	<533D702C.50100@oracle.com>
Message-ID: <533EA337.4040109@oracle.com>

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 "UTC"shouldn'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
>>
>


From masayoshi.okutsu at oracle.com  Fri Apr  4 14:25:51 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 04 Apr 2014 23:25:51 +0900
Subject: <i18n dev> RFR: 8038306: (tz) Support tzdata2014b
In-Reply-To: <533EA337.4040109@oracle.com>
References: <533BEC8E.8080106@oracle.com> <533D6E85.3030108@oracle.com>
	<533D702C.50100@oracle.com> <533EA337.4040109@oracle.com>
Message-ID: <533EC0EF.2030107@oracle.com>

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 "UTC"shouldn'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
>>>
>>
>


From aleksej.efimov at oracle.com  Fri Apr  4 15:19:45 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Fri, 04 Apr 2014 19:19:45 +0400
Subject: <i18n dev> RFR: 8038306: (tz) Support tzdata2014b
In-Reply-To: <533EC0EF.2030107@oracle.com>
References: <533BEC8E.8080106@oracle.com> <533D6E85.3030108@oracle.com>
	<533D702C.50100@oracle.com> <533EA337.4040109@oracle.com>
	<533EC0EF.2030107@oracle.com>
Message-ID: <533ECD91.4040608@oracle.com>

Masayoshi,
Thank you for the review. The "TST" is already used by "Asia/Taipei" in 
"zh_TW".  I'll leave the naming as it is, because I suppose that we 
probably should see an official short name abbreviation for this time 
zone in near future.

-Aleksej
On 04/04/2014 06:25 PM, Masayoshi Okutsu wrote:
> 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 "UTC"shouldn'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
>>>>
>>>
>>
>


From mark at macchiato.com  Wed Apr  9 10:11:08 2014
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Wed, 9 Apr 2014 12:11:08 +0200
Subject: <i18n dev> Problems drawing supplemental characters in Java.
Message-ID: <CAJ2xs_FN9zesgn=0ZuA+fhsgfCMO1bd4=pFd2BFa0x8uJfYGsw@mail.gmail.com>

I'm having some trouble with drawing supplemental characters in Java. It
appears to be due to bugs in Java.

*First, how do I report this? And second, can anyone think of a
work-around?*

This is on a Mac OS 10.9.2, JDK 7, and I am rendering a number of
characters in a loop.

When I call

                graphics.drawString(s, xStart, ascent);

Each supplemental character that shares the same first char (high
surrogate) gets the same image (see attachments).

It appears that it is caching by char instead of by code point.


To work around the problem, I tried changing the code to draw glyph vectors
instead.

                FontRenderContext frc = graphics.getFontRenderContext();

                GlyphVector gv = myFont.createGlyphVector(frc, s);

                ...

                Shape shape = gv.getOutline(xStart, ascent);

                graphics.draw(shape);

To my surprise, it got even worse: I get an unknown glyph after each image.
See attachments.

It appears that when it is advancing through the string to get the glyphs,
it is picking up the glyph ID for the code point, but then it is only
advancing by 1, so it is always picking up garbage after each character.

From naoto.sato at oracle.com  Wed Apr  9 16:17:06 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 09 Apr 2014 09:17:06 -0700
Subject: <i18n dev> Problems drawing supplemental characters in Java.
In-Reply-To: <CAJ2xs_FN9zesgn=0ZuA+fhsgfCMO1bd4=pFd2BFa0x8uJfYGsw@mail.gmail.com>
References: <CAJ2xs_FN9zesgn=0ZuA+fhsgfCMO1bd4=pFd2BFa0x8uJfYGsw@mail.gmail.com>
Message-ID: <53457282.2030106@oracle.com>

Hi Mark,

On 4/9/14, 3:11 AM, Mark Davis ?? wrote:
> I'm having some trouble with drawing supplemental characters in Java. It
> appears to be due to bugs in Java.
>
> *First, how do I report this? And second, can anyone think of a
> work-around?*

Here is the link to report an issue against JDK:

http://bugreport.java.com/bugreport/

Please choose "classes_2d" as the subcategory.

>
> This is on a Mac OS 10.9.2, JDK 7, and I am rendering a number of
> characters in a loop.
>
> When I call
>
>                  graphics.drawString(s, xStart, ascent);
>
> Each supplemental character that shares the same first char (high
> surrogate) gets the same image (see attachments).
>
> It appears that it is caching by char instead of by code point.
>
>
> To work around the problem, I tried changing the code to draw glyph
> vectors instead.
>
>                  FontRenderContext frc = graphics.getFontRenderContext();
>
>                  GlyphVector gv = myFont.createGlyphVector(frc, s);
>
>                  ...
>
>                  Shape shape = gv.getOutline(xStart, ascent);
>
>                  graphics.draw(shape);
>
> To my surprise, it got even worse: I get an unknown glyph after each
> image. See attachments.
>
> It appears that when it is advancing through the string to get the
> glyphs, it is picking up the glyph ID for the code point, but then it is
> only advancing by 1, so it is always picking up garbage after each
> character.

Yeah, your explanation does sound like what's happening in the font 
rendering on MacOSX. Phil/Mike, do you have any idea what's going on?

Naoto

From volker.simonis at gmail.com  Wed Apr  2 15:07:14 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 2 Apr 2014 17:07:14 +0200
Subject: <i18n dev> Improve timezone mapping for AIX platform
In-Reply-To: <CAC-GWLcoK6oSAcFhXkLUDYxGW64snDzwNm9Rrk2PdSWbGOAbzg@mail.gmail.com>
References: <CAC-GWLc1KLNSqzr4h5uYwC6R+JxmgRkCmKv7LUVmw_LzhPEbHw@mail.gmail.com>
	<53329D98.6040002@oracle.com>
	<CA+3eh100td-WaqbMq9JbaVTGvRV=Csr8qdHzBsde5sqJ5PvLDA@mail.gmail.com>
	<CAC-GWLcoK6oSAcFhXkLUDYxGW64snDzwNm9Rrk2PdSWbGOAbzg@mail.gmail.com>
Message-ID: <CA+3eh124zbpaCO_H49QFTJsx7R8LsxWgMiv0h2WTpz3vfuRNUg@mail.gmail.com>

Hi Jonathan,

thanks for updating the change. Please find my comments inline:

On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu <luchsh at linux.vnet.ibm.com> wrote:
> Hi Volker, Masayoshi,
>
> Thanks a lot for your review, here's the updated patch, could you pls take a
> look?
>
> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/
>
>
> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis <volker.simonis at gmail.com>
> 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
>
>
> Updated in new patch.
>
>>
>> 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
>
>
> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris'
> as I observed on my AIX box,
> solaris/lib is not the directory where tzmappings was stored for AIX.
> So I'm keeping this change, please fix me if I was wrong about the config.
>

Yes, but my point was to actually use OPENJDK_TARGET_OS for the
construction of  TZMAPPINGS_SRC as shown in the code snippet above.
OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX
and that should be just enough here.

>>
>>
>> 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().


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.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
>> >
>> >
>
>
> Many thanks
> Jonathan

From volker.simonis at gmail.com  Fri Apr  4 13:22:33 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 4 Apr 2014 15:22:33 +0200
Subject: <i18n dev> Improve timezone mapping for AIX platform
In-Reply-To: <CAC-GWLeJEh3cyFPNTijdiAUnxS7iAUT=GYNeBo2xej_kCYT9Kw@mail.gmail.com>
References: <CAC-GWLc1KLNSqzr4h5uYwC6R+JxmgRkCmKv7LUVmw_LzhPEbHw@mail.gmail.com>
	<53329D98.6040002@oracle.com>
	<CA+3eh100td-WaqbMq9JbaVTGvRV=Csr8qdHzBsde5sqJ5PvLDA@mail.gmail.com>
	<CAC-GWLcoK6oSAcFhXkLUDYxGW64snDzwNm9Rrk2PdSWbGOAbzg@mail.gmail.com>
	<CA+3eh124zbpaCO_H49QFTJsx7R8LsxWgMiv0h2WTpz3vfuRNUg@mail.gmail.com>
	<CAC-GWLfVdcJc3Vi+A6x+4P6TaoT-o5g79e9QiHuqk6M7AMg73g@mail.gmail.com>
	<CAC-GWLeJEh3cyFPNTijdiAUnxS7iAUT=GYNeBo2xej_kCYT9Kw@mail.gmail.com>
Message-ID: <CA+3eh11per7n0dF7JNT2MSWws9uuzxGJOkpxyetuS69VhYHuzA@mail.gmail.com>

Hi Jonathan,

sorry, but I found a few more issues:

- please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise
somebody could easily crash the VM by specifying a TZ with more than
100 characters.

- you can delete the lines 871-872 because the variables are actually
not used and you can also remove the handling for "timezone == 0"
because that is actually done in getGMTOffsetID() anyway.

- could you please avoid the usage of strtok. It is not intended for
usage in a multithreaded environment (see for example "man strtok" on
AIX). strtok_r is probably overkill, but you could use for example
strchr.

did you check the build on Windows?

Thank you and best regards,
Volker


On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com> wrote:
> Hi Volker, Masayoshi,
>
> I made another  patch which fixed the problems mentioned in last mail,
>
> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/
>
> Could you pls help to take a look?
>
> Many thanks
> Jonathan
>
>
>
> On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com>
> wrote:
>>
>> Hi Volker,
>>
>>
>> On 2014?04?02? 23:07, Volker Simonis wrote:
>>
>> Hi Jonathan,
>>
>> thanks for updating the change. Please find my comments inline:
>>
>> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu <luchsh at linux.vnet.ibm.com>
>> wrote:
>>
>> Hi Volker, Masayoshi,
>>
>> Thanks a lot for your review, here's the updated patch, could you pls take
>> a
>> look?
>>
>> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/
>>
>>
>> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis <volker.simonis at gmail.com>
>> 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
>>
>> Updated in new patch.
>>
>> 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
>>
>> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is
>> 'solaris'
>> as I observed on my AIX box,
>> solaris/lib is not the directory where tzmappings was stored for AIX.
>> So I'm keeping this change, please fix me if I was wrong about the config.
>>
>> Yes, but my point was to actually use OPENJDK_TARGET_OS for the
>> construction of  TZMAPPINGS_SRC as shown in the code snippet above.
>> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX
>> and that should be just enough here.
>>
>>
>> That's right, let 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.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
>>
>> Many thanks
>> Jonathan
>>
>> Regards
>> Jonathan
>
>

From philip.race at oracle.com  Wed Apr  9 16:31:59 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 09 Apr 2014 09:31:59 -0700
Subject: <i18n dev> Problems drawing supplemental characters in Java.
In-Reply-To: <53457282.2030106@oracle.com>
References: <CAJ2xs_FN9zesgn=0ZuA+fhsgfCMO1bd4=pFd2BFa0x8uJfYGsw@mail.gmail.com>
	<53457282.2030106@oracle.com>
Message-ID: <534575FF.2070709@oracle.com>

Sounds like https://bugs.openjdk.java.net/browse/JDK-8015556
[macosx] surrogate pairs do not render properly (show up as boxes or 
incorrect glyphs)

But that was fixed in 7u40. What JDK 7 update is in use here ?

-phil.

On 4/9/14 9:17 AM, Naoto Sato wrote:
> Hi Mark,
>
> On 4/9/14, 3:11 AM, Mark Davis ?? wrote:
>> I'm having some trouble with drawing supplemental characters in Java. It
>> appears to be due to bugs in Java.
>>
>> *First, how do I report this? And second, can anyone think of a
>> work-around?*
>
> Here is the link to report an issue against JDK:
>
> http://bugreport.java.com/bugreport/
>
> Please choose "classes_2d" as the subcategory.
>
>>
>> This is on a Mac OS 10.9.2, JDK 7, and I am rendering a number of
>> characters in a loop.
>>
>> When I call
>>
>>                  graphics.drawString(s, xStart, ascent);
>>
>> Each supplemental character that shares the same first char (high
>> surrogate) gets the same image (see attachments).
>>
>> It appears that it is caching by char instead of by code point.
>>
>>
>> To work around the problem, I tried changing the code to draw glyph
>> vectors instead.
>>
>>                  FontRenderContext frc = 
>> graphics.getFontRenderContext();
>>
>>                  GlyphVector gv = myFont.createGlyphVector(frc, s);
>>
>>                  ...
>>
>>                  Shape shape = gv.getOutline(xStart, ascent);
>>
>>                  graphics.draw(shape);
>>
>> To my surprise, it got even worse: I get an unknown glyph after each
>> image. See attachments.
>>
>> It appears that when it is advancing through the string to get the
>> glyphs, it is picking up the glyph ID for the code point, but then it is
>> only advancing by 1, so it is always picking up garbage after each
>> character.
>
> Yeah, your explanation does sound like what's happening in the font 
> rendering on MacOSX. Phil/Mike, do you have any idea what's going on?
>
> Naoto


From mark at macchiato.com  Wed Apr  9 17:29:35 2014
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Wed, 9 Apr 2014 19:29:35 +0200
Subject: <i18n dev> Problems drawing supplemental characters in Java.
In-Reply-To: <534575FF.2070709@oracle.com>
References: <CAJ2xs_FN9zesgn=0ZuA+fhsgfCMO1bd4=pFd2BFa0x8uJfYGsw@mail.gmail.com>
	<53457282.2030106@oracle.com> <534575FF.2070709@oracle.com>
Message-ID: <CAJ2xs_H3mZauBgfna9uOGV0oBXrR5dVb2OHwUMY_rnvKs0yB4w@mail.gmail.com>

jdk1.7.0_25.jdk


Mark <https://google.com/+MarkDavis>

 *? Il meglio ? l?inimico del bene ?*


On 9 April 2014 18:31, Phil Race <philip.race at oracle.com> wrote:

>  Sounds like https://bugs.openjdk.java.net/browse/JDK-8015556
>  [macosx] surrogate pairs do not render properly (show up as boxes or
> incorrect glyphs)
>
> But that was fixed in 7u40. What JDK 7 update is in use here ?
>
> -phil.
>
>
> On 4/9/14 9:17 AM, Naoto Sato wrote:
>
> Hi Mark,
>
> On 4/9/14, 3:11 AM, Mark Davis ?? wrote:
>
> I'm having some trouble with drawing supplemental characters in Java. It
> appears to be due to bugs in Java.
>
> *First, how do I report this? And second, can anyone think of a
> work-around?*
>
>
> Here is the link to report an issue against JDK:
>
> http://bugreport.java.com/bugreport/
>
> Please choose "classes_2d" as the subcategory.
>
>
> This is on a Mac OS 10.9.2, JDK 7, and I am rendering a number of
> characters in a loop.
>
> When I call
>
>                  graphics.drawString(s, xStart, ascent);
>
> Each supplemental character that shares the same first char (high
> surrogate) gets the same image (see attachments).
>
> It appears that it is caching by char instead of by code point.
>
>
> To work around the problem, I tried changing the code to draw glyph
> vectors instead.
>
>                  FontRenderContext frc = graphics.getFontRenderContext();
>
>                  GlyphVector gv = myFont.createGlyphVector(frc, s);
>
>                  ...
>
>                  Shape shape = gv.getOutline(xStart, ascent);
>
>                  graphics.draw(shape);
>
> To my surprise, it got even worse: I get an unknown glyph after each
> image. See attachments.
>
> It appears that when it is advancing through the string to get the
> glyphs, it is picking up the glyph ID for the code point, but then it is
> only advancing by 1, so it is always picking up garbage after each
> character.
>
>
> Yeah, your explanation does sound like what's happening in the font
> rendering on MacOSX. Phil/Mike, do you have any idea what's going on?
>
> Naoto
>
>
>

From philip.race at oracle.com  Wed Apr  9 17:43:43 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 09 Apr 2014 10:43:43 -0700
Subject: <i18n dev> Problems drawing supplemental characters in Java.
In-Reply-To: <CAJ2xs_H3mZauBgfna9uOGV0oBXrR5dVb2OHwUMY_rnvKs0yB4w@mail.gmail.com>
References: <CAJ2xs_FN9zesgn=0ZuA+fhsgfCMO1bd4=pFd2BFa0x8uJfYGsw@mail.gmail.com>
	<53457282.2030106@oracle.com> <534575FF.2070709@oracle.com>
	<CAJ2xs_H3mZauBgfna9uOGV0oBXrR5dVb2OHwUMY_rnvKs0yB4w@mail.gmail.com>
Message-ID: <534586CF.2050101@oracle.com>

So can you please update to 7u51 (current security baseline) and see if 
that cures it ?
http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html

-phil.

On 4/9/2014 10:29 AM, Mark Davis ?? wrote:
> jdk1.7.0_25.jdk
>
>
> Mark <https://google.com/+MarkDavis>
> /
> /
> /? Il meglio ? l?inimico del bene ?/
> //
>
>
> On 9 April 2014 18:31, Phil Race <philip.race at oracle.com 
> <mailto:philip.race at oracle.com>> wrote:
>
>     Sounds like https://bugs.openjdk.java.net/browse/JDK-8015556
>     [macosx] surrogate pairs do not render properly (show up as boxes
>     or incorrect glyphs)
>
>     But that was fixed in 7u40. What JDK 7 update is in use here ?
>
>     -phil.
>
>
>     On 4/9/14 9:17 AM, Naoto Sato wrote:
>>     Hi Mark,
>>
>>     On 4/9/14, 3:11 AM, Mark Davis ?? wrote:
>>>     I'm having some trouble with drawing supplemental characters in
>>>     Java. It
>>>     appears to be due to bugs in Java.
>>>
>>>     *First, how do I report this? And second, can anyone think of a
>>>     work-around?*
>>
>>     Here is the link to report an issue against JDK:
>>
>>     http://bugreport.java.com/bugreport/
>>
>>     Please choose "classes_2d" as the subcategory.
>>
>>>
>>>     This is on a Mac OS 10.9.2, JDK 7, and I am rendering a number of
>>>     characters in a loop.
>>>
>>>     When I call
>>>
>>>                      graphics.drawString(s, xStart, ascent);
>>>
>>>     Each supplemental character that shares the same first char (high
>>>     surrogate) gets the same image (see attachments).
>>>
>>>     It appears that it is caching by char instead of by code point.
>>>
>>>
>>>     To work around the problem, I tried changing the code to draw glyph
>>>     vectors instead.
>>>
>>>                      FontRenderContext frc =
>>>     graphics.getFontRenderContext();
>>>
>>>                      GlyphVector gv = myFont.createGlyphVector(frc, s);
>>>
>>>                      ...
>>>
>>>                      Shape shape = gv.getOutline(xStart, ascent);
>>>
>>>                      graphics.draw(shape);
>>>
>>>     To my surprise, it got even worse: I get an unknown glyph after
>>>     each
>>>     image. See attachments.
>>>
>>>     It appears that when it is advancing through the string to get the
>>>     glyphs, it is picking up the glyph ID for the code point, but
>>>     then it is
>>>     only advancing by 1, so it is always picking up garbage after each
>>>     character.
>>
>>     Yeah, your explanation does sound like what's happening in the
>>     font rendering on MacOSX. Phil/Mike, do you have any idea what's
>>     going on?
>>
>>     Naoto
>
>


From mark at macchiato.com  Wed Apr  9 19:28:41 2014
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Wed, 9 Apr 2014 21:28:41 +0200
Subject: <i18n dev> Problems drawing supplemental characters in Java.
In-Reply-To: <534586CF.2050101@oracle.com>
References: <CAJ2xs_FN9zesgn=0ZuA+fhsgfCMO1bd4=pFd2BFa0x8uJfYGsw@mail.gmail.com>
	<53457282.2030106@oracle.com> <534575FF.2070709@oracle.com>
	<CAJ2xs_H3mZauBgfna9uOGV0oBXrR5dVb2OHwUMY_rnvKs0yB4w@mail.gmail.com>
	<534586CF.2050101@oracle.com>
Message-ID: <CAJ2xs_E7CO78_4_bJr0Kk8rMqJhxLFRBmYn_932AOk8Sov_eiA@mail.gmail.com>

Fixes it, thanks!!


Mark <https://google.com/+MarkDavis>

 *? Il meglio ? l?inimico del bene ?*


On 9 April 2014 19:43, Phil Race <philip.race at oracle.com> wrote:

> So can you please update to 7u51 (current security baseline) and see if
> that cures it ?
> http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html
>
> -phil.
>
> On 4/9/2014 10:29 AM, Mark Davis ?? wrote:
>
>> jdk1.7.0_25.jdk
>>
>>
>> Mark <https://google.com/+MarkDavis>
>> /
>> /
>> /? Il meglio ? l?inimico del bene ?/
>> //
>>
>>
>>
>> On 9 April 2014 18:31, Phil Race <philip.race at oracle.com <mailto:
>> philip.race at oracle.com>> wrote:
>>
>>     Sounds like https://bugs.openjdk.java.net/browse/JDK-8015556
>>     [macosx] surrogate pairs do not render properly (show up as boxes
>>     or incorrect glyphs)
>>
>>     But that was fixed in 7u40. What JDK 7 update is in use here ?
>>
>>     -phil.
>>
>>
>>     On 4/9/14 9:17 AM, Naoto Sato wrote:
>>
>>>     Hi Mark,
>>>
>>>     On 4/9/14, 3:11 AM, Mark Davis ?? wrote:
>>>
>>>>     I'm having some trouble with drawing supplemental characters in
>>>>     Java. It
>>>>     appears to be due to bugs in Java.
>>>>
>>>>     *First, how do I report this? And second, can anyone think of a
>>>>     work-around?*
>>>>
>>>
>>>     Here is the link to report an issue against JDK:
>>>
>>>     http://bugreport.java.com/bugreport/
>>>
>>>     Please choose "classes_2d" as the subcategory.
>>>
>>>
>>>>     This is on a Mac OS 10.9.2, JDK 7, and I am rendering a number of
>>>>     characters in a loop.
>>>>
>>>>     When I call
>>>>
>>>>                      graphics.drawString(s, xStart, ascent);
>>>>
>>>>     Each supplemental character that shares the same first char (high
>>>>     surrogate) gets the same image (see attachments).
>>>>
>>>>     It appears that it is caching by char instead of by code point.
>>>>
>>>>
>>>>     To work around the problem, I tried changing the code to draw glyph
>>>>     vectors instead.
>>>>
>>>>                      FontRenderContext frc =
>>>>     graphics.getFontRenderContext();
>>>>
>>>>                      GlyphVector gv = myFont.createGlyphVector(frc, s);
>>>>
>>>>                      ...
>>>>
>>>>                      Shape shape = gv.getOutline(xStart, ascent);
>>>>
>>>>                      graphics.draw(shape);
>>>>
>>>>     To my surprise, it got even worse: I get an unknown glyph after
>>>>     each
>>>>     image. See attachments.
>>>>
>>>>     It appears that when it is advancing through the string to get the
>>>>     glyphs, it is picking up the glyph ID for the code point, but
>>>>     then it is
>>>>     only advancing by 1, so it is always picking up garbage after each
>>>>     character.
>>>>
>>>
>>>     Yeah, your explanation does sound like what's happening in the
>>>     font rendering on MacOSX. Phil/Mike, do you have any idea what's
>>>     going on?
>>>
>>>     Naoto
>>>
>>
>>
>>
>

From xueming.shen at oracle.com  Wed Apr  9 21:51:53 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 09 Apr 2014 14:51:53 -0700
Subject: <i18n dev> RFR: JDK-8039751: UTF-8 decoder fails to handle some
 edge cases correctly
Message-ID: <5345C0F9.8020601@oracle.com>

Hi,

Please help review the fix for JDK-8039751.

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


This is the corner case (in 4 bytes sequence) we missed when fixing 7096080 [1].
The UTF_8 decoder correctly returns the malformed length for some malformed
4-byte illegal byte sequence (via Decoder.malformedN(...)), but it fails to do so if
there is no enough (< 4 bytes) bytes in input buffer (via isMalfromed4_2(...))

The proposed change fixes these corner cases.

Hey Mark, my reading of tomcat's test case suggests "malformed 4-byte sequence"
is the only thing left after the jdk8 fix, right?

Thanks!
-Sherman

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

From markt at apache.org  Wed Apr  9 23:43:23 2014
From: markt at apache.org (Mark Thomas)
Date: Wed, 09 Apr 2014 17:43:23 -0600
Subject: <i18n dev> RFR: JDK-8039751: UTF-8 decoder fails to handle some
 edge cases correctly
In-Reply-To: <5345C0F9.8020601@oracle.com>
References: <5345C0F9.8020601@oracle.com>
Message-ID: <5345DB1B.6080708@apache.org>

On 09/04/2014 15:51, Xueming Shen wrote:
> Hi,
> 
> Please help review the fix for JDK-8039751.
> 
> Issue:     https://bugs.openjdk.java.net/browse/JDK-8039751
> webrev:  http://cr.openjdk.java.net/~sherman/8039751/webrev/
> 
> 
> This is the corner case (in 4 bytes sequence) we missed when fixing
> 7096080 [1].
> The UTF_8 decoder correctly returns the malformed length for some malformed
> 4-byte illegal byte sequence (via Decoder.malformedN(...)), but it fails
> to do so if
> there is no enough (< 4 bytes) bytes in input buffer (via
> isMalfromed4_2(...))
> 
> The proposed change fixes these corner cases.
> 
> Hey Mark, my reading of tomcat's test case suggests "malformed 4-byte
> sequence"
> is the only thing left after the jdk8 fix, right?

Thanks for such a quick response.

I agree with your reading of the Tomcat test case. There are two
slightly different edge cases here.

The first is the one I explained in detail in the bug report where you
know from the first two bytes that whatever the next two bytes are, the
result is going to be larger than the largest valid code point.

The second is where you know from the first two bytes that whatever the
next two bytes are, the code point should have been encoded in fewer bytes.

If I am reading your additional test cases correctly, you have both of
these covered.

Many thanks,

Mark

> 
> Thanks!
> -Sherman
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-7096080


From luchsh at linux.vnet.ibm.com  Thu Apr 10 09:44:16 2014
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 10 Apr 2014 17:44:16 +0800
Subject: <i18n dev> Improve timezone mapping for AIX platform
In-Reply-To: <CA+3eh11per7n0dF7JNT2MSWws9uuzxGJOkpxyetuS69VhYHuzA@mail.gmail.com>
References: <CAC-GWLc1KLNSqzr4h5uYwC6R+JxmgRkCmKv7LUVmw_LzhPEbHw@mail.gmail.com>
	<53329D98.6040002@oracle.com>
	<CA+3eh100td-WaqbMq9JbaVTGvRV=Csr8qdHzBsde5sqJ5PvLDA@mail.gmail.com>
	<CAC-GWLcoK6oSAcFhXkLUDYxGW64snDzwNm9Rrk2PdSWbGOAbzg@mail.gmail.com>
	<CA+3eh124zbpaCO_H49QFTJsx7R8LsxWgMiv0h2WTpz3vfuRNUg@mail.gmail.com>
	<CAC-GWLfVdcJc3Vi+A6x+4P6TaoT-o5g79e9QiHuqk6M7AMg73g@mail.gmail.com>
	<CAC-GWLeJEh3cyFPNTijdiAUnxS7iAUT=GYNeBo2xej_kCYT9Kw@mail.gmail.com>
	<CA+3eh11per7n0dF7JNT2MSWws9uuzxGJOkpxyetuS69VhYHuzA@mail.gmail.com>
Message-ID: <CAC-GWLfS2pPJ5R2eKTO31-Op5C3q7oR6rx_M4XHGqJ+RuaTZOA@mail.gmail.com>

Hi Volker,

Thanks a lot for your comments, I've made another patch,

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


On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis <volker.simonis at gmail.com>wrote:

> Hi Jonathan,
>
> sorry, but I found a few more issues:
>
> - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise
> somebody could easily crash the VM by specifying a TZ with more than
> 100 characters.
>

Right, I've fix it by using strncpy, and also updated another usage of
strcmp().



>
> - you can delete the lines 871-872 because the variables are actually
> not used and you can also remove the handling for "timezone == 0"
> because that is actually done in getGMTOffsetID() anyway.
>

Nice catch, have deleted those in latest patch.


>
> - could you please avoid the usage of strtok. It is not intended for
> usage in a multithreaded environment (see for example "man strtok" on
> AIX). strtok_r is probably overkill, but you could use for example
> strchr.
>

I've changed it to strtok_r in this patch,
 although strtok was only used once here, it may still impact other threads.


> did you check the build on Windows?
>

Yes, both patches got built on Windows.


>
> Thank you and best regards,
> Volker
>
>
> On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com>
> wrote:
> > Hi Volker, Masayoshi,
> >
> > I made another  patch which fixed the problems mentioned in last mail,
> >
> > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/
> >
> > Could you pls help to take a look?
> >
> > Many thanks
> > Jonathan
> >
> >
> >
> > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com>
> > wrote:
> >>
> >> Hi Volker,
> >>
> >>
> >> On 2014?04?02? 23:07, Volker Simonis wrote:
> >>
> >> Hi Jonathan,
> >>
> >> thanks for updating the change. Please find my comments inline:
> >>
> >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu <luchsh at linux.vnet.ibm.com>
> >> wrote:
> >>
> >> Hi Volker, Masayoshi,
> >>
> >> Thanks a lot for your review, here's the updated patch, could you pls
> take
> >> a
> >> look?
> >>
> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/
> >>
> >>
> >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis <
> volker.simonis at gmail.com>
> >> 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
> >>
> >> Updated in new patch.
> >>
> >> 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
> >>
> >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is
> >> 'solaris'
> >> as I observed on my AIX box,
> >> solaris/lib is not the directory where tzmappings was stored for AIX.
> >> So I'm keeping this change, please fix me if I was wrong about the
> config.
> >>
> >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the
> >> construction of  TZMAPPINGS_SRC as shown in the code snippet above.
> >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX
> >> and that should be just enough here.
> >>
> >>
> >> That's right, let 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.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
> >>
> >> Many thanks
> >> Jonathan
> >>
> >> Regards
> >> Jonathan
> >
> >
>

Regards
Jonathan

From mark at macchiato.com  Thu Apr 10 12:45:43 2014
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Thu, 10 Apr 2014 14:45:43 +0200
Subject: <i18n dev> Problems drawing supplemental characters in Java.
In-Reply-To: <CAJ2xs_E7CO78_4_bJr0Kk8rMqJhxLFRBmYn_932AOk8Sov_eiA@mail.gmail.com>
References: <CAJ2xs_FN9zesgn=0ZuA+fhsgfCMO1bd4=pFd2BFa0x8uJfYGsw@mail.gmail.com>
	<53457282.2030106@oracle.com> <534575FF.2070709@oracle.com>
	<CAJ2xs_H3mZauBgfna9uOGV0oBXrR5dVb2OHwUMY_rnvKs0yB4w@mail.gmail.com>
	<534586CF.2050101@oracle.com>
	<CAJ2xs_E7CO78_4_bJr0Kk8rMqJhxLFRBmYn_932AOk8Sov_eiA@mail.gmail.com>
Message-ID: <CAJ2xs_E_Vsk46ET1iD8BmBdF6up-W+=3969zvni+q3ruzxRT3w@mail.gmail.com>

One further question.

On the Mac, some characters are given a default emoji presentation, and
appear with a colored image. This is done by substituting the glyph from
the Apple Color Emoji.

With drawString(), when I try to draw a character in (say) Symbola that by
default on the Mac is emoji, the font says .canDisplay(...) is true, but I
get no image, just blank. It's like drawing a space.

If I try to draw *any* character in Apple Color Emoji, I get a blank as
well.

Is there any way to work around this, and use the Apple Color Emoji?

Note: I tried using a JTextArea to work around this. When I changed the
existing TextAreaDemo.java to add the following 2 lines, it crashed!

        textArea.setFont(*new* Font("Apple Color Emoji", 0, 18));

        textArea.setText("abc??def");


Same happens if the setText line is omitted, and if you simply paste in an
emoji character into the running program.


Mark <https://google.com/+MarkDavis>

 *? Il meglio ? l?inimico del bene ?*


On 9 April 2014 21:28, Mark Davis ?? <mark at macchiato.com> wrote:

> Fixes it, thanks!!
>
>
> Mark <https://google.com/+MarkDavis>
>
>  *? Il meglio ? l?inimico del bene ?*
>
>
> On 9 April 2014 19:43, Phil Race <philip.race at oracle.com> wrote:
>
> > So can you please update to 7u51 (current security baseline) and see if
> > that cures it ?
> > http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html
> >
> > -phil.
> >
> > On 4/9/2014 10:29 AM, Mark Davis ?? wrote:
> >
> >> jdk1.7.0_25.jdk
> >>
> >>
> >> Mark <https://google.com/+MarkDavis>
> >> /
> >> /
> >> /? Il meglio ? l?inimico del bene ?/
> >> //
> >>
> >>
> >>
> >> On 9 April 2014 18:31, Phil Race <philip.race at oracle.com <mailto:
> >> philip.race at oracle.com>> wrote:
> >>
> >>     Sounds like https://bugs.openjdk.java.net/browse/JDK-8015556
> >>     [macosx] surrogate pairs do not render properly (show up as boxes
> >>     or incorrect glyphs)
> >>
> >>     But that was fixed in 7u40. What JDK 7 update is in use here ?
> >>
> >>     -phil.
> >>
> >>
> >>     On 4/9/14 9:17 AM, Naoto Sato wrote:
> >>
> >>>     Hi Mark,
> >>>
> >>>     On 4/9/14, 3:11 AM, Mark Davis ?? wrote:
> >>>
> >>>>     I'm having some trouble with drawing supplemental characters in
> >>>>     Java. It
> >>>>     appears to be due to bugs in Java.
> >>>>
> >>>>     *First, how do I report this? And second, can anyone think of a
> >>>>     work-around?*
> >>>>
> >>>
> >>>     Here is the link to report an issue against JDK:
> >>>
> >>>     http://bugreport.java.com/bugreport/
> >>>
> >>>     Please choose "classes_2d" as the subcategory.
> >>>
> >>>
> >>>>     This is on a Mac OS 10.9.2, JDK 7, and I am rendering a number of
> >>>>     characters in a loop.
> >>>>
> >>>>     When I call
> >>>>
> >>>>                      graphics.drawString(s, xStart, ascent);
> >>>>
> >>>>     Each supplemental character that shares the same first char (high
> >>>>     surrogate) gets the same image (see attachments).
> >>>>
> >>>>     It appears that it is caching by char instead of by code point.
> >>>>
> >>>>
> >>>>     To work around the problem, I tried changing the code to draw
> glyph
> >>>>     vectors instead.
> >>>>
> >>>>                      FontRenderContext frc =
> >>>>     graphics.getFontRenderContext();
> >>>>
> >>>>                      GlyphVector gv = myFont.createGlyphVector(frc,
> s);
> >>>>
> >>>>                      ...
> >>>>
> >>>>                      Shape shape = gv.getOutline(xStart, ascent);
> >>>>
> >>>>                      graphics.draw(shape);
> >>>>
> >>>>     To my surprise, it got even worse: I get an unknown glyph after
> >>>>     each
> >>>>     image. See attachments.
> >>>>
> >>>>     It appears that when it is advancing through the string to get the
> >>>>     glyphs, it is picking up the glyph ID for the code point, but
> >>>>     then it is
> >>>>     only advancing by 1, so it is always picking up garbage after each
> >>>>     character.
> >>>>
> >>>
> >>>     Yeah, your explanation does sound like what's happening in the
> >>>     font rendering on MacOSX. Phil/Mike, do you have any idea what's
> >>>     going on?
> >>>
> >>>     Naoto
> >>>
> >>
> >>
> >>
> >
>

From mark at macchiato.com  Thu Apr 10 15:31:38 2014
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Thu, 10 Apr 2014 17:31:38 +0200
Subject: <i18n dev> Problems drawing supplemental characters in Java.
In-Reply-To: <CAJ2xs_E_Vsk46ET1iD8BmBdF6up-W+=3969zvni+q3ruzxRT3w@mail.gmail.com>
References: <CAJ2xs_FN9zesgn=0ZuA+fhsgfCMO1bd4=pFd2BFa0x8uJfYGsw@mail.gmail.com>
	<53457282.2030106@oracle.com> <534575FF.2070709@oracle.com>
	<CAJ2xs_H3mZauBgfna9uOGV0oBXrR5dVb2OHwUMY_rnvKs0yB4w@mail.gmail.com>
	<534586CF.2050101@oracle.com>
	<CAJ2xs_E7CO78_4_bJr0Kk8rMqJhxLFRBmYn_932AOk8Sov_eiA@mail.gmail.com>
	<CAJ2xs_E_Vsk46ET1iD8BmBdF6up-W+=3969zvni+q3ruzxRT3w@mail.gmail.com>
Message-ID: <CAJ2xs_EtDgWMyRW-aRFxvdw73-9P_RLqcGHrhXuNwdFapCmAmg@mail.gmail.com>

FYI, here is how Firefox solved the problem:
https://bugzilla.mozilla.org/show_bug.cgi?id=715798#c44


Mark <https://google.com/+MarkDavis>

 *? Il meglio ? l?inimico del bene ?*


On 10 April 2014 14:45, Mark Davis ?? <mark at macchiato.com> wrote:

> One further question.
>
> On the Mac, some characters are given a default emoji presentation, and
> appear with a colored image. This is done by substituting the glyph from
> the Apple Color Emoji.
>
> With drawString(), when I try to draw a character in (say) Symbola that by
> default on the Mac is emoji, the font says .canDisplay(...) is true, but I
> get no image, just blank. It's like drawing a space.
>
> If I try to draw *any* character in Apple Color Emoji, I get a blank as
> well.
>
> Is there any way to work around this, and use the Apple Color Emoji?
>
> Note: I tried using a JTextArea to work around this. When I changed the
> existing TextAreaDemo.java to add the following 2 lines, it crashed!
>
>         textArea.setFont(*new* Font("Apple Color Emoji", 0, 18));
>
>         textArea.setText("abc??def");
>
>
> Same happens if the setText line is omitted, and if you simply paste in an
> emoji character into the running program.
>
>
> Mark <https://google.com/+MarkDavis>
>
>  *? Il meglio ? l?inimico del bene ?*
>
>
> On 9 April 2014 21:28, Mark Davis ?? <mark at macchiato.com> wrote:
>
>> Fixes it, thanks!!
>>
>>
>> Mark <https://google.com/+MarkDavis>
>>
>>  *? Il meglio ? l?inimico del bene ?*
>>
>>
>> On 9 April 2014 19:43, Phil Race <philip.race at oracle.com> wrote:
>>
>> > So can you please update to 7u51 (current security baseline) and see if
>> > that cures it ?
>> >
>> http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html
>> >
>> > -phil.
>> >
>> > On 4/9/2014 10:29 AM, Mark Davis ?? wrote:
>> >
>> >> jdk1.7.0_25.jdk
>> >>
>> >>
>> >> Mark <https://google.com/+MarkDavis>
>> >> /
>> >> /
>> >> /? Il meglio ? l?inimico del bene ?/
>> >> //
>> >>
>> >>
>> >>
>> >> On 9 April 2014 18:31, Phil Race <philip.race at oracle.com <mailto:
>> >> philip.race at oracle.com>> wrote:
>> >>
>> >>     Sounds like https://bugs.openjdk.java.net/browse/JDK-8015556
>> >>     [macosx] surrogate pairs do not render properly (show up as boxes
>> >>     or incorrect glyphs)
>> >>
>> >>     But that was fixed in 7u40. What JDK 7 update is in use here ?
>> >>
>> >>     -phil.
>> >>
>> >>
>> >>     On 4/9/14 9:17 AM, Naoto Sato wrote:
>> >>
>> >>>     Hi Mark,
>> >>>
>> >>>     On 4/9/14, 3:11 AM, Mark Davis ?? wrote:
>> >>>
>> >>>>     I'm having some trouble with drawing supplemental characters in
>> >>>>     Java. It
>> >>>>     appears to be due to bugs in Java.
>> >>>>
>> >>>>     *First, how do I report this? And second, can anyone think of a
>> >>>>     work-around?*
>> >>>>
>> >>>
>> >>>     Here is the link to report an issue against JDK:
>> >>>
>> >>>     http://bugreport.java.com/bugreport/
>> >>>
>> >>>     Please choose "classes_2d" as the subcategory.
>> >>>
>> >>>
>> >>>>     This is on a Mac OS 10.9.2, JDK 7, and I am rendering a number of
>> >>>>     characters in a loop.
>> >>>>
>> >>>>     When I call
>> >>>>
>> >>>>                      graphics.drawString(s, xStart, ascent);
>> >>>>
>> >>>>     Each supplemental character that shares the same first char (high
>> >>>>     surrogate) gets the same image (see attachments).
>> >>>>
>> >>>>     It appears that it is caching by char instead of by code point.
>> >>>>
>> >>>>
>> >>>>     To work around the problem, I tried changing the code to draw
>> glyph
>> >>>>     vectors instead.
>> >>>>
>> >>>>                      FontRenderContext frc =
>> >>>>     graphics.getFontRenderContext();
>> >>>>
>> >>>>                      GlyphVector gv = myFont.createGlyphVector(frc,
>> s);
>> >>>>
>> >>>>                      ...
>> >>>>
>> >>>>                      Shape shape = gv.getOutline(xStart, ascent);
>> >>>>
>> >>>>                      graphics.draw(shape);
>> >>>>
>> >>>>     To my surprise, it got even worse: I get an unknown glyph after
>> >>>>     each
>> >>>>     image. See attachments.
>> >>>>
>> >>>>     It appears that when it is advancing through the string to get
>> the
>> >>>>     glyphs, it is picking up the glyph ID for the code point, but
>> >>>>     then it is
>> >>>>     only advancing by 1, so it is always picking up garbage after
>> each
>> >>>>     character.
>> >>>>
>> >>>
>> >>>     Yeah, your explanation does sound like what's happening in the
>> >>>     font rendering on MacOSX. Phil/Mike, do you have any idea what's
>> >>>     going on?
>> >>>
>> >>>     Naoto
>> >>>
>> >>
>> >>
>> >>
>> >
>>
>
>

From volker.simonis at gmail.com  Fri Apr 11 13:46:08 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 11 Apr 2014 15:46:08 +0200
Subject: <i18n dev> Improve timezone mapping for AIX platform
In-Reply-To: <CAC-GWLfS2pPJ5R2eKTO31-Op5C3q7oR6rx_M4XHGqJ+RuaTZOA@mail.gmail.com>
References: <CAC-GWLc1KLNSqzr4h5uYwC6R+JxmgRkCmKv7LUVmw_LzhPEbHw@mail.gmail.com>
	<53329D98.6040002@oracle.com>
	<CA+3eh100td-WaqbMq9JbaVTGvRV=Csr8qdHzBsde5sqJ5PvLDA@mail.gmail.com>
	<CAC-GWLcoK6oSAcFhXkLUDYxGW64snDzwNm9Rrk2PdSWbGOAbzg@mail.gmail.com>
	<CA+3eh124zbpaCO_H49QFTJsx7R8LsxWgMiv0h2WTpz3vfuRNUg@mail.gmail.com>
	<CAC-GWLfVdcJc3Vi+A6x+4P6TaoT-o5g79e9QiHuqk6M7AMg73g@mail.gmail.com>
	<CAC-GWLeJEh3cyFPNTijdiAUnxS7iAUT=GYNeBo2xej_kCYT9Kw@mail.gmail.com>
	<CA+3eh11per7n0dF7JNT2MSWws9uuzxGJOkpxyetuS69VhYHuzA@mail.gmail.com>
	<CAC-GWLfS2pPJ5R2eKTO31-Op5C3q7oR6rx_M4XHGqJ+RuaTZOA@mail.gmail.com>
Message-ID: <CA+3eh10CCmQ+RfYWuA2SS8X83+gm95iZtsqKS-aim+_c9chK4Q@mail.gmail.com>

Hi Jonathan,

thank you for fixing all the remaining issues. From my point of view this
change looks good now.

@Masayoshi: can I please get a final approval from you for pushing the
change? I also want to downport this to 8u-dev but I don't think that's a
big deal as this only touches AX code.

Thank you and best regards,
Volker

On Thu, Apr 10, 2014 at 11:44 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com>wrote:

> Hi Volker,
>
> Thanks a lot for your comments, I've made another patch,
>
> http://cr.openjdk.java.net/~luchsh/JDK-8Masayoshi034220.v4/<http://cr.openjdk.java.net/~luchsh/JDK-8034220.v4/>
>
>
> On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis <volker.simonis at gmail.com>wrote:
>
>> Hi Jonathan,
>>
>> sorry, but I found a few more issues:
>>
>> - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise
>> somebody could easily crash the VM by specifying a TZ with more than
>> 100 characters.
>>
>
> Right, I've fix it by using strncpy, and also updated another usage of
> strcmp().
>
>
>
>>
>> - you can delete the lines 871-872 because the variables are actually
>> not used and you can also remove the handling for "timezone == 0"
>> because that is actually done in getGMTOffsetID() anyway.
>>
>
> Nice catch, have deleted those in latest patch.
>
>
>>
>> - could you please avoid the usage of strtok. It is not intended for
>> usage in a multithreaded environment (see for example "man strtok" on
>> AIX). strtok_r is probably overkill, but you could use for example
>> strchr.
>>
>
> I've changed it to strtok_r in this patch,
>  although strtok was only used once here, it may still impact other
> threads.
>
>
>> did you check the build on Windows?
>>
>
> Yes, both patches got built on Windows.
>
>
>>
>> Thank you and best regards,
>> Volker
>>
>>
>> On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com>
>> wrote:
>> > Hi Volker, Masayoshi,
>> >
>> > I made another  patch which fixed the problems mentioned in last mail,
>> >
>> > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/
>> >
>> > Could you pls help to take a look?
>> >
>> > Many thanks
>> > Jonathan
>> >
>> >
>> >
>> > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com
>> >
>> > wrote:
>> >>
>> >> Hi Volker,
>> >>
>> >>
>> >> On 2014?04?02? 23:07, Volker Simonis wrote:
>> >>
>> >> Hi Jonathan,
>> >>
>> >> thanks for updating the change. Please find my comments inline:
>> >>
>> >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu <luchsh at linux.vnet.ibm.com
>> >
>> >> wrote:
>> >>
>> >> Hi Volker, Masayoshi,
>> >>
>> >> Thanks a lot for your review, here's the updated patch, could you pls
>> take
>> >> a
>> >> look?
>> >>
>> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/
>> >>
>> >>
>> >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis <
>> volker.simonis at gmail.com>
>> >> 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
>> >>
>> >> Updated in new patch.
>> >>
>> >> 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
>> >>
>> >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is
>> >> 'solaris'
>> >> as I observed on my AIX box,
>> >> solaris/lib is not the directory where tzmappings was stored for AIX.
>> >> So I'm keeping this change, please fix me if I was wrong about the
>> config.
>> >>
>> >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the
>> >> construction of  TZMAPPINGS_SRC as shown in the code snippet above.
>> >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX
>> >> and that should be just enough here.
>> >>
>> >>
>> >> That's right, let 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.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
>> >>
>> >> Many thanks
>> >> Jonathan
>> >>
>> >> Regards
>> >> Jonathan
>> >
>> >
>>
>
> Regards
> Jonathan
>

From Alan.Bateman at oracle.com  Sat Apr 12 09:53:07 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 12 Apr 2014 10:53:07 +0100
Subject: <i18n dev> RFR: JDK-8039751: UTF-8 decoder fails to handle some
 edge cases correctly
In-Reply-To: <5345C0F9.8020601@oracle.com>
References: <5345C0F9.8020601@oracle.com>
Message-ID: <53490D03.7000802@oracle.com>

On 09/04/2014 22:51, Xueming Shen wrote:
> Hi,
>
> Please help review the fix for JDK-8039751.
>
> Issue:     https://bugs.openjdk.java.net/browse/JDK-8039751
> webrev:  http://cr.openjdk.java.net/~sherman/8039751/webrev/
>
>
> This is the corner case (in 4 bytes sequence) we missed when fixing 
> 7096080 [1].
> The UTF_8 decoder correctly returns the malformed length for some 
> malformed
> 4-byte illegal byte sequence (via Decoder.malformedN(...)), but it 
> fails to do so if
> there is no enough (< 4 bytes) bytes in input buffer (via 
> isMalfromed4_2(...))
This looks okay to me although I think it would be useful to put in an 
addition comment or two to make these corner cases a bit easier to 
understand when looking at this code.

-Alan.

From masayoshi.okutsu at oracle.com  Mon Apr 14 06:03:17 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 14 Apr 2014 15:03:17 +0900
Subject: <i18n dev> Improve timezone mapping for AIX platform
In-Reply-To: <CA+3eh10CCmQ+RfYWuA2SS8X83+gm95iZtsqKS-aim+_c9chK4Q@mail.gmail.com>
References: <CAC-GWLc1KLNSqzr4h5uYwC6R+JxmgRkCmKv7LUVmw_LzhPEbHw@mail.gmail.com>	<53329D98.6040002@oracle.com>	<CA+3eh100td-WaqbMq9JbaVTGvRV=Csr8qdHzBsde5sqJ5PvLDA@mail.gmail.com>	<CAC-GWLcoK6oSAcFhXkLUDYxGW64snDzwNm9Rrk2PdSWbGOAbzg@mail.gmail.com>	<CA+3eh124zbpaCO_H49QFTJsx7R8LsxWgMiv0h2WTpz3vfuRNUg@mail.gmail.com>	<CAC-GWLfVdcJc3Vi+A6x+4P6TaoT-o5g79e9QiHuqk6M7AMg73g@mail.gmail.com>	<CAC-GWLeJEh3cyFPNTijdiAUnxS7iAUT=GYNeBo2xej_kCYT9Kw@mail.gmail.com>	<CA+3eh11per7n0dF7JNT2MSWws9uuzxGJOkpxyetuS69VhYHuzA@mail.gmail.com>	<CAC-GWLfS2pPJ5R2eKTO31-Op5C3q7oR6rx_M4XHGqJ+RuaTZOA@mail.gmail.com>
	<CA+3eh10CCmQ+RfYWuA2SS8X83+gm95iZtsqKS-aim+_c9chK4Q@mail.gmail.com>
Message-ID: <534B7A25.7070800@oracle.com>

Looks good to me.

Thanks,
Masayoshi

On 4/11/2014 10:46 PM, Volker Simonis wrote:
> Hi Jonathan,
>
> thank you for fixing all the remaining issues. From my point of view 
> this change looks good now.
>
> @Masayoshi: can I please get a final approval from you for pushing the 
> change? I also want to downport this to 8u-dev but I don't think 
> that's a big deal as this only touches AX code.
>
> Thank you and best regards,
> Volker
>
> On Thu, Apr 10, 2014 at 11:44 AM, Jonathan Lu 
> <luchsh at linux.vnet.ibm.com <mailto:luchsh at linux.vnet.ibm.com>> wrote:
>
>     Hi Volker,
>
>     Thanks a lot for your comments, I've made another patch,
>
>     http://cr.openjdk.java.net/~luchsh/JDK-8Masayoshi034220.v4/
>     <http://cr.openjdk.java.net/%7Eluchsh/JDK-8034220.v4/>
>
>
>     On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis
>     <volker.simonis at gmail.com <mailto:volker.simonis at gmail.com>> wrote:
>
>         Hi Jonathan,
>
>         sorry, but I found a few more issues:
>
>         - please use strncpy instead of strcpy in TimeZone_md.c:798
>         otherwise
>         somebody could easily crash the VM by specifying a TZ with
>         more than
>         100 characters.
>
>
>     Right, I've fix it by using strncpy, and also updated another
>     usage of strcmp().
>
>
>         - you can delete the lines 871-872 because the variables are
>         actually
>         not used and you can also remove the handling for "timezone == 0"
>         because that is actually done in getGMTOffsetID() anyway.
>
>
>     Nice catch, have deleted those in latest patch.
>
>
>         - could you please avoid the usage of strtok. It is not
>         intended for
>         usage in a multithreaded environment (see for example "man
>         strtok" on
>         AIX). strtok_r is probably overkill, but you could use for example
>         strchr.
>
>
>     I've changed it to strtok_r in this patch,
>      although strtok was only used once here, it may still impact
>     other threads.
>
>
>         did you check the build on Windows?
>
>
>     Yes, both patches got built on Windows.
>
>
>         Thank you and best regards,
>         Volker
>
>
>         On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu
>         <luchsh at linux.vnet.ibm.com <mailto:luchsh at linux.vnet.ibm.com>>
>         wrote:
>         > Hi Volker, Masayoshi,
>         >
>         > I made another  patch which fixed the problems mentioned in
>         last mail,
>         >
>         > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/
>         <http://cr.openjdk.java.net/%7Eluchsh/JDK-8034220.v3/>
>         >
>         > Could you pls help to take a look?
>         >
>         > Many thanks
>         > Jonathan
>         >
>         >
>         >
>         > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu
>         <luchsh at linux.vnet.ibm.com <mailto:luchsh at linux.vnet.ibm.com>>
>         > wrote:
>         >>
>         >> Hi Volker,
>         >>
>         >>
>         >> On 2014?04?02? 23:07, Volker Simonis wrote:
>         >>
>         >> Hi Jonathan,
>         >>
>         >> thanks for updating the change. Please find my comments inline:
>         >>
>         >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu
>         <luchsh at linux.vnet.ibm.com <mailto:luchsh at linux.vnet.ibm.com>>
>         >> wrote:
>         >>
>         >> Hi Volker, Masayoshi,
>         >>
>         >> Thanks a lot for your review, here's the updated patch,
>         could you pls take
>         >> a
>         >> look?
>         >>
>         >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/
>         <http://cr.openjdk.java.net/%7Eluchsh/JDK-8034220.v2/>
>         >>
>         >>
>         >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis
>         <volker.simonis at gmail.com <mailto:volker.simonis at gmail.com>>
>         >> 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
>         >>
>         >> Updated in new patch.
>         >>
>         >> 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
>         >>
>         >> I've tried that approach before, but
>         OPENJDK_TARGET_OS_API_DIR is
>         >> 'solaris'
>         >> as I observed on my AIX box,
>         >> solaris/lib is not the directory where tzmappings was
>         stored for AIX.
>         >> So I'm keeping this change, please fix me if I was wrong
>         about the config.
>         >>
>         >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the
>         >> construction of  TZMAPPINGS_SRC as shown in the code
>         snippet above.
>         >> OPENJDK_TARGET_OS is "windows" on Windows platforms and
>         "aix" on AIX
>         >> and that should be just enough here.
>         >>
>         >>
>         >> That's right, let 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.okutsu at oracle.com
>         <mailto: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/
>         <http://cr.openjdk.java.net/%7Eluchsh/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
>         >>
>         >> Many thanks
>         >> Jonathan
>         >>
>         >> Regards
>         >> Jonathan
>         >
>         >
>
>
>     Regards
>     Jonathan
>
>


From luchsh at linux.vnet.ibm.com  Tue Apr 15 07:48:35 2014
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Tue, 15 Apr 2014 15:48:35 +0800
Subject: <i18n dev> Improve timezone mapping for AIX platform
In-Reply-To: <534B7A25.7070800@oracle.com>
References: <CAC-GWLc1KLNSqzr4h5uYwC6R+JxmgRkCmKv7LUVmw_LzhPEbHw@mail.gmail.com>
	<53329D98.6040002@oracle.com>
	<CA+3eh100td-WaqbMq9JbaVTGvRV=Csr8qdHzBsde5sqJ5PvLDA@mail.gmail.com>
	<CAC-GWLcoK6oSAcFhXkLUDYxGW64snDzwNm9Rrk2PdSWbGOAbzg@mail.gmail.com>
	<CA+3eh124zbpaCO_H49QFTJsx7R8LsxWgMiv0h2WTpz3vfuRNUg@mail.gmail.com>
	<CAC-GWLfVdcJc3Vi+A6x+4P6TaoT-o5g79e9QiHuqk6M7AMg73g@mail.gmail.com>
	<CAC-GWLeJEh3cyFPNTijdiAUnxS7iAUT=GYNeBo2xej_kCYT9Kw@mail.gmail.com>
	<CA+3eh11per7n0dF7JNT2MSWws9uuzxGJOkpxyetuS69VhYHuzA@mail.gmail.com>
	<CAC-GWLfS2pPJ5R2eKTO31-Op5C3q7oR6rx_M4XHGqJ+RuaTZOA@mail.gmail.com>
	<CA+3eh10CCmQ+RfYWuA2SS8X83+gm95iZtsqKS-aim+_c9chK4Q@mail.gmail.com>
	<534B7A25.7070800@oracle.com>
Message-ID: <CAC-GWLei+pc9dkayr818jDZF-Tu8O7Rj5mhGd-j850zwDFsspQ@mail.gmail.com>

Hi Masayoshi, Volker,

Thanks a lot for reviewing !
Is it OK for me to push the change into JDK9 directly ? or need another
reviewer's approval ?

Many thanks
Jonathan



On Mon, Apr 14, 2014 at 2:03 PM, Masayoshi Okutsu <
masayoshi.okutsu at oracle.com> wrote:

>  Looks good to me.
>
> Thanks,
> Masayoshi
>
>
> On 4/11/2014 10:46 PM, Volker Simonis wrote:
>
>   Hi Jonathan,
>
>  thank you for fixing all the remaining issues. From my point of view this
> change looks good now.
>
> @Masayoshi: can I please get a final approval from you for pushing the
> change? I also want to downport this to 8u-dev but I don't think that's a
> big deal as this only touches AX code.
>
>  Thank you and best regards,
>  Volker
>
> On Thu, Apr 10, 2014 at 11:44 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com>wrote:
>
>>  Hi Volker,
>>
>>  Thanks a lot for your comments, I've made another patch,
>>
>> http://cr.openjdk.java.net/~luchsh/JDK-8Masayoshi034220.v4/<http://cr.openjdk.java.net/%7Eluchsh/JDK-8034220.v4/>
>>
>>
>> On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis <volker.simonis at gmail.com>wrote:
>>
>>> Hi Jonathan,
>>>
>>> sorry, but I found a few more issues:
>>>
>>> - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise
>>> somebody could easily crash the VM by specifying a TZ with more than
>>> 100 characters.
>>>
>>
>>  Right, I've fix it by using strncpy, and also updated another usage of
>> strcmp().
>>
>>
>>
>>>
>>> - you can delete the lines 871-872 because the variables are actually
>>> not used and you can also remove the handling for "timezone == 0"
>>> because that is actually done in getGMTOffsetID() anyway.
>>>
>>
>>  Nice catch, have deleted those in latest patch.
>>
>>
>>>
>>> - could you please avoid the usage of strtok. It is not intended for
>>> usage in a multithreaded environment (see for example "man strtok" on
>>> AIX). strtok_r is probably overkill, but you could use for example
>>> strchr.
>>>
>>
>>  I've changed it to strtok_r in this patch,
>>  although strtok was only used once here, it may still impact other
>> threads.
>>
>>
>>> did you check the build on Windows?
>>>
>>
>>  Yes, both patches got built on Windows.
>>
>>
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>>
>>> On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com>
>>> wrote:
>>> > Hi Volker, Masayoshi,
>>> >
>>> > I made another  patch which fixed the problems mentioned in last mail,
>>> >
>>> > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/
>>> >
>>> > Could you pls help to take a look?
>>> >
>>> > Many thanks
>>> > Jonathan
>>> >
>>> >
>>> >
>>> > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu <
>>> luchsh at linux.vnet.ibm.com>
>>> > wrote:
>>> >>
>>> >> Hi Volker,
>>> >>
>>> >>
>>> >> On 2014?04?02? 23:07, Volker Simonis wrote:
>>> >>
>>> >> Hi Jonathan,
>>> >>
>>> >> thanks for updating the change. Please find my comments inline:
>>> >>
>>> >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu <
>>> luchsh at linux.vnet.ibm.com>
>>>  >> wrote:
>>> >>
>>> >> Hi Volker, Masayoshi,
>>> >>
>>> >> Thanks a lot for your review, here's the updated patch, could you pls
>>> take
>>> >> a
>>> >> look?
>>> >>
>>> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/
>>> >>
>>> >>
>>> >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis <
>>> volker.simonis at gmail.com>
>>>  >> 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
>>> >>
>>> >> Updated in new patch.
>>> >>
>>> >> 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
>>> >>
>>> >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is
>>> >> 'solaris'
>>> >> as I observed on my AIX box,
>>> >> solaris/lib is not the directory where tzmappings was stored for AIX.
>>> >> So I'm keeping this change, please fix me if I was wrong about the
>>> config.
>>> >>
>>> >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the
>>> >> construction of  TZMAPPINGS_SRC as shown in the code snippet above.
>>> >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX
>>> >> and that should be just enough here.
>>> >>
>>> >>
>>> >> That's right, let 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.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
>>> >>
>>> >> Many thanks
>>> >> Jonathan
>>> >>
>>> >> Regards
>>> >> Jonathan
>>> >
>>> >
>>>
>>
>>  Regards
>>  Jonathan
>>
>
>
>

From volker.simonis at gmail.com  Tue Apr 15 08:50:34 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 15 Apr 2014 10:50:34 +0200
Subject: <i18n dev> Improve timezone mapping for AIX platform
In-Reply-To: <CAC-GWLei+pc9dkayr818jDZF-Tu8O7Rj5mhGd-j850zwDFsspQ@mail.gmail.com>
References: <CAC-GWLc1KLNSqzr4h5uYwC6R+JxmgRkCmKv7LUVmw_LzhPEbHw@mail.gmail.com>
	<53329D98.6040002@oracle.com>
	<CA+3eh100td-WaqbMq9JbaVTGvRV=Csr8qdHzBsde5sqJ5PvLDA@mail.gmail.com>
	<CAC-GWLcoK6oSAcFhXkLUDYxGW64snDzwNm9Rrk2PdSWbGOAbzg@mail.gmail.com>
	<CA+3eh124zbpaCO_H49QFTJsx7R8LsxWgMiv0h2WTpz3vfuRNUg@mail.gmail.com>
	<CAC-GWLfVdcJc3Vi+A6x+4P6TaoT-o5g79e9QiHuqk6M7AMg73g@mail.gmail.com>
	<CAC-GWLeJEh3cyFPNTijdiAUnxS7iAUT=GYNeBo2xej_kCYT9Kw@mail.gmail.com>
	<CA+3eh11per7n0dF7JNT2MSWws9uuzxGJOkpxyetuS69VhYHuzA@mail.gmail.com>
	<CAC-GWLfS2pPJ5R2eKTO31-Op5C3q7oR6rx_M4XHGqJ+RuaTZOA@mail.gmail.com>
	<CA+3eh10CCmQ+RfYWuA2SS8X83+gm95iZtsqKS-aim+_c9chK4Q@mail.gmail.com>
	<534B7A25.7070800@oracle.com>
	<CAC-GWLei+pc9dkayr818jDZF-Tu8O7Rj5mhGd-j850zwDFsspQ@mail.gmail.com>
Message-ID: <CA+3eh10wQ3hZTnHRtg5Om=7O5ugsnxkO7uoreT8TdWNNR-k3Og@mail.gmail.com>

You can push it to jdk9-dev directly. No other reviewer is required.

Regards,
Volker


On Tue, Apr 15, 2014 at 9:48 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com> wrote:
> Hi Masayoshi, Volker,
>
> Thanks a lot for reviewing !
> Is it OK for me to push the change into JDK9 directly ? or need another
> reviewer's approval ?
>
> Many thanks
> Jonathan
>
>
>
> On Mon, Apr 14, 2014 at 2:03 PM, Masayoshi Okutsu
> <masayoshi.okutsu at oracle.com> wrote:
>>
>> Looks good to me.
>>
>> Thanks,
>> Masayoshi
>>
>>
>> On 4/11/2014 10:46 PM, Volker Simonis wrote:
>>
>> Hi Jonathan,
>>
>> thank you for fixing all the remaining issues. From my point of view this
>> change looks good now.
>>
>> @Masayoshi: can I please get a final approval from you for pushing the
>> change? I also want to downport this to 8u-dev but I don't think that's a
>> big deal as this only touches AX code.
>>
>> Thank you and best regards,
>> Volker
>>
>> On Thu, Apr 10, 2014 at 11:44 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com>
>> wrote:
>>>
>>> Hi Volker,
>>>
>>> Thanks a lot for your comments, I've made another patch,
>>>
>>> http://cr.openjdk.java.net/~luchsh/JDK-8Masayoshi034220.v4/
>>>
>>>
>>> On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis <volker.simonis at gmail.com>
>>> wrote:
>>>>
>>>> Hi Jonathan,
>>>>
>>>> sorry, but I found a few more issues:
>>>>
>>>> - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise
>>>> somebody could easily crash the VM by specifying a TZ with more than
>>>> 100 characters.
>>>
>>>
>>> Right, I've fix it by using strncpy, and also updated another usage of
>>> strcmp().
>>>
>>>
>>>>
>>>>
>>>> - you can delete the lines 871-872 because the variables are actually
>>>> not used and you can also remove the handling for "timezone == 0"
>>>> because that is actually done in getGMTOffsetID() anyway.
>>>
>>>
>>> Nice catch, have deleted those in latest patch.
>>>
>>>>
>>>>
>>>> - could you please avoid the usage of strtok. It is not intended for
>>>> usage in a multithreaded environment (see for example "man strtok" on
>>>> AIX). strtok_r is probably overkill, but you could use for example
>>>> strchr.
>>>
>>>
>>> I've changed it to strtok_r in this patch,
>>>  although strtok was only used once here, it may still impact other
>>> threads.
>>>
>>>>
>>>> did you check the build on Windows?
>>>
>>>
>>> Yes, both patches got built on Windows.
>>>
>>>>
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>>
>>>> On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com>
>>>> wrote:
>>>> > Hi Volker, Masayoshi,
>>>> >
>>>> > I made another  patch which fixed the problems mentioned in last mail,
>>>> >
>>>> > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/
>>>> >
>>>> > Could you pls help to take a look?
>>>> >
>>>> > Many thanks
>>>> > Jonathan
>>>> >
>>>> >
>>>> >
>>>> > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu
>>>> > <luchsh at linux.vnet.ibm.com>
>>>> > wrote:
>>>> >>
>>>> >> Hi Volker,
>>>> >>
>>>> >>
>>>> >> On 2014?04?02? 23:07, Volker Simonis wrote:
>>>> >>
>>>> >> Hi Jonathan,
>>>> >>
>>>> >> thanks for updating the change. Please find my comments inline:
>>>> >>
>>>> >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu
>>>> >> <luchsh at linux.vnet.ibm.com>
>>>> >> wrote:
>>>> >>
>>>> >> Hi Volker, Masayoshi,
>>>> >>
>>>> >> Thanks a lot for your review, here's the updated patch, could you pls
>>>> >> take
>>>> >> a
>>>> >> look?
>>>> >>
>>>> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/
>>>> >>
>>>> >>
>>>> >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis
>>>> >> <volker.simonis at gmail.com>
>>>> >> 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
>>>> >>
>>>> >> Updated in new patch.
>>>> >>
>>>> >> 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
>>>> >>
>>>> >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is
>>>> >> 'solaris'
>>>> >> as I observed on my AIX box,
>>>> >> solaris/lib is not the directory where tzmappings was stored for AIX.
>>>> >> So I'm keeping this change, please fix me if I was wrong about the
>>>> >> config.
>>>> >>
>>>> >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the
>>>> >> construction of  TZMAPPINGS_SRC as shown in the code snippet above.
>>>> >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX
>>>> >> and that should be just enough here.
>>>> >>
>>>> >>
>>>> >> That's right, let 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.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
>>>> >>
>>>> >> Many thanks
>>>> >> Jonathan
>>>> >>
>>>> >> Regards
>>>> >> Jonathan
>>>> >
>>>> >
>>>
>>>
>>> Regards
>>> Jonathan
>>
>>
>>
>

From yuka.kamiya at oracle.com  Thu Apr 17 03:44:56 2014
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Thu, 17 Apr 2014 12:44:56 +0900
Subject: <i18n dev> [9] RFR: 8035726: A sentence is truncated in the API doc
 for j.u.Locale.LanguageRange.parse(String, Map).
Message-ID: <534F4E38.8090501@oracle.com>

Hello,

Please review a simple doc fix to add a missing line.

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

Thanks,
--
Yuka


From masayoshi.okutsu at oracle.com  Thu Apr 17 03:55:40 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 17 Apr 2014 12:55:40 +0900
Subject: <i18n dev> [9] RFR: 8035726: A sentence is truncated in the API
 doc for j.u.Locale.LanguageRange.parse(String, Map).
In-Reply-To: <534F4E38.8090501@oracle.com>
References: <534F4E38.8090501@oracle.com>
Message-ID: <534F50BC.6070300@oracle.com>

Looks good.

Masayoshi

On 4/17/2014 12:44 PM, Yuka Kamiya wrote:
> Hello,
>
> Please review a simple doc fix to add a missing line.
>
> http://cr.openjdk.java.net/~peytoia/8035726/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8035726
>
> Thanks,
> --
> Yuka
>


From masayoshi.okutsu at oracle.com  Thu Apr 24 15:52:16 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 25 Apr 2014 00:52:16 +0900
Subject: <i18n dev> Request for Draft JEP
Message-ID: <53593330.6020809@oracle.com>

Hello,

I plan to submit the following JEP for JDK9. I'd appreciate your feedback.

UCA-based Collator Enhancements:
http://cr.openjdk.java.net/~okutsu/JEPs/uca_collator.md
https://bugs.openjdk.java.net/browse/JDK-6414006

Thanks,
Masayoshi


From mark at macchiato.com  Mon Apr 28 13:51:56 2014
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Mon, 28 Apr 2014 15:51:56 +0200
Subject: <i18n dev> Problems drawing supplemental characters in Java.
In-Reply-To: <CAJ2xs_E_Vsk46ET1iD8BmBdF6up-W+=3969zvni+q3ruzxRT3w@mail.gmail.com>
References: <CAJ2xs_FN9zesgn=0ZuA+fhsgfCMO1bd4=pFd2BFa0x8uJfYGsw@mail.gmail.com>
	<53457282.2030106@oracle.com> <534575FF.2070709@oracle.com>
	<CAJ2xs_H3mZauBgfna9uOGV0oBXrR5dVb2OHwUMY_rnvKs0yB4w@mail.gmail.com>
	<534586CF.2050101@oracle.com>
	<CAJ2xs_E7CO78_4_bJr0Kk8rMqJhxLFRBmYn_932AOk8Sov_eiA@mail.gmail.com>
	<CAJ2xs_E_Vsk46ET1iD8BmBdF6up-W+=3969zvni+q3ruzxRT3w@mail.gmail.com>
Message-ID: <CAJ2xs_EzvhEkhWDtwbRpyhvTee3yX_geWkExYiY1gEEhYQPtjg@mail.gmail.com>

Ping... Any workaround for Java not being able to draw these characters?


Mark <https://google.com/+MarkDavis>

*? Il meglio ? l?inimico del bene ?*


On 10 April 2014 14:45, Mark Davis ?? <mark at macchiato.com> wrote:

> One further question.
>
> On the Mac, some characters are given a default emoji presentation, and
> appear with a colored image. This is done by substituting the glyph from
> the Apple Color Emoji.
>
> With drawString(), when I try to draw a character in (say) Symbola that by
> default on the Mac is emoji, the font says .canDisplay(...) is true, but I
> get no image, just blank. It's like drawing a space.
>
> If I try to draw *any* character in Apple Color Emoji, I get a blank as
> well.
>
> Is there any way to work around this, and use the Apple Color Emoji?
>
> Note: I tried using a JTextArea to work around this. When I changed the
> existing TextAreaDemo.java to add the following 2 lines, it crashed!
>
>         textArea.setFont(*new* Font("Apple Color Emoji", 0, 18));
>
>         textArea.setText("abc??def");
>
>
> Same happens if the setText line is omitted, and if you simply paste in an
> emoji character into the running program.
>
>
> Mark <https://google.com/+MarkDavis>
>
>  *? Il meglio ? l?inimico del bene ?*
>
>
> On 9 April 2014 21:28, Mark Davis ?? <mark at macchiato.com> wrote:
>
>> Fixes it, thanks!!
>>
>>
>> Mark <https://google.com/+MarkDavis>
>>
>>  *? Il meglio ? l?inimico del bene ?*
>>
>>
>> On 9 April 2014 19:43, Phil Race <philip.race at oracle.com> wrote:
>>
>> > So can you please update to 7u51 (current security baseline) and see if
>> > that cures it ?
>> >
>> http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html
>> >
>> > -phil.
>> >
>> > On 4/9/2014 10:29 AM, Mark Davis ?? wrote:
>> >
>> >> jdk1.7.0_25.jdk
>> >>
>> >>
>> >> Mark <https://google.com/+MarkDavis>
>> >> /
>> >> /
>> >> /? Il meglio ? l?inimico del bene ?/
>> >> //
>> >>
>> >>
>> >>
>> >> On 9 April 2014 18:31, Phil Race <philip.race at oracle.com <mailto:
>> >> philip.race at oracle.com>> wrote:
>> >>
>> >>     Sounds like https://bugs.openjdk.java.net/browse/JDK-8015556
>> >>     [macosx] surrogate pairs do not render properly (show up as boxes
>> >>     or incorrect glyphs)
>> >>
>> >>     But that was fixed in 7u40. What JDK 7 update is in use here ?
>> >>
>> >>     -phil.
>> >>
>> >>
>> >>     On 4/9/14 9:17 AM, Naoto Sato wrote:
>> >>
>> >>>     Hi Mark,
>> >>>
>> >>>     On 4/9/14, 3:11 AM, Mark Davis ?? wrote:
>> >>>
>> >>>>     I'm having some trouble with drawing supplemental characters in
>> >>>>     Java. It
>> >>>>     appears to be due to bugs in Java.
>> >>>>
>> >>>>     *First, how do I report this? And second, can anyone think of a
>> >>>>     work-around?*
>> >>>>
>> >>>
>> >>>     Here is the link to report an issue against JDK:
>> >>>
>> >>>     http://bugreport.java.com/bugreport/
>> >>>
>> >>>     Please choose "classes_2d" as the subcategory.
>> >>>
>> >>>
>> >>>>     This is on a Mac OS 10.9.2, JDK 7, and I am rendering a number of
>> >>>>     characters in a loop.
>> >>>>
>> >>>>     When I call
>> >>>>
>> >>>>                      graphics.drawString(s, xStart, ascent);
>> >>>>
>> >>>>     Each supplemental character that shares the same first char (high
>> >>>>     surrogate) gets the same image (see attachments).
>> >>>>
>> >>>>     It appears that it is caching by char instead of by code point.
>> >>>>
>> >>>>
>> >>>>     To work around the problem, I tried changing the code to draw
>> glyph
>> >>>>     vectors instead.
>> >>>>
>> >>>>                      FontRenderContext frc =
>> >>>>     graphics.getFontRenderContext();
>> >>>>
>> >>>>                      GlyphVector gv = myFont.createGlyphVector(frc,
>> s);
>> >>>>
>> >>>>                      ...
>> >>>>
>> >>>>                      Shape shape = gv.getOutline(xStart, ascent);
>> >>>>
>> >>>>                      graphics.draw(shape);
>> >>>>
>> >>>>     To my surprise, it got even worse: I get an unknown glyph after
>> >>>>     each
>> >>>>     image. See attachments.
>> >>>>
>> >>>>     It appears that when it is advancing through the string to get
>> the
>> >>>>     glyphs, it is picking up the glyph ID for the code point, but
>> >>>>     then it is
>> >>>>     only advancing by 1, so it is always picking up garbage after
>> each
>> >>>>     character.
>> >>>>
>> >>>
>> >>>     Yeah, your explanation does sound like what's happening in the
>> >>>     font rendering on MacOSX. Phil/Mike, do you have any idea what's
>> >>>     going on?
>> >>>
>> >>>     Naoto
>> >>>
>> >>
>> >>
>> >>
>> >
>>
>
>

From philip.race at oracle.com  Mon Apr 28 20:29:25 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 28 Apr 2014 13:29:25 -0700
Subject: <i18n dev> Problems drawing supplemental characters in Java.
In-Reply-To: <CAJ2xs_EzvhEkhWDtwbRpyhvTee3yX_geWkExYiY1gEEhYQPtjg@mail.gmail.com>
References: <CAJ2xs_FN9zesgn=0ZuA+fhsgfCMO1bd4=pFd2BFa0x8uJfYGsw@mail.gmail.com>
	<53457282.2030106@oracle.com> <534575FF.2070709@oracle.com>
	<CAJ2xs_H3mZauBgfna9uOGV0oBXrR5dVb2OHwUMY_rnvKs0yB4w@mail.gmail.com>
	<534586CF.2050101@oracle.com>
	<CAJ2xs_E7CO78_4_bJr0Kk8rMqJhxLFRBmYn_932AOk8Sov_eiA@mail.gmail.com>
	<CAJ2xs_E_Vsk46ET1iD8BmBdF6up-W+=3969zvni+q3ruzxRT3w@mail.gmail.com>
	<CAJ2xs_EzvhEkhWDtwbRpyhvTee3yX_geWkExYiY1gEEhYQPtjg@mail.gmail.com>
Message-ID: <535EBA25.4060703@oracle.com>

Sorry .. I have been out on vacation .. and before that over-looked this 
email anyway.

I do not have a workaround here.

I had supposed the emoji fonts provide the colour image as an 
alternative that some
APIs understand and that any code asking directly for a normal glyph 
image would get it
but I'd have to investigate what is happening in JDK code and how this 
can be resolved.
Perhaps the emoji can be co-erced into being an ImageGraphicAttribute and we
can use TextLayout to handle it but I suspect there'll be snags ..

Obviously the crash needs to be looked at .. surprised no one has 
reported that before.

-Phil.

On 4/28/2014 6:51 AM, Mark Davis ?? wrote:
> Ping... Any workaround for Java not being able to draw these characters?
>
>
> Mark <https://google.com/+MarkDavis>
> /
> /
> /? Il meglio ? l?inimico del bene ?/
> //
>
>
> On 10 April 2014 14:45, Mark Davis ?? <mark at macchiato.com 
> <mailto:mark at macchiato.com>> wrote:
>
>     One further question.
>
>     On the Mac, some characters are given a default emoji
>     presentation, and appear with a colored image. This is done by
>     substituting the glyph from the Apple Color Emoji.
>
>     With drawString(), when I try to draw a character in (say) Symbola
>     that by default on the Mac is emoji, the font says
>     .canDisplay(...) is true, but I get no image, just blank. It's
>     like drawing a space.
>
>     If I try to draw /any/ character in Apple Color Emoji, I get a
>     blank as well.
>
>     Is there any way to work around this, and use the Apple Color Emoji?
>
>     Note: I tried using a JTextArea to work around this. When I
>     changed the existing TextAreaDemo.java to add the following 2
>     lines, it crashed!
>
>     textArea.setFont(*new* Font("Apple Color Emoji", 0, 18));
>
>     textArea.setText("abc??def");
>
>
>     Same happens if the setText line is omitted, and if you simply
>     paste in an emoji character into the running program.
>
>
>
>     Mark <https://google.com/+MarkDavis>
>     /
>     /
>     /? Il meglio ? l?inimico del bene ?/
>     //
>


From mark at macchiato.com  Tue Apr 29 07:13:40 2014
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Tue, 29 Apr 2014 09:13:40 +0200
Subject: <i18n dev> Problems drawing supplemental characters in Java.
In-Reply-To: <535EBA25.4060703@oracle.com>
References: <CAJ2xs_FN9zesgn=0ZuA+fhsgfCMO1bd4=pFd2BFa0x8uJfYGsw@mail.gmail.com>
	<53457282.2030106@oracle.com> <534575FF.2070709@oracle.com>
	<CAJ2xs_H3mZauBgfna9uOGV0oBXrR5dVb2OHwUMY_rnvKs0yB4w@mail.gmail.com>
	<534586CF.2050101@oracle.com>
	<CAJ2xs_E7CO78_4_bJr0Kk8rMqJhxLFRBmYn_932AOk8Sov_eiA@mail.gmail.com>
	<CAJ2xs_E_Vsk46ET1iD8BmBdF6up-W+=3969zvni+q3ruzxRT3w@mail.gmail.com>
	<CAJ2xs_EzvhEkhWDtwbRpyhvTee3yX_geWkExYiY1gEEhYQPtjg@mail.gmail.com>
	<535EBA25.4060703@oracle.com>
Message-ID: <CAJ2xs_Gc3tgF7Art4r70ZK1oGGq2XkCbG9+Mgq0SH00HZQC0CQ@mail.gmail.com>

On 28 April 2014 22:29, Phil Race <philip.race at oracle.com> wrote:

> I had supposed the emoji fonts provide the colour image as an alternative
> that some
> APIs understand and that any code asking directly for a normal glyph image
> would get it
> but I'd have to investigate what is happening in JDK code and how this can
> be resolved.
> Perhaps the emoji can be co-erced into being an ImageGraphicAttribute and
> we
> can use TextLayout to handle it but I suspect there'll be snags ..
>
> Obviously the crash needs to be looked at .. surprised no one has reported
> that before.
>

Thanks for looking at this. ?Also see:

FYI, here is how Firefox solved the problem:
https://bugzilla.mozilla.org/show_bug.cgi?id=715798#c44



Mark <https://google.com/+MarkDavis>

 *? Il meglio ? l?inimico del bene ?*