You are right that ACC_MANDATED is not expressible for methods. This is
unfortunate not only for equals/hashCode/toString in a record class, but
also for values/valueOf in an enum class.
ACC_SYNTHETIC indicates an implementation artifact -- something that
varies from compiler to compiler (or from one release of a compiler to
the next release of the same compiler). It would be wrong to use
ACC_SYNTHETIC to mark the five methods in the previous paragraph. They
are language artifacts, whose existence + signature + semantics are the
same across compilers.
It would be legitimate to add ACC_MANDATED to method_info.access_flags.
ACC_MANDATED is defined as 0x8000 in other contexts, so convention
dictates that it would have to be defined as 0x8000 in
method_info.access_flags too. Happily, 0x8000 is available there. This
also applies to field_info.access_flags.
Alex
On 8/6/2020 9:20 PM, Tagir Valeev wrote:
Hello, Jonathan!
I believe, current JVM specification doesn't say that methods could be
marked with ACC_MANDATED [1]. I won't mind if it will be used instead
of SYNTHETIC. To me, anything is ok if I can avoid bytecode
inspection.
With best regards,
Tagir Valeev.
[1] https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-4.html#jvms-4.6
On Fri, Aug 7, 2020 at 11:12 AM Jonathan Gibbons
<jonathan.gibb...@oracle.com> wrote:
Tagir,
The concept and word you are looking for is "mandated", which is similar
to but different from "synthetic".
See
https://docs.oracle.com/en/java/javase/14/docs/api/java.compiler/javax/lang/model/util/Elements.Origin.html#MANDATED
-- Jon
On 8/6/20 8:48 PM, Tagir Valeev wrote:
Hello!
I'm working on class-file decompiler for records and discovered that
there's no special flag for generated equals/hashCode/toString (like
ACC_SYNTHETIC). This allows determining whether this method was
explicitly specified in the source code only by looking into method
implementation whether it has an ObjectMethods.bootstrap indy or not.
This looks implementation-dependent and somewhat fragile (though, of
course, we will do this if we have no other options). We also have a
stub decompiler that decompiles declarations only without checking
method bodies at all and it also wants to know whether
equals/hashCode/toString methods were autogenerated. Finally, other
bytecode tools like code coverage may need this to avoid calculating
coverage for methods not present in the source.
Is it possible to mark generated methods via ACC_SYNTHETIC or any
other flag or add any attribute that can be used to differentiate
auto-generated methods from the ones presented in the source code?
Having a synthetic mark for auto-generated canonical constructor or
accessor methods is less critical (as their bodies could be actually
written in the source code like this) but it would be also nice to
have it.
With best regards,
Tagir Valeev.
