43

I understand that in this code:

class Foo {
    public static void method() {
        System.out.println("in Foo");
    }
} 

class Bar extends Foo {
    public static void method() {
        System.out.println("in Bar");
    }
}

.. the static method in Bar 'hides' the static method declared in Foo, as opposed to overriding it in the polymorphism sense.

class Test {
    public static void main(String[] args) {
        Foo.method();
        Bar.method();
    }
}

...will output:

in Foo
in Bar

Re-defining method() as final in Foo will disable the ability for Bar to hide it, and re-running main() will output:

in Foo
in Foo

(Edit: Compilation fails when you mark the method as final, and only runs again when I remove Bar.method())

Is it considered bad practice to declare static methods as final, if it stops subclasses from intentionally or inadvertantly re-defining the method?

(this is a good explanation of what the behaviour of using final is..)

brasskazoo
  • 76,030
  • 23
  • 64
  • 76

10 Answers10

40

I don't consider it's bad practice to mark a static method as final.

As you found out, final will prevent the method from being hidden by subclasses which is very good news imho.

I'm quite surprised by your statement:

Re-defining method() as final in Foo will disable the ability for Bar to hide it, and re-running main() will output:

in Foo
in Foo

No, marking the method as final in Foo will prevent Bar from compiling. At least in Eclipse I'm getting:

Exception in thread "main" java.lang.Error: Unresolved compilation problem: Cannot override the final method from Foo

Also, I think people should always invoke static method qualifying them with the class name even within the class itself:

class Foo
{
  private static final void foo()
  {
    System.out.println("hollywood!");
  }

  public Foo()
  {
    foo();      // both compile
    Foo.foo();  // but I prefer this one
  }
}
Community
  • 1
  • 1
Gregory Pakosz
  • 69,011
  • 20
  • 139
  • 164
  • 1
    yes, we should make a habit of marking all public static methods as 'final'. – ZhongYu Jun 27 '13 at 21:35
  • @GregoryPakosz so you are saying that `Unresolved compilation problem: Cannot override the final method from Foo` makes sense? For non overridable method to begin with? – Eugene Apr 30 '18 at 12:16
36

Static methods are one of Java's most confusing features. Best practices are there to fix this, and making all static methods final is one of these best practices!

The problem with static methods is that

  • they are not class methods, but global functions prefixed with a classname
  • it is strange that they are "inherited" to subclasses
  • it is surprising that they cannot be overridden but hidden
  • it is totally broken that they can be called with an instance as receiver

therefore you should

  • always call them with their class as receiver
  • always call them with the declaring class only as receiver
  • always make them (or the declaring class) final

and you should

  • never call them with an instance as receiver
  • never call them with a subclass of their declaring class as receiver
  • never redefine them in subclasses

 

NB: the second version of you program should fails a compilation error. I presume your IDE is hiding this fact from you!

akuhn
  • 27,477
  • 2
  • 76
  • 91
  • Very nice answer! By the way, the second version does indeed fail compilation in my IDE. Edited the question to clarify this. – brasskazoo Dec 20 '09 at 03:57
  • are you absolutely sure about: always make them (or the declaring class) final - if you make declaring class final, automatically all public methods will be final, but does that applies also for STATIC methods? – ante.sabo Aug 10 '11 at 16:01
  • If the class is final it cannot be subclasses, so it follows that all methods are final as well. For static method this means there cannot be a subclass method that hides them, which is equivalent to making the method final but not the class. – akuhn Aug 20 '11 at 02:53
  • 2
    The first Java warning in Eclipse is "Non-static access to static member". Enable that, and you'll be warned whenever you accidentally use a static method with an instance receiver. – Mike Samuel Jul 02 '12 at 22:47
  • @akuhn very nice answer... but i do not understand what do you mean by "always call them with their class as receiver" "always call them with the declaring class only as receiver"... What is the difference between these two points?... and what exactly "class as receiver" means? – Ankit Mar 12 '15 at 09:54
  • 1
    @Ankit The receiver is, simply said, what is on the left side of the . operator when calling a function. – Adowrath Apr 04 '17 at 18:22
7

If I have a public static method, then it's often already located in a so-called utility class with only static methods. Self-explaining examples are StringUtil, SqlUtil, IOUtil, etcetera. Those utility classes are by itselves already declared final and supplied with a private constructor. E.g.

public final class SomeUtil {

    private SomeUtil() {
        // Hide c'tor.
    }

    public static SomeObject doSomething(SomeObject argument1) {
        // ...
    }

    public static SomeObject doSomethingElse(SomeObject argument1) {
        // ...
    }

}

This way you cannot override them.

If yours is not located in kind of an utility class, then I'd question the value of the public modifier. Shouldn't it be private? Else just move it out to some utility class. Do not clutter "normal" classes with public static methods. This way you also don't need to mark them final.

Another case is a kind of abstract factory class, which returns concrete implementations of self through a public static method. In such case it would perfectly make sense to mark the method final, you don't want the concrete implementations be able to override the method.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • 1
    I think this should be marked as the correct answer personally. This is exactly what I would have suggested. Finalise the class, not the individual method(s). – Matt Keeble Feb 25 '16 at 10:02
  • @MattKeeble this does not matter, there *is* the optional to make it final and we should judge from there. Making it finals does make sense, it's just that compiler throws a very misleading error message in this case – Eugene Apr 30 '18 at 12:18
4

Usually with utility classes - classes with only static methods - it is undesirable to use inheritence. for this reason you may want to define the class as final to prevent other classes extending it. This would negate putting final modifiers on your utility class methods.

mR_fr0g
  • 8,462
  • 7
  • 39
  • 54
  • Good point - one of my refactoring goals is to move static methods to a utility class, marking that class as final is a good idea. – brasskazoo Dec 20 '09 at 03:46
