Eclipse workspace

I use eclipse for all development activities and started with multiple copies of eclipse for each topic.  Say I am learning JUNIT, will have eclipse installation in one folder.  Similarly I used to have a different installation for learning generics/annotations, android, webservices etc.

Over time I realized that in most cases I am using same version of eclipse and this setup is taking up lot of space (this is not really a big issue).  As I started experimenting with maven and other code quality/metric tools, I needed to do the installation of these plugins in every installation of eclipse.

Another possible option is to have single eclipse installation with different workspaces for each specific task.  This addresses the space issue, but I still need to install the plugins in different workspaces again and again.  Having unrelated plugins takes up lot of memory and slows down the eclipse itself.

How about having workspaces for different plugins (grouped logically) and use whichever plugin set is required for your task?  Not sure, but I do not have any better options at this point.  While I play around on how to manage my workspace below trick would help in identifying which workspace is currently being used:

Add -showlocation as the first line in eclipse.ini, which would show the workspace name in the title bar.

BigDecimal to String conversion

We have just realised one more non obvious issue with toString() method of BigDecimal while migrating from jdk1.4 to 1.6

Since Java 5, the toString method started printing the value in scientific form if scale is more than 6, so our messages going out have become wrong; no coding issues, its like silent killer :-)  Good lesson for me is to override this method whenever the output make a difference even though the default is enough.  The new method added is toPlainString() to get what toString() is doing earlier.

What is JIT

The Just-In-Time (JIT) compiler is a part of JVM to improve application performance.

As we all know the class files generated with javac contain platform-independent bytecodes to be interpreted by a JVM on specific OS/machine.  Due to this interpretation performance will be slow than that of a native application.  The JIT compiler compiles bytecodes into native machine code at run time and helps in improving the performance.  Below are some points to be noted:

• It is enabled by default, and is activated when a Java method is called.
• It compiles the bytecodes of that method into native machine code, compiling it "just in time" to run.
• After a method is compiled, JVM calls the compiled code directly instead of interpreting it.
• Methods are not compiled the first time they are called.  For each method, JVM maintains a call counter.  JVM interprets a method until its call count exceeds a JIT compilation threshold.
• After a method is compiled, its call count is reset to zero and subsequent calls to the method will continue to increment its count.  When the call count of a method reaches the JIT recompilation threshold, the JIT compiler compiles it a second time, applying further optimizations than on the previous compilation.  This process is repeated until the maximum optimization level is reached.
• The JIT compiler can be disabled (-Xint interpret-only mode), in which case the entire Java program will be interpreted.