Java Developer Tools

Audit - Rules - Modifier Usage

Description
This group contains audit rules that check your code for incorrect uses of modifiers.

Rules:

Details

Anonymous Class Member Visibility

Summary
Members of anonymous classes should be private.

Description
This audit rule checks the visibility of all fields and methods within an anonymous class to ensure that they are declared private (except for methods that override an inherited method). Such fields and methods should be declared private to make it clear that they cannot be accessed outside the anonymous class (and to make it easier to detect dead code).

Example
The following field declaration would be flagged as a violation because it is declared as being public:

    new Runnable() {
        public int x;
        ...
    }

Avoid Package Scope

Summary
Only use public, protected or private scopes.

Description
This audit flags all inner classes, constructors, methods, and fields that have a package scope.

Note: non-inner classes and interfaces cannot syntactically be declared protected or private, thus since a non-inner class/ interface isn't more secure if it has package scope instead of a public scope, this audit does not flag interfaces or non-inner classes that have a package scope.

Also note: the resolutions (fixes) for flagged instances of this audit include the insertion of the "public" modifier as well as "private" and "protected" modifiers. However, changing a modifier from package scope to a public scope does not make the code more secure, and is included only because it is expected that the public modifier is used.

Security Implications
Classes, methods and fields with package scope (default scope) can be accessed from all code within the same package, including code written by adversaries.

Example
The following will all be flagged since they all have a package scope: the constructor "Example", the class "InnerClass", the method "some_method", and the integer "x":

    class Example {
        Example(){super();}
        class InnerClass{}
        static void some_method(){/* do nothing */}
        int x;
    }

Class Should Be Final

Summary
Classes that do not have subclasses should be final.

Description
This audit rule looks for classes that do not have any subclasses but are not marked as final. Note that this rule is only useful if all of the classes in the product are loaded into the development environment.

Security Implications
The ability to extend classes can be abused by a malicious user. They can be used to obtain access to information contained in the parent class.

Example
The following class would be flagged as a violation because it does not have any subclasses, and it isn't marked as final:

    class MyClass
    {
            ...
    }

Final Method Parameter In Interface

Summary
Method parameters in interfaces should not be final.

Description
This audit rule flags any final method parameters defined in interfaces. It is unnecessary to mark an interface methods's parameters as final, since there is no implementation associated with an interface, and making a parameter final only affects the implementation.

Example
The following declaration of the final parameters a and b would be flagged:

    interface foo {
        public void add(final int a, final int b);
    }

Instance Field Visibility

Summary
Instance fields should have an appropriate visibility.

Description
This audit rule checks the visibility of all non-static fields to ensure that it is one of the allowed visibilities.

Example
If the rule were configured to only allow private instance fields, then the following field declaration would be flagged as a violation because it is declared as being public:

    public int x;

Modifier Order

Summary
Modifiers should always appear in the standard order.

Description
This audit rule checks the order in which the modifiers were declared and reports any deviation from the standard (Sun defined) order.

Example
    final static public int ANSWER = 42;

No Abstract Methods

Summary
Classes should not be declared abstract unless they define abstract methods.

Description
This audit rule finds classes that are declared to be abstract but that do not define any abstract methods.

Example
The following class declaration would be flagged as a violation because it does not define any abstract methods:

    public abstract class Widget
    {
    }

No Public Members

Summary
Classes should not be declared public unless they define public members.

Description
This audit rule finds classes that are declared to be public but that do not define any public members or at least one protected constructor. Consider restricting such classes to package scope.

Non-blank Final Instance Field

Summary
Final instance fields should be blank.

Description
This audit rule finds instance fields that are marked as final and have a value assigned to them in the declaration. If the value of the field is the same for all instances, which it must be in this case, it should be a static field instead. If the value can be different in different instances, then either the field should not be final or the field should be assigned its value in a constructor.

Example
The following field declaration would be flagged as a violation:

    private final int maxItemCount = 64;

Non-private Constructor in Static Type

Summary
Constructors in classes containing only static members should be private.

Description
This audit rule finds non-private constructors in classes containing only static members. There is no value in creating an instance of a type that contains only static members. To prevent such instantiation, ensure that type has a single, no-argument, private constructor and no other constructors.

Example
The following class declaration would be flagged as a violation:

    public class Utilities
    {
        public static int getSize(List list)
        {
            ...
        }
    }

Non-protected Constructor in Abstract Type

Summary
Constructors in abstract classes should be protected.

Description
This audit rule finds non-protected constructors in abstract classes. Constructors in an abstract class can only be called from an instantiating subclass. Marking all constructors protected will help indicate this.

Example
The constructor in the following class declaration would be flagged as a violation:

    public abstract class Widget
    {
        public Widget()
        {
            ...
        }
    }

Obsolete Modifier Usage

Summary
Obsolete modifiers should not be used.

Description
There are a number of modifiers that can validly be specified according to the Java Language Specification, but which Sun strongly discourages the use of. This audit rule checks for places in which those modifiers are used.

Example
    public abstract interface SpecialObject
    {
        ...
    }

Protected Member in Final Class

Summary
Members of a final class should not be protected.

Description
This audit rule finds members that have a visibility of protected but are defined in a final class. There is no reason for them to be given a visibility of protected because there cannot be any subclasses.

Example
The method getSalary() would be flagged as a violation in the following example:

    public final class Employee
    {
        protected double getSalary()
        {
            ...
        }
    }

Public Constructor in Non-public Type

Summary
Constructors in non-public classes should not be public.

Description
This audit rule finds public constructors in non-public classes. There is no value in providing a public constructor because a non-public class cannot be instantiated outside the package in which it is defined. Reduce the access of the constructor to match that of the class itself.

Example
The constructor in the following example would be flagged as a violation because the class only has package visibility:

    class EmployeeData
    {
        public EmployeeData()
        {
            ...
        }
    }

Public Nested Type in Package Visible Type

Summary
Types declared within package visible types should not be public.

Description
This audit rule looks for declarations of public nested types within a package visible type. Because the outer type limits the visibility of the nested type, there is no reason for it to be declared as public, and such a declaration can be misleading.

Example
The following nested type would be flagged as a violation:

    class OuterClass {
        public class InnerClass {
        }
    }

Transient Field in Non-Serializable Class

Summary
Classes that do not implement java.io.Serializable should not declare fields as transient.

Description
This audit rule looks for declarations of fields that are transient in classes that do not implement the interface java.io.Serializable.

Example
The following field would be flagged as a violation:

    class NonSerializable
    {
        private transient int value;
    }

Unnecessary Final Method

Summary
Methods in a final class should not be declared as final.

Description
This audit rule looks for methods that are declared as being final that are defined in a class that is also declared as final. It is not necessary to declare the method to also be final because no subclass of the class could ever be defined.

Example
The "final" modifier on the following method would be flagged as a violation because the class is also marked as being final"

    public final class Point
    {
        public final int getX()
        {
            ...
        }
    }

Variable Should Be Final

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.