3

The code does not compile:

Test.java:8: method() in Bar cannot override method() in Foo; overridden method is static final public static void method() {

The message is misleading since a static method can, by definition, never be overridden.

I do the following when coding (not 100% all the time, but nothing here is "wrong":

(The first set of "rules" are done for most things - some special cases are covered after)

  1. create an interface
  2. create an abstract class that implements the interface
  3. create concrete classes that extend the abstract class
  4. create concrete classes that implements the interface but do not extend the abstract class
  5. always, if possible, make all variables/constants/parameters of the interface

Since an interface cannot have static methods you don't wind up with the issue. If you are going to make static methods in the abstract class or concrete classes they must be private, then there is no way to try to override them.

Special cases:

Utility classes (classes with all static methods):

  1. declare the class as final
  2. give it a private constructor to prevent accidental creation

If you want to have a static method in a concrete or abstract class that is not private you probably want to instead create a utility class instead.

Value classes (a class that is very specialized to essentially hold data, like java.awt.Point where it is pretty much holding x and y values):

  1. no need to create an interface
  2. no need to create an abstract class
  3. class should be final
  4. non-private static methods are OK, especially for construction as you may want to perform caching.

If you follow the above advice you will wind up with pretty flexible code that also has fairly clean separation of responsibilities.

An example value class is this Location class:

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;


public final class Location
    implements Comparable<Location>
{
    // should really use weak references here to help out with garbage collection
    private static final Map<Integer, Map<Integer, Location>> locations;

    private final int row;    
    private final int col;

    static
    {
        locations = new HashMap<Integer, Map<Integer, Location>>();
    }

    private Location(final int r,
                     final int c)
    {
        if(r < 0)
        {
            throw new IllegalArgumentException("r must be >= 0, was: " + r);
        }

        if(c < 0)
        {
            throw new IllegalArgumentException("c must be >= 0, was: " + c);
        }

        row = r;
        col = c;
    }

    public int getRow()
    {
        return (row);
    }

    public int getCol()
    {
        return (col);
    }

    // this ensures that only one location is created for each row/col pair... could not
    // do that if the constructor was not private.
    public static Location fromRowCol(final int row,
                                      final int col)
    {
        Location               location;
        Map<Integer, Location> forRow;

        if(row < 0)
        {
            throw new IllegalArgumentException("row must be >= 0, was: " + row);
        }

        if(col < 0)
        {
            throw new IllegalArgumentException("col must be >= 0, was: " + col);
        }

        forRow = locations.get(row);

        if(forRow == null)
        {
            forRow = new HashMap<Integer, Location>(col);
            locations.put(row, forRow);
        }

        location = forRow.get(col);

        if(location == null)
        {
            location = new Location(row, col);
            forRow.put(col, location);
        }

        return (location);
    }

    private static void ensureCapacity(final List<?> list,
                                       final int     size)
    {
        while(list.size() <= size)
        {
            list.add(null);
        }
    }

    @Override
    public int hashCode()
    {
        // should think up a better way to do this...
        return (row * col);
    }

    @Override
    public boolean equals(final Object obj)
    {
        final Location other;

        if(obj == null)
        {
            return false;
        }

        if(getClass() != obj.getClass())
        {
            return false;
        }

        other = (Location)obj;

        if(row != other.row)
        {
            return false;
        }

        if(col != other.col)
        {
            return false;
        }

        return true;
    }

    @Override
    public String toString()
    {
        return ("[" + row + ", " + col + "]");
    }

    public int compareTo(final Location other)
    {
        final int val;

        if(row == other.row)
        {
            val = col - other.col;
        }
        else
        {
            val = row - other.row;
        }

        return (val);
    }
}
TofuBeer
  • 60,850
  • 18
  • 118
  • 163
1

Most of this final issue dates back to the time when VM-s were quite dumb/conservative. Back then if you marked a method final it meant (among other things), that the VM can inline it, avoiding method calls. That is not case since a long-long (or long double :P ) time: http://java.sun.com/developer/technicalArticles/Networking/HotSpot/inlining.html .

I guess that Idea/Netbeans inspection warns you, because it thinks that you want to use the final keyword for optimization and they think that you are unaware of the fact that it is unneeded with modern VMs.

Just my two cents...

Gergely Szilagyi
  • 3,813
  • 1
  • 14
  • 12
1

It might be a good thing to mark static methods as final, particularly if you are developing a framework that you expect others to extend. That way your users won't inadvertently end up hiding your static methods in their classes. But if you are developing a framework you might want to avoid using static methods to begin with.

Aditya
  • 117
  • 5
0

Because static methods are the properties of the class and they are called with the name of the class rather than of object. If we make the parent class method final as well it will not be overloaded as final methods does not allow to change its memory location but we can update the final data member at the same memory location...

Aasif Ali
  • 11
  • 3
0

I encountered one detriment to using final methods using Spring's AOP and MVC. I was trying to use spring's AOP put in security hooks around one of the methods in the AbstractFormController which was declared final. I think spring was using the bcel library for injection in classes and there was some limitation there.

BillMan
  • 9,434
  • 9
  • 32
  • 52
0

When I create pure utility classes, I declare then with a private constructor so they cannot be extended. When creating normal classes, I declare my methods static if they are not using any of the class instance variables (or, in some cases, even if they were, I would pass the arguments in the method and make it static, it's easier to see what the method is doing). These methods are declared static but are also private - they are there just to avoid code duplication or to make the code easier to understand.

That being said, I don't remember running into the case where you have a class that has public static methods and that can/ should be extended. But, based on what was reported here, I would declare its static methods final.

Ravi Wallau
  • 10,416
  • 2
  • 25
  • 34