javac flag to suppress synthetic members?

[Maurizio Cimadamore]

Hi Jesse,
I understand where you are coming from, but I guess I question your 
numbers a little bit :-)

It is true that javac (and all javac compilers, really) emit lots of 
synthetics nowadays - those are used for a number of reasons:

1) accessibility for otherwise inaccessible members in inner classes
2) erasure bridges
3) visibility bridges (*)
4) lambda translation methods
...

Of these, the only ones that could be considered redundant are those in 
(3) - provided you don't care about runtime reflection. Disabling 
synthetics for all the others will result in significant semantics 
change (lambdas are the extreme case - if you drop the synthetic, your 
lambda body goes away and the code won't even link!).

I believe what you want is to tweak the source code so as to minimize 
generation of those synthetic methods (which you have done already - to 
some degree). If you stick with public members and avoid use of generics 
when overriding methods, I think you would have reduced the need of the 
most common sources for synthetic methods.

If you want to make this more 'official' you can even write an 
annotation processor or - better, a compiler plugin [1], to enforce the 
rules that you think are providing the best results under your 
circumstances. I think adding a compiler switch is addressing the 
problem at the wrong level.

However, if you find cases where the compiler is obviously emitting 
redundant synthetic methods - please do let us know - as these will need 
to be treated as bugs.

[1] - 
https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/util/Plugin.html

Maurizio

On 21/12/15 23:47, Jesse Wilson wrote:
>
> I’m using javac to build libraries that target both Android and 
> desktop Java. Android is particularly sensitive to the size of the 
> compiled classes. But smaller classes improves performance everywhere.
>
> I’ve noticed that javac likes to synthesize additional members to 
> build visibility trampolines for nested classes. In the compiled code 
> for OkHttp <https://github.com/square/okhttp/>, nearly 10% of the 
> method references are synthetic!
>
> I’m tempted to create a classfile rewriter to remove these synthetic 
> members. It’d have to promote some |private| things to 
> |package-private| to make the synthetic things unnecessary.
>
> One alternative to classfile magic would be a new javac flag like 
> |--avoid-synthetic-members|. Such a flag would change |private| 
> members to |package-private| when those members were accessed by 
> nested classes. The compiled code would be smaller, run faster, and 
> have less weird garbage in the stack traces.
>
> Are javac maintainers receptive to a patch that adds such a flag? 
> What’s the process of turning this proposal into a feature?
>
> Thanks.
> Jesse Wilson
>
> ​

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20151222/880b3127/attachment.html>