Yes, findbugs works on class files right now, but there's no reason why it couldn't work on source files. Some projects have tried (arguscodewatch for example) and while they're mostly inactive at this point, source-level scanning is better in many ways; you can have quick fix suggestions and certain findbugs-esque things can only be detected on the source level and no longer in the class level.
So, perhaps not findbugs per se, but some sort of serious static analysis tool, at least. findbugs as a 'check somebody else's already compiled stuff' can stay separate. Also, the programming world as a whole is steadily moving towards more open source. You can see this in the tooling as well: obfuscators have virtually disappeared from the map and nobody cares enough about 'decompiling' java 1.5+ class files to write a good decompiler. So, if you're going to add new tooling, it should definitely focus on source files and not on class files. Nobody is talking about forcing anything. @SuppressWarnings exists for a reason. The compiler is there to tell you there's a problem you should look at, and when you've looked at it, you can easily tell the compiler to shut up henceforth. At least, that's the idea. On Feb 26, 3:41 pm, robilad <[email protected]> wrote: > On Feb 26, 5:04 am, Reinier Zwitserloot <[email protected]> wrote: > > > What are the downsides of > > integrating findbugs into javac, especially if it is done in a way > > that you can easily replace findbugs or upgrade that part of it > > separately? > > Well, the point of javac is that it operates on Java source code. The > idea > behind findbugs is that it operates on Java bytecode - because for > most > binaries out there, there is no way to reliably rebuild them even if > you > want to, so bytecode is what a typical static analysis tool works > with, if it > wants to reach an audience outside the top development shops that > have > their full dependency chain's source code under their control and can > rebuild it on a spot. :) > > The real value of tools like findbugs is not in checking your own, > hopefully > spotless code that you have the source code for .- it's in checking > your > potential dependencies before you commit to using them, so that you > can > weed out the bad choices in advance. 'L'enfer, c'est les autres.' > > So yeah, one could rewrite findbugs to do its checking on source code > instead, and thereby limit its usefulness to people who always have > all > the sources they need, or one could leave it as it is, and run it on > bytecode produced by javac - but that's something everyone can do > (and hopefully does) already anyway. > > Should my IDE run findbugs for me and tell me that my dependencies > are quite likely junk software? Yes, please. Should my IDE be able > to > tell me that the tomcat JAR I'm using in my project through Maven > hasn't been updated in the Maven repo to fix a dozen serious CVEs? > Hell, yeah. Should an IDE force someone to do something about it? > Well, > probably not - a lot of people are stuck with their or their > predecessors > legacy of mvn-snapshot jars, code without adequate test coverage, and > what not - they can't change their environments overnight, sometimes > not > at all (never touch a running system). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
