'. '

Cooperating with Other APIs

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Current revision (07:19, 17 October 2009) (edit) (undo)
(Have You Ever Wondered...?)
 
(4 intermediate revisions not shown.)
Line 1: Line 1:
-
Forgive the linguist in me (I did work on speech recognition for 8 years), but the expression is "painting ourselves into a corner". You can't paint yourself into anything else, or it's a broken metaphor :) I saw this particular expression used wrongly a few times in the book.
+
== Have You Ever Wondered...? ==
-
--[[User:RichUnger|RichUnger]] 22:40, 10 April 2008 (UTC)
+
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 ==
-
Talk to Tim, this is his sentence. As far as I can say, we have "Zahnat se do kouta" - chase yourself into a corner. Which is also a non-sense as you cannot chase yourself. But still it is widely used here and has the right meaning of doing wrong mistakes yourself that you are then sorry for.
+
This chapter also discusses problem with access modifiers in [[Java]] and how to avoid it. See [[ClarityOfAccessModifiers]] page.
-
--[[User:JaroslavTulach|JaroslavTulach]]
+
 
 +
== [[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.

Personal tools
buy