Reflection in Java is done by using using the java.lang.Class class. This class provides access to all the information within your own applications classes or even the regular java library classes. Let’s say you have a class in a package called com.tt.company.Employee then if you need the metadata of the Employee class you would have to first assign it to the Class as :

Class c = Class.forName(“com.tt.company.Employee”);

Accessing Fields, Methods and Constructors with Reflection

If you are not sure which fields and methods are declared in a class and you don’t have access to the source code then you can easily get this information by simple looping.

For example, if I wanted to access the fields and methods declared in the class Employee then its as simple as the below code.

Field[] fields = c.getFields();
 
Method[] methods = c.getMethods();
for (Field f : fields)
 
System.out.println("Field: " + f.getName());
 
for (Method m : methods)
 
System.out.println("Method:" + m.getName());

You might get some additional methods if you use the getMethods() method. This is because, the getMethods() definition also chooses those methods which are present in any of the super classes present. In this case, if Employee class does not have any super class, but still it is a subclass of Object. Hence methods defined in the Object class would also form a part of the output.

In order to avoid the methods defined in the super class you should use the getDeclaredMethods() instead.

Note: An important point worth mentioning over here is that, the loop would produce only those methods or fields which are marked public. If you don’t have a public field or method it won’t be considered. In order to loop over them, use the getDelcaredFields() or getDeclaredMethods()

Fun Things to do with Relection in Java

You can discover new techniques of programming once you feel the power of Reflection in your hands. The new techniques would include instantiation of objects dynamically, setting of values to fields and invoking methods without calling them explicitly.

Let’s take the case of a Singleton class into consideration for showing the true power of Reflection. For a Java novice, a singleton class is the one which has a private constructor. It isn’t practically true, but let’s assume that it is. Using reflection, this concept of singleton can be broken.

Here is an example of a Singleton class:

public class SingleCandidate {
 
private String name;
 
static int counter = 0;
private SingleCandidate() {
 
counter++;
 
System.out.println("Instance #" + counter);
 
}
public void showName() {
 
System.out.println(name);
 
}
 
}

A Singleton pattern dictates that only one instance of the object must be present at a given point of time in a JVM. So now, let’s take the above Singleton class for a ride with Reflection:

Class singleton = SingleCandidate.class;
 
Constructor privateConstructor =  singleton.getDeclaredConstructors()[0];
 
privateConstructor.setAccessible(true);
//This is scary
 
SingleCandidate obj = (SingleCandidate) privateConstructor.newInstance();
 
SingleCandidate obj2 = (SingleCandidate) privateConstructor.newInstance();

The code is self explanatory and you will realize that in this way you can easily create many instances of the possible candidate for a singleton class in the JVM. How fool proof was that?

Setting Values to Private Fields!

What did you learn in encapsulation? Was it making fields private and public so that private fields could be accessed only by the class in which they are declared?  Reflection can break this too.

//Even more scary
 
Field privateField = singleton.getDeclaredField("name");
 
privateField.setAccessible(true);
privateField.set(obj, "You are not a singleton anymore");
//Access private Constructor
 
System.out.println("Accessing private Constructor: " + privateConstructor.getName());//Get a private field value
 
System.out.println("Accessing private Field: " + privateField.get(obj));
//Invoke a method
 
Method method = singleton.getDeclaredMethod("showName");
 
method.invoke(obj);

Reflection with Generics

If you have tried out the above code in Eclipse you might see some warnings for the Class or Constructor usage. The warning message will be:

Class is a raw type. References to generic type Class<T> should be parameterized

Constructor is a raw type. References to generic type Constructor<T> should be parameterized

To suppress these warnings you will have to use the generic parameter “?” as follows:

Class<?> singleton = SingleCandidate.class;
 
Constructor<?> privateConstructor =  singleton.getDeclaredConstructors()[0];

The questions mark symbol is a wildcard type used in generics. This only applies only if you using Java 5 or higher versions.

Uses of reflection

Reflection is powerful technique when used appropriately. The major usage of reflection comes in when you are building your own framework, compilers or development tools in which you need access to the metadata of the classes created by end users. You surely might have already used the best products of Reflection without even knowing about it.

• JSP gets converted to Servlets using Reflection.
• The Spring framework uses Reflection to administer the references which you declare in your spring-config.xml without you explicitly instantiating any object. The whole concept of Dependency Injection (Inversion of Control) is conveniently implemented with Reflection.
• Reflection also gave birth to the concept of aspect oriented programming.

Reflection is not limited just to this post and nor Reflection is used for the purpose of breaking security. This article was aimed at showing you a direction with which you can explore Reflection more and discover new principles and techniques to build better applications.

Related posts:

• Convert Date to String and String to Date in Java
• Getting started with IoC – A simplified tutorial
• Java 5 Generics – Changing for good
• Microsoft Internet Explorer 7 – Nothing Special
• J2EE or JEE, Java 5 or Java 1.5 – Is SUN Crazy?

public class LocalInnerClassTest {
	public void defineInnerClass() {
		class MyLocalInnerClass {
			public void doSomething() {				
			}
		}
 
	}
}

