Finalizer Rules

These rules deal with different problems that can occur with finalizers.

EmptyFinalizer

If the finalize() method is empty, then it does not need to exist.

This rule is defined by the following XPath expression:


   //MethodDeclaration[MethodDeclarator[@Image='finalize'][not(FormalParameters/*)]]
      /Block[count(*)=0]

                

Here's an example of code that would trigger this rule:

			

   public class Foo {
       protected void finalize() {}
   }

       
		

FinalizeOnlyCallsSuperFinalize

If the finalize() is implemented, it should do something besides just calling super.finalize().

This rule is defined by the following XPath expression:


   //MethodDeclaration[MethodDeclarator[@Image="finalize"][not(FormalParameters/*)]]
       /Block[count(BlockStatement)=1]
         /BlockStatement[Statement/StatementExpression/PrimaryExpression
          /PrimaryPrefix[@Image="finalize"]

                

Here's an example of code that would trigger this rule:

			
           
   public class Foo {
       protected void finalize() {
         super.finalize();
       }
   }
           
       
		

FinalizeOverloaded

Methods named finalize() should not have parameters. It is confusing and probably a bug to overload finalize(). It will not be called by the VM.

This rule is defined by the following XPath expression:


//MethodDeclaration
 /MethodDeclarator[@Image='finalize'][FormalParameters[count(*)>0]]

            

Here's an example of code that would trigger this rule:

			

   public class Foo {
       // this is confusing and probably a bug
       protected void finalize(int a) {
       }
   }

   
		

FinalizeDoesNotCallSuperFinalize

If the finalize() is implemented, its last action should be to call super.finalize

This rule is defined by the following XPath expression:



//MethodDeclaration[MethodDeclarator[@Image='finalize'][not(FormalParameters/*)]]
   /Block
      /BlockStatement[last()]
      [not(Statement/StatementExpression/PrimaryExpression/PrimaryPrefix[@Image='finalize'])]
      [not(Statement/TryStatement[@Finally='true']
       /Block/BlockStatement/Statement/StatementExpression
        /PrimaryExpression/PrimaryPrefix[@Image='finalize'])]

                

Here's an example of code that would trigger this rule:

			

public class Foo {
   protected void finalize() {
       something();
       // neglected to call super.finalize()
   }
}

       
		

ExplicitCallToFinalize

An explicit call was made to a finalize method. Finalize methods are meant to be executed at most once (by the garbage collector). Calling it explicitly could result in the method being executed twice for that object (once by you, once by the garbage collector).

This rule is defined by the following XPath expression:


//PrimaryExpression[PrimarySuffix
 /Arguments[count(*) = 0]]
  /PrimaryPrefix
   /Name[@Image = 'finalize' or ends-with(@Image, '.finalize')]

                 

Here's an example of code that would trigger this rule:

			
   
public class Foo {
 public void close()  {
    finalize();       // this is bad
    foo.finalize();   // this is also bad
    this.finalize();  // this is bad but currently not flagged
    super.finalize(); // this is OK
    foo.finalize(3);  // this is arguably OK because the method is overloaded
 }
}
   
       
		

FinalizeShouldBeProtected

If you override finalize(), make it protected. Otherwise, subclasses may not called your implementation of finalize.

This rule is defined by the following XPath expression:

                    
//MethodDeclaration[@Protected="false"]
  /MethodDeclarator[@Image="finalize"]
  [not(FormalParameters/*)]
                    
                

Here's an example of code that would trigger this rule:

			
  
public class Foo {
 public void finalize() {
  // do something
 }
}