RFR: jsr166 jdk9 integration wave 7

[Peter Levart]

Hi Paul,


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.
>> 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/