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

[Tagir Valeev]

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