March 2021 - core-libs-dev

RFR: JDK-8263104: fix warnings for empty paragraphs
by Jonathan Gibbons 06 Mar '21

06 Mar '21

Please review some simple cleanup for empty `<p>` tags. Two of the tags are completely redundant, and simply deleted. The other three, in _package.html_ files are generally undesirable. Although the presumed intent of the `id` declaration is to label the `@see` info, proximity in the source code does not ensure proximity in the generated code. The actual result is an empty paragraph at the end of the enclosing generated `<div>`, and before the generated output for the `@since` tag. The better solution is to move the `id` declaration into the `@see <a href...` and then delete the empty `<p>`. ------------- Commit messages: - JDK-8263104: fix warnings for empty paragraphs Changes: https://git.openjdk.java.net/jdk/pull/2850/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2850&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263104 Stats: 8 lines in 5 files changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2850.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2850/head:pull/2850 PR: https://git.openjdk.java.net/jdk/pull/2850

1 0

RFR: 8261845: File permissions of packages built by jpackage
by Alexander Matveev 06 Mar '21

06 Mar '21

- Fixed by adding write permissions to .exe package. ------------- Commit messages: - 8261845: File permissions of packages built by jpackage Changes: https://git.openjdk.java.net/jdk/pull/2822/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2822&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261845 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2822/head:pull/2822 PR: https://git.openjdk.java.net/jdk/pull/2822

4 4

Contributing to 8259896: Base64 MIME decoder should allow unrecognised characters within padding
by Raffaello Giulietti 05 Mar '21

05 Mar '21

Hello, I can contribute in solving the issue [1] mentioned in [2]. But before investing time, I just want to make sure that there is some consensus that it needs to be solved in the first place. Maybe there are diverging opinions that consider the current behavior as correct. Greetings Raffaello ---- [1] https://bugs.openjdk.java.net/browse/JDK-8259896 [2] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-February/074407.… > Hello Raffaello, > > I have added this comment from you, to that JDK-8259896 issue. > > -Jaikiran > > On 02/02/21 12:43 am, Raffaello Giulietti wrote: >> Hi, >> >> in my opinion, the reporter of [1] is right in requiring that >> extraneous characters be discarded, even inside the padding. >> >> Indeed, the first full paragraph on [2] reads: >> >> "Any characters outside of the base64 alphabet are to be ignored in >> base64-encoded data." >> >> where "the base64 alphabet" also includes the padding character '=' >> and "base64-encoded data" extends to padding as well, because padding >> is an essential part of encoding. >> >> The legitimate doubt expressed in comment [3] should thus be solved in >> favor of a bug fix. >> >> >> My 2 cents >> Greetings >> Raffaello >> >> ---- >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8259896 >> [2] https://tools.ietf.org/html/rfc2045#page-26 >> [3] >> https://bugs.openjdk.java.net/browse/JDK-8259896?focusedCommentId=14395485&… >> >

1 0

RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized*
by Ian Graves 05 Mar '21

05 Mar '21

Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. ------------- Commit messages: - Changing Collections.unmodifiable* to idempotent behavior. Changes: https://git.openjdk.java.net/jdk/pull/2596/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6323374 Stats: 281 lines in 2 files changed: 281 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2596.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2596/head:pull/2596 PR: https://git.openjdk.java.net/jdk/pull/2596

8 39

RFR: 8262300: jpackage app-launcher fails on linux when using JDK11 based runtime
by Alexey Semenyuk 05 Mar '21

05 Mar '21

Fix jpackage app launcher to also look for JLI lib in "lib/jli/libjli.so" subdirectory of runtime ------------- Commit messages: - 8262300: jpackage app-launcher fails on linux when using JDK11 based runtime Changes: https://git.openjdk.java.net/jdk/pull/2827/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2827&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262300 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2827.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2827/head:pull/2827 PR: https://git.openjdk.java.net/jdk/pull/2827

3 3

