Latest Thinking

[John Rose]

On Jun 22, 2010, at 3:33 PM, Rémi Forax wrote:

> Another to say the same thing, I don't see how to do refactoring
> of the corresponding all callsites if the name of one BSM change.

Yes, I see that.  Well, there must be other ways to do that without sharing the magic of InvokeDynamic.

Perhaps allow user-defined annotations instead of @BootstrapMethod.   There is no annotation inheritance which would allow us to use a subclassing pattern, but there are meta-annotations:

@BootstrapProtocolAnnotation(<<details>>)
@interface MyBootstrapProtocol { <<more details or just empty?>> }

...

InvokeDynamic.<@MyBootstrapProtocol Object> foo(bar)

This introduces the level of named indirection you want, without entangling InvokeDynamic itself.

What would the details look like?

BTW, here's part of the puzzle:  JSR 308 (nb. not 309 if that's what I said earlier) mandates that all non-source type annotations go into a complicated, hard-to-use table in a classfile attribute.  I don't want to rely on that, if possible.  Annotations that affect the construction of indy sites are going to have the "SOURCE" retention policy, so they don't go two places at once.

(Would there be a sensible default java.dyn.BootstrapProtocol?)

My draft of @BootstrapProtocol looks like this:

@Target({ElementType.TYPE_USE,
            // For defaulting every indy site within a program element; cf. @SuppressWarnings:
            TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE, TYPE_PARAMETER})
@Retention(RetentionPolicy.SOURCE)
public @interface BootstrapMethod {
    Class<?> value();
    String name() default "bootstrapInvokeDynamic";
}

-- John