Thank you, Alex! I created an issue to track this: https://bugs.openjdk.java.net/browse/JDK-8251375 I'm not sure about the component. I set 'javac', though it also touches JLS and JVMS; hopefully, no actual changes in HotSpot are necessary as HotSpot can happily ignore this flag. I tried to formulate proposed changes in JLS and JVMS right in the issue. For now, I omit fields from the discussion because supporting fields isn't critical for my applications. But it's also ok to extend this to fields.
What else can I do to move this forward? With best regards, Tagir Valeev. On Sat, Aug 8, 2020 at 12:37 AM Alex Buckley <alex.buck...@oracle.com> wrote: > > 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.
