Fields and methods of a record are marked MANDATED

[Alex Buckley]

Enum types are specified such that a `values` method is always 
implicitly declared. (If you declare one explicitly, you have two method 
declarations with override-equivalent signatures, which is an error per 
JLS 8.4.) Accordingly, the corresponding method in the class file should 
always be marked as mandated. Sadly we don't have room for an 
ACC_MANDATED flag in `method_info`, but morally the method is mandated 
and Core Reflection should expose that fact.

Record types are specified more sensitively: a component's accessor is 
implicitly declared if and only if it isn't explicitly declared. (Same 
deal as the default constructor of a class.) If a component's accessor 
is explicitly declared, then there's nothing more to say; if it's 
implicitly declared, then it should be marked as mandated.

I wouldn't characterize this as member descriptor v. member 
implementation, because that sounds like "the signature" v. "the body". 
Fundamentally, the topic at hand is component accessors, which are 
non-abstract methods of non-abstract classes; for such methods of such 
classes, EITHER you declare both the signature and the body (in which 
case there's an explicit declaration of both signature and body) OR you 
declare neither (in which case there's an implicit declaration of both 
signature and body). Ordinary consumers of the record type are happy 
because they can be assured that component accessors are always declared 
(i.e., the compiler will always find the signature, the VM will always 
link the descriptor, and the subsequent execution of the linked method 
will always do something useful), while reflective consumers of the 
record type are happy because they can tell whether a component accessor 
(the signature and body as one undivided entity) was declared explicitly 
or implicitly. You say "random", I say "accurate".

Alex

On 10/10/2019 9:09 AM, Brian Goetz wrote:
> Under that interpretation, that leaves record members in a funny place, since a given mandated member (e.g., an accessor for a component) _might_ have been explicit in the source, or might not have been.  Should ACC_MANDATED describe the member descriptor (“spec mandates a member with this descriptor”) or only the implementation (“the source didn’t have it, but its here in the byte code”)?  In the latter interpretation, the presence of ACC_MANDATED on a mandated member would basically be random, based on implementation-of-the-day, which seems wrong.
> 
>> On Oct 10, 2019, at 12:06 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
>>
>> A mandated construct is one that is mandated by the specification, but not explicitly declared. Constructs of that sort have been in the platform since the beginning, such as default constructors. ACC_MANDATED was added to the platform only more recently and has some exposure through javax.lang.model.
>>
>> I recommend going forward ACC_MANDATED to be used more widely, on all the mandated structures, including the values methods on enum types, etc.
>>
>> Cheers,
>>
>> -Joe
>>
>> On 10/10/2019 8:50 AM, Brian Goetz wrote:
>>> We should match the behavior of methods like `Enum::values`.
>>>
>>>> On Oct 10, 2019, at 10:15 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>>>
>>>> Hi all,
>>>> fields and methods of a record are marked ACC_MANDATED which contradict JLS 13.1.12 that explains that you can not use ACC_MANDATED on field and method.
>>>>
>>>> regards,
>>>> Rémi
>>>>
>