New page: '''Done: 74d64dca0394''' The example of the JDK as non-modular may be out of date by the time you go to print! :) * I am afraid we publish few years sooner I'd like some discussion of ...
New page
'''Done: 74d64dca0394'''
The example of the JDK as non-modular may be out of date by the time you go to print! :)
* I am afraid we publish few years sooner
I'd like some discussion of how you modularize a project that already has a large, non-modular, full-of-spaghetti code base.
I think this would resonate with a lot of programmers.
* I may blog about it or describe that in wiki, but for the book it would be maybe too detailed. Just remind me.
Also, I'd like you to address non-runtime modularization. That is, just enforcing module dependencies at compile time, in the
ant script. It's perfectly valid, requires no additional software like OSGI, but has some pitfalls (Class.forName, etc).
For some organizations that are mistrustful of runtime modularization's performance impact (warranted or not), it's better
than nothing.
* I have contributed description of Ant [http://ant.apache.org/manual/CoreTasks/javac.html Javac task parameters], search for '''sourcepath=""'''
--[[User:RichUnger|RichUnger]] 22:40, 10 April 2008 (UTC)
# Page 99: "Modular programming is here to make it happen." This implies that modular programming encourages the degradation of the architecture rather than preventing it, so you probably meant "Modular programming is here to help prevent it."
--[[User:TomWheeler|TomWheeler]] Sat Apr 12 19:13:37 CDT 2008
'''Done: 134c6f9cad88'''
Page 103, para 1: "using some sort of Hashtable" -- <tt>DriverManager</tt> uses <tt>Vector</tt>'s (but sure, you can view it as a dictionary with <tt>O(N)</tt> complexity). The registration is static, but there is a <tt>deregisterDriver</tt> method (sad, but it is only today that I learned about it). ConnectionPool should probably be <tt>DataSource</tt>. "J2EE" should probably be "Java EE".
--[[User:AndreiBadea|AndreiBadea]] 09:59, 7 April 2008 (UTC)
I'm not sure what "missing method exceptions" are. There are various kinds of LinkageError, but these are errors, not exceptions.
URLHandlerFactory: you mean URLStreamHandlerFactory.
Crimson is so obsolete no one will know what you are talking about. On the other hand, I cannot actually find any implementations of DOM in Java other than Xerces-J.
"I hear that..." is not a confidence-inspiring statement in a book pretending to authority. Research it, and if true, state it definitively.
--[[User:JesseGlick|JesseGlick]] 01:36, 8 April 2008 (UTC)
Page 102: "There is a need for some sort of 'indirect dependency' declaration..." Who needs this and why? An example here would help explain the need in less theoretical terms.
* you need to read the whole sentence, it says '''to ...'''
--[[User:TomWheeler|TomWheeler]] Sat Apr 12 19:13:37 CDT 2008
'''Done: dd09dc43619c''' - I am currently rewriting this part to reflect your comments. As the topic is quite alive, I have also created a dedicated online page for this called [[Injection]].
Page 104, para -1: "The you hope that the framework will" sounds a bit emotional to me for a technical writing. "In Spring you define setters" -- you are not restricted to setters, you can also use constructor parameters.
Page 107, para 2: "As the JDK already contains the <tt>ServiceLoader</tt> API": isn't "Java platform" more appropriate than "JDK"?
<tt>LookupListener</tt> example: the parameter of <tt>resultChanged</tt> should have a sane name, not <tt>arg0</tt>, even if it is not used.
--[[User:AndreiBadea|AndreiBadea]] 10:10, 7 April 2008 (UTC)
This section seems to me to diverge from the goal of talking about how to write APIs, to cover the details of one (relatively unpopular) component assembly framework. I would instead expect a general discussion of the purpose of such frameworks, followed by a list of the major ones (ServiceLoader, Lookup, Spring, Spring with annotations, the various OSGi service discovery APIs, Eclipse extension points), with a brief explanation of the advantages of each. The defensive tone of the sidebars is also unbecoming; this is not the right place to defend your personal architecture from critics.
--[[User:JesseGlick|JesseGlick]] 01:44, 8 April 2008 (UTC)
p.38: meta-inf/services/foo.Service isn't a configuration file?
--[[User:RichUnger|RichUnger]] 22:40, 10 April 2008 (UTC)
Page 103: "However, we are not unaware" - Avoid the double negative.
Page 108: Again, I do not understand the image in Figure 8-1 nor its relevance of teleinterfaces. I don't think many readers would be able to explain the concept of a teleinterface at this point in the book.
--[[User:TomWheeler|TomWheeler]] Sat Apr 12 19:13:37 CDT 2008
I find much of the text in this section to be too NetBeans-specific. I agree with Jesse that it might make sense to talk a bit less about NetBeans details and a bit more about other popular component frameworks.
--[[User:AdamDingle|AdamDingle]] 00:43, 13 April 2008 (UTC)
'''Done: bc774fd94cce'''
<tt>TipOfTheDay</tt> example: <tt>sayHello</tt> doesn't seem a good name for the method. How about <tt>getTip</tt>?
Page 109, para -2,-4: extra "s" in <tt>TipsOfTheDay</tt>.
Page 109, para -2: "TipsOfTheDayProvider" should probably be "<tt>TipOfTheDay</tt>" provider.
Page 110, para 4: extra "s" in <tt>TipsOfTheDay</tt>.
--[[User:AndreiBadea|AndreiBadea]] 11:39, 7 April 2008 (UTC)
"Each module that would like to register its TipsOfTheDayProvider needs to have to core
module on classpath" - I don't understand this sentence. There's either a typo or a grammar mistake here, but I'm confused enough that I don't know what you're saying, so I can't suggest a fix.
--[[User:RichUnger|RichUnger]] 22:40, 10 April 2008 (UTC)
'''Done: b058ea24096e'''
Page 113, code example: <tt>encode</tt> should be <tt>encrypt</tt>. And probably it should return a <tt>byte[]</tt>. OK, you claim the example is a bit artificial, so consider this a nit pick.
Page 112: image uses <tt>Encoder</tt> instead of <tt>Encryptor</tt>.
Page 112, code example: why do you use a plain <tt>assert</tt> in the <tt>encrypt</tt> method? In production builds, when assertions are turned off, this will fail with a meaningless <tt>NullPointerException</tt>.
--[[User:AndreiBadea|AndreiBadea]] 13:06, 8 April 2008 (UTC)
Your discussion seems to be specific to NetBeans. Are you suggesting that every component system should disallow cyclic dependencies? If so, you should say that explicitly. Do other component systems (e.g. Spring?) allow cycles between components?
--[[User:AdamDingle|AdamDingle]] 00:46, 13 April 2008 (UTC)
'''Done: d0b6efbc74d8'''
Page 115: only seasoned NetBeans developers will know what <tt>ic</tt> in <tt>ic.add(new ModifiedImpl(this))</tt> stands for. I think you can just drop the example.
Page 116: code example: <tt>CatQueryImplementation</tt> should probably be an interface. You claimed in a previous section that interfaces are to be preferred to abstract classes. Moreover, see Jesse's comment in [[Are Abstract Classes Useful?]] about protected methods in abstract classes.
I would also argue that the example is too artificial. <tt>FileEncodingQuery</tt> would pehaps be a better example.
--[[User:AndreiBadea|AndreiBadea]] 13:20, 8 April 2008 (UTC)
The example of the JDK as non-modular may be out of date by the time you go to print! :)
* I am afraid we publish few years sooner
I'd like some discussion of how you modularize a project that already has a large, non-modular, full-of-spaghetti code base.
I think this would resonate with a lot of programmers.
* I may blog about it or describe that in wiki, but for the book it would be maybe too detailed. Just remind me.
Also, I'd like you to address non-runtime modularization. That is, just enforcing module dependencies at compile time, in the
ant script. It's perfectly valid, requires no additional software like OSGI, but has some pitfalls (Class.forName, etc).
For some organizations that are mistrustful of runtime modularization's performance impact (warranted or not), it's better
than nothing.
* I have contributed description of Ant [http://ant.apache.org/manual/CoreTasks/javac.html Javac task parameters], search for '''sourcepath=""'''
--[[User:RichUnger|RichUnger]] 22:40, 10 April 2008 (UTC)
# Page 99: "Modular programming is here to make it happen." This implies that modular programming encourages the degradation of the architecture rather than preventing it, so you probably meant "Modular programming is here to help prevent it."
--[[User:TomWheeler|TomWheeler]] Sat Apr 12 19:13:37 CDT 2008
'''Done: 134c6f9cad88'''
Page 103, para 1: "using some sort of Hashtable" -- <tt>DriverManager</tt> uses <tt>Vector</tt>'s (but sure, you can view it as a dictionary with <tt>O(N)</tt> complexity). The registration is static, but there is a <tt>deregisterDriver</tt> method (sad, but it is only today that I learned about it). ConnectionPool should probably be <tt>DataSource</tt>. "J2EE" should probably be "Java EE".
--[[User:AndreiBadea|AndreiBadea]] 09:59, 7 April 2008 (UTC)
I'm not sure what "missing method exceptions" are. There are various kinds of LinkageError, but these are errors, not exceptions.
URLHandlerFactory: you mean URLStreamHandlerFactory.
Crimson is so obsolete no one will know what you are talking about. On the other hand, I cannot actually find any implementations of DOM in Java other than Xerces-J.
"I hear that..." is not a confidence-inspiring statement in a book pretending to authority. Research it, and if true, state it definitively.
--[[User:JesseGlick|JesseGlick]] 01:36, 8 April 2008 (UTC)
Page 102: "There is a need for some sort of 'indirect dependency' declaration..." Who needs this and why? An example here would help explain the need in less theoretical terms.
* you need to read the whole sentence, it says '''to ...'''
--[[User:TomWheeler|TomWheeler]] Sat Apr 12 19:13:37 CDT 2008
'''Done: dd09dc43619c''' - I am currently rewriting this part to reflect your comments. As the topic is quite alive, I have also created a dedicated online page for this called [[Injection]].
Page 104, para -1: "The you hope that the framework will" sounds a bit emotional to me for a technical writing. "In Spring you define setters" -- you are not restricted to setters, you can also use constructor parameters.
Page 107, para 2: "As the JDK already contains the <tt>ServiceLoader</tt> API": isn't "Java platform" more appropriate than "JDK"?
<tt>LookupListener</tt> example: the parameter of <tt>resultChanged</tt> should have a sane name, not <tt>arg0</tt>, even if it is not used.
--[[User:AndreiBadea|AndreiBadea]] 10:10, 7 April 2008 (UTC)
This section seems to me to diverge from the goal of talking about how to write APIs, to cover the details of one (relatively unpopular) component assembly framework. I would instead expect a general discussion of the purpose of such frameworks, followed by a list of the major ones (ServiceLoader, Lookup, Spring, Spring with annotations, the various OSGi service discovery APIs, Eclipse extension points), with a brief explanation of the advantages of each. The defensive tone of the sidebars is also unbecoming; this is not the right place to defend your personal architecture from critics.
--[[User:JesseGlick|JesseGlick]] 01:44, 8 April 2008 (UTC)
p.38: meta-inf/services/foo.Service isn't a configuration file?
--[[User:RichUnger|RichUnger]] 22:40, 10 April 2008 (UTC)
Page 103: "However, we are not unaware" - Avoid the double negative.
Page 108: Again, I do not understand the image in Figure 8-1 nor its relevance of teleinterfaces. I don't think many readers would be able to explain the concept of a teleinterface at this point in the book.
--[[User:TomWheeler|TomWheeler]] Sat Apr 12 19:13:37 CDT 2008
I find much of the text in this section to be too NetBeans-specific. I agree with Jesse that it might make sense to talk a bit less about NetBeans details and a bit more about other popular component frameworks.
--[[User:AdamDingle|AdamDingle]] 00:43, 13 April 2008 (UTC)
'''Done: bc774fd94cce'''
<tt>TipOfTheDay</tt> example: <tt>sayHello</tt> doesn't seem a good name for the method. How about <tt>getTip</tt>?
Page 109, para -2,-4: extra "s" in <tt>TipsOfTheDay</tt>.
Page 109, para -2: "TipsOfTheDayProvider" should probably be "<tt>TipOfTheDay</tt>" provider.
Page 110, para 4: extra "s" in <tt>TipsOfTheDay</tt>.
--[[User:AndreiBadea|AndreiBadea]] 11:39, 7 April 2008 (UTC)
"Each module that would like to register its TipsOfTheDayProvider needs to have to core
module on classpath" - I don't understand this sentence. There's either a typo or a grammar mistake here, but I'm confused enough that I don't know what you're saying, so I can't suggest a fix.
--[[User:RichUnger|RichUnger]] 22:40, 10 April 2008 (UTC)
'''Done: b058ea24096e'''
Page 113, code example: <tt>encode</tt> should be <tt>encrypt</tt>. And probably it should return a <tt>byte[]</tt>. OK, you claim the example is a bit artificial, so consider this a nit pick.
Page 112: image uses <tt>Encoder</tt> instead of <tt>Encryptor</tt>.
Page 112, code example: why do you use a plain <tt>assert</tt> in the <tt>encrypt</tt> method? In production builds, when assertions are turned off, this will fail with a meaningless <tt>NullPointerException</tt>.
--[[User:AndreiBadea|AndreiBadea]] 13:06, 8 April 2008 (UTC)
Your discussion seems to be specific to NetBeans. Are you suggesting that every component system should disallow cyclic dependencies? If so, you should say that explicitly. Do other component systems (e.g. Spring?) allow cycles between components?
--[[User:AdamDingle|AdamDingle]] 00:46, 13 April 2008 (UTC)
'''Done: d0b6efbc74d8'''
Page 115: only seasoned NetBeans developers will know what <tt>ic</tt> in <tt>ic.add(new ModifiedImpl(this))</tt> stands for. I think you can just drop the example.
Page 116: code example: <tt>CatQueryImplementation</tt> should probably be an interface. You claimed in a previous section that interfaces are to be preferred to abstract classes. Moreover, see Jesse's comment in [[Are Abstract Classes Useful?]] about protected methods in abstract classes.
I would also argue that the example is too artificial. <tt>FileEncodingQuery</tt> would pehaps be a better example.
--[[User:AndreiBadea|AndreiBadea]] 13:20, 8 April 2008 (UTC)