Re: RFR: 8230501: Class data support for hidden classes [v5]

2020-11-20 Thread Mandy Chung
> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live > objects > be shared between a hidden class and other classes. A hidden class can load > these live objects as dynamically-computed constants via this API. > > Specdiff >

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

2020-11-20 Thread Roger Baumgartner
On Wed, 18 Nov 2020 13:45:12 GMT, Jim Laskey wrote: > This PR is to introduce a new random number API for the JDK. The primary API > is found in RandomGenerator and RandomGeneratorFactory. Further description > can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be

Re: RFR: 8256480: Refactor ObjectInputStream field reader implementation [v2]

2020-11-20 Thread Brent Christian
On Thu, 19 Nov 2020 20:32:17 GMT, Roger Riggs wrote: >> ObjectInputStream has nearly identical but separate implementations to read >> values from the stream. >> Both implementations read primitive and object values from the stream and >> return an object holding the values. >>

Re: RFR: 8247432: Update IANA Language Subtag Registry to Version 2020-09-29

2020-11-20 Thread Joe Wang
On Fri, 20 Nov 2020 17:55:55 GMT, Naoto Sato wrote: > Hi, > > Please review the changes to the subject issue. This is to incorporate the > latest language subtag registry definition into the JDK. Marked as reviewed by joehw (Reviewer). - PR:

Re: RFR: 8159746: (proxy) Support for default methods

2020-11-20 Thread Peter Levart
On Fri, 20 Nov 2020 20:14:23 GMT, Mandy Chung wrote: >> Hi Mandy, >> thanks for taking the time to explore all the different options, >> >> The solution 1 is fine for me. > > Thanks Remi. I agree solution 1 is the best after all things considered. - PR:

Re: RFR: 8230501: Class data support for hidden classes [v4]

2020-11-20 Thread Jorn Vernee
On Fri, 20 Nov 2020 20:23:27 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2148: >> >>> 2146: * (unlike private static fields that are accessible to >>> nestmates). >>> 2147: * Care should be taken w.r.t. mutability for

Re: RFR: 8230501: Class data support for hidden classes [v4]

2020-11-20 Thread Mandy Chung
On Thu, 19 Nov 2020 10:59:30 GMT, Jorn Vernee wrote: >> Mandy Chung has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix the name passed to condy calling classData > > src/java.base/share/classes/java/lang/invoke/MethodHandles.java line

Integrated: 8256183: InputStream.skipNBytes is missing @since 12

