Guideline for SCJD2 Exam
Dallas SCJD Study Group

by our honor member, Sun cerified Java developer
Shashank Tanksali

Introduction

The Sun Certified Java developer examination is a practical exam rather than an objective exam.Given below are some of the dos and dont's of SCJD.

• Who should take up SCJD
• What will I get with SCJD
• Approach to SCJD
• SCJD Checklist

Return to top

Who should take up SCJD

Technically speaking, only those who have completed their SCJP can take SCJD. Anybody who wants to go beyond mere programming skills and learn all aspec ts of a complete development process can take up SCJD. SCJD is equally useful for both an experienced software professional, who wants to keep his knowledge level current. It is also useful for software professionals, who have non java related work experience, but would like to switch to Java. It is also extremely useful for people with no prior software development experience, as it gives them an opportunity to demonstrate their skills to prospective employers. For people, who want to experience the full software development process and who especially like performance based exams, SCJD is ideal.

Return to top

What will I get with SCJD

SCJD is a third party validation of your development skills, and who better than the originators of Java can validate your skills. Since SCJD is a complete project assignment and not just a knowledge based examination, the process matters more than the end result. With SCJD, a person refines his analytical skills, decision making skills and of course programming skills.Also since there is no time limit, anybody can take up SCJD to suit their own work schedules. Overall once you have completed SCJD, you will find yourself a better developer, who can use Java in conjunction with all the other skills required to develop great software.

Return to top

Approach to SCJD

The objective of the SCJD exam is not to get the assignment working, but rather to enjoy the experience of learning new technologies, analyzing requirements,making suitable assumptions, designing a system,learning design patterns and in general developing an entire application alone. The good thing about the SCJD exam is that it is full of ambiguities, incomplete specifications etc, which force you to think and decide what needs to be done.It is this experience, which will be rewarding in the long run.

Many people cannot resist the temptation to start coding and directly jump to coding. Coding should be considered only after the entire design has been finalized, and it should be a mechanical process to translate a good design to Java code.

Return to top

SCJD Checklist

This is not an exhaustive checklist, but it should give some information about what needs to be completed before the project submission.

• Are all the assumptions made in the project clearly documented ?
  The examiner should not have to guess what assumptions you made. If you made an assumption, it should be clearly documented in the submitted document. It might be even better to have an assumptions section in the document, so that the examiner clearly knows what you had in mind, when you designed the system. The best way to keep track of assumptions made is to put them in a document, as and when the assumptions are made. Documentation is not something done at the end, rather it should be done in parallel with development.

• Is a suitable package structure used for the project assignment ?
  Java classes which logically belong together should go into a separate package.

• Is finally used in all the appropriate places ?
  For example, if a client acquires a lock and then due to some reason, there is an exception, the client should release the lock before returning, immaterial of whether there was an exception or not.

• Are the Javadoc comments written on the same lines as the api documentation ?

• What is the exception handling mechanism used ?
  Do exceptions cascade all the way to the top or are they handled where they can potentially occur ? An end user should not be forced to handle an internal exception, if it is of no interest to him.

• Is the atomicity in the application guaranteed ?
  Atomicity in short is either everything or nothing. So if a booking is taking place for a flight and a record is locked, either the booking should go through or if the number of seats etc are not available, the entire transaction should be rolled back. The database should not be left in an inconsistent state even if the application crashes.

• Is the user documentation clear enough to allow anybody to use the system ?
  The preferred way to package applications is by using executable jar files. With executable jar files, the classpath etc need not be set. Executable jar files are a new feature in Java 2, and it makes sense to use it.

• Documenting design decisions
  Are all the design decisions clearly documented. When a design decision is documented, the alternatives considered, their relative merits and demerits need to be also documented. Basically the examiner is interested in knowing why you chose a particular approach over another.Design decisions should be briefly and clearly explained and should not run into several pages.

• Use of standard design patterns
  Whereever possible, use design patterns. Design patterns are tried and tested ways of accomplishing a particular task. Using design patterns tells the examiner that you have done your homework.

