Tuesday, December 27, 2011

Extend Thread vs implement Runnable

There are two ways to create your own thread type: subclass java.lang.Thread class, or implementing java.lang.Runnable and pass it to Thread constructor or java.util.concurrent.ThreadFactory. What is the difference, and which one is better?
  1. The practical reason is, a Java class can have only one superclass. So if your thread class extends java.lang.Thread, it cannot inherit from any other classes. This limits how you can reuse your application logic.
  2. From a design point of view, there should be a clean separation between how a task is identified and defined, between how it is executed. The former is the responsibility of a Runnalbe impl, and the latter is job of the Thread class.
  3. A Runnable instance can be passed to other libraries that accept task submission, e.g., java.util.concurrent.Executors. A Thread subclass inherits all the overhead of thread management and is hard to reuse.
  4. Their instances also have different lifecycle. Once a thread is started and completed its work, it's subject to garbage collection. An instance of Runnalbe task can be resubmitted or retried multiple times, though usually new tasks are instantiated for each submission to ease state management.

Friday, December 23, 2011

O(n) for operations on Java collections


Collection Interfaces - Java Collection Diagrams


And when we include maps:

Avoid memory leaks using Weak&Soft references

Some Java developers believe that there is no such a thing as memory leak in Java (thanks to the fabulous automatic Garbage Collection concept)

Some others had met the OutOfMemoryError and understood that the JVM has encountered some memory issue but they are not sure if it’s all about the code or maybe even an OS issue…

The OutOfMemoryError API docs reveals that it “Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector. “

As we know, the JVM has a parameter that represents the maximum heap size(-Xmx), hence we can defiantly try to increase the heap size. yet some code can generate new instances all the time, if those instances are accessible(being referenced by the main program – in a recursive manner) for the entire program life span, then the GC won’t reclaim those instances. hence the heap will keep increasing and eventually a OutOfMemoryError will be thrown <- we call that memory leak.

Our job as Java developers is to release references (that are accessible by the main program) that we won’t use in the future. by doing that we are making sure that the GC will reclaim those instances (free the memory that those instances occupying in the heap).

In some cases we reference an instance from 2 different roots. one root represent a fast-retrieval space(e.g. HashMap) and the other manages the real lifespan of that instance. Sometimes we would like to remove the reference of that instance from one root and get the other root(fast retrieval) reference removed automatically.

We wouldn’t want to do it manually due to the fact that we are not C++ developers and we wouldn’t like to manage the memory manually..

Weak references

In order to solve that we can use WeakReference.

Instances that are being referenced by only Weak references will get collected on the next collection! (Weakly reachable), in other words those references don’t protect their value from the garbage collector.

Hence if we would like to manage the life span of an instance by one reference only, we will use the WeakReference object to create all the other references.

( usage: WeakReference wr = new WeakReference(someObject);)

In some apps we would like to add all our existing references to some static list, those references should not be strong, otherwise we would have to clean those references manually, we would add those references to the list using this code.

public static void addWeakReference(Object o){
refList.add(new WeakReference(o));
}


since most of the WeakReferences use cases needs a Map data structure, there is an implementation of Map that add a WeakReference automatically for you – WeakHashMap

Soft References

I saw few implementations of Cache using weak references (e.g. the cache is just a WeakHashMap => the GC is cleaning old objects in the cahce), without WeakReferences naive cache can easily cause memory leaks and therefor weak references might be a solution for that.

The main problem is that the GC will clean the cached-object probably and most-likely faster then you need.

Soft references solve that, those references are exactly like weak references, yet the GC won’t claim them as fast. we can be sure that the JVM won’t throw an OutOfMemory before it will claim all the soft and weak references!

using a soft references in order to cache considered the naive generic cache solution. (poor’s men cache)

( usage:SoftReference sr = new SoftReference(someObject);)

Java Forever - Official Video

Thursday, December 22, 2011

One java - 2 compilers (Javac and JIT)

It seems like that for students there is a lot of confusion regarding how Java/The JVM works because there are TWO compilers involve, so when someone mentions a compiler or the Just In Time compiler some of them would imagine it’s the same one, the Java Compiler..

So how does it really works?

It’s simple..

1) You write Java code (file.java) which compiles to “bytecode“, this is done using the javacthe 1st compiler.

It’s well known fact that Java can be written once get compiled and run anywhere (on any platform) which mean that different types of JVM can get installed over any type of platform and read the same good old byte code

2) Upon execution of a Java program (the class file or Jar file that consists of some classes and other resources) the JVM should somehow execute the program and somehow translate it to the specific platform machine code.

In the first versions of Java, the JVM was a “stupid” interprater that executes byte-code line by line….that was extremely slow…people got mad, there were a lot of “lame-java, awesome c” talks…and the JVM guys got irratated and reinvented the JVM.

the “new” JVM initially was available as an add-on for Java 1.2 later it became the default Sun JVM (1.3+).

So what did they do? they added a second compiler.. Just In Time compiler(aka JIT)..

Instead of interpreting line by line, the JIT compiler compiles the byte-code to machine-code right after the execution..

Moreover, the JVM is getting smarter upon every release, it “knows” when it should interpat the code line-by-line and what parts of the code should get compiled beforehand (still on runtime).

It does that by taking real-usage statistics, and a long-list of super-awesome heuristics..

The JVM can get configured by the user in order to disable/enable some of those heuristics..

To summarize, In order to execute java code, you use two different compilers, the first one(javac) is generic and compiles java to bytecode, the second(jit) is platform-dependent and compiles some portions of the bytecode to machine-code in runtime!

