October 22, 2016
Hot Topics:

Privileged code in Java: Why the API changed from JDK1.2beta3 to JDK1.2beta4

  • August 31, 1998
  • By Gary McGraw
  • Send Email »
  • More Articles »

Why not to use inner classes

Some Java books say that inner classes can only be accessed by the classes that enclose them. But that is not true. Inner classes are implemented by converting them to plain old top-level classes. That's because most Java VM implementations have no notion of inner classes. In the end, inner classes boil down to a shorthand for top-level classes.

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

to read data from a file in many places in a program. Many programmers are likely to repeatedly write the same anonymous class instead of factoring the code out into a top-level class, instinctually going for the "more convenient" inner class.

Page 2 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel