Re: RFR: 8231640: (prop) Canonical property storage [v8]

> The commit in this PR implements the proposal for enhancement that was > discussed in the core-libs-dev mailing list recently[1], for > https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to > now look for the

Re: How can I trigger a @Serial warning?

Hi Cay, The enhancements to javac's serial lint checking have not been implemented as of yet. For now, @Serial is just documentation. HTH, -Joe On 9/8/2021 10:43 PM, Cay Horstmann wrote: I am trying to give an example of the utility of the @Serial annotation. But the JDK 17 javac doesn't

Re: RFR: 8231640: (prop) Canonical property storage [v7]

Hello Roger, On 10/09/21 12:32 am, Roger Riggs wrote: src/java.base/share/classes/java/util/Properties.java line 187: 185: ? System.getenv("SOURCE_DATE_EPOCH") 186: :

Re: RFR: 8273513: Make java.io.FilterInputStream specification more precise about overrides [v3]

> Modify the class level specification of `java.io.FilterInputStream` to be > more exact about `java.io.InputStream` methods that it overrides. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8273513: Remove an extra space

Re: RFR: 8273513: Make java.io.FilterInputStream specification more precise about overrides [v2]

On Thu, 9 Sep 2021 23:54:25 GMT, Brian Burkhalter wrote: >> Modify the class level specification of `java.io.FilterInputStream` to be >> more exact about `java.io.InputStream` methods that it overrides. > > Brian Burkhalter has updated the pull request incrementally with one > additional

Re: RFR: 8273513: Make java.io.FilterInputStream specification more precise about overrides [v2]

> Modify the class level specification of `java.io.FilterInputStream` to be > more exact about `java.io.InputStream` methods that it overrides. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8273513: Change key to select as

Re: RFR: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family

On Wed, 1 Sep 2021 20:13:38 GMT, Raffaello Giulietti wrote: > This PR ideally continues #5285, which has been closed as a consequence of > inadvertently removing the branch on my repo. See there for initial > discussion. > > Sorry for the mess.

RFR: 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict

Small spec clarification. Corresponding CSR has also been drafted. - Commit messages: - 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict Changes: https://git.openjdk.java.net/jdk/pull/5457/files Webrev:

