The final keyword

The final keyword

The final keyword has slightly different meanings depending on the context, but in general it says "This cannot be changed." You might want to prevent changes for two reasons: design or efficiency. Because these two reasons are quite different, it's possible to misuse the final keyword.

The following sections discuss the three places where final can be used: for data, methods and for a class.

Final data

Many programming languages have a way to tell the compiler that a piece of data is "constant." A constant is useful for two reasons:

It can be a compile-time constant that won't ever change.

It can be a value initialized at run-time that you don't want changed.

In the case of a compile-time constant the compiler is allowed to "fold" the constant value into any calculations in which it's used; that is, the calculation can be performed at compile time, eliminating some run-time overhead. In Java, these sorts of constants must be primitives and are expressed using the final keyword. A value must be given at the time of definition of such a constant.

A field that is both static and final has only one piece of storage that cannot be changed.

When using final with object handles rather than primitives the meaning gets a bit confusing. With a primitive, final makes the value a constant, but with an object handle, final makes the handle a constant. The handle must be initialized to an object at the point of declaration, and the handle can never be changed to point to another object. However, the object can be modified; Java does not provide a way to make any arbitrary object a constant. (You can, however, write your class so that objects have the effect of being constant.) This restriction includes arrays, which are also objects.

Here's an example that demonstrates final fields:

Since i1 and I2 are final primitives with compile-time values, they can both be used as compile-time constants and are not different in any important way. I3 is the more typical way you'll see such constants defined: public so they're usable outside the package, static to emphasize that there's only one, and final to say that it's a constant. Note that final static primitives with constant initial values (that is, compile-time constants) are named with all capitals by convention. Also note that i5 cannot be known at compile time, so it is not capitalized.

Just because something is final doesn't mean that its value is known at compile-time. This is demonstrated by initializing i4 and i5 at run-time using randomly generated numbers. This portion of the example also shows the difference between making a final value static or non-static. This difference shows up only when the values are initialized at run-time, since the compile-time values are treated the same by the compiler. (And presumably optimized out of existence.) The difference is shown in the output from one run:

Note that the values of i4 for fd1 and fd2 are unique, but the value for i5 is not changed by creating the second FinalData object. That's because it's static and is initialized once upon loading and not each time a new object is created.

The variables v1 through v4 demonstrate the meaning of a final handle. As you can see in main( ), just because v2 is final doesn't mean that you can't change its value. However, you cannot re-bind v2 to a new object, precisely because it's final. That's what final means for a handle. You can also see the same meaning holds true for an array, which is just another kind of handle. (There is know way that I know of to make the array handles themselves final.) Making handles final seems less useful than making primitives final.

Blank finals

Java 1.1 allows the creation of blank finals, which are fields that are declared as final but are not given an initialization value. In all cases, the blank final must be initialized before it is used, and the compiler ensures this. However, blank finals provide much more flexibility in the use of the final keyword since, for example, a final field inside a class can now be different for each object and yet it retains its immutable quality. Here's an example:

You're forced to perform assignments to finals either with an expression at the point of definition of the field or in every constructor. This way it's guaranteed that the final field is always initialized before use.

Final arguments

Java 1.1 allows you to make arguments final by declaring them as such in the argument list. This means that inside the method you cannot change what the argument handle points to:

Note that you can still assign a null handle to an argument that's final without the compiler catching it, just like you can with a non-final argument.

The methods f( ) and g( ) show what happens when primitive arguments are final: you can only read the argument, but you can't change it.

Final methods

There are two reasons for final methods. The first is to put a "lock" on the method to prevent any inheriting class from changing its meaning. This is done for design reasons when you want to make sure that a method's behavior is retained during inheritance and cannot be overridden.

The second reason for final methods is efficiency. If you make a method final, you are allowing the compiler to turn any calls to that method into inline calls. When the compiler sees a final method call it can (at its discretion) skip the normal approach of inserting code to perform the method call mechanism (push arguments on the stack, hop over to the method code and execute it, hop back and clean off the stack arguments, and deal with the return value) and instead replace the method call with a copy of the actual code in the method body. This eliminates the overhead of the method call. Of course, if a method is big, then your code begins to bloat and you probably won't see any performance gains from inlining since any improvements will be dwarfed by the amount of time spent inside the method. It is implied that the Java compiler is able to detect these situations and choose wisely whether to inline a final method. However, it's better to not trust that the compiler is able to do this and make a method final only if it's quite small or if you want to explicitly prevent overriding.

Any private methods in a class are implicitly final. Because you can't access a private method, you can't override it (the compiler gives an error message if you try). You can add the final specifier to a private method but it doesn't give that method any extra meaning.

Final classes

When you say that an entire class is final (by preceding its definition with the final keyword), you state that you don't want to inherit from this class or allow anyone else to do so. In other words, for some reason the design of your class is such that there is never a need to make any changes, or for safety or security reasons you don't want subclassing. Alternatively, you might be dealing with an efficiency issue and you want to make sure that any activity involved with objects of this class is as efficient as possible.

Note that the data members can be final or not, as you choose. The same rules apply to final for data members regardless of whether the class is defined as final. Defining the class as final simply prevents inheritance - nothing more. However, because it prevents inheritance all methods in a final class are implicitly final, since there's no way to override them. So the compiler has the same efficiency options as it does if you explicitly declare a method final.

You can add the final specifier to a method in a final class, but it doesn't add any meaning.

Final caution

It can seem to be sensible to make a method final while you're designing a class. You might feel that efficiency is very important when using your class and that no one could possibly want to override your methods anyway. Sometimes this is true.

But be careful with your assumptions. In general, it's difficult to anticipate how a class can be reused, especially a general-purpose class. If you define a method as final you might prevent the possibility of reusing your class through inheritance in some other programmer's project simply because you couldn't imagine it being used that way.

The standard Java library is a good example of this. In particular, the Vector class is commonly used and might be even more useful if, in the name of efficiency, all the methods hadn't been made final. It's easily conceivable that you might want to inherit and override with such a fundamentally useful class, but the designers somehow decided this wasn't appropriate. This is ironic for two reasons. First, Stack is inherited from Vector, which says that a Stack is a Vector, which isn't really true. Second, many of the most important methods of Vector, such as addElement( ) and elementAt( ) are synchronized, which as you will see in Chapter 14 incurs a significant performance overhead that probably wipes out any gains provided by final. This lends credence to the theory that programmers are consistently bad at guessing where optimizations should occur. It's just too bad that such a clumsy design made it into the standard library where we must all cope with it.

It's also interesting to note that Hashtable, another important standard library class, does not have any final methods. As mentioned elsewhere in this book, it's quite obvious that some classes were designed by completely different people than others. (Notice the brevity of the method names in Hashtable compared to those in Vector.) This is precisely the sort of thing that should not be obvious to consumers of a class library. When things are inconsistent it just makes more work for the user. Yet another paean to the value of design and code walkthroughs.