Question

Take the following example:

public void init() {
    final Environment env = new Environment();
    Runtime.getRuntime().addShutdownHook(new Thread() {
        public void run() {
             env.close();
        }
     });
}

Firstly, where is env stored? Is it:

  • copied by the compiler into a hidden member variable of the inner class that references it
  • copied to, and referenced on, the heap
  • left on the stack and somehow referenced there
  • something else

My guess is the first option.

Secondly, do any performance issues that arise from doing this (rather than simply creating env as a member variable of the class and referencing it as such) particularly if you are creating large numbers of such inner class constructs that reference final local variables.

Was it helpful?

Solution

Yes, they are copied, which is why you have to declare the variable as final. This way, they are guaranteed to not change after the copy has been made.

This is different for instance fields, which are accessible even if not final. In this case, the inner class gets a reference to the outer instance that it uses for this purpose.

private Environment env;  // a field does not have to be final

public void init() {
    Runtime.getRuntime().addShutdownHook(new Thread() {
        public void run() {
             env.close();
        }
     });
}

Secondly, do any performance issues that arise from doing this?

Compared to what? You need to have the field or variable around for your inner class to work, and a copy is a very efficient way. It is only a "shallow" copy anyway: just the reference to the (in your example) Environment is copied, not the Environment itself.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top