wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes It IS possible to pass without implementing create/delete! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "It IS possible to pass without implementing create/delete!" Watch "It IS possible to pass without implementing create/delete!" New topic
Author

It IS possible to pass without implementing create/delete!

Min Huang
Ranch Hand

Joined: Mar 17, 2004
Posts: 100
Hello fellow ranchers! I responded to a post a while back saying that create and delete don't have to be implemented (that is, they can have empty implementations), but nobody was sure about that. Well, I became the first guinea pig for the URLyBird assignment to test out that theory. It is possible to pass without writing a single line of code for create and delete! Here's the relevant thread where it was discussed: http://www.coderanch.com/t/185598/java-developer-SCJD/certification/unspecified-requirements
Actually, I was just talking with a fellow test taker and we were mulling about how it took so long to get our results, but then I checked the certmanager database and BING! like a blue bolt there's a new entry in my test history and a P dangling right next to it!
My score is nothing spectacular but I feel so happy with it
Grade: P
Score: 348
Comment: This report shows the total 1.4 SCJD points that could have been awarded in each section, and the actual number of points you were awarded. This is provided to give you per-section feedback on your strengths. The maximum possible score is 400; the minimum to pass is 320.
General Considerations (maximum = 100): 99
Documentation (maximum = 70): 70
O-O Design (maximum = 30): 15
GUI (maximum = 40): 40
Locking (maximum = 80): 44
Data store (maximum = 40): 40
Network server (maximum = 40): 40
Yup, I got the "standard" 44/80 locking score.
BTW, Thanks to EVERYBODY in this forum!! I couldn't have passed without your help!
[ May 01, 2004: Message edited by: Min Huang ]

SCJP 1.4, SCJD 1.4, SCBCD (Preparing!)
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11432
    
  85

Thanks for letting us know Min,
Everybody - lets leave this thread for discussing "empty implementations" of required methods.
Min has another thread for announcing his success in passing SCJD. Please post any congratulatory messages in this thread.
Thanks, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Javini Javono
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
Hi,

Min Huang wrote:
General Considerations (maximum = 100): 99
Documentation (maximum = 70): 70
O-O Design (maximum = 30): 15
GUI (maximum = 40): 40
Locking (maximum = 80): 44
Data store (maximum = 40): 40
Network server (maximum = 40): 40
Yup, I got the "standard" 44/80 locking score.

Not sure why you received the 44/80 locking score; this has been speculated on
before, but no one knows. Perhaps it only takes one, small subtle error to lose
quite a lot of points (would be my speculation).
Your "Data store" score was at the maximum. If you could, here are some
questions I have (although I've already done the design and development, so at
this point, it is mainly curiousity):
1. Does your database function in "stand alone" mode. That is, can the Sun
examiner write their own code to use your database and test your database?
2. Does your database have different rules that are dynamically set at run-time
either through a preferences file or through the client application hard-coding
them. Here are some rules my database has:
2.a: The definition of a key which defines which fields, if any, participate in
forming a key. Once a key is defined, it is used to further define the primary
key and the mutable key (both are discussed next).
2.a.1: The definition of a key used to determine if there is a duplicate key
exception. Granted URLyBird has no duplicate keys, but the raw database itself
does support them and they are defined through the appropriate method calls.
2.a.2: The definition of a key used to determine which fields of the record
are or are not mutable (modifiable). For the URLyBird client application,
the database is set up so that the update() method can only mutate the last
field (holding the client ID). But the raw database can be set up so that any
number of fields can be made mutable or immutable.
2.b: A creation policy: i.e., whether new records are allowed to be rewritten
over deleted records. I assume you did not have this since you did not write
the delete() and create() methods.
2.c: An update policy: i.e., whether "blind" updates are allowed.
2.d: A lock policy: i.e., can the client lock more than one record or not.
Thanks,
Javini Javono
[ May 02, 2004: Message edited by: Javini Javono ]
Min Huang
Ranch Hand

Joined: Mar 17, 2004
Posts: 100
Not sure why you received the 44/80 locking score; this has been speculated on
before, but no one knows. Perhaps it only takes one, small subtle error to lose
quite a lot of points (would be my speculation).

Yes, I am also unsure about this. Maybe they toss a die and decide whether to give you 0/80, 44/80, or 80/80.
I did collection locking and tested it thoroughly too. However, I did not account for clients that crash or take any steps to prevent deadlock (which would occur if clients can claim multiple locks - which I allowed). I noted all of these choices in choices.txt. However, I've noticed people who have done the same and gotten perfect locking scores.

