uCertify PrepKit for SCJP 5.0

Recently, I got an exciting opportunity to review the uCertify Prepkit for SCJP 5.0 certification.

SCJP stands for Sun Certified Java Professional and is one of the many certifications offered by Sun Microsystems that makes you stand out in the crowd. In the times like these, who would not want that. :-)

If you want to know more about SCJP, you can look at the Sun's site here or you check this to see some related FAQ's.

Coming back to uCertify Preparation Kit, I actually found it pretty useful overall, for it gives you a broad spectrum of features for a relatively smaller price. The preparation engine provides you with

• Study Notes & Helpful Articles
• 7 Mock Tests, each with 75 questions
• Study & Learn Module
• Ability to Bookmark and Tag Questions

The Study & Learn Module provides a presentation (thus not really boring) based on each Examination Objective of SCJP 5.0. Going through them before the exam could be the fastest way to revise the entire syllabus. This is so because SCJP has well-defined objectives (rules & syntax of the language) that it tests. There is no need to go beyond these objectives if you want to clear the exam.

You can also attach your own notes with Study Notes and Articles, thus making a note of some exceptional condition or some related fact. These makes life really easy when you go through them again.

The practice exams give you a real feel of the actual certification exam as it contains both multiple choice questions (MCQ's) and few drag-and-drop questions. Also the level of the questions are neither too high nor too low. On a personal level, when I took the first practice exam without really preparing for it, I faltered on questions related to in-built classes like Locale, Date, NumberFormat and use of native modifier and Enumerations.

According to me, the best feature is certainly the way the answers are explained once your test is over and you see the results. You can review all the answers whether correct or not, and find out the reason for the same.

The answers are explained in length, touching the concept involved and focussing on why other options are wrong. This gives you a proper insight of what's going on.

On the downside, I would have preferred a highlighting feature that enables me to highlight important facts in the study notes and articles, so that next time I read only that part, which is important to me. Also, I would have loved had they allowed me to copy the code and paste it to test it but I understand that they probably can't do it for piracy issues and misuse.

Conclusion

Although it is an excellent kit to give you a proper feel of the actual exam; it is equipped with some easy ones and some tough(read tricky) questions as well just as the actual paper would. But, do not think that you need just this PrepKit to clear the paper!!

What you also need is a javac(Java compiler) to practice and code. I strongly recommend understanding the involved concepts and coding by hand (not by IDE), then take these useful tests to gain confidence as the actual exam looks almost the same.

For more information about the other preparation kits that uCertify provides you, please visit there site here.

ByteCode Back to Java Source Code !!

I have always thought about the title of this blog entry, ever since I started learning Java. But, until recently, I had no idea about the same. I didn't knew that something magical existed that would perform this conversion. But now since I know a bit, I thought I better share it.

Java Decompiler

As you would have guessed by now, a Java Decompiler is a computer program capable of reversing the work done by a Compiler. In essence, it can convert back the Bytecode (the .class file) into the source code (the .java file).

There are many decompilers that exist today, but we will talk about the most widely used JD - Java Decompiler, which is available both as a stand-alone GUI program and as an Eclipse-plugin.

To install and use these tools are a breeze and would not take you more than a few minutes to get accustomed to it. Hence, I would not repeat the process that's already mentioned on their site.

One thing that we must note here is that the process of conversion might NOT result into 100% exact code, i.e. the generated Java file might not match the actual Java code character by character. However, most of the code would be replicated but things like variable & function names or some other minor details may differ.

Lets have a look at the JD-GUI, stand-alone tool, written in C++;making it pretty fast to execute(decompile) and display the result. Also, it is independent of the the Java Runtime Environment and thus no setup is required to install it.

Lets test the tool now.

Example Java Code:

public class test{

public static void main(String[] args){

System.out.println("Hello world");

}

}

Compile it: javac test.java

so that we have ByteCode (test.class file) with us now.

Decompile it using any one of the following ways:

1. Execute the following on the command line: jdi-gui.exe test.class
2. Select 'Open File' from the menu, browse to get to the test.class file and open it
3. Drag and Drop the test.class file into the JD-GUI tool

All of the above situations result in generating the following Java Code, have a look:

import java.io.PrintStream;

public class test

{

public static void main(String[] paramArrayOfString)

{

System.out.println("Hello world");

}

}

Well just by seeing JD perform really well on this simple example, we cannot decide how efficient is this tool. But, still it is a tool that every Java Developer must be aware of. Because, in case you have accidently deleted your Java files and are left with only the .class files, this is the tool that can save your neck. :-)

