|
Java Compile Time Constants
This tutorials is all about Java Compile Time
Constants.
2005-09-16 The Java Specialists' Newsletter [Issue 114] - Compile-time String Constant Quiz
Author:
Dr. Heinz M. Kabutz JDK version: All
If you are reading this, and have not subscribed, please consider doing it now by going to our
subscribe page. You can subscribe either via email or RSS.
Welcome to the 114th edition of The Java(tm) Specialists' Newsletter. I learned last
Tuesday that I had been nominated as a Java
Champion. The nomination was approved this Monday.
So now I am one of the world's first elected Java Champions.
I do not fully understand yet what that means, but I am
overwhelmed that I had been noticed, considering how small
our subscription base is :)
I am going on a world tour with my family next week, to
France, Germany, Crete, USA, Greece and then back to South
Africa. In the USA, on the 5th of October, I am
speaking at the Java
In Action conference, and will demonstrate
how dynamic proxies can be put to use to reduce the amount of
code that you need to write. Please
email me if you are attending, so that we can make an
effort to meet. This is a new type of conference that
promises to be more than the usual vendor fest. The
name should give a hint: Java in Action. Kirk Pepperdine is
doing a live performance tuning demonstration, which will be
very educational to watch. (Kirk went from being a Cray
Supercomputer whizz to Java performance fundi and has some
great insight into how to make the code run really fast.)
Compile-time String Constant Quiz
This week's newsletter is based on a quiz sent to me by Clark
Updike from the John Hopkins University Applied Physics
Laboratory. Thanks Clark :)
Consider the following interface (remember that all fields in
an interface are automatically public static
final):
public interface StaticFinalTest {
String LITERAL = "Literal";
String LITERAL_PLUS = "Literal" + "Plus";
String LITERAL_NEW = new String("LiteralNew");
String LITERAL_CONCAT = "LiteralConcat".concat("");
}
And we can use this as follows:
public class StaticFinalTestClient {
public static void main(String[] args) {
System.out.println(StaticFinalTest.LITERAL);
System.out.println(StaticFinalTest.LITERAL_PLUS);
System.out.println(StaticFinalTest.LITERAL_NEW);
System.out.println(StaticFinalTest.LITERAL_CONCAT);
}
}
When we run the program, we see:
Literal
LiteralPlus
LiteralNew
LiteralConcat
Now Change StaticFinalTest, compile it, but do not compile
StaticFinalTestClient. If you in an IDE, you will have to
compile it from the command line.
public interface StaticFinalTest {
String LITERAL = "LiteralXXX";
String LITERAL_PLUS = "Literal" + "PlusXXX";
String LITERAL_NEW = new String("LiteralNewXXX");
String LITERAL_CONCAT = "LiteralConcat".concat("XXX");
}
Here is the quiz: What is the output? (scroll down for the
answer)
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Literal
LiteralPlus
LiteralNewXXX
LiteralConcatXXX
At compile time, all final fields that have a
constant value, and are either primitive or String, get
inlined by the compiler. This includes of course the Strings
in our StaticFinalTest class. Since the NEW and CONCAT
values are not compile time literals they are not inlined.
So, when you change libraries, you have to recompile all your
code. This limits how you change between libraries. You
cannot simply swap out libraries at runtime, because
if you as soon as you use constants, they are inlined and
require a full recompile of your code.
Whilst I would think this is really widely understood, I have
met a number of Java programmers who did not realise this.
Unit Testing
Be careful when writing unit tests. If you look at the
following (incorrect) code, we can write unit tests that make
it appear correct:
public class Car {
private final String registrationNumber;
public Car(String registrationNumber) {
this.registrationNumber = registrationNumber;
}
public boolean equals(Object o) {
if (!(o instanceof Car)) return false;
return registrationNumber == ((Car) o).registrationNumber;
}
public int hashCode() {
return registrationNumber.hashCode();
}
}
The code is obviously incorrect, because it compares Strings
using the == operator, instead of equals(). But look at this
unit test, which one would you write?
import junit.framework.TestCase;
public class CarTest extends TestCase {
public void testIncorrect() {
assertEquals(
new Car("CET192233"),
new Car("CET192233"));
}
public void testCorrect() {
assertEquals(
new Car(new String("CET192233")),
new Car("CET192233"));
}
}
The first test is incorrect, since it compares the Car
objects with identical strings, so the equals() method
appears correct.
In JDK 1.1 and 1.0, final methods were inlined as
well if you compiled with the -O option. Since
Java 2, final methods are only inlined at runtime by the
hotspot compiler (if necessary).
Hope to see you in Orlando at Java in Action
in three weeks time :)
Kind regards
Heinz
This material from
The Java(tm) Specialists' Newsletter by Maximum Solutions (South Africa). Please
contact Maximum Solutions for
more information.
|