Privileged code in Java: Why the API changed from JDK1.2beta3 to JDK1.2beta4
Why not to use inner classes
by Gary McGraw and John Viega 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.
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.
Return to the article Privileged code in Java: Why the API changed from JDK1.2beta3 to JDK1.2beta4
Gary McGraw, Ph.D., is vice President of Reliable Software Technologies. Dr. McGraw is a noted authority on Java security and co-authored Java Security: Hostile Applets, Holes & Antidotes (Wiley, 1996) with Prof. Ed Felten of Princeton. They are currently writing a second book, Securing Java: Getting Down to Business with Mobile Code, available in late 1998. Along with RST's Dr. Jeff Voas, McGraw has written Software Fault Injection: Inoculating Programs Against Errors (Wiley, 1998). Dr. McGraw also has over 50 peer-reviewed publications, consults with major e-commerce vendors such as Visa, and is principal investigator on grants from the U.S. Air Force Research Labs, DARPA and NIST's Advanced Technology Program.
John Viega is a research associate at Reliable Software Technologies. He holds a M.S. in computer science from the University of Virginia. Viega developed and maintains mailman, the gnu mailing list manager. His research interests include software assurance, programming languages and object-oriented systems.
Portions of this article are taken by permission from Securing Java: Getting Down to Business with Mobile Code (John Wiley & Sons, 1998), the second edition of McGraw and Felten's book Java Security: Hostile Applets, Holes, & Antidotes.
Page 2 of 2