From 4bbc0f515d83b57b0629cac40d1059791b963ec9 Mon Sep 17 00:00:00 2001 From: Evgeny Mandrikov Date: Sun, 30 Jan 2011 01:45:58 +0300 Subject: SONAR-1280: Add experimental Findbugs rules --- .../resources/org/sonar/plugins/findbugs/rules.xml | 156 ++++++++++++++++++++- 1 file changed, 154 insertions(+), 2 deletions(-) diff --git a/plugins/sonar-findbugs-plugin/src/main/resources/org/sonar/plugins/findbugs/rules.xml b/plugins/sonar-findbugs-plugin/src/main/resources/org/sonar/plugins/findbugs/rules.xml index 577575cd2c5..cb1c9949065 100644 --- a/plugins/sonar-findbugs-plugin/src/main/resources/org/sonar/plugins/findbugs/rules.xml +++ b/plugins/sonar-findbugs-plugin/src/main/resources/org/sonar/plugins/findbugs/rules.xml @@ -4389,5 +4389,157 @@ public @NonNegative Integer example(@Negative Integer value) { This method does not override the toString() method in java.lang.Object, which is probably what was intended.

]]> - - \ No newline at end of file + + + + + + + This constructor calls methods in the parent Applet that rely on the AppletStub. Since the AppletStub + isn't initialized until the init() method of this applet is called, these methods will not perform + correctly. +

]]> + + + + + + + This method invokes the .equals(Object o) method on a final class that doesn't override the equals method + in the Object class, effectively making the equals method test for sameness, like ==. It is good to use + the .equals method, but you should consider adding an .equals method in this class. +

+

[Bill Pugh]: Sorry, but I strongly disagree that this should be a warning, and I think your code + is just fine. Users of your code shouldn't care how you've implemented equals(), and they should never + depend on == to compare instances, since that bypasses the libraries ability to control how objects + are compared. +

]]> + + + + + + + This class has a circular dependency with other classes. This makes building these classes + difficult, as each is dependent on the other to build correctly. Consider using interfaces + to break the hard dependency. +

]]> + + + + + + + This method of an inner class reads from or writes to a private member variable of the owning class, + or calls a private method of the owning class. The compiler must generate a special method to access this + private member, causing this to be less efficient. Relaxing the protection of the member variable or method + will allow the compiler to treat this as a normal access. +

]]> + + + + + + + This derived method merely calls the same superclass method passing in the exact parameters + received. This method can be removed, as it provides no additional value. +

]]> + + + + + + + This abstract method is already defined in an interface that is implemented by this abstract + class. This method can be removed, as it provides no additional value. +

]]> + + + + + + + This method may fail to clean up (close, dispose of) a stream, + database object, or other + resource requiring an explicit cleanup operation. +

+

+ In general, if a method opens a stream or other resource, + the method should use a try/finally block to ensure that + the stream or resource is cleaned up before the method + returns. +

+

+ This bug pattern is essentially the same as the + OS_OPEN_STREAM and ODR_OPEN_DATABASE_RESOURCE + bug patterns, but is based on a different + (and hopefully better) static analysis technique. + We are interested is getting feedback about the + usefulness of this bug pattern. + To send feedback, either: +

+ +

+ In particular, + the false-positive suppression heuristics for this + bug pattern have not been extensively tuned, so + reports about false positives are helpful to us. +

+

+ See Weimer and Necula, Finding and Preventing Run-Time Error Handling Mistakes, for + a description of the analysis technique. +

]]> + + + + + + + FindBugs generated a warning that, according to a @NoWarning annotated, + is unexpected or undesired +

]]> + + + + + + + FindBugs didn't generate generated a warning that, according to a @ExpectedWarning annotated, + is expected or desired +

]]> + + + + + + + OpenJDK introduces a potential incompatibility. + In particular, the java.util.logging.Logger behavior has + changed. Instead of using strong references, it now uses weak references + internally. That's a reasonable change, but unfortunately some code relies on + the old behavior - when changing logger configuration, it simply drops the + logger reference. That means that the garbage collector is free to reclaim + that memory, which means that the logger configuration is lost. For example, + consider: +

+ 

public static void initLogging() throws Exception {
+      Logger logger = Logger.getLogger("edu.umd.cs");
+      logger.addHandler(new FileHandler()); // call to change logger configuration
+      logger.setUseParentHandlers(false); // another call to change logger configuration
+      }

+

The logger reference is lost at the end of the method (it doesn't + escape the method), so if you have a garbage collection cycle just + after the call to initLogging, the logger configuration is lost + (because Logger only keeps weak references).

+ 

public static void main(String[] args) throws Exception {
+      initLogging(); // adds a file handler to the logger
+      System.gc(); // logger configuration lost
+      Logger.getLogger("edu.umd.cs").info("Some message"); // this isn't logged to the file as expected
+      }

+

Ulf Ochsenfahrt and Eric Fellheimer +

]]> + + -- cgit v1.2.3