Java Immutable Object

The simple definition of immutable object is "An object called immutable whose states can't be changed after it constructed". It means every time we need to alter the state we actually end up having a new object. The best example is "java.lang.String".

Some body might be thinking its actually overhead, this practice ends up creating too many objects. Actually over the time with optimization of garbage collection and the cost of creating new objects decreases. So in a situation where you want to define constant, or say a multi threading case immutable objects work well. As the value doesn't change at any stage, we are assured of dirty or inconsistent value.

Lets understand how to create our own immutable object.

1) Make the class final, to stop any other class to extend.

2) All fields in the class should be private and final.

3) Since we don't want the state of the object to change,  there should not be any setter method.

4) Any method which require to change the state, must create a new object with updated state.

For Ex:

final public class MyCar

{

     private final String registrationNumber;

     public MyCar(String registrationNumber)

     {

        this.registrationNumber = registrationNumber;

     }

     public String getRegistrationNumber()

    {

        return registrationNumber;

    }

    public MyCar upgradeCar(String newCarRegNo)

    {

       return new MyCar(newCarRegNo);

    }

}

String, StringBuffer and StringBuilder

With respect to C or C++ in java String handling is different. Java provides String class to represent Strings. For better memory utilization java treats String as constant and their value can't be changed.

This behavior is popularly known as immutable.The idea is if some one write

String hello = "Hello"; 

String greetings = "Hello";

Internally both refer to same object. In JVM memory area there is a dedicated memory for these String literals, known as String pool.

So in our example hello == greetings will return true.

But if someone write

String str = new String("Hello");

It will create a new object, it won't point to same literal available in string pool.

So hello == str will return false. 

Another advantage of java String is we can use + for concatenation.

String greetMe = hello + "Java";

We can concatenate diffrent type of object other than String with String too. The typecast is automatic.String conversions are implemented through the method toString, defined by Object and inherited by all classes in Java.

As we learned String objects are immutable means the values cannot be altered. So strings are always thread safe. Any operation such as hello.toLowerCase() will result another object. For extensive String manipulation java provides two other classes StringBuffer and StringBuilder. These classes gives us a way to manipulate String efficiently. The only difference is StringBuffer is thread safe while StringBuilder is not. So by design StringBuilder is faster than StringBuffer.

So when to use what

String is used to handle multiple literal, it gives you optimum way to handle duplicate literal for better memory utilization.

StringBuffer is natural choice if we need to do a lots of String manipulation in a thread safe way. If synchronization is not the issue StringBuilder should be used since its faster than StringBuffer.

Have fun with your Strings  ;)

Future of Enterprise Applications Development

This is something I came to know while working with Weblogic for past few years. Over the years weblogic has developed quite a bit from one of its oldest version 6 (formerly known as BEA and before that known as Aqualogic) to Weblogic 12 (currently known as Oracle weblogic).

David Moyes might have left Manchester United in a mess this year (2013-2014), but oracle has done its bit to enhance Weblogic for its betterment. The most stable version currently in industry standard is 11g (10.3.6). Forgive me for showing my untiring effort to link Football to Weblogic, which are no way related, but one more expensive player bought on board by Oracle is Sun Java. And as a branch of Oracle Java is growing very fast and although Java 6 is considered as an industry standard now, there is already a new version of Java 8 already released in March 2014.

Now, naturally the question is where am I leading you to? The point I am trying to make is, the version of Java that comes for the latest Weblogic is still Java 6. Although you can use Java 7 in weblogic 12c (http://docs.oracle.com/cd/E24329_01/doc.1211/e24492/jdk7.htm), as of now we haven’t seen Weblogic using the full potential of the new Java versions. All features available might not be of use, but features like new concurrent Garbage Collector , improved compiler warnings etc would mean a vastly improved Weblogic application server with less and less memory issues for heavy enterprise applications.

And the latest in this is Java 8 which boasts of a very small JVM of 3MB. These features combined with the new improved weblogic GUI, security features gives enterprise applications a huge boost in terms of performance and ease of handling. What I am looking forward to is coming days with a complete package having the latest version of all the products required for enterprise application development. A Language (Java),an Application Server (Weblogic), a database (Oracle Database) and an IDE (NetBeans). This might act as a Commercial Of the Shelf (COTS) product for oracle and would standardize the process starting from development till deployment. Although this might sound as taking away the flexibility of the individual options that you can have but it is more to make an industry acceptable standard for enterprise architecture while free lancers and open source community continuing their adventure to explore new avenues and improve the standard in future.