Anonymous Inner Class

Meri bheegi bheegi si palkon pe rah gaye, jaise mere sapne bikhar ke – ANAMIKA“. Indian readers can find the relevance here :-)

An anonymous inner class is one which does not have any name. Anonymous inner classes are created on the fly just in time. They introduce the weirdest looking java syntax. Following code shows an example of the anonymous inner class:

class Test
{

public void foo()
{

System.out.println(“main class foo method”);

}

public static void main(String[] args)
{

Test t = new Test()
{

public void foo()
{

System.out.println(“Anonymous class’s foo method”);

}

};

t.foo();

}

}

In this case look at the line in the main method that creates the instance of the Test class. Isn’t the syntax looking weired. Whats happening here is that we are actually creating an anonymous class which is a subclass of the Test class and overriding the foo() method. This is very useful when you just require to override one or two methods of a class, but do not want to create a new class all together for it. Here the anonymous class is created just-in-time and when the above program is run, it prints “Anonymous class’s foo method”.

Anonymous inner classes can also be used as an argument to a method call. The following code shows the same:

class Test
{

public void foo(Test t)
{

t.foo();

}

public void foo()
{

System.out.println(“main class’s foo called”);

}

public static void main(String[] args)
{

Test t = new Test();

t.foo(new Test()
{

public void foo()
{

System.out.println(“Anonymous class’s foo method”);

}

});

}

}

In the above we are calling an overloaded foo() method that takes an object of the Test class. We want to pass in an object that has a different behavior for the foo() method. So what we do is we create a just-in-time anonymous inner class and pass it as an argument to overloaded foo method. So when the no-arg foo method is called on the Test object from within the overloaded foo method, the anonymous inner class’s version of the no-arg foo method is called instead of the Test class’s original no-arg foo method. When this program is run it prints “Anonymous class’s foo method”

I would like to discuss one more case of the anonymous inner class case here. Sometimes you might require passing a just-in-time implementation of an interface which is not yet created. Consider a scenario that you have an interface and you do not have any class implementing that interface. You want to call a method that accepts the interface type. hat do you do? Simple ion this case also you would create an anonymous inner class and pass it as an argument to that method. The following code shows you the same:

class Test
{

public void foo(AnInterface i)
{

i.method1();

}

public static void main(String[] args)
{

Test t = new Test();t.foo(new AnInterface()

{

public void method1()
{

System.out.println(“Created just in time implementation class of the AnInterface”);

}

});

}

}

interface AnInterface
{

void method1();

}

Here we just created an anonymous inner class that is an implementation of the AnInterface interface and passed it to the method foo which takes the AnInterface type as a parameter. You can see that the anonymous inner class has to give the implement the method1() present in the AnInterface (obviously :-) ). When this program is run, it prints “Created just in time implementation class of the AnInterface”.

This is it for the anonymous inner classes :-) . Will keep coming up with more topics till the time I finish preparing for SCJP :-)

Method-Local Inner Classes

Method local inner class is that class which is declared within the curly braces of a method as follows:

class OuterClass
{

public void method1()
{

class MethodLocalInnerClass
{

public void innerClassMethod()
{
}

}

}

}

same as the method method1() can. The The above class MethodLocalInnerClass declared inside the method method1() is called method local inner class. As the name suggests this class is in the scope of the method only and can access any member of the OuterClass. Important point here is that the MethodLocalInnerClass class cannot use any of the local variables of the method1() (except those which have been marked final). the reason being that the method resides on the stack and as soon as the method life is over all the local variables of the method are also vanished. Now imagine if the method local inner class is using the method methods1()’s local variables and setting them as value of one of its instance variables and then method method1() passes an object of the MethodLocalInnerClass in another method’s invocation as a parameter. In that case the local variable will also be passed as a part of the MethodLocalInnerClass object. Now if the method1’s execution completes, then the local variables are vanished and in that case the object of the MethodLocalInnerClass will be carrying a reference to a variable which does not even exist on the stack anymore.

The following code will explain this scenario more clearly:

public class Test2
{

public static void main(String[] args)
{

System.out.println(foo().toString());

}
static Object foo()
{

Object localVar = new Object();
class Foo
{

public String toString()
{

return “Hi:”+localVar.toString();

}

}
return new Foo();

}

}

If you look properly, you can see that the foo() method of the Test class is returning a reference of the method local inner class Foo declared in the foo() method. So now you can call the toStrin() method of the Foo class from outside the method foo(). So whats the problem here. The problem is that the toString() method of the Foo class is using the local variable localVar which does not exists anymore as the method foo() has already returned and its stack has already been blown up. So this would not even compile. The only solution to make this code compilable is to make the localVar being used in the method local inner class Foo class as final.

One more thing about the method local inner class, that an instance of the method local inner class should be made after full declaration of the method local inner class. The following code will explain what I want to say here:

class OuterClass
{

public void method1()
{

class MethodLocalInnerClass
{

public void innerClassMethod()
{
}

}
MethodLocalInnerClass mlic = new MethodLocalInnerClass(); // remember this instantiation of the method //local inner class came after the class declaration.

}

}

If you try to create an instance before the class declaration, the code won’t compile for obvious reasons here :-)
That’s it for the method local inner classes.

JAVA Inner Classes

One class one responsibility : Cohesive Class. Got it. Its good of course“.

But what about the situation when there is a totally different set of responsibilities that actually require to be together as one unit and at the same time should be tightly bound to your class. The inner classes serve the purpose of having class that has an intimate relationship with your class while your class is hidden from others. This is because the inner class is actually a part of your class and has access to all the members of the class including even the members that have been marked private as any other other instance method would have. The inner classes are declared within the outer classes with curly braces as follows:

class OuterClass
{

class InnerClass { }

}

The InnerClass in the above code is an inner class of the OuterClass class. If you compile the outer class, you will get two classes instead of one as follows:

OuterClass.class
OuterClass$InnerClass.class

As you can see that the inner class is associated with the inner class name with a $ sign joining the name of the inner class with the outer class. This is so true to the behavior also, as the inner class would never be accessible without the existence of the outer class. As in an instance of the inner class does not make any sense without an associated instance of the outer class. Moreover you cannot say like java OuterClass$InnerClass to run the main() method in the InnerClass because the InnerClass cannot have any static declaration (main() is static of course !!).

Instantiating Inner Classes: As I already said, the inner class instance does not make any sense without the instance of the outer class to which it is associated or tied to, so in order to instantiate any inner class, you need an instance of the outer class as well. You may instantiate the inner class from within the outer class or outside the outer class.

Instantiating InnerClass From Within any non-static method of the OuterClass: This is fairly simple. As you would know that the outer class methods always has a this reference (except the static methods), so in order to instantiate you can simply write

InnerClass in = new InnerClass();

from any non-static method of the OuterClass.

Instantiating InnerClass From Outside the OuterClass or From a static method Within the OuterClass: In order to instantiate the InnerClass from within a static method of the OuterClass or from anywhere outside the OuterClass you would first need to make a reference of the OuterClass as follows:

OuterClass outerClass = new OuterClass();
OuterClass.InnerClass inc =
outerClass.new InnerClass();

That’s it for now on Inner Classes. there is a lot more to tell about it, but next time (but very soon I guess).

SCJP Exam Preparation

Hi all,

I am preparing for the SCJP exam and started the preparation about 3 months back. Its been a very tough decision for me to kick-start the preparation but then after one of my friends made me realize that I am wasting my precious time and that it is important to get certified ASAP, I started the preparation. I am going to tell you about the journey till now (I have still not given the certification exam). In my company the certification is compulsory though and I need to get certified by the end March 2008. I guess there is enough time till then. But you never know. Sometimes people might take years to get certified. Ok what I am going to do is to update this post till I get certified regrading what decisions I made in my journey to get certified :-)

1. So let me tell you that I finished Kathie Sierra’s book “SCJP Sun Certified Programmer for Java 5 Study Guide (Exam 310-055) (known best book for the certification as far as I know). This book has got everything that you might need to clear the certification with good score. I have my friends her in the company most of who have scored more than 90%in the exam (one has has also scored 100% :-) ). So I finished this book first time in about 20 days of time. There are a total of 10 chapters.

2. Although I started taking the mock tests that are freely available on the Internet. I tried Enthuware and whizlabs tests. But I did not get the expected score (average 70%). The reason obviously being that I probably did not remember all the details properly that are there in the book. So today I decided to re-read the book and then probably will take the mock exams again. Let’s see what happens…….

3. I am glad to announce that today I am nearly going to complete the whole book. I have already read till the 9th chapter half way and hope o complete the book by end of next weak (I would have completed it this weekend itself but then I have some prior appointments, so won’t be able to make it.)

“Protected” and “Default” JAVA Access Modifiers

I guess that these two are the most confusing and misunderstood access modifiers amongst all other JAVA access modifiers for most of the average java programmers till date . I would like to take one by one. Lets start with “default first”

Default: Default access modifier is no-modifier. i.e when you do not specify any access modifier explicitly for a method, a variable or a class ( FYI : a top-level class can only be default or public access modifiers) it gets the default access. Default access also means “package-level” access. That means a default member can be accessed only inside the same package in which the member is declared.

Protected: Protected access modifier is the a little tricky and you can say is a superset of the default access modifier. Protected members are same as the default members as far as the access in the same package is concerned. The difference is that, the protected members are also accessible to the subclasses of the class in which the member is declared which are outside the package in which the parent class is present. But these protected members are “accessible outside the package only through inheritance“. i.e you can access a protected member of a class in its subclass present in some other package directly as if the member is present in the subclass itself. But that protected member will not be accessible in the subclass outside the package by using parent class’s reference. Confused with language ? Take an example. Say there is class “Super” in package A containing a protected integer variable “protected int x” and it’s subclass “Sub” in package B. The following would be a legal statement in a class B:

System.out.println(x); // valid

Whereas following would be an illegal statement:

System.out.println(new Super().x);

// invalid, as you cannot use parent class reference to access the protected member outside the package.

Once the child gets access to the parent class’s protected member, it becomes private (or rather I would say a special private member which can be inherited by the subclasses of the subclass) member of the subclass.

I hope that clarifies the difference between the private and default access modifiers. But if you have a question still about it, please leave a comment and I’ll get back to you. :-)

thx

Posted in Java. 11 Comments »

Java Serialization

Java Serialization is used to persist Java objects. The persistence is achieved by writing the object state to an external system (it can be a file database etc). Once you have written an object, you can get the object back any time by reading the object back from that external source. This feature is mainly required when you are working in a distributed environment where your application is running in more than one JVM’s and you need to pass the objects from one JVM to another.

Serialization is achieved by using JAVA interface named “Serializable”. This is a marker interface (An interface that is just used to mark any class of being a particular type to let the JVM know that it is of that type. A marker interface does not contain any methods). We need to make any class implement the serializable interface (or inherit from a serializable class) if we want to persists the objects of that class. Its tells the JVM that the objects of this class can be serialized.

How to Serialize: After making any class implement the serializable interface, we need to write following few lines of code to actually serialize the objects of that class. Consider the following class that you want top serialize:

import java.io.*;
class Cat implements Serializable { }

public class SerializeCat

{

public static void main(String[] args) {

Cat c = new Cat();// serialization of the Cat object c, starts here
try

{

FileOutputStream fs = new FileOutputStream(“testSer.ser”);
ObjectOutputStream os = new ObjectOutputStream(fs);
os.writeObject(c);
os.close();

}

catch (Exception e)

{

e.printStackTrace();

}

// deserialization of the Cat object c, starts here
try

{

FileInputStream fis = new FileInputStream(“testSer.ser”);
ObjectInputStream ois = new ObjectInputStream(fis);
c = (Cat) ois.readObject();
ois.close();

}

catch (Exception e)

{

e.printStackTrace();

}

}

}

You can see that the serialization and deserialization requires calling the readObject() and writeObject() methods. These methods are present in the ObjectOutputStream and ObjectInputStream classes respectively. These methods actually perform the serialization of the object passed as the parameter. While serializing the object the current state of the object is saved. Here we are saving the state of the object by writing it to a file testSer.ser. Then we can restore or deserialize the same state of the object by using the ObjectInputStream’s readObject method. Note that here, since the readObejct() method returns the type Object so we need to cast the object to the required type explicitly.

Not everything might be serializable, make it Transient: If your class contains reference variables of other non serialzable classes, then while serializing the object of your class you would not be able to save the value or state of that reference variable of non serializable class. If you try saving you will get the following run time exception: java.io.NotSerializableException In this scenario, you have got following two choices:

1. To declare the reference variable transient by prefixing the variable declaration by keyword transient: In this case the state of the non-serializable reference will not be saved while saving the serializing the object of your class. Remember in this case, when the you deserialize the object of your class the value of the transient marked references of your class will be null as during deserialization the constructor of the class is never called.

2. To override the readObject and wrietObject methods of the ObjectInputStream and ObjectOutputStream classes respectively and save the state of the reference of the non-seriazable class.
In this case, you will have to call the defaultReadObject() and defaultWriteObject() methods in the readObeject() and writeObject() methods respectively and these calls should be the first line in the readObeject() and writeObject() methods. The methods should have the following signature only:

private void writeObject(ObjectOutputStream os)

{

// your code for saving the non serializable reference variables

}
private void readObject(ObjectInputStream os)

{

// your code to read the non serializable reference

}

After that you will have to specify how to save the state of the non serializable references of your class while saving the object of your class.

JAVA Threads : Join() and wait() methods

We all know that there are a lot of things in JAVA and to all of us (or rather to all the people I met till date, feel that Threads are the most tricky to understand as far as their real time behavior is concerned). This topic is about the behavior of the join method and its comparison to the wait method. I am making this comparison because the join method calls the wait method internally.

Wait() : If a thread calls wait method on an object (obliviously that thread must already have acquired the lock of the object it is calling the wait method on, otherwise a runtime exception is thrown), that thread releases the object and goes to the waiting state. So in all the wait call forces the thread to release the object it is calling wait on.

Join() : If a thread (name it T1) calls the join method on another Thread (remember the wait method is in the Object class and the join method is specific to the Thread class and is present in the Thread class) named T2, then T1 waits for T2 to complete its execution before it continues from that point. Now think what will happen. Will thread T1 leave the locks on the object it has acquired lock on or not ? If we consider the fact that the join method internally calls the wait method the answer that pops up immediately is that “obviously it should leave the lock“, which is WRONG !!!!

For a moment lets assume this answer is correct. Now imagine the scenario, where the thread T1 has called this wait inside a synchronized lock where it has acquired a lock on a String object “abc” and has called the T2.join() inside this block. Now as this call has been made by T1 inside the synchronized block, it obviously means that it needs the lock on the “abc” object to continue the execution further. If T1 has released the lock on “abc” object it will be rescheduled by the thread scheduler to acquire lock on “abc”. But it is not guaranteed tha it will acquire the lock as soon as the thread T2 completes. So in this case some other thread T3 might acquire the lock on “abc” and enter the same synchronized block which the thread T1 already half way !!!! So if the join method makes the calling thread leave the locks, then whole whole use of the synchronized block is ruined.

Wait() inside Join() mystery : The wait method call in side the join method implementation is being called on “this” i.e the thread on which join was called (T2). That wait call does not have to do anything with the calling thread (T1). That means the join call does not causes the calling thread to release a lock on any object and it simply makes it wait till the thread it called join on completes its execution keeping all the locks it already acquired.

I tried the above theory with the following example code:

class AThread extends Thread
{

public void run()
{

System.out.println(“T2 started”);
synchronized (Test2.lock)

{

System.out.println(“Hi hello”);

}

}

}

public class Test implements Runnable
{

public static final String lock = “lock”;
public static final String lock1 = “lock1″;
static Test t = new Test();
static Thread T1 = new Thread(t, “Thread T1″);
static AThread T2 = new AThread();

public static void main(String[] args)
{

T1.start();
Thread.yield();
T2.start();

}

public void run()
{

synchronized (lock)

{

System.out.println(“T1 started”);
try
{

System.out.println(“waiting for T2 to join”);
T2.join();

}
catch (InterruptedException e)
{

System.out.println(“e.getMessage() = ” + e.getMessage());

}
System.out.println(“T1 ended”);

}

}

}

Running the above program produces the following output:

T1 started
T2 started
waiting for T2 to join

And the execution locks here as Thread T2 tries o acquire lock on the “lock” object which has already been acquired by thread T1 and as T1 has called join on T2, T1 does not leave the lock on the “lock” object and thus a deadlock occurs.

Note: The call to the yield() between the cal to the start() method of T1 and T2 is just to increase the possibility of starting the T1 thread and go a lil ahead on the execution line before the ThreadT2 is started. If the thread T2 starts first, then there would br no deadlock here as the lock will be gained by thread T1 and the execution will complete smoothly. Remember the above example is a 99% deadlock situation and so you should always avoid such situations.

Posted in Java. 2 Comments »