Hi Paul,
On 07/07/2016 12:39 PM, Paul Sandoz wrote:
On 30 Jun 2016, at 13:20, Martin Buchholz <marti...@google.com> wrote:
Webrev regenerated with updates.
Lots of rework for the atomic VarHandle specs.
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
Here is a spec diff for the atomics:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080603-concurrent-unsafe-vhs/specdiff/java/util/concurrent/atomic/package-summary.html
<http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080603-concurrent-unsafe-vhs/specdiff/java/util/concurrent/atomic/package-summary.html>
Paul.
Why don't javadocs of AtomicXXX.getPlain|setPlain methods refer to
VarHandle.get|set like other methods do?
Also, I can't seem to understand why the naming of methods on VarHandle
vs. the naming of methods on AtomicXXX classes is sometimes so
confusingly different and/or the same. For example, the following pairs
present equivalent memory effects:
VarHandle.getVolatile ~ AtomicInteger.get
VarHandle.get ~ AtomicInteger.getPlain
I understand that AtomicXXX classes have legacy and we can't change
their method names. But why was a method in new class (VarHandle) given
the same name as an existing AtomicXXX class method with different
memory effects? IMHO, this is just asking for confusion among developers.
Why the naming wasn't more like the following:
VarHandle.getVolatile ~ @Deprecated AtomicInteger.get ~ /* new method */
AtomicInteger.getVolatile
VarHandle.getPlain ~ /* new method */ AtomicInteger.getPlain
Why was it chosen that plain VarHandle.get() method is without Plain
suffix? Do you expect it will be used more often than other methods?
Regards, Peter
In the unlikely case you want the old webrev, it's at
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration.2016-06-29/
