Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions

  




 

 

Thinking in Java
Prev Contents / Index Next

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:

  1. 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. title="Send BackTalk

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

    When using final with object references rather than primitives, the meaning gets a bit confusing. With a primitive, final makes the value a constant, but with an object reference, final makes the reference a constant. Once the reference is initialized to an object, it can never be changed to point to another object. However, the object itself 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:

    //: c06:FinalData.java
    // The effect of final on fields.
    import com.bruceeckel.simpletest.*;
    import java.util.*;
    
    class Value {
      int i; // Package access
      public Value(int i) { this.i = i; }
    }
    
    public class FinalData {
      private static Test monitor = new Test();
      private static Random rand = new Random();
      private String id;
      public FinalData(String id) { this.id = id; }
      // Can be compile-time constants:
      private final int VAL_ONE = 9;
      private static final int VAL_TWO = 99;
      // Typical public constant:
      public static final int VAL_THREE = 39;
      // Cannot be compile-time constants:
      private final int i4 = rand.nextInt(20);
      static final int i5 = rand.nextInt(20);
      private Value v1 = new Value(11);
      private final Value v2 = new Value(22);
      private static final Value v3 = new Value(33);
      // Arrays:
      private final int[] a = { 1, 2, 3, 4, 5, 6 };
      public String toString() {
        return id + ": " + "i4 = " + i4 + ", i5 = " + i5;
      }
      public static void main(String[] args) {
        FinalData fd1 = new FinalData("fd1");
        //! fd1.VAL_ONE++; // Error: can't change value
        fd1.v2.i++; // Object isn't constant!
        fd1.v1 = new Value(9); // OK -- not final
        for(int i = 0; i < fd1.a.length; i++)
          fd1.a[i]++; // Object isn't constant!
        //! fd1.v2 = new Value(0); // Error: Can't
        //! fd1.v3 = new Value(1); // change reference
        //! fd1.a = new int[3];
        System.out.println(fd1);
        System.out.println("Creating new FinalData");
        FinalData fd2 = new FinalData("fd2");
        System.out.println(fd1);
        System.out.println(fd2);
        monitor.expect(new String[] {
          "%% fd1: i4 = \\d+, i5 = \\d+",
          "Creating new FinalData",
          "%% fd1: i4 = \\d+, i5 = \\d+",
          "%% fd2: i4 = \\d+, i5 = \\d+"
        });
      }
    } ///:~


    Since VAL_ONE and VAL_TWO are final primitives with compile-time values, they can both be used as compile-time constants and are not different in any important way. VAL_THREE 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, with words separated by underscores. (This is just like C constants, which is where the convention originated.) 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 when you run the program. 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 v3 demonstrate the meaning of a final reference. As you can see in main( ), just because v2 is final doesn’t mean that you can’t change its value. Because it’s a reference, final means that you cannot rebind v2 to a new object. You can also see that the same meaning holds true for an array, which is just another kind of reference. (There is no way that I know of to make the array references themselves final.) Making references final seems less useful than making primitives final.

    Blank finals

    Java 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:

    //: c06:BlankFinal.java
    // "Blank" final fields.
    
    class Poppet {
      private int i;
      Poppet(int ii) { i = ii; }
    }
    
    public class BlankFinal {
      private final int i = 0; // Initialized final
      private final int j; // Blank final
      private final Poppet p; // Blank final reference
      // Blank finals MUST be initialized in the constructor:
      public BlankFinal() {
        j = 1; // Initialize blank final
        p = new Poppet(1); // Initialize blank final reference
      }
      public BlankFinal(int x) {
        j = x; // Initialize blank final
        p = new Poppet(x); // Initialize blank final reference
      }
      public static void main(String[] args) {
        new BlankFinal();
        new BlankFinal(47);
      }
    } ///:~


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

    Final arguments

    Java 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 reference points to:

    //: c06:FinalArguments.java
    // Using "final" with method arguments.
    
    class Gizmo {
      public void spin() {}
    }
    
    public class FinalArguments {
      void with(final Gizmo g) {
        //! g = new Gizmo(); // Illegal -- g is final
      }
      void without(Gizmo g) {
        g = new Gizmo(); // OK -- g not final
        g.spin();
      }
      // void f(final int i) { i++; } // Can't change
      // You can only read from a final primitive:
      int g(final int i) { return i + 1; }
      public static void main(String[] args) {
        FinalArguments bf = new FinalArguments();
        bf.without(null);
        bf.with(null);
      }
    } ///:~


    The methods f( ) and g( ) show what happens when primitive arguments are final: you can read the argument, but you can't change it. This feature seems only marginally useful, and is probably not something you’ll use.
    Thinking in Java
    Prev Contents / Index Next


 
 
   Reproduced courtesy of Bruce Eckel, MindView, Inc. Design by Interspire