Saturday, November 28, 2009

Why String has been made immutable in Java?

Why String has been made immutable in Java?

Though, performance is also a reason (assuming you are already aware of the internal String pool maintained for making sure that the same String object is used more than once without having to create/re-claim it those many times), but the main reason why String has been made immutable in Java is 'Security'. Surprised? Let's understand why.

Suppose you need to open a secure file which requires the users to authenticate themselves. Let's say there are two users named 'user1' and 'user2' and they have their own password files 'password1' and 'password2', respectively. Obviously 'user2' should not have access to 'password1' file.

As we know the filenames in Java are specified by using Strings. Even if you create a 'File' object, you pass the name of the file as a String only and that String is maintained inside the File object as one of its members.

Had String been mutable, 'user1' could have logged into using his credentials and then somehow could have managed to change the name of his password filename (a String object) from 'password1' to 'password2' before JVM actually places the native OS system call to open the file. This would have allowed 'user1' to open user2's password file. Understandably it would have resulted into a big security flaw in Java.
I understand there are so many 'could have's here, but you would certainly agree that it would have opened a door to allow developers messing up the security of many resources either intentionally or un-intentionally.

With Strings being immutable, JVM can be sure that the filename instance member of the corresponding File object would keep pointing to same unchanged "filename" String object. The 'filename' instance member being a 'final' in the File class can anyway not be modified to point to any other String object specifying any other file than the intended one (i.e., the one which was used to create the File object).

Liked the article?
Subscribe to this blog for regular updates. Wanna follow it to tell the world that you enjoy GeekExplains? Please find the 'Followers' widget in the rightmost sidebar.


Tuesday, November 17, 2009

Memory Leak in Java? Does 'static' cause it?

Does 'static' cause Memory Leak in Java?

What's memory leak? In simple terms, it's unused but referenced (somehow because the programmer probably unintentionally forgot to remove the references once the use of the object was over) part of the memory. Before we start discussing if 'static' can cause memory leak in Java, let me assure you that whatever you've read about Garbage Collectors in Java, is still valid and it certainly takes care of most (almost all) of the memory allocation/reclaimation of Java objects. But, that alone doesn't remove the possibility of the presence of memory leak in a Java program - just for example, you might not only be using only Java objects in your Java program. Putting it differently, what if you have used some native objects and forgot to reclaim the memory explicitly because that's anyway not going to be taken care by the GC (which takes care of heap memory management only)... right?

Now that we agree with the possibility of a Java program having potential memory leaks, let's see if using 'static' can also be one of the potential reasons for memory leaks in Java.

How to find if your Java program contains Memory Leaks?

Well... the programmer should have kept their eyes open while development itself. Once the app is ready, one may like to use Profilers (available from many vendors) to analyze the object graphs.

If your Java app is usually crashing with 'OutOfMemoryError' after executing for a while then it should ring an alarm for the possibility of memory leaks in your app. Though, this doesn't necessarily mean your app is having memory leaks, it might be possible that the allocated heap space is not enough for the proper functioning of your app.

Does 'static' cause memory leak in Java?

'static' can't straightway be blamed for causing memory leaks. But, if the programmer has not well thought the usage and has not taken care of the setting the references to 'null' explicitly after using the static objects then they can definitely cause memory leaks. Let's see how.

As you know 'static' members will by default live for the entire life of an app unless they are explicitly set to 'null'. So, always make it a point to nullify the references as soon as you reach at a point in your code where the use of the static member is over. For example: suppose you have created a 'Statement' object from a DB Connection and the connection is a pooled one. Now as you know calling close() method on a pooled connection will not actually close the connection instead it will return the Connection object to the pool to be re-used. So, in such a case unless you explicitly close the 'Statement' object, it would keep consuming precious memory space for no real use. Just think the scenario where you have declared the 'Statement' object as a static member, it'll be maintained in the memory for the entire life time of the app even when the control is out of the scope. It's just a sample scenario and many of you might never have used 'Statement' object in such an irresponsible manner. It's just an attempt to show how the 'static' can be misused to cause memory leaks in Java.

Not that if your Statement object is non-static you should reply on the out-of-scope nullification (i.e., as soon as control is out of scope the local objects would be marked for re-claimation) as in case you still have a significant amount of code (in terms of time/space) after using the Statement last and before reaching the end of the local scope, it would be a sheer wastage of memory if you don't explicitly nullify the 'Statement' after its use is over. Such a scenario should also be thought of as memory leaks only and one should always make sure the nullification of resources is as close to their last usage as possible.

Therefore, in summary we can say that one should/must :-

  • always think if you really need to make this variable/member a 'static' one?
  • always try to confine the scope of an object to restrict its usage only to the section it's actually needed
  • always make a conscious effort to explicitly nullify objects once you finish using them (especially the large objects)

Liked the article? Subscribe to this blog for regular updates. Wanna follow it to tell the world that you enjoy GeekExplains? Please find the 'Followers' widget in the rightmost sidebar.


Thursday, October 29, 2009

Marker Interface in Java: what, why, uses, etc.

What are Marker Interfaces in Java?

