AWG Blogs

Saturday, February 21, 2015

Eclipse Classpath Run Configurations being overwritten

Encountered a strange issue with eclipse (both Luna and Mars) on certain run configurations. What happened was when launching I would almost immediately (after some messages from loading classes) get "Error: Could not find or load [name of the class]" or in some other run configuration a java.lang.ClassNotFoundException and then a stack trace.

This would happen despite cleaning the project, recreating the run configuration, or running eclipse  with the -clean option. The project depended on another project to which I traced the unfound class. This told me that it was a classpath issue; however, the project was clearly listed in the Classpath tab of the run configuration. I even tried exporting the project to a jar and adding it to the local client project build path but that didn't work either.

I then decided to examine the running JVM process. I ran JConsole, attached to the failing process and opened the VM Summary tab. There were a huge number of VM arguments which I scrolled through to get to the Class path entry. The Class path entry had only one entry in it, a single jar file used by the application. There should have been more entries though. I then created a new run configuration using the reverse-engineered items from the output of wmic to get the full command line (see I tried obtaining it from Process Explorer via save but it truncated it because it was very long I guess. The reverse configured run configuration also produced the same errors.

The I did a search for the single jar file that was assigned to the classpath in the long command line figuring it had to be set there somehow. Sure enough it was being assigned via the -Djava.class.path vm argument. Since the jar was already being loaded via the build path I removed the java.class.path argument -- and that resolved the error. Apparently, adding that argument was causing Eclipse to ignore the Classpath as shown in the Classpath tab of the run configuration. This would only happen though using that particular set of VM arguments. If I only added a few VM arguments in addition to the java.class.path argument Eclipse would run the config and no errors would result. Interestingly JConsole would show only the VM arguments other than java.class.path so apparently Eclipse cleans it up, perhaps recognizing whether the entry is needed or already is reflected in the run configuration classpath (update: this seems to indicate java.class.path is not settable; and I wasn't able to prove otherwise, i.e that it was settable, when using test projects and configurations with classpath tweaking by removing the default classpath and adding my own under "User entries").

My guess regarding the error is that the replacing of the run configuration classpath with the value added to java.class.path vm argument is due to either 1) the vm argument list I was using was too long or 2) the vm argument list was corrupted somehow. This cause would be in addition to an existing eclipse state -- most likely the state of the plugins installed. The reason why is that some eclipse installations worked given the same set of vm arguments and all else being equal while other eclipse installations failed. It did so happen that when I uninstalled one custom plugin that did custom run configurations and reinstalled an earlier version of the plugin this solved the issue. However repeating the steps did not solve the issue on other eclipse installations so I could not pinpoint it to the plugin. It therefore must be a combination of plugin installation or absence of and the above faulty set of vm arguments containing the java.class.path entry...


Friday, February 13, 2015

Creating a sequence diagram from a stack trace

Install AmaterasUML:
- download AmaterasUML from
- unzip
- copy the three jars to eclipse plugin folder, e.g. D:\App\eclipse-jee-luna-R-win32-x86_64\eclipse\plugins
- install Graphical Editing Framework eclipse plugin. It was already installed in mine, maybe through a dependency on BPMN2 Modeler or something else.
- restart eclipse
Get the stack trace
- in Eclipse put a breakpoint in some method you want to analyze via sequence diagram
- start debug 
- in the debug view right-click the Daemon Thread and click Copy Stack
- paste into text editor
Fix up stack trace
- remove unwanted lines including lines that end with "line: 1" or start with "Daemon Thread" or "owns:" leaving only the lines that start with entities to be added to the sequence diagram
- save the file e.g. D:\work\AmaterasPrepWork\MyStackTrace.txt
- create a second text file and paste into it the following awk script:
str = $0;\
sub(/^\t/, "", str);\
match(str, /(.*)\./, arr);\
sub(/^/, "at ", str);\
#print str;\
sub(/\([^\)]*\)/, "(", str);\
sub(/ line: /, arr[1]".java:", str);\
sub(/$/, ")", str);\
sub(/\t\)$/, ")", str);\
print str}
- save the file as e.g. D:\work\AmaterasPrepWork\AmaterasPrepProg.txt
- download gawk and run file e.g. gawk-3.1.6-1-setup.exe
- open a command prompt and cd to e.g. D:\work\AmaterasPrepWork
- execute the following commands:
D:\AmaterasPrepWork>set path=%path%;D:\Program Files (x86)\GnuWin32\bin
D:\AmaterasPrepWork>echo awk -f AmaterasPrepProg.txt MyStackTrace.txt ^> out.txt > run.bat
Make sequence diagram in eclipse
- Do Window, Show View, AmaterasUML, Stack Trace Sample, OK
- paste the contents of D:\AmaterasPrepWork\out.txt into the window
- click the 'i' (image of lower case 'i') button in upper right-hand corner of the Stack Trace Sample view
- select a folder in your project as the destination of new sequence
- refresh the folder in eclipse
- open sequence.sqd
- do finishing touches. It appears e.g. that some entities weren't added and need to be added?? will check on this...
- save the file as MySequence.sqd or save sequence.sqd and refactor to another name because AmaterasUML uses sequence.sqd as the target file name evidently.