What to do if you have a question
You might find that you want to ask for
further explanation of some part of this
document, perhaps to seek permission to solve a problem in a particular way.
this document deliverately leaves some issues unspecified, and some problems
unraised. Your ability to think through these issues, in the face of realistically
imperfect specifications, and come to a tenable solution is something upon which
you are being graded.
In general, you should not ask your question; rather you should consider
the options available and make a decision about how to address the problem
yourself. This decision-making process is part of the marking scheme, and as
such it is crucially important that you provide documentation of your choice.
Be sure to describe the options you considered, the perceived benefits and
weaknesses of each, and why you chose the solution you did. Provided you do
not contravene any specification in this document you will not be marked on
the particular choice that you made, but rather on the consistency of your
decision making process and your adherence to other aspects of these notes
during that decision making process.
If you feel you must ask your question, you should address it to
emailAddress@sun.com. Clearly indicate that the question relates to
the Sun Certified Developer Exam, provide your candidate ID number, name,
and include your return e-mail address in the body of your message.
Describe your issue as briefly as reasonably possible;
you will be asked for more information if necessary.
I think I'd like to ask Sun if a trivial implementation of the lock(),
unlock(), and isLocked() methods will result in automatic failure.
Afterall, if having us exercise our skill by implementing this feature
is an automatic requirement, I would think that Sun would know
the answer to this.
Here is a rough draft of my question; you all might have other
points which I should supply in order to ensure an unambiguous
response from Sun.
Concerning the Java developer's project:
Your specification is troublesome in some respects
because it simultaneously uses "must" conditions in
ambiguous statements. I would recommend that you
split the project specifications into two sections:
1) Sun speaking must conditions unambiguously (since
Sun is implicitly a client I have to satisfy),
2) The "customer" speaking must conditions ambiguously
where it is our job to find the best solution.
But, besides offering the above suggestion to make your
future exams clearer, here is my specific problem.
I am able to provide file database consistency without
using the lock(), unlock(), and isLocked() methods of
the Data class. I am prepared to argue that as part
of my solution that to implement the Data class and
to make it widely available to the corporation as a
contractual Java interface is irresponsible, if for no
other reason than the methods do not throw and handle
exceptions in a responsible manner.
However, some people may consider it a "must" condition
that lock(), unlock(), and isLocked() be implemented
non-trivially. What is your opinion? That is, is it a mandatory
requirement that everyone must without exception and regardless
of any other consideration non-trivially implement lock(),
unlock(), and isLocked()?
Or, can one present arguments, as I am inclined to do,
wherein I assert that my design automatically handles
locking, and the methods lock(), unlock(), and isLocked()
are not needed and will be deprecated.
In short, nomatter what reasoning I give, will I be
automatically failed if I trivially implement lock(), unlock(),
and isLocked(), if I label these methods as deprecated,
and if I issue severe warnings that these methods should
never, ever be called by client programmers?
Which of these statements is closer to the truth:
1. You must fully implement the lock, unlock, and isLocked methods as required by the specification, and you must do so in the Data class.
2. The lock, unlock, and isLocked methods must be fully implemented as required by the specification, but this may occur outside of the Data class.
In this way you might have some hope of getting back a response. It's clear from the instructions that Sun doesn't think it's necessary for candidates to have any interaction with them, but if you phrase the question consisely and make it very easy for them to respond you might get a single digit reply. I've employed this tactic in the past when dealing with difficult customers.