Now lets suppose we want to pass a variable in the defineInnerClass() and pass it to the doSomething() for some computation, then according to the specifications on local inner classes methods we must declare the variables as final or else it will result in a compile time error. So the resulting code must be something as follows:

public class LocalInnerClassTest {
	public void defineInnerClass(final int var) {
		class MyLocalInnerClass {
			public void doSomething() {
				System.out.println(var);
			}
		}
	}
}

where var is the variable that must be declared as final to be passed into the doSomething() method of MyLocalInnerClass. Now the mysterious question which I faced was why exactly such a specification has been outlined. Why can’t the inner class simply take the variable as it is and process further.

In order to understand this reason as to why local inner classes can access only final variables, we have to learn how exactly inner classes get translated to the byte code. The moment you come to know this, you can easily see the logic behind making the variables final.

How Are Inner Classes Translated to the Byte Code

Here is the secret. Inner classes as you must have known them from a long time are still mysterious to the JVM. Yes its true. Inner classes have been implemented only to the compiler level. When the classes are compiled which contain inner classes, the byte code which gets generated does not actually implement inner classes as a class within a class. The book on Core Java from makes this statement:

“Inner classes are translated into regular class files with $ (dollar signs) delimiting outer and inner class names and the virtual machine does not have any special knowledge about them”

That means when the above class file from the example is compiled it will generate two class files such as:

1. LocalInnerClassTest.class
2. LocalInnerClassTest$MyLocalInnerClass.class

Unfurling the mystery of final variables

If you apply logic to the above theory of inner class at the byte code level, you have the answer to the mystery of having final variables. For explanation purpose, lets take the same example.

First lets say we make a call to the defineInnerClass() by creating an instance of LocalInnerClassTest. At this point, the instance of MyLocalInnerClass is still not present because the JVM treats it as a separate class at the byte code level. So when the call to defineInnerClass() is made the JVM tries to instantiate an object of MyLocalInnerClass.

But here we run into a problem. The function doSomething() accesses the var variable which is passed down from the outer class method. If you can simply apply logic over here, you can see the problem. How should the JVM pass the variable which has been declared in one class file to the method in another class file?

In order to solve this big problem, the JVM acts smart. It makes a requirement for the developer to make the variable passed from the method of an outer class to be declared as final. How would this solve the problem, you may ask? When you declare the variable var as final the compiler does a trick. The trick being, it quietly places a hidden variable with the name val$var inside the 2nd compiled class file.

The variable val$var is assigned the same value which has been assigned to var since now the compiler knows that the value cannot be changed as it has been declared final. This is very clever, since final variable must always be assigned before compilation.

So there you go. Now, when you run the program from within an application the inner class already has the value which has been assigned to var through its inner hidden variable val$var and thus the mystery gets solved. Therefore you have the concept that local inner class methods can have access to only the final variables of the outer class.

Hey, Local Inner Classes can even access Outer Class member variables directly. How?

Ok, now that we have tackled the above mystery, this is more simpler. The below code gets perfectly compiled

public class LocalInnerClassTest {
     private int var2;
     public void defineInnerClass(final int var){
 	  class MyLocalInnerClass{
 		public void doSomething(){
 			System.out.println(var+var2);
 		}
     	  }
     }
}

You can notice that the local inner class has direct access to even the private variable var2 of its outer class. The reason behind the accessibility of outer member variables directly inside the local inner classes is that, once again the compiler cleverly places one more hidden variable named as this$0 which is a final instance variable of the outer class type. When the inner class object is instantiated the variable this$0 is given a reference to the outer variable with direct access privileges. Hence you can access the outer class member variables directly from within the inner class. Smart isn’t it?

Related posts:

• Unleash the Power in Your Blog with Google Custom Search
• HP Snapfish India, For Cost Effective Printing
• Learn the Servlet API – A step by step approach
• Annotations in POJO – a boon or a curse?
• Getting started with IoC – A simplified tutorial

 Unsupported major.minor version 49.0

This error is given because the new features introduced in the newer version of Java are not present in the older version. So you have to be careful for using such class files on older environments. For resolving this error you have to follow some simple tips as follows:

1. Check you java version by running the command java – version
2. Check your environment variable JAVA_HOME and the path associated with it
3. Check your server installation if it was installed on an older version
4. Check which path exists in the environment entries

These are the quick tips you would need to do in order to get rid of the error. Sometimes it may happen that the system which you are using might be loaded with 2 to 3 version of Java and you might be required to work on the newer one. In such cases always there is a confusion as to what went wrong and with which version. So if you are left in such crises do the following quick action tips:

1. Edit your JAVA_HOME with the latest java home folder path
2. Edit your path variable which might already have been set with older version
3. For this goto My Computer > Properties > Advanced > Environment Variables > path
4. Remove the earlier version path which might be something like <java_installed_path>/bin and replace it with newer version path
5. If your server was installed on a older version of Java and if it not been used then its better to uninstall it and then install it after making the above changes.

