constant : Java Glossary

Types of Constants

1. Literals

   e.g.

   42, "abc"

   You may use byte, short, char and int literals as switch case labels. However, longs and Strings are not supported.

2. Compile Time Constants

   or just plain compile constants, Officially known as compile-time constant expressions these are static finals whose value

   // constants known at compile time
   static final int ARMS = 2;
   static final int LIMBS = ARMS * 2;

   These can be used as switch case labels, subject, of course, to the usual byte, short, char and int-only restriction.

3. Load-Time Class Constants

   or just plain load constants, static finals whose value is not known

   static final int SERIALNUMBER = ++generator;

   These cannot used in switch case labels. All the variables in an interface are implicitly static finals. They may be either compile time constants or load time constants.

4. Instance Constants

   instance finals whose value is not known until object instantiation time, e. g. These too cannot used as switch case labels. It is sometimes possible for an instance constant to be evaluated at compile time. In that case it is treated like a literal, much like a static compile-time constant. You can use a compile-time local int constant as a case label.

5. Local Constants

   stack finals whose value is not known until the method executes, e. g.

   final int bottomLine = getTax();

   These too cannot used as switch case labels.

   final int LEGS = 2;

   As in the example above, it is sometimes possible for a local constant to be evaluated at compile time. In that case it is treated like a literal, much like a static compile-time constant. You can use a compile-time local int constant as a case label.

6. Parameter Constants

   A parameter marked final. This indicates the called method will never change its local copy of the passed parameter.

7. enum Constants

   The names of the possibilities for an enum. These are under-the-hood static finals evaluated at load time, but through the magic of Java, you can use them as if they were known at compile time, e.g. as case labels.

A key point that bears repeating is that constant references are constrained to point to the same object for their entire lifetimes. However, the object itself they point to is not necessarily constant. Its fields may or may not change. Whether they can change or not has nothing to do with whether the references that point to them are final.

See literals for how to specify Strings, integers etc. final in Java means a variable that will not change after it is initialised. The associated keywords with a named constant are static final. Constant values have alphabetic names, e.g. Math.PI. For most practical purposes constants in Java are called static final variables. However, only those static final variables whose value can be computed at compile time are true constants. Only true constants can be used as case labels. Note that constants always need to be qualified with the classname except in code inside the class. To further confuse the matter, the language specification refer to static final variables as values not constants.

Constants can be defined in both classes and interfaces. Interfaces without methods can be used simply as namespaces for related constants defined within them. For example, an interface MyConstants might define MAX_ROWS and MAX_COLS, accessed in other classes as MyConstants. MAX_ROWS and MyConstants.MAX_COLS. To access the constants in such an interface by unqualified name (e.g., MAX_ROWS) in methods of another class MyClass, you can make MyClass implement MyConstants. However, this trick comes with some costs, so should be used carefully. First, the constants become non-private class members of MyClass. Other classes can become dependent on MyClass implementing MyConstants — an implementation detail. Second, other classes that access those public members depend on the values in the last-compiled version of MyClass, which can differ from the current values in the interface. Third, if MyClass implements multiple such interfaces, ambiguities can be created in MyClass during maintenance of those other interfaces.

Compile Time vs Load Time Constants

public static final int DAYS_IN_WEEK = 7;

public static final int SECONDS_PER_HOUR = 60 * 60;

public static final String COPYRIGHT = "Copyright (c) " + "2005";

public static final int POSTAGE_IN_CENTS = 60;
public static final int HANDLING_IN_CENTS = 500;
public static final int BIGGER_IN_CENTS =
( POSTAGE_IN_CENTS > HANDLING_IN_CENTS )
? POSTAGE_IN_CENTS
: HANDLING_IN_CENTS;

public static final Random wheel = new Random();
public static final int CARD = wheel.nextInt( 52 );

To find out whether other expressions will be evaluated at compile time, you can use a decompiler to see what sort of code was generated for the initialisation.

Who Cares?

1. compile time int constants can be used as case labels. Load time constants cannot.
2. There are various restrictions on accessing static variables, e.g. static references from enum constructors are not permitted. Compile time constants are generally immune from these restrictions since they are treated just like literals.
3. Since the values of all compile time constants are computed at compile time, they are all known before any load time static initialisation is done. This lets you get away with forward references to compile-time constants.
4. compile-time constants are in-lined, just as if you had specified a literal every time they were referenced. This means if class A uses class B’s compile time constants and you change the values of those constants in class B, class A still has the old values embedded all through it, in-lined, until it is recompiled to refresh the values. There is no record in class A where those literals came from. Thus, it is not sufficient for class A to just load a fresh copy of B’s class file. This is why you periodically must do clean compiles to recompile the universe.
5. Compile time constants generate faster, leaner code. Get in the habit of adding final to any variable whose value is computed only once. It is good documentation, makes code easier to follow, prevents bugs and makes the code faster.

Importing Constants

• The constants should be declared

  package.com.mindprod.backup.Backup;
  public class Backup
     {
     ...
     static final public int DAYS_BETWEEN_BACKUPS = 2;
     ...
     }

• You can access the constant in some other

  package com.mindprod.other.Other;
  import com.mindprod.backup.Backup;
  public class Other
     {
     ...
     int days = Backup.DAYS_BETWEEN_BACKUPS;
     ...
     }

  Note how you must specify the class name of the constant.
• Alternatively

  package com.mindprod.other.Other;
  import static com.mindprod.backup.Backup.DAYS_BETWEEN_BACKUPS;
  public class Other
     {
     ...
     int days = DAYS_BETWEEN_BACKUPS;
     ...
     }

  Note how you can leave off the class name of the constant. This feature is not available in prior to Java 1.5.

Rules of Thumb

• Avoid literals other than 0 and 1. Use static finals instead.
• If a value can be known at compile or load time, mark it static final.
• If a value does not change after you compute it, mark it final. This applies to static variables, instance variables, local variables and parameters.
• If in doubt whether a value is ok for a case, try it. If the compiler does not complain, it was ok.
• If your constants need to be computed in some special order, put that initialisation in a static {} or an instance initialisation {} block where the order won’t be meddled with. Don’t trust the order of declarations. Some tidying program such as IntelliJ Idea Rearranger will eventually disturb the variable declaration order leaving you or someone else baffled why the initialisation no longer works.
• If you change the value of a non-private static final, do a clean recompile of all places it is used to propagate the new value.

Gotchas

You cannot define static finals in an enum and use them in the enum constructors. You can put them in a separate private static nested class.