Cooperating with Other APIs
From APIDesign
(Removing all content from page) |
(→Have You Ever Wondered...?) |
||
| (3 intermediate revisions not shown.) | |||
| Line 1: | Line 1: | ||
| + | == 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. [[Cooperating with Other APIs|Chapter 10]] analyses why we have problems when working with foreign APIs and suggest strategies to deal with such situations. | ||
| + | |||
| + | == Clarity of Modifiers == | ||
| + | |||
| + | This chapter also discusses problem with access modifiers in [[Java]] and how to avoid it. See [[ClarityOfAccessModifiers]] page. | ||
| + | |||
| + | |||
| + | == [[Errata 10|Errata]] == | ||
| + | |||
| + | {{:Errata 10}} | ||
Current revision
Contents |
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
This chapter also discusses problem with access modifiers in Java and how to avoid it. See ClarityOfAccessModifiers page.
Errata
Page 160
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.
Page 164
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.
Page 173
"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)
Page 178
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.
Follow
