What does these FindBug messages show?

Not every description from from http://findbugs.sourceforge.net/bugDescriptions.html is clear to me. Sure, I can study the implementation but if somebody is more experienced then me, some explanation and examples would be great.

• Do you have some examples for UI_INHERITANCE_UNSAFE_GETRESOURCE when this is getting a problem?
• In BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR I don't see the problem either. If one type is "bigger" then the other, for example int and float, then the result is float. If its Integer and Float its the wrapper Float too. That's what I expect.
• Does the GC_UNRELATED_TYPES really help to find errors? Isn't it the job of the compiler to check, if--taking the given example--Foo can't go into a Collection<String>.
• Does HE_SIGNATURE_DECLARES_HASHING_OF_UNHASHABLE_CLASS mean something like bla(Foo f){hashtable.put(f);}, where ´Foo´ is not hashable? Does FingBugs "see" the subclasses too?
• NP_GUARANTEED_DEREF_ON_EXCEPTION_PATH is stronger "wrong" then NP_ALWAYS_NULL_EXCEPTION? Why two error cases and with NP_NULL_ON_SOME_PATH_EXCEPTION even one more? Sounds very similar to me.
• What is an example of SIO_SUPERFLUOUS_INSTANCEOF? Something like foo(String s){if (s intenceof String) .... This does a null check too, but this is not the test here...
• NN_NAKED_NOTIFY. I my opinion the description is not clear. A change of the state is not necessary. If I use new Object() to wait and notify on I don't change the object state. Or is state the lock-state? I don't get it.
• SP_SPIN_ON_FIELD. Can this really happen that a compiler will move this outside from a loop? This do开发者_高级运维esn't make sense to me because from outside a Thread can always change the values. And if the variable is volatile the JVM can't cache the value. So what's the meaning?
• That is the difference between STCAL_STATIC_CALENDAR_INSTANCE and STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE or STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE/STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE?
• Why is XXXX.class in WL_USING_GETCLASS_RATHER_THAN_CLASS_LITERAL better then getClass()? A getClass() in a superclass called from the subclass will always return the Class object from the subclass which is good I think.
• What exactly does EQ_UNUSUAL do? It should check that the argument is of the same type of the class itself but it does't?
• Did you ever had problems with breaks? Is there real value with SF_SWITCH_FALLTHROUGH? Sounds to strong for me.
• No idea what TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_ALWAYS_SINK and TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_NEVER_SINK could be.

I can comment on some of the FindBugs descriptions you mention, based on my experience and testing, without consulting the FindBugs source code.

• UI_INHERITANCE_UNSAFE_GETRESOURCE: If you use this.getClass().getResource(...) with a relative URI, that URI is resolved with respect to the class of this. When a subclass resides in a different package and you get the resource for a subclass, you end up looking at a different place (relative to the subclass). I know of examples where a class looks for a resource known to reside in the same package, by calling getResource() with a relative URI containing only the filename. If that class where to use this.getClass() instead of ClassName.class, and the actual instance is of a subclass, the resource would not be found.

• BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR: This talks about boxed number types, like Integer and Float, as opposed to primitive number types, like int and float. For primitives, your expectation is correct: In boolean ? int : float the int is coerced to float. But for wrapped numbers, something unexpected happens: In boolean ? Integer : Float, the Integer is unboxed and coerced to float. I would have expected the objects to be returned unchanged, like in boolean ? (Number)Integer : Float.

  boolean b = Boolean.TRUE;
  final Integer i = 123456789;
  final Float f = 1.0f;
  final Number x = b ? i : f;
  System.out.println("wrapped coerced: " + x); // 1.23456792E8
  final Number y = b ? (Number) i : f;
  System.out.println("wrapped uncoerced: " + y); // 123456789
  

• GC_UNRELATED_TYPES: FindBugs knows about some collection methods that could not be generified for Java 1.5, like Collection.contains(Object). Here, the argument must be of type Object, because otherwise existing source code might break. But any object not of the collection's type is sure to be not contained, so asking for containment of an Integer in a String collection probably is a bug.

  Collection<String> coll = new ArrayList<String>();
  System.out.println(coll.contains(42));
  

• HE_SIGNATURE_DECLARES_HASHING_OF_UNHASHABLE_CLASS: ?

• NP_GUARANTEED_DEREF_ON_EXCEPTION_PATH: ?

• SIO_SUPERFLUOUS_INSTANCEOF: ?

• NN_NAKED_NOTIFY: ?

• SP_SPIN_ON_FIELD: If you spin on a field that is not volatile, the JIT is free to optimize the code (by moving the read out of the loop) as long as the thread executing the loop produces the same result, without taking into account the existence and actions of other threads. That's why there is a volatile keyword. I know of no example where this actually lead to a bug.

• STCAL_STATIC_CALENDAR_INSTANCE: ?

• WL_USING_GETCLASS_RATHER_THAN_CLASS_LITERAL: In the FindBugs example, the method synchronizes on getClass() to access a static member of its class. A subclass will synchronize on the subclass, and so the superclass and the subclass can enter the synchronized block at the same time because they synchronize on different monitors, leading to a race condition.

• EQ_UNUSUAL: ?

• SF_SWITCH_FALLTHROUGH: This helps me sometimes, because I tend to miss the break. Interestingly, in a test case just performed, I got in addition to this FindBugs message the message SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH.

• TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_ALWAYS_SINK: ?