Design notes of and request for feedback on preliminary javax.lang.model support for records and sealed types

[Joe Darcy]

Hi Vicente,

On 4/23/2019 5:23 AM, Vicente Romero wrote:
> Hi Joe,
>
> On 4/17/19 4:19 PM, Joe Darcy wrote:
>> Hello,
>>
>> I recently pushed preliminary  javax.lang.model support for records 
>> and sealed types to the "records-and-sealed" branch of amber:
>>
>>     Initial support: 
>> http://hg.openjdk.java.net/amber/amber/rev/7eb4eb5792df
>>     Small bug fix: 
>> http://hg.openjdk.java.net/amber/amber/rev/20cd97aac3b0
>>
>> Please send feedback on the API design.
>>
>> The records document used as the basis for the API design is:
>>
>>     http://cr.openjdk.java.net/~briangoetz/amber/datum.html
>>
>> To summarize the language changes:
>>
>>

[snip]


>>
>> Some known bugs/limitations:
>>
>> * The API design discussed above implicitly calls for state 
>> components to be modeled separately from the fields or accessor 
>> methods they get desugared into. In the current implementation, the 
>> private fields are marked and used as the state components.
>>
>> * The permitted types method always returns an empty list.
>
> update: there is already support for this method in the compiler. Now 
> if the permitted types are declared the method return a non-empty list.


Thanks for adding the support for that method.


>
>>
>> * Elements.isSealed() always returns false.
>>
>> * A larger fractions of the fields and methods of a record are 
>> generated by the compiler than for other kinds of types. Therefore, I 
>> think it would be helpful if compiler implementations were more 
>> diligent about setting and tracking *origin* information for records. 
>> The origin
>>
>> https://docs.oracle.com/en/java/javase/12/docs/api/java.compiler/javax/lang/model/util/Elements.Origin.html 
>>
>>
>> of an element is whether it was declared explicitly (EXPLICIT), 
>> generated by the compiler under the mandate of a specification 
>> (MANDATED), or a compiler translation artifact (SYNTHETIC). One 
>> sample use of this information is the printing processor eliding 
>> output for methods like toString, equals, and hashCode if they are 
>> generated by the compiler.
>
> regarding this aspect, it is not clear that the MANDATED flag should 
> be applied to compiler generated methods. According to the spec: JLS 
> 11 13.1 The Form of Binary:
>
> 12. A construct emitted by a Java compiler must be marked as mandated 
> if it
> corresponds to a formal parameter declared implicitly in source code 
> (§8.8.1,
> §8.8.9, §8.9.3, §15.9.5.1).
>
> I think that we need to agree first if we want to change the spec to 
> apply the MANDATED flag to methods before giving support to this in 
> the compiler.
>

The current *requirement* to use mandated full-cycle is quite limited, 
but per the annotation processing API, a compiler can and should provide 
origin information to be retrieved from source files. I would generally 
support the spec mandating mandated origin information be passed along 
more widely.

The description of the MANDATED enum constant states:

"A mandated construct is one that is not explicitly declared in the 
source code, but whose presence is mandated by the specification. Such a 
construct is said to be implicitly declared. One example of a mandated 
element is a default constructor in a class that contains no explicit 
constructor declarations. Another example of a mandated construct is an 
implicitly declared container annotation used to hold multiple 
annotations of a repeatable annotation type."

and the package-level docs for javax.lang.model.element states:

"Some elements which are mandated may not be marked as such when created 
from class files. Additionally, synthetic constructs in a class file, 
such as accessor methods used in implementing nested classes and bridge 
methods used in implementing covariant returns, are translation 
artifacts strictly outside of this model. However, when operating on 
class files, it is helpful be able to operate on such elements, 
screening them out when appropriate."

Cheers,

-Joe