2020-11-20 Thread Conor Cleary
On Thu, 19 Nov 2020 12:35:04 GMT, Conor Cleary wrote: > InputStream.skipNBytes is missing `@since 12` tag which was not added during > the review of [JDK-6516099](https://bugs.openjdk.java.net/browse/JDK-6516099). > > This small fix adds the `@since` tag to InputStream.skipNBytes This pull

Re: RFR: 8159746: (proxy) Support for default methods

2020-11-20 Thread Mandy Chung
On Fri, 20 Nov 2020 20:06:38 GMT, Rémi Forax wrote: >> I have a fresh look at the different options we have explored (lots of >> challenges in finding the right API with security, usability and performance >> issues to consider). I agree with Remi that we should keep the design and >> API

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Stuart Marks
On Fri, 20 Nov 2020 19:59:52 GMT, Mandy Chung wrote: >> Alan Bateman 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 four additional >> commits

Re: RFR: 8159746: (proxy) Support for default methods

2020-11-20 Thread Rémi Forax
On Fri, 20 Nov 2020 19:51:57 GMT, Mandy Chung wrote: >> @plevart I'm okay with this slight performance improvement. > > I have a fresh look at the different options we have explored (lots of > challenges in finding the right API with security, usability and performance > issues to consider).

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Mandy Chung
On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman wrote: >> This change terminally deprecates the following methods defined by >> java.lang.ThreadGroup >> >> - stop >> - destroy >> - isDestroyed >> - setDaemon >> - isDaemon >> >> The stop method has been deprecated since=1.2 because it is

Re: RFR: 8159746: (proxy) Support for default methods

2020-11-20 Thread Mandy Chung
On Fri, 20 Nov 2020 19:11:54 GMT, Mandy Chung wrote: >> In my previous attempts when I was modifying the ProxyGenerator I noticed >> that generated proxy fields holding Method objects are just "static" but >> could be "static final". If they were "static final", JIT could >> constant-fold the

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Iris Clark
On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman wrote: >> This change terminally deprecates the following methods defined by >> java.lang.ThreadGroup >> >> - stop >> - destroy >> - isDestroyed >> - setDaemon >> - isDaemon >> >> The stop method has been deprecated since=1.2 because it is

Re: RFR: 8159746: (proxy) Support for default methods

2020-11-20 Thread Mandy Chung
On Fri, 20 Nov 2020 11:18:32 GMT, Peter Levart wrote: >> Hi Mandy, >> I re-ran the benchmark on your latest version (the static API) and I get >> similar results as you: >> >> Benchmark Mode Cnt Score Error Units >> ProxyBench.implClassavgt5 3.745 ± 0.033 ns/op

Re: RFR: 8159746: (proxy) Support for default methods [v6]

2020-11-20 Thread Mandy Chung
> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke > the given default method on the given proxy instance. > > The implementation looks up a method handle for `invokespecial` instruction > as if called from with the proxy class as the caller, equivalent to calling >

Re: RFR: 8256154: Some TestNG tests require default constructors

2020-11-20 Thread Brian Burkhalter
On Thu, 19 Nov 2020 13:50:30 GMT, Conor Cleary wrote: > In TestNG 7, it is a requirement that TestNG is able to create a Test object > using a default constructor. > > This simple fix addresses two such classes so that this requirement is > satisfied by inserting default construtors.

Integrated: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem

2020-11-20 Thread Poonam Bajaj
On Thu, 19 Nov 2020 01:22:01 GMT, Poonam Bajaj wrote: > Hi, > > Please review this simple change that catches UncheckedIOException that can > occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the > system, or if there is an interrupt while these are being read. > >

Integrated: 8037384: Fix wording in Javadoc of java.io.Serializable

2020-11-20 Thread Stuart Marks
On Thu, 19 Nov 2020 03:44:10 GMT, Stuart Marks wrote: > 8231547: Serializable class doc should link to serialization specification > > Rewrite a couple confusing sentences in the Serializable class doc. This does > affect normative text, but the edits are primarily to focus and clarify the >

Re: RFR: 8256154: Some TestNG tests require default constructors

2020-11-20 Thread Daniel Fuchs
On Fri, 20 Nov 2020 09:37:19 GMT, Conor Cleary wrote: >> Ah, missed the final on depth :-) > > Any particular strengths associated with `this(0)` as opposed to the actual > assignment? Aside from the brevity it provides of course. Happy to modify the > PR to include it My personal preference

Re: RFR: 8256154: Some TestNG tests require default constructors

2020-11-20 Thread Daniel Fuchs
On Thu, 19 Nov 2020 13:50:30 GMT, Conor Cleary wrote: > In TestNG 7, it is a requirement that TestNG is able to create a Test object > using a default constructor. > > This simple fix addresses two such classes so that this requirement is > satisfied by inserting default construtors.

RFR: 8247432: Update IANA Language Subtag Registry to Version 2020-09-29

2020-11-20 Thread Naoto Sato
Hi, Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK. - Commit messages: - LSR 2020-09-29 - LSR 2020-07-17 Changes: https://git.openjdk.java.net/jdk/pull/1357/files Webrev:

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Sergey Bylokhov
On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman wrote: >> This change terminally deprecates the following methods defined by >> java.lang.ThreadGroup >> >> - stop >> - destroy >> - isDestroyed >> - setDaemon >> - isDaemon >> >> The stop method has been deprecated since=1.2 because it is

