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.da...@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 <fo...@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
