RFR 8151705 VarHandle.AccessMode enum names should conform to code style
john.r.rose at oracle.com
Mon Apr 11 21:23:50 UTC 2016
On Apr 7, 2016, at 6:39 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151705-VH-AccessMode-names/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151705-VH-AccessMode-names/webrev/>
> I was persuaded (in internal CCC review) to change the enum VarHandle.AccessMode constant names to conform to the expected Java style.
I'm sorry you were persuaded, because in some of these cases it is the code style that needs to flex here, not the source code names.
When working with reflective representations of API points, there is no benefit from representing (say) a method called toString by a variable which is called TO_STRING. It just makes it hard to see the correspondences between the ground names and the reflective names. (To start with, grep and other tools will fail to find both names.)
This is why, in the original JSR 292 code base, I have chosen to use hybrid names for fields that reflect API points. The prefix of the hybrid names does, in fact, follow the code style, but the suffix is the exact spelling of the reflected API point. I would be sad if some officious soul "fixed" these divergent names, because it would obscure the code. In fact, I wish this particular use case for hybrid identifiers were more widely recognized.
NF_internalMemberName = new NamedFunction(DirectMethodHandle.class
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/8c293ee99d5a/src/java.base/share/classes/java/lang/invoke/Invokers.java#l443 <http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/8c293ee99d5a/src/java.base/share/classes/java/lang/invoke/Invokers.java#l443> <http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/8c293ee99d5a/src/java.base/share/classes/java/lang/invoke/Invokers.java#l443>
MH_asSpreader = IMPL_LOOKUP.findVirtual(MethodHandle.class, "asSpreader",
MethodType.methodType(MethodHandle.class, Class.class, int.class));
As a precedent, the JVMS uses hybrid identifiers for quasi-reflective names like CONSTANT_String, etc.
Arguably (and also arguably not), the access types in your enums are quasi-reflective references to specific methods, and so should have their names derived (as a hybrid name) from the literal method names.
Good style includes knowing when to bend the rules.
More information about the core-libs-dev