FYI, proposed javax.lang.model changes for records

[Vicente Romero]

Hi Maurizio,

Thanks for the feedback. Yes I agree we still don't have a great story 
for non-XX modifiers, we can probably talk about that in the next meeting.

On 10/7/19 6:51 PM, Maurizio Cimadamore wrote:
> 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).

good point, yes we can leverage the API for enums too

> 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

Thanks,
Vicente

>
> 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 
>>