Architectual problems

Local variables that shadow accessible fields

A local variable shadows an accessible and compatible field, which might be a programming error.

Solution: consider using the field or renaming the local variable

Severity level: 1

Field declarations that shadow accessible fields in a super type

A field declared in class shadows an accessible and compatible one in a super class, which might be a programming error.

Solution: remove the field, if appropriate

Severity level: 1

Class implementing an interface already implemented by a superclass

This class declares an interface in its "implements" declaration which is already implemented by a super class. Methods required by that interface might be implemented in the class, inadvertently overriding methods of the super class.

Solution: remove the interface from the "implements" section and check if methods required by the interface are necessary on the offending class. Caveat: serializable classes without a serialversionUID will change their UID value.

Severity level: 2

Interface declaring a method already declared by an extended interface

An interface declares a method that is already declared by one of the interfaces it extends.

Solution: remove the method from the interface declaration

Severity level: 3

Abstract class without abstract method

This abstract class doesn't define any abstract method, and the abstract keyword was probably only used to prevent instantiation.

Solution: use a private constructor instead, or a protect one if the class has subclasses.

Severity level: 3

Abstract methods overrides abstract method

An abstract methods overrides an abstract method declared in a superclass.

Solution: remove the method in the subclass.

Severity level: 3

Empty method implementation in abstract class

An empty method implementation in an abstract class was detected. It may be better to declare the method abstract, and have concrete subclasses implement the appropriate behavior.

Solution: Consider declaring the method abstract.

Severity level: 3

Abstract class without abstract method

This abstract class doesn't define any abstract method, and the abstract keyword was probably only used to prevent instantiation.

Solution: use a private constructor instead, or a protect one if the class has subclasses.

Severity level: 3

Abstract class without any method

This abstract class doesn't define any method, and could be replaced by a marker interface. Subclasses are then free to use any superclass.

Solution: use an interface instead

Severity level: 3

A class using any of its subclasses

A type referencing one of its derived types breaks object encapsulation. This is not an issue if the class implements a class cluster.

Solution: revisit the inheritance hierarchy and prefer to use polymorphism

Severity level: 3

Poor exception propagation

Poor exception propagation by throwing general purpose exceptions such as java.lang.Throwable, java.lang.Exception, java.lang.Error, or java.lang.RuntimeException.

Solution: replace with more specific exceptions from the Java libraries, or create your own.

Severity level: 4