[jsr-292-eg] updated RI code and API javadoc

[John Rose]

(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_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...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090915/15f1184f/attachment.html