Your "Data store" score was at the maximum. If you could, here are some
questions I have (although I've already done the design and development, so at
this point, it is mainly curiousity):
1. Does your database function in "stand alone" mode. That is, can the Sun
examiner write their own code to use your database and test your database?

Yes. I went with a 2-tier approach. Maybe that's why I lost points on OO Design?

2. Does your database have different rules that are dynamically set at run-time
either through a preferences file or through the client application hard-coding
them. Here are some rules my database has:
2.a: The definition of a key which defines which fields, if any, participate in
forming a key. Once a key is defined, it is used to further define the primary
key and the mutable key (both are discussed next).

No, my "primary key" is defined as the record number (which is 0, 1, 2, 3, ... and determined by the record offset).

2.a.1: The definition of a key used to determine if there is a duplicate key
exception. Granted URLyBird has no duplicate keys, but the raw database itself
does support them and they are defined through the appropriate method calls.

I defined DKE to be thrown if adding a record would cause integer overflow (because a recNo must be an int, and so only a finite number of recNo's can exist).
Note: while I did not implement create/delete, I noted the exact behavior of create/delete in the comments and choices.txt so future programmers could implement it and see how it works with the locking scheme and the rest of the database functions.

2.a.2: The definition of a key used to determine which fields of the record
are or are not mutable (modifiable). For the URLyBird client application,
the database is set up so that the update() method can only mutate the last
field (holding the client ID). But the raw database can be set up so that any
number of fields can be made mutable or immutable.

I didn't do that. My client has access to the entire data class.

2.b: A creation policy: i.e., whether new records are allowed to be rewritten
over deleted records. I assume you did not have this since you did not write
the delete() and create() methods.

Yes. I allowed this. create searches for the first deleted record. If it does not find one, it will append to the file.
(see above for my note on implementing create/delete)

2.c: An update policy: i.e., whether "blind" updates are allowed.

What is a blind update? You mean updating without reading the record first to see if it has changed since you last read it? I allow this. I noted that if you want this to be avoided, then read it first, then update.

2.d: A lock policy: i.e., can the client lock more than one record or not.

I did not do this. A client can lock as many records as he wants.
Javini Javono
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
Hi,

What is a blind update? You mean updating without reading the record first to see if it has changed since you last read it? I allow this. I noted that if you want this to be avoided, then read it first, then update.

Yes, that is what I meant.
Thanks very much for your responses,
Javini Javono
Cleverson Schmidt
Ranch Hand

Joined: Feb 17, 2004
Posts: 55
Hi Min
Thanks for sharing your experience.
I would like to know if you leave your delete/create methods without any implementation at all or do you throw a UnsupportedOperationException? And did you mention this in the JavaDocs from these methods?
Thank you
Cleverson
Vishwa Kumba
Ranch Hand

Joined: Aug 27, 2003
Posts: 1064
Min,
Congratulations!.....I guess you happened to be lucky not to loose any points for the empty create/delete() methods. If SUN expects everybody to be smart enough to submit empty method implementations, then it does not make much sense to include them in the DB/DBMain interface. Does it? I think SUN wants us to implement them and the instructions document somehow
missed to mention it or possibly meant it implicitly,(must implement the interface meaning NO dummy methods).

Certainly I do not want to risk it...But still it would be interesting to find out how you didn't loose any points for this?
Min Huang
Ranch Hand

Joined: Mar 17, 2004
Posts: 100
Thanks for sharing your experience.
I would like to know if you leave your delete/create methods without any implementation at all or do you throw a UnsupportedOperationException? And did you mention this in the JavaDocs from these methods?

I didn't know there was such an exception. I looked through the Java 2 API and found NoSuchMethodError, and I decided that was close enough. I didn't lose many points in General Considerations or anything, so I guess its ok to do that. Maybe it would have been smarter to throw USOE.
I did document that create/delete had no implementations in my choices.txt and in my Javadocs. Actually I clearly mentioned that there was no implementation several times in my documentation, noting that as a future enhancement, those 2 methods could be implemented.
To Vishwa: So in that case, I think that my empty implementations did not go unnoticed by the grader unless he decided to give but a cursory glance at my documentation. Granted, my choices.txt was a huge horking monster of a text file, but that's a different story
I also mentioned that nowhere in the spec is there a must requirement (or even a "should" requirement) to provide create/delete functionality, so I did not provide it (as extra work gives no extra credit). I listed that as a basic assumption in choices.txt. Maybe if you do not implement create/delete and do not mention anywhere that you did not implement it, the grader will not be so forgiving.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: It IS possible to pass without implementing create/delete!