RFR: 8262989: Vectorize VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods
by Sandhya Viswanathan 04 Mar '21

04 Mar '21

The hot path of VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods can be implemented using Vector API methods. For the attached jmh TestSlice.java, performance improves as below. Before: Benchmark (size) Mode Cnt Score Error Units TestSlice.vectorSliceOrigin 1024 thrpt 5 1224.698 ± 53.825 ops/ms TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 657.895 ± 31.945 ops/ms After: Benchmark (size) Mode Cnt Score Error Units TestSlice.vectorSliceOrigin 1024 thrpt 5 11221.532 ± 88.616 ops/ms TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6509.519 ± 18.102 ops/ms ------------- Commit messages: - 8262989: Vectorize VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods Changes: https://git.openjdk.java.net/jdk/pull/2819/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2819&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262989 Stats: 43 lines in 8 files changed: 7 ins; 9 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/2819.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2819/head:pull/2819 PR: https://git.openjdk.java.net/jdk/pull/2819

2 4

RFR: JDK-8261518: jpackage looks for main module in current dir when there is no module-path
by Andy Herrick 04 Mar '21

04 Mar '21

when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory. ------------- Commit messages: - JDK-8261518: jpackage looks for main module in current dir when there is no module-path - JDK-8261518: jpackage looks for main module in current dir when there is no module-path Changes: https://git.openjdk.java.net/jdk/pull/2781/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2781&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261518 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2781.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2781/head:pull/2781 PR: https://git.openjdk.java.net/jdk/pull/2781

4 16

RFR: 8262927: Explicitly state fields examined for BigDecimal.hashCode
by Joe Darcy 03 Mar '21

03 Mar '21

The class BigDecimal can be and sometimes is subclassed. The spec of BigDecimal.hashCode is improved slightly by explicitly stating it is a function of the unscaled value and the scale of the BigDecimal, the same fields examined by equals. It is a conscious choice to *not* explicitly state what the exact hash function is. As the behavior of hashCode is mostly implied from equals, I don't think a CSR is necessary in this case. ------------- Commit messages: - 8262927: Explicitly state fields examined for BigDecimal.hashCode Changes: https://git.openjdk.java.net/jdk/pull/2817/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2817&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262927 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2817.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2817/head:pull/2817 PR: https://git.openjdk.java.net/jdk/pull/2817

2 2

RFR: 8166026: Refactor java/lang shell tests to java
by Ivan Šipka 03 Mar '21

03 Mar '21

Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. ------------- Commit messages: - 8166026: Refactor java/lang shell tests to java Changes: https://git.openjdk.java.net/jdk/pull/1577/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8166026 Stats: 501 lines in 6 files changed: 196 ins; 305 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577

4 31

RFR: 8261862: Expand discussion of rationale for BigDecimal equals/compareTo semantics
by Joe Darcy 03 Mar '21

03 Mar '21

I considered @stuart-marks previous suggestion during the code review of JDK-8261123 to include a more explicit discussion of why, say, different representations of 2 should not be regarded as equivalent. After contemplating several alternatives, I didn't find anything simpler than Stuart's 2/3 example so I used that as seen in the diff. A short digression, BigDecimal supports both fixed-point style and floating-point style rounding. Floating-point rounding primarily replies on the number of precision digits, regards of their scale, while fixed-point style rounding prioritizes the scale. The number of digits of eventual output is a function of number number of digits in the inputs and the number of precision digits in a floating-point style rounding. A floating-point style rounding has a preferred scale, rather than a fixed scale based on the inputs. The fixed-point style divide method used in the example has a scale based on the dividend, allowing a relatively simple expression to show a distinction between 2.0 and 2.00. ------------- Commit messages: - 8261862: Expand discussion of rationale for BigDecimal equals/compareTo semantics Changes: https://git.openjdk.java.net/jdk/pull/2804/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2804&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261862 Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2804.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2804/head:pull/2804 PR: https://git.openjdk.java.net/jdk/pull/2804

3 7