Fwd: Re: RFR: JEP 359-Records: compiler code

Vicente Romero vicente.romero at oracle.com
Wed Nov 6 13:11:26 UTC 2019

Hi Joe,

I made an experiment: removing the code you added to PrintingProcessor 
and the tests, TestRecord and family, just work.


On 11/5/19 7:13 PM, Joe Darcy wrote:
> Hi Vicente,
> On 11/5/2019 2:58 PM, Vicente Romero wrote:
>> Hi Joe,
>> Thanks for the review,
>> On 11/4/19 12:33 AM, Joe Darcy wrote:
>>> Hi Vicente,
>>> I've taken a pass over the javax.lang.model portions of the change.
>>> Elements.recordComponentFor should have an @implSpec tag.
>>> I suggest a double-check of the existing visitors/scanners that used 
>>> to extend one of the "FooVisitor9" types and was updated to extend 
>>> "FooVisitor14". In prior work, I had to add a new method override 
>>> for visitRecordComponent to the printing processor to get the proper 
>>> semantics of that class. For example, PubapiVisitor might need an 
>>> update.
>> I have updated the code for all the comments but the one above. I 
>> don't understand what you are exactly asking for,
> For the printing processor to have the right semantics after record 
> components were modeled with their own top-level element, I had to 
> make the following adjustment:
>     http://hg.openjdk.java.net/amber/amber/rev/6b2b5e4c01a7
> In effect, the unmodified processor with its default methods, etc. did 
> not "just" work when the superclass was changed from the old JDK-9 
> based visitors to the JDK-14 based one.
> Analogous updates may be needed for other visitors/scanners to contend 
> with records and record components.
> HTH,
> -Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20191106/7de1da1d/attachment.html>

More information about the compiler-dev mailing list