Final (Java): Difference between revisions

Content deleted Content added
Caesar (talk | contribs)
C/C++ analog of final variables: combined two sentences into one to avoid repetition
 
(40 intermediate revisions by 27 users not shown)
Line 1:
{{Short description|Keyword in the Java programming language}}
{{lowercase}}
{{lowercase title}}
In the [[Java (programming language)|Java programming language]], the <code>'''final'''</code> [[Keyword (computing)|keyword]] is used in several contexts to define an entity that can only be assigned once.
In the [[Java (programming language)|Java programming language]], the <code>'''final'''</code> [[Keyword (computing)|keyword]] is used in several contexts to define an entity that can only be assigned once.
 
Once a <code>'''final'''</code> variable has been assigned, it always contains the same value. If a <code>'''final'''</code> variable holds a reference to an object, then the state of the object may be changed by operations on the object, but the variable will always refer to the same object (this property of <code>'''final'''</code> is called ''non-transitivity''<ref>{{cite journal|last1=Coblenz|first1=Michael|last2=Sunshine|first2=Joshua|last3=Aldrich|first3=Jonathan|last4=Myers|first4=Brad|last5=Weber|first5=Sam|last6=Shull|first6=Forrest|title=Exploring Language Support for Immutability|journal=The 38th International Conference on Software Engineering|date=14{{ndash}}22 May 2016}}</ref>). This applies also to arrays, because arrays are objects; if a <code>'''final'''</code> variable holds a reference to an array, then the components of the array may be changed by operations on the array, but the variable will always refer to the same array.<ref>Java Language Specification #4.12.4</ref>
 
==Final classes==
A '''final [[Class (computer science)|class]]''' cannot be subclassed. As doing this can confer security and efficiency benefits, many of the Java standard library classes are final, such as {{Javadoc:SE|package=java.lang|java/lang|System}} and {{Javadoc:SE|package=java.lang|java/lang|String}}.
 
A '''final [[Class (computer science)|class]]''' cannot be subclassed. Doing this can confer security and efficiency benefits, so many of the Java standard library classes are final, such as {{Javadoc:SE|package=java.lang|java/lang|System}} and {{Javadoc:SE|package=java.lang|java/lang|String}}.
 
Example:
<sourcesyntaxhighlight lang="java">
public final class MyFinalClassFinalClass {...}
// ...
}
 
// Forbidden
public class ThisIsWrong extends MyFinalClass {...} // forbidden
public class DerivedClass extends FinalClass {
</source>
// ...
}
</syntaxhighlight>
 
==Final methods==
 
