Re: Re: Re: Re: bootstrap methods in the constant pool

Le 26/08/2010 19:13, [email protected] a écrit :

[...]

>
>    
>>> - visitCstClassInsn(String desc) // replaces Type arguments in
>>> visitLdcInsn
>>> - visitCstMethodInsn(String methDesc) // JSR 292
>>>
>>>        
>> I prefer visitCstMethodTypeInsn(String methodDesc) // JSR292 MethodType
>>
>>      
>>> - visitCstMethodInsn(String owner, String name, String desc, int tag)
>>> // JSR 292
>>>
>>>        
>> and visitCstMethodHandleInsn(int tag, String owner, String name, String
>> desc) // JSR292 MethodHandle
>> Moving the tag as first argument is in my opinion more like other
>> methods visit in ASM.
>>      
> ok to move the tag first; I did not add Type/Handle to avoid too long names
>    

And what about visitCstMHandleInsn() and visitCstMTypeInsn().

>
>    
>>> - visisCstInvokeInsn(String bootstrapOwner, String bootstrapName,
>>> String bootstrapDesc, int bootstrapTag, String methName, String
>>> methDesc) // JSR 292
>>>
>>>        
>> ???
>>      
> John added this in its patch (see lines 47-52, 130-131, 151-157 and 176-179 of his 'bsm' patch). But maybe this is not in JSR 292?
>    

Ok, JSR 292 now specifies that bootstrap method are encoded in the 
constant pool.
But there is no need to bubble up this constant into ASM API.
This constant will be managed by and shared between several 
visitIndyMethodInsn()
if possible.

>
>    
>>> add a new method for InvokeDynamic:
>>>
>>> - visitMethodInsn(String bootstrapOwner, String bootstrapName, String
>>> bootstrapDesc, int bootstrapTag, String methName, String methDesc) //
>>> JSR 292
>>>
>>>        
>> I think I prefer putting bootstrap info after calling info:
>> visitInvokeDynamicMethodInsn(methName, methDesc, bootstrapTag,
>> bootstrapOwner, bootstrapName, bootstrapDesc)
>>      
> why not
>
>    
>> About the stability of the API, there is a vicious circle for ASM:
>> ASM is quite popular as backend tool for (dynamic) language runtime,
>> so If we want the JSR292 bytecode changes to be tested we need a version
>> of ASM with these changes.
>> But because runtime developers test the API using ASM, we have feedback
>> that require to change
>> the JSR292 spec which leads to change the ASM API, etc.
>>      
> "temporary" ideas can be tested with ASM changes made in a branch. Here
> we are speaking of the final API for the final JSR 292 spec.
>    

I agree.
But developers like Charles will want a published (in maven) version.
Anyway, I will create a new branch in ASM SVN and try to code it during
the next week-end.

> Eric
>    

Rémi

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws