RFR: jsr166 jdk9 integration wave 7
peter.levart at gmail.com
Thu Jul 7 14:06:33 UTC 2016
On 07/07/2016 12:39 PM, Paul Sandoz wrote:
>> On 30 Jun 2016, at 13:20, Martin Buchholz <martinrb at google.com> wrote:
>> Webrev regenerated with updates.
>> Lots of rework for the atomic VarHandle specs.
> 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>
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 */
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?
>> In the unlikely case you want the old webrev, it's at
More information about the core-libs-dev