• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Errors in "SCJD Exam with J2SE 5" book

 
Alecsandru Cocarla
Ranch Hand
Posts: 158
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Alecsandru Cocarla
Ranch Hand
Posts: 158
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 158
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 11831
181
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11831
181
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 11831
181
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 158
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 158
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic