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