Re: RFR: JDK-8326951 Missing @since Tags [v4]
> I added `@since` tags for methods/constructors that do not match the `@since` > of the enclosing class. > > The `write` method already existed in `PrintStream` in earlier versions and > instances of it could always call this method, since it extends > `FilterOutputStream` [which has the > method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96). Nizar Benalla has updated the pull request incrementally with three additional commits since the last revision: - update the copyright year to 2024 - Revert "update the copyright year to 2024" This reverts commit 9ddd230dcf88bedade76a8e2804db6e120a200f8. - update the copyright year to 2024 - Changes: - all: https://git.openjdk.org/jdk/pull/18055/files - new: https://git.openjdk.org/jdk/pull/18055/files/3cec63e9..7d6e969e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18055=03 - incr: https://webrevs.openjdk.org/?repo=jdk=18055=02-03 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/18055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18055/head:pull/18055 PR: https://git.openjdk.org/jdk/pull/18055
Re: RFR: JDK-8326836 Incorrect @since Tags for ClassSignature methods [v2]
> # Issue > - [JDK-8326836](https://bugs.openjdk.org/browse/JDK-8326836): changes were > made to the method signatures but this modification isn't reflected in the @ > since tags. The @ since tags need to be updated. > > I changed the @\since tags to better accurately show when the methods were > introduced. Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: update the copyright year to 2024 - Changes: - all: https://git.openjdk.org/jdk/pull/18030/files - new: https://git.openjdk.org/jdk/pull/18030/files/0d857db4..8c0c7122 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18030=01 - incr: https://webrevs.openjdk.org/?repo=jdk=18030=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18030.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18030/head:pull/18030 PR: https://git.openjdk.org/jdk/pull/18030
Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v7]
> This code change adds an alternative implementation of user-based > authorization `Subject` APIs that doesn't depend on Security Manager APIs. > Depending on if the Security Manager is allowed, the methods store the > current subject differently. See the spec change in the `Subject.java` file > for details. When the Security Manager APIs are finally removed in a future > release, this new implementation will be only implementation for these > methods. > > One major change in the new implementation is that `Subject.getSubject` > always throws an `UnsupportedOperationException` since it has an > `AccessControlContext` argument but the current subject is no longer > associated with an `AccessControlContext` object. > > Now it's the time to migrate from the `getSubject` and `doAs` methods to > `current` and `callAs`. If the user application is simply calling > `getSubject(AccessController.getContext())`, then switching to `current()` > would work. If the `AccessControlContext` argument is retrieved from an > earlier `getContext()` call and the associated subject might be different > from that of the current `AccessControlContext`, then instead of storing the > previous `AccessControlContext` object and passing it into `getSubject` to > get the "previous" subject, the application should store the `current()` > return value directly. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - years and comments - Merge branch 'master' into 8296244 - revert changes to MBeanServerFileAccessController.java - Merge branch 'master' into 8296244 - revert some test changes, spec change for subject - fix MBeanServerFileAccessController, more test in SM - JMX needs SM - Resolve Alan's comments - remove exe bits - remove x bit - ... and 1 more: https://git.openjdk.org/jdk/compare/bb164794...dfa22af0 - Changes: - all: https://git.openjdk.org/jdk/pull/17472/files - new: https://git.openjdk.org/jdk/pull/17472/files/80810b54..dfa22af0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17472=06 - incr: https://webrevs.openjdk.org/?repo=jdk=17472=05-06 Stats: 384142 lines in 1493 files changed: 18191 ins; 81433 del; 284518 mod Patch: https://git.openjdk.org/jdk/pull/17472.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472 PR: https://git.openjdk.org/jdk/pull/17472
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Tue, 19 Mar 2024 22:19:50 GMT, David Holmes wrote: >> In fact, it appears as if the problem is with the use of "any", which is >> universal in strength, whereas the intention here is existential in strength >> (as suggested by. my wording). Indeed, you might achieve the same effect by >> replacing "any" with "some" so that: >> >> "An object is reachable if it can be accessed in some continuing computation >> from some live thread." >> >> You needn't even say live because dead threads can neither take steps nor >> continue participating in the computation nor can they "access" objects for >> whatever informal notion of access. The "some continuing computation" >> subsumes "potential" (as in a possible future) so potential can be dropped. > > I think you are overthinking this somewhat Ramki. I don't see a practical > (non discrete-math) distinction between "some" and "any", so would not object > to that single word change if it helps. But "potential" should remain as it > covers branching in the program whereby if we proceed down one branch an > object remains reachable, whereas if we precede down another then it may not. I don't think changing "any" to "some" is helpful. I think "any" is ambiguous regarding meaning universal or existential strength. The sense used here is, considering the possible future execution paths of a thread, if any of them accesses the object, that object is reachable. In other words, it means "any one" and not "all". - PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1531198317
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Tue, 19 Mar 2024 16:38:49 GMT, Y. Srinivas Ramakrishna wrote: >> Sorry, my use of words was sloppy here. I think I did mean loose or somewhat >> informal and therefore slippery. >> >> What I was saying is that using terms such as "any continuing computation" >> doesn't make sense because this is referring to a current state of the >> computation. I'm not sure what "any continuing computation" from a state is >> because the concept of what constitutes the notion of "a continuing >> computation" has not been defined before. To me it sounds like a computation >> tree with nodes as state and transitions as edges and a continuing >> computation as a path through that tree into the future. The way it is >> written then, it sounds to the naive reader, or to me at least, as if the >> object is perpetually reachable by every thread always. I assume I am >> misinterpreting the intention of the writing, but it sounds too loose for a >> definition being invoked here in the javadoc. May be it can be tightened up >> a bit. >> >> Could one state instead that "An object is reachable at a given state when >> some thread is able to access the object through a sequence of steps >> starting at that state without other threads taking any steps." ? Or >> something along those lines? Or at least something tighter than the current >> wording that is somewhat too loose. > > In fact, it appears as if the problem is with the use of "any", which is > universal in strength, whereas the intention here is existential in strength > (as suggested by. my wording). Indeed, you might achieve the same effect by > replacing "any" with "some" so that: > > "An object is reachable if it can be accessed in some continuing computation > from some live thread." > > You needn't even say live because dead threads can neither take steps nor > continue participating in the computation nor can they "access" objects for > whatever informal notion of access. The "some continuing computation" > subsumes "potential" (as in a possible future) so potential can be dropped. I think you are overthinking this somewhat Ramki. I don't see a practical (non discrete-math) distinction between "some" and "any", so would not object to that single word change if it helps. But "potential" should remain as it covers branching in the program whereby if we proceed down one branch an object remains reachable, whereas if we precede down another then it may not. - PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1531191269
Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v3]
> Moving array construction within BigInteger.implMultiplyToLen intrinsic > candidate to its caller simplifies the intrinsic implementation in JIT > compiler. Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision: address comment. - Changes: - all: https://git.openjdk.org/jdk/pull/18226/files - new: https://git.openjdk.org/jdk/pull/18226/files/bfc323b7..870a6127 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18226=02 - incr: https://webrevs.openjdk.org/?repo=jdk=18226=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18226/head:pull/18226 PR: https://git.openjdk.org/jdk/pull/18226
Re: RFR: 8327791: Optimization for new BigDecimal(String) [v10]
On Tue, 19 Mar 2024 12:12:30 GMT, Shaojin Wen wrote: >> I think splitting `CharArraySequence` into two versions is somewhat dubious >> as more observable types at call sites may mean the performance gain in >> targeted micros is lost. How much of an improvement did you observe from >> this? Again the `char[]` constructors is probably less performance sensitive >> than the others. > > @cl4es @jddarcy All feedback has been fixed, can it be integrated? @wenshao I'll take a look sometime this week. - PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-200708
Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v2]
On Tue, 19 Mar 2024 19:06:36 GMT, Yudi Zheng wrote: >> Moving array construction within BigInteger.implMultiplyToLen intrinsic >> candidate to its caller simplifies the intrinsic implementation in JIT >> compiler. > > Yudi Zheng has updated the pull request incrementally with one additional > commit since the last revision: > > address comment. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4670: > 4668: const Register tmp6 = r15; > 4669: const Register tmp7 = r16; > 4670: const Register tmp8 = r17; It looks like tmp8 is never used. The call to multiply_to_len() below needs to be adjusted. - PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1530986811
Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v2]
On Tue, 19 Mar 2024 19:06:36 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
> commit since the last revision:
>
> address comment.
src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 3559:
> 3557: Register tmp5, Register tmp6,
> Register product_hi, Register tmp8) {
> 3558:
> 3559: assert_different_registers(x, xlen, y, ylen, z, tmp1, tmp2, tmp3,
> tmp4, tmp5, tmp6, tmp8);
Suggestion:
assert_different_registers(x, xlen, y, ylen, z, tmp1, tmp2, tmp3, tmp4, tmp5,
tmp6, tmp8, product_hi);
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1530980566
Re: RFR: 8327791: Optimization for new BigDecimal(String) [v10]
On Tue, 12 Mar 2024 14:03:01 GMT, Claes Redestad wrote: >> Shaojin Wen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> restore comment > > I think splitting `CharArraySequence` into two versions is somewhat dubious > as more observable types at call sites may mean the performance gain in > targeted micros is lost. How much of an improvement did you observe from > this? Again the `char[]` constructors is probably less performance sensitive > than the others. > @cl4es @jddarcy All feedback has been fixed, can it be integrated? Hello @wenshao , This change will need additional review from myself or others who maintain BigDecimal before it can be integrated. - PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2007967764
Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v2]
> Moving array construction within BigInteger.implMultiplyToLen intrinsic > candidate to its caller simplifies the intrinsic implementation in JIT > compiler. Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision: address comment. - Changes: - all: https://git.openjdk.org/jdk/pull/18226/files - new: https://git.openjdk.org/jdk/pull/18226/files/37232a5f..bfc323b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18226=01 - incr: https://webrevs.openjdk.org/?repo=jdk=18226=00-01 Stats: 70 lines in 11 files changed: 8 ins; 28 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/18226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18226/head:pull/18226 PR: https://git.openjdk.org/jdk/pull/18226
Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v2]
On Mon, 18 Mar 2024 16:55:28 GMT, Damon Fenacci wrote: > Quite a simplification! Have you checked if there are any performance > differences? Ran https://github.com/oracle/graal/blob/master/compiler/src/org.graalvm.micro.benchmarks/src/micro/benchmarks/BigIntegerBenchmark.java The results are $ before change Benchmark Mode CntScore Error Units BigIntegerBenchmark.bigIntMontgomeryMul thrpt5 122.488 ± 0.130 ops/s BigIntegerBenchmark.bigIntMontgomerySqr thrpt5 76.023 ± 0.106 ops/s BigIntegerBenchmark.bigIntMulthrpt5 330.130 ± 0.349 ops/s BigIntegerBenchmark.bigIntMulAdd thrpt5 455.590 ± 0.663 ops/s $ after change Benchmark Mode CntScore Error Units BigIntegerBenchmark.bigIntMontgomeryMul thrpt5 124.407 ± 0.045 ops/s BigIntegerBenchmark.bigIntMontgomerySqr thrpt5 76.036 ± 0.232 ops/s BigIntegerBenchmark.bigIntMulthrpt5 329.836 ± 0.953 ops/s BigIntegerBenchmark.bigIntMulAdd thrpt5 456.485 ± 0.766 ops/s - PR Comment: https://git.openjdk.org/jdk/pull/18226#issuecomment-2007922439
Re: CFV: New Core Libraries Group Member: Per-Ake Minborg
Vote: yes Mandy On 3/19/24 8:19 AM, Daniel Fuchs wrote: Hi, I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the Core Libraries Group [4]. Per-Ake is an OpenJDK Reviewer, a committer in the Leyden and Panama projects, and a member of Oracle’s Java Core Libraries team. Per-Ake has been actively participating in the development of the JDK and Panama projects for several years, and is one of the co-author of the Implementation of Foreign Function and Memory API (Third Preview) [2]. His contributions include more than 80 commits in the JDK [3] Votes are due by 16:00 UTC on April 2, 2024. Only current Members of the Core Libraries Group [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. best regards, -- daniel [1] https://openjdk.org/census#pminborg [2] https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d [3] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg=commits [4] https://openjdk.org/census#core-libs [5] https://openjdk.org/groups/#member-vote
Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v23]
On Tue, 19 Mar 2024 16:55:14 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >> install might not come with the packaged modules (directory `jmods`). This >> is particularly useful to further reduce the size of a jlinked runtime. >> After the removal of the concept of a JRE, a common distribution mechanism >> is still the full JDK with all modules and packaged modules. However, >> packaged modules can incur an additional size tax. For example in a >> container scenario it could be useful to have a base JDK container including >> all modules, but without also delivering the packaged modules. This comes at >> a size advantage of `~25%`. Such a base JDK container could then be used to >> `jlink` application specific runtimes, further reducing the size of the >> application runtime image (App + JDK runtime; as a single image *or* >> separate bundles, depending on the app being modularized). >> >> The basic design of this approach is to add a jlink plugin for tracking >> non-class and non-resource files of a JDK install. I.e. files which aren't >> present in the jimage (`lib/modules`). This enables producing a `JRTArchive` >> class which has all the info of what constitutes the final jlinked runtime. >> >> Basic usage example: >> >> $ diff -u <(./bin/java --list-modules --limit-modules java.se) >> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules >> --limit-modules java.se) >> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) >> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules >> --limit-modules jdk.jlink) >> $ ls ../linux-x86_64-server-release/images/jdk/jmods >> java.base.jmodjava.net.http.jmod java.sql.rowset.jmod >> jdk.crypto.ec.jmod jdk.internal.opt.jmod >> jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod >> java.compiler.jmodjava.prefs.jmod java.transaction.xa.jmod >> jdk.dynalink.jmod jdk.internal.vm.ci.jmod >> jdk.jdwp.agent.jmod jdk.management.jfr.jmodjdk.security.jgss.jmod >> java.datatransfer.jmodjava.rmi.jmodjava.xml.crypto.jmod >> jdk.editpad.jmod jdk.internal.vm.compiler.jmod >> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod >> java.desktop.jmod java.scripting.jmod java.xml.jmod >> jdk.hotspot.agent.jmod jdk.i... > > Severin Gehwolf has updated the pull request incrementally with one > additional commit since the last revision: > > Move CreateLinkableRuntimePlugin to build folder > > Keep runtime link supporting classes in package > jdk.tools.jlink.internal.runtimelink Thanks for the details.I feel the pain in extending jlink for this work as the current jlink implementation is not easily understandable and has been yearning for rewrite in my perspective (looking forward to Project Leyden's condenser model). Really appreciate your effort for this. IIUC, the main issue is regarding extending an jimage with additional entries in the same compression level. The other option is to add the diffs as a separate file in the JDK image under `lib` instead of part of the jimage. The per-module mapping metadata files can be generated as part of the normal linking as the footprint is small. Would that simplify it? I think the other issues may be solvable. - PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2007823095
Re: CFV: New Core Libraries Group Member: Per-Ake Minborg
Vote: Yes On 3/19/24 11:19 AM, Daniel Fuchs wrote: I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the Core Libraries Group [4].
Re: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v8]
On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla wrote: >> # Issue >> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in >> JDK 10 >> >> I changed the @\since tags to better accurately show when the methods and >> constructors were introduced. > > Nizar Benalla has updated the pull request incrementally with two additional > commits since the last revision: > > - update the copyright year to 2024 > - Revert "update the latter years for the Oracle copyrights" > >This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64. Thank you justin - PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2007813492
Re: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
> This task addresses an essential aspect of our testing infrastructure: the > proper handling and cleanup of temporary files and socket files created > during test execution. The motivation behind these changes is to prevent the > accumulation of unnecessary files in the default temporary directory, which > can affect the system's storage and potentially influence subsequent test > runs. > > Our review identified that several tests create temporary files or socket > files without ensuring their removal post-execution. > - Direct calls to java.io.File.createTempFile and > java.nio.file.Files.createTempFile without adequate cleanup. > - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not > explicitly removing socket files post-use. Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Implemented review comments - Changes: - all: https://git.openjdk.org/jdk/pull/18352/files - new: https://git.openjdk.org/jdk/pull/18352/files/8472c31f..620f9259 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18352=01 - incr: https://webrevs.openjdk.org/?repo=jdk=18352=00-01 Stats: 136 lines in 5 files changed: 36 ins; 13 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/18352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352 PR: https://git.openjdk.org/jdk/pull/18352
Re: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v8]
On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla wrote: >> # Issue >> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in >> JDK 10 >> >> I changed the @\since tags to better accurately show when the methods and >> constructors were introduced. > > Nizar Benalla has updated the pull request incrementally with two additional > commits since the last revision: > > - update the copyright year to 2024 > - Revert "update the latter years for the Oracle copyrights" > >This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64. Change looks good to me, but you will need someone with reviewer status to sponsor your changes before you can integrate them. BTW, I also added a `noreg-doc` label to your JBS issue, which just means that no tests are needed for this change as it is a documentation only change. - Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/18032#pullrequestreview-1946933024
Re: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v7]
On Tue, 19 Mar 2024 17:05:50 GMT, Nizar Benalla wrote: >> src/java.base/share/classes/java/nio/channels/Channels.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2000, 2023, 2024, Oracle and/or its affiliates. All >>> rights reserved. >> >> Thanks for updating, but needs a little adjustment. >> >> Rather than adding a third year, the format should be: "original year, >> current year, Oracle ..." >> So in this case -> `2000, 2024,` > > Thanks for the explanation, I have fixed it. > I have a couple other similar PRs, is the policy to update the copyright year > every time a file is changed? whether it's an addition or removal of code? Yes, you should update the copyright year to the current year if you make a change to the file, regardless if the change itself is "significant" or not. Note that there are two formats: `Year1, Year2, Oracle` and `Year, Oracle`. The latter would be used if say you added a new file in 2024. - PR Review Comment: https://git.openjdk.org/jdk/pull/18032#discussion_r1530792055
Re: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v7]
On Tue, 19 Mar 2024 16:13:49 GMT, Justin Lu wrote: >> Nizar Benalla has updated the pull request incrementally with one additional >> commit since the last revision: >> >> update the latter years for the Oracle copyrights > > src/java.base/share/classes/java/nio/channels/Channels.java line 2: > >> 1: /* >> 2: * Copyright (c) 2000, 2023, 2024, Oracle and/or its affiliates. All >> rights reserved. > > Thanks for updating, but needs a little adjustment. > > Rather than adding a third year, the format should be: "original year, > current year, Oracle ..." > So in this case -> `2000, 2024,` Thanks for the explanation, I have fixed it. I have a couple other similar PRs, is the policy to update the copyright year every time a file is changed? whether it's an addition or removal of code? - PR Review Comment: https://git.openjdk.org/jdk/pull/18032#discussion_r1530770401
Re: CFV: New Core Libraries Group Member: Per-Ake Minborg
Vote: yes Joe (joehw) On 3/19/24 8:19 AM, Daniel Fuchs wrote: Hi, I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the Core Libraries Group [4].
Re: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v8]
> # Issue > - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK > 10 > > I changed the @\since tags to better accurately show when the methods and > constructors were introduced. Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: - update the copyright year to 2024 - Revert "update the latter years for the Oracle copyrights" This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64. - Changes: - all: https://git.openjdk.org/jdk/pull/18032/files - new: https://git.openjdk.org/jdk/pull/18032/files/8bcc364f..56968dcd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18032=07 - incr: https://webrevs.openjdk.org/?repo=jdk=18032=06-07 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032 PR: https://git.openjdk.org/jdk/pull/18032
Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v23]
> Please review this patch which adds a jlink mode to the JDK which doesn't > need the packaged modules being present. A.k.a run-time image based jlink. > Fundamentally this patch adds an option to use `jlink` even though your JDK > install might not come with the packaged modules (directory `jmods`). This is > particularly useful to further reduce the size of a jlinked runtime. After > the removal of the concept of a JRE, a common distribution mechanism is still > the full JDK with all modules and packaged modules. However, packaged modules > can incur an additional size tax. For example in a container scenario it > could be useful to have a base JDK container including all modules, but > without also delivering the packaged modules. This comes at a size advantage > of `~25%`. Such a base JDK container could then be used to `jlink` > application specific runtimes, further reducing the size of the application > runtime image (App + JDK runtime; as a single image *or* separate bundles, > depending on the app b eing modularized). > > The basic design of this approach is to add a jlink plugin for tracking > non-class and non-resource files of a JDK install. I.e. files which aren't > present in the jimage (`lib/modules`). This enables producing a `JRTArchive` > class which has all the info of what constitutes the final jlinked runtime. > > Basic usage example: > > $ diff -u <(./bin/java --list-modules --limit-modules java.se) > <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules > --limit-modules java.se) > $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) > <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules > --limit-modules jdk.jlink) > $ ls ../linux-x86_64-server-release/images/jdk/jmods > java.base.jmodjava.net.http.jmod java.sql.rowset.jmod > jdk.crypto.ec.jmod jdk.internal.opt.jmod > jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod > java.compiler.jmodjava.prefs.jmod java.transaction.xa.jmod > jdk.dynalink.jmod jdk.internal.vm.ci.jmod > jdk.jdwp.agent.jmod jdk.management.jfr.jmodjdk.security.jgss.jmod > java.datatransfer.jmodjava.rmi.jmodjava.xml.crypto.jmod > jdk.editpad.jmod jdk.internal.vm.compiler.jmod > jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod > java.desktop.jmod java.scripting.jmod java.xml.jmod > jdk.hotspot.agent.jmod jdk.internal.vm.compiler.manage... Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Move CreateLinkableRuntimePlugin to build folder Keep runtime link supporting classes in package jdk.tools.jlink.internal.runtimelink - Changes: - all: https://git.openjdk.org/jdk/pull/14787/files - new: https://git.openjdk.org/jdk/pull/14787/files/e25dd440..5a6d2e4f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14787=22 - incr: https://webrevs.openjdk.org/?repo=jdk=14787=21-22 Stats: 29 lines in 12 files changed: 14 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/14787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787 PR: https://git.openjdk.org/jdk/pull/14787
Re: CFV: New Core Libraries Group Member: Per-Ake Minborg
Vote: yes On 3/19/2024 8:19 AM, Daniel Fuchs wrote: Hi, I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the Core Libraries Group [4]. Per-Ake is an OpenJDK Reviewer, a committer in the Leyden and Panama projects, and a member of Oracle’s Java Core Libraries team. Per-Ake has been actively participating in the development of the JDK and Panama projects for several years, and is one of the co-author of the Implementation of Foreign Function and Memory API (Third Preview) [2]. His contributions include more than 80 commits in the JDK [3] Votes are due by 16:00 UTC on April 2, 2024. Only current Members of the Core Libraries Group [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. best regards, -- daniel [1] https://openjdk.org/census#pminborg [2] https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d [3] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg=commits [4] https://openjdk.org/census#core-libs [5] https://openjdk.org/groups/#member-vote
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Tue, 19 Mar 2024 16:20:55 GMT, Y. Srinivas Ramakrishna wrote: >> https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.html#jls-12.6.1 >> >>> A reachable object is any object that can be accessed in any potential >>> continuing computation from any live thread. >> >> It may be "loose" because the devil is in the details when it comes to >> reachability, but I disagree that it is "sloppy". This expresses >> reachability in simple terms, as a "first-order" or "Newtonian" model. There >> are of course "Quantum" effects that need to be dealt with in practice. The >> JLS alludes to this with: >>> Optimizing transformations of a program can be designed that reduce the >>> number of objects that are reachable to be less than those which would >>> naively be considered reachable. > > Sorry, my use of words was sloppy here. I think I did mean loose or somewhat > informal and therefore slippery. > > What I was saying is that using terms such as "any continuing computation" > doesn't make sense because this is referring to a current state of the > computation. I'm not sure what "any continuing computation" from a state is > because the concept of what constitutes the notion of "a continuing > computation" has not been defined before. To me it sounds like a computation > tree with nodes as state and transitions as edges and a continuing > computation as a path through that tree into the future. The way it is > written then, it sounds to the naive reader, or to me at least, as if the > object is perpetually reachable by every thread always. I assume I am > misinterpreting the intention of the writing, but it sounds too loose for a > definition being invoked here in the javadoc. May be it can be tightened up a > bit. > > Could one state instead that "An object is reachable at a given state when > some thread is able to access the object through a sequence of steps starting > at that state without other threads taking any steps." ? Or something along > those lines? Or at least something tighter than the current wording that is > somewhat too loose. In fact, it appears as if the problem is with the use of "any", which is universal in strength, whereas the intention here is existential in strength (as suggested by. my wording). Indeed, you might achieve the same effect by replacing "any" with "some" so that: "An object is reachable if it can be accessed in some continuing computation from some live thread." You needn't even say live because dead threads can neither take steps nor continue participating in the computation nor can they "access" objects for whatever informal notion of access. The "some continuing computation" subsumes "potential" (as in a possible future) so potential can be dropped. - PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1530731176
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Tue, 19 Mar 2024 02:53:37 GMT, David Holmes wrote:
>> src/java.base/share/classes/java/lang/ref/package-info.java line 137:
>>
>>> 135: *
>>> 136: * A reachable object is any object that can be accessed in
>>> any potential
>>> 137: * continuing computation from any live thread (as stated in {@jls
>>> 12.6.1}).
>>
>> This seems like somewhat loose and sloppy wording to me. "Any potential
>> continuing computation"? "Any live thread"? Could you share a pointer to JLS
>> 12.6.1 being referenced here?
>
> https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.html#jls-12.6.1
>
>> A reachable object is any object that can be accessed in any potential
>> continuing computation from any live thread.
>
> It may be "loose" because the devil is in the details when it comes to
> reachability, but I disagree that it is "sloppy". This expresses reachability
> in simple terms, as a "first-order" or "Newtonian" model. There are of course
> "Quantum" effects that need to be dealt with in practice. The JLS alludes to
> this with:
>> Optimizing transformations of a program can be designed that reduce the
>> number of objects that are reachable to be less than those which would
>> naively be considered reachable.
Sorry, my use of words was sloppy here. I think I did mean loose or somewhat
informal and therefore slippery.
What I was saying is that using terms such as "any continuing computation"
doesn't make sense because this is referring to a current state of the
computation. I'm not sure what "any continuing computation" from a state is
because the concept of what constitutes the notion of "a continuing
computation" has not been defined before. To me it sounds like a computation
tree with nodes as state and transitions as edges and a continuing computation
as a path through that tree into the future. The way it is written then, it
sounds to the naive reader, or to me at least, as if the object is perpetually
reachable by every thread always. I assume I am misinterpreting the intention
of the writing, but it sounds too loose for a definition being invoked here in
the javadoc. May be it can be tightened up a bit.
Could one state instead that "An object is reachable at a given state when some
thread is able to access the object through a sequence of steps starting at
that state without other threads taking any steps." ? Or something along those
lines? Or at least something tighter than the current wording that is somewhat
too loose.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1530705355
Re: RFR: 8325579: Inconsistent behavior in com.sun.jndi.ldap.Connection::createSocket [v8]
On Thu, 14 Mar 2024 21:59:54 GMT, Christoph Langer wrote:
>> During analysing a customer case I figured out that we have an inconsistency
>> between documentation and actual behavior in class
>> com.sun.jndi.ldap.Connection. The [method documentation of
>> com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281)
>> states: "If a timeout is supplied but unconnected sockets are not supported
>> then the timeout is ignored and a connected socket is created."
>>
>> This, however does not happen. If a SocketFactory would not support
>> unconnected sockets, it would likely throw a SocketException in
>> [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123).
>> And since [the
>> code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336)
>> does not check for this behavior, a connection with timeout value through a
>> SocketFactory that does not support unconnected sockets would simply fail
>> with an IOException.
>>
>> So we should either make the code adhere to what is documented or adapt the
>> documentation to the actual behavior.
>>
>> I hereby try to fix the connect coding. Alternatively, we could also adapt
>> the description - I have no strong opinion. What do the experts suggest?
>
> Christoph Langer has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains 12 additional
> commits since the last revision:
>
> - Update module-info text
> - Merge branch 'master' into JDK-8325579
> - Indentation
> - Merge branch 'master' into JDK-8325579
> - Review feedback
> - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
> - Merge branch 'master' into JDK-8325579
> - Typo
> - Merge branch 'master' into JDK-8325579
> - Rename test and refine comment
> - ... and 2 more: https://git.openjdk.org/jdk/compare/bc0070cb...10271159
The latest version looks good to me with a couple minor comments and
suggestions.
src/java.naming/share/classes/module-info.java line 42:
> 40: * The value of this environment property specifies the fully
> 41: * qualified class name of the socket factory used by the LDAP
> provider.
> 42: * This class must implement the javax.net.SocketFactory abstract
> class
You could add a link to the `SocketFactory` class here:
Suggestion:
* This class must implement the {@link javax.net.SocketFactory}
abstract class
test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 164:
> 162: if
> (CustomSocketFactory.customSocket.closeMethodCalledCount() <= 0) {
> 163: System.err.println("Custom Socket was not
> closed.");
> 164: System.exit(-1);
Can we update test not to use `System.exit` and replace it with throwing `new
RuntimeException`, something like:
Suggestion:
throw new RuntimeException("Custom Socket was not
closed");
test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 177:
> 175: ctx.close();
> 176: if (!checkSocketClosed(sock)) {
> 177: System.exit(-1);
Can be replaced with:
Suggestion:
throw new RuntimeException("Socket isn't closed");
test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 184:
> 182: e.printStackTrace();
> 183: System.exit(-1);
> 184: }
For simplification and `System.exit` removal purposes this catch block can be
removed with addition of `throws Exception` clause to the `main` method.
Suggestion:
}
-
PR Review: https://git.openjdk.org/jdk/pull/17797#pullrequestreview-1946713010
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1530674406
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1530686689
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1530696579
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1530693641
Re: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v7]
On Tue, 19 Mar 2024 10:54:41 GMT, Nizar Benalla wrote: >> # Issue >> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in >> JDK 10 >> >> I changed the @\since tags to better accurately show when the methods and >> constructors were introduced. > > Nizar Benalla has updated the pull request incrementally with one additional > commit since the last revision: > > update the latter years for the Oracle copyrights src/java.base/share/classes/java/nio/channels/Channels.java line 2: > 1: /* > 2: * Copyright (c) 2000, 2023, 2024, Oracle and/or its affiliates. All > rights reserved. Thanks for updating, but needs a little adjustment. Rather than adding a third year, the format should be: "original year, current year, Oracle ..." So in this case -> `2000, 2024,` - PR Review Comment: https://git.openjdk.org/jdk/pull/18032#discussion_r1530694415
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v2]
On Tue, 19 Mar 2024 10:01:31 GMT, Suchismith Roy wrote: >>> > In AIX, we have an usecase where shared libraries have certain member >>> > objects to be referred to. E.g libclang.a(shr_64.o) . >>> >>> Would you happen to know any official documentation which explains that AIX >>> syntax? >>> >> >> https://www.ibm.com/docs/en/aix/7.2?topic=l-ld-command >> Text : >> >> **autoload: path/file(member) | Automatically load the archive member. >> -- | --** >> Autoload is a flag used to load archive members. The format of the path is >> mentioned. > >> Do you mean some application code is calling the `System.loadLibrary()` >> method with such values? > > Yes we are trying to install liblcang and also jextract and it fails with > errors. > > Exception in thread "main" java.lang.UnsatisfiedLinkError: no clang in > java.library.path > > at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2439) > at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916) > at java.base/java.lang.System.loadLibrary(System.java:2063) > at > [org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.RuntimeHelper.(RuntimeHelper.java:65)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65)) > at > [org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.constants$17.(constants$17.java:46)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46)) > at > [org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)) > at > [org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)) > at > [org.openjdk.jextract@22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)) > at > [org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)) > at > [org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)) > > > The actual member is libclang.a(libclang.so.16) Is this also needed for any other operating system? If not, I think the new code should only be used if `OperatingSystem.isAix()` (`import jdk.internal.util.OperatingSystem;`). - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1530686989
Re: CFV: New Core Libraries Group Member: Per-Ake Minborg
Vote: yes
Integrated: 8328261: public lookup fails with IllegalAccessException when used while module system is being initialized
On Mon, 18 Mar 2024 17:40:26 GMT, Mandy Chung wrote: > A simple fix. This is caused by a bug in `VerifyAccess::isClassAccessible` > that checks if a class is exported from `java.base` before the exports are > fully setup.It should check if the module system is fully initialized > before checking the module exports instead. This pull request has now been integrated. Changeset: 13292168 Author:Mandy Chung URL: https://git.openjdk.org/jdk/commit/132921683bc9860ce2ba89729dcd989b10b89aa2 Stats: 9 lines in 1 file changed: 1 ins; 5 del; 3 mod 8328261: public lookup fails with IllegalAccessException when used while module system is being initialized Reviewed-by: rriggs, alanb - PR: https://git.openjdk.org/jdk/pull/18356
Re: RFR: JDK-8326951 Missing @since Tags [v3]
> I added `@since` tags for methods/constructors that do not match the `@since` > of the enclosing class. > > The `write` method already existed in `PrintStream` in earlier versions and > instances of it could always call this method, since it extends > `FilterOutputStream` [which has the > method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96). Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: added since tag - Changes: - all: https://git.openjdk.org/jdk/pull/18055/files - new: https://git.openjdk.org/jdk/pull/18055/files/ba97724d..3cec63e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18055=02 - incr: https://webrevs.openjdk.org/?repo=jdk=18055=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18055/head:pull/18055 PR: https://git.openjdk.org/jdk/pull/18055
Re: CFV: New Core Libraries Group Member: Per-Ake Minborg
Vote: yes Naoto On 3/19/24 8:19 AM, Daniel Fuchs wrote: Hi, I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the Core Libraries Group [4]. Per-Ake is an OpenJDK Reviewer, a committer in the Leyden and Panama projects, and a member of Oracle’s Java Core Libraries team. Per-Ake has been actively participating in the development of the JDK and Panama projects for several years, and is one of the co-author of the Implementation of Foreign Function and Memory API (Third Preview) [2]. His contributions include more than 80 commits in the JDK [3] Votes are due by 16:00 UTC on April 2, 2024. Only current Members of the Core Libraries Group [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. best regards, -- daniel [1] https://openjdk.org/census#pminborg [2] https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d [3] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg=commits [4] https://openjdk.org/census#core-libs [5] https://openjdk.org/groups/#member-vote
Re: RFR: 8328524: [x86] StringRepeat.java failure on linux-x86: Could not reserve enough space for 2097152KB object heap
On Tue, 19 Mar 2024 14:59:19 GMT, Goetz Lindenmaier wrote: > …rve enough space for 2097152KB object heap > > I would like to fix this as the two related issues mentioned in the JBS bug. > We see it currently in most GHA runs. Marked as reviewed by sgehwolf (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/18380#pullrequestreview-1946656126
Re: CFV: New Core Libraries Group Member: Per-Ake Minborg
Vote: yes On 2024-03-19 16:19, Daniel Fuchs wrote: Hi, I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the Core Libraries Group [4]. Per-Ake is an OpenJDK Reviewer, a committer in the Leyden and Panama projects, and a member of Oracle’s Java Core Libraries team. Per-Ake has been actively participating in the development of the JDK and Panama projects for several years, and is one of the co-author of the Implementation of Foreign Function and Memory API (Third Preview) [2]. His contributions include more than 80 commits in the JDK [3] Votes are due by 16:00 UTC on April 2, 2024. Only current Members of the Core Libraries Group [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. best regards, -- daniel [1] https://openjdk.org/census#pminborg [2] https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d [3] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg=commits [4] https://openjdk.org/census#core-libs [5] https://openjdk.org/groups/#member-vote
Integrated: 8297879: javadoc link to preview JEP 1000 has grouping character comma
On Mon, 18 Mar 2024 14:53:44 GMT, Pavel Rappo wrote: > Please review this simple bugfix to properly construct links to preview JEPs. > > The most straightforward fix I could think of was to pass `String` rather > than `int` (`Integer`) to a method, which eventually calls > `java.text.MessageFormat.format(String, Object...)`. > > For the test, I decided to be ~lazy~ practical and piggyback on the existing > infrastructure. The alternatives were: > > 1. slap `noreg-hard` on the JBS bug and skip testing > 2. create a sophisticated test that dynamically adds a constant into the > `PreviewFeature.Feature` enum, annotates some class with `PreviewFeature` > with that constant, and finally documents that class with `PreviewFeature` > patched into `java.base` > > While (1) is insufficient, (2) seems overkill in this case. This pull request has now been integrated. Changeset: f140eb4c Author:Pavel Rappo URL: https://git.openjdk.org/jdk/commit/f140eb4c3a47e1479d62fe1eef16bbbea92892bc Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod 8297879: javadoc link to preview JEP 1000 has grouping character comma Reviewed-by: jjg, vromero - PR: https://git.openjdk.org/jdk/pull/18350
Re: CFV: New Core Libraries Group Member: Per-Ake Minborg
Vote: yes On Mar 19, 2024, at 11:19 AM, Daniel Fuchs wrote: Hi, I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the Core Libraries Group [4]. Per-Ake is an OpenJDK Reviewer, a committer in the Leyden and Panama projects, and a member of Oracle’s Java Core Libraries team. Per-Ake has been actively participating in the development of the JDK and Panama projects for several years, and is one of the co-author of the Implementation of Foreign Function and Memory API (Third Preview) [2]. His contributions include more than 80 commits in the JDK [3] Votes are due by 16:00 UTC on April 2, 2024. Only current Members of the Core Libraries Group [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. best regards, -- daniel [1] https://openjdk.org/census#pminborg [2] https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d [3] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg=commits [4] https://openjdk.org/census#core-libs [5] https://openjdk.org/groups/#member-vote [oracle_sig_logo.gif] Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
CFV: New Core Libraries Group Member: Per-Ake Minborg
Hi, I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the Core Libraries Group [4]. Per-Ake is an OpenJDK Reviewer, a committer in the Leyden and Panama projects, and a member of Oracle’s Java Core Libraries team. Per-Ake has been actively participating in the development of the JDK and Panama projects for several years, and is one of the co-author of the Implementation of Foreign Function and Memory API (Third Preview) [2]. His contributions include more than 80 commits in the JDK [3] Votes are due by 16:00 UTC on April 2, 2024. Only current Members of the Core Libraries Group [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. best regards, -- daniel [1] https://openjdk.org/census#pminborg [2] https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d [3] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg=commits [4] https://openjdk.org/census#core-libs [5] https://openjdk.org/groups/#member-vote
Re: RFR: 8328524: [x86] StringRepeat.java failure on linux-x86: Could not reserve enough space for 2097152KB object heap
On Tue, 19 Mar 2024 14:59:19 GMT, Goetz Lindenmaier wrote: > …rve enough space for 2097152KB object heap > > I would like to fix this as the two related issues mentioned in the JBS bug. > We see it currently in most GHA runs. LGTM. - Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18380#pullrequestreview-1946550205
Re: RFR: 8328524: [x86] StringRepeat.java failure on linux-x86: Could not reserve enough space for 2097152KB object heap
On Tue, 19 Mar 2024 14:59:19 GMT, Goetz Lindenmaier wrote: > …rve enough space for 2097152KB object heap > > I would like to fix this as the two related issues mentioned in the JBS bug. > We see it currently in most GHA runs. lgtm - Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18380#pullrequestreview-1946547791
RFR: 8328524: [x86] StringRepeat.java failure on linux-x86: Could not reserve enough space for 2097152KB object heap
…rve enough space for 2097152KB object heap I would like to fix this as the two related issues mentioned in the JBS bug. We see it currently in most GHA runs. - Commit messages: - 8328524: [x86] StringRepeat.java failure on linux-x86: Could not reserve enough space for 2097152KB object heap Changes: https://git.openjdk.org/jdk/pull/18380/files Webrev: https://webrevs.openjdk.org/?repo=jdk=18380=00 Issue: https://bugs.openjdk.org/browse/JDK-8328524 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18380/head:pull/18380 PR: https://git.openjdk.org/jdk/pull/18380
Re: RFR: 8327791: Optimization for new BigDecimal(String) [v10]
On Tue, 12 Mar 2024 14:03:01 GMT, Claes Redestad wrote: >> Shaojin Wen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> restore comment > > I think splitting `CharArraySequence` into two versions is somewhat dubious > as more observable types at call sites may mean the performance gain in > targeted micros is lost. How much of an improvement did you observe from > this? Again the `char[]` constructors is probably less performance sensitive > than the others. @cl4es @jddarcy All feedback has been fixed, can it be integrated? - PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2007020206
Re: RFR: JDK-8326951 Missing @since Tags [v2]
On Tue, 19 Mar 2024 11:21:14 GMT, Nizar Benalla wrote:
>> I added `@since` tags for methods/constructors that do not match the
>> `@since` of the enclosing class.
>>
>> The `write` method already existed in `PrintStream` in earlier versions and
>> instances of it could always call this method, since it extends
>> `FilterOutputStream` [which has the
>> method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
>
> Nizar Benalla has updated the pull request incrementally with three
> additional commits since the last revision:
>
> - Revert "fix rest of private/public since tags"
>
>This reverts commit 2c04a9d8e773616b7b6239335d4e5eb955944ad1.
> - Revert "removed unnecessary @ since tags"
>
>This reverts commit 5da3f0d83d19393eeb3a9da68aac40dd999de660.
> - removed unnecessary @ since tags
src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java line 68:
> 66: *
> 67: * @return {@inheritDoc java.security.AsymmetricKey}
> 68: * @since 22
Hello Nizar, are the removal of `@since` in this PR intentional? I haven't
checked all of them, but this specific removal appears incorrect, since this
method was indeed introduced in Java 22 as part of
https://bugs.openjdk.org/browse/JDK-8318096.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1526987579
Re: RFR: JDK-8326951 Missing @since Tags [v2]
On Mon, 18 Mar 2024 14:02:20 GMT, Jan Lahoda wrote:
>> Hello Jaikiran,
>> in jdk21 DHPPublicKey did have a
>> [getParams()](https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L244)
>> method, so it is not new in jdk 22. It also existed [before
>> that](https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L252)
>>
>> If you haven't looked at the other cases, I was about to group the changes
>> related to the Key interfaces in a separate PR if that's fine. let me know
>> what you think
>
> Hello,
>
> While the override of `getParams` in `DHPublicKey` was added, the `getParams`
> method has been inherited to `DHPublicKey` for a long time from `DHKey`.
> E.g., I can take this:
>
> import javax.crypto.interfaces.DHPublicKey;
>
> public class DhkeyTest {
>
> public static void main(DHPublicKey key) {
> System.err.println(key.getParams());
> }
>
> }
>
>
> and compile using JDK 8 without any compile-time errors. So, it would make
> more sense to me to not add the `@since` for it.
>
> I believe Nizar will separate the changes to the Key interfaces into a
> separate PR, so we can discuss in more detail there.
>
> Thanks!
Hello Jan, interesting. I hadn't noticed that
`javax.crypto.interfaces.DHPublicKey` already was exposing `getParams()` in
earlier versions because `javax.crypto.interfaces.DHPublicKey` extends from
`javax.crypto.interfaces.DHKey` which has the `getParams()` method.
> I believe Nizar will separate the changes to the Key interfaces into a
> separate PR, so we can discuss in more detail there.
That sounds fine to me.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1528641492
Re: RFR: JDK-8326951 Missing @since Tags [v2]
On Sun, 17 Mar 2024 01:20:17 GMT, Nizar Benalla wrote:
>> src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java line 68:
>>
>>> 66: *
>>> 67: * @return {@inheritDoc java.security.AsymmetricKey}
>>> 68: * @since 22
>>
>> Hello Nizar, are the removal of `@since` in this PR intentional? I haven't
>> checked all of them, but this specific removal appears incorrect, since this
>> method was indeed introduced in Java 22 as part of
>> https://bugs.openjdk.org/browse/JDK-8318096.
>
> Hello Jaikiran,
> in jdk21 DHPPublicKey did have a
> [getParams()](https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L244)
> method, so it is not new in jdk 22. It also existed [before
> that](https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L252)
>
> If you haven't looked at the other cases, I was about to group the changes
> related to the Key interfaces in a separate PR if that's fine. let me know
> what you think
Hello,
While the override of `getParams` in `DHPublicKey` was added, the `getParams`
method has been inherited to `DHPublicKey` for a long time from `DHKey`. E.g.,
I can take this:
import javax.crypto.interfaces.DHPublicKey;
public class DhkeyTest {
public static void main(DHPublicKey key) {
System.err.println(key.getParams());
}
}
and compile using JDK 8 without any compile-time errors. So, it would make more
sense to me to not add the `@since` for it.
I believe Nizar will separate the changes to the Key interfaces into a separate
PR, so we can discuss in more detail there.
Thanks!
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1528625403
Re: RFR: JDK-8326951 Missing @since Tags [v2]
> I added `@since` tags for methods/constructors that do not match the `@since` > of the enclosing class. > > The `write` method already existed in `PrintStream` in earlier versions and > instances of it could always call this method, since it extends > `FilterOutputStream` [which has the > method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96). Nizar Benalla has updated the pull request incrementally with three additional commits since the last revision: - Revert "fix rest of private/public since tags" This reverts commit 2c04a9d8e773616b7b6239335d4e5eb955944ad1. - Revert "removed unnecessary @ since tags" This reverts commit 5da3f0d83d19393eeb3a9da68aac40dd999de660. - removed unnecessary @ since tags - Changes: - all: https://git.openjdk.org/jdk/pull/18055/files - new: https://git.openjdk.org/jdk/pull/18055/files/2c04a9d8..ba97724d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18055=01 - incr: https://webrevs.openjdk.org/?repo=jdk=18055=00-01 Stats: 10 lines in 10 files changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18055/head:pull/18055 PR: https://git.openjdk.org/jdk/pull/18055
Re: RFR: JDK-8326951 Missing @since Tags [v2]
On Sat, 16 Mar 2024 00:20:51 GMT, Jaikiran Pai wrote:
>> Nizar Benalla has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Revert "fix rest of private/public since tags"
>>
>>This reverts commit 2c04a9d8e773616b7b6239335d4e5eb955944ad1.
>> - Revert "removed unnecessary @ since tags"
>>
>>This reverts commit 5da3f0d83d19393eeb3a9da68aac40dd999de660.
>> - removed unnecessary @ since tags
>
> src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java line 68:
>
>> 66: *
>> 67: * @return {@inheritDoc java.security.AsymmetricKey}
>> 68: * @since 22
>
> Hello Nizar, are the removal of `@since` in this PR intentional? I haven't
> checked all of them, but this specific removal appears incorrect, since this
> method was indeed introduced in Java 22 as part of
> https://bugs.openjdk.org/browse/JDK-8318096.
Hello Jaikiran,
in jdk21 DHPPublicKey did have a
[getParams()](https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L244)
method, so it is not new in jdk 22. It also existed [before
that](https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L252)
If you haven't looked at the other cases, I was about to group the changes
related to the Key interfaces in a separate PR if that's fine. let me know what
you think
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1527393223
Re: RFR: 8327176: UnreferencedExecutor.java can fail on libgraal with -Xcomp
On Sun, 3 Mar 2024 17:01:53 GMT, Doug Simon wrote: > The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail > when run on libgraal and `-Xcomp` is specified. The problem is that libgraal > in `-Xcomp` temporarily causes some extra memory pressure (probably due to > [JDK-8310218](https://bugs.openjdk.org/browse/JDK-8310218)) which can cause > recoverable OOMEs to occur (memory is recovered when the relevant libgraal > compilations complete). It also seems related to async threads used for > cleaning weak references when using G1 or ZGC as I cannot reproduce the > failure under `-XX:+UseSerialGC`. > > Installing a global `Thread.UncaughtExceptionHandler` that ignores > `OutOfMemoryError`s resolves the problem. I confirmed that `java/util/concurrent/Executors/UnreferencedExecutor.java` still fails if the [fix applied to ThreadContainers.java](https://github.com/openjdk/jdk/commit/ada416e66cbff6c8e631bf352acc0744c248740b#diff-1e347b9a95cc4fe81a01ca70e4122a73a65d99a69668c7567abb2a6067f8cc6dL68) is reverted. - PR Comment: https://git.openjdk.org/jdk/pull/18098#issuecomment-1975231258
RFR: 8327176: UnreferencedExecutor.java can fail on libgraal with -Xcomp
The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail when run on libgraal and `-Xcomp` is specified. The problem is that libgraal in `-Xcomp` temporarily causes some extra memory pressure (probably due to [JDK-8310218](https://bugs.openjdk.org/browse/JDK-8310218)) which can cause recoverable OOMEs to occur (memory is recovered when the relevant libgraal compilations complete). It also seems related to async threads used for cleaning weak references when using G1 or ZGC as I cannot reproduce the failure under `-XX:+UseSerialGC`. Installing a global `Thread.UncaughtExceptionHandler` that ignores `OutOfMemoryError`s resolves the problem. - Commit messages: - ignore recoverable OOMEs Changes: https://git.openjdk.org/jdk/pull/18098/files Webrev: https://webrevs.openjdk.org/?repo=jdk=18098=00 Issue: https://bugs.openjdk.org/browse/JDK-8327176 Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18098.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18098/head:pull/18098 PR: https://git.openjdk.org/jdk/pull/18098
Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v22]
> Please review this patch which adds a jlink mode to the JDK which doesn't > need the packaged modules being present. A.k.a run-time image based jlink. > Fundamentally this patch adds an option to use `jlink` even though your JDK > install might not come with the packaged modules (directory `jmods`). This is > particularly useful to further reduce the size of a jlinked runtime. After > the removal of the concept of a JRE, a common distribution mechanism is still > the full JDK with all modules and packaged modules. However, packaged modules > can incur an additional size tax. For example in a container scenario it > could be useful to have a base JDK container including all modules, but > without also delivering the packaged modules. This comes at a size advantage > of `~25%`. Such a base JDK container could then be used to `jlink` > application specific runtimes, further reducing the size of the application > runtime image (App + JDK runtime; as a single image *or* separate bundles, > depending on the app b eing modularized). > > The basic design of this approach is to add a jlink plugin for tracking > non-class and non-resource files of a JDK install. I.e. files which aren't > present in the jimage (`lib/modules`). This enables producing a `JRTArchive` > class which has all the info of what constitutes the final jlinked runtime. > > Basic usage example: > > $ diff -u <(./bin/java --list-modules --limit-modules java.se) > <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules > --limit-modules java.se) > $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) > <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules > --limit-modules jdk.jlink) > $ ls ../linux-x86_64-server-release/images/jdk/jmods > java.base.jmodjava.net.http.jmod java.sql.rowset.jmod > jdk.crypto.ec.jmod jdk.internal.opt.jmod > jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod > java.compiler.jmodjava.prefs.jmod java.transaction.xa.jmod > jdk.dynalink.jmod jdk.internal.vm.ci.jmod > jdk.jdwp.agent.jmod jdk.management.jfr.jmodjdk.security.jgss.jmod > java.datatransfer.jmodjava.rmi.jmodjava.xml.crypto.jmod > jdk.editpad.jmod jdk.internal.vm.compiler.jmod > jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod > java.desktop.jmod java.scripting.jmod java.xml.jmod > jdk.hotspot.agent.jmod jdk.internal.vm.compiler.manage... Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits: - Fix race wrt. first and second image generation. The second, create-linkable-runtime enabled link, needs to depend on the first (default jdk link). Also fix an issue with respect to which support dir is being used for which link. - Merge branch 'master' into jdk-8311302-jmodless-link - Fix comment. - Review feedback and Windows build fix (FixPath) - Fix comment in autoconf file - Remove no longer needed plugin options - Restore GenerateJLIClassesPluginTest.java - Update some comments - Add copyright header/comments - Ensure build-only plugin isn't propagated to the final image - ... and 80 more: https://git.openjdk.org/jdk/compare/fc0472ba...e25dd440 - Changes: https://git.openjdk.org/jdk/pull/14787/files Webrev: https://webrevs.openjdk.org/?repo=jdk=14787=21 Stats: 3549 lines in 38 files changed: 3413 ins; 111 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/14787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787 PR: https://git.openjdk.org/jdk/pull/14787
Re: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v6]
On Mon, 18 Mar 2024 12:44:46 GMT, Nizar Benalla wrote: >> # Issue >> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in >> JDK 10 >> >> I changed the @\since tags to better accurately show when the methods and >> constructors were introduced. > > Nizar Benalla has updated the pull request incrementally with one additional > commit since the last revision: > > added terminal new line I have updated them - PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2006812767
Re: RFR: JDK-8326853 Missing @since tags for Charset related methods added in Java 10 [v7]
> # Issue > - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK > 10 > > I changed the @\since tags to better accurately show when the methods and > constructors were introduced. Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: update the latter years for the Oracle copyrights - Changes: - all: https://git.openjdk.org/jdk/pull/18032/files - new: https://git.openjdk.org/jdk/pull/18032/files/abc5a6ab..8bcc364f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18032=06 - incr: https://webrevs.openjdk.org/?repo=jdk=18032=05-06 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032 PR: https://git.openjdk.org/jdk/pull/18032
Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v21]
On Mon, 18 Mar 2024 20:18:09 GMT, Mandy Chung wrote: > This is what I understand from your implementation: > > 1. create a regular JDK image under > `support/images/runtime-link-initial-jdk` using jlink from the exploded JDK > build > > 2. create a linkable JDK image under `images/jdk` using jlink from the > exploded JDK build with jlink command-line options used in step 1 plus > > > ``` > -create-linkable-runtime > jimage=support/images/runtime-link-initial-jdk/lib/modules:module-path=support/images/jmods > ``` > > jlink in step 2 has to run through the plugin pipeline as in step 1 and also > the `create-linkable-runtime` plugin to generate the diffs and record the > metadata for reconstituting the modules from the images (without the packaged > modules). > > Step 2 re-creates a new jimage file from the input packaged modules while the > diffs are generated from `runtime-link-initial-jdk/lib/modules`. In this > approach, step 1 and step 2 assume that the same set of modules are linked > and set set of plugin transformation is applied except > `--create-linkable-runtime` as in step 1, i.e. it relies on the makefile to > pass proper commands to step 1 and step 2 to result in the same `lib/modules` > minus the new metadata and diffs added by `--create-linkable-runtime`. That's correct. > The original idea we discussed is that step 1 creates a normal JDK image (as > step 1 above) and then step 2 solely creates a new JDK linkable image without > involving plugin pipeline that would be a simpler model. The idea was > something like this: > > ``` > $ runtime-link-initial-jdk/bin/jlink -create-linkable-runtime > support/images/jmods --output images/jdk > ``` > > jlink `--create-linkable-runtime` will copy everything under > `runtime-link-initial-jdk` (the runtime executing jlink) except `lib/modules` > to `images/jdk` and create a new jimage `lib/modules` from > `runtime-link-initial-jdk/lib/modules` (include diffs and metadata files). > > Have you seen any issues with this approach over your current approach which > involves the plugin transformation in both step 1 and 2? Yes, a couple of issues. In no particular order: - `jlink` is the only tool capable of generating the `jimage` file (`lib/modules`) as of yet. See class `ImageFileCreator`. - `jlink` is currently designed in a way to work on a) some form of an `Archive` (packaged modules, really) and b) a plugin pipeline. a) changes with this patch due to introduction of `JRTArchive`, but this archive relies on the "diff parts" as well as the "non-class-resource" parts. So in order to "use" `lib/modules` from `runtime-link-initial-jdk` we have a chicken and egg problem: Use `JRTArchive` before it's ready to be used. Or we'd have to distinguish between `JRTArchive` usage at JDK build time and `JRTArchive` usage at jlink runtime (after the JDK build has completed). - Let's assume the `JRTArchive` issue as described above is solved then we wouldn't have a way to **not** run any plugins at jlink time, unless we specify `--disable-plugin ` for each. Even if we had, then there is no guarantee to present the resources in the `jimage` file in the desired order. - Let's assume we don't use `JRTArchive` and use an `Archive` implementation from packaged modules instead. We cannot use that approach either, since we'd miss generated resources from plugins (like `--system-modules`, `--release-info` and `--generate-jli-classes`) or change the order of the resources in the `jimage` (plugin `--order-resources`) or have a different compression level (plugin `--compress`). There is more, which affects generation of the actual `jimage` file. - The way I understand the `jimage` [format](https://cr.openjdk.org/~sgehwolf/leyden/jimage_visualization_1.png) and how it's generated, it doesn't allow for post-factum addition of resources for a module. Those need to be known at jlink pipeline run time so that this information is available when the actual image format is being serialized. So unless, I'm missing something, the approach that I've taken would be the one with less compatibility impact. Thoughts? - PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2006724776
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v2]
On Tue, 19 Mar 2024 09:58:04 GMT, Suchismith Roy wrote: >>> In AIX, we have an usecase where shared libraries have certain member >>> objects to be referred to. E.g libclang.a(shr_64.o) . >> >> Would you happen to know any official documentation which explains that AIX >> syntax? >> >>> When we provide the path to loadLibrary() >> >> Do you mean some application code is calling the `System.loadLibrary()` >> method with such values? > >> > In AIX, we have an usecase where shared libraries have certain member >> > objects to be referred to. E.g libclang.a(shr_64.o) . >> >> Would you happen to know any official documentation which explains that AIX >> syntax? >> > > https://www.ibm.com/docs/en/aix/7.2?topic=l-ld-command > Text : > > **autoload: path/file(member) | Automatically load the archive member. > -- | --** > Autoload is a flag used to load archive members. The format of the path is > mentioned. > Do you mean some application code is calling the `System.loadLibrary()` > method with such values? Yes we are trying to install liblcang and also jextract and it fails with errors. Exception in thread "main" java.lang.UnsatisfiedLinkError: no clang in java.library.path at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2439) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916) at java.base/java.lang.System.loadLibrary(System.java:2063) at [org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.RuntimeHelper.(RuntimeHelper.java:65)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65)) at [org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.constants$17.(constants$17.java:46)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46)) at [org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)) at [org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)) at [org.openjdk.jextract@22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)) at [org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)) at [org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)) The actual member is libclang.a(libclang.so.16) - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1530059834
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v2]
On Mon, 18 Mar 2024 17:40:04 GMT, Jaikiran Pai wrote: > > In AIX, we have an usecase where shared libraries have certain member > > objects to be referred to. E.g libclang.a(shr_64.o) . > > Would you happen to know any official documentation which explains that AIX > syntax? > https://www.ibm.com/docs/en/aix/7.2?topic=l-ld-command Text : **autoload: path/file(member) | Automatically load the archive member. -- | --** Autoload is a flag used to load archive members. The format of the path is mentioned. - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1530054525
Re: RFR: JDK-8327640: Allow NumberFormat strict parsing [v2]
On Tue, 19 Mar 2024 00:07:37 GMT, Justin Lu wrote:
>> Please review this PR and associated
>> [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict
>> parsing for NumberFormat.
>>
>> The concrete subclasses that will utilize this leniency value are
>> `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for
>> parsing to be used as an input validation technique for localized formatted
>> numbers. The default leniency mode will remain lenient, and can only be set
>> to strict through an intentional `setLenient(boolean)` method call. Leniency
>> operates differently based off the values returned by `isGroupingUsed()`,
>> `getGroupingSize()`, and `isParseIntegerOnly()`.
>>
>> Below is an example of the change, the CSR can be viewed for further detail.
>>
>>
>> DecimalFormat fmt = (DecimalFormat)
>> NumberFormat.getNumberInstance(Locale.US);
>> fmt.parse("1,,,0,,,00,.23Zabced45"); // returns 1000.23
>> fmt.setLenient(false);
>> fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
>> fmt.setGroupingSize(2);
>> fmt.parse("12,34,567"); // throws ParseException
>> fmt.setParseIntegerOnly(true)
>> fmt.parse("12,34.56"); // throws ParseException
>> fmt.parse("12,34"); // successfully returns the Number 1234
>>
>>
>> The associated tests are all localized, and the data is converted properly
>> during runtime.
>
> Justin Lu has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Replace protected field with a public getter -> isStrict().
> Replace setLenient() with setStrict() to avoid messy inversion of boolean.
> Add a leniency section to NumberFormat.
> Overhaul of NumberFormat class specification to be much more
> organized/readable.
src/java.base/share/classes/java/text/DecimalFormat.java line 2419:
> 2417: if (gotPositive) {
> 2418: boolean containsPosSuffix =
> 2419: text.regionMatches(position, positiveSuffix,0,
> positiveSuffix.length());
Suggestion:
text.regionMatches(position, positiveSuffix, 0,
positiveSuffix.length());
src/java.base/share/classes/java/text/DecimalFormat.java line 2426:
> 2424: if (gotNegative) {
> 2425: boolean containsNegSuffix =
> 2426: text.regionMatches(position, negativeSuffix,0,
> negativeSuffix.length());
Suggestion:
text.regionMatches(position, negativeSuffix, 0,
negativeSuffix.length());
src/java.base/share/classes/java/text/DecimalFormat.java line 2428:
> 2426: text.regionMatches(position, negativeSuffix,0,
> negativeSuffix.length());
> 2427: boolean endsWithNegSuffix =
> 2428: containsNegSuffix && text.length() == position
> + negativeSuffix.length();
Suggestion:
containsNegSuffix && text.length() == position +
negativeSuffix.length();
src/java.base/share/classes/java/text/DecimalFormat.java line 2482:
> 2480: // process digits or Inf, find decimal position
> 2481: status[STATUS_INFINITE] = false;
> 2482: if (!isExponent && text.regionMatches(position,
> symbols.getInfinity(),0,
Suggestion:
if (!isExponent && text.regionMatches(position, symbols.getInfinity(),
0,
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1529965478
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1529965780
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1529966184
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1529966645
Re: RFR: 8326941: Remove StringUTF16::isBigEndian
On Mon, 18 Mar 2024 22:51:55 GMT, Claes Redestad wrote: >> This PR proposes to remove the native method `StringUTF16::isBigEndian` and >> its corresponding C implementation and instead rely on the >> `jdk.internal.misc.Unsafe::isBigEndian` method. >> >> This PR passes tier1-3 tests. > >> Initialization order > > ```java -Xlog:class+init -XX:-CompactStrings -version```: > > Before: > > [0.015s][info][class,init] 71 Initializing 'java/lang/StringUTF16' > (0x00ff00063a20) by thread "main" > [0.015s][info][class,init] 72 Initializing 'jdk/internal/util/ArraysSupport' > (0x00ff00063c20) by thread "main" > [0.015s][info][class,init] 73 Initializing 'jdk/internal/misc/Unsafe' > (0x00ff00050de0) by thread "main" > > > After: > > [0.018s][info][class,init] 71 Initializing 'java/lang/StringUTF16' > (0x000400063a30) by thread "main" > [0.018s][info][class,init] 72 Initializing 'jdk/internal/misc/Unsafe' > (0x000400050de0) by thread "main" > [0.018s][info][class,init] 73 Initializing 'jdk/internal/util/ArraysSupport' > (0x000400063c30) by thread "main" > > Seems the order only changes subtly. > >> Unsafe was added 2015, a few weeks before the explicit C code was added. >> This might indicate the previous solution was deliberate or it might be the >> case, the new method was not known by the author at the time. > > `sun.misc.Unsafe::isBigEndian` has existed longer, and was removed when > `jdk.internal.misc.Unsafe` was added. `StringUTF16::isBigEndian` was added by > JEP 254 by a group of people who I believe would have been well aware of its > existence. It doesn't seem that having `StringUTF16` have a `` > dependency on `Unsafe` is problematic today, though. Perhaps > `sun.misc.Unsafe` did more weird things back in 2015. Thanks for the clarifications @cl4es! - PR Comment: https://git.openjdk.org/jdk/pull/18348#issuecomment-2006338283
Integrated: 8326941: Remove StringUTF16::isBigEndian
On Mon, 18 Mar 2024 14:09:09 GMT, Per Minborg wrote: > This PR proposes to remove the native method `StringUTF16::isBigEndian` and > its corresponding C implementation and instead rely on the > `jdk.internal.misc.Unsafe::isBigEndian` method. > > This PR passes tier1-3 tests. This pull request has now been integrated. Changeset: c59c41aa Author:Per Minborg URL: https://git.openjdk.org/jdk/commit/c59c41aa6e28ab1dc59e6051f85e3e9ade251b07 Stats: 18 lines in 2 files changed: 2 ins; 13 del; 3 mod 8326941: Remove StringUTF16::isBigEndian Reviewed-by: rriggs - PR: https://git.openjdk.org/jdk/pull/18348
