Re: RFR: 8264859: Implement Context-Specific Deserialization Filters [v3]

On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the >> deserialization filtering mechanisms with more flexible and customizable >> protections against malicious deserialization. See JEP 415: >>

Re: RFR: 8224243: Make AccessibleObject a sealed class

Hi Joe, I see that I blogged about AccessibleObject in 2006 and already complained about its protected constructor back then. :-) Still, if the main motivation of sealing it is to avoid adding @implSpec to a few methods, perhaps it

RFR: 8267403: tools/jpackage/share/FileAssociationsTest.java#id0 failed with "Error: Bundler "Mac PKG Package" (pkg) failed to produce a package"

Looks like another issue similar to hdiutil (JDK-8249395) when process is gone, but we still waiting for it. I was not able to reproduce this issue by running test or pkgbuild separately and conclusion was made based on logs. Fixed in same way as hdiutil issue. Also, I added logging PID for

Re: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v3]

On Thu, 20 May 2021 22:13:51 GMT, Gavin Bierman wrote: >> Hi all, >> >> Please review this patch to make the ConstantDesc hierarchy `sealed`, as was >> promised in its Javadoc, now that sealed classes are finalising in JDK 17. >> >> Thanks, >> Gavin > > Gavin Bierman has updated the pull

Re: RFR: 8264859: Implement Context-Specific Deserialization Filters [v3]

On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the >> deserialization filtering mechanisms with more flexible and customizable >> protections against malicious deserialization. See JEP 415: >>

Re: RFR: 8224243: Make AccessibleObject a sealed class [v2]

On Fri, 21 May 2021 02:42:50 GMT, Joe Darcy wrote: >> Conceptually, AccessbileObject is a sealed class with a protected >> constructor stating >> >> Constructor: only used by the Java Virtual Machine. >> >> With the language now supporting sealed classes, the AccessbileObject should >>

Re: RFR: 8224243: Make AccessibleObject a sealed class [v2]

> Conceptually, AccessbileObject is a sealed class with a protected constructor > stating > > Constructor: only used by the Java Virtual Machine. > > With the language now supporting sealed classes, the AccessbileObject should > be marked as sealed. > > Executable and Field are the

Re: RFR: 8224243: Make AccessibleObject a sealed class

Thanks for the tip, Alan. Guava's public Invokable class does inherit from AccessibleObject. It would probably not be too hard to make it stop doing so. That's technically a breaking API change, but the

RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K

The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other

Re: jpackage GraalVM on Windows 10

> On May 20, 2021, at 6:45 PM, Michael Hall wrote: > > Has anyone done this who can indicate how it should be done? > It seems to be the non-standard JDK name. I renamed it to jdk-11 and it worked. Letting it default still set it to the current jdk-16 even though that was later in PATH.

Integrated: 8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException

On Wed, 19 May 2021 21:00:07 GMT, Alexander Matveev wrote: > For debug build on macOS, runtime which used for test fill be located in > /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files > except fastdebug and in this case our check to decide if we need to copy app > or

jpackage GraalVM on Windows 10

Has anyone done this who can indicate how it should be done? I recently set this up for my app on OS/X and thought I’d have cross platform versions. I have tried it both with —runtime-image and making Graal the installed JVM. Both ways I seem to get an application with directory structure

Re: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2]

On Thu, 20 May 2021 22:35:38 GMT, Thiago Henrique Hüpner wrote: >> I should have made it clear. I was expecting `DynamicConstantDesc` should >> be `sealed`. Do you expect non-JDK implementation class extending >> `DynamicConstantDesc`? > > From the ConstantDesc Javadoc: > > * Non-platform

Re: RFR: 8267190: Optimize Vector API test operations [v3]

On Thu, 20 May 2021 23:19:01 GMT, Sandhya Viswanathan wrote: >> Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and >> IS_NEGATIVE) are computed in three steps: >> 1) reinterpreting the floating point vectors as integral vectors (int/long) >> 2) perform the test in

Re: RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException [v2]

On Thu, 20 May 2021 22:25:10 GMT, Alexander Matveev wrote: >> For debug build on macOS, runtime which used for test fill be located in >> /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files >> except fastdebug and in this case our check to decide if we need to copy app

Re: RFR: 8267190: Optimize Vector API test operations [v3]

> Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and > IS_NEGATIVE) are computed in three steps: > 1) reinterpreting the floating point vectors as integral vectors (int/long) > 2) perform the test in integer domain to get a int/long mask > 3) reinterpret the int/long mask

Re: RFR: 8266310: deadlock while loading the JNI code [v2]

Hi Peter, On 21/05/2021 12:42 am, Peter Levart wrote: Hi Aleksei, Are you trying to solve this in principle or do you have a concrete problem at hand which triggers this deadlock? If it is the later, then some rearrangement of code might do the trick... For example, native libraries are

Re: RFR: 8224243: Make AccessibleObject a sealed class

Hi Éamonn, On 5/20/2021 2:59 PM, Éamonn McManus wrote: Thanks for the tip, Alan. Guava's public Invokable class does inherit from AccessibleObject. It would probably not be too hard to make it stop

Re: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2]

On Thu, 20 May 2021 22:28:56 GMT, Mandy Chung wrote: >> It's a permitted subclass of `ConstantDesc`, so it must be either `final`, >> `sealed`, or `non-sealed`. Making it `non-sealed` means it can still be >> extended. > > I should have made it clear. I was expecting `DynamicConstantDesc`

Re: RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException [v2]

On Thu, 20 May 2021 22:25:10 GMT, Alexander Matveev wrote: >> For debug build on macOS, runtime which used for test fill be located in >> /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files >> except fastdebug and in this case our check to decide if we need to copy app

Re: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2]

On Thu, 20 May 2021 22:17:03 GMT, Gavin Bierman wrote: >> src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java line >> 59: >> >>> 57: * @since 12 >>> 58: */ >>> 59: non-sealed public abstract class DynamicConstantDesc >> >> can you explain why `DynamicConstantDesc` is

Re: RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException [v2]

On Thu, 20 May 2021 16:15:21 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8267056: tools/jpackage/share/RuntimePackageTest.java fails with >> NoSuchFileException [v2] > >

Re: RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException [v2]

> For debug build on macOS, runtime which used for test fill be located in > /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files > except fastdebug and in this case our check to decide if we need to copy app > or runtime will return /path/jdk-17 which is not correct. Fixed

Re: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2]

On Thu, 20 May 2021 21:32:08 GMT, Mandy Chung wrote: >> Gavin Bierman has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Removing javadoc comments about future use of sealed > >

Re: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v3]

> Hi all, > > Please review this patch to make the ConstantDesc hierarchy `sealed`, as was > promised in its Javadoc, now that sealed classes are finalising in JDK 17. > > Thanks, > Gavin Gavin Bierman has updated the pull request incrementally with one additional commit since the last

Re: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2]

On Thu, 20 May 2021 21:32:05 GMT, Gavin Bierman wrote: >> Hi all, >> >> Please review this patch to make the ConstantDesc hierarchy `sealed`, as was >> promised in its Javadoc, now that sealed classes are finalising in JDK 17. >> >> Thanks, >> Gavin > > Gavin Bierman has updated the pull

Re: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2]

> Hi all, > > Please review this patch to make the ConstantDesc hierarchy `sealed`, as was > promised in its Javadoc, now that sealed classes are finalising in JDK 17. > > Thanks, > Gavin Gavin Bierman has updated the pull request incrementally with one additional commit since the last

Re: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams

Hello, Hm, how is that list used? - StandardCharaet.ISO_8859_1 is a guaranteed Charset for JVM, and since the encoding is done in Java it should be fine. Added benefit is, it’s 8bit transparent. As for OS there is not a single standard charset (ebcdic vs latin families) but ASCII is probably

Re: RFR: 8267190: Optimize Vector API test operations [v2]

On Thu, 20 May 2021 01:27:48 GMT, Sandhya Viswanathan wrote: >> Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and >> IS_NEGATIVE) are computed in three steps: >> 1) reinterpreting the floating point vectors as integral vectors (int/long) >> 2) perform the test in

RFR: 8265130: Make ConstantDesc class hierarchy sealed

Hi all, Please review this patch to make the ConstantDesc hierarchy `sealed`, as was promised in its Javadoc, now that sealed classes are finalising in JDK 17. Thanks, Gavin - Commit messages: - 8265130: Make ConstantDesc class hierarchy sealed Changes:

Re: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams

