-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8359919: Minor java.util.concurrent doc improvements #25880
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
/issue JDK-8187775 |
/issue JDK-8254060 |
👋 Welcome back dl! A progress list of the required criteria for merging this PR into |
❗ This change is not yet ready to be integrated. |
/issue JDK-8210149 |
/issue JDK-8199501 |
@DougLea |
/issue JDK-8233050 |
@DougLea |
/issue JDK-8210312 |
/issue JDK-8292365 |
@DougLea |
/issue JDK-8356304 |
@DougLea |
@DougLea |
@DougLea |
@DougLea |
@DougLea |
Webrevs
|
I think the problem in |
src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/java/util/concurrent/CompletionStage.java
Outdated
Show resolved
Hide resolved
* forcibly completing normally or exceptionally, probing completion | ||
* status or results, or awaiting completion of a stage. | ||
* Implementations of CompletionStage may provide means of achieving | ||
* such effects, as appropriate. Method {@link #toCompletableFuture} | ||
* enables interoperability among different implementations of this | ||
* interface by providing a common conversion type. | ||
* | ||
* <p>Memory consistency effects: Actions in a thread prior to the | ||
* submission of a computation producing a {@code CompletionStage} | ||
* <i>happen-before</I> that computation begins. And actions taken by |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* <i>happen-before</I> that computation begins. And actions taken by | |
* <i>happen-before</i> that computation begins. And actions taken by |
* submission of a computation producing a {@code CompletionStage} | ||
* <i>happen-before</I> that computation begins. And actions taken by | ||
* a {@code CompletionStage} <i>happen-before</i> actions of any | ||
* dependent stage subsequent to its completion. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found "its" ambiguous in that sentence, does it mean:
* dependent stage subsequent to its completion. | |
* dependent stage subsequent to that stage's completion. |
🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
Outdated
Show resolved
Hide resolved
* submit(function.apply(item)); | ||
* subscription.request(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@@ -46,7 +46,7 @@ | |||
|
|||
/** | |||
* A reflection-based utility that enables atomic updates to | |||
* designated {@code volatile} reference fields of designated | |||
* designated non-static {@code volatile} reference fields of designated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't this change also apply to the other AtomicXFieldUpdaters?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Will do. Also, as mentioned by @liach we could trap violations by throwing a better exception. But considering that people should be using VarHandles instead anyway these days, and old uses might depend on current behavior, it doesn't seem worthwhile to add? (line 338)
-
if (Modifier.isStatic(modifiers))
-
throw new IllegalArgumentException("Must not be static");
/issue JDK-8353155 |
@DougLea |
/issue JDK-8186959 |
@DougLea |
/issue JDK-8190889 |
@DougLea |
/issue JDK-6351533 |
/issue JDK-6317534 |
@DougLea |
@DougLea |
/issue JDK-8195628 |
@DougLea |
/issue JDK-8333172 |
@DougLea |
@@ -398,6 +398,8 @@ else if (s == MICRO_SCALE) | |||
* @param obj the object to wait on | |||
* @param timeout the maximum time to wait. If less than | |||
* or equal to zero, do not wait at all. | |||
* @throws IllegalMonitorStateException if the current thread is not | |||
* the owner of this object's monitor. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably use "the object's monitor" rather than "the object's monitor" as "this" is the TimeUnit instance.
* return LEFT.compareAndSet(this, expect, update); | ||
* } | ||
* // ... and so on | ||
* }}</pre> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this should be convert to a {@snippet ..}
and have it handle the checked exceptions thrown by findVarHandle. I'm just thinking of someone seeing VarHandle usage for first time, then reporting a bug that the example doesn't compile.
This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers
Progress
Issues
whenComplete
andthenApply
change exceptional result (Bug - P4)Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25880/head:pull/25880
$ git checkout pull/25880
Update a local copy of the PR:
$ git checkout pull/25880
$ git pull https://git.openjdk.org/jdk.git pull/25880/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 25880
View PR using the GUI difftool:
$ git pr show -t 25880
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25880.diff
Using Webrev
Link to Webrev Comment