Inner Classes ?
Java bytecode has no concept of inner classes, so the compiler translates inner classes into ordinary classes that are accessible to any code in the same package. An inner class gets access to the fields of the enclosing outer class梕ven if these fields are declared private梐nd the inner class is translated into a separate class. To let this separate class access the fields of the outer class, the compiler silently changes these fields' scope from private to package. As a result, when you use inner classes, you not only have the inner class exposed, but you also have the compiler silently overruling your decision to make some fields private.
After reading the above I wanted to clarify what is the benefit of using inner classes.
Thanks
[762 byte] By [
RYALIa] at [2007-10-3 3:46:42]
The compiler doesn't 'silently change' anything.
Anything which is declared inside a scope has access to everything in that scope. The access modifiers control what the visibility is outside that scope.
Inner classes can be declared public, protected, package-protected, or private, just like any other class.
What is the problem again?
ejpa at 2007-7-14 21:43:29 >
> The compiler doesn't 'silently change' anything.
A quick google hunt would suggest that this somewhat correct:
http://www.ftponline.com/javapro/2004_03/online/rule2_03_17_04/
http://www.owasp.org/index.php/Publicizing_of_private_data_when_using_inner_classes
http://www.javaworld.com/javaworld/jw-12-1998/jw-12-securityrules_p.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4097812
[ http://forum.java.sun.com/thread.jspa?threadID=742333 ]
> What is the problem again?
No idea really.
mlka at 2007-7-14 21:43:29 >
> After reading the above I wanted to
> clarify what is the benefit of using inner classes.
Scope. I'm not talking about run time protection. You can always get round that somehow.
I'm talking about design. Well used innerclasses will help make your code more readable.
mlka at 2007-7-14 21:43:29 >
I have to say that the only time I use them is for GUI stuff (anonymouse inner classes). Are they useful? Not really. You will rarely see/use them in practice. Will it make your code more readable? I don't really see how. It's 6 in one...
They are very useful as delegates of various kinds.
As listeners (even if there's only one listeners of with a particular interface from a class it's undesireable to make the inteface method public).
When returning things like iterators.
When it's natural that some child object be largely internal.
When hiding concrete implementations inside factories or abstract classes.
They also save unecessary name space polution and keep the number of source files down.
> > The compiler doesn't 'silently change' anything.
>
> A quick google hunt would suggest that this somewhat
> correct:
I was referring to the statement 'the compiler silently changes these fields' scope from private to package'. It is not correct, and any references than can be cited that support it such as #3 are certainly mistaken.
It is the location of the class itself in the package scope that causes the issue and it is cured simply by making the inner class private. Or is the contention now that doing that also causes the compiler to silently change these fields back how they were?
ejpa at 2007-7-14 21:43:29 >
>
> I was referring to the statement 'the compiler
> silently changes these fields' scope from private to
> package'. It is not correct, and any references than
> can be cited that support it such as #3 are certainly
> mistaken.
>
There's surely a potential difference between access modifiers as they affect compilation, and at the bytecode level.
The compiler, certainly, knows all about inner classes and appropriate access restrictions.