On Thu, 20 May 2021 20:46:36 GMT, Roger Riggs wrote: >> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 64: >> >>> 62: return new Object[][] { >>> 63: {"UTF-8"}, >>> 64: {"ISO8859-1"}, >> >> `ISO8859-1` may not be available on all underlying

Re: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams

On Thu, 20 May 2021 20:42:35 GMT, Naoto Sato wrote: >> Methods are added to java.lang.Process to read and write characters and >> lines from and to a spawned Process. >> The Charset used to encode and decode characters to bytes can be specified >> or use the >> operating system native encoding

Re: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams

On Thu, 20 May 2021 19:57:22 GMT, Roger Riggs wrote: > Methods are added to java.lang.Process to read and write characters and lines > from and to a spawned Process. > The Charset used to encode and decode characters to bytes can be specified or > use the > operating system native encoding as

Re: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams

On Thu, 20 May 2021 20:12:07 GMT, Rémi Forax wrote: > I don't think that using PrintWriter is a good idea here given that a > PrintWriter shallow the IOException Good point, but... PrintStream does also and it is used frequently for Stdout and Stderr. OutputStreamWriter would be a better

Re: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams

On Thu, 20 May 2021 19:57:22 GMT, Roger Riggs wrote: > Methods are added to java.lang.Process to read and write characters and lines > from and to a spawned Process. > The Charset used to encode and decode characters to bytes can be specified or > use the > operating system native encoding as

RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams

Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process. The Charset used to encode and decode characters to bytes can be specified or use the operating system native encoding as is available from the "native.encoding" system property.

Re: RFR: 8264859: Implement Context-Specific Deserialization Filters [v3]

On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the >> deserialization filtering mechanisms with more flexible and customizable >> protections against malicious deserialization. See JEP 415: >>

Re: RFR: 8264859: Implement Context-Specific Deserialization Filters [v3]

On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the >> deserialization filtering mechanisms with more flexible and customizable >> protections against malicious deserialization. See JEP 415: >>

Re: Suppressed IllegalAccessException in MethodHandle.setVarargs

This seems a good improvement.  I created https://bugs.openjdk.java.net/browse/JDK-8267509 for this issue. How did you run into this illegal varargs method?  Is that class file generated at runtime? Mandy On 5/20/21 10:18 AM, x4e_x4e wrote: Hello, If a MethodHandles.Lookup is used to

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >>

Make java.lang.constant.ConstantDesc selead

Now that Sealed classes are integrated, should be the moment to seal the ConstantDesc class and its subclasses, or would be better to wait a little bit more? Best regards Thiago

Re: RFR: 8264859: Implement Context-Specific Deserialization Filters [v3]

On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the >> deserialization filtering mechanisms with more flexible and customizable >> protections against malicious deserialization. See JEP 415: >>

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v24]

On Wed, 28 Apr 2021 08:20:05 GMT, Chris Hegarty wrote: >> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 466: >> >>> 464: } >>> 465: >>> 466: private static final JavaNioAccess NIO_ACCESS = >>> SharedSecrets.getJavaNioAccess(); >> >> It might be cleaner to move to

Re: RFR: 8224243: Make AccessibleObject a sealed class

On Thu, 20 May 2021 17:14:57 GMT, Joe Darcy wrote: > Conceptually, AccessbileObject is a sealed class with a protected constructor > stating > > Constructor: only used by the Java Virtual Machine. > > With the language now supporting sealed classes, the AccessbileObject should > be

RFR: 8224243: Make AccessibleObject a sealed class

Conceptually, AccessbileObject is a sealed class with a protected constructor stating Constructor: only used by the Java Virtual Machine. With the language now supporting sealed classes, the AccessbileObject should be marked as sealed. Executable and Field are the subclasses of

Re: RFR: 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates [v2]

On Tue, 8 Dec 2020 05:54:24 GMT, Martin Buchholz wrote: >> 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates > > Martin Buchholz has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences >

Re: RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException

On Wed, 19 May 2021 21:00:07 GMT, Alexander Matveev wrote: > For debug build on macOS, runtime which used for test fill be located in > /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files > except fastdebug and in this case our check to decide if we need to copy app > or

Re: RFR: 8264859: Implement Context-Specific Deserialization Filters [v3]

> JEP 415: Context-specific Deserialization Filters extends the deserialization > filtering mechanisms with more flexible and customizable protections against > malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. > The `java.io.ObjectInputFilter` and

Re: RFR: 8266310: deadlock while loading the JNI code [v2]

Hi Aleksei, Are you trying to solve this in principle or do you have a concrete problem at hand which triggers this deadlock? If it is the later, then some rearrangement of code might do the trick... For example, native libraries are typically loaded by a class initializer of some class that

Integrated: 8261880: Change nested classes in java.base to static nested classes where possible

On Tue, 16 Feb 2021 14:30:58 GMT, Сергей Цыпанов wrote: > Non-static classes hold a link to their parent classes, which in many cases > can be avoided. This pull request has now been integrated. Changeset: 9425d3de Author:Sergey Tsypanov Committer: Claes Redestad URL:

Re: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2]

On Wed, 17 Feb 2021 16:38:03 GMT, Сергей Цыпанов wrote: >> Non-static classes hold a link to their parent classes, which in many cases >> can be avoided. > > Сергей Цыпанов has updated the pull request incrementally with one additional > commit since the last revision: > > 8261880: Remove

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v24]

On Thu, 20 May 2021 13:00:14 GMT, Maurizio Cimadamore wrote: >> Maurizio Cimadamore 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 35 >>

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v24]

