Hi, while working and trying the new JDK9 MethodHandles features like MethodHandles#countedLoop, I recognized a API inconsistency problem with it. We also found this while implementing the "Painless" scripting language for Elasticsearch (see https://goo.gl/DbOzjC)! Painless is a very limited scripting language with a very limited subset of classes to access and close integration into Elasticsearch (similar to Lucene's Expressions Module). Both compile script code to anonymous classes and Elasticsearch uses invokedynamic for the untyped stuff. It is much faster than Groovy or Nashorn, because it compiles most of the code completely static with known types (like Lucene expressions), but also supports a Groovy-like "def" type. The latter one uses invokedynamic, everything else is exactly the same speed as native Java code. During implementing array getters and setters for untyped stuff with invokedynamic we recognized the following problem (Java 8 code, see https://github.com/elastic/elasticsearch/pull/18232): There is MethodHandles.arrayElementGetter and MethodHandles.arrayElementSetter, so we can have full speed and full dynamic flexibility for array loads and stores - the speed is great, same as native array access! But there is one factory method missing in Java 8: MethodHandles.arrayLengthGetter (or similar name). As "length" is not a field on the array class, it is impossible to create a "simple" MethodHandle as field access to "array.class#length" to access it (it must invoke the "arraylength" bytecode, there is no field). I think the "length" field is just syntactic sugar of javac compiler. I know that Nashorn used to use java.lang.reflect.Array#getLength (not sure if this is still the case), but this makes usage inconsistent. You have to explicitly create a MethodHandle using the reflective array class to use it: And it is not strongly typed (it accepts Object). A real MethodHandle would be created for a specific type of array class and would return its length without runtime type checks. I know that at least Array.getLength() is optimized by Hotspot (in contrast to the other get/set methods, which are like 20 times slower than a method access, so MethodHandles.arrayElementGetter/Setter is very useful), but I would really like to suggest to fix this! With Java 9 this gets a bit worse: There is no "easy way" with the MethodHanldes class to generate a MethodHandles.countedLoop() on all elements of an array: public static MethodHandle countedLoop(MethodHandle iterations, MethodHandle init, MethodHandle body) [new in Java 9] With a full-featured API one could write: Class<?> type = arraytype, e.g. long[].class or String[].class MethodHandle body = some code that uses MethodHandles.arrayElementGetter(type) for further processing MethodHandles.countedLoop(MethodHandles.arrayLengthGetter(type), MethodHandles.constant(int.class, 0), body); As you see, for the first parameter (count), you would need to use the reflective part in java.lang.reflect.Array if the method is still missing in Java 9. This is not bad here, because it is not called all the time, but for our scripting language, the reflective class was slower. We implemented our own version of "arrayLengthGetter": public class ArrayLengthHelper { private ArrayLengthHelper() {} private static final Lookup PRIV_LOOKUP = MethodHandles.lookup(); private static final Map<Class<?>,MethodHandle> ARRAY_TYPE_MH_MAPPING = Collections.unmodifiableMap( Stream.of(boolean[].class, byte[].class, short[].class, int[].class, long[].class, char[].class, float[].class, double[].class, Object[].class) .collect(Collectors.toMap(Function.identity(), type -> { try { return PRIV_LOOKUP.findStatic(PRIV_LOOKUP.lookupClass(), "getArrayLength", MethodType.methodType(int.class, type)); } catch (ReflectiveOperationException e) { throw new AssertionError(e); } })) ); private static final MethodHandle OBJECT_ARRAY_MH = ARRAY_TYPE_MH_MAPPING.get(Object[].class); static int getArrayLength(boolean[] array) { return array.length; } static int getArrayLength(byte[] array) { return array.length; } static int getArrayLength(short[] array) { return array.length; } static int getArrayLength(int[] array) { return array.length; } static int getArrayLength(long[] array) { return array.length; } static int getArrayLength(char[] array) { return array.length; } static int getArrayLength(float[] array) { return array.length; } static int getArrayLength(double[] array) { return array.length; } static int getArrayLength(Object[] array) { return array.length; } public static MethodHandle arrayLengthGetter(Class<?> arrayType) { if (!arrayType.isArray()) { throw new IllegalArgumentException("type must be an array"); } return (ARRAY_TYPE_MH_MAPPING.containsKey(arrayType)) ? ARRAY_TYPE_MH_MAPPING.get(arrayType) : OBJECT_ARRAY_MH.asType(OBJECT_ARRAY_MH.type().changeParameterType(0, arrayType)); } } Interestingly I later found out that MethodHandles.arrayElementGetter/Setter uses the same "trick" behind the scenes! See MethodHandleImpl.ArrayAccessor: http://goo.gl/94f6OB I would suggest to add the missing Method to MethodHandles class and implement it together with the getters and setters in ArrayAccessor, similar to our example code (it is just a few lines more). In addition this one could then also use the extra intrinsic improvement that our class cannot use: makeIntrinsic(getAccessor(Object[].class, false), Intrinsic.ARRAY_LOAD); [with another intrinsic added: Intrinsic.ARRAY_LENGTH for the arraylength bytecode] What would be the process to propose such a change? Bug/Issue/JEP? I could quickly create a patch, but fixing the Intrinsic/LambdaForm stuff is way too complicated for me, so I would suggest to take this as an inspiration how to do it Uwe ----- Uwe Schindler uschindler@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/