Optimizing and Speeding up the code in Java

Finalizers: object that overwrites the finalize() method (“Called by the garbage collector on an object when garbage collection determines that there are no more references to the object.”) is slower!(for both allocation and collection) if it’s not a must, do clean ups in other ways ( e.g. in JDBC close the connection using the try-catch-finally block instead)

New is expensive: creating new heavy object() on the heap is expensive!, it’s recommended to recycle old objects (by changing their fields) or use the flyweight design pattern.

Strings : (1) Strings are immutable which mean that upon usage of the + operator between 2 strings the JVM will generate a new String(s1+s2) on the heap (expensive as I just mentioned), in order to avoid that, it’s recommended to use the StringBuffer.(Update) since JDK 1.5 was introduced  StringBuilder is a better option than Stringbuffer in a single-threaded environment.

(2) Don’t convert your strings to lower case in order to compare them, use String.equalIgnoreCase() instead.

(3) String.startswith() is more expensive than String.charat(0) for the first character.

Inline method: inline is a compiler feature, when you call a method from anywhere in your code, the compiler copies the content of the inline method and replace the line that calls the method with it.

Obviously,It saves runtime time: (1) there is no need to call a method (2) no dynamic dispatch.

In some languages you can annotate a method to be inline, yet in Java it’s impossible, it’s the compiler decision.

the compiler will consider inline a method if the method is private.

My recommendation is to search in your code for methods that are heavily used(mostly in loops) and annotate those method as private if possible.

Don’t invent the wheel: the java api is smart and sophisticated and in some cases use native implementation, code that you probably can’t compete with. unless you know what you are doing (performance wise) don’t rewrite methods that already exists in the java API. e.g. benchmarks showed that coping and array using a for loop is at least n/4 times slower than using System.arraycopy()

Reflection: reflection became much faster for those of you who use the most recent JVMs, yet using reflection is most certainly slower than not using it. which mean that you better avoid reflection if there is no need.

Synchronization: Some data structures auto-support concurrency, in case of a single thread application don’t use those to avoid overhead e.g. use ArrayList instead of a Vector

Multithreads: in case of a multi processor use threads, it will defiantly speed up your code, if you are not a thread expert some compilers know how to restructure your code to thread automatically for you. you can always read a java threads tutorial as well

Get familiar with the standard data structures:   e.g. if you need a dast for puting and retriving objects use HashMap and not an ArrayList. (O(1))

Add an id field, for faster equals(): object that contains many fields are hard to compare ( equals() wise), to avoid that add an id(unique) field to your object and overwrite the equals() method to compare ids only.

Be careful, In case  your code already works, optimizing it is a sure way to create new bugs and make your code less maintainable!

it’s highly recommended to time your method before and after an optimization.

Sunday, October 9, 2011

101 reasos why java is better than .net

I was once reading the interesting article and so I decided to share on this blog:
link

Divide by Zero in case of Java

One of the good interview questions I found was related to divide by zero.
Lets take the case:

What will be the output of this code snippet?

public class NaN {
 
    public static void main(String[] args) {
        double d = 2.0 / 0.0;
        System.out.println(d);
    }
}

What's the answer: The code will not compile or will it throw a DivideByZero error? Both are wrong. The code compiles fine and the output is,
Infinity

Let's check another code snippet,

public class NaN {
 
    public static void main(String[] args) {
        double d = 0.0 / 0.0;
        System.out.println(d);
    }
}

The output in this case is,
NaN

Saturday, October 8, 2011

Hello World in Ruby using Netbeans

After getting a decent knowledge of what Ruby is and the useful resources that are available, lets get into action by creating our first hello world program.

Ruby and Ruby on Rails development becomes amazingly easy using Netbeans IDE where you can perform almost all the tasks in one single IDE. Download and install the Netbeans-Ruby version. You should be having JDK installed in your box, thats pretty much the pre-requisite for Netbeans to install.

OR you can simply download the complete version of netbeans and install ruby plugins.

Download the ruby from here. Extract it to some location, Say C:\\ruby
Now create new project.
Launch Netbeans go to File --> New Project. A new project wizard should come up. Select Ruby Application i.e. C:ruby\bin., click Next and click Finish. Thats it!!!!
You dont even have to type a Hello World. The new project template does it for you! So sweet isnt it? Now, click on the big green Run button and the console should print out Hello World without a hitch.

Now just run the program :)

installing RadRails on Eclipse

I could not find a proper answer when i wanted to install RadRails on eclipse . This is how it is done , .... in the Eclipse menu go to
Help-->Software Updates --> Find and Install....
then in the pop - up window which appears ,..
Search for new features to install
and then click next and then u will have to add 2 new remote sites, .. the details for the sites are the ones which were very difficult to obtain , they are
site 1 :
Name :RadRails
URL : http://radrails.sourceforge.net/update
site 2 :
Name :RDT
URL : http://updatesite.rubypeople.org/release
then click on finish , u are almost done with the installation , u have to just follow the instructions from here on to finish the installation .
This entry was posted on Friday, May 16, 2008 at 8:37 PM and is filed under , , . You can follow any responses to this entry through the comments feed .

Monday, October 3, 2011

Making collections final

Once we write final
ArrayList list = new ArrayList();

We can add, delete objects from this list, but I can not
list = new ArrayList() or list = list1.

So declaring the list final means that you cannot reassign the list variable to another object.

