Thursday, January 2, 2014

org.osgi.framework.BundleException: Exception in org.eclipse.core.resources.ResourcesPlugin.start()

Today morning, one of my colleague was reported that, his eclipse is not launching and It throws below error.

MESSAGE An error occurred while automatically activating bundle
org.eclipse.core.resources (26).
org.osgi.framework.BundleException: Exception in
org.eclipse.core.resources.ResourcesPlugin.start() of bundle org.eclipse.core.resources.
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.s tartActivator

I have verified all the plugins, and could not see any issue with them. So where is the problem then?

I could solve the problem with Option (2).

Option 1: Try launching eclipse in clean mode. This did not work in my case, it was throwing an error before it asks for workspace selection.
> eclipse -clean

Option 2: Delete .metadata/.plugins/org.eclipse.core.resources/.snap file workspace directory.

Option 3: Most of the time option (2) will work, if it's not working, try to delete all files from .metadata/  folder.

After launching your eclipse, you will not find your old projects and workspace preference settings, you need to re-import into eclipse workspace and need to configure eclipse preferences.
Why this would have happened?
As per my understanding, this happens if you closed your eclipse forcefully, shutdown the system forcefully before eclipse closes or some files in workspace metadata would have been modified.
What is this .snap files contain ?
*.snap files represent the changes in workspace state of the IDE during the runtime. This is mostly for eclipse crash recovery plan. When a crash happens these files are used to recover the state of eclipse workspace.

While Eclipse is running, information about what has changed in the workspace is incrementally logged into various "snapshot" files (including .snap). On normal Eclipse shutdown, the complete workspace state is saved and the .snap files are deleted. When Eclipse crashes, the snapshot files are used during the next startup to recover from the crash.

Enable Eclipse verbose for troubleshooting

Have you ever wanted to trace what happens when you start an eclipse, or wanted to check what are the classes are loading during start up or while performing certain action.

Just to mention my use case, I was facing the below problem,

java.lang.LinkageError: loader constraint violation: when resolving method "com.kk.MUtils.logDebug(Lorg/apache/log4j/Logger;Ljava/lang/String;)V" the class loader (instance of java/net/FactoryURLClassLoader) of the current class, com/kk/common/KHttpServletRequestWrapper, and the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) for resolved class, com/kk/MUtils, have different Class objects for the type com.kk.MUtils.logDebug(Lorg/apache/log4j/Logger;Ljava/lang/String;)V used in the signature

From the above error, we can understand that Logger class is the issue, it was loaded multiple times by different class loaders and they could not link each other since both of them are loaded by different class loaders.

My call request involves multiples plug-ins, I wanted to check which of the plugins are loading Logger class to identify a root cause of the problem.

To get all that info, we can make use of java verbose vm parameter.

so how do we enable that ?

By default, eclipse launches with javaw.exe process, since it's a window thread so you will not be able to see any verbose messages.

Step 1:  Add below VM parameter in eclipse.ini file. By default, eclipse will have javaw.exe, modify it to java.exe

Step 2: Pass verbose parameter during the eclipse launch.
> eclipse -verbose

This will open up a console window to display all log messages.

Write it to a file:
To write log messages to a file, use below command.
>eclipse -verbose  >mytracelog.txt

You can find this file in eclipse root directory.

You can also provide complete file system path, if required.
>eclipse -verbose  >C:\kk\logs\mytracelog.txt

You can also add verbose parameter in eclipse.ini vm parameters.

Java Decompiler

Decompiler is to convert java .class files into java source files. This would be useful, If you don't have source code of a particular jar file, but you wanted to check the source of it. 

I am using below Java decompiler for last few years, and it was very much useful to me.

You can directly download:

If you are working with eclipse, please find the update site below.

Thursday, December 26, 2013

JStack - Generating stack dump

This would be useful to analyze a root cause, when an application has suddenly stopped working or not responding . There could be a some kind of deadlock or waiting processes or something else. 
JStack would help in getting the stack dump to a currently running java process.

JStack comes along with JDK kit, need not to install separately.

Go to command prompt, type below command with java process id.

>jstack <pid>

To identify the java process id, you can 'jps' command.

>jps  => this will list out the all java process id's.
5730 main  => this is my java process id.
10800 jps

To get more details about which process ID belongs to which process use below command
> jps -ml

To get the additional information about the locks.
>jps  -l  <pid>

Jstack can also be used to get the thread dump for remotely running processes.
>jps  <remote host name/ip address>

To write stack dump to a file:
>jstack -l 7840 >  D:\Test\kklog.txt

">" is important to write into a file.

Some useful resources on this.

Monday, December 9, 2013

UseCompressedOops flag with java

Recently one of colleague was unable to launch eclipse, it says ‘Java returned with exit code =1’ , we have tried lot of options by increasing heap memory and all, but finally what worked out for him was by setting a  UseCompressedOops flag in eclipse configuration file.

He was using 64 bit machine and 64 bit JVM.

Here is the story, what compressed flag does.

The -XX:+UseCompressedOops option can improve performance of the 64-bit JRE when the Java object heap is less than 32 gigabytes in size. In this case, HotSpot compresses object references to 32 bits, reducing the amount of data that it must process.

Compressed oops is supported and enabled by default in Java SE 6u23 and later. In Java SE 7, use of compressed oops is the default for 64-bit JVM processes when -Xmx isn't specified and for values of -Xmx less than 32 gigabytes. For JDK 6 before the 6u23 release, use the -XX:+UseCompressedOops flag with the java command to enable the feature.

In summary:
Java version <6u23 - use command to set it.
Java version >=6u23 - by default enabled.
JDK7 - if -xmx not specified or -xmx <32GB => configured bydefault

You might have a question how does 64 bit pointer fits into 32 bit pointer, how it will be compressed. Please go through below link to understand more about it.

This is how JRocket JVM is compressing it, this will give us some understanding.

Java code to Java Heap

This is an excellent article which describes how Java 32 bit and 64 bit processes works with various primitives and objects in Java.

Comparing 2 files

If you wanted to know whether 2 files is having same content or not, you need not to compare two files line by line, instead you can compare checksums of each file.

For this, you need to use Apache common-codec_1.7.jar file.


package com.kk;


import org.apache.commons.codec.digest.DigestUtils;

public class CompareFiles {

public static boolean compare(String oldFile, String newFile) throws IOException {
FileInputStream fis1 = new FileInputStream(oldFile);
String oldmd5 = DigestUtils.md5Hex(fis1);// old file checksum
FileInputStream fis = new FileInputStream(newFile);
String latestmd5 = DigestUtils.md5Hex(fis); // new file checksum
return oldmd5.equals(latestmd5);
public static void main(String[] args) {
String oldFile = "D:\\Work\\test\\js\\kklibrary.js";
String newFile = "D:\\Work\\test\\kklibrary.js";
try {
boolean compare = compare(oldFile, newFile);
System.out.println("Both files are: "+ compare);
} catch (IOException e) {