Strings & Java

Perhaps one of the most frequently used Class in Java is the String class. The major reason for Strings to be really poweful is the flexibility of Strings to interact with other objects with so much ease.

Strings in Java posses many unique characteristics that differentiates it from the rest. For example, it is a well-known fact that Strings are Immutable. For those who do not know what that means is, 'String objects one created, can never be changed.' An example would make it more clear.

String s1 = "Hello World";

Here, s1 holds the reference to the String object on the heap containing the value "Hello World". Now, if we type

String s2 = s1.concat(", here I come");

Now, s2 holds another object on the heap with the value "Hello World, here I come". But this doesn't change the object s1. What it rather does, it creates a new object concatenating the new value to it and storing its reference in s2.

If we would have typed,

s1.concat(", here I come");

then also a new object with value "Hello World, here I come" is created but is lost and cannot be referenced since we have not stored it somewhere. Here also, s1 remains the same and is not changed. It cannot be changed.

It would also be good to remember that to make Java Memory Model more efficient,  Java Runtime allocates memory for Strings from "String constant pool" rather than allocating the memory from the heap. 

Now, when the compiler encounters any string literal, it first searches the String constant pool for an identical string. 

• If a match is found, the reference to the already existing identical string is returned for the new request. 
• If a match is not found, then a new string literal is created in the pool of strings. This approach works without failure since Strings are immutable in nature.
  

An example can again smooth things out here:

String s1 = "Agraj";

String s2 = "Agraj";

System.out.println(s1 == s2);              // prints true !!

System.out.println(s1.equals(s2));     // prints true as expected

String s1 = "Agraj";

String s2 = new String("Agraj");

System.out.println(s1 == s2);              // prints false because of 'new'

System.out.println(s1.equals(s2));     // prints true as expected

The first example prints according to String constant pool approach. While, the second example allocates memory again to s2 because the new operator is used, which forces the compiler to allocate memory again.

It would not hurt to remember that the '==' operator is used to compare references while the 'equals' function actually compares the string value(character by character) stored inside the objects.

On some pondering, one might think that if identical strings are not allocated same memory, then if one might change one reference to the string, then all other references would also reflect the change. For example,

String s1 = "Agraj";

String s2 = "Agraj";

s1 = s1.toUpperCase();       // s1 = "AGRAJ" but s2="Agraj"

One might expect s2 also to be equal to "AGRAJ", which is not desired. But, since Strings are immutable in nature, so the toUpperCase() function creates a new string, rather than modifying the original string (it cannot modify the original string, nothing can) and assigns it to s1 while s2 still reference to the original string "Agraj".

StringBuffer and StringBuilder 

A person can argue that in a module that does heavy String manipulation, there would be excess of new Strings that would be created now and then and would not be used at the end, leading to wastage of memory. And you see, this person is not entirely wrong. Strings if used in a careless manner can cause huge performance bottleneck. 

So mostly, when we have to do String manipulation a lot in our application, it is advisable to use classes such as StringBuffer & StringBuilder. Both of these provide the same API and behave in the same manner as Strings do, the difference being the fact that they are mutable. Thus, you can change a StringBuffer / StringBuilder object once created. 

Example:

StringBuilder str1 = new StringBuilder("Hello");

str1.append(" World");

would change the existing object "Hello" and will not create a new object as normal String Object would have done. 

Difference b/w StringBuilder & StringBuffer

Both of them provide us with the same API and thus are similar except the fact that StringBuffer is thread-safe while StringBuilder is not. 

Thus it is always advisable to use StringBuilder class, where-ever thread-safety is not a issue (which is commonly the case always). It is advisable to use StringBuilder than StringBuffer because StringBuilder is much more faster than its thread-safe twin. This is so because it ignores the complications that comes along while deailing with stuff like synchronization and threads. 

There is much more to Strings usage in Java than what can be covered in a blog entry, but I guess I have covered some of the important points which are normally ignored by novices like me. 

Ergonomics - Garbage Collection in Java

What is Ergonomics ?

With J2SE 5.0 onwards, Ergonomics is defined as the capability of the JVM to

• Automatically select Heap Size, Garbage collector & type of Virtual Machine (server or client) based on the platform on which your application is running.
• Allowing us to Tune the behaviour of the Garbage Collector using various command line options to achieve the desired effect. 

