<AWT Dev> <Swing Dev> [12] Review Request: 8209340 The code which avoids synthetic accessors has become outdated

[Prasanta Sadhukhan]

+1

Regards
Prasanta
On 8/20/2018 12:20 PM, Krishna Addepalli wrote:
> Hi Sergey,
>
> Thanks for providing the test code. Now I understand why the constructors were explicitly written.
> After some discussions here, I understood that the "Compiler generated default constructor has the same access as the class". So, if the class had a private access, then the constructor would also be private.
> To work around this limitation, the compiler generates an additional public constructor with a dummy type as the parameter, which it in turn uses to instantiate the private inner classes.
>
> The changes look fine for me! +1.
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, August 14, 2018 8:36 AM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [12] Review Request: 8209340 The code which avoids synthetic accessors has become outdated
>
> On 13/08/2018 19:32, Krishna Addepalli wrote:
>> I understand that with the new jep, we no longer need to explicitly write the constructor to avoid the synthetic accessor methods generated by the compiler. AFAIK, each inner class declared  results in a class file being generated rather than each default constructor. Could you clarify this a bit more?
> You can compile this example by jdk8 and jdk11:
>
> public final class InheritTest {
>       Object createInnerClass() {
>           return new InnerClass();
>       }
>       private final class InnerClass { // change access here.
>       }
> }
>
> On jdk8 three classfiles will be created, and only two on jdk11. If you change the type to default/protected then two files will be created on
> jdk8 as well. This is why the classes in the fix have such constructors.
>
>> I also have another question: In general, is it better to provide a manual method to avoid the generation of synthetic accessor methods? In the context of this code change, I fail to see how it would have helped by writing explicit method rather than letting the compiler generate an accessor method.
> In the context of this change it is not necessary to have any tricks to avoid synthetic methods, which were created by javac to solve "access"
> problem. Because this problem was fixed by JEP 181.
>
>