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

Reply via email to