June 2018 - core-libs-dev

8143850: retrofit ArrayDeque to implement List
by Alex Foster 07 Aug '18

07 Aug '18

Hi, <https://bugs.openjdk.java.net/browse/JDK-8143850> <https://bugs.openjdk.java.net/browse/JDK-8143850> I did this awhile ago and I'd like to submit it. I believe it needs to be a new class because it changes the behavior of equals and hashcode. My implementation is based off of the java 8 version I think and it has changed a lot since then, I could add some of the improvements if you want. Also I'm not sure if we should make a new Deque + List interface for it to implement or not. Code: https://pastebin.com/suXMfMZW Bug: https://bugs.openjdk.java.net/browse/JDK-8143850 Previous discussion:<https://bugs.openjdk.java.net/browse/JDK-8143850> <https://bugs.openjdk.java.net/browse/JDK-8143850>http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024938.h… <https://bugs.openjdk.java.net/browse/JDK-8143850>Alex<http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024938.h…>

6 14

RFR: 8202794: Native Unix code should use readdir rather than readdir_r
by Pengfei Li 06 Aug '18

06 Aug '18

Hi Last month, Bernard proposed a patch to fix the OpenJDK build issue with recent versions of glibc. See http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052991.html But this fix requires to be tested on all POSIX systems before getting integrated. As recently, more and more guys are complaining about the OpenJDK build failure issue, shall we just add the following workaround to upstream before Bernard's real fix eventually merged? diff --git a/src/java.base/unix/native/libjava/TimeZone_md.c b/src/java.base/unix/native/libjava/TimeZone_md.c index f0bb362afc..e156381acd 100644 --- a/src/java.base/unix/native/libjava/TimeZone_md.c +++ b/src/java.base/unix/native/libjava/TimeZone_md.c @@ -146,7 +146,7 @@ findZoneinfoFile(char *buf, size_t size, const char *dir) (void) closedir(dirp); return NULL; } - +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" while (readdir64_r(dirp, entry, &dp) == 0 && dp != NULL) { /* * Skip '.' and '..' (and possibly other .* files) diff --git a/src/java.base/unix/native/libjava/UnixFileSystem_md.c b/src/java.base/unix/native/libjava/UnixFileSystem_md.c index 315aa92b64..5b9554dd47 100644 --- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c +++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c @@ -339,6 +339,7 @@ Java_java_io_UnixFileSystem_list(JNIEnv *env, jobject this, if (rv == NULL) goto error; /* Scan the directory */ +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" while ((readdir64_r(dir, ptr, &result) == 0) && (result != NULL)) { jstring name; if (!strcmp(ptr->d_name, ".") || !strcmp(ptr->d_name, "..")) diff --git a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c index 53bb1c1009..72c38eb9a6 100644 --- a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c +++ b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c @@ -731,6 +731,7 @@ Java_sun_nio_fs_UnixNativeDispatcher_readdir(JNIEnv* env, jclass this, jlong val /* EINTR not listed as a possible error */ /* TDB: reentrant version probably not required here */ +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" res = readdir64_r(dirp, ptr, &result); #ifdef _AIX diff --git a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c index 1adeaf7bb5..080cf2a89b 100644 --- a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c +++ b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c @@ -80,6 +80,7 @@ static struct dirent* read_dir(DIR* dirp, struct dirent* entry) { return dbuf; #else /* __linux__ || _ALLBSD_SOURCE */ struct dirent* p; +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" if (readdir_r(dirp, entry, &p) == 0) { return p; } else { -- Thanks, Pengfei

4 8

Add x-IBM-1129 charset
by Nasser Ebrahim 03 Aug '18

03 Aug '18

Hello, With the following three bugs, all the default locale charsets except two (Vi_VN.IBM-1129 & ja_JP.IBM-eucJP) are fixed for AIX platform. - JDK-8201540: [AIX] Extend the set of supported charsets in java.base - JDK-8202329: Codepage mappings for IBM-943 and Big5 (aix) - http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html : [AIX] Add charset IBM-964 (default charset for zh_TW.IBM-eucTW) to stdcs [bug not yet opened]. For those fixed charsets, the charsets were existing in the extended charsets (jdk.charsets) and they were not working with default locale charset as it did not exist in the standard charset (java.base). The charsets correspond to the two pending locale (Vi_VN.IBM-1129 & ja_JP.IBM-eucJP) does not exist in the jdk. They need to be added to the extended charsets before adding to stdcs on AIX platform. Here, am including the patch to fix the charset IBM-1129 for the locale Vi_VN.IBM-1129. We are working on the other missing charset (for ja_JP.IBM-eucJP) which will be contributed in some time. The webrev of the fix is available at http://cr.openjdk.java.net/~aleonard/IBM1129/webrev.00/ Kindly request you to open a bug and review the fix. Please let me know if you have any questions. Thank you, Nasser Ebrahim

3 4

Draft JEP proposal: JDK-8200758: Packaging Tool
by Kevin Rushforth 27 Jul '18

27 Jul '18

I would like to propose the following Draft JEP [1] for discussion. JDK-8200758: Packaging Tool This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX. Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758

