5

I have the following code:

public class SomeClass {
   //InterfaceUpdateListener is an interface
   private InterfaceUpdateListener listener = new InterfaceUpdateListener(){
        public void onUpdate() {
           SomeClass.this.someMethod();  //complier complains on this line of code
        }
   };

   private void someMethod() {
     //do something in here on an update event occuring
   }

   //other code to register the listener with another class...
}

My compiler in Eclipse complains that

Access to enclosing method 'someMethod' from type SomeClass is emulated by a synthetic accessor method.

Can anyone explain exactly

  1. what this means,
  2. what the possible ramifications might mean if I leave it as is (since its only a warning), and
  3. how I might fix it?

Thanks

J Richard Snape
  • 20,116
  • 5
  • 51
  • 79
Chris Knight
  • 24,333
  • 24
  • 88
  • 134
  • 1
    Duplicate of http://stackoverflow.com/questions/921025/eclipse-warning-about-synthetic-accessor-for-private-static-nested-classes-in-jav – JB Nizet Aug 12 '11 at 21:33
  • 1
    @JB Nizet, not exactly. I saw that question which deals with concrete inner classes rather than anonymous ones. I can't (AFAIK) add a constructor to my declaration to the error go away. – Chris Knight Aug 12 '11 at 21:41

2 Answers2

4

I would just deactivate the rule (i.e. make the compiler not generate warning for this). If the construction is legal, and if an additional method is added by the compiler to support it, then it's the way it must be done.

I doubt there is a significant loss of performance caused by this synthetic method. The JIT must inline it anyway if necessary.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • Thanks. I'm not worried about performance but this is new territory for me so want to make sure I design the code correctly in the first place since its critical to the rest of my application. – Chris Knight Aug 12 '11 at 21:50
  • Security implications ? see : http://stackoverflow.com/a/5559064/281545. I mean the method is not private anymore - it is package private - so why not declare it as such (related to my question in http://stackoverflow.com/questions/17772622/is-it-needed-to-declare-innards-of-private-inner-classes-private - I finally found a concrete reason for *not* declaring private members of Nested I access from Enclosing) – Mr_and_Mrs_D Oct 17 '13 at 15:53
  • 2
    Synthetic methods can cause serious hassles when debugging code. The hot code replacement doesn't support adding/removing methods, but it's not transparent to users when a synthetic method will be added/removed behind your back. – Mark Jeronimus May 30 '14 at 11:39
2

How about this? There's only one class declaration that has to be keept by your JVM (PermGen), implementing class is still not available outside SomeClass (I think this is the only legal intention to write an nested class anyway) and last but not least you might also provide a second constructor with InterfaceUpdateListener as argument (if needed for mor flexibility and testability). And ther's no need to change warnings.

expect

public interface InterfaceUpdateListener {
    public void onUpdate();
}

is provided, SomeClass might be implemented like this

public class SomeClass {
   //InterfaceUpdateListener is an interface
   private final InterfaceUpdateListener listener;
   private static class SomeClassInterfaceUpdateListener implements InterfaceUpdateListener {
       private final SomeClass internal;
       public SomeClassInterfaceUpdateListener(final SomeClass aSomeClass) {
           internal = aSomeClass;
       }
       @Override
       public void onUpdate() {
           internal.someMethod();  //complier complains on this line of code
       }
   }
   public SomeClass() {
       listener =  new SomeClassInterfaceUpdateListener(this);
   }
   private void someMethod() {
     //do something in here on an update event occuring
   }
}