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.
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.