On 7/29/2016 12:48 AM, Andrew Dinn wrote:
It might be worth pointing out at this stage in the discussion that
ACC_SYNTHETIC was never given a hard and fast meaning whose logic
transcends the vagaries of what javac decided to use it for -- citation,
Neal Gafter in a thread I was involved in many years ago on the meaning
of this term:
Said definition:
http://mail.openjdk.java.net/pipermail/compiler-dev/2010-August/002257.html
and explanation:
http://mail.openjdk.java.net/pipermail/compiler-dev/2010-August/002258.html
On the contrary, Neal and I agree on the hard and fast meaning of
ACC_SYNTHETIC. The second link says:
"As a simple example, the compiler-provided default constructor is added
by the compiler, but it is not synthetic because it is supposed to be
visible for the purposes of the language. The synthetic flag was
systematically added to precisely those symbols that should not be
visible in the language."
The default ctor, specified in JLS 8.8.9, is not present in source code
but is nevertheless not marked as ACC_SYNTHETIC. It is the poster child
for ACC_MANDATED. In terms of the first link, the default ctor is
plainly used for semantic analysis so ACC_SYNTHETIC is inappropriate.
The problem is that I can't go back in time to JVMS1 and add
ACC_MANDATED to ClassFile.access_flags, field_info.access_flags, and
method_info.access_flags. There are some classes, fields, and methods on
this Earth marked ACC_SYNTHETIC which "should" be ACC_MANDATED because
they're JLS-defined. As we define new class file artifacts, we can
specify the ACC_SYNTHETIC mask and the ACC_MANDATED mask to allow more
precise recording of "origin".
Alex
