Hardcore Java Questions Thread

Question

Greetings,
I am otherwise known as Robert Simmons jr. O'Reilly has recently published my first book entitled hardcore java. Since the motivation for some of the content came from questions asked on this forum, I decided to make a question an answer thread on this forum to deal with your questions on the book, its content and topics.
You can find the book at O'Reilly:
http://www.oreilly.com/catalog/hardcorejv/
Or Amazon.com
http://www.amazon.com/exec/obidos/tg/detail/-/0596005687/qid=1080130526/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/103-4213374-6043826?v=glance&s=books&n=507846
It is also on sale in quite a few other places but I just mentioed two of the most popular.
Feel free to ask your questions and I will knock them down as quick as I can.
-- Robert Simmons Jr.

Answer 1

I read the sample chapter about using final and,
whilst I agree with you about using final beinggood
coding practise, there are a few points I wouldmake:
Example 2-2. Simple constants using final:
public static class CircleToolsBetter {
/** A value for PI. **/
public final static double PI = 3.141;I think you should limit the scope of that variableby
making it private.Why? What would be your motivation in hiding this
value? At any rate, the example you are mentioning
wasnt designed to demonstrate guarding access to
constants. I talk about that a bit later in the
chapter. There may be reasons for havign this private,
I concede that. Just in this example I cant think of
one. At any rate derived classes will probably need PI
so protected would be a better option if you want to
seal it off for some reason. I just think that you should always try to limit the scope of a variable as much as possible. I know that wasn't the point of that particular example, but I think it's good practise "in general".
At any rate derived classes will probably need PI so
protected would be a better option if you want to seal
it off for some reason.Ah, but what about classes (it's public in the example), they could reference that variable and then if it changes ...
In the section "Public Primitives and
Substitution" you don't mention anywhere thatyou
can get around the problem of having to recompile
dependant classes by using static initializion and
also by interning Strings. I think that would makea
good addition to that section.Good feedback, Ill think about that for revision 2.
There is some other material that didnt make that
chapter as well. =) However, I do talk abotu
initialization in detail in chapter one. You should
check it out. =) Do I have to buy the book : )
You say[i] "Most singleton classes shouldn't be
declared as final. You never know what otherfeatures
your class's user will dream up. However, since
singleton classes need to be protected fromexternal
instantiation, you can't make the constructorpublic.
The solution to the problem is a protected
constructor". I think you should add that thismeans you must put your singleton in a relevant
package (i.e. Not in a package with classes that
shouldn't be able to instantiate the singleton!)Of course you should always employ good package
management. In fact package management might be in
second edition as I do have quite a few notes on it.
However, a singleton can only instantiate itself and
that only once, so I dotn see why you think this is a
concern. The goal of protected constructors is to
prevent external instantiation of the class. Perhaps
you were thinking of constructors with "package
private" access (ie no public, private or protected
keyword used) ?? Protected constructors can only be
accessed bby the class and subclasses, whereas a
"package private" constructor can be accessed by any
class in the package.
A protected constructor is accessible to the class itself, its subclasses, and classes in the same package.