Note: You can check if your server was installed on an older version or not by opening the startup.bat of your Tomcat server or any start up script of other servers and finding the part where the script itself sets the JAVA_HOME variable. If you find that it has been set to a older version then it won’t do any good just by replacing it with a newer version path. You would ultimately have to reinstall the server as per my understanding.

It would be interesting to know if the same can be resolved without having to reinstall the server. Please suggest some alternatives if you have.

Related posts:

• Wordpress Database Error – Table ‘wp_post2cat’ doesn’t exist
• Wordpress Error – “Allowed memory size of 8388608 bytes”
• Working With JAX-WS in JDK 1.6
• J2EE or JEE, Java 5 or Java 1.5 – Is SUN Crazy?
• 3 Easy Steps to Install MySQL on Windows XP

What is a namespace?

A namespace is an identifier for elements. XML and XSD use the concept of namespaces to define a relationship between the elements and their hierarchy. It means that when their are multiple elements to be defined then it might be possible that some of the elements may tend to have the same name. But having the same name often leads to collision just as the in the case of classes with same names although in different packages but referenced by name alone in a Java program. Hence the concept of namespaces is used in order to distinguish such elements.

Why are namespaces used?

XML and XSD are never meant for human reading. You have to remember that even though XML is a data representation markup language, it would be rare that you will actually be parsing through an XML file to use the data in your application through your own code.

Such parsing is often supplied through the use of API’s like SAX, DOM, JAXB, etc. You would have till now actually used these libraries while dealing with web services since it is field which uses XML, XSD to the maximum. The concept of namespace has no relevance until and unless an XML instance is associated with an XML Schema (XSD). This is because, XSD defines what do the elements in the XML instance actually mean. A standalone XML just makes the data easier to understand to you but to an XML parser it is nothing but a set of elements in some heirarchy.

For example if suppose you have the following XML format:

<employee>
<name>Alan</name>
</employee>

From this an XML parser can list out that the XML instance contains 2 elements in which employee is the root and name is the child of employee. It cannot say anything more than that. For giving more meaning to the elements, XML Schema or XSD should be provided. If you want the parser to know what kind of element employee is then you would have to provide a namespace for the element to be in as follows:

<tt:employee xmlns:tt=”http://techtracer.com/schemas/employee”>
<name>Alan</name>
</tt:employee>

How to interpret namespaces?

In an object oriented language like Java, entities of the real world are mapped to Beans. Beans have properties. And in general every application uses the beans and their properties to provide values which are taken from either a system or an end user. Such values when needed to be transferred in the XML format need some kind of hierarchy to be structured with. For this API’s come to the rescue.

But before we can supply the API with the elements in any adhoc fashion it becomes necessary that we make the API aware of the structure by providing it with the Schema without which the API won’t be able to tell you if anything has gone wrong in the hierarchy or not. Such API are said to be namespace aware API’s.

For Example, if I have an bean inside a package which is to be included into any program then you would include it when required as:

import com.techtracer.*;

//and then make the bean as

MyBean bean = new MyBean();

Now you can refer to the classes within the package successfully.

Comparing the above to namespaces consider the example.

<tt:employee xmlns:tt=”http://techtracer.com/schemas/employee”>
</tt:employee>

Here tt would be an prefix to the elements which has the value of the entire URL and it would correspond to the namespace just as a package in Java and employee would be an element just as the MyBean in Java. If you would not have provided the packages then the Java program would have given out an error. Similarly in a namespace aware XML parser if you don’t specify the namespace of the element then it would not run successfully.

Default Namespaces

java.lang.* is the default package of core java. Comparing with a XSD the default namespace is:

<xsd xmlns=”http://www.w3c.org/2001/01/XMLSchema”>
</xsd>

Here xsd is in the default namespace i.e. the element xsd is an element of the XSD specification. So now we can say that as java.lang is the default package of java similarly the above namespace is the default namespace of XSD. And as Object is the parent of the Java classes the element xsd is the root of the XSD specification

Custom and Target Namespaces

There are libraries in Java, which may / may NOT be required. Library means something which you can refer to when required, else not. So including it unnecessarily as a inherent feature may be disturbing since they are present for specific reasons and not to be imposed as an implicit feature of the language. Consider this example:

<xsd xmlns=”http://www.w3c.org/2001/01/XMLSchema”>
<employee>Alan</employee>
</xsd>

Woops, now here is an error. The element employee is NOT an element of the XSD specification. If you have an XSD validator it will blurt out with a big error message. This is because the XSD specification does not know a thing about your custom element employee. So what do you do? Somehow you should keep your employee in a safe and secure place where it can be recognized as yours. So we can keep it under a custom namespace like “http://techtracer.com/schemas/employee”. So the change required in the above fragment would be as follows:

<xsd xmlns=”http://www.w3c.org/2001/01/XMLSchema” targetnamespace=”http://techtracer.com/schemas/employee”>
<employee>Alan</employee>
</xsd>

So now when the XSD validator comes across the element employee, it just checks if you have told it where it should belong (before starting the ritual of swearing at you!). Now it knows that you have mentioned a thing called targetnamespace. So it knows that your employee actually belongs to a separate specification which is nothing but your custom XML Schema. The new URL which is mentioned in the targetnamespace is your custom namespace itself.