There are two situations in which this can be useful.
  1. You want to make sure that no-one reassigns your list variable once it has received its value. This can reduce complexity and helps in understanding the semantics of your class/method. In this case you are usually better off by using good naming conventions and reducing method length (the class/method is already too complex to be easily understood).
  2. When using inner classes you need to declare variables as final in an enclosing scope so that you can access them in the inner class. This way, Java can copy your final variable into the inner class object (it will never change its value) and the inner class object does not need to worry what happens to the outer class object while the inner class object is alive and needs to access the value of that variable.


Tuesday, September 27, 2011

Difference between Proxy, Decorator, Adaptor, and Bridge Patterns ?

Proxy, Decorator, Adapter, and Bridge are all variations on "wrapping" a class. But their uses are different.
  • Proxy could be used when you want to lazy-instantiate an object, or hide the fact that you're calling a remote service, or control access to the object.
    See proxy pattern with details.
  • Decorator is also called "Smart Proxy." This is used when you want to add functionality to an object, but not by extending that object's type. This allows you to do so at runtime.
  • Adapter / Wrapper is used when you have an abstract interface, and you want to map that interface to another object which has similar functional role, but a different interface.
    In particular Decorator looks very close to Adapter but still there is basic difference:
      Adapter / Wrapper Decorator
    Composes "origin" class True True
    Modifies original interface True False
    Modifies behavior of interface
    False True
    Proxies method calls True True
     
    See Adapter pattern and Decorator Pattern with examples.
  • Bridge is very similar to Adapter, but we call it Bridge when you define both the abstract interface and the underlying implementation. I.e. you're not adapting to some legacy or third-party code, you're the designer of all the code but you need to be able to swap out different implementations.
    See bridge pattern with example.
  • Facade is a higher-level (read: simpler) interface to a subsystem of one or more classes. Think of Facade as a sort of container for other objects, as opposed to simply a wrapper. So you don't have to worry about so many things, just call the facade to do all the stuff.
    See Facade pattern with example.

Interface And Abstraction – Spiritual Explanation

“What is the difference between interface and abstract class?”, a typical interview question . Answer is so obvious, and we can list at least 3 differences. Here is an attempt to correlate Object Oriented world with spiritual world, and explain abstraction and interface.

“Soul is an abstract notion realized by concrete living being”. So as per OO world, if you got “Soul” as abstract class, you got to have a concrete class “Life”. Soul can not operate without Life.
Just like I said object is an entity with an objective to live, abstract class can live through concrete class. Inheritance is the only mechanism for an abstract class to live. Spiritually, Soul operates through life. Life is an object with a process thread running in it.

In Spiritual world, it is said that “Soul carries the karma (good or bad actions) from previous life, which has influences in the new life”. If you consider this statement, karma is the action log recorded into the abstract class.
Body is an interface to life (and hence interface to Soul) and real world. so IBody can be implemented by body of human, bird or any living creature. Once the objective is complete in this real world, destructor is called on life object. However actions are kept recorded (like log files) in the abstract class through out this new life.
In every new life actions recorded in abstract class is not revealed, as it is private declaration . Only the ultimate object builder (God)  has access to it. Object builder reads this private variable, and makes the decision of choosing a new interface for Soul. Dispose method is programmed to be called in a timer function. When timer event fires, dispose is called, and the Life object is disposed terminating the process thread.

After thread is terminated and Life is disposed, Object builder reads the record log from Soul class. Based on the karma recorded in the log, a new object with the suitable interface (body) is created, and Life is induced into it with a process thread. And a timer is started in the Life class, which when fires Thread Abort is called.

Thursday, September 22, 2011

Shallow Copy and Deep Copy

There are two ways to make a copy of an object called shallow copy and deep copy.
Here is what they mean:

Shallow Copy
Shallow copy is a bit-wise copy of an object. A new object is created that has an exact copy of the values in the original object. If any of the fields of the object are references to other objects, just the references are copied. Thus, if the object you are copying contains references to yet other objects, a shallow copy refers to the same subobjects.

Deep Copy
Deep copy is a complete duplicate copy of an object. If an object has references to other objects, complete new copies of those objects are also made. A deep copy generates a copy not only of the primitive values of the original object, but copies of all subobjects as well, all the way to the bottom. If you need a true, complete copy of the original object, then you will need to implement a full deep copy for the object.
Shallow Copy
Shallow Copy
Deep Copy
Deep Copy

You may like : 
Design patterns using shallow copy and deep copy - Prototype pattern
Shallow and deep copy using clone

MVC Pattern Basics

Definition
The Model-View-Controller (MVC) architectural pattern is used in software engineering to allow for the separation of three common features in GUI applications:
  • the data access (typically via a database)
  • the business logic (how the data will be used)
  • user interaction (how the data and actions will be visually presented)

MVC pattern differenciates all the 3 aspects of application in 3 difft tiers.

Modal
It incorporates following point
  •  Holds the business logic of the application.
  •  holds data sent between different. tiers like JSP to servlet and handler classes.
  • One of the goals of the model is to give a presentation which does not directly refer to any specific DBMS. 

View
  • This represents the visible user interface, so handles presentation tier of the application.
  • it knows enough about the data to create a coherent presentation, but does not actually do the work of presenting the data. Instead, it provides the ability to manipulate data outside the View through event handlers defined within. 
  • handles presentation logic, client side validation.
  • e.g. HTML, JSP

Controller
  • handles the flow of the application
  • Joins the Model with the View and is the heart of the business logic.
  • It is the source of activity when an event occurs and defines the event handling actions which access data (from the Model) and are presented to the user (in the View).
  • e.g. Servlets, Action Class in Struts, ActionServlet is using struts-config.xml as front controller to handle each request and redirect it to appropriate destination.

