June 2018 - core-libs-dev

JDK-8042131: Proposal of Mapped-values formatter for non-IsoChronology
by Toshio 5 Nakamura 15 Jun '18

15 Jun '18

Hello core-libs and i18n folks, We'd like to request to reconsider JDK-8042131, "DateTimeFormatterBuilder Mapped-values do not work for JapaneseDate". The report was posted by our team long time ago, and was closed as not an issue. At that time, the feature was for only IsoChronology. Now, I found the attached patch can activate the mapped-values formatter for non-IsoChronology. Additionally, the Japanese new era will be expected in May 2019. The first year of each era has a special expression in Japanese, "U+5143 U+5e74" (Gannen). java.util.JapaneseImperialCalendar uses this expression. We'd like to use the expression with JapaneseChronology by mapped-values formatter as an option. Can we have a sponsor of this proposal? --sample usage of Japanese new era-- DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder(); Map<Long, String> yearMap = new HashMap<>(); yearMap.put(1L, "\u5143"); builder.appendText(ChronoField.ERA, TextStyle.FULL) .appendText(ChronoField.YEAR_OF_ERA, yearMap) .appendLiteral("\u5e74"); --------------- Report: https://bugs.openjdk.java.net/browse/JDK-8042131 Patch: --- old/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java 2018-06-15 17:39:11.489303979 +0900 +++ new/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java 2018-06-15 17:39:11.157303972 +0900 @@ -793,6 +793,11 @@ final LocaleStore store = new LocaleStore(map); DateTimeTextProvider provider = new DateTimeTextProvider() { @Override + public String getText(Chronology chrono, TemporalField field, + long value, TextStyle style, Locale locale) { + return store.getText(value, style); + } + @Override public String getText(TemporalField field, long value, TextStyle style, Locale locale) { return store.getText(value, style); } --- old/test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilderWithLocale.java 2018-06-15 17:39:12.664304007 +0900 +++ new/test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilderWithLocale.java 2018-06-15 17:39:12.298303999 +0900 @@ -67,14 +67,21 @@ import java.time.chrono.Chronology; import java.time.chrono.IsoChronology; import java.time.chrono.JapaneseChronology; +import java.time.chrono.JapaneseEra; import java.time.chrono.MinguoChronology; +import java.time.chrono.ThaiBuddhistChronology; +import java.time.chrono.ChronoLocalDate; import java.time.format.DateTimeFormatter; import java.time.format.DateTimeFormatterBuilder; import java.time.format.FormatStyle; import java.time.LocalDate; import java.time.temporal.Temporal; +import java.time.temporal.ChronoField; +import static java.time.temporal.ChronoUnit.YEARS; import java.util.Locale; +import java.util.Map; +import java.util.HashMap; import static org.testng.Assert.assertEquals; @@ -115,6 +122,31 @@ } //----------------------------------------------------------------------- + @DataProvider(name="mappedPatterns") + Object[][] localizedMappedPatterns() { + return new Object[][] { + {IsoChronology.INSTANCE.date(1,1,1), Locale.ENGLISH}, + {JapaneseChronology.INSTANCE.date(JapaneseEra.HEISEI, + 1,1,8), Locale.ENGLISH}, + {MinguoChronology.INSTANCE.date(1,1,1), Locale.ENGLISH}, + {ThaiBuddhistChronology.INSTANCE.date(1,1,1), Locale.ENGLISH}, + }; + } + + @Test(dataProvider="mappedPatterns") + public void test_getLocalizedMappedPattern(ChronoLocalDate date, Locale locale) { + final String new1st = "1st"; + Map<Long, String> yearMap = new HashMap<>(); + yearMap.put(1L, new1st); + DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder(); + builder.appendText(ChronoField.YEAR_OF_ERA, yearMap); + + String actual = date.format(builder.toFormatter(locale)); + assertEquals(actual, new1st); + } + + + //----------------------------------------------------------------------- @DataProvider(name="localePatterns") Object[][] localizedDateTimePatterns() { return new Object[][] { --- Best regards, Toshio Nakamura, IBM Japan

4 3

Re: RFR: 8204967: Resolve disabled warnings for libunpack
by Srinivas Dama 15 Jun '18

15 Jun '18

