RFR: JEP 359-Records: compiler code

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Oct 31 14:03:17 UTC 2019


The idea sounds good, in the sense that a compact record constructor is 
more similar to an initializer block than it is to a regular 
constructor, so I can see it being modeled as a JCBlock with the RECORD 
flag set. This is also made easier by the fact that we no longer allow 
instance initializers on records (**).

That said, if the compact constructor becomes a block, I'm pretty sure 
we'll run into issues with respect to source reflection - blocks are 
typically looked at in Attr, which is too late for source 
reflection/annotation processing. So I agree that, while it looks like a 
promising direction, it will probably be a non-trivial effort, and it 
would better be postponed as a followup cleanup

Maurizio

(*) In the list of error messages in [1] I don't see anything about 
'illegal instance initializer in record declaration' - is that an 
omission in the diagnostic examples, or a more serious issue in the 
code/spec?

[1] - http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.02/

On 31/10/2019 13:22, Vicente Romero wrote:
> Hi Srikanth,
>
> On 10/30/19 11:41 PM, Srikanth wrote:
>>
>>
>> On 30/10/19 11:37 PM, Vicente Romero wrote:
>>> (12) Compact constructor trees are modified in in 
>>> com.sun.tools.javac.parser.JavacParser#recordDeclaration to become 
>>> elaborated tree - I thought this practice of modifying parse trees 
>>> in the early stages is frowned upon ?? (Other parse tree 
>>> transformations also happen here)
>>>
>>> right but no other feature allows to declare a parameter-less 
>>> method. If not expanded here the compact constructor would have to 
>>> be expanded in TypeEnter, which probably is not very nice either, so 
>>> I didn't see a perfect solution
>>
>> It may be quite a bit of work, but the canonical solution would be to 
>> introduce a new node type to model these. Not asking it to be done. 
>> Just saying.
>
> yep, what you are saying sounds good, we could revisit this later on
>>
>> Srikanth
>>
> Thanks,
> Vicente


More information about the compiler-dev mailing list