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 <[email protected]> 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.
