Re: RFR: 8276084: Linux DEB Bundler: release number in outputted .deb file should be optional
On Thu, 11 Nov 2021 04:07:18 GMT, Alexey Semenyuk wrote: > 8276084: Linux DEB Bundler: release number in outputted .deb file should be > optional Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6345
Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v3]
On Fri, 12 Nov 2021 19:11:07 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should >> start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Force the jnu encoding to UTF-8 if the original one is not supported I reproduced those failures on Debian Linux. Corrected the issue by replacing unsupported jnu encoding with `UTF-8` in `System::initPhase1`. - PR: https://git.openjdk.java.net/jdk/pull/6282
Re: RFR: 8276609: Document setting property `jdk.serialFilter` to an invalid value throws `ExceptionInInitializerError`
On Tue, 9 Nov 2021 15:48:22 GMT, Roger Riggs wrote: > When set on the command line `jdk.serialFilter` to an invalid value, the > invalid value is logged but the application is allowed to start without > setting the filter. > This leaves the application without the protections of the serial filter. > The specification should be clarify that an `ExceptionInInitializerError` is > thrown when the `jdk.serialFilter` system property is set on the command line > to an invalid value. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6317
Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v3]
> Please review the subject fix. In light of JEP400, Java runtime can/should > start in UTF-8 charset if the underlying native encoding is not supported. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Force the jnu encoding to UTF-8 if the original one is not supported - Changes: - all: https://git.openjdk.java.net/jdk/pull/6282/files - new: https://git.openjdk.java.net/jdk/pull/6282/files/d3c240c9..c50e6279 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6282=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6282=01-02 Stats: 12 lines in 1 file changed: 8 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6282.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6282/head:pull/6282 PR: https://git.openjdk.java.net/jdk/pull/6282
Re: RFR: 8277013: Allow creation of module graphs without defining modules to the VM
On Thu, 11 Nov 2021 14:53:13 GMT, Ivan Ristović wrote: > Related JBS issue: https://bugs.openjdk.java.net/browse/JDK-8277013 > > The GraalVM Native Image module support must create the runtime boot-module > layer at image build time; module instances created at build time need to > reflect module relations at runtime, i.e., their opens, reads, and exports. > To achieve this, we had to duplicate and modify a significant portion of the > module synthesis methods from the JDK. The GraalVM PR that demonstrates this > duplication can be found at: > > https://github.com/oracle/graal/blob/9bfa3a312d7d0309eb014d52e49afd7136d9e77e/substratevm/src/com.oracle.svm.hosted.jdk11/src/com/oracle/svm/hosted/ModuleLayerFeature.java#L269 > > The hard-to-maintain code duplication is necessary as synthesizing module > graphs in the JDK unconditionally defines modules to the VM which causes an > error due to module redefinition. For example, methods `System.defineModule`, > `ModuleLayer` factories and constructor, and `Module` constructor > unconditionally update the VM state. All these methods eventually reach the > `Module` constructor or the `Modules.defineModules` method. > > We propose that the `Module` constructor and the `Modules.defineModules` > conditionally update the VM state (similarly to 'Module.implAddReads`). The > JDK would call these methods so they update the VM state and GraalVM Native > Image would call them without updating the state. The internal API for modules already allows conditional VM updates used for white-box testing (e.g., `Module.implAddReadsNoSync()` and `Module.implAddExportsNoSync()`). This PR adds similar functionality to the module constructor and the module graph synthesizer and as such is quite consistent with the existing code. Would the appropriate cleanup be to add white-box tests for the newly added methods? This would increase the test coverage, and at the same time avoid bit rot of the methods that Native Image requires? - PR: https://git.openjdk.java.net/jdk/pull/6356
Re: RFR: 8277059: Use blessed modifier order in java.xml
On Fri, 12 Nov 2021 15:06:35 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source code in java.xml and > java.xml.crypto. This scripts verifies that modifiers are in the "blessed" > order, and fixes it otherwise. I have manually checked the changes made by > the script to make sure they are sound. Thanks, Magnus. However, we've discussed the issue for sources from the 3rd party, and we'd like it keep it that way to facilitate any future merges. Refer to JDK-8264019 / https://github.com/openjdk/jdk/pull/3091. - PR: https://git.openjdk.java.net/jdk/pull/6369
Re: RFR: 8277048: Tiny improvements to the specification text for java.util.Properties.load
On Fri, 12 Nov 2021 12:25:20 GMT, Pavel Rappo wrote: > Please review this simple two-hunk fix to the documentation comment of > java.util.Properties#load(java.io.Reader). The first hunk (line/lines) is a > suggestion. I believe it reads better since the plurality is more idiomatic; > native English speakers should correct me if I'm wrong. The second hunk picks > up what was overlooked in JDK-8274075 > (https://git.openjdk.java.net/jdk/pull/5610). Marked as reviewed by naoto (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6367
Re: RFR: 8276084: Linux DEB Bundler: release number in outputted .deb file should be optional
On Thu, 11 Nov 2021 04:07:18 GMT, Alexey Semenyuk wrote: > 8276084: Linux DEB Bundler: release number in outputted .deb file should be > optional @andyherrick please review - PR: https://git.openjdk.java.net/jdk/pull/6345
Re: RFR: 8274856: Failing jpackage tests with fastdebug/release build
On Fri, 5 Nov 2021 19:58:01 GMT, Alexey Semenyuk wrote: > The fix is to isolate C++ calls in the separate forked child process on > Linux. > This change requires the passing of JLI command line arguments and values of > environment variables between two processes. @andyherrick please review - PR: https://git.openjdk.java.net/jdk/pull/6283
Re: RFR: 8276084: Linux DEB Bundler: release number in outputted .deb file should be optional
On Thu, 11 Nov 2021 04:07:18 GMT, Alexey Semenyuk wrote: > 8276084: Linux DEB Bundler: release number in outputted .deb file should be > optional @sashamatveev please review - PR: https://git.openjdk.java.net/jdk/pull/6345
Re: RFR: 8277015: Use blessed modifier order in Panama code
On Fri, 12 Nov 2021 11:13:24 GMT, Maurizio Cimadamore wrote: >>> You could also do this directly in the Panama repo branches. I'll volunteer >>> to help, if you want. >> >> I'll run the script on the PR I've submitted for the Foreign API, and I will >> update that one - thanks. Perhaps @PaulSandoz can do the same for the Vector >> API refresh? > >> > You could also do this directly in the Panama repo branches. I'll >> > volunteer to help, if you want. >> >> I'll run the script on the PR I've submitted for the Foreign API, and I will >> update that one - thanks. Perhaps @PaulSandoz can do the same for the Vector >> API refresh? > > Done - the jdk.incubator.foreign changes are now part of > https://github.com/openjdk/jdk/pull/5907 > @mcimadamore Thanks! > > @PaulSandoz I'll keep this PR open until after the integration is done, and > check if or what parts are still needed after that. I don't want to mess up > your integration with trivia like this. (Had I realized the bad timing I > would have waited before opening this PR) Thanks, integration should happen to today, then i can help guide you on what to update. - PR: https://git.openjdk.java.net/jdk/pull/6355
Re: RFR: 8277048: Tiny improvements to the specification text for java.util.Properties.load
On Fri, 12 Nov 2021 12:25:20 GMT, Pavel Rappo wrote: > Please review this simple two-hunk fix to the documentation comment of > java.util.Properties#load(java.io.Reader). The first hunk (line/lines) is a > suggestion. I believe it reads better since the plurality is more idiomatic; > native English speakers should correct me if I'm wrong. The second hunk picks > up what was overlooked in JDK-8274075 > (https://git.openjdk.java.net/jdk/pull/5610). Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6367
Re: RFR: 8276609: Document setting property `jdk.serialFilter` to an invalid value throws `ExceptionInInitializerError`
On Wed, 10 Nov 2021 02:06:42 GMT, Jaikiran Pai wrote:
>> When set on the command line `jdk.serialFilter` to an invalid value, the
>> invalid value is logged but the application is allowed to start without
>> setting the filter.
>> This leaves the application without the protections of the serial filter.
>> The specification should be clarify that an `ExceptionInInitializerError` is
>> thrown when the `jdk.serialFilter` system property is set on the command
>> line to an invalid value.
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 528:
>
>> 526: * The filter is created as if {@link #createFilter(String)
>> createFilter} is called;
>> 527: * if the filter string is invalid, an {@link
>> ExceptionInInitializerError} is thrown.
>> 528: * Otherwise, the filter is not configured during initialization and
>
> Hello Roger, the new line looks good to me. However, with this new line now
> staying between the "If the Java virtual machine ..." and the "Otherwise,
> ..." lines, I had to re-read this "Otherwise, the filter is not ..." line a
> few times to see which "if" it corresponds to, because there's a "if the
> filter string is invalid" on the previous line.
> Do you think these lines might have to be rearranged?
Good suggestion, I'll take that up in a new issue related to incomplete
initialization.
-
PR: https://git.openjdk.java.net/jdk/pull/6317
Re: RFR: 8276609: Document setting property `jdk.serialFilter` to an invalid value throws `ExceptionInInitializerError`
On Tue, 9 Nov 2021 15:48:22 GMT, Roger Riggs wrote: > When set on the command line `jdk.serialFilter` to an invalid value, the > invalid value is logged but the application is allowed to start without > setting the filter. > This leaves the application without the protections of the serial filter. > The specification should be clarify that an `ExceptionInInitializerError` is > thrown when the `jdk.serialFilter` system property is set on the command line > to an invalid value. Marked as reviewed by dfuchs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6317
Integrated: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File
On Wed, 10 Nov 2021 20:51:20 GMT, Lance Andersen wrote: > Hi all, > > This patch addresses a regression introduced in JDK 15 via JDK-8242959 where > you can no longer access a file entry contained within a Zip file when there > is also a directory entry with the same name via ZipFile:getEntry(). > > Once fixed, the behavior will be consistent with earlier JDK releases. > > Mach5 tiers 1-3 have been run without failure > > Best > Lance This pull request has now been integrated. Changeset: b85500e5 Author:Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/b85500e52479c48b02a96b28fddefa2b25d5d9bd Stats: 594 lines in 2 files changed: 589 ins; 3 del; 2 mod 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File Reviewed-by: redestad, alanb - PR: https://git.openjdk.java.net/jdk/pull/6342
Integrated: 8274835: Remove unnecessary castings in java.base
On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov wrote: > Redundant castings make code harder to read. > Found them by IntelliJ IDEA. > I tried to select only casts which are definitely safe to remove. Also didn't > touch primitive types casts. This pull request has now been integrated. Changeset: 5a2452c8 Author:Andrey Turbanov Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/5a2452c80e64b8b7a1799caa1a8a6e9e6a7dab6d Stats: 36 lines in 15 files changed: 1 ins; 4 del; 31 mod 8274835: Remove unnecessary castings in java.base Reviewed-by: mullan, naoto, lancea, bpb - PR: https://git.openjdk.java.net/jdk/pull/5454
Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v8]
> Sorting: > > - adopt radix sort for sequential and parallel sorts on int/long/float/double > arrays (almost random and length > 6K) > - fix tryMergeRuns() to better handle case when the last run is a single > element > - minor javadoc and comment changes > > Testing: > - add new data inputs in tests for sorting > - add min/max/infinity values to float/double testing > - add tests for radix sort iaroslavski has updated the pull request incrementally with one additional commit since the last revision: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) - Set limit for buffer length - Radix sort is invoked on fully random data - Use 3 steps in Radix sort isntead of 4 for int/float - Set better options for parallel sorting - Changes: - all: https://git.openjdk.java.net/jdk/pull/3938/files - new: https://git.openjdk.java.net/jdk/pull/3938/files/ee7f6e82..e1b01cfb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3938=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3938=06-07 Stats: 182 lines in 2 files changed: 46 ins; 59 del; 77 mod Patch: https://git.openjdk.java.net/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.java.net/jdk/pull/3938
RFR: 8277059: Use blessed modifier order in java.xml
I ran bin/blessed-modifier-order.sh on source code in java.xml and java.xml.crypto. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. - Commit messages: - 8277059: Use blessed modifier order in java.xml Changes: https://git.openjdk.java.net/jdk/pull/6369/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6369=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277059 Stats: 505 lines in 140 files changed: 0 ins; 0 del; 505 mod Patch: https://git.openjdk.java.net/jdk/pull/6369.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6369/head:pull/6369 PR: https://git.openjdk.java.net/jdk/pull/6369
Re: RFR: JDK-8274685 - Documentation suggests there are ArbitrarilyJumpableGenerator when none
On Thu, 11 Nov 2021 13:34:21 GMT, Jim Laskey wrote: > "There is also an interface RandomGenerator.ArbitrarilyJumpableGenerator for > algorithms that allow jumping along the state cycle by any user-specified > distance. In this package, implementations of these interfaces include > "Xoroshiro128PlusPlus", and "Xoshiro256PlusPlus" is incorrect. > "Xoroshiro128PlusPlus", and "Xoshiro256PlusPlus" are actually > RandomGenerator.JumpableGenerator. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6349
Re: RFR: JDK-8277003 - JumpableGenerator.rngs() documentation refers to wrong method
On Thu, 11 Nov 2021 13:54:37 GMT, Jim Laskey wrote: > Documentation in `RandomGenerator.rngs()` refers to > `JumpableGenerator.jump()` when it should be `JumpableGenerator.jumps()` The change is ok but you'll need to update the title to refer to the original issue: JDK-8273792 The CSR can't be used for the commit. - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6352
Re: RFR: 8277048: Tiny improvements to the specification text for java.util.Properties.load
On Fri, 12 Nov 2021 12:25:20 GMT, Pavel Rappo wrote: > Please review this simple two-hunk fix to the documentation comment of > java.util.Properties#load(java.io.Reader). The first hunk (line/lines) is a > suggestion. I believe it reads better since the plurality is more idiomatic; > native English speakers should correct me if I'm wrong. The second hunk picks > up what was overlooked in JDK-8274075 > (https://git.openjdk.java.net/jdk/pull/5610). Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6367
Re: RFR: 8277015: Use blessed modifier order in Panama code
On Fri, 12 Nov 2021 11:13:24 GMT, Maurizio Cimadamore wrote: >>> You could also do this directly in the Panama repo branches. I'll volunteer >>> to help, if you want. >> >> I'll run the script on the PR I've submitted for the Foreign API, and I will >> update that one - thanks. Perhaps @PaulSandoz can do the same for the Vector >> API refresh? > >> > You could also do this directly in the Panama repo branches. I'll >> > volunteer to help, if you want. >> >> I'll run the script on the PR I've submitted for the Foreign API, and I will >> update that one - thanks. Perhaps @PaulSandoz can do the same for the Vector >> API refresh? > > Done - the jdk.incubator.foreign changes are now part of > https://github.com/openjdk/jdk/pull/5907 @mcimadamore Thanks! @PaulSandoz I'll keep this PR open until after the integration is done, and check if or what parts are still needed after that. I don't want to mess up your integration with trivia like this. (Had I realized the bad timing I would have waited before opening this PR) - PR: https://git.openjdk.java.net/jdk/pull/6355
Re: RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File [v2]
On Thu, 11 Nov 2021 17:19:04 GMT, Lance Andersen wrote: >> Hi all, >> >> This patch addresses a regression introduced in JDK 15 via JDK-8242959 where >> you can no longer access a file entry contained within a Zip file when there >> is also a directory entry with the same name via ZipFile:getEntry(). >> >> Once fixed, the behavior will be consistent with earlier JDK releases. >> >> Mach5 tiers 1-3 have been run without failure >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional > commit since the last revision: > > Address minor review comments Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6342
RFR: 8277048: Tiny improvements to the specification text for java.util.Properties.load
Please review this simple two-hunk fix to the documentation comment of java.util.Properties#load(java.io.Reader). The first hunk (line/lines) is a suggestion. I believe it reads better since the plurality is more idiomatic; native English speakers should correct me if I'm wrong. The second hunk picks up what was overlooked in JDK-8274075 (https://git.openjdk.java.net/jdk/pull/5610). - Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/6367/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6367=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277048 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6367.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6367/head:pull/6367 PR: https://git.openjdk.java.net/jdk/pull/6367
Re: RFR: 8277015: Use blessed modifier order in Panama code
On Thu, 11 Nov 2021 21:34:17 GMT, Maurizio Cimadamore wrote: > > You could also do this directly in the Panama repo branches. I'll volunteer > > to help, if you want. > > I'll run the script on the PR I've submitted for the Foreign API, and I will > update that one - thanks. Perhaps @PaulSandoz can do the same for the Vector > API refresh? Done - the jdk.incubator.foreign changes are now part of https://github.com/openjdk/jdk/pull/5907 - PR: https://git.openjdk.java.net/jdk/pull/6355
Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v24]
> This PR contains the API and implementation changes for JEP-419 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Adopt blessed modofier order - Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/8c3860f8..79d3d685 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5907=23 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5907=22-23 Stats: 7 lines in 6 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907
Always false condition in jdk.internal.jrtfs.JrtFileSystem#getPathMatcher
Hello.
I found suspicious condition in implementation of method
JrtFileSystem.getPathMatcher(String)
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java#L178
public PathMatcher getPathMatcher(String syntaxAndInput) {
int pos = syntaxAndInput.indexOf(':');
if (pos <= 0 || pos == syntaxAndInput.length()) {
throw new IllegalArgumentException("pos is " + pos);
}
Variable pos is a result of String.indexOf(char) call. It is compared
with the length() of the same String.
This condition 'pos == syntaxAndInput.length()' will always be false:
String.indexOf() can't return any value greater than length()-1.
Perhaps it was intended to be 'pos == syntaxAndInput.length() - 1'?
BTW, I think exception message could be improved. Current message 'pos
is -1' is not user friendly.
Andrey Turbanov
