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

Joe Darcy joe.darcy at oracle.com
Fri Aug 14 02:22:23 UTC 2020


Note that the javax.lang.model API already exposes that information:

https://docs.oracle.com/en/java/javase/14/docs/api/java.compiler/javax/lang/model/util/Elements.html#getOrigin(javax.lang.model.element.Element)

This as a case where there can be higher fidelity when a source file vs 
a class file is the basis of the element, as noted in the javadoc:

> Note that if this method returns EXPLICIT and the element was created 
> from a class file, then the element may not, in fact, correspond to an 
> explicitly declared construct in source code. This is due to 
> limitations of the fidelity of the class file format in preserving 
> information from source code. For example, at least some versions of 
> the class file format do not preserve whether a constructor was 
> explicitly declared by the programmer or was implicitly declared as 
> the default constructor.

If it is not deemed worthwhile to expand the usage of the ACC_MANDATED 
bit position for other constructs, it would be possible to define new 
attributes for that information, at a higher spec and implementation cost.

Cheers,

-Joe

On 8/11/2020 9:00 AM, Alex Buckley wrote:
> If the mandated status of a class/member was to be reified in the 
> class file, then you would need Core Reflection and Language Model 
> APIs to expose that status, along the lines of isSynthetic.
>
> Alex
>
> On 8/10/2020 8:26 PM, Tagir Valeev wrote:
>> 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.


More information about the amber-spec-observers mailing list