April 2021 - core-libs-dev

jpackage bugs
by Michael Hall 17 Apr '21

17 Apr '21

Is there anyway to get a simple/test reference type application available that could be used in reproducing bugs? I had two I think potentially serious bugs that were basically not addressed for problems in reproducing. JDK-8263156 : [macos]: OS X application signing concerns - a sealed resource is missing or invalid https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156> The command to reproduce was provided. The error appears to be in files included in the embedded JDK not being signed. So apparently not having to do with anything of mine. (Mentioned I now see in the comments). As I indicate this is not a serious error for me since I am not submitting the app to the Mac App Store but I believe this would get the app Apple rejected for anyone who is attempting that. A show stopper for a major use case. It seems too bad to simply close it because I missed an email asking for a reproduce. With a reference application I could demonstrate the error against would eliminate the need to provide a separate reproducible test case. Quite sized for the application in question. Such an application is actually mentioned in the bug report comments. Could such a application be made available for download or user reproducing - the jpackage command and arguments? I have looked a little bit at if to see if I can figure out how to sign the embedded jdk files. So far only accomplishing that I can no longer simply use my name for signing but have to use my fully qualified security identity. The question now seems to be what is in fact the difference between mine and the, unavailable to me, reference application as to these files verifying as correctly signed. A second bug JDK-8263154 : [macos]: OS X DMG builds have errors and end up incorrect I thought a fix for this was all set to go in and was pulled. It was apparently determined that the problem only applies if the —install-dir parameter is used for DMG’s. Where it really makes no sense. My use apparently held over from when I was just creating the app.I thought this had somehow also in some way regressed to not reproducible. I still think a fairly simple change to the AppleScript as was originally planned would resolve the issue independently of parameters. The default DMG build I would think should _always_ indicate installation to the Applications folder. With —install-dir this remains a reproducible bug for me at 17-ea. If a reference build was provided somewhere I might have picked up on the parameter difference sooner.

3 7

ObjectMethods seems generating wrong methods for array-type field
by Kengo TODA 17 Apr '21

17 Apr '21

Hello there, I'm Kengo TODA, an engineer learning about the Record feature. Today I found a nonintentional behavior, and it seems that the bug database has no info about it. Let me ask here to confirm it's by-design or not. If it's a bug, I want to try to send a patch to OpenJDK. Here is the code reproducing the nonintentional behavior: https://gist.github.com/KengoTODA/4d7ef6a5226d347ad9385241fee6bc63 In short, the ObjectMethods class in OpenJDK v16 generates code that invokes the fields' method, even when the field is an array. Please help me to understand this behavior, or make an entry in the bug database to propose a patch. Thanks in advance! :) *** Kengo TODA skypencil(a)gmail.com

2 3

RFR: 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter
by Naoto Sato 16 Apr '21

