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.
