FWD » Core Development

What is a "synthetic" method?¶

Explanation from here: https://stackoverflow.com/questions/4501324/synthetic-accessor-method-warning

You're running into one such case; you're attempting to access a private field of a class from an anonymous inner class. The Java language permits this but the JVM doesn't support it, and so the Java compiler generates a synthetic method that exposes the private field to the inner class. This is safe because the compiler doesn't allow any other classes to call this method, however it does introduce two (small) issues:

1. Additional methods are being declared. This shouldn't be a problem for the vast majority of use cases, but if you're working in a constrained environment like Android and are generating a lot of these synthetic methods you may run into issues.
2. Access to this field is done indirectly through the synthetic method, rather than directly. This too shouldn't be a problem except for highly performance-sensitive use cases. If you wouldn't want to use a getter method here for performance reasons, you wouldn't want a synthetic getter method either. This is rarely an issue in practice.

In Eclipse, to check if some synthetic access methods are created by the compiler:

1. Go to Preferences > Java > Compiler > Errors/Warnings
2. Enable the Access to a non-accessible member of an enclosing type warning or error.

To remove the issue accept one of the suggested by Eclipse quick fix actions:

1. Change visibility of the field or member in question;
2. Create an explicit default constructor;
3. Add the @SuppressWarnings("synthetic-access") annotation.

The previous discussion:

On 5/22/20 3:03 PM, Greg Shah wrote:

Vladimir,

I agree. Please go ahead with such changes. You can put them in 4231b.

Thanks,
Greg

On 5/21/20 3:55 PM, Vladimir Tsichevski wrote:

Hi Greg,

For FWD Eclipse shows multiple warnings like this:

Write access to enclosing field WindowManager.WorkArea.y is emulated by a synthetic accessor method

As I see it, some extra code is generated just to access a private field, so both the code size and performance do suffer. May be, it is worth to fix all these small issues by changing the fields access modifiers to some less restrictive values, as the IDE suggests.

This might not be an issue once we upgrade to Java 11. I read that thanks to nest-based access control JEP 181, accessor methods are not generated any more (see the 4th entry in Impact on Java Source Code Compilers).

Ovidiu Maxiniuc wrote:

This might not be an issue once we upgrade to Java 11. I read that thanks to nest-based access control JEP 181, accessor methods are not generated any more (see the 4th entry in Impact on Java Source Code Compilers).

Thanks, Ovidiu. I did not know that.

Then, may be, I should not commit the changes, and will will close this issue with some "will not do" resolution?
Greg, what do you think?

BTW, when do we plan to upgrade to Java 11?