16 Apr '21

Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`). ------------- Commit messages: - 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter Changes: https://git.openjdk.java.net/jdk/pull/3553/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3553&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265375 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3553.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3553/head:pull/3553 PR: https://git.openjdk.java.net/jdk/pull/3553

2 3

Enhancement proposal regarding bufferization of InputStream
by Сергей Цыпанов 16 Apr '21

16 Apr '21

Hello, buffering with j.i.BufferedInputStream is a handy way to improve performance of IO operations. However in many cases buffering is redundant. Consider this code snippet from Spring Framework: static ClassReader getClassReader(Resource rsc) throws Exception { try (var is = new BufferedInputStream(rsc.getInputStream())) { return new ClassReader(is); } } Interface Resource has lots of implementations some of them return buffered InputStream, others don't, but all of them get wrapped with BufferedInputStream. Apart from obvious misuses like BufferedInputStream cascade such wrapping is not necessary, e.g. when we read a huge file using FileInputStream.readAllBytes(), in others cases it's harmful e.g. when we read a small (comparing to the default size of buffer in BufferedInputStream) file with readAllBytes() or when we read from ByteArrayInputStream which is kind of buffered one by its nature. I think an instance of InputStream should decide itself whether it requires buffering, so I suggest to add a couple of methods into j.i.InputStream: // subclasses can override this protected boolean needsBuffer() { return true; } public InputStream buffered() { return needsBuffer() ? new BufferedInputStream(this) : this; } this allows subclasses of InputStream to override needsBuffer() to declare buffering redundancy. Let's imagine we've overridden needsBuffer() in BufferedInputStream: public class BufferedInputStream { @Override public boolean needsBuffer() { return true; } } then the code we've mentioned above should be rewritten as static ClassReader getClassReader(Resource rsc) throws Exception { try (var is = rsc.getInputStream().buffered()) { return new ClassReader(is); } } preventing cascade of BufferedInputStreams. There are also cases when the need for buffering depends on the way how we read from InputStream: new FileInputStream(file).buffered().readAllBytes() // buffering is redundant var data = new DataInputStream(new FileInputStream(file).buffered()) for (int i = 0; i < 1000; i++) { data.readInt(); // readInt() does 4 calls to InputStream.read() so buffering is needed } here if FileInputStream.needsBuffer() is overridden and returns false (assuming most of reads from it are bulk) then we won't have buffering for DataInputStream. To avoid this we can also add InputStream.buffered(boolean enforceBuffering) to have manual control. To sum up, my proposal is to add those methods to InputStream: protected static boolean needsBuffer() { return true; } public InputStream buffered() { return buffered(needsBuffer()); } public InputStream buffered(boolean enforceBuffering) { return enforceBuffering ? new BufferedInputStream(this) : this; } What do you think? With best regards, Sergey Tsypanov

3 3

RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
by Daniel D.Daugherty 16 Apr '21

16 Apr '21

A set of trivial ProblemListing for macos-aarch64 Tier2 test failures: - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64 - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64 - JDK-8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64 - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64 - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64 ------------- Commit messages: - 8265370: ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64 - 8265368: ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64 - 8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64 - 8265363: ProblemList java/net/Socket/UdpSocket.java on macos-aarch64 - 8265361: ProblemList a few compiler/whitebox tests on macos-aarch64 - 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3549/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3549&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265358 Stats: 16 lines in 3 files changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3549/head:pull/3549 PR: https://git.openjdk.java.net/jdk/pull/3549

3 6

Looking for reviewer and sponsor for 4926314
by Philippe Marschall 16 Apr '21

16 Apr '21

Hello I am looking for reviewers and a sponsor for JDK-4926314: Optimize Reader.read(CharBuffer) [1]. The PR [2] went through quite some changes and is now back to few changes to reduce the impact and the risk. [1] https://bugs.openjdk.java.net/browse/JDK-4926314 [2] https://github.com/openjdk/jdk/pull/1915 Cheers Philippe

2 1

8246334: Casting ‘double to int’ and ‘long to int’ produce different results
by Raffaello Giulietti 16 Apr '21

16 Apr '21

Hello, the reporter of [1] seems to understand that the current behavior is well specified (since ever) and correctly implemented. Also, it's unclear how s/he would like to enhance it. Shouldn't [1] be closed? Greetings Raffaello ---- [1] https://bugs.openjdk.java.net/browse/JDK-8246334

1 0

RFR: 8262108: SimpleDateFormat formatting broken for sq_MK Locale
by Jaikiran Pai 16 Apr '21

16 Apr '21

Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108? As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108. The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field. The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix. After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values. ------------- Commit messages: - Fix test that now fails after fixing 8262108 - 8262108: SimpleDateFormat formatting broken for sq_MK Locale Changes: https://git.openjdk.java.net/jdk/pull/3463/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3463&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262108 Stats: 117 lines in 3 files changed: 97 ins; 1 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/3463.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3463/head:pull/3463 PR: https://git.openjdk.java.net/jdk/pull/3463

2 19

RFR: 8258794: Support for CLDR version 39
by Naoto Sato 15 Apr '21

15 Apr '21

Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698) ------------- Commit messages: - 8258794: Support for CLDR version 39 - CLDR 38.1 Changes: https://git.openjdk.java.net/jdk/pull/3502/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3502&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258794 Stats: 26326 lines in 815 files changed: 761 ins; 23140 del; 2425 mod Patch: https://git.openjdk.java.net/jdk/pull/3502.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3502/head:pull/3502 PR: https://git.openjdk.java.net/jdk/pull/3502

3 4

RFR: 8261301: StringWriter.flush() is NOOP but documentation does not indicate it
by Brian Burkhalter 15 Apr '21

15 Apr '21

The specification of the method `flush()` in the `java.io` classes `CharArrayWriter` and `StringWriter` is not explicit about the fact that the method has no effect. This request proposes to add to the specification of each flush() method the sentence The {@code flush} method of {@code <ClassName/>} does nothing. The corresponding CSR is JDK-8264867. ------------- Commit messages: - 8261301: StringWriter.flush() is NOOP but documentation does not indicate it Changes: https://git.openjdk.java.net/jdk/pull/3383/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3383&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261301 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3383.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3383/head:pull/3383 PR: https://git.openjdk.java.net/jdk/pull/3383

3 4