On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth wrote:
> Further, I confirm that if I pass that option to jlink or jpackage when
> creating a custom runtime, there is no warning.
Great! What about jpackage without a custom runtime, wondering if
--java-options can be tested.
-
On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth wrote:
> Further, I confirm that if I pass that option to jlink or jpackage when
> creating a custom runtime, there is no warning.
Great! What about jpackage without a custom runtime, wondering if
--java-options can be tested.
-
On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth wrote:
> Further, I confirm that if I pass that option to jlink or jpackage when
> creating a custom runtime, there is no warning.
Great! What about jpackage without a custom runtime, wondering if
--java-options can be tested.
-
On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth wrote:
> Further, I confirm that if I pass that option to jlink or jpackage when
> creating a custom runtime, there is no warning.
Great! What about jpackage without a custom runtime, wondering if
--java-options can be tested.
-
On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth wrote:
> Further, I confirm that if I pass that option to jlink or jpackage when
> creating a custom runtime, there is no warning.
Great! What about jpackage without a custom runtime, wondering if
--java-options can be tested.
-
On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth wrote:
> Further, I confirm that if I pass that option to jlink or jpackage when
> creating a custom runtime, there is no warning.
Great! What about jpackage without a custom runtime, wondering if
--java-options can be tested.
-
On Thu, 23 May 2024 03:28:30 GMT, Chen Liang wrote:
> Please review this change that convert dynamic proxies implementations to
> hidden classes, intended to target JDK 24.
>
> Summary:
> 1. Adds new implementation while preserving the old implementation behind
>
On Tue, 7 May 2024 22:23:48 GMT, Jonathan Gibbons wrote:
> A long vertical series of lines beginning /// is replaced by lines beginning
> //|.
This one looks unusual when it's just one line, I could imagine deleting the
"|" in these cases.
-
PR Comment:
On Tue, 7 May 2024 22:23:48 GMT, Jonathan Gibbons wrote:
> A long vertical series of lines beginning /// is replaced by lines beginning
> //|.
This one looks unusual when it's just one line, I could imagine deleting the
"|" in these cases.
-
PR Comment:
On Tue, 21 May 2024 16:59:38 GMT, Brent Christian wrote:
> Indeed - can't move forward without a CSR. Also wouldn't mind more reviewer
> ✔️s.
I can do that. One other thing to do is to rebase the changes, it looks like
this branch is 6 months behind main line.
-
PR Comment:
On Wed, 22 May 2024 05:16:42 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only change for addressing
> https://bugs.openjdk.org/browse/JDK-8332490?
>
> The jmh test opens a `InflaterInputStream`, reads the stream contents, but
> then doesn't close the stream. This can
JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one
change. The type of the operation parameter of the callWhere method is changed
to a new functional interface to avoid having the API throw Exception. With
that change, the getWhere (and the corresponding method on Carrier)
l sample of methods to
> ensure the changes doesn't cause any perf regressions ([sample
> results](https://cr.openjdk.org/~alanb/8331670-results.txt)).
>
> For now, the changes include the update to the man page for the "java"
> command. It might be that this has to be se
On Mon, 20 May 2024 18:47:35 GMT, Phil Race wrote:
> Have you looked into / thought about how this will work for jpackaged apps ?
> I suspect that both the existing FFM usage and this will be options the
> application packager will need to supply when building the jpackaged app -
> the end
On Mon, 20 May 2024 18:47:35 GMT, Phil Race wrote:
> Have you looked into / thought about how this will work for jpackaged apps ?
> I suspect that both the existing FFM usage and this will be options the
> application packager will need to supply when building the jpackaged app -
> the end
On Mon, 20 May 2024 18:47:35 GMT, Phil Race wrote:
> Have you looked into / thought about how this will work for jpackaged apps ?
> I suspect that both the existing FFM usage and this will be options the
> application packager will need to supply when building the jpackaged app -
> the end
On Mon, 20 May 2024 18:47:35 GMT, Phil Race wrote:
> Have you looked into / thought about how this will work for jpackaged apps ?
> I suspect that both the existing FFM usage and this will be options the
> application packager will need to supply when building the jpackaged app -
> the end
On Mon, 20 May 2024 18:47:35 GMT, Phil Race wrote:
> Have you looked into / thought about how this will work for jpackaged apps ?
> I suspect that both the existing FFM usage and this will be options the
> application packager will need to supply when building the jpackaged app -
> the end
On Mon, 20 May 2024 18:47:35 GMT, Phil Race wrote:
> Have you looked into / thought about how this will work for jpackaged apps ?
> I suspect that both the existing FFM usage and this will be options the
> application packager will need to supply when building the jpackaged app -
> the end
On Mon, 20 May 2024 18:47:35 GMT, Phil Race wrote:
> Have you looked into / thought about how this will work for jpackaged apps ?
> I suspect that both the existing FFM usage and this will be options the
> application packager will need to supply when building the jpackaged app -
> the end
On Mon, 20 May 2024 18:47:35 GMT, Phil Race wrote:
> Have you looked into / thought about how this will work for jpackaged apps ?
> I suspect that both the existing FFM usage and this will be options the
> application packager will need to supply when building the jpackaged app -
> the end
On Mon, 20 May 2024 18:39:31 GMT, Phil Race wrote:
>> make/conf/module-loader-map.conf line 105:
>>
>>> 103: java.smartcardio \
>>> 104: jdk.accessibility \
>>> 105: jdk.attach \
>>
>> The list of allowed modules has been rewritten from scratch, by looking at
>> the set of modules
On Mon, 20 May 2024 18:39:31 GMT, Phil Race wrote:
>> make/conf/module-loader-map.conf line 105:
>>
>>> 103: java.smartcardio \
>>> 104: jdk.accessibility \
>>> 105: jdk.attach \
>>
>> The list of allowed modules has been rewritten from scratch, by looking at
>> the set of modules
On Mon, 20 May 2024 18:39:31 GMT, Phil Race wrote:
>> make/conf/module-loader-map.conf line 105:
>>
>>> 103: java.smartcardio \
>>> 104: jdk.accessibility \
>>> 105: jdk.attach \
>>
>> The list of allowed modules has been rewritten from scratch, by looking at
>> the set of modules
On Mon, 20 May 2024 18:39:31 GMT, Phil Race wrote:
>> make/conf/module-loader-map.conf line 105:
>>
>>> 103: java.smartcardio \
>>> 104: jdk.accessibility \
>>> 105: jdk.attach \
>>
>> The list of allowed modules has been rewritten from scratch, by looking at
>> the set of modules
On Mon, 20 May 2024 18:39:31 GMT, Phil Race wrote:
>> make/conf/module-loader-map.conf line 105:
>>
>>> 103: java.smartcardio \
>>> 104: jdk.accessibility \
>>> 105: jdk.attach \
>>
>> The list of allowed modules has been rewritten from scratch, by looking at
>> the set of modules
On Mon, 20 May 2024 18:39:31 GMT, Phil Race wrote:
>> make/conf/module-loader-map.conf line 105:
>>
>>> 103: java.smartcardio \
>>> 104: jdk.accessibility \
>>> 105: jdk.attach \
>>
>> The list of allowed modules has been rewritten from scratch, by looking at
>> the set of modules
On Mon, 20 May 2024 18:39:31 GMT, Phil Race wrote:
>> make/conf/module-loader-map.conf line 105:
>>
>>> 103: java.smartcardio \
>>> 104: jdk.accessibility \
>>> 105: jdk.attach \
>>
>> The list of allowed modules has been rewritten from scratch, by looking at
>> the set of modules
On Mon, 20 May 2024 18:39:31 GMT, Phil Race wrote:
>> make/conf/module-loader-map.conf line 105:
>>
>>> 103: java.smartcardio \
>>> 104: jdk.accessibility \
>>> 105: jdk.attach \
>>
>> The list of allowed modules has been rewritten from scratch, by looking at
>> the set of modules
On Mon, 20 May 2024 15:23:36 GMT, Viktor Klang wrote:
>> Local testing seems to indicate that this fix (which mirrors what's done in
>> the FIFO mode) addresses the problem. Regression test added for JDK20+
>
> Viktor Klang has updated the pull request incrementally with one additional
>
On Fri, 17 May 2024 13:19:19 GMT, Viktor Klang wrote:
>> Local testing seems to indicate that this fix (which mirrors what's done in
>> the FIFO mode) addresses the problem. Regression test added for JDK20+
>
> Viktor Klang has updated the pull request incrementally with one additional
>
On Mon, 20 May 2024 12:48:01 GMT, Sean Mullan wrote:
>> Joe Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> withdraw changes to jaxp.properties. The configuration process has not
>> changed, changing the default configuration
On Mon, 20 May 2024 12:48:01 GMT, Sean Mullan wrote:
>> Joe Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> withdraw changes to jaxp.properties. The configuration process has not
>> changed, changing the default configuration
On Thu, 16 May 2024 08:25:17 GMT, Kevin Walls wrote:
>>> > ...Is there any way to run jconsole in a way that would result in it
>>> > passing a non-empty delegationSubjects, resulting in this issue still
>>> > reproducing?
>>>
>>> I don't think there is, JConsole has a hard null in this call.
On Thu, 16 May 2024 08:25:17 GMT, Kevin Walls wrote:
>>> > ...Is there any way to run jconsole in a way that would result in it
>>> > passing a non-empty delegationSubjects, resulting in this issue still
>>> > reproducing?
>>>
>>> I don't think there is, JConsole has a hard null in this call.
On Fri, 17 May 2024 11:33:14 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?
>
> Jaikiran Pai has updated the pull request incrementally with one additional
> commit since the
On Mon, 20 May 2024 06:02:31 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal 3 methods on `java.net.MulticastSocket`? This addresses
>> https://bugs.openjdk.org/browse/JDK-8332181.
>>
>> As noted in that issue these methods have
On Sun, 19 May 2024 05:01:32 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from
On Sun, 19 May 2024 05:01:32 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from
On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik wrote:
>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while
>> current thread is in native thread state.
>>
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>>
On Thu, 16 May 2024 10:39:43 GMT, Nizar Benalla wrote:
> Please review this change. I converted the `package.html` file to
> `package-info.java`, because `javac` cannot recognize `package.html`.
> I already brought this up [in the mailing
>
On Fri, 17 May 2024 11:50:15 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal 3 methods on `java.net.MulticastSocket`? This addresses
>> https://bugs.openjdk.org/browse/JDK-8332181.
>>
>> As noted in that issue these methods have
On Fri, 17 May 2024 10:42:44 GMT, Alan Bateman wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update src/java.base/share/classes/java/net/Inet4Address.java
>>
>> Co
On Fri, 17 May 2024 08:46:28 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?
>
> Jaikiran Pai has updated the pull request incrementally with one additional
> commit since the
On Thu, 16 May 2024 09:12:20 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
On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls wrote:
>> Running JConsole from a previous JDK, and attaching to jdk-23 (after
>> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): Remove the Java
>> Management Extension (JMX) Subject Delegation feature), the MBean tab is
>> blank.
>>
On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls wrote:
>> Running JConsole from a previous JDK, and attaching to jdk-23 (after
>> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): Remove the Java
>> Management Extension (JMX) Subject Delegation feature), the MBean tab is
>> blank.
>>
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Mon, 13 May 2024 21:00:10 GMT, Stuart Marks wrote:
>>> If an event class is loaded before JFR is started, the event class needs to
>>> be retransformed, but if it is loaded later, we can add instrumentation on
>>> class load and avoid the retransformation. More happens when an event class
On Thu, 16 May 2024 12:10:46 GMT, Erik Gahlin wrote:
>> Hi,
>>
>> Could I have a review of a change that moves the jdk.FileRead and
>> jdk.FileWrite events to java.base to remove the use of the ASM
>> instrumentation.
>>
>> Testing: jdk/jdk/jfr
>>
>> Thanks
>> Erik
>
> Erik Gahlin has
On Sun, 12 May 2024 13:35:42 GMT, Erik Gahlin wrote:
> I guess it's not 100% safe if the JIT decides to store the read value
> elsewhere over several event checks, but it seems unlikely. Event settings
> checks (i.e., Event::isEnabled()) have always used plain reads, so it is not
> more
On Fri, 17 May 2024 05:44:29 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?
>
> Jaikiran Pai has updated the pull request incrementally with one additional
> commit since the
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from
On Fri, 17 May 2024 00:38:07 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmti.xml line 1008:
>>
>>> 1006: function descriptions. Empty lists, arrays, sequences, etc are
>>> 1007: returned as nullptr which is C programming language
>>> 1008: null pointer.
>>
>> Perhaps
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote:
>>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going
>>> > into the direction you had envisioned? Any more blockers? The CSR should
>>> > be up-to-date and is open for review
On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote:
>>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going
>>> > into the direction you had envisioned? Any more blockers? The CSR should
>>> > be up-to-date and is open for review
101 - 200 of 18235 matches
Mail list logo
