Privileged code in Java: Why the API changed from JDK1.2beta3 to JDK1.2beta4
What might seem to be a minor implementation detail actually has severe ramifications. Inner classes happen to be accessible to any code in the same package, and not just the class in which they are nested. And package-level visibility can not be relied on for security. Java packages are not closed, allowing an attacker to introduce a new class inside your package. With this new class, the attacker might access things you thought were hidden inside your inner class.
It gets worse. An inner class is allowed to access the fields of enclosing classes, even if those fields are declared private. Since the inner class is treated as a separate top-level class, the way that such access is generally implemented is to silently change private fields to package accessibility. It's bad enough that the inner class is exposed; but it's even worse that the compiler is silently overruling your decision to make some fields private.
In addition, inner classes promote a programming style that detracts from the notions of reuse and encapsulation, which are primary goals of the object-oriented paradigm. Inner classes are often tightly coupled to the class in which they are nested. The language promotes this sort of coupling by giving inner classes indiscriminate access to their containing class. So instead of having two classes talking by higher level abstractions, programmers are encouraged to let their classes communicate through private variables and methods. Such interdependencies can lead to maintenance problems.
Inner classes also have a conceptually limited visibility (since they're only supposed to be visible to the class or method in which they're nested), which does not encourage factoring out common code. We have seen code in the real world with tons of small but similar inner classes, where all the inner classes were essentially duplicating the same behavior.
For example, assume a programmer wants to use
Page 2 of 2