When FindBugs tries to lookup a class, it looks at, in the following
order:
* the classes to be analyzed
* anything that can be loaded from the auxclasspath (if specified)
* anything that can be loaded via sun.boot.class.path or a jar file
contained in java.ext.dirs
(actually, is there a platform independent way of getting the boot
class path? Something that will
work in any JVM?)
The advantage of looking in all three is that it allows FindBugs to
find information about classes and interfaces such as
java.lang.reflect.Type, without having to explicitly pass the JVM
classes to the auxclasspath
However, a user ran into trouble when they were:
* running FindBugs using Java 5
* specifying an auxclasspath that included the Java 1.4 rt.jar file
When FindBugs was run, it resolved some JVM classes from the Java 1.4
rt.jar file,
and some from the Java 5 JVM that was running FindBugs. This resulted
a number of
inconsistencies and problems.
In general, this could happen with any library, if one version is
provided on the auxclasspath
and another version is available via the classpath used to run FindBugs.
So how do we fix this?
One possibility would be to say that if an auxclasspath is specified,
we should ignore the classpath.
But that would mean that if you specify an auxclasspath, you would
need to provide the rt.jar library on it. Which would be a pain.
It seems like a better (but not entirely cheap) solution might be:
* For each entry on the boot class path (i.e., each directory or jar
file),
* if that entry provides a class that is also one of the analyzed
classed, or available via the auxclasspath,
then the findbugs ignores the entry completely.
Does this sound like a good solution? Does anyone have any
alternatives to suggest?
Bill
|
| 
