8297385: Remove duplicated null typos in javadoc
-
Commit messages:
- 8297385: Remove duplicated null typo in javadoc
Changes: https://git.openjdk.org/jdk/pull/11311/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=11311=00
Issue: https://bugs.openjdk.org/browse/JDK-8297385
On Tue, 15 Nov 2022 15:05:45 GMT, Dongxu Wang wrote:
> 8297385: Remove duplicated null typos in javadoc
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/11169
On Wed, 23 Nov 2022 06:49:56 GMT, Dongxu Wang wrote:
>> 8297385: Remove duplicated null typos in javadoc
>
> Dongxu Wang 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
On Wed, 23 Nov 2022 06:43:56 GMT, Yi Yang wrote:
> This looks good, but I'm not a Reviewer, you still need an approval from
> Reviewer.
Thanks
-
PR: https://git.openjdk.org/jdk/pull/11169
> 8297385: Remove duplicated null typos in javadoc
Dongxu Wang 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 two additional commits since the
last
On Wed, 23 Nov 2022 06:45:26 GMT, Dongxu Wang wrote:
>> 8297385: Remove duplicated null typos in javadoc
>
> Dongxu Wang 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
On Mon, 14 Nov 2022 12:20:54 GMT, Julian Waters wrote:
>> Sorry my eyes must be playing tricks on me. ??
>>
>> Why did you need to add this here?
>
> It's to avoid redefining the linkage as static in os_windows.cpp (where it's
> implemented) after an extern declaration (inside the class),
This commit guards thread modifications for the process reaper thread with
doPrivileged.
-
Commit messages:
- 8297451: ProcessHandleImpl should assert privilege when modifying reaper
thread
Changes: https://git.openjdk.org/jdk/pull/11309/files
Webrev:
On Mon, 21 Nov 2022 02:43:12 GMT, Julian Waters wrote:
> Out of curiosity, is there a way to get the discussion on approving the use
> of alignas back up? [...]
A PR to address JDK-8252584 would be welcomed by me. Just do the process for
Style Guide changes (see the Style Guide or previous PRs
On Tue, 15 Nov 2022 01:52:14 GMT, Bo Zhang wrote:
> As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329),
> previously, the jar validator compare the "version" to validate a
> multi-release jar. The "version" is a mix of the major and minor version
> fused into a single
On Wed, 23 Nov 2022 03:01:51 GMT, Jorn Vernee wrote:
>> @JornVernee can you please sponsor this PR?
>
> @blindpirate Yes. If you `/integrate` it, I can then `/sponsor`.
Thanks @JornVernee !
-
PR: https://git.openjdk.org/jdk/pull/11153
On Wed, 23 Nov 2022 02:50:26 GMT, Bo Zhang wrote:
>> Marked as reviewed by jvernee (Reviewer).
>
> @JornVernee can you please sponsor this PR?
@blindpirate Yes. If you `/integrate` it, I can then `/sponsor`.
-
PR: https://git.openjdk.org/jdk/pull/11153
On Wed, 16 Nov 2022 13:23:03 GMT, Jorn Vernee wrote:
>> Bo Zhang has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains one
>> new commit
On Wed, 23 Nov 2022 00:24:28 GMT, Serguei Spitsyn wrote:
> This problem has two sides.
> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents`
> value.
> It caused the native method `notifyJvmtiUnmountBegin()` not called after the
> field `notifyJvmtiEvents`
> value has
On Wed, 23 Nov 2022 00:24:28 GMT, Serguei Spitsyn wrote:
> This problem has two sides.
> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents`
> value.
> It caused the native method `notifyJvmtiUnmountBegin()` not called after the
> field `notifyJvmtiEvents`
> value has
This problem has two sides.
One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents`
value.
It caused the native method `notifyJvmtiUnmountBegin()` not called after the
field `notifyJvmtiEvents`
value has been set to `true` when an agent library is loaded into running VM.
The
On Tue, 22 Nov 2022 00:50:51 GMT, Brent Christian wrote:
>> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the
>> shutdown sequence, noting that calling Runtime.halt() skips the shutdown
>> sequence and immediately terminates the VM. Thus, "threads' current methods
>>
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed in the `@spec` tags.
>
> "Somewhat automated" means that
Thanks you Alan and Roger.
I filed the following issue to track this:
https://bugs.openjdk.org/browse/JDK-8297451
There are likely many more usages of innocuous thread that could be
improved by ensuring setDaemon is invoked while asserting privileges,
but I'd like to leave those to a later
On Tue, 22 Nov 2022 18:43:53 GMT, Roger Riggs wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Seal Digits
>
> src/java.base/share/classes/java/lang/template/StringProcessor.java line 58:
>
>> 56: /**
>> 57:
On Tue, 22 Nov 2022 18:33:23 GMT, Roger Riggs wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Seal Digits
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 52:
>
>> 50: * given by the
On Tue, 22 Nov 2022 18:17:28 GMT, Roger Riggs wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Seal Digits
>
> src/java.base/share/classes/java/lang/template/package-info.java line 57:
>
>> 55: *{@link
On Mon, 21 Nov 2022 17:43:16 GMT, Jim Laskey wrote:
>> Enhance the Java programming language with string templates, which are
>> similar to string literals but contain embedded expressions. A string
>> template is interpreted at run time by replacing each expression with the
>> result of
On Tue, 22 Nov 2022 13:49:45 GMT, Per Minborg wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 914:
>>
>>> 912: * If so, make a copy to put the dst data in.
>>> 913: */
>>> 914: @SuppressWarnings("try")
>>
>> After looking
> JEP 429 implementation.
Andrew Haley has updated the pull request incrementally with three additional
commits since the last revision:
- Merge branch 'JDK-828' of https://github.com/theRealAph/jdk into
JDK-828
- Update src/java.base/share/classes/java/lang/VirtualThread.java
> JEP 429 implementation.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Update src/java.base/share/classes/java/lang/Thread.java
Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
-
Changes:
-
> JEP 429 implementation.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Update src/hotspot/cpu/aarch64/aarch64.ad
Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
-
Changes:
- all:
> JEP 429 implementation.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Remove incorrect assertion.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/10952/files
- new:
On Tue, 22 Nov 2022 15:57:57 GMT, Christian Stein wrote:
>> This PR copies the `CommandLine.java` file from module `jdk.compiler`
>> (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module,
>> creating a new package with name `jdk.internal.opt`. That new
>> `jdk.internal.opt`
Hi Chris,
Yes, adding a doPriv for setDaemon and setName in a couple of places
makes sense.
Thanks, Roger
On 11/22/22 11:12 AM, Chris Hegarty wrote:
Hi Alan,
On 22/11/2022 16:08, Alan Bateman wrote:
On 22/11/2022 15:21, Chris Hegarty wrote:
..
Just to double check, does the ES
> JEP 429 implementation.
Andrew Haley has updated the pull request incrementally with two additional
commits since the last revision:
- Merge branch 'JDK-828' of https://github.com/theRealAph/jdk into
JDK-828
- Fix bad merge.
-
Changes:
- all:
Hi Alan,
On 22/11/2022 16:08, Alan Bateman wrote:
On 22/11/2022 15:21, Chris Hegarty wrote:
..
Just to double check, does the ES security manager override
checkAccess(Thread)?
Yes. :-(
That is usually a no-op but if overridden then it
will expose an issue with the thread factory for the
On 22/11/2022 15:21, Chris Hegarty wrote:
Hi,
A change in JDK 19, that changed process reaper threads to be
innocuous [1], has had an adverse affect when terminating the
Elasticsearch server [2]. I agree with changing the process reapers to
be innocuous, but just wonder if we're missing a few
> This PR copies the `CommandLine.java` file from module `jdk.compiler`
> (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module,
> creating a new package with name `jdk.internal.opt`. That new
> `jdk.internal.opt` package is then exported to the following modules:
> -
On Mon, 21 Nov 2022 15:40:19 GMT, Christian Stein wrote:
> This PR copies the `CommandLine.java` file from module `jdk.compiler`
> (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module,
> creating a new package with name `jdk.internal.opt`. That new
> `jdk.internal.opt`
Hi,
A change in JDK 19, that changed process reaper threads to be
innocuous [1], has had an adverse affect when terminating the
Elasticsearch server [2]. I agree with changing the process reapers to
be innocuous, but just wonder if we're missing a few doPriv blocks.
Additionally, and also in JDK
On Tue, 15 Nov 2022 15:05:45 GMT, Dongxu Wang wrote:
> 8297385: Remove duplicated null typos in javadoc
The source of this PR is the "master" branch of your fork. Note the Comment
from the bot at the top.
The conventional usage is to create a branch specific to the change you are
making and
> This PR contains the API and implementation changes for JEP-434 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.org/jeps/434
Maurizio Cimadamore has updated the pull request
> This PR proposes the introduction of **guarding** of the use of
> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
> Function and Memory access, it is possible to derive Buffer instances that
> are backed by native memory that, in turn, can be closed asynchronously
On Tue, 22 Nov 2022 09:23:40 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rework Acquisition
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
> line 914:
On Tue, 22 Nov 2022 09:29:14 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rework Acquisition
>
> src/java.base/share/classes/java/nio/Buffer.java line 827:
>
>> 825:
>> 826:
On Tue, 22 Nov 2022 09:38:35 GMT, Maurizio Cimadamore
wrote:
>> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590:
>>
>>> 588: int pos)
>>> 589: throws IOException {
>>> 590: try (var guard =
On Tue, 22 Nov 2022 00:50:51 GMT, Brent Christian wrote:
>> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the
>> shutdown sequence, noting that calling Runtime.halt() skips the shutdown
>> sequence and immediately terminates the VM. Thus, "threads' current methods
>>
On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg wrote:
>> This PR proposes the introduction of **guarding** of the use of
>> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
>> Function and Memory access, it is possible to derive Buffer instances that
>> are backed
On Tue, 22 Nov 2022 09:32:32 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rework Acquisition
>
> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590:
>
>> 588:
On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg wrote:
>> This PR proposes the introduction of **guarding** of the use of
>> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
>> Function and Memory access, it is possible to derive Buffer instances that
>> are backed
On Mon, 21 Nov 2022 15:29:11 GMT, Per Minborg wrote:
> That is clear to me but I am trying to prevent future redundant guarding.
> Anyway, I will remove the comments.
The faraway use sites look much better now. The performance sensitive usages
need close attention. Can you summarise the
On Tue, 22 Nov 2022 03:33:55 GMT, Yi Yang wrote:
> > > good catch, do you need a JBS issue for this?
> >
> >
> > Thank you if you can help with that.
>
> I filed https://bugs.openjdk.org/browse/JDK-8297385 for this, you can change
> your PR title and commit message to [8297385: Remove
On Mon, 21 Nov 2022 20:06:20 GMT, Alan Bateman wrote:
>>> > Although this looks much simpler and concise, it means "a new object is
>>> > created for each invocation"
>>>
>>> My comment was actually to see if DirectBuffer could extend AutoCloseable
>>> so that the acquire returns "this" for
> This PR proposes the introduction of **guarding** of the use of
> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
> Function and Memory access, it is possible to derive Buffer instances that
> are backed by native memory that, in turn, can be closed asynchronously
50 matches
Mail list logo
