[jsr-292-eg] updated RI code and API javadoc
John.Rose at Sun.COM
Tue Sep 15 17:56:11 PDT 2009
(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
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
> daniel_heidinga at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mlvm-dev