A final [[Method (computer science)|method]] cannot be [[Method overriding|overridden]] or hidden by subclasses.<ref>[http{{Cite web |title=Chapter 8. Classes |url=https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls |access-8.4.3.3date=2024-04-25 JLS 8|website=docs.4oracle.3.3. final Methods]com}}</ref> This is used to prevent unexpected behavior from a subclass altering a method that may be crucial to the function or consistency of the class.<ref>[http{{Cite web |title=Writing Final Classes and Methods |url=https://javadocs.sunoracle.com/docs/booksjavase/tutorial/java/IandI/final.html Writing|access-date=2024-04-25 Final Classes and Methods]|website=docs.oracle.com}}</ref>
 
Example:
<sourcesyntaxhighlight lang="java">
public class Base {
public void m1() { ... }
{
public final void m1m2() { ... }
public final void m2() {...}
 
public static void m3() { ... }
public static final void m4() { ... }
}
 
public class Derived extends Base {
public void m1() { ... } // OK, overriding Base#m1()
{
public void m1m2() { ... } // OK, overriding Base#m1()forbidden
public void m2() {...} // forbidden
 
public static void m3() { ...} } // OK, hiding Base#m3()
public static void m4() { ...} } // forbidden
}
</syntaxhighlight>
</source>
 
A common misconception is that declaring a method as <code>final</code> improves efficiency by allowing the compiler to directly insert the method wherever it is called (see [[inline expansion]]). Because the method is loaded at [[run time (program lifecycle phase)|runtime]], compilers are unable to do this. Only the runtime environment and [[Just-in-time compilation|JIT]] compiler know exactly which classes have been loaded, and so only they are able to make decisions about when to inline, whether or not the method is final.<ref>[{{Cite web |title=Java theory and practice: Is that your final answer? |url=http://www.ibm.com/developerworks/java/library/j-jtp1029.html Java theory|url-status=dead and practice|archive-url=https://web.archive.org/web/20090208100217/http://www.ibm.com/developerworks/java/library/j-jtp1029.html Is|archive-date=2009-02-08 that|access-date=2024-04-25 your final answer?]|website=developer.ibm.com}}</ref>
 
Machine code compilers that generate directly executable, platform-specific [[machine code]], are an exception. When using [[static linking]], the compiler can safely assume that methods and variables computable at [[compile-time]] may be inlined.
 
==Final variables==
A '''final [[Variable (programming)|variable]]''' can only be initialized once, either via an initializer or an assignment statement. It does not need to be initialized at the point of declaration: this is called a "blank final" variable. A blank final [[instance variable]] of a class must be definitely assigned in every constructor of the class in which it is declared; similarly, a blank final static variable must be definitely assigned in a static initializer of the class in which it is declared; otherwise, a compile-time error occurs in both cases.<ref>Java Language Specification #8.3.1.2.</ref> (Note: If the variable is a reference, this means that the variable cannot be re-bound to reference another object. But the object that it references is still [[mutable object|mutable]], if it was originally mutable.)
 
Unlike the value of a [[constant (computer science)|constant]], the value of a final variable is not necessarily known at compile time. It is considered good practice to represent final constants in all uppercase, using underscore to separate words.<ref>{{Cite web |title=Java Programming Style Guidelines |url=https://petroware.no/javastyle.html |access-date=2024-04-25 |website=petroware.no}}</ref>
A '''final [[Variable (programming)|variable]]''' can only be initialized once, either via an initializer or an assignment statement. It does not need to be initialized at the point of declaration: this is called a "blank final" variable. A blank final instance variable of a class must be definitely assigned in every constructor of the class in which it is declared; similarly, a blank final static variable must be definitely assigned in a static initializer of the class in which it is declared; otherwise, a compile-time error occurs in both cases.<ref>Java Language Specification #8.3.1.2.</ref> (Note: If the variable is a reference, this means that the variable cannot be re-bound to reference another object. But the object that it references is still [[mutable object|mutable]], if it was originally mutable.)
 
Unlike the value of a [[constant (computer science)|constant]], the value of a final variable is not necessarily known at compile time. It is considered good practice to represent final constants in all uppercase, using underscore to separate words.<ref>http://geosoft.no/development/javastyle.html</ref>
 
Example:
<sourcesyntaxhighlight lang="java">
public class Sphere {
 
// piPi is a universal constant, about as constant as anything can be.
public static final double PI = 3.141592653589793;
 
Line 63 ⟶ 65:
 
Sphere(double x, double y, double z, double r) {
radius = r;
xPos = x;
yPos = y;
zPos = z;
}
 
[...]
}
</syntaxhighlight>
</source>
 
Any attempt to reassign <code>radius</code>, <code>xPos</code>, <code>yPos</code>, or <code>zPos</code> will result in a compile error. In fact, even if the constructor doesn't set a final variable, attempting to set it outside the constructor will result in a compilation error.
Line 77 ⟶ 79:
To illustrate that finality doesn't guarantee immutability: suppose we replace the three position variables with a single one:
 
<sourcesyntaxhighlight lang="Java">
public final Position pos;
</syntaxhighlight>
</source>
 
where <code>pos</code> is an object with three properties <code>pos.x</code>, <code>pos.y</code> and <code>pos.z</code>. Then <code>pos</code> cannot be assigned to, but the three properties can, unless they are final themselves.
Line 87 ⟶ 89:
Though it appears to violate the <code>final</code> principle, the following is a legal statement:
 
<sourcesyntaxhighlight lang="Java">
for (final SomeObject obj : someList) {
// do something with obj
}
</syntaxhighlight>
</source>
 
Since the obj variable goes out of scope with each iteration of the loop, it is actually redeclared each iteration, allowing the same token (i.e. <code>obj</code>) to be used to represent multiple variables.<ref>{{cite web|url=httphttps://www.cs.cmu.edu/~pattis/15-1XX/15-200/lectures/morejava/lecture.html|title=More Java|last=Pattis|first=Richard E.|work=Advanced Programming/Practicum 15–200|publisher=School of Computer Science [[Carnegie Mellon University]]|accessdate=23 July 2010}}</ref>
 
=== Final variables in nested objects ===
Although it also appears to break the intent of final variables, modifying the value from another class (by getting the reference via a public getter method and changing its value) ''does'' change the value of the referenced object. For instance, according to the semantics of the final keyword, the following unit test should output "68", while in fact it outputs "82" and throws an assertion exception:
Final variables can be used to construct trees of immutable objects. Once constructed, these objects are guaranteed not to change anymore. To achieve this, an immutable class must only have final fields, and these final fields may only have immutable types themselves. Java's primitive types are immutable, as are strings and several other classes.
 
If the above construction is violated by having an object in the tree that is not immutable, the expectation does not hold that anything reachable via the final variable is constant. For example, the following code defines a coordinate system whose origin should always be at (0, 0). The origin is implemented using a <code>java.awt.Point</code> though, and this class defines its fields as public and modifiable. This means that even when reaching the <code>origin</code> object over an access path with only final variables, that object can still be modified, as the below example code demonstrates.
<source lang="java">
package test;
import java.sql.Date;
public final class TestFinal {
    
    private final String name = "Andrew";
    @SuppressWarnings("deprecation")
    private final Date dob = new Date(Date.parse("07/20/1968"));
    public String getName() {
        return name;
    }
 
<syntaxhighlight lang="java">
    final public Date getDob() {
import java.awt.Point;
        return dob;
    }
}
 
public class FinalDemo {
package test;
import static org.junit.Assert.*;
import java.util.Date;
import org.junit.Test;
public class TestFinalTest {
 
static class CoordinateSystem {
    @Test
private final Point origin = new Point(0, 0);
    public void test() {
    }
 
public Point getOrigin() { return origin; }
    @Test
}
    public void changeDate() {
 
        TestFinal testFinal = new TestFinal();
public static void main(String[] args) {
        Date initialDate = testFinal.getDob();
CoordinateSystem coordinateSystem = new CoordinateSystem();
        initialDate.setYear(82);
 
        Date finalDate = testFinal.getDob();
coordinateSystem.getOrigin().x = 15;
        System.out.println(finalDate.getYear());
 
        assert(finalDate.getYear() == 68);
assert coordinateSystem.getOrigin().getX() == 0;
    }
}
}
</syntaxhighlight>
</source>
 
The reason for this is that declaring a variable final only affectsmeans thethat reference, not the value of thethis variable, and Java always passes by value, which creates a differentwill referencepoint to the same valueobject inat theany second classtime. ThatThe theobject value ofthat the privatevariable fieldpoints canto beis changednot withoutinfluenced aby publicthat setterfinal impliesvariable thatthough. encapsulationIn isthe weak atabove bestexample, andthe shouldnorigin'ts bex countedand ony tocoordinates protectcan keybe values,freely even in combination with the final keywordmodified.
 
To prevent this undesirable situation, a common requirement is that all fields of an immutable object must be final, and that the types of these fields must be immutable themselves. This disqualifies <code>java.util.Date</code> and <code>java.awt.Point</code> and several other classes from being used in such immutable objects.
===Final and inner classes===
 
===Final and inner classes===
When an anonymous [[inner class]] is defined within the body of a method, all variables declared <code>final</code> in the scope of that method are accessible from within the inner class. For scalar values, once it has been assigned, the value of the <code>final</code> variable cannot change. For object values, the reference cannot change. This allows the Java compiler to "capture" the value of the variable at run-time and store a copy as a field in the inner class. Once the outer method has terminated and its [[call stack|stack frame]] has been removed, the original variable is gone but the inner class's private copy persists in the class's own memory.
 
<sourcesyntaxhighlight lang="Java">
import javax.swing.*;
 
Line 163 ⟶ 151:
}
}
</syntaxhighlight>
</source>
 
===Blank final===
The '''blank final''', which was introduced in Java 1.1, is a final variable whose declaration lacks an initializer.<ref>{{cite book|last=Flanagan|first=David|title=Java in a Nutshell|url=https://archive.org/details/javainnutshelld100flan|edition=2nd|date=May 1997|publisher=O'Reilly|isbn=1-56592-262-X|chapter=Chapter 5 Inner Classes and Other New Language Features:5.6 Other New Features of Java 1.1|url-access=registration}}</ref><ref>{{cite web|url=http://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.12.4|title=Chapter 4. Types, Values, and Variables|year=2015|work=The Java® Language Specification (Java SE 8 Edition)|publisher=Oracle America, Inc.|access-date=23 Feb 2015}}</ref> Previous to Java 1.1, a final variable was required to have an initializer. A blank final, by definition of "final", can only be assigned once. i.e. it must be unassigned when an assignment occurs. In order to do this, a Java compiler runs a flow analysis to ensure that, for every assignment to a blank final variable, the variable is definitely unassigned before the assignment; otherwise a compile-time error occurs.<ref name="define_assignment">{{cite web|url=http://docs.oracle.com/javase/specs/jls/se8/html/jls-16.html|title=Definite Assignment|year=2015|work=The Java® Language Specification (Java SE 8 Edition)|publisher=Oracle America, Inc.|access-date=29 Oct 2016}}</ref>
 
<syntaxhighlight lang="java">
The '''blank final''', which was introduced in Java 1.1, is a final variable whose declaration lacks an initializer.<ref>{{cite book|last=Flanagan|first=David |title=Java in a Nutshell|url=http://web.deu.edu.tr/doc/oreily/java/javanut/ch05_06.htm|edition=2nd|date=May 1997 |publisher=O'Reilly|isbn=1-56592-262-X|chapter=Chapter 5 Inner Classes and Other New Language Features:5.6 Other New Features of Java 1.1}}</ref><ref>{{cite web|url=http://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.12.4|title=Chapter 4. Types, Values, and Variables|year=2015|work=The Java® Language Specification (Java SE 8 Edition)|publisher=Oracle America, Inc.|access-date=23 Feb 2015}}</ref> A blank final can only be assigned once and must be unassigned when an assignment occurs. In order to do this, a Java compiler runs a flow analysis to ensure that, for every assignment to a blank final variable, the variable is definitely unassigned before the assignment; otherwise a compile-time error occurs.<ref>{{cite web|url=http://docs.oracle.com/javase/specs/jls/se8/html/jls-16.html|title=Definite Assignment|year=2015|work=The Java® Language Specification (Java SE 8 Edition)|publisher=Oracle America, Inc.|access-date=29 Oct 2016}}</ref>
final boolean hasTwoDigits;
if (number >= 10 && number < 100) {
hasTwoDigits = true;
}
if (number > -100 && number <= -10) {
hasTwoDigits = true; // compile-error because the final variable might already be assigned.
}
</syntaxhighlight>
 
In addition, a blank final also has to be definitely assigned before being accessed.<ref name="define_assignment" />
<syntaxhighlight lang="java">
final boolean isEven;
 
if (number % 2 == 0) {
isEven = true;
}
 
System.out.println(isEven); // compile-error because the variable was not assigned in the else-case.
 
</syntaxhighlight>
 
Note though that a non-final local variable also needs to be definitely assigned before being accessed.<ref name="define_assignment" />
 
<syntaxhighlight lang="java">
boolean isEven; // *not* final
 
if (number % 2 == 0) {
isEven = true;
}
 
System.out.println(isEven); // Same compile-error because the non-final variable was not assigned in the else-case.
 
</syntaxhighlight>
 
==C/C++ analog of final variables==
{{detailsfurther|const (computer programming)}}
In [[C (programming language)|C]] and [[C++]], the analogous construct is the <code>[[const (computer programming)|const]]</code> [[keyword (computer programming)|keyword]]. This differs substantially from <code>final</code> in Java, most basically in being a [[type qualifier]]: <code>const</code> is part of the ''[[data type|type]],'' not only part of the identifier (variable). This also means that the constancy of a value can be changed by casting (explicit type conversion), in this case known as "const casting". Nonetheless, casting away constness and then modifying the object results in [[undefined behavior]] if the object was originally declared <code>const</code>. Java's <code>final</code> is a strict rule such that it is impossible to compile code that directly breaks or bypasses the final restrictions. Using [[Reflection (computer programming)#Java|reflection]], however, it is often possible to still modify final variables. This feature is mostly made use of when [[Serialization|deserializing]] objects with final members.
 
Further, because C and C++ expose pointers and references directly, there is a distinction between whether the pointer itself is constant, and whether the data pointed to by the pointer is constant. Applying <code>const</code> to a pointer itself, as in <code>SomeClass * const ptr</code>, means that the contents being referenced can be modified, but the reference itself cannot (without casting). This usage results in behaviour which mimics the behaviour of a <code>final</code> variable reference in Java. By contrast, when applying const to the referenced data only, as in <code>const SomeClass * ptr</code>, the contents cannot be modified (without casting), but the reference itself can. Both the reference and the contents being referenced can be declared as <code>const</code>.
 
In C++, the <code>final</code> keyword is used to denote that a function cannot be further overridden. It is also used similarly to Java to declare a class as final (cannot be extended).
In C++, <code>const</code> is a soft guideline that programmers can easily override by [[Type casting (computer programming)|type casting]] a const reference to a non-const reference. Java's <code>final</code> is a strict rule such that it is impossible to compile code that directly breaks or bypasses the final restrictions. Using [[Reflection (computer programming)#Java|reflection]], however, it is often possible to still modify final variables. This feature is mostly made use of when [[Serialization|deserializing]] objects with final members.
 
<syntaxhighlight lang="C++">
==References==
// final in a class declaration declares that a class cannot be extended
class Z final : public X, public Y {
public:
// final in a method signature declares that a method cannot be overridden further
void someOperation() override final {
// do something here
}
};
</syntaxhighlight>
 
==C# analogs for final keyword ==
[[C Sharp (programming language)|C#]] can be considered as similar to Java, in terms of its language features and basic syntax: Java has JVM, C# has .Net Framework; Java has bytecode, C# has MSIL; Java has no pointers (real memory) support, C# is the same.
 
Regarding the final keyword, C# has two related keywords:
# The equivalent keyword for methods and classes is <code>sealed</code>
# The equivalent keyword for variables is <code>readonly</code> <ref>[https://stackoverflow.com/questions/1327544/what-is-the-equivalent-of-javas-final-in-c What is the equivalent of Java's final in C#?]</ref>
 
Note that a key difference between the C/C++ derived keyword <code>const</code> and the C# keyword <code>readonly</code> is that <code>const</code> is evaluated at compile time, while <code>readonly</code> is evaluated at runtime, and thus can have an expression that is only calculated and fixed later (at runtime).
 
== See also ==
* [[final (C++)]]
 
==References==
{{reflist}}