[records] Mark generated toString/equals/hashCode in class files somehow?

[Tagir Valeev]

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.gibbons at 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.