java.util and anonymous class

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Mon Dec 5 02:37:03 PST 2011


On 05/12/11 10:20, Rémi Forax wrote:
> While removing generics warnings in java.util,
> I've seen that some anonymous classes are coded in a way that
> make javac to generate too much fields.
>
> This code:
> final List<String> list = Arrays.asList(args);
>     Iterator<String> iterator = new Iterator<String>() {
>       private Iterator<String> it = list.iterator();
>
>       ...
>       }
>     };
>
> generates an anonymous class with two fields:
> final class Foo$1 implements java.util.Iterator<java.lang.String> {
>   java.util.Iterator<java.lang.String> it;
>   final java.util.List val$list;
>   FinalCaptureTooBig$1(java.util.List);
> ...
>
> while this code:
> List<String> list = Arrays.asList(args);
>     final Iterator<String> it = list.iterator();
>     Iterator<String> iterator = new Iterator<String>() {
> ...
>
> generates an anonymous class with only one field:
> final class FinalCaptureTooBig$1 implements 
> java.util.Iterator<java.lang.String> {
>   final java.util.Iterator val$it;
>   FinalCaptureTooBig$1(java.util.Iterator);
> ...
>
> If javac was smart, it should generate only one field because the 
> variable 'list' is only
> use in the initializer of a field, so 'list' has to be passed as 
> parameter of the constructor
> but don't need to be stored as a field.
>
> Note that this change in javac may break the serialization compatibility,
> so may be it's not a good idea to change javac. Or we can say that we 
> don't care
> because there is an item in Effective Java that says that you should 
> not use
> an anonynous class.
>
> Should we change the code of java.util or javac ?
My 0.02$ is that it is potentially a risky change (as you point out) to 
do in the compiler, and not such a straightforward one as well (javac 
currently does not distinguish as to whether a variable is accessed from 
a variable initializer w.r.t. form inside a method body). Of course, it 
could be done - but I think it'd be wiser to invest time on making 
lambda better so that people will be less and less forced to use inner 
classes ;-)

Maurizio
>
> cheers,
> Rémi
>
>
>
>




More information about the compiler-dev mailing list