But, the aim of Ergonomics is to improve performance & minimize command line tuning as it believes in selecting the optimum configuration for the application which is running. The values are chosen based on the type of machine and the operating system (the platform) on which the application is running.

Machines are divided into 2 categories:

• Server class machines
• Non-server class machines

According to J2SE 5.0, a server class machine is the one which has

1. At least 2 CPU's (processors)
2. At least 2 GB of physical memory

All other machines with less no of processors and memory are treated as non-server class machines. As visible from the configuration, the server class machines are mostly used to run large applications (typically web applications using some server framework) 

Automatic Selections

For a server class machine, the default values chosen are

Type of JVM : Server JVM

Type of Garbage Collector  : Parallel Garbage Collector

Heap Size :

1/64th of Physical Mem Avail  <=  Min Heap Size  <= 1 GB

1/4th of Physical Mem Avail    <=  Max Heap Size <= 1 GB

For a non-server class machine, the default values chosen are

Type of JVM    : Client JVM

Type of Garbage Collector     : Serial Collector

Heap Size :

Min Heap Size :    4 MB

Max Heap Size : 64 MB

To explicitly make JVM treat your machine as server machine, one can do it using any of the 2 ways:

1. Use the -server command line option with java command

2. Change the first two lines of jvm.cfg file in your JRE_installation_directory/lib/

Change 

-client KNOWN

-server KNOWN

to

-server KNOWN

-client KNOWN

A server JVM differs from client JVM in the sense that it might take more time (approx. 10% more time) in start-up, but eventually it increases the performance & the throughput of the application in the long run. 

While client JVM is sufficient for normal standalone applications, server JVM is best suited for large-scale applications like web applications using a server framework running on some application server.

Behavioral Tuning

If you really know that these automatic settings are not suitable for your application, then JVM gives you the flexibility of changing them as well.

Changing the type of VM

Use -client for using Client VM

Use -server for using Server VM

Changing the type of Garbage Collector

Use

-XX:UseSerialGC Serial Collector

-XX:UseParallelGC Parallel Collector

-XX:UseParallelOldGC Parallel Compacting Collector

-XX:UseConcMarkSweepGC CMS Collector

Changing the Heap Size

Use -Xms to set Minimum heap size. Ex: -Xms512 will set 512MB to be minimum heap size

Use -Xmx to set Maximum heap size. Ex: -Xmx724 will set 724MB to be maximum heap size.

Setting maximum & minimum heap size to be same takes away the flexibility away from JVM of changing the heap size according to the requirements as they arise.

Certain Goals

With these command line options, you can set certain goals for the Garbage Collector to achieve and their relative priorities. The Garbage Collector works to achieve these goals and can change the heap size and other related parameters

Maximum Pause Time Goal

This goal can be used to set Maximum pause time that a Garbage Collector is allowed i.e. we can specify -XX:MaxGCPauseMillis=n meaning that Garbage Collector is allowed a maximum pause time of n milliseconds for each generation. And if it is not able to limit itself to n milliseconds then it must take some measures to achieve this goal. For example, it can reduce the size of the heap in order to reduce the maximum pause time.

Throughput Goal

It can be used to specify the time spend in doing Garbage Collection using -XX:GCTimeRatio=n 

The ratio of garbage collection time to application time is 1/(1+n)

So, that means if we set -XX:GCTimeRatio=19, it means that a maximum of 5% of total time can be spend in Garbage Collection.

Default value is n=99 which means that 1% of  total time is allowed for garbage collection

If this goal is not met, then the size of heap is increased so that it takes more time to fill the heap and thus garbage collection occurs less frequently.

Footprint Goal

This is an interesting one. It specifies that if Maximum Pause time goal and Throughput goal have been met, then keep on decreasing the size of the heap until one of the above mentioned Goals cannot be met. Then try to meet that goal. :-)

Goal Priorities

This goal specifies that priority of above mentioned goals. The order of importance is 

1. Max Pause Time goal

2. Throughout goal

3. Footprint goal

Tools to evaluate GC performace

In an ideal condition, you need not worry about Garbage Collection. This is precisely the goal of Ergonomics; selecting the best possible configuration according to the machine on which the application is running. But if your application runs into memory troubles like memory leaks and OutOfMemoryError, then there exists a plethora of tools to choose from.

Writing about each of them is out of scope of this document. So, I'm just giving out the names and the required links that would help you analyze the application and take proper steps

Some Tools To Look Out for

jConsole (Monitor you App)

HPROF (A Heap/CPU Profiling Tool)

jHat (Java Heap Analysis Tool)

VisualVM (Latest Tool and a Very Good One)

jStack (Stack Trace)

jinfo (Configuration Info)

Disclaimer: The contents of this blog and of all others are totally my personal opinion about the stuff, I have written and has nothing to do with my employer :-)

Getting started with Ant

Each one of us has used Ant knowingly or unknowingly, while building our projects. But, most of us are not aware of its existence. Thanks to IDEs like Eclipse & NetBeans !!

But, I feel that one must know how things happen. How a series of commands are executed when you build your project and how you can control and alter this flow.

This entry is not meant to give you insight into the build process but it is meant to introduce the tool (Ant) to beginners like me. We will go through installation and normal usage of Ant Tool.

So, lets get started :-)

What is ANT ?

Ant is a Java-based build tool used for automating the build process.

Ant is written in Java and that's what makes it platform-independent. This also means that you lose out on doing certain things (issuing certain OS-specific commands in build.xml) that could be done fastly in a OS-dependent manner.

ANT is an acronym for "Another Neat Tool". :-)

It accepts input in form of XML files (like build.xml) and can be used to perform repeatitive task in an efficient manner.

Installing ANT

Download the binary distribution from here.

Now, all you have to do to install ant and run from command line is to set following environment variables:

• ANT_HOME : Set this variable to the path where you have unzipped the downloaded binary distribution
• PATH : Append the ANT_HOME/bin to the already existing PATH value. This is needed so that we can run ant from command line.
• JAVA_HOME : Set this variable(if not already set) to the path where JDK is installed
  

And Bingo !! you are done with installation. It's time to test whether we have installed Ant correctly or not

Test Your Installation

To test whether you have successfully installed Ant or not, type

>ant

on command line and press enter

It will give an error like

Buildfile: build.xml doesn't exist!

Build failed

because right now there is no build.xml file existing in the current directory. Ant tool makes use of build.xml to automate the build process.

Congratulations !!

You have successfully installed ANT if you can see this error message. :-)

What is build.xml ?

It is nothing but a normal XML file that is used to automate the build process. It contains certain commands that are executed in a defined/prescribed manner. You can think of it as writing a Shell Script which will be executed by Ant tool. Actually it's more like a make-file that we have in Linux/Unix environment.

A normal build.xml file would consist of following sections, in that order:

1. Clean - It removes all the previously deployed files of the same application, if any.
2. Init - Creating the directories and subdirectories according to your choice
3. Compile - Used to compile the *.java files & servlets or jsp's with the help of libraries
4. Copy - It copies the compiled class files and servlets in their appropriate locations
5. Create-war - Finally, we create a .war file of our application and copy it to your server's deplyoment directory so that you can run the application.

All these steps are not neccessary and it depends entirely on you that what you wanna keep in your build.xml.

A look at a simple build.xml would simply what seems so tough right now. :-)

BUILD.XML

Lets see what it really means:

1. Root Element

First line tells us that it is a XML file.

Then comes the root element, project. Rest of the code for this project will come in between project tags. It has 3 attributes:

1. name (optional) - Name of the project
2. default (required) - The default target to use when no target is specified
3. basedir (optional) - This tells the basedir for all the paths mentioned in the in this script. If it is missing, then parent directory of this build script will be used as basedir

2. User-defined variables

These 2 lines declare user-defined variables which are used later in the file.

src holds the location of the current directory as given by '.'

build holds the location "basedir/build" where basedir was defined in project name above.

Remember all the paths mentioned are relative to basedir

So, property tag is used to give name-value pairs, but same effect could have been achieved by mentioning these name-value pairs in an external file (named build.properties) and using them in build.xml as they are used now.

3. Clean your earlier deployment

Target tag is like a function which you can call again to perform a reusable task.

These lines are pretty simple to understand.

The echo tag will echo/display whats written to the output console, and the delete command will delete the build directory

${build} is way to evaluate the build variable that we have defined above using property tag

4. Initialization - Creating Directory Structure for deployment

Here, we just create a directory using mkdir command.

The thing to note here is the depends attribute of target tag. This attribute is used throughout build.xml to create a chain of targets, to give a sequential flow i.e. it helps in specifying the dependencies of one module over another and tells us how the targets will be called.

5. Compiling source files and copying them to destination folder

This function compiles the source files present in src directory and stores the resulting .class files in build directory.

I have deliberately not added more steps like creating a war file and deploying it on server, because that would make this entry long and complicated un-neccessarily. Time to run what we have done so far.

Running this script

To run this script, create a folder and name it Test and copy this build.xml file in it. And to test whether your script works or not, create any correct java file in this Test folder, which we will compile.

Your directory structure should look like this.

Test

|

|------ build.xml

|

|-------HelloWorld.java

To run your build script, go to Test Folder, and type ant

C:\Users\Agraj\Desktop\Test>ant

If everything goes correct, it will give output

Buildfile: build.xml

clean:

[echo] Deleting build

[delete] Deleting directory C:\Users\Agraj\Desktop\Test\build

init:

[echo] Creating new directory: build

[mkdir] Created dir: C:\Users\Agraj\Desktop\Test\build

compile:

[echo] Compiling source files present in . to build

[javac] Compiling 1 source file to C:\Users\Agraj\Desktop\Test\build

BUILD SUCCESSFUL

Total time: 2 seconds

For starters, it doesn't and shouldn't work right away :-)

I said shouldn't because if it does, then perhaps you won't enjoy and learn more about Ant.

Having said that, the problem that occurs most commonly is that Ant tool is unable to parse the build.xml file correctly. This is so because even a space or tab inserted in xml file can cause Ant to fail. You can get to know about the extra spaces/tabs using vi editor on linux/unix machines, but it can be pretty frustating on windows to look out for such an error

Although, most of us will never change the build.xml while development but still it helps a lot when you know what happens when you build your project and you don't feel alien to the environment :-)

Random Notes :

• Make sure that your CLASSPATH variable doesn't have any single quotes or double quotes ( ' or " ) in it even if there is a space in the path because, the presence of them will make ANT to fail.
• Also make sure that there is no ending forward or backward slash ( / or \ ) in your CLASSPATH
• For more on Ant, please refer to FAQ section here
  
• For detailed installation from source or for setting optional parameters/preferences, one can go to the docs/manual/index.html page of the installation directory

Any comments, suggestions and corrections are welcome and required !!

Checked Vs Unchecked Exceptions

In Java, there are 2 kinds of Exception:

Unchecked Exceptions which indicate some sort of programming error on the part of developer. Unchecked Exceptions are usually subclasses of RuntimeException class. Examples include: 

 --- NullPointerException (which is usually thrown when method is              invoked on a null object)

 --- DivideByZeroException (thrown when divide by zero happens in        your code)

 --- IllegalArgumentException (usually thrown when invalid argument        is passed to a method)

 --- ArrayIndexOutOfBoundsException (thrown when you try to access         array index beyond the memory allocated to it)

 --- ArithmeticException

 --- RuntimeException

If your methods throw an unchecked exception, then your method need not specify it as a part of its API i.e no need to write all the exceptions it throws using "throws" clause.

Checked Exceptions on the other hand, specifies conditions that are not due to human errors but due to conditions that are not in programmer's control. These include conditions such as database errors, network failures, file not found when searching or performing some operation on it. Examples include:

 --- FileNotFoundException

 --- SQLException

 --- PersistenceException

On the other hand, if your code throws any checked conditions, then either you must handle it or specify it using "throws" clause else your program will give compile-time error. 

Checked Vs Unchecked

Use Checked Exception in your code when you Client code (code that calls your code) is capable of dealing with the Exception and have ample knowledge why that Exception occurred in the first place and how to do away with it. 

Otherwise, it is always preferable to use Unchecked Exceptions since then the Client code is not forced to handle it and can choose to ignore it. Though that would not solve the problem and the exception would travel high up in hierarchy of function calls and perhaps finally encountered by the JVM, but at least the Client code is saved from the hassle of dealing with Exceptions that they don't know about it.

Let's take an example. Suppose we have a method throwing an SQLException:

The client code would never come to know that why this SQLException occurred, as it has no knowledge of underlying business logic and internal database design. Thus client is unable to handle the exception, so its always better to not force a client to handle an exception he do not know about.

Articles Worth Reading:

• Unchecked Exceptions - The Controversy
  
• Best Practices for Exception Handling
  
• Does Java Need Checked Exceptions?

Happy New Year 2009 !!

Wishing all the readers a very happy and prosperous new year ahead. :-)

Small Update About Me

I would soon be starting off with my training at ST Microelectronics, so I don't know how much time I would be able to devote to this passion of mine. But, I surely hope that this habit of mine doesn't die out so soon and I get enough opportunities to share my thoughts.