— Scott McNealy, Sun Microsystems Chairman, President and ceo

HeadFirst: 
Can I get a clear example?
Inner object: 
Remember the drawing panel we used, 
where we made our own subclass of JPanel? Right now, 
that class is a separate, non-inner, class. And that’s fine, 
because the class doesn’t need special access to the instance 
variables of the main GUI. But what if it did? What if
we’re doing an animation on that panel, and it’s getting its 
coordinates from the main application (say, based on some-
thing the user does elsewhere in the GUI). In that case, if
we make the drawing panel an inner class, the drawing 
panel class gets to be a subclass of JPanel, while the outer 
class is still free to be a subclass of something else. 
HeadFirst: 
Yes I see! And the drawing panel isn’t reus-
able enough to be a separate class anyway, since what it’s 
actually painting is specific to this one GUI application.
Inner object: 
Yes! You’ve got it! 
HeadFirst: 
Good. Then we can move on to the nature of
the relationship between you and the outer instance.
Inner object: 
What is it with you people? Not enough 
sordid gossip in a serious topic like polymorphism?
HeadFirst: 
Hey, you have no idea how much the public is 
willing to pay for some good old tabloid dirt. So, someone 
creates you and becomes instantly bonded to the outer 
object, is that right?
Inner object: 
Yes that’s right. And yes, some have 
compared it to an arranged marriage. We don’t have a say 
in which object we’re bonded to.
HeadFirst: 
Alright, I’ll go with the marriage analogy. 
Can you get a divorce and remarry something else?
Inner object: 
No, it’s for life. 
HeadFirst: 
Whose life? Yours? The outer object? Both?
Inner object: 
Mine. I can’t be tied to any other outer 
object. My only way out is garbage collection.