arrayLength argument of MethodHandle.asCollector() and failing JCK test 'asCollectorIAE01'

Volker Simonis volker.simonis at
Tue Mar 26 12:15:11 UTC 2013


while running JCK test for our PPC port I realized that the test
'asCollectorIAE01' which checks valid and invalid 'arrayLength' arguments
to MethodHandle.asCollector() fails for the current 7u/jdk and jdk8/jdk
sources. Further investigations revealed that the failure is due to the
change "7191102: nightly failures after JSR 292 lazy method handle update
(round 3)" which changed the way how
sun.invoke.util.ValueConversions.varargsArray() works. Apparently, the new
implementation can now handle 'arrayLength' parameters up to 254 while the
old implementation could only handle up to 253 parameters.

However the mentioned JCK test explicitly checks that
MethodHandle.asCollector() throws an exception if called with an
'arrayLength' argument of 254 and fails for current  jdk7u and jdk8 builds
because they can handle such an argument.

The API-documentation of "MethodHandle.asCollector()" is a little vague
because it only states "Throws: IllegalArgumentException - if ...
arrayLength is not a legal array size" but doesn't actually specify which
are "legal array sizes". I therefore think that this is an implementation
detail and the JCK test should not check for values like 254 but only for
the real hard limits imposed by the VM (i.e. 255). I would therefore
propose to exclude the mentioned test from the TCK. Otherwise the API
documentation would have to be changed to explicitly specify the valid
range of 'arrayLength' arguments.

Attached you can find a small test program which can be used to reproduce
the problem. Running the program with a released Java 7 version (which
doesn't contain the change "7191102" yet) will throw an
IllegalArgumentException if MethodHandle.asCollector() is called with an
'arrayLength' argument of 254. On the other hand if the program is beeing
run with a recent JDK8 build (i.e. b82) or a curent build of jdk7u,
MethodHandle.asCollector() will accept 254 as 'arrayLength' parameter and
the generated MethodHandle can indeed be invoked with 254 arguments.

Notice that there already exists a bug which is related to this problem:
"7194534 : MethodHandle.asCollector() throws IAE with "bad parameter count
256" in spite of correct param count" ( However it
only objects the fact that for the the old implementation the
IllegalArgumentException wrongly reports 'arrayLength' + 2 instead of
'arrayLength' as the failing argument.

Thank you and best regards,

More information about the core-libs-dev mailing list