Conclusion

Hope that this article helps to make you understand namespaces quite easily. Feel free to ask a question if you have any doubt about namespaces. Your query will be solved at the earliest.

Related posts:

• Java 5 Generics – Changing for good
• Resolving the “Unsupported major.minor version 49.0″ Error
• Java EE – Exhaustive yet Enchanting
• J2EE or JEE, Java 5 or Java 1.5 – Is SUN Crazy?
• And I thought I Knew How Java Worked!

It was in the morning that my colleague asked me that he had taken an interview where he asked the question to the interviewee,

What is the difference between JVM and JRE?

Of course, it was Java Virtual Machine and Java Run Time Environment, I said without a second thought. But it doomed to me like never before, what next was their difference? Was it something that SUN had planned to demystify my confidence in the world of Java. Reluctantly, yet diplomatically I said to him that I knew the difference but I would like his point of opinion. He said something which I half heartedly believed, putting on a note in my mind the quest for the day to find the interesting answer to this seemingly easy but notorious question. The answer he relented was,

JVM is a specification and JRE is an implementation. JVM is just like the Servlet or the JSP specification provided by SUN and JRE is the implementation that is OS specific. JVM is not installed, but JRE is.

The last line left me gasping for breath. Until now I had been installing JVM and also had seen the JRE folder in C:/Java, but today I failed to recollect what the heck was JRE and how in the world I could install a JVM, as supposedly said by my colleague.

I went to the office to quench the thirst of my curiosity. I was ablaze with surprise when I searched and found the exact same words that my colleague had said to me. This came from the Java Forum. I thought it was maybe the right one. Enlightened with this, I called upon another colleague of mine and asked him as to put him to the judgment grill. The question remained the same but the answer did not. It was another baffling one,

Do you know you can download JVM too. Now don’t try to act smart. Just Google it and you will come to know.

And Google did answer it by religiously giving me the set of links to download JVM. But none of them were from the creator itself i.e SUN. It was turning out a little fishy in this. Now came the moment to test download JRE and to my relief, the first link was of SUN. Thankfully the query had been resolved to a partial satisfaction that maybe the first answer had really been true.

Little was my confidence boosted when my colleague intriguingly asked me another,

Did you know that your JRE is capable of running your class files without the need of a JDK. I have done that and they ran like any normal program would.

I gawked at him in amazement. It was like getting bedazzled with someone pounding you like a heavy weight boxer. But having no mercy he went on saying,

I have been able to run Eclipse and write Java programs without having JDK in my system. I have seen there is no javac in JRE folder but still I was able to create a Java Project and run it in Eclipse.

Bewilderment was taking a toll on my brain and I was at the brink of saying that I love Microsoft and .NET, when he said that he was also amazed at this but did not know the right answer. Phew! something to cheer about, at last. It is good to know that somebody else in your surrounding is feeling the same pain in the butt and telling you about it.

One thing was clear, my knowledge lacked the essence of core Java as some of them who searched the forums to find a relieving answer. And as lucky as I could get I got one such nicely explained statement from which, I hopefully came to know what was the difference between JVM and JRE, in JGuru forum,

JVM forms part of large system JRE. It comprises a set of base class which are implementation of base java API, as well as JVM. JVM is used for running the java software with the availablity of JRE which is different in a given environment. JVM’s main job is interpreting java bytecode and translating this into actions or OS calls.

This I found was the correct definition and further to clear my doubts I found one more resource which gave out a formal explanation with a set of diagrams to clarify the point being made. The point of concern are as follows:

• The Java Virtual Machine is responsible for interpreting Java bytecode, and translating this into actions or operating system call.
• The Java Virtual Machine forms part of a large system, the Java Runtime Environment (JRE). Each operating system and CPU architecture requires a different JRE.
• The JRE comprises a set of base classes, which are an implementation of the base Java API, as well as a JVM
• Without an available JRE for a given environment, it is impossible to run Java software.

In short and sweet words, I can now say that JRE is like the motherboard and JVM is like your processor which powers your computer. You can never have a processor and motherboard catering to different architecture. And although each entity is a different component of your computer, both have to run in tandem to bring the power of computing to reality.

Now I somewhat know how Java works!

Related posts:

• Mozilla Prism – A Revolution in Web Apps
• SCWCD – Mission Accomplished 2
• Effects of Oracle BEA Acquisition
• Eclipse Europa Has Ruined My Day
• Author

The product confusion

If you are still thinking that Java 2 meant version 2 of Java then you are being duped. Java 2 means version 1.4 of Java. I am still dumbfounded as to where Java 3 and Java 4 disappeared but I guess with the success of Java 5 they were buried in debris even before they born!

I was still in bewilderment until the web started to roar about Java 6. It took me a lot of time to actually sink in the fact whether Java 5 referred to version 1.5 of Java and Java 6 referred to version 1.6 of Java. This confusion was due to the use of Java 5.0 in some places. Are Java 5.0 and version 1.5 of Java one and the same?

The fact is that Sun makes use of dual naming convention for the same thing. One naming convention if for the product and one is for the developer. The official documents mentions,

