Sunday, September 22, 2013

Maven : Jars not copied to Tomcat's lib folder


Sometime you might run into problem with Maven, You can see the Maven dependencies but they are not copied to servers lib folder and hence class not found exception will be thrown.
Here is a simple solution for it. In Eclipse go to "Project properties -> Deployment Assembly page".
This page describes how your app will be packaged for deployment or export. Add a new source "Maven dependency". It will solve the issue and jars will be copied to the server.

Friday, September 20, 2013

Display / Hide / Update processing message in jQuery Datatables

You can display / update the processing message displayed by Datatables. There is a hidden div which contains the processing text. Id of the hidden div is "YourTablesId_processing".
By hiding / showing div you can hide / show the processing message also by updating divs HTML you can change the processing message.
This demo shows how to display / hide / update the processing message in Datatables.

Thursday, June 20, 2013

jQuery : Warn user for unsaved data

$(document).ready(function() {
    needToConfirm = false; 
    window.onbeforeunload = askConfirm;
});

function askConfirm() {
    if (needToConfirm) {
        return "Your unsaved data will be lost.";
    }
}

$("select,input,textarea").change(function() {
    needToConfirm = true;
});

The above code checks the needToConfirm variable, if its true then it will display warning message. Whenever input, select or textarea elements value is changed, needToConfirm variable is set to true.

Wednesday, June 19, 2013

Forcing Java virtual machine to run garbage collector

No, You cant force garbage collection.
Even using
 
System.gc(); 
You can just make a request for garbage collection but it depends on JVM to do it or not.
Also Garbage collector are smart enough to collect unused memory when required so instead of forcing garbage collection you should check if you are handling objects in a right way.
If you are handling objects in a wrong way (like keeping reference to unnecessary objects) there is hardly anything JVM can do to free the memory. 


From Doc 
Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects. 
Which means that garbage collector makes best possible effort but it is not guaranteed that it will free up the space every-time.  

Bug regarding System.gc() documentation 
The documentation for System.gc() is extremely misleading and fails to make reference to the recommended practise of never calling System.gc().
The choice of language leaves it unclear what the behaviour would be when System.gc() is called and what external factors will influence the behaviour.
 Few useful links to visit when you think you should force JVM to free up some memory
1. How does garbage collection work
2. System.gc() in Java
3. Why is it a bad practice to call System.gc?  


All says
1. You don't have control over Garbage Collection in Java even System.gc() dont guarantee it.
2. Also its bad practice as forcing it may have adverse effect on performance.
3. Revisit your design and let JVM do his work :)

ResourceBundle : Loading properties file from JAR

With ResourceBundle you can use properties file which are present in external JAR.
  
getBundle(String baseName,Locale locale)
Where baseName should be the base name of the resource bundle, a fully qualified class name. Which mean it should be fully qualified name of properties excluding .properties extension.

Suppose you have a JAR structure like displayed in following image


(I have renamed the msg.jar to msg.zip just to open it and show the file structure).
Here properties files are in package "com.msg" so baseName should be "com.msg.messages" like
  
getBundle("com.msg.messages", desiredLocale);
For more details : Java Doc Link

Saturday, May 18, 2013

Implementing singleton in Java

While implementing Singleton we have 2 options 
1. Lazy loding - Create object only when required
2. Early loading - Create object when class is loaded and don't care if it will be used ever

Lazy loading adds bit overhead(lots of to be honest) so use it only when you have a very large object or heavy construction code AND also have other accessible static methods or fields that might be used before an instance is needed, then and only then you need to use lazy initialization.Otherwise choosing early loading is a good choice.

Most simple way of implementing Singleton is 

public class Foo {

 // It will be our sole hero
 private static final Foo INSTANCE = new Foo();

 private Foo() {
  if (INSTANCE != null) {
   // SHOUT
   throw new IllegalStateException("Already instantiated");
  }
 }

 public static Foo getInstance() {
  return INSTANCE;
 }
}

Everything is good except its early loaded singleton. Lets try lazy loaded singleton

class Foo {

 // Our now_null_but_going_to_be sole hero
 private static Foo INSTANCE = null;

 private Foo() {
  if (INSTANCE != null) {
   // SHOUT
   throw new IllegalStateException("Already instantiated");
  }
 }

 public static Foo getInstance() {
  // Creating only when required.
  if (INSTANCE == null) {
   INSTANCE = new Foo();
  }
  return INSTANCE;
 }
}

So far so good but our hero will not survive while fighting alone with multiple evil threads who want many many instance of our hero.
So lets protect it from evil multi threading

class Foo {
 private static Foo INSTANCE = null;

 // TODO Add private shouting constructor
 public static Foo getInstance() {
  // No more tension of threads
  synchronized (Foo.class) {
   if (INSTANCE == null) {
    INSTANCE = new Foo();
   }
  }
  return INSTANCE;
 }
}
but it is not enough to protect out hero, Really!!! This is the best we can/should do to help our hero
class Foo {
 // Pay attention to volatile
 private static volatile Foo INSTANCE = null;

 // TODO Add private shouting constructor

 public static Foo getInstance() {
  if (INSTANCE == null) { // Check 1
   synchronized (Foo.class) {
    if (INSTANCE == null) { // Check 2
     INSTANCE = new Foo();
    }
   }
  }
  return INSTANCE;
 }
}

This is called "Double-Checked Locking idiom". It's easy to forget the volatile statement and difficult to understand why it is necessary. 

Now we are sure about evil thread but what about the cruel serialization? We have to make sure even while deserialiation no new object is created

class Foo implements Serializable {

 private static final long serialVersionUID = 1L;

 private static volatile Foo INSTANCE = null;

 // Rest of the things are same as above

 // No more fear of serialization
 @SuppressWarnings("unused")
 private Foo readResolve() {
  return INSTANCE;
 }
}
The method readResolve() will make sure the only instance will be returned, even when the object was serialized in a previous run of our program.

Finally we have added enough protection  against threads and serialization but our code is looking bulky and ugly. Lets give our hero a make over

public final class Foo implements Serializable {

 private static final long serialVersionUID = 1L;

 // Wrapped in a inner static class so that loaded only when required
 private static class FooLoader {
  // And no more fear of threads
  private static final Foo INSTANCE = new Foo();
 }

 // TODO add private shouting construcor

 public static Foo getInstance() {
  return FooLoader.INSTANCE;
 }

 // Damn you serialization
 @SuppressWarnings("unused")
 private Foo readResolve() {
  return FooLoader.INSTANCE;
 }
}
Yes this is our very same hero :)  
Since the line private static final Foo INSTANCE = new Foo(); is only executed when the class FooLoader is actually used, this takes care of the lazy instantiation and is it guaranteed to be thread safe.
And we have came so far, here is the best way to achieve everything we did is best possible way
public enum Foo {
       INSTANCE;
   }
Which internally will be treated as 
public class Foo {

    // It will be our sole hero
    private static final Foo INSTANCE = new Foo();
}
That's it no more fear of serialization, threads and ugly code.
   
This approach is functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks. While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton.
-Joshua Bloch in "Effective Java"      

Now you might have realized why ENUMS are considered as best way to implement Singleton and thanks for your patience :)

Saturday, February 23, 2013

Reverse selected elements in jQuery

You can reverse the selected elements in jQuery using get and reverse methods.  
Just use get and reverse with any jQuery selectors like  
$($("ANY_JQUERY_SELECTOR").get().reverse())
For example   
$("tr") 
Will select all tr elements in order of appearance while
$($("tr").get().reverse())
will select the elements in reverse order of appearance.  

Live Demo.