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 http://serverfault.com/questions/323795/display-complete-command-line-including-arguments-for-windows-process). 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...
refs:
http://www.javahotchocolate.com/tutorials/bad-output-folder.html
Replace nested-if's with proper exception-handling
-
" Why handle exceptions separately:
■ Handling exceptions separately enables you to define the main logic of
your
code together.
■ Without the use of sepa...
2 years ago