Both version numbers “1.5.0″ and “5.0″ are used to identify this release of the Java 2 Platform Standard Edition. Version “5.0″ is the product version, while “1.5.0″ is the developer version. The number “5.0″ is used to better reflect the level of maturity, stability, scalability and security of the J2SE.

Really, a lot of maturity I say!

Developmental and Mental Destruction

SUN has not left people in peril by their naming conventions swapping not only in the case of Java releases but also in the names of the development kits. Earlier for programming in Java I used to download JDK which meant Java Development Kit. I don’t remember which version I was working upon. Maybe it was 1.1.

But when the Java 2 reign started I was asked to download J2SDK which means Java 2 Software Development Kit. SUN had finally realized that people were actually making softwares on Java!!

Java 2 was there to stay for a long time until the hue and uproar for Java 5 came in the picture. But wait, SUN was ready for another swap of naming to gain momentum with the success Java 5, which was reverting back to the name of JDK.
The official document mentions,

Due to significant popularity within the Java developer community, the development kit has reverted back to the name “JDK” from “Java 2 SDK”

Am I supposed to NOW assume if JDK still stands for the same meaning i.e “Java Development Kit“. No! Sun has more surprises for me. NOW, JDK actually means “J2SE Development Kit“. I still fear when this meaning will come crashing by! Did I hear some one shouting “Jean Claude Van Damn Karate Club” for JDK!!

Certifications Confusion

The certifications were also not spared. If you happen to prepare yourself for the SCBCD (Sun Certified Business Component Developer) exam, then you are in for trouble with making sure which exam are you heading for. I bet you would definitely get fumbled in this-

• SCBCD 1.3 refers to you working with EJB 2.0
• SCBCD 5.0 refers to you working with EJB 3.0

Didnt it all appear to SUN to keep the version of SCBCD same as the EJB we are working on?

The reality is that EJB 2.x was meant to work with J2EE 1.3 and since now after the up gradation of EJB to EJB 3.0 even the Java EE specifications have been upgraded to 5.0. Hence the certification number is the number of the Java EE specification and not of the version of EJB it is based on. Similarly it is SCJP 1.4 and SCWCD 1.4 which are for J2EE.. err.. I mean J2EE 1.4 or is it so. Jesus, pardon me if I have done anything wrong!

Now you must have been enlightened about which version you are associated with. I will take some time to digest this completely. My head is still reeling with these numerological mumbo jumbo. Maybe there is something more in store for us. Before that hey, which version are you currently working on?

Related posts:

• And I thought I Knew How Java Worked!
• Java 5 Generics – Changing for good
• SCDJWS preparation – a kick start guide
• SCDJWS study material and resources – The most searched thing
• SCDJWS – mission accomplished

Why are there always 3 Steps to success?

This probably would be the same doubt on the lines of why do we say “Ready…Steady…Go” and also the countdown of a start of a timer in “3..2..1“. Well, the 3 steps are same everywhere, only their definition changes. Similarly I always make it a point to divide my preparation routine into particularly 3 steps to make it sound quicker and much systematic. Finally, its the enthusiasm that counts that you put in each of the steps.

Stop all that blabber… How do I go about preparing for SCWCD?

Okay..okay. SCWCD (exam code – CX 310 081) is aimed particularly for the web developers and it takes into consideration that you must have developed web applications in the past and now want to try out with JSP/ Servlets. So there wont be any questions about how and what are the intricacies dealing with what a web application is, but concentrates on how would you build web applications using the web components that SUN provides.

SCWCD – The preparation

The 3 steps for success in SCWCD are:

Step 1 - Head First Servlets & JSP

The Head First Series have become a kind of bible series in whatever they have released their books. In case of JSP / Servlets , its remarkable to see how easily the concepts can be grasped from their way of story telling. Some people would find their books very nonsensical with all those cluttered animations and text written like a scratch pad. Even I had felt the same before reading their first chapter. I did not even come to know that I had finished a total of 3 chapters even though I had the intention of reading just one.

You should mark my words “Every beginner must use the Head First Series to grasp the concepts quickly“. Ever since I have read this book I have become a fan of the authors! This book would even be handy to pass out of the exam if you were actually acquainted with working of JSP / Servlets. Solve all the questions at the end of each chapter.

OR

Step 1 - SCWCD Exam Study Kit – Hanumant Deshmukh

For a beginner in the world of JSP/ Servlets the Head First Series is enough. But for people who have worked for some time in this technology would find the Head First Series a no brainer. Instead I would suggest such people to get a copy of this book. First of all, its a no nonsense book. It goes strictly with the exam topics and covers almost everything that is required to pass out of the exam.

The language is very lucid and is devoid of any jargons. The quizzes at the end of each chapter should be solved only after you have read the entire book since it would be like a revision of all the concepts. I especially liked the quizlets in the midst of the chapters which act as brain teasers. It even gives you a quick revision section where in you can just flip through the pages and have a quick briefing of all the important aspects for the exam. It does not have a mock test as HFSJ does at the end of all chapters.

Step 2 – SCWCD Study Companion – Charles Lyons

SCWCD cannot be aimed for a 100% if you have not referred to the API documentation or the JSP and Servlet Specifications. But would you really like to go through such humongous documentation within a short span of time? I hear many no’s cried out loud. But what if I say you would get a compact series of chapters and exam wise listed topics with the API information just perfect for the exam and Specification filtered out with only the exam relevant aspects then this the book to go for. I woudln’t have been able to score a 90+ score seriously speaking without this book.

Charles Lyons has prepared the book with a lot of efforts of perfectly scanning upto the API level details and also packaging it with the specification information so compactly that you don’t get bored reading it. He has maintained the flow so accurately that your questions will immediately be answered just as they get raised in your mind. Don’t try to read through the chapters in between because the flow of the chapters will be clear only when you start it from the beginning. I assure that reading this book wont make you touch the specifications nor the API documentations at all. Even I didn’t!

The best part of the book is it acts not only as a SCWCD study companion but also as a Reference book for future use since it has additional chapters for the updates that have happened in the recent past in JSP and Servlets.

The one thing I would reprimand in using this book is don’t try to solve tests provided at the end of each chapter since they are literally tough! You need to have your brain super charged to solve the tests since they cover an amazing depth of knowledge. But on the lines of SCWCD you won’t get such difficult questions so it is better if you stick to the tests provided in the earlier 2 books.

Step 3 – Test yourself with the JWebPlus Simulator and the HFSJ mock test

Finally when you are exhausted with all the reading you would need some time to practice. Till now I have not said about practicing! This is because I believe that it is better if you first understand all the concepts clearly before practicing. So after all your theoretical concepts have been cleared try to practice on the basis of mock tests! This is a unique way of clearing your doubts.

The JWebPlus Simulator is the best simulator, provided by Enthuware, which perfectly mimics the original exam environment. I haven’t tried the Whizlabs since they don’t replicate the same sense of depth as the exam provides. They are more tough than the actual exam and I don’t want anyone to feel disheartened when they get a low WhizLabs score.

After your reading is over try to solve 1 or 2 tests. In each test note down which are your strong and weak points. The exam results provide scores topic wise. The strong points dont need to be tried out since you obviously have the knowledge of them. But you definitely need to try out the weak points.

If you ask me I had failed in the first 2 tests and my weak points were mainly tag libraries and EL(Expression Language). But when I realized that I had the theoretical knowledge but did not know about their practical aspects then I tried it out myself and each of the trials clarified my doubts and I felt more confident. I sincerely feel this is a good approach rather than practicing out each and every thing. Some things can be just learnt from the books.

The JWebPlus Simulator has a total of 7 mock tests and 3 categorical tests namely – easy, tough and very tough. By carrying out the step in the fashion as I mentioned I started getting 84% in the later tests and my confidence was sky high.

The ultimate test I would advice you to give is the HFSJ mock test. Altough after solving so many tests you don’t actually have to solve this one, but as the saying goes “Nothing is impossible” you should try to solve it out too. The only challenge you would face here is that the multiple choice questions haven’t been stated as to how many you have to choose. Rather it is mentioned “Choose all that apply” which is somewhat irritating. But you should accept it as a challenge and prove yourself that you are an expert now! I took the challenge and scored an 81% in the mock test.

The battle begins!

So now that your 3 steps have completed, you are armed and ready to conquer the test of the time. The final SCWCD (CX 310 081 – remember this!) and the moment of celebration will be just 2 and a half hours far from you! So get armed with these 3 steps in mind and jump the bandwagon of conquerors as I shout out loud “Ready…Steady…Go!“

Related posts:

• uCertify SCWCD PrepKit – Detailed Review
• J2EE or JEE, Java 5 or Java 1.5 – Is SUN Crazy?
• SCWCD – Mission Accomplished 2
• Google Chrome – What’s in it for ya?
• Web and Desktop Apps – the 3rd World War!

What is a Front Controller Pattern?

A Front controller pattern follows the rule of having a single entity controlling the entire application. The single entity acts as a barrier between the client and the remote application. All requests targeted towards the application and first received by the single entity and then based on the controlling flow of the application, the requests are forwarded to the intended recipient module of the application.

The advantage of the Front Controller Pattern is in the simplicity of maintaining a single entity instead of multiple flows controlled by multiple entities. This results in streamlining the flow and proper filtering of the requests made to the application.

Why is Struts Framework essential in an MVC architecture?

In a J2EE web application, when creating an MVC architecture, usually the JSP is taken for a view while the Servlets do the job of controlling the flow from the view to the underlying model, which may consist of POJO’s or EJB’s.

When it comes to designing the controlling flow for the application, developers are left in a scurry to decide how many Servlets should they finalize for the application.This decision is usually based on the number of forms which have to be created for the application to collect the data.

This is because each form when submitted via a JSP with a POST method has to be handled in a Servlet (This can be done in a JSP also, but it is not a good practice since scripting inside a JSP is a criminal offence!) . Now if the application consists of about 10 forms, handling each form in a separate Servlet seems to be a good choice, but that means creating 10 Servlets!.

Any alternatives?

The way to avoid through the above situation is have less Servlets and use the switch or the if..else structure to find which request are you serving for. But over a period of time this nature of creating Servlets can easily lead to creating a mess of conditional statements scattered over the application leading to costly maintainance.

Besides this, the major downside is that as the number of Servlets in your application grows the number of instances to be kept running in the memory also increases. One Servlet spawning many threads is always less heavier than many Servlets having multiple threads.

Why choose the Struts Framework?

Due to the above analogy it might be worth the benefit if having only a Single Controller Servlet which accepts all the requests and then makes the decision of where to forward the request. But, making a manual Front Controller Design may be more time consuming than thought as compared to making multiple servlets.

Hence to avoid all these difficulties, the Struts framework is used to implement the Controller entity in your MVC architecture since it follows the Front Controller pattern. It has been very well establised in the web applications domain for a long time.

What are the advantages of choosing Struts?

The inherent advantage of choosing the Struts Framework is that you get a ready made implementation of the Front Controller pattern. Besides that Struts is a robust and an entirely flexible framework to work with.

Struts gives you the features of

• Custom class based controlling components
• Population of Java Beans through HTML form elements and their validation
• XML based configuration for all underlying components
• Full support for internationalization through provision of resource bundles for all the HTML elements
• Tag libraries for easy integration with your existing JSP’s and
• An elegant way of handling form related errors.

Installing the Struts framework just involves including the required Struts JAR files in your /WEB-INF/lib and taglibs in your WEB-INF directory. Struts is a very robust and lightweight framework which can run even on a Tomcat Web Container. Struts can come handy when you want to achieve the task of making a web application which not only is easier to maintain but also good in its overall performance.

Related posts:

• Key Points for Choosing the Best framework
• Java EE – Exhaustive yet Enchanting
• First step in Ajax – Choosing the right framework
• Inversion of Control – for easy integration
• 5 tips to use Ajax in the proper way

The traditional looping for construct has served well for many years in Java. Even today, for collections people still use the traditional approach for looping through them. The simple reason being familiarity. Its evident that the powers provided by the revolutionary addition of features in Java upgrades have yet to see their complete establishment.

Coming to the collections frameworks the other leagues of languages like PHP, JavaScript, VB have provided convenient looping constructs for the for syntax namely the for each block. Java programmers have craved long for the same and its time that it was implemented in the favorite language of millions worldwide.

The collections framework comes with a new for construct or the for-each block although the each term is missing from the syntax. Now you don’t need the much abused Iterator for looping and fretting over the same routines to be written when a collection is received. The for-each block makes it more cooler to write the same construct without the need to obtain an Iterator and with the added feature of generics, you don’t have to typecast the object received from the collection.

The earlier way in which the code for looping through a collection would have been written as,

	List list = new ArrayList();
	String a = "Hello";
	String b = "World";
	list.add(a);
	list.add(b);
 
	String s;
	for(Iterator i = list.iterator(); i.hasNext();){
		s = (String) i.next();
		System.out.print(s + " ");
	}

OR

	Iterator i = list.iterator();
	String s;
	while(i.hasNext()){
		s = (String) i.next();
		System.out.print(s + " ");
	}

The result would print “Hello World”.

The Iterator becomes simply unnecessary since it is obvious that a collections require it to get looped. But in the traditional approach the programmer has to make the trouble of introducing it every time he sees a collection. In Java 5 you would be writing the same block as follows:

	List<String> list = new ArrayList<String>();
	String a = "Hello";
	String b = "World";
	list.add(a);
	list.add(b);
 
	for(String s : list)
		System.out.print(s + " ");

Here you see that looping through the for-each block is so simple that it reduces all the need to construct an Iterator. The generics features make the collections specific to one type of object i.e when you define List<String> you make it explicit that the List would only contain String objects. Of course you would question about losing flexibility by doing this. But generics is a very vast topic to be dealt with and it includes all the features for introducing objects of inheritance in a collection.

Coming down to the main topic i.e the for-each construct, here you only have to define the type of object which you will be requiring in your loop. In the example I had made a String collection. So the object I would require to store the intermediate values would be a String object. The object “s” of String type does this work of storing the intermediate values.

The syntax “String s : list” means that “for each object of type String in the collection list, do loop and store the obtained value in s“. Once inside the loop you get the intermediate value in s to be printed. Hence avoiding the need of an Iterator and a type cast for looping inside the new collections framework. Using this feature the code definitely becomes more easier to be written, debug, test and mainly readable.

Related posts:

• Java 5 Generics – Changing for good
• JAX-WS + JAXP Tutorial – Building A StockQuote Web Service Client
• Reflection in Java – Simplified
• J2EE or JEE, Java 5 or Java 1.5 – Is SUN Crazy?
• Resolving the “Unsupported major.minor version 49.0″ Error

Objective
The main objective of this mini tutorial is to highlight the implementation of an interface based Inversion of Control (IoC) architecture and to state how it could help in the integration and maintenance of the application.

For this mini application I will use the following set of classes