9 12

Re: Add x-IBM-1129 charset
by Nasser Ebrahim 26 Jul '18

26 Jul '18

Hello, I just realized that I missed to provide the details of the test I have conducted for the new charset IBM-1129. Please note that I have done the following jtreg tests to make sure the new charset is working properly. sun.nio.cs.TestCharsetMapping java.nio.charset.Charset.RegisteredCharsets sun.nio.cs.CheckHistoricalNamesTest java.nio.charset.RemovingSunIO.SunioAlias Please let me know if I have to run any additional tests. Am aware of the suggestion from Alan and Thomas in the mail thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053316.html to move the IBM platform specific charsets to a separate module instead of adding to jdk.charsets. We will open another thread to discuss that topic as we would like to contribute many more extended charsets. However, I believe we can still consider integrating this charset without waiting for the conclusion of that discussion as this charset is part of default charset for AIX and needs to be part of the java.base. If we decided to move the IBM charsets out of jdk.charsets, we can move this charsets as well for non-AIX platforms. Kindly request you to open a bug/RFE for this change request, review the fix and provide your feedback. Thank you, Nasser Ebrahim From: Nasser Ebrahim/India/IBM To: core-libs-dev(a)openjdk.java.net Date: 05/19/2018 12:51 PM Subject: Add x-IBM-1129 charset Hello, With the following three bugs, all the default locale charsets except two (Vi_VN.IBM-1129 & ja_JP.IBM-eucJP) are fixed for AIX platform. - JDK-8201540: [AIX] Extend the set of supported charsets in java.base - JDK-8202329: Codepage mappings for IBM-943 and Big5 (aix) - http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html : [AIX] Add charset IBM-964 (default charset for zh_TW.IBM-eucTW) to stdcs [bug not yet opened]. For those fixed charsets, the charsets were existing in the extended charsets (jdk.charsets) and they were not working with default locale charset as it did not exist in the standard charset (java.base). The charsets correspond to the two pending locale (Vi_VN.IBM-1129 & ja_JP.IBM-eucJP) does not exist in the jdk. They need to be added to the extended charsets before adding to stdcs on AIX platform. Here, am including the patch to fix the charset IBM-1129 for the locale Vi_VN.IBM-1129. We are working on the other missing charset (for ja_JP.IBM-eucJP) which will be contributed in some time. The webrev of the fix is available at http://cr.openjdk.java.net/~aleonard/IBM1129/webrev.00/ Kindly request you to open a bug and review the fix. Please let me know if you have any questions. Thank you, Nasser Ebrahim

3 4

Re: Draft JEP proposal: JDK-8200758: Packaging Tool
by Buchberger, Joerg 25 Jul '18

25 Jul '18

Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I really mean it] But, to sum up my comprehension... anyone who placed their bets on javapackager, starting with last LTS Java 8 will be left in the rain with followup LTS Java 11, because their ain't neither javapackager (anymore), nor jpackager (yet). Is this correct? So, strategic choice boils down to either throw away all work done based on javapackager so far and the associated distribution concepts (reworking everything from scratch) or neglect Java 11 completely, thus placing all bets on jpackager really coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter. Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in ... Cheers Jörg On 5/31/2018 0:10 AM, Rushforth, Kevin wrote: > I would like to propose the following Draft JEP [1] for discussion. > > JDK-8200758: Packaging Tool > > This is intended as a JDK-scope replacement for the existing > javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK > releases), and was delivered as part of the JavaFX build. The > javapackager tool has been removed from Oracle JDK 11 along with the > removal of JavaFX. > > Comments on this JEP are welcome. It is currently not targeted for a > specific release, but we are aiming for JDK 12. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >

7 17

RFR 8198882: Add 10 JNDI tests to com/sun/jndi/dns/AttributeTests/
by Chris Yin 25 Jul '18

25 Jul '18

Please review the changes to add 10 JNDI tests to com/sun/jndi/dns/AttributeTests/, thanks bug: https://bugs.openjdk.java.net/browse/JDK-8198882 <https://bugs.openjdk.java.net/browse/JDK-8198882> webrev: http://cr.openjdk.java.net/~xyin/8198882/webrev.00/ <http://cr.openjdk.java.net/~xyin/8198882/webrev.00/> Regards, Chris

3 9

[PATCH] AbstractStringBuilder.append(<StringBuilder>)
by Isaac Levy 18 Jul '18

18 Jul '18

