May 2021 - core-libs-dev

RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home
by ScientificWare 11 Jun '21

11 Jun '21

This concern [dtdbuilder tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/buil…. In jshell, try `System.getProperty("html32") + ""` you'll get a `String`. So, in `DTDBuilder.java` when none `dtd_home` property is set, the `dtd_home` string value is not `null`, causing an exception with the present test. The expect value is `"Must set property 'dtd_home'"` And in this case, should'nt we have a `System.exit(1)` too rather than a simple `return` ? ------------- Commit messages: - Change test none dtd_home property is set. Changes: https://git.openjdk.java.net/jdk/pull/3626/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3626&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265909 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3626.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3626/head:pull/3626 PR: https://git.openjdk.java.net/jdk/pull/3626

2 10

RFR: 8267893: Improve EFH do get native/mixed stack traces for cores and live processes
by Leonid Mesnik 10 Jun '21

10 Jun '21

EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated. ------------- Commit messages: - Merge branch 'master' of https://github.com/openjdk/jdk into efh - EFH improvements Changes: https://git.openjdk.java.net/jdk/pull/4234/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4234&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267893 Stats: 188 lines in 13 files changed: 158 ins; 6 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/4234.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234 PR: https://git.openjdk.java.net/jdk/pull/4234

3 17

RFR: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions
by Rafael Winterhalter 10 Jun '21

10 Jun '21

If a type is changed from a type that can be a member of an annotation which is used in an array, changing it to a type that cannot be an array member will be treated as if the type is an annotation type. As a result, no exception proxy is created and the type is returned as if it was correctly defined. ------------- Commit messages: - 8266766: Arrays of types that cannot be an annotation member do not yield exceptions Changes: https://git.openjdk.java.net/jdk/pull/3925/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3925&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266766 Stats: 130 lines in 2 files changed: 128 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3925/head:pull/3925 PR: https://git.openjdk.java.net/jdk/pull/3925

3 9

RFR: 8266835: Add a --validate option to the jar tool
by Jorn Vernee 09 Jun '21

09 Jun '21

This patch adds a `--validate` option to the jar tool which can be used to validate a jar file that might be malformed. For instance, if a jar is a multi-release jar, it is malformed if different versions expose different APIs. The implementation is straight forward since there already exists validation logic that is run when creating or updating a jar. This patch just exposes that logic directly under a new command line flag. I've enhanced the existing ApiValidatorTest to also create malformed jars using the zip file APIs (the jar tool does not output malformed jars) and run them through `jar --validate`. Note that while the jdk's jar tool does not output malformed jars, third-party archiving tools might, or the jar could have been manually edited. Some prior discussion here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077420.html Testing: running jdk/tools/jar test suite locally, tier 1-3 (in progress), manual testing. ------------- Commit messages: - - Remove spurious test imports - Add tests - Change validate option wording to not mention multi-release jars - Add jar --validate Changes: https://git.openjdk.java.net/jdk/pull/3971/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3971&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266835 Stats: 146 lines in 4 files changed: 114 ins; 4 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/3971.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3971/head:pull/3971 PR: https://git.openjdk.java.net/jdk/pull/3971

3 12

RFR: 8266598: Exception values for AnnotationTypeMismatchException are not always informative
by Rafael Winterhalter 09 Jun '21

09 Jun '21

This improves the messages that are provided by `AnnotationTypeMismatchException`s. The message provided by AnnotationTypeMismatchExceptions is deliberately undefined such that this should not break any contract. ------------- Commit messages: - 8266598: Exception values for AnnotationTypeMismatchException are not always informative Changes: https://git.openjdk.java.net/jdk/pull/3892/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3892&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266598 Stats: 21 lines in 3 files changed: 12 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3892.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3892/head:pull/3892 PR: https://git.openjdk.java.net/jdk/pull/3892

3 10

RFR: 8264859: Implement Context-Specific Deserialization Filters
by Roger Riggs 09 Jun '21

09 Jun '21

JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional configuration mechanisms and filter utilities. ------------- Commit messages: - JEP 415: Context-specific Deserialization Filters Changes: https://git.openjdk.java.net/jdk/pull/3996/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264859 Stats: 1583 lines in 5 files changed: 1475 ins; 24 del; 84 mod Patch: https://git.openjdk.java.net/jdk/pull/3996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996 PR: https://git.openjdk.java.net/jdk/pull/3996

5 73

RFR: 8195129: System.load() fails to load from unicode paths
by Maxim Kartashev 08 Jun '21

08 Jun '21

Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page". This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug). The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS. Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well. Results from Linux: Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 ============================== TEST SUCCESS Building target 'run-test-only' in configuration 'linux-x86_64-server-release' Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java Test results: passed: 1 Results from Windows 10: Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg/runtime 746 746 0 0 ============================== TEST SUCCESS Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java Test results: passed: 1 ------------- Commit messages: - 8195129: System.load() fails to load from unicode paths Changes: https://git.openjdk.java.net/jdk/pull/4169/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8195129 Stats: 294 lines in 7 files changed: 247 ins; 27 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/4169.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4169/head:pull/4169 PR: https://git.openjdk.java.net/jdk/pull/4169

6 30

RFR: JDK-8266918: merge_stack in check_code.c add NULL check
by Matthias Baesken 08 Jun '21

08 Jun '21

Hello, please review this small Sonar finding. Sonar reports a potential NULL pointer dereference here : https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8… "Access to field 'item' results in a dereference of a null pointer (loaded from variable 'new')" It would be better to add a check . ------------- Commit messages: - JDK-8266918 Changes: https://git.openjdk.java.net/jdk/pull/3979/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3979&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266918 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3979.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3979/head:pull/3979 PR: https://git.openjdk.java.net/jdk/pull/3979

3 4

RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams
by Roger Riggs 07 Jun '21

07 Jun '21

Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process. The Charset used to encode and decode characters to bytes can be specified or use the operating system native encoding as is available from the "native.encoding" system property. ------------- Commit messages: - 8191441: (Process) add Readers and Writer access to java.lang.Process streams Changes: https://git.openjdk.java.net/jdk/pull/4134/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8191441 Stats: 416 lines in 2 files changed: 412 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4134.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4134/head:pull/4134 PR: https://git.openjdk.java.net/jdk/pull/4134

8 31

RFR: 8265039: Adjust javadoc for ByteArray*Stream and InputStream
by Сергей Цыпанов 07 Jun '21

07 Jun '21

Hello, to avoid cases detected in [https://github.com/openjdk/jdk/pull/2992](https://github.com/openjdk/jdk/pu… I propose to modify JavaDoc of `ByteArray*Stream` to explicitly mention redundancy of wrapping with `BufferedInputStream`. As of `InputStream` I think in notation `It is never correct to use the return value of this method to allocate a buffer intended to hold all data in this stream.` the word 'never' should be replaced with 'usually': apart from `ByteArrayInputStream` e.g. `FileInputStream.available()` often returns the count of remaining bytes (the only exclusion I'm aware of is the files located under `/proc/`) and indeed this count can be used to allocate a buffer to read all the bytes in one call. Consider benchmark @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class ByteArrayInputStreamBenchmark { @Benchmark public void read(Data data, Blackhole bh) { int value; var in = data.bais; while ((value = in.read()) != -1) { bh.consume(value); } } @Benchmark public void readBuffered(Data data, Blackhole bh) throws IOException { int value; var in = new BufferedInputStream(data.bais); while ((value = in.read()) != -1) { bh.consume(value); } } @Benchmark public Object readAllBytes(Data data) { var in = data.bais; return in.readAllBytes(); } @Benchmark public Object readAllBytesBuffered(Data data) throws IOException { var in = data.bais; return new BufferedInputStream(in).readAllBytes(); } @State(Scope.Thread) public static class Data { @Param({"8", "128", "512", "1024"}) private int length; private byte[] bytes; private ByteArrayInputStream bais; @Setup(Level.Iteration) public void setUp() { bytes = new byte[length]; ThreadLocalRandom.current().nextBytes(bytes); } @Setup(Level.Invocation) public void setUpBais() { bais = new ByteArrayInputStream(bytes); } } } giving (length) Score Error Units read 8 55.737 ± 0.431 ns/op read 128 533.172 ± 1.613 ns/op read 512 2066.238 ± 23.989 ns/op read 1024 4335.570 ± 20.137 ns/op readBuffered 8 521.936 ± 2.454 ns/op readBuffered 128 971.617 ± 100.469 ns/op readBuffered 512 2284.472 ± 251.390 ns/op readBuffered 1024 4168.598 ± 77.980 ns/op readAllBytes 8 34.850 ± 0.072 ns/op readAllBytes 128 36.751 ± 0.133 ns/op readAllBytes 512 45.304 ± 0.699 ns/op readAllBytes 1024 61.790 ± 0.386 ns/op readAllBytesBuffered 8 870.454 ± 4.406 ns/op readAllBytesBuffered 128 910.176 ± 32.258 ns/op readAllBytesBuffered 512 896.155 ± 6.005 ns/op readAllBytesBuffered 1024 965.596 ± 29.225 ns/op read:·gc.alloc.rate.norm 8 32.006 ± 0.001 B/op read:·gc.alloc.rate.norm 128 32.007 ± 0.004 B/op read:·gc.alloc.rate.norm 512 32.010 ± 0.010 B/op read:·gc.alloc.rate.norm 1024 32.011 ± 0.008 B/op readBuffered:·gc.alloc.rate.norm 8 8280.354 ± 0.016 B/op readBuffered:·gc.alloc.rate.norm 128 8240.484 ± 0.015 B/op readBuffered:·gc.alloc.rate.norm 512 8240.599 ± 0.056 B/op readBuffered:·gc.alloc.rate.norm 1024 8280.978 ± 0.024 B/op readAllBytes:·gc.alloc.rate.norm 8 56.008 ± 0.001 B/op readAllBytes:·gc.alloc.rate.norm 128 176.017 ± 0.001 B/op readAllBytes:·gc.alloc.rate.norm 512 560.035 ± 0.002 B/op readAllBytes:·gc.alloc.rate.norm 1024 1072.057 ± 0.002 B/op readAllBytesBuffered:·gc.alloc.rate.norm 8 16512.660 ± 0.026 B/op readAllBytesBuffered:·gc.alloc.rate.norm 128 16632.684 ± 0.008 B/op readAllBytesBuffered:·gc.alloc.rate.norm 512 17016.694 ± 0.017 B/op readAllBytesBuffered:·gc.alloc.rate.norm 1024 17528.748 ± 0.012 B/op ------------- Commit messages: - Adjust javadoc for ByteArray*Stream Changes: https://git.openjdk.java.net/jdk/pull/3341/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3341&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265039 Stats: 20 lines in 3 files changed: 7 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3341.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3341/head:pull/3341 PR: https://git.openjdk.java.net/jdk/pull/3341

3 3