Integrated: 8211449: Correction to the spec of implicit negative subpattern in DecimalFormat

2020-11-20 Thread Naoto Sato
On Thu, 19 Nov 2020 17:15:11 GMT, Naoto Sato wrote: > Hi, > > Please review this doc only fix to the class description of `DecimalFormat` > class. `localized minus sign` has never been (and should never be) used in > the implicit negative subpattern. Actual implementation correctly uses ascii

Re: RFR: 8246739: InputStream.skipNBytes could be implemented more efficiently [v3]

2020-11-20 Thread Brian Burkhalter
> Please review this modification of `java.io.InputStream.skipNBytes(long)` to > improve its performance when `skip(long)` skips fewer than the requested > number of bytes. In the current implementation, `skip(long)` is invoked once > and, if not enough bytes have been skipped, then `read()` is

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Alan Bateman
On Fri, 20 Nov 2020 16:05:24 GMT, Sean Mullan wrote: > If you agree, I can file an issue. Yes, make sense to separate this out, esp. permission targets such as "stopThread" where all usages are in deprecated methods. However, I don't expect "modifyThreadGroup" would be deprecated, at least

Re: RFR: 8246739: InputStream.skipNBytes could be implemented more efficiently [v2]

2020-11-20 Thread Brian Burkhalter
On Fri, 20 Nov 2020 11:43:11 GMT, sergus13 wrote: >> Brian Burkhalter has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - 8246739: InputStream.skipNBytes could be implemented more efficiently >> - 8246739: InputStream.skipNBytes could

Integrated: 8235304: JPackage Windows test should be added to set Publisher

2020-11-20 Thread Alexey Semenyuk
On Thu, 19 Nov 2020 22:00:01 GMT, Alexey Semenyuk wrote: > 8235304: JPackage Windows test should be added to set Publisher This pull request has now been integrated. Changeset: 11bfdc57 Author:Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/11bfdc57 Stats: 107 lines

Re: RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem [v3]

2020-11-20 Thread Bob Vandette
On Thu, 19 Nov 2020 20:49:16 GMT, Poonam Bajaj wrote: >> Hi, >> >> Please review this simple change that catches UncheckedIOException that can >> occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the >> system, or if there is an interrupt while these are being read. >>

Integrated: 8229845: Decrease memory consumption of BigInteger.toString()

2020-11-20 Thread Brian Burkhalter
On Thu, 22 Oct 2020 20:56:44 GMT, Brian Burkhalter wrote: > Please review this proposed fix. The review was initially in this thread > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061914.html > > under the old Hg SCM. The changes proposed here are derived from the final

Re: RFR: 8235304: JPackage Windows test should be added to set Publisher [v2]

2020-11-20 Thread Andy Herrick
On Thu, 19 Nov 2020 22:26:20 GMT, Alexey Semenyuk wrote: >> 8235304: JPackage Windows test should be added to set Publisher > > Alexey Semenyuk 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

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Sean Mullan
On Fri, 20 Nov 2020 15:50:11 GMT, Alan Bateman wrote: > > Ok, but then how about putting a similar note in the javadoc for the > > RuntimePermission "modifyThreadGroup" target? > > The "modifyThread" and "modifyThreadGroup" permission targets list methods > that have been terminally

Re: RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem [v3]

2020-11-20 Thread Severin Gehwolf
On Thu, 19 Nov 2020 20:49:16 GMT, Poonam Bajaj wrote: >> Hi, >> >> Please review this simple change that catches UncheckedIOException that can >> occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the >> system, or if there is an interrupt while these are being read. >>

Re: RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem [v3]

