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: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: 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 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 > 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: 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: 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: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: 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 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 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 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: 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: 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: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: 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 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 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 > 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 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: 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: 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: 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: Problems drawing supplemental characters in Java. Message-ID: 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: Problems drawing supplemental characters in Java. In-Reply-To: References: 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: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Jonathan, thanks for updating the change. Please find my comments inline: On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu 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 > 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 >> 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: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: 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 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 > 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 >> 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 >> 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 >> 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: Problems drawing supplemental characters in Java. In-Reply-To: <53457282.2030106@oracle.com> References: <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: Problems drawing supplemental characters in Java. In-Reply-To: <534575FF.2070709@oracle.com> References: <53457282.2030106@oracle.com> <534575FF.2070709@oracle.com> Message-ID: jdk1.7.0_25.jdk Mark *? Il meglio ? l?inimico del bene ?* On 9 April 2014 18:31, Phil Race 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: Problems drawing supplemental characters in Java. In-Reply-To: References: <53457282.2030106@oracle.com> <534575FF.2070709@oracle.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 > / > / > /? Il meglio ? l?inimico del bene ?/ > // > > > On 9 April 2014 18:31, Phil Race > 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: Problems drawing supplemental characters in Java. In-Reply-To: <534586CF.2050101@oracle.com> References: <53457282.2030106@oracle.com> <534575FF.2070709@oracle.com> <534586CF.2050101@oracle.com> Message-ID: Fixes it, thanks!! Mark *? Il meglio ? l?inimico del bene ?* On 9 April 2014 19:43, Phil Race 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 >> / >> / >> /? 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 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: 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: 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: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: 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 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 > 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 > > 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 > >> 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 > >> 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: Problems drawing supplemental characters in Java. In-Reply-To: References: <53457282.2030106@oracle.com> <534575FF.2070709@oracle.com> <534586CF.2050101@oracle.com> Message-ID: 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 *? Il meglio ? l?inimico del bene ?* On 9 April 2014 21:28, Mark Davis ?? wrote: > Fixes it, thanks!! > > > Mark > > *? Il meglio ? l?inimico del bene ?* > > > On 9 April 2014 19:43, Phil Race 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 > >> / > >> / > >> /? 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 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: Problems drawing supplemental characters in Java. In-Reply-To: References: <53457282.2030106@oracle.com> <534575FF.2070709@oracle.com> <534586CF.2050101@oracle.com> Message-ID: FYI, here is how Firefox solved the problem: https://bugzilla.mozilla.org/show_bug.cgi?id=715798#c44 Mark *? Il meglio ? l?inimico del bene ?* On 10 April 2014 14:45, Mark Davis ?? 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 > > *? Il meglio ? l?inimico del bene ?* > > > On 9 April 2014 21:28, Mark Davis ?? wrote: > >> Fixes it, thanks!! >> >> >> Mark >> >> *? Il meglio ? l?inimico del bene ?* >> >> >> On 9 April 2014 19:43, Phil Race 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 >> >> / >> >> / >> >> /? 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 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: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: 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 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 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 >> 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 > > >> > 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 > > >> >> 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 >> >> 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: 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: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.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 > > 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 > > 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 > > > 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 > > > > 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 > > > >> 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 > > > >> 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 > >> > 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 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: Improve timezone mapping for AIX platform In-Reply-To: <534B7A25.7070800@oracle.com> References: <53329D98.6040002@oracle.com> <534B7A25.7070800@oracle.com> Message-ID: 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 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 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 >>> 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 >>> >> 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: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> <534B7A25.7070800@oracle.com> Message-ID: 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 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 > 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 >> 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 >>> 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 >>>> 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 >>>> > >>>> > 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 >>>> >> >>>> >> 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 >>>> >> >>>> >> 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 >>>> >> 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: [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: [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: 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: Problems drawing supplemental characters in Java. In-Reply-To: References: <53457282.2030106@oracle.com> <534575FF.2070709@oracle.com> <534586CF.2050101@oracle.com> Message-ID: Ping... Any workaround for Java not being able to draw these characters? Mark *? Il meglio ? l?inimico del bene ?* On 10 April 2014 14:45, Mark Davis ?? 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 > > *? Il meglio ? l?inimico del bene ?* > > > On 9 April 2014 21:28, Mark Davis ?? wrote: > >> Fixes it, thanks!! >> >> >> Mark >> >> *? Il meglio ? l?inimico del bene ?* >> >> >> On 9 April 2014 19:43, Phil Race 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 >> >> / >> >> / >> >> /? 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 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: Problems drawing supplemental characters in Java. In-Reply-To: References: <53457282.2030106@oracle.com> <534575FF.2070709@oracle.com> <534586CF.2050101@oracle.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 > / > / > /? Il meglio ? l?inimico del bene ?/ > // > > > On 10 April 2014 14:45, Mark Davis ?? > 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 > / > / > /? 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: Problems drawing supplemental characters in Java. In-Reply-To: <535EBA25.4060703@oracle.com> References: <53457282.2030106@oracle.com> <534575FF.2070709@oracle.com> <534586CF.2050101@oracle.com> <535EBA25.4060703@oracle.com> Message-ID: On 28 April 2014 22:29, Phil Race 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 *? Il meglio ? l?inimico del bene ?*