javac flag to suppress synthetic members?

[Maurizio Cimadamore]

On 22/12/15 03:40, Jake Wharton wrote:
> javac is already rewriting the callsite to point at a completely 
> different method than the source indicates, and one that's not even 
> present anywhere in the original source file. In a strictly objective 
> look at the javac's rewriting behavior, the proposal is far less 
> drastic in terms of changes to the generated code than the current 
> behavior.
This is true for any synthetic code generation right? I.e. when the 
compiler emits synthetic code, a new discrepancy is added between source 
and classfile. But I think we also have to look under the lid and ask - 
why does this code end up here? In the case of accessor methods, without 
them it would be impossible to call non-public members of an enclosing 
class - which is something that the language allows you to do (and the 
VM doesn't, given the VM doesn't have a true notion of inner classes). 
In cases like these resorting to synthetic code is unavoidable, and 
dropping synthetic members will mean changing the language.

I still think that the idea I proposed (add extra static checks to 
enforce the rules you find useful, e.g. "no lambdas, no private access 
to enclosing classes, ....") might lead to a better outcome, since 
you'll be taming the beast at the right level - i.e. by deliberately 
restricting yourself not to use those features which cause too much 
synthetic code bloat.

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