naming of internal MH classes

[John Rose]

Here is a heads-up before an engineering code review!

The OpenJDK implementation of JSR 292 has a number of private MH subclasses, including DirectMethodHandle, BoundMethodHandle, AdapterMethodHandle, AdapterMethodHandle.AsVarargsCollector.  Except for the last, these names date back to the days of prototyping JSR 292.

As we tune and refactor the implementation, I am starting to define more subclasses.  Now it is time to consider some name changes.  Because these can impact the JVM (as it recognizes intrinsics) I would like to keep these changes as low-impact as possible.

In particular, I want to switch to something similar to Dan Heidinga's naming convention (in IBM's implementation), where private subclasses have simpler but more specific names like AsTypeHandle.

Dan's account of MH type names is on slide 6 of his 2010 talk:
  http://www.wiki.jvmlangsummit.com/images/a/ad/J9_MethodHandle_Impl.pdf (2010)

I don't propose to duplicate this, but rather to use the names as a model.

(It is possible that this might ease the creation of a common implementation API with IBM, which would be good, but that's not the immediate goal.)

Before I start refactoring and renaming, in the OpenJDK implementation, I want to know if we see any downside to using such a naming scheme in OpenJDK.

Comments?

-- John

P.S. The immediate occasion for naming and refactoring is the (likely) need for a CountingHandle (or is it CountingAdapterMethodHandle or AdapterMethodHandle$AsCounter?), to assist in profiling tasks.  (Cf. the methodDataOop which profiles for bytecodes.  We need similar infra. for MH graphs.)

P.P.S.  Dan's 2011 talk is here, for the record.  It's delves into other interesting details of the J9 implementation, including their version of supercombinators:
  http://www.wiki.jvmlangsummit.com/images/6/6b/2011_Heidinga.pdf (2011)