(Getting a round of EG work in before the Summit, so we'll have more
to talk about. :-)
On Jul 15, 2009, at 6:02 AM, Daniel Heidinga wrote:
Regarding keeping MHs.methodType, it seems cleaner to keep the
MethodHandles factory and the MethodType factory separate. The
static import concerns can be addressed by renaming MethodType's
make() methods to have a more descriptive name such as methodType().
It'll look a little silly for people not using static import
(MethodType.methodType()), but I can live with that.
That seems like a good compromise. I'll add those methods and
deprecate the others, and see what comments we get.
I think the factory pattern "SomeType.make" makes less sense in a Java
world with static import. I guess the adjusted pattern
"SomeType.someType" is better. I'm open to other suggestions...
I'm glad that you agree that we should remove the _# from the
MHs.invoke() methods. Using invokeVarargs rather than
invokeWithArguments is fine.
Good. It looks much better that way.
Regarding the LDC proposal, it came to my attention that JSR 294
(Modularity) is planning to add new ConstantPool types as well. This
makes me very opposed to the idea of trying to overload the existing
CONSTANT_* rather than adding CONSTANT_MethodHandleref_info and
CONSTANT_MethodTyperef_info.
That seems right. Let's talk about this at the Summit. The advantage
of using constants rather than reflective factory methods is the
ability of tools (or the JVM) to see ahead of time how the app. is
going to link itself. There may also be compactness benefits.
Dan Heidinga
J9 VM Software Developer
IBM Ottawa Lab
613-356-5036
daniel_heidi...@ca.ibm.com
Thanks a lot for the detailed comments. I've forwarded it to a couple
observer lists.
To deal with API bloat, instead of getting rid of MHs.methodType, I'd
prefer to get rid of MethodType.make. Now that we have static import
in the language, I'd like to profit from it, and methodType is a much
more reasonable thing to import than "make".
I like your idea about getting rid of invoke_2. Since "varargs" is
the Java term, let's make the varargs guy "invokeVarargs".
Many more responses later.
-- John
On Jul 8, 2009, at 1:39 PM, Daniel Heidinga wrote:
> We've taken a look through the Javadoc and have some comments.
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
