FYI, proposed javax.lang.model changes for records
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Mon Oct 7 22:51:42 UTC 2019
Hi Vicente,
looking at the ElementKind construct, it is very nice to see that we
have now a nice 1-1 mapping between:
- Record/Record_Component
- Enum/Enum_Constant
That said, from an API perspective, while both enums and records are
TypeElement (so we're consistent there), there's nothing in the API to
model enum constants directly, while now we do have a way to model
record components.
I think this asymmetry should be rectified, eventually, but I do not
think this is a fault of the record API - I believe in reality what I'd
wish is for enums to be more exposed in the element API, rather than
being presented as a special kind of field (which is, I think, what
happens now). Moreover, there's no way to ask a TypeElement representing
an 'enum' questions like: give me all your constants.
As for sealing, I echo here what was said offline by Jon, which I think
was a good point that should not get lost: at the source level we now
have new modifiers, such as 'non-sealed'. While javac supports them, we
haven't worked out a story for these yet in the source reflection API.
In a way, one could say that the changes you have there are enough:
after all, you can see that a class has been marked as 'non-sealed' by
the absence of any other modifier there. But this brings out a question
of 'how much fidelity' do we expect between source code and the
j.l.model API - I believe right now the mapping is a bit fuzzy - that
is, e.g. interface fields will probably have { PUBLIC, STATIC }
regardless of the way in which they have been declared. In any case,
there's a question about what to do w.r.t. 'non-sealed' (and, more
generally, with 'non-xyz' modifiers), especially if we expect some of
these to be inspectionable by some other tools (see javadoc).
Overall, this looks like solid work - and at some point we'll need to
have some discussion about the finishing touches discussed above.
Maurizio
On 07/10/2019 21:59, Vicente Romero wrote:
> Hi,
>
> We have recently made an update of the javax.lang.model implementation
> for records [1]. The key difference with the previous implementation
> is that we have made javax.lang.model.element.RecordComponentElement,
> a top level element in the model, a direct subinterface of
> j.l.m.e.Element. Previously it was extending j.l.m.e.VariableElement.
> Doing this seemingly minor change has implied a cascade of changes
> several existing APIs plus the addition of several new ones: new
> visitors, new scanners, etc. A specdiff of the changes comprised in
> this iteration can be seen at [2]. As a baseline I have also provided
> a specdiff of all the changes done in javax.lang.model for records at
> [3]. This last diff is a comparison between current JDK14
> implementation and our proposal for records,
>
> Thanks,
> Vicente
>
> [1] https://hg.openjdk.java.net/amber/amber/rev/cf64ea74503e
> [2]
> http://cr.openjdk.java.net/~vromero/amber/records/javax.lang.model/diff_initial_and_current_approach/specdiff.01/java.compiler/module-summary.html
> [3]http://cr.openjdk.java.net/~vromero/amber/records/javax.lang.model/specdiff.00/java.compiler/module-summary.html
>
More information about the compiler-dev
mailing list