Inner Class Confusion

[Robert Lippens]

I ran through Enthuware's practice Inheritance test, since that seems to be where I am struggling the most (along with explicit casting). Sufficient to say, I didn't do too well.

I am particularly stuck on this example of anonymous inner class/nested classes/local classes.

From what I understood an anonymous inner class looked something like this:

public class HelloWorldAnonymousClasses {
  
    interface HelloWorld {
        public void greet();
        public void greetSomeone(String someone);
    }

public void sayHello() {
        HelloWorld frenchGreeting = new HelloWorld() {
            String name = "tout le monde";
            public void greet() {
                greetSomeone("tout le monde");
            }
            public void greetSomeone(String someone) {
                name = someone;
                System.out.println("Salut " + name);
            }
        };

where you instantiate an implementation of the Interface via something like:

Interface i1 = new Interface() {
//implementation goes here
}

Now, they had the following, which I cannot follow whatsoever.

interface Worker { 
void perform_work();
 }
...
Worker getWorker(final int i){
  return new Worker() {
   public void perform_work() {
    System.out.println(i); }
   };
}

This class seems to lack the "new" keyword (aside from the return statement... which I also don't understand.) Are the first two lines equivalent to Worker getWorker = new Worker(final int i) { //implementation of interface methods here } ?

I've never seen an anonymous class example like this before, so it's throwing me for a loop!

[Mansukhdeep Thind]

It's simple Robert. getWorker(final int) method returns a Worker type that is fetched by implementing the Worker interface as an anonymous inner class when you say:

new Worker() {  
   public void perform_work() {  
    System.out.println(i); }  
   };

What's the exact confusion?

[Robert Lippens]

None now! I see what's going on after your explanation.

To test it out, I made in my main, something like Worker joe = getWorker(12);

This then ran the method getWorker, inside of which did exactly what you said it would. I could call joe.perform_work(); and it would print out whatever number I assigned joe in the method, which sort of acts like a ... constructor?

One more question about this.... why must my method declaration require a final parameter? Apparently it cannot be seen accessed from the perform_work method... but it lies within the method body?

[Winston Gutkowski]

Robert Lippens wrote:One more question about this.... why must my method declaration require a final parameter? Apparently it cannot be seen accessed from the perform_work method... but it lies within the method body?

This is the relevant page in the JLS. It has something to do with allowing the class to include a copy of the value, but I've forgotten the exact memory mechanics.

And TBH, you don't really need to know; just remember that you have to do it. If it's just idle curiosity, by all means read the link; but I warn you: it's not easy reading. I'm not even sure that it will explain why (it's been ages since I looked at it) - sometimes, you just have to do what you're told.

Winston

[Robert Lippens]

Thanks for the link. Indeed it sounds like it's just something that has to be done.

Any local variable, formal parameter, or exception parameter used but not declared in an inner class must be declared final.

is their exact wording! I think it's just my math brain demanding proofs for everything I read, I don't like the language just telling me what to do without knowing why

[Henry Wong]

Robert Lippens wrote:Thanks for the link. Indeed it sounds like it's just something that has to be done.

Any local variable, formal parameter, or exception parameter used but not declared in an inner class must be declared final.

is their exact wording! I think it's just my math brain demanding proofs for everything I read, I don't like the language just telling me what to do without knowing why

Well, technically, you should NOT be allowed to do it at all -- final or otherwise. The scope of parameters are for the duration of the method. The scope of instances are until it becomes unreachable -- and garbage collected. Since the method can go out of scope way before the instance is garbage collected, then it shouldn't be allowed to access the parameter -- even if the parameter is final.

So, you should not need proof as to why it is not allowed if the parameter is not final -- you should need proof as to why it is allowed at all !!


Anyway, it is a design of inner classes. If the inner class is trying to access a constant, meaning a final variable that already have been initialized, then it will make a copy of the value during initialization. At this point, the parameter is still in scope, so a copy is made. Later, when the code wants to access the parameter, it is actually accessing the copy, and not the actual parameter.

Henry

[Winston Gutkowski]

Robert Lippens wrote:I think it's just my math brain demanding proofs for everything I read, I don't like the language just telling me what to do without knowing why

That's certainly fair, but sometimes you can get bogged down in all that stuff. You don't need to understand all the intricacies of the internal combustion engine in order to be a racing driver. In fact, it'd probably be a distraction.

I'm sure Henry (or someone else) will correct me if I'm wrong, but as I recall, the 'why' is because the compiler generates a constructor for the inner class automatically that initializes the values it needs to copy. But don't ask me for details: I forgot 'em long ago and it doesn't seem to have slowed down my programming any.

Winston

[Paul Clapham]

Those fields which are secretly inserted by the compiler are called "synthetic" fields if I'm not mistaken. I believe the Java Language Specification describes them, but I've never bothered to look it up. I'm a mathematician too but when I ride my bicycle I don't need to know whether it's the gyroscope effect or the caster effect which keeps me upright.

[Robert Lippens]

Thanks for further explanation guys, it has satisfied my brain. Yeah, some of it I can get bogged down in, but I tend to forget things unless I can explain them to myself. If it's just some arbitrary fact (well, eventually it is an arbitrary fact/axiom) I find it difficult to keep in my head. If it has a reason, then I can reason about it later in case I forget the answer.

For instance, I just learned if I have a class with a constructor that throws an exception, if I subclass this class, the subclass constructor has to throw an exception that is a SUPERclass of the constructor's exception (the opposite of how the method subclassing exception rules work). I suppose I could have just remembered this fact, but having been able to explain it to myself now, I am sure I won't forget it as easily as without!

I haven't signed up for the OCAJ7 exam yet, so it's best I plan for the long run here