Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5]

On Mon, 25 Apr 2022 20:48:54 GMT, Lance Andersen wrote: >> Alan Bateman has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Refresh > > test/jdk/jdk/internal/vm/Continuation/Basic.java line 327: > >> 325: >> 326: // @Test >> 327:

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]

On Sun, 17 Apr 2022 04:57:34 GMT, Jaikiran Pai 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 five additional >>

Re: JEP 411: Deprecation with removal would break most existing Java libraries

The JEP addresses this: > In future JDK releases, we will degrade the Security Manager APIs so that > they remain in place but have limited or no functionality. ... This will allow libraries that support the Security Manager and were compiled against previous Java releases to continue to

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

I think you’re coming to this discussion with a very different perspective from us, which makes understanding what is or isn’t on the table unclear, and also steers the ideas in directions that are different from the one we’re going. Our goal is not to maintain some status quo until such time

Re: RFC: 8200559: Java agents doing instrumentation need a means to define auxiliary classes

Hi Rafael! The use cases you mention might be legitimate, but why are they legitimate *for agents*? For example, why can’t the Replacement class be defined in a regular library, not injected by the agent? As to the existence of Unsafe hacks and others, those are going away, so “we can do

RFR 10: JDK-8161207: Remove extra MethodHandle subclass in MethodHandleImpl

Hi. Please review, Bug: https://bugs.openjdk.java.net/browse/JDK-8161207 Webrev: http://cr.openjdk.java.net/~rpressler/jdk10/JDK-8161207-intrinsicmethodhandle/webrev/

Re: RFR 10 JDK-8159995: Rename internal Unsafe.compare methods

Thank you. Your comments, and Paul's, have all been addressed in a revised patch (same webrev). Ron On 08/05/2017 08:30, David Holmes wrote: Hi Ron, On 6/05/2017 5:27 AM, Ron Pressler wrote: Hi, Please review the following core/hotspot change: Bug: https://bugs.openjdk.java.net/browse

RFR 9 JDK-8180075: Javadoc of MethodHandles.Lookup::bind should note the difference from MethodHandle::bindTo introduced by JDK-8177146

Hi. Please review the following doc-only patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8180075 There is no change in specification, only an elaboration on a note. Ron diff -r fc53a0468c1f src/java.base/share/classes/java/lang/invoke/MethodHandles.java ---

JDK 10 RFR JDK-8174267: Stream.findFirst unnecessarily always allocates an Op

Hi. Please review the following patch, which creates static final instances of FindOp. Bug: https://bugs.openjdk.java.net/browse/JDK-8174267 I believe an additional test is not required as this is an implementation detail. --- diff -r 83d37efcd2a5

JDK 10 RFR JDK-8177153: LambdaMetafactory has default constructor

Hi. Please review this trivial fix: --- diff -r 83d37efcd2a5 src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java --- a/src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java Thu Apr 13 20:35:17 2017 + +++

Re: JDK 9 RFR: JDK-8177146 MethodHandles.Lookup::bind allows illegal protected access

jtreg tag to refer to the fixed bug from the test. Best regards, Vladimir Ivanov On 4/26/17 7:50 PM, Ron Pressler wrote: Hi. Please review, Bug: https://bugs.openjdk.java.net/browse/JDK-8177146 Webrev: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8177146-bind-protected-method/webrev

JDK 9 RFR: JDK-8177146 MethodHandles.Lookup::bind allows illegal protected access

Hi. Please review, Bug: https://bugs.openjdk.java.net/browse/JDK-8177146 Webrev: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8177146-bind-protected-method/webrev/ - The patch contains a few changes: 1. The method `getDirectMethodCommon`, was changed so that if narrowing due to

Re: Process API Updates (JEP 102)

descriptors to the specific memory mapping and there may be others. Roger On 8/26/2014 7:25 AM, Ron Pressler wrote: I might be a little late to this party, but recently I've had a (rather frustrating) need for the ability to execve a process rather than fork-exec it. I understand

Process API Updates (JEP 102)

I might be a little late to this party, but recently I've had a (rather frustrating) need for the ability to execve a process rather than fork-exec it. I understand that the ability to exec (replace the current process's image) is also available on Windows. This operation (on ProcessBuilder?),