Hi Magnus/Jim, Thank you for the comments. Here is the latest webrev with suggested changes: webrev: http://cr.openjdk.java.net/~sdama/8204967/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8204967 Jim, gnu c supports -Wimplicit-fallthrough=3. clang takes -Wimplicit-fallthrough without any parameters and ignores it without any effect. clang++ works with -Wimplicit-fallthrough along with -std=c++11(it is cpp specific option) Note: My earlier fix http://cr.openjdk.java.net/~sdama/8204967/webrev.00/ broke linux build because some switch case statements which are having implicit-fallthroughs will be enabled only in debug build(src/jdk.pack/share/native/common-unpack/unpack.cpp) Earlier,I missed to fix those so debug build failed in linux. Regards, Srinivas ----- Original Message ----- From: magnus.ihse.bursie(a)oracle.com To: srinivas.dama(a)oracle.com, core-libs-dev(a)openjdk.java.net Sent: Thursday, 14 June, 2018 3:23:23 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi Subject: Re: RFR: 8204967: Resolve disabled warnings for libunpack On 2018-06-13 18:57, Srinivas Dama wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8204967/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8204967 Hi Srinivas, In src/jdk.pack/share/native/common-unpack/zip.cpp, you just read and discard the return value from fread to hide the warning. But the purpose of the warning is to point out that this kind of code is incorrect. The proper fix would be to check the return code from fread to make sure that the read did not fail. Otherwise you're just making it impossible for the compiler to point out the badly written code, and if you're not going to fix this properly, it's better to keep the warning (that way we know the code is fishy). /Magnus > > Regards, > Srinivas

2 1

RFR JDK-8204930 Reader:nullReader() spec does not match the behavior
by Patrick Reinhart 15 Jun '18

15 Jun '18

Hi everybody, While looking into the current Reader Spec and the failing methods I found that the ready() method actually does behave wrong and I fixed this. For the case of mark() I would like to revise the specification to align with the Reader’s default behavior that states for the mark method: IOException - If the stream does not support mark(), or if some other I/O error occurs The new spec for those methods would then read like: 70 * The {@code markSupported()} method returns {@code false}. The 71 * {@code mark()} and {@code reset()} methods throw an {@code IOException}. Here the link to the webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8204930/webrev -Patrick

4 8

RFR: JDK-8204973: Add build support for filtering translations
by Erik Joelsson 14 Jun '18

14 Jun '18

Hello, Oracle will reduce the number of languages that it maintains translations of JDK resources for. The current translations will remain in the source for now, but we need a way to filter out a set of translations at build time so that we only include the ones we support. This patch adds such a configuration option. It also changes how Oracle builds by using the option to exclude all translations except English, Japanese, Simplified Chinese and Traditional Chinese. Anyone else building OpenJDK will by default include all translations present in the source, just as before. I added a test that verifies this for builds with the "IMPLEMENTOR" field in the release file set to "Oracle Corporation". The test will not be run for other OpenJDK builds. I had to modify an existing test for java.logging which used various translations to verify localized log messages to only use translations that Oracle chooses to include. Since this is the second test that specifically verifies build behavior, I moved the previous such test together with this new test into a common top level test directory "build", under the jdk test root. I put these tests in the jdk tier3 test group. I have run all tier1, 2 and 3 tests in Mach 5 as well as specifically looked for tests that use the java.util.Locale class and ran them locally. Webrev: http://cr.openjdk.java.net/~erikj/8204973/webrev.01/index.html Bug: https://bugs.openjdk.java.net/browse/JDK-8204973 /Erik

4 5

RFR: [11] 8202537: CLDR 33
by Rachna Goel 14 Jun '18

14 Jun '18

Hi, Kindly review fix for JDK-8202537. Fix is to upgrade Unicode consortium's CLDR data into JDK from current version 29 to 33. For more info : http://cldr.unicode.org/index/downloads/cldr-33 Bug : https://bugs.openjdk.java.net/browse/JDK-8202537 Patch: http://cr.openjdk.java.net/~rgoel/JDK-8202537/webrev.06/index.html -- Thanks, Rachna

4 5

RFR: 8204967: Resolve disabled warnings for libunpack
by Srinivas Dama 14 Jun '18

14 Jun '18

Hi, Please review http://cr.openjdk.java.net/~sdama/8204967/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8204967 Regards, Srinivas

3 2

[AIX] Fix codepage mappings in Java for IBM-943 and Big5
by Bhaktavatsal R Maram 14 Jun '18

14 Jun '18

