Possible showstopper: was Re: new tree node

[Werner Dietl]

Jon,

I was expecting some follow-up to your previous message:

http://mail.openjdk.java.net/pipermail/type-annotations-dev/2013-April/000797.html

I don't know how the EG feels on the uugh-ness of the two alternatives.

cu, WMD.


On Wed, May 8, 2013 at 11:28 PM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
> Werner,
>
> The more I think about it, the more I think the correct solution is to merge
> JCVariableDecl and JCReceiverVariableDecl, by adding an extra field or
> method onto JCVariableDecl.
>
> This is in line with the precedent to add a default value onto a method
> decl, for the similarly limited use case of the default value in annotation
> declarations.
>
> I will work to create a changeset.
>
> -- Jon
>
>
>
> On 05/07/2013 07:01 PM, Jonathan Gibbons wrote:
>>
>> Werner,
>>
>> The problems with JCReceiverVariableDecl are more serious than I thought.
>> TreeCopier will definitely throw class cast exceptions at runtime because of
>> the unchecked cast in TreeCopier.copy.
>>
>> In general, it is not going to work to create this semi-private subclass
>> of JCVariableDecl and hope that everything works out. We would need to
>> either generalize JCVariableDecl, which implies changing existing API, or
>> else bite the bullet and add JCReceiverDecl, a corresponding com.sun.source
>> tree node, and update all related Kind, Tag, Visitor, Scanner, Copier
>> classes.
>>
>> -- Jon
>>
>>
>> On 05/07/2013 04:45 PM, Jonathan Gibbons wrote:
>>>
>>> Werner,
>>>
>>> If you add a new tree node in JCTree, you must add a corresponding new
>>> node in com.sun.source.tree. It is not enough to simply create
>>> JCReceiverVariableDecl be a subtype of JCVariableDecl :-(
>>>
>>> -- Jon
>>>
>>>
>>
>



-- 
http://www.google.com/profiles/wdietl