Cooperating with Other APIs
 Have You Ever Wondered...?
Did you ever write an application against one version of Java just to find out that it does not work with newer version? I guess everyone faced that situation, however did you ever faced that with your library? Did you change nothing in your library, yet your customers complain that their code using your library classes does not run or even compile with newer version of Java? I guess some of us have been in such situation, facing TransitivityOfIncompatibleChange. This is an inevitable impact caused not only by Java but by cooperating with any API created by others. Chapter 10 analyses why we have problems when working with foreign APIs and suggest strategies to deal with such situations.
 Clarity of Modifiers
Introducing the String class in re-export sample is bit artificial and decreases readability. At least it should be renamed to something like LibraryString.
There suddenly appears the Query library in the text not being introduced anywhere. Don't get confused. The only important thing to know about this library is that it is returning the re-exported String on computeReply() method call.
The text is unfortunately silently referring to the side note story (code completion). So when you read the text first and the NetBeans stories later you can get confused slightly.
"Because they are protected, calling them from a subclass has no meaning, as they don’t provide any implementation in the defining class." should be "Because they are abstract, calling them from a subclass has no meaning, as they don’t provide any implementation in the defining class."
--Silentfish 09:29, 10 September 2009 (UTC)
Type parameter is bit confusing. While most of the people are familiar with single uppercase letter (like T, E, V) and can easily recognize them as a type parameter author is using Configuration and switch to C just a few lines later.