This benefit pales in comparison to proper integration with your source code. Especially because a lot of other JVM languages will produce class files that look like they were written in java code with a lot of potential bugs in it. It's just that the potential bugs never show up, and the compiler knew about it. In other words, you get a bunch of false positives.
False positives that you can't properly ignore = absolutely unusable error checker. (there's another issue right there: Its hard to tell findbugs to ignore a certain problem in future runs because you've inspected it and come to the conclusion that there's no problem and there's no sane way to rewrite the code to appease findbugs. Contrast to the existence of @SupressWarnings) FindBugs is great. Stellar, even. Someone should just rewrite it from scratch, take every case that it analysis, and rewrite it to analyse a java AST node. It's a shame that eclipse is still using a lexer/parser/ AST generator adapted from an Ada parser back from the 1980s (really, eclipse, there's a reason people laugh behind your back sometimes), so whatever plugin you produce won't integrate nicely into eclipse, but at least IDEA and NetBeans both do use (slightly hacked versions of) javac for their AST nodes. My biggest issue is that a bunch of projects are creating a source-level error checker and coming up with their own checks instead of looking at findbugs' extensive library (e.g. arguscodewatch, a very very nicely integrated eclipse plugin), and most of those don't try to interoperate. I guess what I'm saying is, that I'm annoyed that there is no open source project out there that has given itself the mission of rewriting ALL of findbugs to the source level. On Sep 5, 11:33 pm, Alexey Zinger <[EMAIL PROTECTED]> wrote: > Yeah, but at the same time it allows you to inspect binaries produced from > other JVM languages. > > Alexey > 2001 Honda CBR600F4i (CCS) > 1992 Kawasaki > EX500http://azinger.blogspot.comhttp://bsheet.sourceforge.nethttp://wcollage.sourceforge.net > > --- On Fri, 9/5/08, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > > > From: Reinier Zwitserloot <[EMAIL PROTECTED]> > > Subject: [The Java Posse] Re: Java Posse #201 - FindBugs plugin for > > IntelliJ IDEA > > To: "The Java Posse" <[email protected]> > > Date: Friday, September 5, 2008, 4:56 PM > > One major, humongous, huge, enormous, incredible STUPID > > aspect of > > FindBugs is that it works on class files. > > > D'oh. > > > Source-level static analysis means your error/warning is > > better > > focused on the problematic AST Node, and its much easier to > > program > > 'quick fixes' right in there. I'm still waiting > > for a rewrite of > > findbugs that works on source and not class files. Until > > then, I > > understand looking at findbugs, going: Neat, we should have > > something > > like that! - and then not using it all and rewriting its > > features > > instead. It's unfortunate that the various efforts > > happening to get > > there aren't communicating. > > > On Sep 5, 12:15 am, Casper Bang > > <[EMAIL PROTECTED]> wrote: > > > We used to say "If it compiles, the crap > > works". Now a day, with all > > > the annotation cr... stuff, this doesn't seem to > > hold true any longer. > > > > /Casper > > > > On Sep 4, 10:38 pm, Christian Catchpole > > <[EMAIL PROTECTED]> > > > wrote: > > > > > I'm thinking of writing something called > > HideBugs, which rather than > > > > pointing them out, simply obfuscates them.. > > What you don't know won't > > > > hurt you I reckon. Michael, you use something > > similar don't you? :) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
