On Tue, 11 Jun 2024 18:11:55 GMT, Kevin Walls wrote:
>> jstatd is an RMI server application which monitors HotSpot VMs, and provides
>> an interface to the monitoring tool jstat, for use across a remote RMI
>> connection.
>>
>> RMI is not how modern applications communicate. It is an old
On 11/06/2024 18:19, David Lloyd wrote:
:
I thought that might be where Alan was headed with this. I would
support this solution; it would solve the problem for conformant
serialization libraries. If a class has a `readObject`/etc. then we
use it - we wouldn't care if it was "natural" or
On Tue, 11 Jun 2024 16:54:36 GMT, Kevin Walls wrote:
>> jstatd is an RMI server application which monitors HotSpot VMs, and provides
>> an interface to the monitoring tool jstat, for use across a remote RMI
>> connection.
>>
>> RMI is not how modern applications communicate. It is an old
On Tue, 11 Jun 2024 16:52:13 GMT, Kevin Walls wrote:
> Sure, happy to not add annotations in sun.jvmstat.monitor.remote
> (RemoteHost.java, RemoteVm.java).
Right, you can drop it from all the source files except for module-info.java.
-
PR Comment:
On 11/06/2024 17:27, David Lloyd wrote:
:
Yes, all of the method-access methods on ReflectionFactory are used,
not just for readObject/writeObject but also readObjectNoData,
readResolve, and writeReplace, the constructor accessors, and the
factory methods for OptionalDataException. We
On 06/06/2024 18:37, David Lloyd wrote:
Just bumping this one more time. I intend to start by opening a JIRA
to add the two proposed methods to `ReflectionFactory`, and go from
there. I guess that we might need a JEP for the proposed serialization
restrictions, which is going to be
On Tue, 11 Jun 2024 13:09:06 GMT, Kevin Walls wrote:
> jstatd is an RMI server application which monitors HotSpot VMs, and provides
> an interface to the monitoring tool jstat, for use across a remote RMI
> connection.
>
> RMI is not how modern applications communicate. It is an old transport
On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls wrote:
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
>
On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in
> java.1) are handled separately.
>
> This initial generation also picks up the unpublished
On Thu, 6 Jun 2024 18:16:14 GMT, Raffaello Giulietti
wrote:
> A documentation-only change to match the original intent and the implemented
> behavior.
Yes, this one needs a CSR.
-
Marked as reviewed by alanb (Reviewer).
PR Review:
On Thu, 6 Jun 2024 10:42:20 GMT, Alan Bateman wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix default description of keep-packaged-modules
>
> I've read through all src chan
On Thu, 6 Jun 2024 09:47:30 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Sun, 28 Apr 2024 09:54:34 GMT, Viktor Klang wrote:
> Primarily offering this PR for discussion, as Throwables throwing exceptions
> on toString(), getLocalizedMessage(), or getMessage() seems like a rather
> unreasonable thing to do.
>
> Nevertheless, there is some things we can do, as
On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 4 Jun 2024 14:39:23 GMT, Severin Gehwolf wrote:
> I've added a couple of `@requires jlink.packagedModules` (new with this
> patch) so that jlink tests don't start to fail with it.
Good, the `@requires jlink.packagedModules` make sense.
-
PR Comment:
On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Wed, 5 Jun 2024 12:14:07 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which updates the API specification
>> of `java.util.zip.InflaterInputStream.skip()` method to match its current
>> implementation?
>>
>> `InflaterInputStream.skip()`, just like
On Fri, 31 May 2024 13:18:33 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Wed, 5 Jun 2024 04:41:48 GMT, David Alayachew wrote:
> Hey, I'm just curious -- why was the solution to remove an entire module? I
> understand the point of moving the relevant code over to `java.base`, but I
> don't understand why removing the random module made sense.
With the
On Tue, 4 Jun 2024 13:17:11 GMT, Thomas Stuefe wrote:
> Curious, why tier 1 to 3 specifically? Is there anything specific in tier 3
> you want to have tested?
I think just prudent to run more tests when touching the launcher as it has
options that aren't tested much in tier1. Shouldn't be an
On Tue, 4 Jun 2024 12:59:54 GMT, Jaikiran Pai wrote:
> I'll file follow up issue(s) and also trigger CI testing of this PR.
Thanks, the regressions fixed here are important to fix. It's unfortunate there
the original changes weren't changes weren't caught by tests. There is a good
test
On Tue, 4 Jun 2024 12:49:18 GMT, Alexey Semenyuk wrote:
> We already have [JDK-8263466](https://bugs.openjdk.org/browse/JDK-8263466) to
> find the original crash.
Thanks, just making sure the issue that there is an issue tracking it as it's a
bit unsettling that a re-run may be hiding
On Fri, 31 May 2024 14:34:16 GMT, Sonia Zaldana Calles
wrote:
> Hi all,
>
> I think there's some consensus that we need some follow up cleanup issues for
> the JNI spec, renaming constants, fixing return codes, etc.
>
> Seeing how that grows the scope of the issue quite a bit, I'd like to
On Mon, 3 Jun 2024 14:38:03 GMT, Alexey Semenyuk wrote:
>> I am yet to see anything that actually explains the cause of the `dlerror`
>> crash here ???
>
> @dholmes-ora there is no fix for the cause of the `dlerror` crash in this PR.
> The PR fixes jpackage tests to rerun a launcher if it
On Mon, 3 Jun 2024 15:40:10 GMT, Severin Gehwolf wrote:
> Does that proposal sound good?
That table is useful, I think it's right. No change to default behavior. If
someone configures with --enable-runtime-image then they get a JDK run-time
image that supports jlink (with some limitations)
On Sun, 2 Jun 2024 17:41:55 GMT, Alan Bateman wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 110 commits:
>>
>> - Merge branch 'master' into jdk-8311302-jmodless
On Wed, 22 May 2024 13:23:25 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Wed, 8 May 2024 09:40:38 GMT, Alan Bateman wrote:
> 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
&g
On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato wrote:
> There is an initialization code in `Console` class that searches for the
> Console implementations. Refactoring the init code not to use lambda/stream
> would reduce the (initial) number of loaded classes by about 100 for
> java.base
nding method on
> Carrier) are no longer needed. The functional interface is not proposed for
> j.u.function at this time.
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 merg
On Tue, 28 May 2024 20:22:24 GMT, Jonathan Gibbons wrote:
> What about changing `///` to `//---` to give slightly more prominence to
> these comments, over plain old `//` comments. The dashes give a small sense
> of a horizontal rule, to delimit sections of code.
>
> (FWIW, I have locally
On Tue, 28 May 2024 18:57:07 GMT, Jonathan Gibbons wrote:
> OK. I was just trying to honor the apparent intent to make the comment stand
> out more than just a plain `//` comment, but I have no strong feelings
> against reducing `///` to `//`
In this case I would reduce it to '//' but others
On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman wrote:
> This is the implementation changes for JEP 471.
>
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated
> for removal. This means a removal warning at compile time. No methods have
> been remove
On Tue, 28 May 2024 12:27: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 Fri, 10 May 2024 10:58:42 GMT, Alan Bateman wrote:
> There aren't any API or implementations changes in third preview but the JEP
> number/title needs to be bumped for the javadoc page.
This pull request has now been integrated.
Changeset: e708d135
Author: Alan Batema
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
> There aren't any API or implementations changes in third preview but the JEP
> number/title needs to be bumped for the javadoc page.
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 b
On Sun, 26 May 2024 06:06:50 GMT, Daniel Jeliński wrote:
> SkippedException works with jtreg tests only. For jUnit you need to use
> [Assumptions.abort](https://junit.org/junit5/docs/5.9.1/api/org.junit.jupiter.api/org/junit/jupiter/api/Assumptions.html#abort(java.lang.String))
Yes, the
On Fri, 24 May 2024 23:15:26 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Fri, 24 May 2024 05:26:40 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, 23 May 2024 23:24:16 GMT, Chen Liang wrote:
> Hmm, actually, looking at the specs of the method again, does it imply that
> Proxy classes are never unloaded once defined in a ClassLoader, as seen in
> `Proxy::getProxyClass`:
It's not specified, Proxy pre-dates hidden classes although
On Thu, 23 May 2024 16:42:39 GMT, Severin Gehwolf wrote:
> Do you think you'll be able to review this next week?
Yes, I want to help you get this one over the line.
-
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2127828050
On Thu, 23 May 2024 13:28:16 GMT, Chen Liang wrote:
> I have updated the compatibility risk description of the CSR.
>
> My CSR proposes to allow dynamic unloading of the proxy implementation
> classes, but currently it's not implemented as they are strongly referenced
> in the
On Thu, 23 May 2024 11:25:00 GMT, Chen Liang wrote:
> A CSR targeting 24 describing the compatibility concerns and behavioral
> differences is here, somehow not linked by skara:
> https://bugs.openjdk.org/browse/JDK-8332770 The incompatibilities were much
> greater in the previous iterations
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, 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: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 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 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 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 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 Wed, 15 May 2024 10:21:14 GMT, Maurizio Cimadamore
wrote:
> I believe we already disable a bunch of warnings from the command line when
> compiling these benchmarks. Perhaps we can just tweak the build script in a
> similar way and avoid the changes to the sources? E.g.
>
> ```
>
l sample of methods to
> ensure the changes doesn't cause any perf regressions.
>
> For now, the changes include the update to the man page for the "java"
> command. It might be that this has to be separated out so that it goes with
> other updates in the releas
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
On Wed, 15 May 2024 10:18:11 GMT, Maurizio Cimadamore
wrote:
> The FFM code throws if an unknown value is passed. Here we log. Should we try
> to be more consistent?
I don't have a strong opinion on this. The value of --illegal-native-access is
examined during startup so startup can fail if
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 08:49:46 GMT, ExE Boss wrote:
> Maybe export this interface to `jdk.unsupported`?
I don't we should do that. In general, we need jdk.unsupported to go away in
the long term. Also integrity of the platform depends on java.base being very
stingy and not exporting internal
On Wed, 15 May 2024 00:54:43 GMT, David Holmes wrote:
>> src/hotspot/share/runtime/arguments.cpp line 2271:
>>
>>> 2269: } else if (match_option(option, "--illegal-native-access=",
>>> )) {
>>> 2270: if (!create_module_property("jdk.module.illegal.native.access",
>>> tail,
On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg wrote:
> # Stable Values & Collections (Internal)
>
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API,
> which provides immutable value holders where elements are initialized _at
> most once_. Stable Values
On Mon, 13 May 2024 23:59:17 GMT, Viktor Klang wrote:
>> This change adds wrapping of the CancellationException produced by
>> CompletableFuture::get() and CompletableFuture::join() to add more
>> diagnostic information and align better with FutureTask.
>>
>> Running the sample code from the
On Tue, 14 May 2024 07:14:09 GMT, Thomas Stuefe wrote:
> but it does not state explicitly that an exception is thrown on every error,
> or whether there are cases where the API can return NULL but not throw an
> exception, or vice versa.
>
> So, I'd check for both. Or, if we think that both
On Mon, 13 May 2024 11:47:38 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 10:30:43 GMT, Per Minborg wrote:
> Some of the deprecated methods are very likely to be run in hot loops (e.g.
> read/store operations). Unless we set
> `--sun-misc-unsafe-memory-access=allow`, what would be the performance impact
> on various platforms for these
On Thu, 9 May 2024 18:44:10 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
The OpenJDK net-dev mailing list is the best place to bring this. There
was discussion about SOCKS when the HTTP client was developed, I thought
JEP 321 had a summary on this but it seems not. I'm sure others on
net-dev can say more on this.
-Alan
On 12/05/2024 22:58, Alessandro Autiero
On Mon, 13 May 2024 06:58:42 GMT, Per Minborg wrote:
> Would it make sense to add some verbiage in the JavaDocs for
> `sun.misc.Unsafe` that indicates the planned direction for said class and the
> use of the new command line options?
There is an API note to say that the class predates
On Sun, 12 May 2024 21:44:56 GMT, Alan Snyder wrote:
> I was not using the Zip file system. I was processing a Zip file.
They are equivalent, the suggestion to look at the sym link support in the zip
file system provider is that it's a much better fit for this extension. It
already has
This is the implementation changes for JEP 471.
The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated
for removal. This means a removal warning at compile time. No methods have been
removed. A deprecated message is added to each of the methods but unlikely to
be seen as
On Thu, 9 May 2024 19:52:12 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the
On Sun, 12 May 2024 09:48:42 GMT, xiaotaonan wrote:
> This issue was reported by a person named Alan Snyder, I don't have his or
> her contact information, how to create a CSR in this situation.
He came to core-libs-dev in Dec 2023 [1] to discuss this. The context at the
time was symbolic
On Sat, 11 May 2024 19:31:34 GMT, Erik Gahlin 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
> is
On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan wrote:
> Add API to access ZipEntry.extraAttributes
I think this will require discussion on core libs before proposing APIs in this
area. I think a starting point would be explain how you might use this, esp.
with file permissions and sym links.
On Thu, 9 May 2024 16:02:02 GMT, Erik Gahlin wrote:
>> The field is only used once and a VarHandle implementation loads three
>> additional classes during startup and in my measurements add about 0.6 ms to
>> startup.
>
> A compromise between performance and readability is:
>
> if
On Sat, 27 Apr 2024 11:52:18 GMT, Viktor Klang wrote:
>> This is an attempt to be more clear about recommendations on Lock usage.
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update
>
On Thu, 9 May 2024 11:19:14 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 Fri, 10 May 2024 07:57:40 GMT, Alan Bateman wrote:
> In preparation for JEP 471 and JEP 472, provide access to the initial value
> of System.err from JavaLangAccess. The initial value of System.in is already
> exposed to code in java.base with this shared secret.
This pull reques
In preparation for JEP 471 and JEP 472, provide access to the initial value of
System.err from JavaLangAccess. The initial value of System.in is already
exposed to code in java.base with this shared secret.
-
Commit messages:
- Initial commit
Changes:
There are any API or implementations changes in third preview but the JEP
number/title needs to be bumped for the javadoc page.
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.org/jdk/pull/19175/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=19175=00
1 - 100 of 1968 matches
Mail list logo