• Error handling
  Do not expect sensible data to be provided to your application always. How does the data converter behave if the data supplied to it does not match the schema supplied ? What happens if a negative number or a non numberic value is entered for the number of seats ? For example if the 20th row in the input data file for the data converter is wrong,the data converter should either skip the row, log an error and continue, or it should give an option to the user to choose an action (either abort entire conversion or skip bad record). The data converter should not load 19 records, throw an exception and exit.
  Also document clearly, the expected outcome in case of an error. For example, you might document that the data converter ignores bad data.

• Code clarity
  The best comment you can write is readable code. With readable code, there is no need to write comments.

• Is the indentation uniform all over the code and according to the java standards ?
  There is nothing more annoying than seeing several files all using a separate coding style. Read the java coding standards (as it will be enormously helpful in the professional career as well) and ensure indentation across all the java classes is consistent.

• Testing the application
  Testing an application should start when individual classes are developed. It is better to prepare an entire suite of test programs (not to be included in the submission) to test the application. Sometimes, it might be useful to ask a friend etc to use the system to uncover any possible faults in the system. For example, when asked my friend entered the number of seats as 5 followed by a space. I was not doing a trim on the entered value, which caused an exception to be thrown. Asking others to use the system without an prior knowledge can uncover bugs, which we might not have thought of.

• Use intuitive field names
  Except for loop indexes etc, intuitive field names should almost always be used. originFlight gives a lot more meaning than origFlt for example.

• Ask yourself why this approach ? What are the alternatives ?
  For every single design decision that you make in the assignment, ask yourself what are the alternatives ? What are the advantages of the chosen approach over the other approaches ? For example, why sub classing, why RMI, why singleton etc

• Make interfaces where appropriate
  Wherever possible, consider using interfaces instead of classes. For example, consider if having a DBInterface and a class which implements it is better, as dealing with interfaces will allow you to change the implementing class at any time. Similarly do not directly refer to a Hashtable, instead refer to a Map with Map m = new Hashtable() ; This allows you to switch from a Hashtable to a HashMap at any time, without affecting anything else.

• If using Object serialization, clearly document the serializable fields

• Wherever possible, implement Runnable instead of extending Thread.
  This allows you to keep the one chance that you have to extend any class sometime later.

• Sensible server output log
  Ensure that the output of the server is sensible and does not include any output of no concern to a server administrator, for example debug statements etc should not be part of the server output. However critical errors etc, should always be logged.

• Write consistent code
  It should be obvious from the code, that it is written by a single individual. Do not for example, use
  import java.util.* ; in a java file and import java.util.Vector; in another file. It is recommended that any classes used are explicitly imported, so that by looking at the top of any java file, it is obvious, what classes are used in that file. Also group together all public members first, protected members next, package members next and finally private members in all the java files.

• If there is any cleanup to be done in any class, is finalize being used ?

• Are all the server classes threadsafe ?
  Write a multi threaded program to simulate several users and connect to the database server with it to test if the server is threadsafe.

• Test separately in local mode and network mode.

• Look for the non obvious
  For example in the FBN assignment, deleted records are just marked for deletion and are not actually removed from the underlying database. What will happen if an attempt is made to insert a record with a key belonging to a record marked for deletion.

• If any method like getRecord() returns null, is it being appropriately handled ?

• Consider using meaningful names for boolean variables.
  For example, if you have a boolean record status attribute in a lock class, a value of LOCKED and UNLOCKED is more descriptive rather than true or false. These variables can be defined as static final constants in an interface or the class itself.

• Ensure the method signatures are the most restrictive.
  Changing a method signature from most restrictive to less restrictive can be done at any time without breaking any existing code, but the other way cannot be done easily. Once a public interface is exposed, making it more restrictive may break some existing code. Never use public data members unless absolutely necessary, instead use accessors.

Return to top

It is good to be a walking Java compiler. It is better to be a Java developer.

---

[join us]

[home]

[javachina]

Last updated 03-25-2002 by webmaster
Copyright © 1999 - 2002 Shashank Tanksali, All Rights Reserved

---

Hosted by www.Geocities.ws