Re: [jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac

On Thu, 9 Sep 2021 20:14:01 GMT, Andy Herrick wrote: > backport from jdk-18 Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/306

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" > via an AppContext to support "applet logging isolation". The AppContext class > became useless since the plugin and webstart are no longer supported and >

Re: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

On Thu, 9 Sep 2021 14:31:19 GMT, Magnus Ihse Bursie wrote: >> Currently, the build system defaults the libjvm.so location to "server". >> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We >> need to see if moving the libjvm.so to a proper location breaks anything.

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

On Fri, 3 Sep 2021 17:19:05 GMT, Phil Race wrote: > Hmm I was under the impression this was removing AppContext itself but it is > just removing the backdoor needed by logging > Perhaps this isn't the change that requires the CSR but it then leaves an > inconsistent state where desktop

Re: [jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac

On Thu, 9 Sep 2021 20:14:01 GMT, Andy Herrick wrote: > backport from jdk-18 Is it for jdk17 or for jdk17u? - PR: https://git.openjdk.java.net/jdk17/pull/306

Re: [jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac

On Thu, 9 Sep 2021 20:14:01 GMT, Andy Herrick wrote: > backport from jdk-18 Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/306

RFR: 8273402: Use derived NamingExceptions in com.sun.jndi.ldap.Connection#readReply

Hi, The following fix changes type of exception thrown when an LDAP operation fails for reasons like read timeout or connection closure/cancellation: instead of throwing a general `NamingException`, the internal LDAP connection class will throw a

Re: RFR: 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming [v2]

On Thu, 9 Sep 2021 13:24:27 GMT, Andrey Turbanov wrote: >> Update code checks both non-null and instance of a class in java.naming >> module classes. >> The checks and explicit casts could also be replaced with pattern matching >> for the instanceof operator. >> For example: >> The

[jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac

backport from jdk-18 - Commit messages: - JDK-8272639: jpackaged applications using microphone on mac Changes: https://git.openjdk.java.net/jdk17/pull/306/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=306=00 Issue:

Integrated: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed"

On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote: > The gist of the issue is that the test case now always creates the boot > classpath with non-ASCII chars appended, because the default encoding is > fixed to UTF-8 with the fix to JDK-8260265. > > On macOS, javaagent tries to load the class

[jdk17] Integrated: 8271868: Warn user when using mac-sign option with unsigned app-image.

On Thu, 9 Sep 2021 16:36:44 GMT, Andy Herrick wrote: > This is a backport from JDK-18 This pull request has now been integrated. Changeset: a37254c7 Author:Andy Herrick URL: https://git.openjdk.java.net/jdk17/commit/a37254c79fa5973465d90f4b52ab88fe68016c9f Stats: 65 lines in 9

Re: RFR: 8231640: (prop) Canonical property storage [v7]

On Thu, 9 Sep 2021 09:56:30 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was >> discussed in the core-libs-dev mailing list recently[1], for >> https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in

Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2]

On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 >> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was >> a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

Hi Jaikiran, I agree with separating out the discussion of a new store method and (mostly) with the list of objectives below. And I'd propose doing it in a separate RFE[1] and PR. As to support for comments, I think we can omit them entirely from the new method. Since the caller has access

RFR: JDK-8273162 AbstractSplittableWithBrineGenerator does not create a random salt

RandomSupport.AbstractSplittableWithBrineGenerator. makeSplitsSpliterator is intending to create a salt from a random long. The salt should have random letters of size 4 for each consecutive 4 bits and then the last 4 bits as ff, i.e. all bits set. However the loop is never executed, the

Re: RFR: 8272903: Missing license header in ArenaAllocator.java

On Thu, 9 Sep 2021 17:12:23 GMT, Maurizio Cimadamore wrote: > This small patch adds missing copyright header to a segment allocator > implementation class. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5447

Integrated: 8272903: Missing license header in ArenaAllocator.java

On Thu, 9 Sep 2021 17:12:23 GMT, Maurizio Cimadamore wrote: > This small patch adds missing copyright header to a segment allocator > implementation class. This pull request has now been integrated. Changeset: 96614da0 Author:Maurizio Cimadamore URL:

Re: RFR: 8272903: Missing license header in ArenaAllocator.java

On Thu, 9 Sep 2021 17:12:23 GMT, Maurizio Cimadamore wrote: > This small patch adds missing copyright header to a segment allocator > implementation class. Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5447

RFR: 8272903: Missing license header in ArenaAllocator.java

This small patch adds missing copyright header to a segment allocator implementation class. - Commit messages: - Add missing copyright header Changes: https://git.openjdk.java.net/jdk/pull/5447/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5447=00 Issue:

Re: [jdk17] RFR: 8271868: Warn user when using mac-sign option with unsigned app-image.

On Thu, 9 Sep 2021 16:36:44 GMT, Andy Herrick wrote: > This is a backport from JDK-18 Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/305

[jdk17] RFR: 8271868: Warn user when using mac-sign option with unsigned app-image.

This is a backport from JDK-18 - Commit messages: - JDK-8271868: Warn user when using mac-sign option with unsigned app-image. Changes: https://git.openjdk.java.net/jdk17/pull/305/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=305=00 Issue:

Re: RFR: 8273514: java/util/DoubleStreamSums/CompensatedSums.java failure [v2]

> Relaxing some assertion bounds to allow for small error values that still > show improvement over previous summation method. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Tweaking asserts - Changes: - all:

Re: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v3]

On Fri, 3 Sep 2021 12:01:12 GMT, Vladimir Ivanov wrote: > > For the change of MethodHandle::asType to a final method, this needs a CSR. > > It is not allowed to extend/subclass `MethodHandle` outside > `java.lang.invoke` package. > So, the aforementioned change doesn't have any compatibility

Re: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT [v2]

On Thu, 9 Sep 2021 12:25:17 GMT, Jovan Stevanovic wrote: >> GraalVM Native Image supports loading classes at runtime if they are known >> during image build (class predefinition). This is achieved by the JVMTI >> agent that registers dynamically generated classes in a regular HotSpot run. >>

Re: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

On Thu, 9 Sep 2021 15:23:45 GMT, Aleksey Shipilev wrote: >> Sure, that works for me. > > While we are at it, do `core` and `custom` even carry their weight? I cannot > remember if I ever seen anyone using them. Maybe we should "just" drop those > variants, and leave only "server, client,

Re: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

On Thu, 9 Sep 2021 15:12:27 GMT, Magnus Ihse Bursie wrote: >> Ok, I agree. Can I do a Zero-specific thing here (so that it is potentially >> cleanly backportable), and then handle the rest of the variants? > > Sure, that works for me. While we are at it, do `core` and `custom` even carry their

Re: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

On Thu, 9 Sep 2021 14:41:02 GMT, Aleksey Shipilev wrote: >> I think we should stop these as well from impersonating the server JVM. >> Preferably in the same fix, so we can remove all the special casing for >> "server" being anything else but server. > > Ok, I agree. Can I do a Zero-specific

Re: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

On Thu, 9 Sep 2021 14:28:19 GMT, Magnus Ihse Bursie wrote: >> Yes, there are at least "core" and "custom": >> >> >> # All valid JVM variants >> VALID_JVM_VARIANTS="server client minimal core zero custom" > > I think we should stop these as well from impersonating the server JVM. > Preferably

Re: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote: > Currently, the build system defaults the libjvm.so location to "server". > This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We > need to see if moving the libjvm.so to a proper location breaks anything. > >

Re: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

On Thu, 9 Sep 2021 13:14:35 GMT, Aleksey Shipilev wrote: >> make/autoconf/hotspot.m4 line 86: >> >>> 84: fi >>> 85: >>> 86: # All "special" variants share the same output directory ("server") >> >> I presume "zero" was a special variant? Are there any other variants >> remaining? > >

Re: RFR: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed"

On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote: > The gist of the issue is that the test case now always creates the boot > classpath with non-ASCII chars appended, because the default encoding is > fixed to UTF-8 with the fix to JDK-8260265. > > On macOS, javaagent tries to load the class

Re: RFR: 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming [v2]

> Update code checks both non-null and instance of a class in java.naming > module classes. > The checks and explicit casts could also be replaced with pattern matching > for the instanceof operator. > For example: > The following code: > > return (obj != null && >

Re: RFR: 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming

On Mon, 6 Sep 2021 08:08:33 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in java.naming > module classes. > The checks and explicit casts could also be replaced with pattern matching > for the instanceof operator. > For example: > The following

Re: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

On Thu, 9 Sep 2021 13:02:23 GMT, David Holmes wrote: >> Currently, the build system defaults the libjvm.so location to "server". >> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We >> need to see if moving the libjvm.so to a proper location breaks anything. >> >>

Re: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote: > Currently, the build system defaults the libjvm.so location to "server". > This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We > need to see if moving the libjvm.so to a proper location breaks anything. > >

Re: Patch for JDK-8273541

Hi! Thanks for the reply, Aleksey and Alan. I had submitted the patch after viewing the first response but have now withdrawn it as PR is already open. Regards, Kartik On Thu, Sep 9, 2021 at 6:32 PM Alan Bateman wrote: > On 09/09/2021 13:36, Kartik Ohri wrote: > > Hi all! > > I would like to

Re: Patch for JDK-8273541

On 09/09/2021 13:36, Kartik Ohri wrote: Hi all! I would like to work on a fix for JDK-8273541 . I think the regression was introduced by the change here

RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. Additional testing: - [x] Linux x86_64 Zero build - [x] Linux x86_64

Re: Patch for JDK-8273541

On 9/9/21 2:36 PM, Kartik Ohri wrote: I would like to work on a fix for JDK-8273541 Sure, it does not seem taken yet. Submit the PR, and work there. -- Thanks, -Aleksey

Patch for JDK-8273541

Hi all! I would like to work on a fix for JDK-8273541 . I think the regression was introduced by the change here . It

Re: RFR: 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming

On Mon, 6 Sep 2021 08:08:33 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in java.naming > module classes. > The checks and explicit casts could also be replaced with pattern matching > for the instanceof operator. > For example: > The following

Re: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT

On Wed, 8 Sep 2021 18:15:47 GMT, Joe Wang wrote: > I'm not involved in any older releases. You'll need to find the right channel > for a particular backport you want to make and ask there. As for merging the > change in the current release, please update the copyright header and the >

Re: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT [v2]

> GraalVM Native Image supports loading classes at runtime if they are known > during image build (class predefinition). This is achieved by the JVMTI agent > that registers dynamically generated classes in a regular HotSpot run. The > Native Image build uses these registered classes to embed

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

On 2021-09-09 12:04, Magnus Ihse Bursie wrote: Let me be more concrete: I suggest adding a new overloaded method, publicvoidstore(Writerout, Stringcomments, boolean includeTimestamp) And somehow my email program managed to mess up the code formatting. :-( The signature I meant was of course:

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current

On Thu, 9 Sep 2021 09:21:59 GMT, Matthias Baesken wrote: > https://bugs.openjdk.java.net/browse/JDK-8266490 > extended the OSContainer API in order to also support the pids controller of > cgroups. However only pids.max output was added with 8266490. > There is a second parameter pids.current ,

Re: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test [v2]

On Wed, 8 Sep 2021 09:17:31 GMT, Aleksey Shipilev wrote: >> This test runs a lot of configurations, and spends a lot of time serially. >> This is especially pronounced when run in prospective tier4 runs >> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We >> can

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

On 2021-09-09 10:27, Jaikiran Pai wrote: On 31/08/21 7:09 pm, Jaikiran Pai wrote: Hello Magnus, On 30/08/21 5:29 pm, Magnus Ihse Bursie wrote: On 2021-08-28 17:16, Alan Bateman wrote: On 28/08/2021 05:45, Jaikiran Pai wrote: I hadn't considered the system property approach to switch to

Re: RFR: 8231640: (prop) Canonical property storage [v7]

> The commit in this PR implements the proposal for enhancement that was > discussed in the core-libs-dev mailing list recently[1], for > https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to > now look for the

RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current

https://bugs.openjdk.java.net/browse/JDK-8266490 extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. There is a second parameter pids.current , see

Re: RFR: 8273513: Make java.io.FilterInputStream specification more precise about overrides

On Wed, 8 Sep 2021 22:00:53 GMT, Brian Burkhalter wrote: > Modify the class level specification of `java.io.FilterInputStream` to be > more exact about `java.io.InputStream` methods that it overrides. LGTM. The use of `synchronized` on `mark()` and `reset()` is strange. But I guess that

Re: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v2]

On Thu, 9 Sep 2021 08:25:44 GMT, Wu Yan wrote: >> Hi, >> Please help me review the change to enhance getting time zone ID from >> /etc/localtime on linux. >> >> We use `realpath` instead of `readlink` to obtain the link name of >> /etc/localtime, because `readlink` can only read the value of

Re: RFR: 8231640: (prop) Canonical property storage [v6]

On Thu, 9 Sep 2021 05:46:34 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was >> discussed in the core-libs-dev mailing list recently[1], for >> https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

On 31/08/21 7:09 pm, Jaikiran Pai wrote: Hello Magnus, On 30/08/21 5:29 pm, Magnus Ihse Bursie wrote: On 2021-08-28 17:16, Alan Bateman wrote: On 28/08/2021 05:45, Jaikiran Pai wrote: I hadn't considered the system property approach to switch to old behaviour in my proposals, so this is

Re: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v2]

> Hi, > Please help me review the change to enhance getting time zone ID from > /etc/localtime on linux. > > We use `realpath` instead of `readlink` to obtain the link name of > /etc/localtime, because `readlink` can only read the value of a symbolic of > link, not the canonicalized absolute

Re: RFR: 8273487: Zero: Handle "zero" variant in runtime tests [v2]

On Wed, 8 Sep 2021 13:25:27 GMT, Aleksey Shipilev wrote: >> JDK-8179317 rewritten runtime shell tests to Java. There is a little >> omission in VM variant selection, which makes Zero fail some of the tier1 >> tests, like: >> >> >> $ CONF=linux-x86_64-zero-fastdebug make exploded-test >>

Integrated: 8273487: Zero: Handle "zero" variant in runtime tests

On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev wrote: > JDK-8179317 rewritten runtime shell tests to Java. There is a little omission > in VM variant selection, which makes Zero fail some of the tier1 tests, like: > > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test >

Integrated: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test

On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote: > This test runs a lot of configurations, and spends a lot of time serially. > This is especially pronounced when run in prospective tier4 runs > (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can >

Re: RFR: 8231640: (prop) Canonical property storage [v3]

On 09/09/21 12:51 am, Stuart Marks wrote: On Wed, 8 Sep 2021 09:32:55 GMT, Jaikiran Pai wrote: Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: - adjust testcases to verify the new semantics - implement review suggestions:

Re: [External] : Re: RFR: 8231640: (prop) Canonical property storage

Hello Stuart, On 09/09/21 12:35 am, Stuart Marks wrote: Unless there's an overriding reason, it might be nice to have the output format match the format used in the Debian patch that adds SOURCE_DATE_EPOCH: