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