I’m doing a little hacking on jEdit in preparation for my next article, as well as an upcoming talk at Software Development 2006. After mutliple failed attempts, I finally figure out how to check out the main code base from CVS into Eclipse with assistance from Rick Stabile.
The next step is to run the
main() method. The application starts but no window pops up, and this error message is printed on the console:
[error] Image Fetcher 0: Uncaught error fetching image: [error] Image Fetcher 0: java.lang.NullPointerException [error] Image Fetcher 0: at sun.awt.image.URLImageSource.getConnection(URLImageSource.java:97) [error] Image Fetcher 0: at sun.awt.image.URLImageSource.getDecoder(URLImageSource.java:106) [error] Image Fetcher 0: at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:240) [error] Image Fetcher 0: at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:172) [error] Image Fetcher 0: at sun.awt.image.ImageFetcher.run(ImageFetcher.java:136)
What’s going on here? Grepping through the jEdit source doesn’t find any of those error messages, plus the stack trace doesn’t seem to go into jEdit code at all. Is Eclipse filtering the stack trace somehow? No, it turns out that an uncaught exception only terminates the thread in which it’s thrown, not the entire VM, and this is happening off in a separate thread.
Googling on the error message (a technique more people should use) finds several instances of this problem in different environments going back years. All seem to have the same root cause: something is calling
getImage() to load an image but can’t finds the right file in the class path. That certainly seems possible. Trying to set up jEdit’s classpath in Eclipse has indeed been a royal pain, and I can well believe I might have gotten something wrong. Grepping through the jEdit source finds just a single call to
image = getToolkit().getImage( getClass().getResource("/org/gjt/sp/jedit/icons/splash.png"));
This seems to be trying to load the splash screen and that’s about the point at which jEdit is dying. OK. Why might this be failing? Probably /org/gjt/sp/jedit/icons/splash.png is not in the class path. The next question is to how to tell Eclipse to add this folder full of icons to the class path. The obvious approach (just adding it to the build path using the Add Class Folder… button in the Libraries tab) doesn’t seem to have any affect. What else might? Back to Google. Hmm, this time Google can’t seem to help. None of the search terms I try find anything relevant.
OK. Looks like the problem is that I excluded that folder from the source path when I first configured the project. Now it won’t go back in the right place. OK. Instead of adding it to the source path or the class path let’s try editing the exclusion filters to remove it. Now it at least looks like it’s in the right place. Will it run? Yes! Success. On to what I was actually trying to do in the first place.
Moral of the story: when setting up a project in CVS be sure to have separate source and build directories. In particular, do not just put the roots of the source tree (org, com, installer, bsh, etc.) in the root directory. Put them in a src directory along with anything else that needs to go into the classpath. This helps users avoid adding things to the sourcepath that don’t belong there (as Eclipse did automatically when I first loaded jEdit from CVS) and then helps keep people from removing too much from the source path. To configure jEdit properly, I did in fact need to remove several folders from the sourcepath that Eclipse had put there. The problem was that I removed one too many, and Eclipse was rather thick about figuring out how to put it back.