Thursday, August 19, 2010

Eclipse fails to start?

Your eclipse fails to start? actually we could say your workspace fails to start. I've gone through it several times and my solution was to create a new workspace and import the existing projects into the new workspace.
However, this time I'm trying to solve it once for all (as though it's possible :). Googled around and I found, imho, a rough solution that works for me. It's as simple as deleting org.eclipse.core.resources folder inside {workspace}/.metadata/.plugins and then run eclipse -clean.
The result is eclipse is working but I still have to import the existing projects back. The good thing is I don't lost all the preferences and server setting (though I could just import the preferences file I once exported).

Check the link on the title and also this one, tools from eclipse team that maybe could help with the broken workspace (I never tried it yet... my workspace already fixed :)

Tuesday, August 17, 2010

A bit on classloader

At first glance, I thought java could face the same problem as dll was (dll hell). But then classloader scoping comes to the rescue. And by the way, I won't explain the theory of classloading here. By having classloader scope set to the application, it will allow each application to bring their own libraries without worrying of library conflict.

For example, I built a library of common utilities and there are already 2 versions of it. And 2 of my web applications are using the library, however each with a different versions from the other. If the flat classloading is used, only one of the 2 versions of the library will be used and the impact is the web application which used the version not loaded will have strange errors such as ClassCastException, IllegalAccessErrors and possibly many others. Having classloader scoping will allow each of my web application to use its respective library.

One thing cross my mind, how could I have a smaller deployment size for a web application and still having the classloader scoping. Smaller deployment size here refers to my classes only without the whole bunch of libraries. Usually when people delivers a patch for the web application, all is packed in war file which size is quite large. On my case, the library size are around 80% of the war file size. Up to now, all I can do is to deploy the application as exploded. Thus allowing me to deploy patches by replacing the content/libraries. Not an elegant solution but still a viable one, until I can find a nicer solution.....

Sunday, August 15, 2010

Initialize static List and Map

If you intend to create a List or Map for your constants, here's how you do it.

List

public static String CONSTANT_1 = "1";
public static String CONSTANT_2 = "2";

public static List CONSTANTS = new ArrayList() { {
add(CONSTANT_1);
add(CONSTANT_2);
}};


Map


public static Map CONSTANTS = new HashMap() { {
put("key1", "value1");
put("key2", "value2");
}};


Even better is to wrap the ArrayList/HashMap by passing them to Collections.unmodifiableList or Collections.unmodifiableMap. Thus making sure that it is truly a constant list/map.