On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Tue, 7 May 2024 08:43:09 GMT, Christoph Langer wrote:
>> While working in that area I found some potential for cleanup of a few tests.
>>
>> Most notably:
>>
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free
On Tue, 7 May 2024 08:43:09 GMT, Christoph Langer wrote:
>> While working in that area I found some potential for cleanup of a few tests.
>>
>> Most notably:
>>
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free
On Wed, 15 May 2024 08:21:36 GMT, Christoph Langer wrote:
>> 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 11 additional
>> c
On Wed, 15 May 2024 07:55:27 GMT, ExE Boss wrote:
> Note that this line is still not entirely correct, as for code like:
You are correct - the message is however consistent with what written in JEP
472. I'll discuss with @pron
-
PR Review Comment: https://git.openjdk.org/jdk/pull/
On Wed, 15 May 2024 06:15:35 GMT, Alan Bateman wrote:
>> So my recollection/understanding is that we use this mechanism to convert
>> module-related `--` flags passed to the VM into system properties that the
>> Java code can then read, but we set them up such that you are not allowed to
>> sp
On Mon, 22 Apr 2024 11:06:57 GMT, Christoph Langer wrote:
> While working in that area I found some potential for cleanup of a few tests.
>
> Most notably:
>
> B5045306.java:
> - does not need to run in othervm
> - the executor service that it uses should be shut down eventually to free
> reso
On Wed, 15 May 2024 08:21:36 GMT, Christoph Langer wrote:
>> 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 11 additional
>> c
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
> the use of JNI in the following ways:
>
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` metho
On Mon, 20 Nov 2023 14:58:05 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which proposes to fix an issue in
>> the JDK's HttpClient implementation, noted in
>> https://bugs.openjdk.org/browse/JDK-8308144?
>>
>> The HttpClient implementation internally uses
>> `java.ut
On Wed, 15 May 2024 10:34:01 GMT, Maurizio Cimadamore
wrote:
> I don't fully agree that this option is not module related (which is why I
> gave it that name). The very definition of illegal native access is related
> to native access occurring from a module that is outside a specific set. So
On Wed, 15 May 2024 05:06:02 GMT, Jaikiran Pai wrote:
> Can I please get a review of this doc-only change which clarifies the value
> type for the `java.net.SocketOptions.SO_LINGER` option?
src/java.base/share/classes/java/net/SocketOptions.java line 197:
> 195: * {@link #setOption(int, O
On Wed, 15 May 2024 10:40:34 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
> the use of JNI in the following ways:
>
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` metho
On Mon, 6 May 2024 18:36:24 GMT, Sergey Chernyshev
wrote:
>> There are two distinct approaches to parsing IPv4 literal addresses. One is
>> the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another
>> one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr`
On Tue, 12 Mar 2024 10:46:00 GMT, Michael McMahon wrote:
> Hi,
>
> This PR proposes to add simple utility method which returns a simple GET
> HttpRequest in one call. The current builder pattern requires 4 (or 3 since
> GET is the default method) method calls to achieve the same effect.
>
> T
16 matches
Mail list logo