On Thu, 20 May 2021 13:05:22 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2]

On Thu, 20 May 2021 10:42:49 GMT, Claes Redestad wrote: >> Сергей Цыпанов has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8261880: Remove static from declarations of Holder nested classes > > Marked as reviewed by redestad (Reviewer).

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v24]

> This PR contains the API and implementation changes for JEP-412 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v24]

On Thu, 20 May 2021 13:00:15 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8266310: deadlock while loading the JNI code [v3]

On Wed, 19 May 2021 16:29:33 GMT, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between the >> two lock objects - a lock object associated with the class being loaded, and >> the ClassLoader.loadedLibraryNames hash map, locked during the native >>

Re: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2]

On Wed, 17 Feb 2021 16:38:03 GMT, Сергей Цыпанов wrote: >> Non-static classes hold a link to their parent classes, which in many cases >> can be avoided. > > Сергей Цыпанов has updated the pull request incrementally with one additional > commit since the last revision: > > 8261880: Remove

RFR: 8267452: Delegate forEachRemaining in Spliterators.iterator()

Sometimes, `Spliterator::forEachRemaining` has much more optimized implementation, compared to `Spliterator::tryAdvance`. For example, if a `Stream::spliterator` called for a stream that has intermediate operations, `tryAdvance()` may buffer intermediate elements while `forEachRemaining()` just

Integrated: 8260517: implement Sealed Classes as a standard feature in Java

On Fri, 16 Apr 2021 01:08:57 GMT, Vicente Romero wrote: > Please review this PR that intents to make sealed classes a final feature in > Java. This PR contains compiler and VM changes. In line with similar PRs, > which has made preview features final, this one is mostly removing preview >

Re: JEP draft: Scope Locals

On 5/19/21 10:51 PM, David Lloyd wrote: > I think it would be really nice if the snapshot class could hold its > run/call method rather than making it a static method of `ScopeLocal`. This > reads more naturally to me (and is nicer to write): True, but inheritance is *extremely* time-critical

Re: JEP draft: Scope Locals

On 5/19/21 9:55 PM, David Lloyd wrote: > Turning this around, I would argue that there are few (or perhaps *no*) > cases where it would ever be desirable to inherit scope locals across > thread creation; in cases where this is explicitly desired, one can always > resume the snapshot from within

Re: JEP draft: Scope Locals

On 5/19/21 5:55 PM, Peter Levart wrote: > In other words, non-inheritable bindings are > never transferred from thread to thread automatically or by > snapshot/runWithSnapshot. I can see that snapshot/runWithSnapshot was > meant as a mechanism to "simulate" inheritance of bindings when >

Re: JEP draft: Scope Locals

On 5/15/21 6:15 PM, Remi Forax wrote: > I think the JEP should be more explicit about the shortcoming of ThreadLocal > and how the design of scope local fix both issues. Yes. It's in progress. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd.

Re: [External] : Re: ReversibleCollection proposal

On 20/05/2021 08:35, dfranken@gmail.com wrote: I also think the proposal of Stuart is reasonable though, but it seemed to me that we had reached some sort of impasse in this discussion. As Remi points out, we have (default) methods which sometimes throw exceptions when they are implemented

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

On Thu, 20 May 2021 04:22:32 GMT, Phil Race wrote: >> That is unfortunate, but nonetheless I think required to be done. >> We have acknowledeged this can't reasonably be called an RFE, so the JEP is >> introducing bugs/technical debt/call it what you will. This should generally >> be part of a

Re: RFR: 8203359: Container level resources events [v14]

> With this change it becomes possible to surface various cgroup level metrics > (available via `jdk.internal.platform.Metrics`) as JFR events. > > Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is > turned into JFR events to start with. > * CPU related metrics > *

Re: RFR: 8203359: Container level resources events [v9]

On Wed, 19 May 2021 17:21:26 GMT, Erik Gahlin wrote: > I think you need to add the hook, for the event metadata to be correct. > Otherwise, the "period" setting will not show up. Yes. The failed test log would indicate also the rest of the metadata not being in a good shape. But with the hook

Re: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2]

On Wed, 17 Feb 2021 16:38:03 GMT, Сергей Цыпанов wrote: >> Non-static classes hold a link to their parent classes, which in many cases >> can be avoided. > > Сергей Цыпанов has updated the pull request incrementally with one additional > commit since the last revision: > > 8261880: Remove

Re: [External] : Re: ReversibleCollection proposal

Dear Brian, I understand this would be a massive undertaking. Still, the date-time library was a mess before Java 8 and it has been rewritten and found its way to most other libraries. So while I understand this isn't going to be done any time soon, my only question was whether it had been