[Bluej-discuss] CheckStyle extension

[Stephen Edwards]

OK, a new version of the checkstyle extension is now ready.
You can pick it up here:

http://web-cat.cs.vt.edu/checkstyle-extension-4.2.zip

This version includes the latest checkstyle release.

It turned out there were some issues in supporting the latest
checkstyle version that were a bit tricky to handle.  These
revealed some problems that hark back to the old "it won't run
under OSX" issues with the checkstyle extension.  For those that
are interested, I'll explain what I found and how I fixed it.
If you're not interested, you can stop reading now :-).

The problem is that checkstyle refers to a number of file
resources (dtd files and other config files).  It does the
normal thing to locate these: uses the class loader's
getResourceAsStream() method, which searches the appropriate
classpath.  Indeed, the corresponding resources are bundled in
the checkstyle jars.

However, whether separate jars, or on unified jar is used, the
code wasn't able to find the necessary files on the classpath.
This is exactly what was happening under OSX with the previous
version of this extension.  So I poked around, and the problem
was *which* classloader checkstyle was using.

Universally in the checkstyle code base, everything uses
Thread.currentThread().getContextClassLoader() to look up
the appropriate class loader.  It appears that for extensions,
the classloader associated with the thread invoking extension
methods is *not* the one that contains the classpath for the
extension's classes.  I ended up changing all references to
use getClass().getClassLoader().  This means that, regardless
of the class loader in effect for the current thread, the
class loader used to load the checkstyle classes would be used
to search for resources.

This might be an implementation issue for the BlueJ extension
folks.  Of course, there's no "right" answer when the thread's
class loader and the library class's class loader are different.
Either one might be the "right" one to use to look up resources
like this.  For the extension mechanism, the question is really
this: is there a useful reason (other than an accident of how the
code was developed) for these two class loaders to be different?
I'm guessing it won't be simple to make them the same, and it may
not be worth it to do so, but this does have implications for
folks writing extensions, especially if those extensions use
external tools that use class loaders in different ways.

But here's the good news: this new version of the extension might
actually work under OSX now.  Possibly.  Maybe.  Or maybe not :-).
Who ever tries it first, please post your experiences.

                                 -- Steve

--
Stephen Edwards            604 McBryde Hall          Dept. of Computer Science
e-mail      : edwards at cs.vt.edu           U.S. mail: Virginia Tech (VPI&SU)
office phone: (540)-231-5723                         Blacksburg, VA  24061
-------------------------------------------------------------------------------