aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Errors in Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Errors in "SCJD Exam with J2SE 5" book" Watch "Errors in "SCJD Exam with J2SE 5" book" New topic
Author

Errors in "SCJD Exam with J2SE 5" book

Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
I hope this is the place to post some of the things which I think that are mistakes in the "SCJD Exam with J2SE 5 - Second edition" book.

I'm still reading it, so if anything else might pop-up in the meanwhile, I'll post it in this topic.

So,

1. In chapter 5 - Section "The DVD Class: A Value Object" - there's an affirmation which goes like: "a default constructor (required for any serialized object)". This is incorrect. Such constructor is only required for non-serializable super-classes of serializable classes.

2. In chapter 5 - Section "The logical Release Method" - there's no try/finally for calling unlock. I think this is quite important.

3. In chapter 5 - Section "Discussion point: Multiple Notification Objects" - this section can convince the reader that a hand-over mechanism for locking is required (not having this mechanism in Java 1.4 is mentioned as "a problem"). In my opinion this hand-over (at least in this case) is itself a problem, because until the thread acquires the dvdLock, it will also hold the masterLock, blocking all other threads that want to get it. In other words, for only one thread which wants to get a lock for a certain record we block a lot of other threads which are only interested in the masterLock.

In the end, I would also like to add that I think the book is a very good one and it helps me a lot in proceeding with the certification .

Good luck everybody.


SCJP 1.4 100%
SCJD 99.5%
Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
4. In chapter 6 - section "The classes and interfaces of RMI" - figure 6-7. The notation used resembles UML, but the generalization relationships are drawn backwards (the arrow should point to the more general type, not to the specialization). For someone used to reading UML diagrams it can be quite hard to follow figure 6-7.
[ November 01, 2008: Message edited by: Alecsandru Cocarla ]
Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
5. Code. In DvdFileAccess, the construcor looks like this:




Since database is not static, this code will always create a new database at every call (the private database is always null when calling this constructor). Which means:
- the javadoc "All instances of this class share the same data file" is not true
- the "else if" branch will never be entered (so it's useless)
- a new RandomAccessFile will be created at every construction. This is not a really bad idea, as long as you take care about this when creating a record (create operations do not lock the record, so theoretically one could create twice at the same offset)

Probably, the "database" was meant to be static.


Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11508
    
  95

Alecsandru Cocarla wrote:1. In chapter 5 - Section "The DVD Class: A Value Object" - there's an affirmation which goes like: "a default constructor (required for any serialized object)". This is incorrect. Such constructor is only required for non-serializable super-classes of serializable classes.

Thanks - I will add this to the errata.

Alecsandru Cocarla wrote:2. In chapter 5 - Section "The logical Release Method" - there's no try/finally for calling unlock. I think this is quite important.

Why do you think that?

In the reserveDvd section, there was the possibility of an InterruptedException being thrown by the call to await(), so we ensured that the unlock() method would get called in such a circumstance by putting that code in a finally block. However with the releaseDvd method, there are no exceptions that we think we might recover from (or declared), so there is no need to use the finally block.

Alecsandru Cocarla wrote:3. In chapter 5 - Section "Discussion point: Multiple Notification Objects" - this section can convince the reader that a hand-over mechanism for locking is required (not having this mechanism in Java 1.4 is mentioned as "a problem").

Hmm. I don't think it was my intention to indicate that hand-over-hand locking was required, and I apologize if it reads that way. The potential problem that can occur without hand-over-hand locking is a real problem though, however there are other ways of solving the issue (including the valid case of ignoring the problem as being "out of scope" for the SCJD project). ;)

Alecsandru Cocarla wrote:In my opinion this hand-over (at least in this case) is itself a problem, because until the thread acquires the dvdLock, it will also hold the masterLock, blocking all other threads that want to get it. In other words, for only one thread which wants to get a lock for a certain record we block a lot of other threads which are only interested in the masterLock.

Yes, there seems to be a problem here. I can see how to fix it such that it is using hand-over-hand locking while not blocking all other threads. I may not get a chance to look at it before the weekend though.

Alecsandru Cocarla wrote:In the end, I would also like to add that I think the book is a very good one and it helps me a lot in proceeding with the certification .

Thank you very much!

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11508
    
  95

Alecsandru Cocarla wrote:4. In chapter 6 - section "The classes and interfaces of RMI" - figure 6-7. The notation used resembles UML, but the generalization relationships are drawn backwards (the arrow should point to the more general type, not to the specialization). For someone used to reading UML diagrams it can be quite hard to follow figure 6-7.
Strange, I hadn't noticed that before.

I will have to get in touch with Terry and find out what his intention was there. I agree that it can be confusing.

Regards, Andrew
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11508
    
  95

Alecsandru Cocarla wrote:5. Code. In DvdFileAccess, the construcor ...

You have a lot of good points here, but I think we have covered them in Question from Andrew's book. Sorry that we started conversations in that topic rather than this one - I think it would have been better if I had seen this topic first and gone through all the items here.

Regards, Andrew
Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
Andrew Monkhouse wrote:
Alecsandru Cocarla wrote:2. In chapter 5 - Section "The logical Release Method" - there's no try/finally for calling unlock. I think this is quite important.

Why do you think that?

In the reserveDvd section, there was the possibility of an InterruptedException being thrown by the call to await(), so we ensured that the unlock() method would get called in such a circumstance by putting that code in a finally block. However with the releaseDvd method, there are no exceptions that we think we might recover from (or declared), so there is no need to use the finally block.


I agree, there's no visible exception declared which could be thrown.
However, I'd always put my unlock code in a finally block, you never know what happens (or how the code gets refactored).
Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
6. The PositiveIntegerField, and some other code in the GUI, make way for some nasty bugs, which mostly lead to application crash:

- entering a server port greater than 65534 will result in IllegalArgumentException for the server. The error is not signaled to the user, the server looks like it's working, but in fact it's crashed.
- entering an empty string for the port number results in NumberFormatException and crash for the server. Something somewhat similar for the networked client.
- entering a number which is greater than Integer.MAX_VALUE results in NumberFormatException and crash for the server. Something somewhat similar for the networked client.
- entering 0 for the server port will start the server on a random port, which means the clients will not be able to connect (entering 0 for the client won't work).
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Errors in "SCJD Exam with J2SE 5" book