AbstractStringBuilder already has append(<StringBuffer>). This patch adds append(<StringBuilder>). The new method improves parity between the two classes. In addition, combining StringBuilders is presumably common. append(<CharSequence>) has a couple insteadof checks, which this new method skips. -Isaac diff --git a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java index 2ef3e53256..1fe89bb92a 100644 --- a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java +++ b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java @@ -543,6 +543,11 @@ abstract class AbstractStringBuilder implements Appendable, CharSequence { return this.append((AbstractStringBuilder)sb); } + // Documentation in subclasses because of synchro difference + public AbstractStringBuilder append(StringBuilder sb) { + return this.append((AbstractStringBuilder)sb); + } + /** * @since 1.8 */ diff --git a/src/java.base/share/classes/java/lang/StringBuffer.java b/src/java.base/share/classes/java/lang/StringBuffer.java index e597a8112e..613ba90c25 100644 --- a/src/java.base/share/classes/java/lang/StringBuffer.java +++ b/src/java.base/share/classes/java/lang/StringBuffer.java @@ -313,6 +313,33 @@ import jdk.internal.HotSpotIntrinsicCandidate; return this; } + /** + * Appends the specified {@code StringBuilder} to this sequence. + * + * The characters of the {@code StringBuilder} argument are appended, + * in order, to the contents of this {@code StringBuffer}, increasing the + * length of this {@code StringBuffer} by the length of the argument. + * If {@code sb} is {@code null}, then the four characters + * {@code "null"} are appended to this {@code StringBuffer}. + * + * Let n be the length of the old character sequence, the one + * contained in the {@code StringBuffer} just prior to execution of the + * {@code append} method. Then the character at index k in + * the new character sequence is equal to the character at index k + * in the old character sequence, if k is less than n; + * otherwise, it is equal to the character at index k-n in the + * argument {@code sb}. + * + * + * @param sb the {@code StringBuilder} to append. + * @return a reference to this object. + */ + public synchronized StringBuffer append(StringBuilder sb) { + toStringCache = null; + super.append(sb); + return this; + } + /** * Appends the specified {@code StringBuffer} to this sequence. * diff --git a/src/java.base/share/classes/java/lang/StringBuilder.java b/src/java.base/share/classes/java/lang/StringBuilder.java index 40da2083c2..5ddd4fb5f9 100644 --- a/src/java.base/share/classes/java/lang/StringBuilder.java +++ b/src/java.base/share/classes/java/lang/StringBuilder.java @@ -199,6 +199,30 @@ public final class StringBuilder return this; } + /** + * Appends the specified {@code StringBuilder} to this sequence. + * + * The characters of the {@code StringBuilder} argument are appended, + * in order, to this sequence, increasing the + * length of this sequence by the length of the argument. + * If {@code sb} is {@code null}, then the four characters + * {@code "null"} are appended to this sequence. + * + * Let n be the length of this character sequence just prior to + * execution of the {@code append} method. Then the character at index + * k in the new character sequence is equal to the character at + * index k in the old character sequence, if k is less than + * n; otherwise, it is equal to the character at index k-n + * in the argument {@code sb}. + * + * @param sb the {@code StringBuilder} to append. + * @return a reference to this object. + */ + public StringBuilder append(StringBuilder sb) { + super.append(sb); + return this; + } + @Override public StringBuilder append(CharSequence s) { super.append(s);

4 8

[PATCH] regex matcher opt: remove redundant StringBuilder
by Isaac Levy 18 Jul '18

18 Jul '18

(moving this to a separate discussion) --- a/src/java.base/share/classes/java/util/regex/Matcher.java +++ b/src/java.base/share/classes/java/util/regex/Matcher.java @@ -993,13 +993,11 @@ public Matcher appendReplacement(StringBuilder sb, String replacement) { // If no match, return error if (first < 0) throw new IllegalStateException("No match available"); - StringBuilder result = new StringBuilder(); - appendExpandedReplacement(replacement, result); // Append the intervening text sb.append(text, lastAppendPosition, first); // Append the match substitution + appendExpandedReplacement(replacement, sb); - sb.append(result); On Mon, Apr 23, 2018 at 5:05 PM Xueming Shen <xueming.shen(a)oracle.com> wrote: > > > I would assume in case of an exception thrown from appendExpandedReplacement() we don't > want "text" to be pushed into the "sb". > > -sherman Perhaps. Though the behavior under exception is undefined and this function is probably primarily used though the replaceAll API, which wouldn’t return the intermediate sb under the case of exception. My reading of the blame was the temp StringBuilder was an artifact of the api previously using StringBuffer externally. See http://hg.openjdk.java.net/jdk9/dev/jdk/rev/763c564451b3

2 6

RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers
by Adam Farley8 16 Jul '18

16 Jul '18

Hi All, Native memory allocation for DBBs is tracked in java.nio.Bits, but that only includes what the user thinks they are allocating. When the VM adds extra memory to the allocation amount this extra bit is not represented in the Bits total. A cursory glance shows, minimum, that we round the requested memory quantity up to the heap word size in the Unsafe.allocateMemory code, and something to do with nmt_header_size in os:malloc() (os.cpp) too. On its own, and in small quantities, align_up(sz, HeapWordSize) isn't that big of an issue. But when you allocate a lot of DBBs, and coupled with the nmt_header_size business, it makes the Bits values wrong. The more DBB allocations, the more inaccurate those numbers will be. To get the "+X", it seems to me that the best option would be to introduce an native method in Bits that fetches "X" directly from Hotspot, using the same code that Hotspot uses (so we'd have to abstract-out the Hotspot logic that adds X to the memory quantity). This way, anyone modifying the Hotspot logic won't risk rendering the Bits logic wrong again. That's only one way to fix the accuracy problem here though. Suggestions welcome. Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

3 3