review request (XL): 6981777: implement JSR 292 EG adjustments from summer 2010

[John Rose]

On Oct 28, 2010, at 4:30 AM, Christian Thalinger wrote:

> On Oct 26, 2010, at 10:39 AM, John Rose wrote:
>> This is a large set of miscellaneous API adjustments that takes account of intensive JSR 292 Expert Group work since the JVM Language Summit and JavaOne.
>> 
>> http://cr.openjdk.java.net/~jrose/6981777/webrev.01/
> 
> src/share/classes/java/dyn/MethodHandles.java:
> 833 * of {@code Object} arguments and an {@code Object} return type.
> There is something wrong with this line (accidental paste?).

A leftover from the previous version of the javadoc.  Thanks.

> src/share/classes/java/dyn/package-info.java:
> 90 * The first pair of bytes bytes after the tag must be an index to a {@code CONSTANT_MethodHandle}
> One bytes too much.

:-)

> 225 * Any {@code varargs} modifier on the bootstrap method is irrelevant,
> 226 * since is no provision for adapting a bootstrap method with
> 227 * {@link java.dyn.MethodHandle#asCollector asCollector}.
> This sounds odd.

I broke out the point separately, under the discussion of ldc/MH:

 * A constant may refer to a method or constructor with the {@code varargs}
 * bit (hexadecimal {@code 80}) set in its modifier bitmask.
 * The method handle constant produced for such a method behaves the same
 * as if the {@code varargs} bit were not set.
 * The argument-collecting behavior of {@code varargs} can be emulated by
 * adapting the method handle constant with
 * {@link java.dyn.MethodHandle#asCollector asCollector}.
 * There is no provision for doing this automatically.

(It's important for users to know that varargs isn't simulated automagically.  We could do this, though, with another constant pool entry subtype, to apply the asCollector call.  But that's probably for a future version.)

> 330 * or an {@code Object} array of reference to all the arguments (if there are two or more),
> references?

Yes, thanks.

> src/share/classes/sun/dyn/CallSiteImpl.java:
> 
> 66 if (false) // switch when invokeGeneric works
> Doesn't invokeGeneric work now?

I want to shake the bugs out a little more.

> src/share/classes/sun/dyn/util/Wrapper.java:
> 
> 118 /** Does the JVM verifier allow allow a variable of this wrapper's
> One allow too much.
> 
> Otherwise looks good.

Thanks for reading it over carefully.

> -- Christian

-- John