Add PATH for MAC or Linux temporarily

PATH=$PATH\:/dir/path

/dir/path is the path you want to add to your $PATH

How to export all resources into runnable JAR file in Eclipse?

Well, the post title says it all.
I was stuck in doing that, but today I've found the solution.

For example, I have the directory tree like this:

• src
• net.leolink.project_name.resources
• myicon.png
• net.leolink.project_name.client
• MainFrame.java

In file "MainFrame.java" I want to display "home.png", so I used this code:

ImageIcon icon = new ImageIcon(this.getClass().getResource("../resource/home.png"));
JLabel lb = new JLabel(icon);

Of course, it works well when you compile in Eclipse, but then you export to runnable JAR file (File->Export->Java->Runnable JAR file), and try to run the JAR file with command line you will get the error like:

Exception in thread "main" java.lang.NullPointerException
    at javax.swing.ImageIcon.<init>(ImageIcon.java:181)
    at net.leolink.project_name.client.MainFrame.<init>(Main.java:15)
    at net.leolink.project_name.client.MainFrame.main(Main.java:27)

So what is the solution?
It's so simple, just change your code to (notice the bold texts):

ImageIcon icon = new ImageIcon(this.getClass().getClassLoader().getResource("net/leolink/project_name/resource/home.png"));
JLabel lb = new JLabel(icon); 

Then try to export again, the exported JAR file should work well ;)

Difference between volatile and synchronized

volatile is a field modifier, while synchronized modifies code blocks and methods. So we can specify three variations of a simple accessor using those two keywords:

         int i1;              int geti1() {return i1;}
volatile int i2;              int geti2() {return i2;}
         int i3; synchronized int geti3() {return i3;}

geti1() accesses the value currently stored in i1 in the current thread. Threads can have local copies of variables, and the data does not have to be the same as the data held in other threads. In particular, another thread may have updated i1 in it's thread, but the value in the current thread could be different from that updated value. In fact Java has the idea of a "main" memory, and this is the memory that holds the current "correct" value for variables. Threads can have their own copy of data for variables, and the thread copy can be different from the "main" memory. So in fact, it is possible for the "main" memory to have a value of 1 for i1, for thread1 to have a value of 2 for i1 and for thread2 to have a value of 3 for i1 if thread1 and thread2 have both updated i1 but those updated value has not yet been propagated to "main" memory or other threads.
On the other hand, geti2() effectively accesses the value of i2 from "main" memory. A volatile variable is not allowed to have a local copy of a variable that is different from the value currently held in "main" memory. Effectively, a variable declared volatile must have it's data synchronized across all threads, so that whenever you access or update the variable in any thread, all other threads immediately see the same value. Generally volatile variables have a higher access and update overhead than "plain" variables. Generally threads are allowed to have their own copy of data is for better efficiency.
There are two differences between volitile and synchronized.
Firstly synchronized obtains and releases locks on monitors which can force only one thread at a time to execute a code block. That's the fairly well known aspect to synchronized. But synchronized also synchronizes memory. In fact synchronized synchronizes the whole of thread memory with "main" memory. So executing geti3() does the following:

1. The thread acquires the lock on the monitor for object this .
2. The thread memory flushes all its variables, i.e. it has all of its variables effectively read from "main" memory .
3. The code block is executed (in this case setting the return value to the current value of i3, which may have just been reset from "main" memory).
4. (Any changes to variables would normally now be written out to "main" memory, but for geti3() we have no changes.)
5. The thread releases the lock on the monitor for object this.

So where volatile only synchronizes the value of one variable between thread memory and "main" memory, synchronized synchronizes the value of all variables between thread memory and "main" memory, and locks and releases a monitor to boot. Clearly synchronized is likely to have more overhead than volatile.

Source: http://javaexp.blogspot.com/2007/12/difference-between-volatile-and.html

Do you ever use the "volatile" keyword in Java?

I haven't ever :( I even haven't ever heard about it before reading this post on stackoverflow.com: http://stackoverflow.com/questions/698964/checking-if-a-clientsocket-has-disconnected-in-java-hangs
And here is something I've found on the net:

• http://stackoverflow.com/questions/106591/do-you-ever-use-the-volatile-keyword-in-java
• http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.3.1.4

8.3.1.4. volatile Fields

The Java programming language allows threads to access shared variables (§17.1). As a rule, to ensure that shared variables are consistently and reliably updated, a thread should ensure that it has exclusive use of such variables by obtaining a lock that, conventionally, enforces mutual exclusion for those shared variables.

The Java programming language provides a second mechanism, volatile fields, that is more convenient than locking for some purposes.

A field may be declared volatile, in which case the Java Memory Model ensures that all threads see a consistent value for the variable (§17.4).

It is a compile-time error if a final variable is also declared volatile.

Example 8.3.1.4-1. volatile Fields

If, in the following example, one thread repeatedly calls the method one (but no more than Integer.MAX_VALUE times in all), and another thread repeatedly calls the method two:

class Test {
    static int i = 0, j = 0;
    static void one() { i++; j++; }
    static void two() {
        System.out.println("i=" + i + " j=" + j);
    }
}

then method two could occasionally print a value for j that is greater than the value of i, because the example includes no synchronization and, under the rules explained in §17.4, the shared values of i and j might be updated out of order.

One way to prevent this out-or-order behavior would be to declare methods one and two to be synchronized (§8.4.3.6):

class Test {
    static int i = 0, j = 0;
    static synchronized void one() { i++; j++; }
    static synchronized void two() {
        System.out.println("i=" + i + " j=" + j);
    }
}

This prevents method one and method two from being executed concurrently, and furthermore guarantees that the shared values of i and j are both updated before method one returns. Therefore method two never observes a value for j greater than that for i; indeed, it always observes the same value for i and j.

Another approach would be to declare i and j to be volatile:

class Test {
    static volatile int i = 0, j = 0;
    static void one() { i++; j++; }
    static void two() {
        System.out.println("i=" + i + " j=" + j);
    }
}

This allows method one and method two to be executed concurrently, but guarantees that accesses to the shared values for i and j occur exactly as many times, and in exactly the same order, as they appear to occur during execution of the program text by each thread. Therefore, the shared value for j is never greater than that for i, because each update to i must be reflected in the shared value for i before the update to j occurs. It is possible, however, that any given invocation of method two might observe a value for j that is much greater than the value observed for i, because method one might be executed many times between the moment when method two fetches the value of i and the moment when method two fetches the value of j.

See §17.4 for more discussion and examples.

Just a tips with grep

It searches recursively, ignores binary files, and doesn't look inside Subversion hidden folders.(...)

grep -Ir --exclude="*\.svn*" "pattern" *

Daemon Thread and User Thread

In java we have two type of Threads : Daemon Thread and User Threads. Generally all threads created by programmer are user thread (unless you specify it to be daemon or your parent thread is a daemon thread). User thread are generally meant to run our programm code. JVM doesn't terminates unless all the user thread terminate. 

On the other hand we have Daemon threads. Typically these threads are service provider threads. They should not be used to run your program code but some system code. These thread run parallelly to your code but survive on the mercy of the JVM. When JVM finds no user threads it stops and all daemon thread terminate instantly. Thus one should never rely on daemon code to perform any program code. 

For better understanding consider a well known example of Daemon thread : Java garbage collector. Garbage collector runs as a daemon thread to reclaim any unused memory. When all user threads terminates, JVM may stop and garbage collector also terminates instantly.

Some tips for Mac users

Show all hidden files:

defaults write com.apple.finder AppleShowAllFiles TRUE
killall Finder

Unlock folder recursively:

sudo chflags -R nouchg * ./