1. Dependency – This is the interface which is implementation as per my application versions progress and which will be used by the View components in my application. In other words this is my Model component in a MVC architecture
2. Dependent – This is my View component which uses the Model component to produce the results for displaying. As the name suggests the class is dependent on the Dependency implementation.
3. Injector – This is most important class in the application and which introduces the aspect of Inversion Of Control into the applications. This class can also be referred as the configurator class.
4. Finally there can a number of implementations of the Dependency interface according to the needs of the application.

Note: This mini tutorial is based on the concept of Interface based IOC. It also assumes that you import the required classed in your Classes when compiling them.

Lets start with our tutorial.

Dependency.java

public interface Dependency {
	public void doSomething();
}

Dependency is the generic interface which my application supports. The IoC is done by a configurater class which will inject the dependency of the implementation object based on the runtime requirements and then provide it to my application. Hence my application can support various types and versions of the implementations until and unless they follow the contract as per the Dependency interface. Sometimes this technique is referred to as “Design By Contract“. So for any interface based IoC design, your set of interfaces in the application must be finalized since they prove as the reference to be used inside the configurater classes.

DependencyImplOne.java

public class DependencyImplOne implements Dependency{
 
	public void doSomething() {
		System.out.println("Hello World! This is the first implementation for Dependency");
	}
 
}

This is my first implementation for the Dependency interface. It just implements the single method doSomething() and displays some text.

ioc.properties

# You can have your own package instead of the one mentioned here.
package.name = com.techtracer.ioc
class.name = DependencyImplOne

This is a simple external IoC configuration file . It defines the values for the package name and the implementation class name. I have used an external file in order to highlight the benefits of not having to hard-code the required parameters in the program.

Injector.java

public class Injector {
	public static Dependency getInstance(String propertiesFile){
		Dependency d = null;	
 
		Properties p = new Properties();
 
		try {
			p.load(new FileInputStream(propertiesFile));
		} catch (Exception e) {
			System.out.println("Could not load file");
		}
 
		String packageName = p.getProperty("package.name");
		String className = p.getProperty("class.name");
		String impl = packageName + "." + className;		
 
		try {
			System.out.println("Instantiating Type : "+  impl);
			d = (Dependency) Class.forName(impl).newInstance();
		} catch (Throwable e) {
			/*
			 * You have to remember to catch a Throwable here
			 * since only catching an Exception could still throw an
			 * NoClassDefFoundError if you supply a wrong class name
			 */
			d = null;
		}
 
		return d;
	}
}

Finally this is actual class on which my IoC architecture will depend. This is the configurator class which will inject the Dependency implemented object based on the application requirements in runtime. However I am free to change this class anytime I want and provide a new dependency to my application either through hard-coding or through some configuration properties or XML file. It is like a pre processor which acts between the object creation and the object consuming phase and is the heart of the IoC architecture.

You might see that I have used Reflection for getting the class name to be instantiated as shown in the syntax Class.forName(). You are not expected to know this and you can very well use a different type of instantiation method of your choice or simply create an new DependencyImplOne() and return it. Also for this tutorial I have used the above created ioc.properties file. Remember this file has to be stored in your application ROOT folder and not the package directories.

Running the application
Now after creating all the classes you are ready to run the first IoC implementation. Just compile the set of classes in your package and after running the Dependent.java class you should be able to see the output:

Instantiating Type : com.techtracer.ioc.DependencyImplOne
Hello World! This is the first implementation for Dependency

Congratulations! if you were successfully able to run the program.

IoC for easier integration
Now suppose at a later point of time you would like to change the behavior of your program and it should be able to produce another output instead of what the DependencyImplOne.java provides. But what if you have to do this without ever having to touch the source code of your earlier code. Is this possible?

The answer to the question is YES. This is because due to the IoC provided by the Injector class now you have the full flexibility in modifying the runtime behavior of your application by just creating another class which implements the Dependency interface and mention the newly created and compiled class inside your ioc.properties file.

So I would now create another class with the name DependencyImplTwo.java and simply put a different output String in place of the original.

public class DependencyImplTwo implements Dependency{
	public void doSomething() {
		System.out.println("This is the second implementation for Dependency");
	}
}

Remember this class has to import the Dependency interface but it itself can be placed in any package regardless of the package structure of the original source code. After compiling the above class you should once again run the Dependent.java class as earlier and check the output. The output now should be:

Instantiating Type : com.techtracer.ioc.DependencyImplTwo
This is the second implementation for Dependency

Conclusion
So, with this tutorial it is clear that with the help of an IoC architecture you can change the dependencies as and when required without affecting the rest of the components in your application, thus avoiding side effects of the frequent changes done to it. It’s also very easy to maintain and involves just placing the classes in their proper location.

Thus your application can be scaled and adapted to a changing environment by reducing the number of dependencies an application can encounter during its lifespan. However you have to be careful in designing the architecture and choose properly which are your Dependent components and which are your Dependencies since the interfaces are used to map the dependencies with those required for the dependents.

Related posts:

• Reflection in Java – Simplified
• Eclipse Europa Has Ruined My Day
• Working With JAX-WS in JDK 1.6
• About
• Convert Date to String and String to Date in Java