[FB-Discuss] integration with Checkstyle

Oliver Burn oliver at puppycrawl.com
Tue Sep 14 19:39:26 EDT 2004


Hi David,

Thanks for adding the URL support, and it is certainly a way to
integrate with Checkstyle.

Note, I am unable to locate Class files using the "java.class.path"
system property as Checkstyle is configured in different ways and does
not always use the system classpath. For example, when run via ANT it is
possible to specify the classpath to use.

However, the following utility method can be used to locate the physical
Class file for a java.lang.Class object:

    public static URL getUrlFor(final Class clazz)
    {
        final String resName = clazz.getName().replace('.', '/') + ".class";
        return clazz.getClassLoader().getResource(resName);
    }


The concern I have about not providing the ability to supply a
java.lang.Class object directly is performance. With the proposed
approach, even though Checkstyle already has the java.lang.Class object
in memory, the following will happen:

  * Checkstyle will use utility above to generate a URL. I assume this
    will require checking the file system.

  * The URL will be passed to FindBugs, which will then reload the Class
    file from the file system into memory.


This is bound to be orders of magnitude slower that just being able to
supply the java.lang.Class object. Checkstyle had a major performance
increase in the past when we stopped loading the source file from disk
twice.

So I would suggest that is would be beneficial to also be able to supply
the java.lang.Class object. Checkstyle would not necessarily be the only
user of this method. Having this method would make it possible to
develop a webapp that one can upload a Class (or JAR) file for
processing by FindBugs. With this method, the uploaded file would not
have to written to disk before processing by FindBugs.

Regards,
Oliver

David Hovemeyer said:
> On Fri, Sep 10, 2004 at 02:10:34PM -0400, dbrosius at qis.net wrote:
>> Quoting Brian Goetz <brian at quiotix.com>:
>>
>> > This seems reasonable.  And some others:
>> >    addClass(Class)
>> >    addClass(InputStream)
>> >    addClass(File)
>> >    addJar(File)
>> >    addJar(InputStream)
>> > and even
>> >    addWar(File|InputStream) which could take apart the WAR and add any
>> > JARs or classes it finds...
>> >
>>
>> addClass(URL);
>> addJar(URL);
>
> Here is my $.02.
>
> The Project class, in general, tells FindBugs what code
> to analyze.  I don't like the idea of incorporating things like
> Class and InputStream objects that are only meaningful at
> runtime.
>
> However, I do agree that having a more flexible way to specify where
> to look for code to analyze is a good idea.  So, I went ahead and
> implemented Dave's suggestion of using URLs.  You can add a
> URL (in string form) using the addJar() method.  If you pass a
> string that isn't a URL (i.e., no protocol), we assume it should
> be a file URL (and prepend "file:" in the appropriate place).
>
> [Aside: the addJar() method is misnamed.  You can specify a jar
> file, zip file, single classfile, or directory, and FindBugs
> will do the right thing.  "addCodeSource()" would really be a
> better name.  Maybe we should change it at some point.]
>
> To support Oliver's scenario where you have a Class object you want
> to analyze, you just need to search through the classpath
> (i.e., "java.class.path" system property) until you find the codebase
> that defined the class.  Then you can construct either a
> file: or jar: URL to refer to the class.
>
> Regarding when 0.8.5 will come out: sometime in the next month
> would be my guess.
>
> -Dave
>
>





More information about the Findbugs-discuss mailing list