Advantages
  •  Increases modularity of the application.
  •  Increases Maintainability of the application, i.e.  the data presentation can be changed without any notion of how the data is obtained and conversely, the data access can be changed without any knowledge of how it is to be presented. 
Example
to be added soon

    Feelings today


    Java: Rounding off to 2 decimal places

    Seeking the simplest way to round off a float value to 2 decimal places, i found these:

    Method 1:
    x = (double)int((x+0.005)*100.0)/100.0;

    Method 2:
    x = Math.round(x*100.0) / 100.0;

    Method 3:
    DecimalFormat df2 = new DecimalFormat( "#,###,###,##0.00" );
    double dd = 100.2397;
    double dd2dec = new Double(df2.format(dd)).doubleValue();

    Method 4:
    f = (float) (Math.round(n*100.0f)/100.0f);

    Method 5:
    double r = 5.1234;
    System.out.println(r); // r is 5.1234
    int decimalPlaces = 2;
    BigDecimal bd = new BigDecimal(r);
    bd = bd.setScale(decimalPlaces, BigDecimal.ROUND_HALF_UP); // setScale is immutable
    r = bd.doubleValue();
    System.out.println(r); // r is 5.12

    [source: www.thescripts.com, accuracy unchecked]

    How I did it:
    float percentage = score.floatValue()/(qapairs.length*10)*100; //my float value
    percentage = Float.valueOf((new DecimalFormat("###.00").format(percentage)));

    Friday, July 15, 2011

    The Value of String.valueOf

    Most Java developers have probably had their fill of NullPointerException. Most of us have learned the value of doing certain things to reduce our "opportunities" of encountering the NullPointerException. Indeed, there is a Wiki page dedicated to preventing or reducing NullPointerExceptions.

    Several people have argued for additional language support for improved and easier handling of potential null. These include Java SE 7 proposals, Optimized Null Check, and Kinga Dobolyi's thesis Changing Java’s Semantics for Handling Null Pointer Exceptions.

    Among the many things we can already do rather easily to reduce our encounters with NullPointerException, one particular easy thing to do is to apply String.valueOf(Object) when appropriate. The String.valueOf(Object) method, as its Javadoc-generated documentation states, returns "null" if the passed in object is null and returns the results on the passed-in Object's toString() call if the passed-in Object is not null. In other words, String.valueOf(String) does the null checking for you.

    The use of String.valueOf(Object) is particularly useful when implementing toString methods on custom classes. Because most toString implementations provide the class's data members in String format, String.valueOf(Object) is a natural fit. All Java objects based on classes that extend Object provide a toString() implementation even if it is simply their parent's (or even Object's) implementation of toString(). However, if a member class implements toString but the member itself is null rather than an instance of the class, then the toString() does no good (and actually leads to a NullPointerException when called).

    This is demonstrated with the following example code.

    Consider a class called PersonName, which holds last name and first name of the person:

    package com.vaani.string;

    /**
    * Class upon which to call toString.
    */
    public class PersonName
    {
    private String lastName;
    private String firstName;

    public PersonName(final String newLastName, final String newFirstName)
    {
    lastName = newLastName;
    firstName = newFirstName;
    }

    /**
    * Provide String representation of me.
    *
    * @return My String representation.
    */
    @Override
    public String toString()
    {
    return firstName + " " + lastName;
    }
    }


    Person.java


    package com.vaani.string;



    public class Person
    {
    private PersonName name;

    public Person( PersonName newName)
    {
    name = newName;
    }



    /**
    * Provide String representation of me.
    *
    * @return My String representation.
    */
    public String toString()
    {
    //to be implemented
    }
    }


    Now this person.java has toString() which is to be implemented, but we will see how it throws NPE. Consider the main method:


    PersonName personName = new PersonName("Flintstone", null);
    //print personname as string
    System.out.println("Person's Name [DIRECT]: " + personName);
    System.out.println("Person's Name [TOSTRING]: " + personName.toString());
    System.out.println("Person's Name [STRING.VALUEOF]: " + String.valueOf(personName));
    Output will be:

    Person's Name         [DIRECT]: null Flintstone
    Person'
    s Name [TOSTRING]: null Flintstone
    Person's Name [STRING.VALUEOF]: null Flintstone

    Now consider the toString() func is represented as

    Also if we call Person's constructor with personName(instance created above), everything will still be fine:

    PersonName name;
    //code skipped
    public String toString()
    {
    // Don't use -- can lead to runtime error (NullPointerException)
    return name.toString();
    }

    Now as we did earlier:

    PersonName personName = new PersonName("Flintstone", null);

    //create next object from personName
    Person personOne = new Person(personName);
    System.out.println("Person One [DIRECT]: " + personOne);
    System.out.println("Person One [TOSTRING]: " + personOne.toString());
    System.out.println("Person One [STRING.VALUEOF]: " + String.valueOf(personOne));

    This will work fine because of personName will return its toString() func, and dont throw any NPE. But this will result in bang:

    Person personTwo = new Person(null);
    System.out.println("Person Two [DIRECT]: " + personTwo);
    System.out.println("Person Two [TOSTRING]: " + personTwo.toString());
    System.out.println("Person Two [STRING.VALUEOF]: " + String.valueOf(personTwo));
    Each of this above line throws exception. So please be aware of this. To avoid null pointer exception you can implement toString() func of Person like this:

    public String toString()
    {
    // It's all good
    return String.valueOf(name);
    }
    Now the personTwo will be printed as null.
    Full code listing for Person.java(personName.java is already covered):

    package com.vaani.string;



    public class Person
    {
    private PersonName name;

    public Person( PersonName newName)
    {
    name = newName;
    }



    /**
    * Provide String representation of me.
    *
    * @return My String representation.
    */
    public String toString()
    {
    // Don't use -- leads to compiler time error (incompatible types)
    //return name;

    // Don't use -- can lead to runtime error (NullPointerException)
    //return name.toString();

    // It's all good
    return String.valueOf(name);
    }
    }

    main method to run this code:

    package com.vaani.string;

    import java.io.IOException;
    import java.io.OutputStream;
    import java.util.logging.Logger;

    /**
    * Example class demonstrating use of String representations available through
    * implicit String, toString(), and String.valueOf().
    */
    public class StringValueFunc
    {
    private static final String NEW_LINE = System.getProperty("line.separator");

    /** Using java.util.logging. */
    private static Logger LOGGER = Logger.getLogger(
    StringValueFunc.class.getName());

    /**
    * Main function for running tests/demonstrations.
    *
    * @param arguments Command-line arguments; none anticipated.
    */
    public static void main(final String[] arguments)
    {
    //takes last name and first name
    PersonName personName = new PersonName("Flintstone", null);

    //create next object from personName
    Person personOne = new Person(personName);
    //just initiate to null
    Person personTwo = new Person(null);
    printHeader("String representation of direct Strings", System.out);

    System.out.println("Person's Name [DIRECT]: " + personName);
    System.out.println("Person's Name [TOSTRING]: " + personName.toString());
    System.out.println("Person's Name [STRING.VALUEOF]: " + String.valueOf(personName));
    printBlankLine(System.out);

    printHeader("String representation of non-null complex object", System.out);

    System.out.println("Person One [DIRECT]: " + personOne);
    System.out.println("Person One [TOSTRING]: " + personOne.toString());
    System.out.println("Person One [STRING.VALUEOF]: " + String.valueOf(personOne));
    printBlankLine(System.out);

    printHeader("String representation of null complex object", System.out);

    System.out.println("Person Two [DIRECT]: " + personTwo);
    System.out.println("Person Two [TOSTRING]: " + personTwo.toString());
    System.out.println("Person Two [STRING.VALUEOF]: " + String.valueOf(personTwo));
    printBlankLine(System.out);
    }

    public static void printHeader(final String message, final OutputStream out)
    {
    final String headerSeparator =
    "====================================================================";

    try
    {
    out.write((headerSeparator + NEW_LINE + message + NEW_LINE).getBytes());
    out.write((headerSeparator + NEW_LINE).getBytes());
    }
    catch (IOException ioEx)
    {
    System.out.println(headerSeparator);
    System.out.println(message);
    System.out.println(headerSeparator);
    LOGGER.warning("Could not write header information to provided OutputStream.");
    }
    }

    public static void printBlankLine(final OutputStream out)
    {
    try
    {
    out.write(NEW_LINE.getBytes());
    }
    catch (IOException ioEx)
    {
    System.out.println(NEW_LINE);
    LOGGER.warning("Could not write blank line to provided OutputStream.");
    }
    }


    }

    The above code can be used to demonstrate building of a toString method on a complex object and how its behaves when called by an owning class. The method of most interest is at the bottom of the code shown above. Two return values are commented out because of problems associated with them. The final example, using String.valueOf(Object) is NOT commented out because it works the best each time it is run whether or not the complex PersonName object is null. The next three images show the output for each of these presentations of the Person objects' String representations.











    Finally, the String class provides many overloaded valueOf methods. In addition to the version that was the focus of this blog post (accepts an Object), the other overloaded versions of valueOf accept primitive data types and arrays of primitive data types.
    Conclusion
    Regardless of what the future brings in terms of improved null handling in Java, there are many tactics we can take today to reduce the unwanted (sometimes we actually do want them thrown!) occurrences of NullPointerException. One of these is to use String.valueOf(Object) when appropriate.

    Additional Resources

    Effective Java : How to Avoid NPE / Null Pointer Exception in java?

    It doesn't take much Java development experience to learn firsthand what the NullPointerException is about. In fact, one person has highlighted dealing with this as the number one mistake Java developers make. I blogged previously on use of String.value(Object) to reduce unwanted NullPointerExceptions. There are several other simple techniques one can use to reduce or eliminate the occurrences of this common type of RuntimeException that has been with us since JDK 1.0. This blog post collects and summarizes some of the most popular of these techniques.

    Check Each Object For Null Before Using

    The most sure way to avoid a NullPointerException is to check all object references to ensure that they are not null before accessing one of the object's fields or methods. As the following example indicates, this is a very simple technique.

    final String causeStr = "adding String to Deque that is set to null.";
    final String elementStr = "Fudd";
    Deque<String> deque = null;

    try
    {
    deque.push(elementStr);
    log("Successful at " + causeStr, System.out);
    }
    catch (NullPointerException nullPointer)
    {
    log(causeStr, nullPointer, System.out);
    }

    try
    {
    if (deque == null)
    {
    deque = new LinkedList<String>();
    }
    deque.push(elementStr);
    log( "Successful at " + causeStr
    + " (by checking first for null and instantiating Deque implementation)",
    System.out);
    }
    catch (NullPointerException nullPointer)
    {
    log(causeStr, nullPointer, System.out);
    }

    In the code above, the Deque used is intentionally initialized to null to facilitate the example. The code in the first try block does not check for null before trying to access a Deque method. The code in the second try block does check for null and instantiates an implementation of the Deque (LinkedList) if it is null. The output from both examples looks like this:

    ERROR: NullPointerException encountered while trying to adding 
    String to Deque that is set to null.
    java.lang.NullPointerException
    INFO: Successful at adding String to Deque that is set to null.
    (by checking first for null and instantiating Deque implementation)

    The message following ERROR in the output above indicates that a NullPointerException is thrown when a method call is attempted on the null Deque. The message following INFO in the output above indicates that by checking Deque for null first and then instantiating a new implementation for it when it is null, the exception was avoided altogether.

    This approach is often used and, as shown above, can be very useful in avoiding unwanted (unexpected) NullPointerException instances. However, it is not without its costs. Checking for null before using every object can bloat the code, can be tedious to write, and opens more room for problems with development and maintenance of the additional code. For this reason, there has been talk of introducing Java language support for built-in null detection, automatic adding of these checks for null after the initial coding, null-safe types, use of Aspect-Oriented Programming (AOP) to add null checking to byte code, and other null-detection tools.

    Groovy already provides a convenient mechanism for dealing with object references that are potentially null. Groovy's safe navigation operator (?.) returns null rather than throwing a NullPointerException when a null object reference is accessed.

    Because checking null for every object reference can be tedious and does bloat the code, many developers choose to judiciously select which objects to check for null. This typically leads to checking of null on all objects of potentially unknown origins. The idea here is that objects can be checked at exposed interfaces and then be assumed to be safe after the initial check.

    This is a situation where the ternary operator can be particularly useful. Instead of
    // retrieved a BigDecimal called someObject
    String returnString;
    if (someObject != null)
    {
    returnString = someObject.toEngineeringString();
    }
    else
    {
    returnString = "";
    }

    the ternary operator supports this more concise syntax

    // retrieved a BigDecimal called someObject
    final String returnString = (someObject != null)
    ? someObject.toEngineeringString()
    : "";
    }

    Check Method Arguments for Null

    The technique just discussed can be used on all objects. As stated in that technique's description, many developers choose to only check objects for null when they come from "untrusted" sources. This often means testing for null first thing in methods exposed to external callers. For example, in a particular class, the developer might choose to check for null on all objects passed to public methods, but not check for null in private methods.

    The following code demonstrates this checking for null on method entry. It includes a single method as the demonstrative method that turns around and calls two methods, passing each method a single null argument. One of the methods receiving a null argument checks that argument for null first, but the other just assumes the passed-in parameter is not null.

    /**
        * Append predefined text String to the provided StringBuilder.
        *
        * @param builder The StringBuilder that will have text appended to it; should
        * be non-null.
        * @throws IllegalArgumentException Thrown if the provided StringBuilder is
        * null.
        */
    private void appendPredefinedTextToProvidedBuilderCheckForNull(
    final StringBuilder builder)
    {
    if (builder == null)
    {
    throw new IllegalArgumentException(
    "The provided StringBuilder was null; non-null value must be provided.");
    }
    builder.append("Thanks for supplying a StringBuilder.");
    }

    /**
        * Append predefined text String to the provided StringBuilder.
        *
        * @param builder The StringBuilder that will have text appended to it; should
        * be non-null.
        */
    private void appendPredefinedTextToProvidedBuilderNoCheckForNull(
    final StringBuilder builder)
    {
    builder.append("Thanks for supplying a StringBuilder.");
    }

    /**
        * Demonstrate effect of checking parameters for null before trying to use
        * passed-in parameters that are potentially null.
        */
    public void demonstrateCheckingArgumentsForNull()
    {
    final String causeStr = "provide null to method as argument.";
    logHeader("DEMONSTRATING CHECKING METHOD PARAMETERS FOR NULL", System.out);

    try
    {
    appendPredefinedTextToProvidedBuilderNoCheckForNull(null);
    }
    catch (NullPointerException nullPointer)
    {
    log(causeStr, nullPointer, System.out);
    }

    try
    {
    appendPredefinedTextToProvidedBuilderCheckForNull(null);
    }
    catch (IllegalArgumentException illegalArgument)
    {
    log(causeStr, illegalArgument, System.out);
    }
    }

    When the above code is executed, the output appears as shown next.
    ERROR: NullPointerException encountered while trying to provide null to 
    method as argument.
    java.lang.NullPointerException
    ERROR: IllegalArgumentException encountered while trying to provide null
    to method as argument.
    java.lang.IllegalArgumentException: The provided StringBuilder was null;
    non-null value must be provided.


    In both cases, an error message was logged. However, the case in which a null was checked for threw an advertised IllegalArgumentException that included additional context information about when the null was encountered. Alternatively, this null parameter could have been handled in a variety of ways. For the case in which a null parameter was not handled, there were no options for how to handle it. Many people prefer to throw a NullPolinterException with the additional context information when a null is explicitly discovered (see Item #60 in the Second Edition of Effective Java or Item #42 in First Edition), but I have a slight preference for IllegalArgumentException when it is explicitly a method argument that is null because I think the very exception adds context details and it is easy to include "null" in the subject.

    The technique of checking method arguments for null is really a subset of the more general technique of checking all objects for null. However, as outlined above, arguments to publicly exposed methods are often the least trusted in an application and so checking them may be more important than checking the average object for null.

    Checking method parameters for null is also a subset of the more general practice of checking method parameters for general validity as discussed in Item #38 of the Second Edition of Effective Java (Item 23 in First Edition).


    Consider Primitives Rather than Objects

    I don't think it is a good idea to select a primitive data type (such as int) over its corresponding object reference type (such as Integer) simply to avoid the possibility of a NullPointerException, but there is no denying that one of the advantages of primitive types is that they do not lead to NullPointerExceptions. However, primitives still must be checked for validity (a month cannot be a negative integer) and so this benefit may be small. On the other hand, primitives cannot be used in Java Collections and there are times one wants the ability to set a value to null.

    The most important thing is to be very cautious about the combination of primitives, reference types, and autoboxing. There is a warning in Effective Java (Second Edition, Item #49) regarding the dangers, including throwing of NullPointerException, related to careless mixing of primitive and reference types.


    Carefully Consider Chained Method Calls

    A NullPointerException can be very easy to find because a line number will state where it occurred. For example, a stack trace might look like that shown next:

    java.lang.NullPointerException
    at dustin.examples.AvoidingNullPointerExamples.
    demonstrateNullPointerExceptionStackTrace(AvoidingNullPointerExamples.java:222)
    at dustin.examples.
    AvoidingNullPointerExamples.main(AvoidingNullPointerExamples.java:247)

    The stack trace makes it obvious that the NullPointerException was thrown as a result of code executed on line 222 of AvoidingNullPointerExamples.java. Even with the line number provided, it can still be difficult to narrow down which object is null if there are multiple objects with methods or fields accessed on the same line.

    For example, a statement like someObject.getObjectA().getObjectB().getObjectC().toString(); has four possible calls that might have thrown the NullPointerException attributed to the same line of code. Using a debugger can help with this, but there may be situations when it is preferable to simply break the above code up so that each call is performed on a separate line. This allows the line number contained in a stack trace to easily indicate which exact call was the problem. Furthermore, it facilitates explicit checking each object for null. However, on the downside, breaking up the code increases the line of code count (to some that's a positive!) and may not always be desirable, especially if one is certain none of the methods in question will ever be null.


    Make NullPointerExceptions More Informative

    In the above recommendation, the warning was to consider carefully use of method call chaining primarily because it made having the line number in the stack trace for a NullPointerException less helpful than it otherwise might be. However, the line number is only shown in a stack trace when the code was compiled with the debug flag turned on. If it was compiled without debug, the stack trace looks like that shown next:

    java.lang.NullPointerException
    at dustin.examples.AvoidingNullPointerExamples.
    demonstrateNullPointerExceptionStackTrace(Unknown Source)
    at dustin.examples.AvoidingNullPointerExamples.main(Unknown Source)

    As the above output demonstrates, there is a method name, but not no line number for the NullPointerException. This makes it more difficult to immediately identify what in the code led to the exception. One way to address this is to provide context information in any thrown NullPointerException. This idea was demonstrated earlier when a NullPointerException was caught and re-thrown with additional context information as a IllegalArgumentException. However, even if the exception is simply re-thrown as another NullPointerException with context information, it is still helpful. The context information helps the person debugging the code to more quickly identify the true cause of the problem.

    The following example demonstrates this principle.

    final Calendar nullCalendar = null;

    try
    {
    final Date date = nullCalendar.getTime();
    }
    catch (NullPointerException nullPointer)
    {
    log("NullPointerException with useful data", nullPointer, System.out);
    }

    try
    {
    if (nullCalendar == null)
    {
    throw new NullPointerException("Could not extract Date from provided Calendar");
    }
    final Date date = nullCalendar.getTime();
    }
    catch (NullPointerException nullPointer)
    {
    log("NullPointerException with useful data", nullPointer, System.out);
    }

    The output from running the above code looks as follows.

    ERROR: NullPointerException encountered while trying to NullPointerException 
    with useful data
    java.lang.NullPointerException
    ERROR: NullPointerException encountered while trying to
    NullPointerException with useful data
    java.lang.NullPointerException: Could not extract Date from provided Calendar

    The first error does not provide any context information and only conveys that it is a NullPointerException. The second error, however, had explicit context information added to it which would go a long way in helping identify the source of the exception.


    Use String.valueOf Rather than toString

    As described previously, one of the surest methods for avoiding NullPointerException is to check the object being referenced for null first. The String.valueOf(Object) method is a good example of a case where this check for null can be done implicitly without any additional effort on the developer's part. I blogged on this previously, but include a brief example of its use here.

     


    Source : Inspired by actual events

    Stringifying Java Arrays

    J2SE 5 provided significant new language features that made Java significantly easier to use and more expressive than it had ever been. Although "big" new J2SE 5 features such as enums, generics, and annotations, there was a plethora of new APIs and methods that have made our lives easier ever since. In this post, I briefly look at two of my favorites when dealing with Java arrays: the Arrays.toString(Object[]) method and the Arrays.deepToString(Object[]) method.

    The Arrays class has been around since JDK 1.2, but the methods for conveniently and simply converting arrays to a readable String including relevant array content without using Arrays.asList() were added with J2SE 5. Both Arrays.toString(Object[]) and Arrays.deepToString(Object[]) are static methods that act upon the arrays provided to them. The former, Arrays.toString(Object[]), is intended for single-dimension arrays while the latter, Arrays.deepToString(Object[]), is intended for multi-dimensional arrays. As my example later in this post will demonstrate, the multi-dimension deepToString will produce expected results even for single-dimension arrays. The two methods also provide easy and safe null handling, something that I appreciate.

    The next code listing is for a simple demonstration class that demonstrates trying to put the contents of various types of Java arrays into a String format. The types of arrays demonstrated are a single dimension array, a double dimensional array representing multi-dimensional arrays of various sizes, and an array that is really just null. The three methods demonstrated for getting a String out of these three types of arrays are (1) simple Object.toString() on each array (implicitly in case of null array to avoid the dreaded NullPointerException), (2) Arrays.toString(Object[]), and (3) Arrays.deepToString(Object[]).
    package com.vaani.arraytest;

    import java.util.Arrays;
    import static java.lang.System.out;

    /**
    * Simple demonstration of Arrays.toString(Object[]) method and the
    * Arrays.deepToString(Object[]) method.
    */
    public class Array2String
    {
    /**
    * Demonstrate usage and behavior of Arrays.toString(Object[]).
    */
    private static void demonstrateArraysToString()
    {
    out.println(
    "Single Dimension Arrays.toString: "
    + Arrays.toString(prepareSingleDimensionArray()));
    out.println(
    "Double Dimension Arrays.toString: "
    + Arrays.toString(prepareDoubleDimensionArray()));
    out.println(
    "Null Array Arrays.toString: "
    + Arrays.toString(prepareNullArray()));
    }

    /**
    * Demonstrate usage and behavior of Arrays.deepToString(Object[]).
    */
    private static void demonstrateArraysDeepToString()
    {
    out.println(
    "Single Dimension Arrays.deepToString: "
    + Arrays.deepToString(prepareSingleDimensionArray()));
    out.println(
    "Double Dimension Arrays.deepToString: "
    + Arrays.deepToString(prepareDoubleDimensionArray()));
    out.println(
    "Null Array Arrays.deepToString: "
    + Arrays.deepToString(prepareNullArray()));
    }

    /**
    * Demonstrate attempting to get String version of array with simple toString()
    * call (not using Arrays class).
    */
    private static void demonstrateDirectArrayString()
    {
    out.println("Single Dimension toString(): " + prepareSingleDimensionArray().toString());
    out.println("Double Dimension toString(): " + prepareDoubleDimensionArray());
    out.println("Null Array toString(): " + prepareNullArray());
    }

    /**
    * Prepare a single-dimensional array to be used in demonstrations.
    *
    * @return Single-dimensional array.
    */
    private static Object[] prepareSingleDimensionArray()
    {
    final String[] names = {"Aaron", "Bianca", "Charles", "Denise", "Elmer"};
    return names;
    }

    /**
    * Prepare a double-dimension array to be used in demonstrations.
    *
    * @return Double-dimensional array.
    */
    private static Object[] prepareDoubleDimensionArray()
    {
    final Object[][] namesAndAges = {
    {"Aaron", 10}, {"Bianca", 25}, {"Charles", 32}, {"Denise", 29}, {"Elmer", 67}};
    return namesAndAges;
    }

    /**
    * Prepare a null array.
    *
    * @return Array that is really null.
    */
    private static Object[] prepareNullArray()
    {
    return null;
    }

    /**
    * Main executable function for demonstrating Arrays.toString(Object[]) and
    * Arrays.deepToString(Object[]) methods.
    */
    public static void main(final String[] arguments)
    {
    out.println("\n\n\nDemonstrating direct array to string using toString():");
    demonstrateDirectArrayString();

    out.println("\n\n\nDemonstrating Arrays.toString() to get arrays as String:");
    demonstrateArraysToString();

    out.println("\n\n\nDemonstrating Arrays.deepToString() to get the String:");
    demonstrateArraysDeepToString();
    }
    }


    The above code exercises the three mentioned approaches for getting a String out of an array on the three different types of arrays: single dimension, multi dimension, and null array. The output from running this code demonstrates the utility of the different approaches. That output is shown next.

    Demonstrating direct array to string using toString():
    Single Dimension toString(): [Ljava.lang.String;@3e25a5
    Double Dimension toString(): [[Ljava.lang.Object;@19821f
    Null Array toString(): null
    ///////////
    Demonstrating Arrays.toString() to get arrays as String:
    Single Dimension Arrays.toString: [Aaron, Bianca, Charles, Denise, Elmer]
    Double Dimension Arrays.toString: [[Ljava.lang.Object;@addbf1, [Ljava.lang.Object;@42e816, [Ljava.lang.Object;@9304b1, [Ljava.lang.Object;@190d11, [Ljava.lang.Object;@a90653]
    Null Array Arrays.toString: null


    ///////////
    Demonstrating Arrays.deepToString() to get the String:
    Single Dimension Arrays.deepToString: [Aaron, Bianca, Charles, Denise, Elmer]
    Double Dimension Arrays.deepToString: [[Aaron, 10], [Bianca, 25], [Charles, 32], [Denise, 29], [Elmer, 67]]
    Null Array Arrays.deepToString: null

    The code above and its corresponding output lead to several observations:



    1. Simple Object.toString() on arrays is seldom what we want as it only prints the String representation of the array itself and not of its contents.
    2. Arrays.toString(Object[]) will print a String representation for multi-dimensional arrays, but this representation suffers the same drawbacks as Object.toString() after the first dimension. The first dimension (and only dimension for a single dimension array) gets put into an expected String, but deeper dimensions have the same Object.toString() treatment.
    3. Arrays.deepToString(Object[]), while intended for multi-dimensional arrays, produces the expected results for both single and multi-dimensional arrays.
    4. Both Arrays.toString(Object[]) and Arrays.deepToString(Object[]) handle null array gracefully, simply returning a String "null".

    I tend to use Java Collections far more than I use Java arrays. However, when I do need to work with arrays, it is nice to have the many useful features of the java.util.Arrays class. As this post has demonstrated, Arrays.toString(Object[]) and Arrays.deepToString(Object[]) are particularly valuable in obtaining a useful String representation of an array's contents. The java.util.Arrays class provides similar "deep" methods for performing equals and hashCode functionality on multi-dimensional arrays: Arrays.deepEquals and Arrays.deepHashCode.

    Chitika