An empty interface having no methods or fields/constants is called a marker interface or a tag interface. This of course means if the interface is extending other interfaces (directly or indirectly) then the super interfaces must not have any inheritable member (method or field/constant) as otherwise the definition of the marker interface (an entirely empty interface) would not be met. Since members of any interface are by default 'public' so all members will be inheritable and hence we can say for an interface to be a marker interface, all of its direct or indirect super interfaces should also be marker. (Thanks marco for raising the point. I thought it was obvious, but mentioning all this explicitly would probably help our readers.)

There are few Java supplied marker interfaces like Cloneable, Serializable, etc. One can create their own marker interfaces the same way as they create any other interface in Java.

Purpose of having marker interfaces in Java i.e., why to have marker interfaces?

The main purpose to have marker interfaces is to create special types in those cases where the types themselves have no behavior particular to them. If there is no behavior then why to have an interface? Because the implementor of the class might only need to flag that it belongs to that particular type and everything else is handled/done by some other unit - either internal to Java (as in the case of Java supplied standard marker interfaces) or an app specific external unit.

Let's understand this by two examples - one in which we will discuss the purpose of a standard Java interface (Cloneable) and then another user-created marker interface.

What purpose does the Cloneable interface serve?

When JVM sees a clone() method being invoked on an object, it first verifies if the underlying class has implemented the 'Cloneable' interface or not. If not, then it throws the exception CloneNotSupportedException. Assuming the underlying class has implemented the 'Cloneable' interface, JVM does some internal work (maybe by calling some method) to facilitate the cloning operation. Cloneable is a marker interface and having no behavior declared in it for the implementing class to define because the behavior is to be supported by JVM and not the implementing classes (maybe because it's too tricky, generic, or low-level at the implementing class level). So, effectively marker interfaces kind of send out a signal to the corresponding external/internal entity (JVM in case of Cloneable) for them to arrange for the necessary functionality.

How does JVM support the 'cloning' functionality - probably by using a native method call as cloning mechanism involves some low-level tasks which are probably not possible with using a direct Java method. So, a possible 'Object.clone' implementation would be something like this:-

public Object clone() throws CloneNotSupportedException {

if (this implements Cloneable)

return nativeCloneImpl();


throw new CloneNotSupportedException();


Anyone wondered as to why and when do we get 'CloneNotSupportedException' exception at compile-time itself? Well... that's no trick. If you see the signature of the 'Object.clone()' method carefully, you will see a throws clause associated with it. I'm sure how can you get rid of it: (i) by wrapping the clone-invocation code within appropriate try-catch (ii) throwing the CloneNotSupportedException from the calling method.

What purpose does a user-defined marker interface serve? It can well serve the same purpose as by any standard marker interface, but in that case the container (the module controlling the execution of the app) has to take the onus of making sure that whenever a class implements that interface it does the required work to support the underlying behavior - the way JVM does for Cloneable or any other standard marker interface for that matter.

Defining an user-defined marker interface in Java

Let's define a user-defined marker interface. Let's say there is an app suporting a medical store inventory and suppose you need a reporting showing the sale, revenue, profit, etc. of three types of medicines - allopathic, homeopathic, and ayurvedic separately. Now all you need is to define three marker interfaces and make your products (medicines) implement the corresponding ones.

public interface Allopathic{}
public interface Homeopathic{}
public interface Ayurvedic{}

In your reporting modules, you can probably get the segregation using something similar to below:-

for (Medicine medicine : allMedicines) {
if (medicine instanceof Allopathic) {
//... update stats accordingly
else if (medicine instanceof Homeopathic) {
//... update stats accordingly
else if (medicine instanceof Ayurvedic) {
//... update stats accordingly
else {
//... handle stats for general items

As you can see the medicines themselves don't need to implement any specific behavior based on whether they are allopathic, homeopathic, or ayurvedic. All they need is to have a way of reflecting which category they belong to, which will in turn help the reporting modules to prepare the stats accordingly.

Now this can be done by having a flag as well... yeah, sure it can be. But, don't you think tagging a class makes it more readable than having a flag indicating the same. You kind of make it an implementation-independent stuff for the consumers of your classes. If your class implements an interface, it becomes part of the class signature of the published API. Otherwise, you would probably handle the situation by having a public final field having the flag set up at the time of instantiation - final because you would not like others to change it. I guess going the marker interface way would probably make more sense in many such situations.

Another advantage of going via marker interface way is that at any point of time you can easily cast the objects of the implementing classes. Again it's not that if you go via public final approach, you can't do that. You can very well do, but casting might look a cleaner approach in many situations.

The bottom-line is there will hardly be any enforced need for a designer/developer to go via that way as there can be possible alternatives, but marker interfaces can surely be a preferred choice for some in some cases.

Note: Annotations are considered as another possible (quite popular as well) alternative to marker interfaces. Read more about them in this article - Annotations in Java >>

Liked the article? Subscribe to this blog for regular updates. Wanna follow it to tell the world that you enjoy GeekExplains? Please find the 'Followers' widget in the rightmost sidebar.


Tuesday, October 13, 2009

Connecting to an HTTP Web Service from VBA via Proxy

Connecting to an HTTP Web Service from VBA Excel via a Proxy Server

Though MSDN suggests using stubs generated from the WSDL by MS Soap Toolkit for connecting to an HTTP Web Service from within VBA Excel, but it might not work as you would like it to, especially for a SOA-compliant web service and particularly in the cases where you need to access the service via a Proxy Server.

I have used the SOAP Connector called 'httpConnector30' successfully to connect to an HTTP Web Service without any issues. This connector is a part of the Microsoft SOAP Library named MSSOAPLib30 and you got to make sure that this library is referenced in your Excel installation. If it's not already there in your excel, just add the corresponding DLL and you're done.

Using httpConnector30 is different from consuming a Web Service by creating the stubs using MS Soap Toolkit. 'httpConnector30' requires you to specify the actual Web Service URL whereas the toolkit asks you the WSDL url and creates stubs accordingly, which you use in your VBA code. I personally think using 'httpConnector30' is easier and more straightforward if you have the service url.

Before we jump on to the code listed below, let's understand what all the code does broadly:-

  • Instantiating the SOAP Connector
  • Setting up the Proxy Server and Port (if access needed via Proxy)
  • Setting up the Web Service URL (not WSDL url)
  • Setting up Timeout period for the service call
  • Setting up the SOAP Action i.e., the actual method to be called
  • Beginning SOAP Message and getting connector's Input Stream
  • Building up the SOAP Request (as per your Web Service definition)
  • Sending the SOAP Message (this is where the service call is made)
  • Initializing the SOAP Reader and reading the SOAP Response
Note: in the below code I have not shown the exception handling blocks, which you should include to grab and handle the potential errors gracefully. For example: you should first check the 'connector' as 'Not Nothing' before trying to load the 'reader' with connector's output stream.

Additionally, I've assumed that the first node (except the generic envelope and body) of the SOAP Response is actually a List and hence I've put a loop to iterate through it. 'Set response = reader.RPCResult.childNodes' actually sets the 'response' to the first node of the SOAP Response as read from the reader (which itself is loaded with the connector's output stream).

Just to make your service consumption code robust and independent of the Response Structure changes (like addition of new nodes and/or reordering of nodes), in your client code, you should iterate through all the SOAP Response nodes and compare the current node name with your Service Response node names (you can get them in the service WSDL) and subsequently handle the particular node, say inside an if-block. This will make sure that your code doesn't fail abruptly in case Service Response Structure changes. For example: it will avoid any code failure say because you had written it assuming the first node in the response was a List and let's say the service response structure changes make it the second node in the response - maybe because the service provider needed to add another field in the response and also wished to make that the first field. I know the service provide will certainly let the client developers know about the changes, but if you make your code flexible to such possible changes, nothing like it... right?

Public Sub HTTPConnectivityTest()

'Instantiating the SOAP Connector
Dim connector As New MSSOAPLib30.HttpConnector30

'Setting up the Proxy Server and Port
connector.Property("ProxyServer") = "fully-qualified-proxy-server-or-IPAddress:Port"

'Setting up the Web Service URL
connector.Property("EndPointURL") = "http://web-service-server:port/webservices/SampleService.v1"

'Setting up Timeout period for the service call
connector.Property("Timeout") = 2000 '2 minutes

'Setting up the SOAP Action i.e., the actual method to be called
connector.Property("SoapAction") = "urn:getSampleData"

'Beginning SOAP Message

'Initializing SOAP Serializer with connector's input stream
Dim writer As New MSSOAPLib30.SoapSerializer30
writer.Init connector.InputStream

'Building the SOAP Request - envelope and body
writer.startEnvelope ' <SOAP-ENV:Envelope>
writer.startBody ' <SOAP-ENV:Body>

'Populating the SOAP Request with actual input parameters
writer.startElement "SampleServiceRequest", "service namespace", , "s3" ' <SampleServiceRequest>

writer.startElement "inputParam1" ' <inputParam1>
writer.writeString "param1 value" ' value of inputParam1
writer.endElement ' </inputParam1>

writer.startElement "inputParam2" ' <inputParam2>
writer.writeString "param2 value" ' value of inputParam2
writer.endElement ' </inputParam2>

writer.startElement "inputParam3" ' <inputParam3>
writer.writeString "param3 value" ' value of inputParam3
writer.endElement ' </inputParam3>

'Populating list-type parameter
writer.startElement "paramList" ' <paramList>

'Adding node #1 to the list-type param
writer.startElement "paramListNode" ' <paramListNode>
writer.startElement "nodeParam1" ' <nodeParam1>
writer.writeString "value1" ' value of nodeParam1
writer.endElement ' </nodeParam1>

writer.startElement "nodeParam2" ' <nodeParam2>
writer.writeString "value1" ' value of nodeParam2
writer.endElement ' </nodeParam2>
writer.endElement ' </paramListNode>

'Adding node #2 to the list-type param
writer.startElement "paramListNode" ' <paramListNode>
writer.startElement "nodeParam1" ' <nodeParam1>
writer.writeString "value2" ' value of nodeParam1
writer.endElement ' </nodeParam1>

writer.startElement "nodeParam2" ' <nodeParam2>
writer.writeString "value2" ' value of nodeParam2
writer.endElement ' </nodeParam2>
writer.endElement ' </paramListNode>

'Population of list-type param ends here
writer.endElement ' </paramList>

'Finishing the SOAP Request
writer.endElement ' </SampleServiceRequest>
writer.endBody ' </SOAP-ENV:Body>
writer.endEnvelope ' </SOAP-ENV:Envelope>

'Sending the SOAP Message (this is where the service call is made)

'Defining SOAP Reader and initializing it with connector's output stream
Dim reader As New MSSOAPLib30.SoapReader30
reader.Load connector.OutputStream

'Parsing the SOAP Response
Dim response As MSXML2.IXMLDOMNodeList

'Setting the response to the first node of the SOAP Response
Set response = reader.RPCResult.childNodes
Dim node As MSXML2.IXMLDOMNode

'Iterating through the first node of SOAP Response knowing it is a list
For Each node In response
Dim nodeName As String
Dim nodeValue As String

nodeName = node.nodeName
nodeValue = node.nodeTypedValue

'Showing the Node Name and Value on Alert Boxes
MsgBox node.nodeName & ": " & node.nodeTypedValue
Next node
End Sub

Liked the article? Subscribe to this blog for regular updates. Wanna follow it to tell the world that you enjoy GeekExplains? Please find the 'Followers' widget in the rightmost sidebar.


Sunday, October 11, 2009

Why wait(),notify() and notifyAll() in the Object class?

Why wait(), notify() and notifyAll() methods have been defined in the Object class?

Java concurrency model uses locks to implement mutually exclusive access to objects in a multi-threaded environment and locks are associated with every object in Java (of type 'Object'), not only with Threads.

, notify/notifyAll methods are used by threads to communicate with each other while trying to access a common object. Putting it differently, objects become a medium via which threads communicate with each other. For example: suppose there is a 'telephone' object, which at one point of time can be used by only one thread. Like every other object in Java, 'telephone' object would also have an intrinsic lock (monitor) associated with it which at one point of time can be acquired by only one thread. Suppose the 'telephone' object requires activation before it can be used and suppose only a few admin threads can activate the 'telephone' object.

As soon as a thread needs access to the 'telephone' object, it checks if the lock on that 'telephone' object is available or not, if yes, it acquires that and checks if the 'telephone' is active or not. If yes, it starts using it otherwise it calls 'wait()' on the telephone object which effectively releases the monitor of the 'telephone' object (eventually to be acquired by one of the admin threads for its activation) and puts the requester thread into the wait-set of the 'telephone' object. The requester thread goes into WAITING state. The way every object in Java has an intrinsic lock associated with it, it has an intrinsic wait-set associated with it as well.

Every other non-admin requester thread goes through the same process as discussed above till one of the admin threads acquire lock on the 'telephone' object and eventually activates it and subsequently calls 'notify()' or 'notifyAll()' on the 'telephone' object. 'notify()' will simply pick one of the threads from the wait-set of the 'telephone' object (which one will be picked is an implementation dependent stuff and Java Language specification doesn't enforce any restriction on which one to be picked) and the chosen thread will now get out of WAITING mode and start trying to acquire the monitor/lock of the 'telephone' object along with any other thread that might be vying to access the 'telephone' at that point of time.

The only difference between 'notify' and 'notifyAll' is that in case of the latter all the threads of the corresponding wait-set are picked and they all start trying to acquire the lock on the object (with any other incoming requester thread) at the same time.

Evidently you see that these three methods are essentially object-related and not thread-related and hence the designers of Java Language considered it wise to put them in the Object class instead of putting them into the Thread class. The usage of the 'object' (in our case 'telephone') is the particular object's prerogative and not that of the requester threads'. Putting these three methods in the Object class helps the objects owning/controlling their usage in a better way as in that case a thread needs to first acquire the lock on the object (kind of getting a license to use the object) and then calling either wait (in case the thread doesn't find the object in the state it would have wished it to be in and hence thought of waiting for some time to let the object become useful for it) or notify/notifyAll to alert other threads waiting on the object once it finishes using the object (of course in the case when the thread find the object useful in its current state).

Additionally, the communication among the interested threads becomes far too easier when the control is kept at the object's level - one common shared resource/medium and all interested threads communicating via it. Not that the communication won't be possible if these methods are kept in the Thread class, but the handling of the communication and usage of the objects in a multi-threaded environment will probably become more complex and less flexible in that case.

Liked the article? Subscribe to this blog for regular updates. Wanna follow it to tell the world that you enjoy GeekExplains? Please find the 'Followers' widget in the rightmost sidebar.


Monday, August 3, 2009

per-thread Singleton and per-thread Logging in Java

Usage of ThreadLocal: per-thread Singleton and per-thread Logging

Should you require a refresh of what ThreadLocals in Java are and how they work, refer to this article first. You can then proceed with the current article for understanding two of the most common uses of ThreadLocals in Java.

per-thread Singleton impl using ThreadLocal

Suppose you have a need of having a JDBC Connection objects per thread of your application. The moment you hear the term 'per-thread', ThreadLocal automatically comes into mind as that's what it's primarily meant for. Below is a sample implementation of how easily can you actually use ThreadLocal for a per-thread JDBC Connection object in Java.

public class ConnectionDispenser {

private static class ThreadLocalConnection extends ThreadLocal {

public Object initialValue() {

return DriverManager.getConnection(ConfigurationSingleton.getDbUrl());



private static ThreadLocalConnection conn = new ThreadLocalConnection();

public static Connection getConnection() {

return (Connection) conn.get();



Most of the code is self-explanatory and you can easily see how overriding the 'initialValue()' method of ThreadLocal is doing the trick of getting a Connection object by calling 'getConnection' method of the 'DriverManager' class. As you know the 'initialValue()' method is called only once for a ThreadLocal object and hence the Connection object will be obtained only once per thread (as a ThreadLocal object is created per thread only). From then on, whenever the particular thread requires the Connection object it simply calls the static 'getConnection' method of the your 'ConnectionDispenser' class, which in turn calls the 'get()' method of ThreadLocal to fetch the Connection object associated with that particular thread.

per-thread Debug Logging impl using ThreadLocal

Ever thought of having a per-thread DEBUG logging for any of your applications? Few multi-threading applications do get trickier at times and having per-thread DEBUG logs might be of great help in such situations as you probably can't visualize the actual order in which the threads might have executed and changed the shared objects. Here goes a sample implementation of per-thread DEBUG logging in Java using ThreadLocal.

public class DebugLogger {

private static class ThreadLocalList extends ThreadLocal {

public Object initialValue() {

return new ArrayList();


public List getList() {

return (List) super.get();



private ThreadLocalList list = new ThreadLocalList();

private static String[] stringArray = new String[0];

public void clear() {



public void put(String text) {



public String[] get() {

return list.getList().toArray(stringArray);



As you can identify we are using an ArrayList object to store the logging info for a thread. 'initialValue' has been overridden to initialize every thread with a new ArrayList object. Whenever your multi-threaded application calls the 'put' method of your 'DebugLogger' class then all that method does is that it adds the logging info (passed as an String parameter to the 'put' call) to the corresponding ArrayList object of the current thread. Similarly a 'get' call of your 'DebugLogger' class simply returns the associated ArrayList object of the current thread in form of an String array. Evidently the 'clear' method of your 'DebugLogger' class is for clearing the logging info captured so far for the current thread - it'll simply clear the ArrayList object holding logging info for the current thread. This might help you getting rid of the non-essential logging info, maybe based on some condition, when you know for sure that all that you need for your debugging is what you are going to capture next and now what has already been captured so far.

Source: a nice article on ThreadLocals in Java, which I thoroughly enjoyed.

Liked the article? Subscribe to this blog for regular updates. Wanna follow it to tell the world that you enjoy GeekExplains? Please find the 'Followers' widget in the rightmost sidebar.


Thursday, June 18, 2009

Choosing the Most Specific Method - Tricky Overloading

Choosing the Most Specific Method - Tricky Method Overloading

Let's start with looking at a code-segment and try to think of the output/error, it would produce when compiled/executed and subsequently we'll discuss the behavior of code.

public class NullTest {

public static void method(Object obj){
System.out.println("method with param type - Object");

public static void method(String obj){
System.out.println("method with param type - String");

public static void main(String [] args){

So, what do you expect as the output here? Before thinking about the output, do you really expect the code to compile successfully? Well... yeah, the code will compile and run fine as opposed to anyone who might have sensed an ambiguity here - we'll see the reason soon.

Since the methods are overloaded, the resolution will be done at compile-time only. Which method do you see being bind here - the one with parameter type 'Object' or the one with parameter type 'String' and why? Of course, the compiler can't bind two methods with one call, so on what basis would it pick the most suitable? Which method would be picked, is evident from the output given below:-

method with param type - String

Any guesses for why a special treatment is being given to 'String' here? Well... it's not actually for 'String' class specifically, but any sub-class would get a preference over the super class in such a situation. But, why? Because JLS (Section: allows this. It clearly says:

"If more than one member method is both accessible and applicable to a method invocation, it is necessary to choose one to provide the descriptor for the run-time method dispatch. The Java programming language uses the rule that the most specific method is chosen."

As you easily deduce that the compiler should be able to pick 'the most specific', failing which it will throw a compile-time error. Let's understand it with the below code-segment which doesn't compile because the compiler can't pick 'the most specific' here.

public class NullTest {

public static void method(Object obj){
System.out.println("method with param type - Object");

public static void method(String str){
System.out.println("method with param type - String");

public static void method(StringBuffer strBuf){
System.out.println("method with param type - StringBuffer");

public static void main(String [] args){
method(null); //... compile-time error!

Why is the compiler not able to pick 'the most specific' here - because both String and StringBuffer are are sub-classes of the Object class, but without being in the same inheritance hierarchy. For finding 'the most specific' method, the compiler needs to find a method having the parameter type, which is a sub-class of the parameter types of all other overloaded methods.

This holds true for overloaded methods having more than one parameters as well. The compiler would pick 'the most specific' by looking which method is having at least one of its parameter types as a clear sub-class of the corresponding parameter type and other parameter types being either the same or clear sub-classes, in all other overloaded methods. If it can find one, good, otherwise it will throw a compile-time error. For example:

public class NullTest {

public static void method(Object obj, Object obj1){
System.out.println("method with param types - Object, Object");

public static void method(String str, Object obj){
System.out.println("method with param types - String, Object");

public static void main(String [] args){
method(null, null);


method with param types - String, Object

In this case the compiler can easily pick 'the most specific' as the method having parameter types (String, Object) as the other overloaded method is having its parameter types as (Object, Object) - clearly 'String' is a subclass of 'Object' and the other parameter is of same type, so the method with parameter types (String, Object) can be picked with ease. But, the below code would throw a compile-time error as none of the methods satisfy the condition for being picked as 'the most specific' method.

public class NullTest {

public static void method(Object obj, String obj1){
System.out.println("method with param types - Object, String");

public static void method(String str, Object str1){
System.out.println("method with param types - String, Object");

public static void main(String [] args){
method(null, null); //... compile-time error!

Before I conclude let me thank Ranvijay (one of our regular visitors), who inquired about the underlying reason of this behavior via an email. I thought it would probably be helpful to other visitors as well and hence posted a full article. Keep contributing Ranvijay!

Liked the article? Subscribe to this blog for regular updates. Wanna follow it to tell the world that you enjoy GeekExplains? Please find the 'Followers' widget in the rightmost sidebar.


Thursday, June 11, 2009

Initializer Blocks & their alternatives in Java

Initializer Blocks in Java and their possible alternatives

Initializer Blocks - what are they, why & how are they used?

These blocks are similar to the static initialization blocks with the only difference being the absence of the 'static' keyword. The Java compiler copies all the initializer blocks in the same order as they are in the source code in every constructor before any executable statement in that constructor.

public class InitializationWithInitializerBlock{

public static int staticIntField = 100;
private boolean instanceBoolField;

boolean y;

y = true; //or, y = <some expression returning a boolean value>;

instanceBoolField = y;

So if you see all your constructors having same code-segment at the top then you will probably be better off keeping that in an initializer block as anyway the compiler would copy the block in every constructor at the top. This way you can at least make the code more readable, maintainable (as the common code will only be at one place), and if the size of common code is significant and if you have multiple constructors then using initializer block you can also reduce the size of your source code.

public class InitializerBlocks {

public static void main(String[] args) {
new InitializerBlocks();
//Constructor - 1
public InitializerBlocks(){
//Initializer Block - 1
//Initializer Block - 2



(Of course the above code is not making a good use of initializer blocks as they not initializing anything what they are actually meant to. The purpose here is just to show how a Java compiler places all the initializer blocks at the top in every constructor in the same order as they appear in the code.)

Alternative to Initializer Blocks in Java

You can use an instance method to initialize an instance field - in most of the cases you would like to make this instance method as 'final' as there will hardly be any need for the subclasses to override such a method (evidently, a non-final instance method would also do the job). Similarly if you need to call the method only from within the same class, you would probably make it 'private'.
Read more about how to pick access modifiers - choosing suitable access control modifiers in Java >>

public class InitializationWithPrivateInstanceMethod{

public static int staticIntField = 100;
private boolean instanceBoolField = privInstanceMeth();

private final boolean privInstanceMeth() {
boolean y;
//computing the value of y
y = <some expression returning boolean>;
return y;

The advantage of using an instance method over an initializer block is that it gives you flexibility of re-initializing those instance fields by calling the corresponding final instance method(s) in some setter or in some other method. Another interesting scenario where you can't use an initializer block and you would probably need an instance method to do it for you: Suppose you have a need of using the code of initializer block in any of your sub-classes and suppose all your constructors have extra code as well in addition to the initializer block code which would be added to them on the top during compilation. Now in such a situation, if you need to set only those fields which are set in the initializer block then you can't do that directly in your subclass as the most you can do here is to call a super class constructor (that too would normally re-set all the instance fields) ... right? Having a final instance method would solve your problem here. Choosing a suitable access specifier will again follow the same rules what has been discussed in article mentioned in above paragraph. In this case since the sub-classes require access to that method, so choosing 'protected' as the access specifier should be fine.

Liked the article? Subscribe to this blog for regular updates. Wanna follow it to tell the world that you enjoy GeekExplains? Please find the 'Followers' widget in the rightmost sidebar.


Sunday, June 7, 2009

Static Initialization Blocks & their alternatives

Static Initialization Blocks and their alternatives in Java

Why do we need Static Initialization Blocks?

The easiest way of initializing fields (static or instance) in Java at the time of their declaration is simply by providing a compile time constant value of a compatible data type. For example:

public class InitializationWithConstants{

public static int staticIntField = 100;
private boolean instanceBoolField = true;


This type of initialization has its limitation due to its simplicity and it can not support initialization based even on some moderately complex logic - like initializing only selected elements of a complex array using some logic in a for loop.

Here comes the need for static initialization blocks and initializer blocks for initializing static and instance fields, respectively.

Static Initialization Blocks - what are they and how to use them?

It's a normal block of code enclosed within a pair of braces and preceded by a 'static' keyword. These blocks can be anywhere in the class definition where we can have a field or a method. The Java runtime guarantees that all the static initialization blocks are called in the order in which they appear in the source code and this happens while loading of the class in the memory.

public class InitializationWithStaticInitBlock{

public static int staticIntField;
private boolean instanceBoolField = true;

//compute the value of an int variable 'x'
staticIntField = x;

Since static initialization blocks are actually code-blocks so they will allow us to initialize even those static fields which require some logical processing to be done for them to get their initial values.

Alternative to Static Initialization Blocks

A private static method is a suitable alternative to the static initialization blocks. In fact it has some advantages over static initialization blocks as well like you can re-use a private static method to re-initialize a static field in case you need it. So, you kind of get more flexibility with a private static method in comparison to the corresponding static initialization block. This should not mislead that a 'public' static method can't do the same. But, we are talking about a way of initializing a class variable and there is hardly any reason to make such a method 'public'.
More about how to pick the access control modifiers here - Choosing a suitable access control modifier >>

public class InitializationWithPrivateStaticMethod{

public static int staticIntField = privStatMeth();
private boolean instanceBoolField = true;

private static int privStatMeth() {
//compute the value of an int variable 'x'
return x;

Liked the article? Subscribe to this blog for regular updates. Wanna follow it to tell the world that you enjoy GeekExplains? Please find the 'Followers' widget in the rightmost sidebar.


Saturday, May 30, 2009

Choosing a suitable access control modifier in Java

How to choose a suitable access control specifier of a method or a field?

Access Control Modifiers available for classes and members in Java

Top-level classes in Java can have only two access control modifiers - public and default (package-private) whereas the members have four access control modifiers - public, protected, default (package-private), and private. Nested Classes are treated as members of the top-level classes so all four access control modifiers are applicable to them.

Choosing suitable access control modifier for methods in Java?

Here I'm assuming that your top-level (i.e., a class which is not nested) class is 'public' as otherwise if it's having the default access control modifier then you would probably never make any member public or protected owning to the fact the class itself can't be used outside the package.

When to pick 'public' as the access control modifier?

How do you normally go about choosing the access specifier/modifier of a method in your class definition - whether you start from 'public' and move on to 'private' to see which specifier would actually suit the requirements or do you go about the other way round? It probably makes more sense to go the other way - starting from 'private' and moving onto 'public'. There should be a very strong reason why you would need a method to make 'public' as it would then become a part of the public interface of the class - a commitment from the class designer to all (those who are already consuming or those who would be consuming in future).

Therefore, choosing 'public' as the access specifier should be given a thorough review as consumers of the class can (which they normally do) use them in their implementation and hence once you make something public you got to support that for the consumers of your class till eternity (making a 'public' member deprecated and subsequently getting rid of it will be a difficult and time consuming exercise). A big ask especially in a professional environment where your class is being consumed by many critical applications. So as a thumb rule make only those members 'public', which you can't make either 'private', 'package-private (default)' or 'protected'.

When to pick 'protected' as the access control specifier?

A 'protected' modifier specifies that the member can be accessed from within the same package as well as by a sub-class in some other package.

Let's pick the suitable access modifier for a member which you want any of your sub-classes to have access to. Of course you can't choose 'private' here as the access will then be limited to your class only. Next up the ladder is 'package-private (default)' which will restrict the access limited to all the classes (either a sub class or not) in the same package only. But, if you want any sub class of your class to access the member then the default access modifier won't do it for you. Next up the ladder is 'protected' which suits fine here so no need to go further up. Quite simple to pick the suitable access modifier, isn't it?

Making something 'protected' also puts you in some sort of commitment in case you are not making your class as 'final' as otherwise the sub-classes of your class may write their implementation based on the availability of your 'protected' member. You have to be careful with the fact that the 'protected' members can be used by any class in the same package, so even if you have made your class as 'final' the commitment to make the 'protected' members available to all the classes in the same package still remains.
But, why would you come up with such a design? If you want the member to be accessible only from within the same package, better make it package-private (default). Making a class 'final' which is having 'protected' members would certainly draw attention as to why would anyone like to do it. You would better need to review the class design in such a case.

When to pick default access control modifier?

'package-private' or the default access control modifier puts you under only one commitment. This is towards all the classes in the same package as they will have access to all your package-private members and hence they can have their implementation dependent on those members.

When to pick 'private' access control modifier?

'private' is something private to your class and hence you have no commitment towards others. You can change them anytime you want as long as it doesn't hurt the functioning of any public/protected/default member.

How to pick access control modifier for fields in Java?

For fields, the thumb rule is quite simple - make all instance fields 'private' and have getters/setters to access/modify them. However, you would probably like to make most of your static fields as 'public' as they are class variables and meant to be accessed from outside either on the class name (preferred way) or on any instance.

Liked the article? Subscribe to this blog for regular updates. Wanna follow it to tell the world that you enjoy GeekExplains? Please find the 'Followers' widget in the rightmost sidebar.


Friday, May 29, 2009

Finding caller of an instance or static method in Java

Finding Caller object, method/class of an instance method in Java

You might think if we would ever need it? Well... you may never, but no harm in exploring whether we have any/some ways of finding this in Java or not. This question was asked by one of our visitors - Marco Servetto. Thanks Marco for bringing this question up.

For instance methods, by caller you might mean either the object instance of the caller/calling method or method/class name of the caller/calling method. But, for static methods the caller will never be an instance, but only the other two (method/class).

In case of a static method, we don't have the implicit object reference (this) passed to them as they are never called on instances (even if you call static methods on object references, the call is actually resolved at compile time only and is made on the declared type of the object reference). And hence for them the caller will never be an instance.

If we are interested in finding the object associated with the calling method inside the called method then the most obvious way is to pass the reference 'this' to the called method while making the call in the calling/caller method. I doubt if we have any other JVM implementation independent way of doing this. Better to understand it by code, which is pretty simple and straightforward.

public class FindingCallerDemo {

public static void main(String[] args) {
new CallerClass().callerMethod();
class CallerClass{
public void callerMethod(){
Object returnedObj = new CalledClass().calledMethod(this);
//assert returnedObj == this;
if (returnedObj == this)
class CalledClass{
public Object calledMethod(Object obj){
return obj;

By caller if we mean the name of the caller method name OR the name of the class of the caller method then we can probably use the getStackTrace() method either on current thread instance or on a Throwable instance:
  • Using getStackTrace on current thread (since Java 1.5) - 'StackTraceElement[] stackTraceElements = Thread.currentThread().getStackTrace()' - we can use this to get the stack trace of the current thread in a StackTraceElemnt array where the first element of the array is the most recent method invocation sequence on the stack - provided the returned array is of non-zero length. StackTraceElement has methods like getClassName, getMethodName, etc., which one can use to find the caller class name or method name.
  • Calling getStackTrace on a Throwable instance (since Java 1.4) - creating an instance of Throwable and then calling getStackTrace() method on it, will return an array of StackTraceElement, each of which will contain one stack frame each with the first element containing the most recent inovaction and the last having the least recent. You don't really need to throw the Throwable instance, only creating one would be good enough here.

StackTraceElement[] ste = new Throwable().getStackTrace();
for (int i = 0; i < ste.length; i++)
System.out.println("Class Name: " + ste[i].getClassName()+ ", Method Name: " + ste[i].getMethodName());

Potential Problem:
In certain situations, few JVM implementations may either omit one or more stack frames from the stack trace or they might not have any stack frame info at all related to this Throwable instance as a JVM implementation is allowed to return a zero-length array by Java language specs.

Another possible issue is that compile-time inlining may show skewed results. Say if a method A internally calls another method B and B calls C. Let's suppose the method B has no other executable statement. Obviously this will be a good candidate for compile time inlining as the compiler might replace the call to method B inside method A definition with a call to method C. In such cases, the above two approaches will return the caller method of method C as method A and not as method B what the source code might suggest. Please note that this will require you to turn on the optimization of the compiler. Results may vary across compilers as different compilers may have different criteria for inlining - some might never do.

Other Possible Solutions: there can be some other possible solutions using a native method (like getCallerClass method) of some JVM implementation specific classes. We should avoid such a practice as we may otherwise sacrifice the portability of the code. Even worse, in case the implementation specific class is non-public then you might not use your code on the changed version of the same JVM implementation itself.

Liked the article? Subscribe to this blog for regular updates. Wanna follow it to tell the world that you enjoy GeekExplains? Please find the 'Followers' widget in the rightmost sidebar.


Sunday, May 24, 2009

Passing '\n' (new-line) on command line in Java

Can we pass a new-line ('\n') character or any other escape sequence via command line in Java?

One of our visitors (Vivek Athalye) asked this in response to the article -
Tricky use of static initializer block. Thought of posting the answer as a separate article to increase the chances of it reaching to a wider range of audience.

The answer to the query is NO. The question arises, if you pass the same escape sequence programmtically, it works fine, so why doesn't it work well when passed via command line? For example: System.setProperty("line.separator", " Bye!\nBBye!"); will work fine, but if try to do the same via command line as (java -Dline.separator=" Bye!\nBBye!" ClassName) then '\n' will be treated as two distinct ASCII characters ('\' and 'n') and not as a single escape sequence new-line Unicode character.

This behavior was logged as a
bug on Sun's Bug Database on Oct 31, 2003. But, it was closed saying 'not a bug' on Nov 05, 2003. The reason given is that interpretation of text passed on command line is a shell specific stuff and it is not reasonable to expect that to work in lines with the handling of escape sequences by any particular programming language.

It's not something to do with Java as even if you pass a command line argument having '\n' to a C program, it will be treated as two distinct ASCII characters only and not as a escape sequence.

What stops a shell to interpret escape sequences is that escape sequences are represented differently in different programming languages - like '\n' is actually a single character Unicode character whereas in C it's a two-character ASCII sequence having a different meaning because of the preceding '\' character. So, on a system which requires to run both Java and C programs, which convention should the shell use? Tomorrow, if we see any other representation of escape sequence by some other programming language, how will the already developed shell will cope up with that? Hence, shell plays it straight and simply passes everything written on command line as ASCII character sequences without giving any special meaning to any particular sequence. Fair enough, I believe.

Liked the article? Subscribe to this blog for regular updates. Wanna follow it to tell the world that you enjoy GeekExplains? Please find the 'Followers' widget in the rightmost sidebar.