March 2, 2021
Hot Topics:

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

  • By Gary McGraw
  • Send Email »
  • More Articles »

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.

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.

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

This article was originally published on August 31, 1998

Enterprise Development Update

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

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