2020-11-20 Thread Severin Gehwolf
On Fri, 20 Nov 2020 09:27:56 GMT, Severin Gehwolf wrote: >> Poonam Bajaj has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Added UnchedkedIOException catch blocks for sumTokensIOStat and >> getLongEntry methods > > This seems OK.

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Alan Bateman
On Fri, 20 Nov 2020 15:27:14 GMT, Roger Riggs wrote: >> Alan Bateman 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 four additional >> commits

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Roger Riggs
On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman wrote: >> This change terminally deprecates the following methods defined by >> java.lang.ThreadGroup >> >> - stop >> - destroy >> - isDestroyed >> - setDaemon >> - isDaemon >> >> The stop method has been deprecated since=1.2 because it is

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Sean Mullan
On Fri, 20 Nov 2020 14:49:16 GMT, Alan Bateman wrote: > > I think it would be useful in the javadoc of the RuntimePermission targets > > (stopThread, etc) to add a note/link that the corresponding method that the > > permission applies to is terminally deprecated. Something as simple as > >

Re: RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem [v3]

2020-11-20 Thread Poonam Bajaj
On Fri, 20 Nov 2020 09:27:56 GMT, Severin Gehwolf wrote: >> Poonam Bajaj has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Added UnchedkedIOException catch blocks for sumTokensIOStat and >> getLongEntry methods > > This seems OK.

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Alan Bateman
> This change terminally deprecates the following methods defined by > java.lang.ThreadGroup > > - stop > - destroy > - isDestroyed > - setDaemon > - isDaemon > > The stop method has been deprecated since=1.2 because it is inherently > unsafe. It is time to terminally deprecate this

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v28]

2020-11-20 Thread Vladimir Ivanov
On Tue, 17 Nov 2020 11:49:26 GMT, Maurizio Cimadamore wrote: >> This patch contains the changes associated with the first incubation round >> of the foreign linker access API incubation >> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory >> access support (see JEP 393

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,…

2020-11-20 Thread Alan Bateman
On Fri, 20 Nov 2020 14:03:20 GMT, Sean Mullan wrote: > I think it would be useful in the javadoc of the RuntimePermission targets > (stopThread, etc) to add a note/link that the corresponding method that the > permission applies to is terminally deprecated. Something as simple as "Note > that

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,…

2020-11-20 Thread Alan Bateman
On Fri, 20 Nov 2020 14:05:09 GMT, Sean Mullan wrote: >> This change terminally deprecates the following methods defined by >> java.lang.ThreadGroup >> >> - stop >> - destroy >> - isDestroyed >> - setDaemon >> - isDaemon >> >> The stop method has been deprecated since=1.2 because it is

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,…

2020-11-20 Thread Sean Mullan
On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman wrote: > This change terminally deprecates the following methods defined by > java.lang.ThreadGroup > > - stop > - destroy > - isDestroyed > - setDaemon > - isDaemon > > The stop method has been deprecated since=1.2 because it is inherently

Re: RFR: 8229845: Decrease memory consumption of BigInteger.toString()

2020-11-20 Thread Claes Redestad
On Fri, 23 Oct 2020 08:19:01 GMT, Claes Redestad wrote: >> Please review this proposed fix. The review was initially in this thread >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061914.html >> >> under the old Hg SCM. The changes proposed here are derived from the

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3]

2020-11-20 Thread Alan Bateman
On Fri, 20 Nov 2020 03:27:54 GMT, Mandy Chung wrote: >> Good point -- case added. > > Looks good. testWithAddExportsInManifest create an executable JAR with "Add-Exports: java.base/sun.security.x509" in the manifest. It runs it twice, once without any options, the second with

Re: RFR: 8246739: InputStream.skipNBytes could be implemented more efficiently [v2]

2020-11-20 Thread sergus13
On Thu, 19 Nov 2020 20:20:17 GMT, Brian Burkhalter wrote: >> Please review this modification of `java.io.InputStream.skipNBytes(long)` to >> improve its performance when `skip(long)` skips fewer than the requested >> number of bytes. In the current implementation, `skip(long)` is invoked once

Re: RFR: 8159746: (proxy) Support for default methods

2020-11-20 Thread Peter Levart
On Fri, 20 Nov 2020 10:55:21 GMT, Peter Levart wrote: >> The trick is that if we know that a class like java.lang.invoke.Proxy may >> exist, >> it means that instead of distorting the j.l.r.Proxy API to increase of few >> percents the performance when calling a default method, you can come

Re: RFR: 8159746: (proxy) Support for default methods

2020-11-20 Thread Peter Levart
On Wed, 28 Oct 2020 20:13:19 GMT, Rémi Forax wrote: >> Hi Remi, >> >> I appreciate your proposal to modernize Proxy API. There are several >> requests for this enhancement to support default methods in Proxy. >> Defining a new `java.lang.invoke.Proxy` is a much bigger project that I >>

Re: RFR: 8246739: InputStream.skipNBytes could be implemented more efficiently [v2]

2020-11-20 Thread sergus13
On Thu, 19 Nov 2020 20:20:17 GMT, Brian Burkhalter wrote: >> Please review this modification of `java.io.InputStream.skipNBytes(long)` to >> improve its performance when `skip(long)` skips fewer than the requested >> number of bytes. In the current implementation, `skip(long)` is invoked once

Re: RFR: 8246739: InputStream.skipNBytes could be implemented more efficiently [v2]

2020-11-20 Thread sergus13
On Fri, 20 Nov 2020 09:56:16 GMT, sergus13 wrote: >> Brian Burkhalter has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - 8246739: InputStream.skipNBytes could be implemented more efficiently >> - 8246739: InputStream.skipNBytes could

Re: RFR: 8256154: Some TestNG tests require default constructors

2020-11-20 Thread Conor Cleary
On Thu, 19 Nov 2020 16:44:52 GMT, Lance Andersen wrote: >> `depth` is `final`, so it needs to be assigned. but this could be replaced >> with `this(0)` > > Ah, missed the final on depth :-) Any particular strengths associated with `this(0)` as opposed to the actual assignment? Aside from the

Re: RFR: 8256154: Some TestNG tests require default constructors

2020-11-20 Thread Conor Cleary
On Thu, 19 Nov 2020 15:09:30 GMT, Daniel Fuchs wrote: > Hi Conor, > > Were you able to verify that the two tests passed properly (and non > trivially) with both the current version of TestNG as well as the new version? > > best regards, > > -- daniel Hi Daniel, Yes, I was able to verify

Re: RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem [v3]

2020-11-20 Thread Severin Gehwolf
On Thu, 19 Nov 2020 20:49:16 GMT, Poonam Bajaj wrote: >> Hi, >> >> Please review this simple change that catches UncheckedIOException that can >> occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the >> system, or if there is an interrupt while these are being read. >>

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3]

2020-11-20 Thread David Holmes
Hi Alan, On 20/11/2020 6:04 pm, Alan Bateman wrote: On Fri, 20 Nov 2020 07:33:50 GMT, David Holmes wrote: I'm somewhat surprised by the extent of the other changes given the basic change here is to deprecate the option and change its default. I literally expected to see only 2 simple

Re: RFR: 8037384: Fix wording in Javadoc of java.io.Serializable [v2]

2020-11-20 Thread Chris Hegarty
On Thu, 19 Nov 2020 23:36:20 GMT, Stuart Marks wrote: >> 8231547: Serializable class doc should link to serialization specification >> >> Rewrite a couple confusing sentences in the Serializable class doc. This >> does affect normative text, but the edits are primarily to focus and clarify >>

Re: RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem [v2]

2020-11-20 Thread Severin Gehwolf
On Thu, 19 Nov 2020 20:49:07 GMT, Poonam Bajaj wrote: >> Shouldn't you add a check in >> src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java:sumTokensIOStat >> ? >> >> What about getLongEntry in >>

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3]

2020-11-20 Thread Alan Bateman
On Fri, 20 Nov 2020 07:33:50 GMT, David Holmes wrote: > I'm somewhat surprised by the extent of the other changes given the basic > change here is to deprecate the option and change its default. I literally > expected to see only 2 simple changes to the functional code: the deprecation >