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 lead
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: ht
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: https://git.openjdk.org/jd
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
> `-Djdk.reflect.useLegacyProxyI
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.
-
P
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 o
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 ClassLoaderValue
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 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 i
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 any
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 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 Assumpt
> 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
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
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 B
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 update
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 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 w
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 edit
ng 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 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 implem
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
> Exceptio
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 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-j
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) but
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 crash
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 pus
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 somethin
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 coverag
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 i
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 implementat
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 with
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 `DeflaterInputStrea
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
>> i
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: https://git.openjdk.or
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
>> i
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
>> i
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
>> i
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
>> i
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
>> i
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 witn
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
>> i
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 ch
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: https://git.openjdk.org/jdk/pull/19583#pullreque
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 chan
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
> -Djava.security.manager=allo
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 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 considerably
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 don't
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: https://git.openjdk.org/jdk/pull/
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 trans
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 ge
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 trans
On Tue, 4 Jun 2024 19:44:57 GMT, Naoto Sato wrote:
>> lingjun-cg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 896: Performance regression of DecimalFormat.format
>
> Also it would be helpful to compare the performance without bias
On Wed, 12 Jun 2024 14:02:58 GMT, fitzsim wrote:
> 8334048: -Xbootclasspath can not read some ZIP64 zip files
Are you planning to add tests? I don't think we should be changing this code
with good tests.
-
PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2163152471
On Wed, 12 Jun 2024 14:23:07 GMT, Daniel Fuchs wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> udpates
>
> test/jdk/javax/management/remote/mandatory/notif/policy.negative line 7:
>
>> 5: permission javax.manag
On Wed, 12 Jun 2024 20:58:28 GMT, Viktor Klang wrote:
> Erronous Javadoc reference addressed. This should be backported to 23.
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19682#pullrequestreview-2114807878
On Wed, 12 Jun 2024 19:06:23 GMT, Pavel Rappo wrote:
>> Please review this fix for an intermittent test failure.
>>
>> On some configurations, the default `expect` timeout of 10 seconds is
>> insufficient. It is increased to 20; it's hard to imagine a configuration
>> for which that new value
On Thu, 13 Jun 2024 06:59:39 GMT, Jaikiran Pai wrote:
>> test/jdk/java/io/IO/IO.java line 192:
>>
>>> 190: // adapted from
>>> https://junit.org/junit5/docs/current/user-guide/#extensions-lifecycle-callbacks-timing-extension
>>> 191:
>>> 192: public static class TimingExtension impleme
On 12/06/2024 15:23, David Lloyd wrote:
:
.
I have a *very* rough prototype up [1]. It adds two new accessor
methods to `ReflectionFactory`: `defaultReadObjectForSerialization`
and `defaultWriteObjectForSerialization`. It was easier than expected,
due largely to the classfile API, which is r
On 13/06/2024 14:22, David Lloyd wrote:
:
I've updated with a few commits today which solve (I think) the access
control issue, moves constant descriptors to constants in a holder
class, moves the bootstrap to `ConstantBootstraps`, just says "no" to
caching, and cleans up a few other minor is
On Thu, 6 Jun 2024 13:28:55 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which proposes to remove the
>> `CHECK_EXCEPTION_NULL_FAIL` macro from the `java` launcher code?
>>
>> This addresses https://bugs.openjdk.org/browse/JDK-8333714. As noted in that
>> JBS issue, in
On Wed, 12 Jun 2024 16:54:54 GMT, Severin Gehwolf wrote:
> Could you please help review it? Thanks!
Yes, on my list.
-
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2167341692
On 17/06/2024 11:43, Andrew Dinn wrote:
On 13/06/2024 14:39, Alan Bateman wrote:
Good to hear you've got a prototype to discuss. I don't think I can
look at what you have in your own repo but I do have a question. Do
the defaultXXX methods return a method handle or do they fail/
On Mon, 17 Jun 2024 15:24:27 GMT, Weijun Wang wrote:
>> Make sure `pd` is always the same object when `getProtectionDomain0` is null.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> explain why the test is related to the fix
On Mon, 17 Jun 2024 20:51:34 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
>> -Djava.security.manager
On Wed, 19 Jun 2024 11:58:07 GMT, Aleksey Shipilev wrote:
> @AlanBateman -- could you please take a look? Thanks.
There was a lot of heap analysis done a few years ago that shined a light on
the number of empty collections in a typical heap. I don't recall seeing COWAL
in any of the data but i
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the sta
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Tue, 18 Jun 2024 16:35:10 GMT, Jorn Vernee wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update man page header to be consisten with the others
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JD
On Wed, 19 Jun 2024 21:13:33 GMT, Maurizio Cimadamore
wrote:
>> What do you suggest? Just a note in the error message that exploded
>> modules/class paths are not supported?
>
> Something like that yes
An altermative is to use ResolvedModule::reference to get a ModuleReference,
then use its o
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Thu, 20 Jun 2024 17:40:25 GMT, Alan Bateman wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update man page header to be consisten with the others
>
> src/jdk.jdeps/share/cla
On Tue, 11 Jun 2024 21:09:14 GMT, Sean Mullan wrote:
>> I also think a period at the end is not necessary.
>
> For the Security Manager, the warning was worded a little differently:
>
> "WARNING: The Security Manager is deprecated and will be removed in a future
> release"
>
> I think that wor
On Fri, 21 Jun 2024 11:56:37 GMT, Adam Sotona wrote:
> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes
> `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>
> Please review.
>
On Thu, 20 Jun 2024 19:37:23 GMT, Jorn Vernee wrote:
> I've massaged the parsing code to where the help message now looks like this:
It is better but it might mean looking at HelpFormatter as you mentioned,.
Right now the usage message `--add-modules ` whereas the java --help
will print `--add
On Fri, 21 Jun 2024 14:05:51 GMT, Kevin Walls wrote:
> Man page update for JDK-8327793 which marked jstatd as deprecated for removal
> in JDK 24.
I assume we should hold off reviewing until the warning and the experiment note
are combined.
-
PR Comment: https://git.openjdk.org/jd
On Tue, 25 Jun 2024 08:25:00 GMT, Kevin Walls wrote:
>> Man page update for JDK-8327793 which marked jstatd as deprecated for
>> removal in JDK 24.
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the last revision:
>
> text update
Marked as revi
On Wed, 26 Jun 2024 06:04:08 GMT, Thomas Stuefe wrote:
> Question, what is the noreg-hard label used for?
It's the label to mean that it's too hard or impossible write a regression
test. It is documented in the [JBS label
dictionary](https://openjdk.org/guide/#jbs-label-dictionary) but may not
On Thu, 20 Jun 2024 19:37:23 GMT, Jorn Vernee wrote:
> It looks like it's possible to get even more custom by using a custom
> `HelpFormatter` as well, if we wanted.
I think what you have is okay for the first integration, just looks odd to have
the help/usage say "String" and "Path". Using a
On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Fri, 28 Jun 2024 19:43:36 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote:
> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
> support for functionality required to continue to support IIOP and custom
> serializers in light of additional module-based restrictions on reflection.
> It was ex
On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Mon, 8 Jul 2024 16:46:00 GMT, Joe Darcy wrote:
>> Make well-behaved implementation expectations of Object.{toString, hashCode}
>> explicit.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update wording.
Specifying that t
Probably best to bring this to loom-dev as there have been some
exploration into but where we decided not to expose any APIs at this time.
-Alan
On 09/07/2024 19:50, Louis Wasserman wrote:
My understanding of the structured concurrency APIs now in preview is
that when a subtask is forked, exce
On Wed, 10 Jul 2024 05:02:36 GMT, Joe Darcy wrote:
>> Make well-behaved implementation expectations of Object.{toString, hashCode}
>> explicit.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Narrow scope of the change.
Redu
On Mon, 15 Jul 2024 08:38:59 GMT, Uwe Schindler wrote:
>> src/hotspot/share/prims/scopedMemoryAccess.cpp line 179:
>>
>>> 177: //
>>> 178: // The safepoint at which we're stopped may be in between the
>>> liveness check
>>> 179: // and actual memory access, but is itself
Bringover some of the changes accumulated in the loom repo to the main line,
most of these changes are test updates and have been baking in the loom repo
for several months. The motive is partly to reduce the large set of changes
that have accumulated in the loom repo, and partly to improve robu
On Tue, 2 Jul 2024 12:20:17 GMT, Yasumasa Suenaga wrote:
> We cannot pass GNU style options like --enable-preview to jlink --add-option.
> It is hard to use for complex application.
JDK-8303884 was created to track a much larger re-examination of the jlink
option parameter. I think the issue w
On Mon, 17 Jun 2024 15:24:27 GMT, Weijun Wang wrote:
>> Make sure `pd` is always the same object when `getProtectionDomain0` is null.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> explain why the test is related to the fix
On Fri, 5 Jul 2024 19:27:27 GMT, Chen Liang wrote:
> 3. Remove the filter in `sun.misc.Unsafe`; users are already using other ways
> to steal this instance, bypassing the filtered getter.
JEP 471 has the roadmap for sun.misc.Unsafe, which is to wind it down over
time. Relaxing the filter to a
On Fri, 5 Jul 2024 19:27:27 GMT, Chen Liang wrote:
> Please review this patch that address the reflection member filtering flaws.
>
> 1. Remove a pointless bootstrap check to ensure no filter is accidentally
> bypassed due to class-loading order.
> 2. Clarify the scenarios for filtering, and th
On Wed, 17 Jul 2024 17:36:29 GMT, Naoto Sato wrote:
> Proposing a new overload method for `Process#waitFor()` which takes a
> `Duration` for the timeout value. This will reduce the possibility for making
> mistakes with the `TimeUnit` in the other overload method. A corresponding
> CSR has als
On Wed, 17 Jul 2024 17:51:52 GMT, Chen Liang wrote:
> waitFor can be overridden by pre-24 subclasses to provide a better
> implementation while ...
It doesn't really make sense to extend Process, except maybe for mocking or
other testing. Process is really for JDK implementations, it's just hi
On Wed, 17 Jul 2024 17:47:11 GMT, Chen Liang wrote:
> Please review this change that moves `Class.protectionDomain` and `signers`
> to explicit fields.
>
> Related native methods in `Class` and `AccessController::getProtectionDomain`
> are converted to pure Java. These fields are still set and
On Wed, 17 Jul 2024 21:42:17 GMT, Naoto Sato wrote:
>> It will be addressed by https://bugs.openjdk.org/browse/JDK-8336679
>
> I am planning to add `@implSpec` with a separate issue:
> [JDK-8336679](https://bugs.openjdk.org/browse/JDK-8336679)
Okay, just a bit strange to add waitFor(Duration) h
1 - 100 of 3166 matches
Mail list logo
