FYI, proposed javax.lang.model changes for records

[Jonathan Gibbons]

On 10/7/19 3: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). 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).

With regard to non-sealed, at least for javadoc, it's not enough to just 
look for the absence of "sealed"; you have to look at the supertype to 
see if it is sealed, and hence whether non-sealed may be necessary.  In 
other words, we have a tri-valued state here ...

 1. "nothing" (standard for almost all declarations)
 2. "sealed" (for sealed types)
 3. "non-sealed" (for non-sealed subtypes of sealed types)

It's not rocket-science for javadoc to do the right thing, but it's not 
convenient either.

-- Jon



>
> 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 
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20191007/84d4709d/attachment.html>