Hi All, This issue is continuation to bug 8201540 (Extend the set of supported charsets in java.base on AIX) in which we have moved default charsets of most of the locales supported by Operating System to java.base module thus enabling OpenJDK on those locales for AIX platform. As part of that, charsets for locales Ja_JP (IBM-943) and Zh_TW (big5) also have been moved. However, corresponding charsets mapped in Java is not correct for them on AIX. Following are the details: 1. IBM-943 [1] for locale Ja_JP should be mapped to IBM-943C [2] Fundamental difference between IBM-943 and IBM-943C is that IBM-943C is ASCII compatible which means code points 'yen' and 'overline' of IBM-943 is replaced with 'backslash' and 'tilde' from ASCII character set. 2. Big5 for locale Zh_TW should be mapped to IBM-950 [3] I've attached simple test program to print the default charset along with fix for this issue. When run test program (PrintDefaultCharset) with IBM JDK 8 (on AIX) for locales Ja_JP & Zh_TW, following is output. -bash-4.4$ LANG=Ja_JP ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset LANG = Ja_JP Default charset = x-IBM943C file.encoding = IBM-943C sun.jnu.encoding = IBM-943C -bash-4.4$ LANG=Zh_TW ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset LANG = Zh_TW Default charset = x-IBM950 file.encoding = IBM-950 sun.jnu.encoding = IBM-950 Same test run with openJDK 11 gives following output -bash-4.4$ LANG=Ja_JP ~/jdk/bin/java PrintDefaultCharset LANG = Ja_JP Default charset = x-IBM943 file.encoding = IBM-943 sun.jnu.encoding = IBM-943 -bash-4.4$ LANG=Zh_TW ~/jdk/bin/java PrintDefaultCharset LANG = Zh_TW Default charset = Big5 file.encoding = big5 sun.jnu.encoding = big5 I will get webrev hosted in http://cr.openjdk.java.net for this change and send it for review once JIRA bug is created. [1] http://demo.icu-project.org/icu-bin/convexp?conv=ibm-943_P130-1999&s=JAVA [2] http://demo.icu-project.org/icu-bin/convexp?conv=ibm-943_P15A-2003&s=ALL [3] https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgd… Thanks, Bhaktavatsal Reddy

5 17

JDK 11 RFR of JDK-8205003: Replace selected link tags with linkplain in java.lang.Class
by joe darcy 14 Jun '18

14 Jun '18

Hello, Please review the small patch below to address JDK-8205003: Replace selected link tags with linkplain in java.lang.Class Thanks, -Joe diff -r 0742a087710e src/java.base/share/classes/java/lang/Class.java --- a/src/java.base/share/classes/java/lang/Class.java Wed Jun 13 13:12:50 2018 -0700 +++ b/src/java.base/share/classes/java/lang/Class.java Wed Jun 13 17:50:12 2018 -0700 @@ -820,7 +820,7 @@ * primitive type or void, then the {@code Module} object for the * {@code java.base} module is returned. * - * If this class is in an unnamed module then the {@link + * If this class is in an unnamed module then the {@linkplain * ClassLoader#getUnnamedModule() unnamed} {@code Module} of the class * loader for this class is returned. * @@ -953,14 +953,14 @@ * empty string if the class is in an unnamed package. * * If this class is a member class, then this method is equivalent to - * invoking {@code getPackageName()} on the {@link #getEnclosingClass + * invoking {@code getPackageName()} on the {@linkplain #getEnclosingClass * enclosing class}. * - * If this class is a {@link #isLocalClass local class} or an {@link + * If this class is a {@linkplain #isLocalClass local class} or an {@linkplain * #isAnonymousClass() anonymous class}, then this method is equivalent to - * invoking {@code getPackageName()} on the {@link #getDeclaringClass - * declaring class} of the {@link #getEnclosingMethod enclosing method} or - * {@link #getEnclosingConstructor enclosing constructor}. + * invoking {@code getPackageName()} on the {@linkplain #getDeclaringClass + * declaring class} of the {@linkplain #getEnclosingMethod enclosing method} or + * {@linkplain #getEnclosingConstructor enclosing constructor}. * * If this class represents an array type then this method returns the * package name of the element type. If this class represents a primitive @@ -2576,7 +2576,7 @@ * @param name name of the desired resource * @return A {@link java.io.InputStream} object; {@code null} if no * resource with this name is found, the resource is in a package - * that is not {@link Module#isOpen(String, Module) open} to at + * that is not {@linkplain Module#isOpen(String, Module) open} to at * least the caller module, or access to the resource is denied * by the security manager. * @throws NullPointerException If {@code name} is {@code null} @@ -2675,7 +2675,7 @@ * @return A {@link java.net.URL} object; {@code null} if no resource with * this name is found, the resource cannot be located by a URL, the * resource is in a package that is not - * {@link Module#isOpen(String, Module) open} to at least the caller + * {@linkplain Module#isOpen(String, Module) open} to at least the caller * module, or access to the resource is denied by the security * manager. * @throws NullPointerException If {@code name} is {@code null}

4 3

RFR: JDK-8204172 Predicate::not should explicitly mention "NullPointerException - if target is null"
by Jim Laskey 13 Jun '18

13 Jun '18

CSR: https://bugs.openjdk.java.net/browse/JDK-8204959 webrev: http://cr.openjdk.java.net/~jlaskey/8204172/webrev/index.html Thank you, — Jim

2 1

RFR(xs): 8204663: clean up remaining native parts after JDK-8187631
by Thomas Stüfe 13 Jun '18

13 Jun '18

Hi, may I please have reviews for this small cleanup. Bug: https://bugs.openjdk.java.net/browse/JDK-8204663 Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8204663-clean-up-after-JDK-8… This change removes some native functions from FOS/FIS which are orphaned and unused since "JDK-8187631: Refactor FileDescriptor close implementation". Tests on jdk-submit came back clean save one strange test error on windows which I cannot reproduce locally. I am investigating that one. Thank you, Thomas

3 6