Do we really need static final constants in Java?
Assume I have the following code:
public class Test {
public static final int A = 1234;
public static int getA()
{
return 1234;
}
}
Can you please compare the following two cases in terms of efficiency?
Test.A
Test.getA()
Answer 5518b447937676d350004c42. Constants can be used with public or private just fine!
A value-returning method returns a value of some specific type. When the method is defined, this type comes before the method name. In the body of the method there must be a return statement that returns some value matching the return type of the method.
Within the body of the method, you use the return statement to return the value. Any method declared void doesn't return a value. It does not need to contain a return statement, but it may do so.
To turn an ordinary variable into a constant, you have to use the keyword "final." As a rule, we write constants in capital letters to differentiate them from ordinary variables. If you try to change the constant in the program, javac (the Java Compiler) sends an error message.
Assuming a JIT compiler, there should be no noticeable difference in efficiency - at least not enough to make a significant difference in the execution speed of your application.
There is a noticeable gain in flexibility, though: encapsulating the value in a method is nearly always good, because it lets you change the way the value is calculate later.
A notable exception to this rule is pure constants, say, from the world of mathematics: it does not make much sense to encapsulate access to Math.PI
, because there is no chance that the value of this fundamental constant is going to change, prompting a need to switch the method the value is obtained in your program.
The static
final
constants behave differently than literal values returned from a method. The java compiler also uses these in certain cases at compile time.
One example,
public static boolean DEBUG = false;
...
if (DEBUG)
{
...do something...
}
vs.
public boolean debug()
{
return false;
}
...
if (debug())
{
...do something 2...
}
In the first case, the condition and ...do something... code will not be included in the compiled byte-code (the class file). In the second case, the condition and ...do something 2... code will be included but never execute - the JIT may do sufficient analysis in this case though to remove the code at runtime.
At one time, in the early days of Java, the JIT didn't exist or was not smart enough to optimize out the simple method that returns a literal value. Then a constant value was needed for performance. It's also more convenient to define constants this way if you keep in mind that external classes (for public/protected static final constants) will have the value baked in to that byte-code at compile time; rather than getting the value from the source class at runtime.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With