That is, two bugs in the language specification that allow a program to compile without warnings but to produce a ClassCastException at runtime on a line with no explicit cast.
class Outer<E> {
Inner inner;
class Inner {
E e;
E getOtherElement(Object other) {
if (!(other instanceof Outer.Inner)) {
throw new IllegalArgumentException(String.valueOf(other));
}
Inner that = (Inner) other;
return that.e;
}
}
public static void main(String[] args) {
Outer<String> s = new Outer<String>();
s.inner = s.new Inner();
s.inner.e = "hello";
Outer<Integer> i = new Outer<Integer>();
i.inner = i.new Inner();
i.inner.e = 1234;
String producesClassCast = s.inner.getOtherElement(i.inner);
}
}
Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String at Outer.main(Outer.java:26)
The Java language specification lacks rules about casts to inner classes. Commonly used versions of javac happen to allow us to cast to Inner — that is, to cast to Outer<E>.Inner — without a warning. The more honest version of the cast, (Outer<E>.Inner), ought likewise to be permitted with a warning; it's rejected outright.
This subtle interaction between generics and inner classes pales in comparison to...
import java.util.HashSet;
import static java.util.Collections.singleton;
class Printer {
static <E> void print(Iterable<E> input) {
for (E e : input) {
System.out.println("Unsorted " + e);
}
}
}
class SortedPrinter extends Printer {
static <E extends Comparable<? super E>> void print(Iterable<E> input) {
for (E e : input) {
System.out.println("Sorted " + e);
}
}
}
class Caller {
public static void main(String[] args) {
SortedPrinter.print(singleton(1));
SortedPrinter.print(singleton(null));
SortedPrinter.print(singleton(new HashSet<Object>()));
}
}Sorted 1 Sorted null Exception in thread "main" java.lang.ClassCastException: java.util.HashSet cannot be cast to java.lang.Comparable at SortedPrinter.print(Caller.java:14) at Caller.main(Caller.java:24)
You need two obscure pieces of knowledge to understand this one:
class Base {
static void foo() {}
}
class Derived extends Base {
}Derived.foo() is "void Derived.foo(),"
not "void Base.foo()." The VM knows to look for the method first in Derived
and then in Base.
So:
The compiler can see that Collection<HashSet<Object>> does not
implement Comparable. Thus, it chooses the more general "inherited" version <E>
print(Iterable<E>) over the restricted version <E extends Comparable<? super E>>
print(Iterable<E>). Nevertheless, per point #2 above, the bytecode it produces still reads "void
SortedPrinter.print(Iterable)."
The VM sees "void SortedPrinter.print(Iterable)" and begins its search for void print(Iterable) in
SortedPrinter. SortedPrinter has exactly such a method. The fact that it requires
its input to be Comparable is unavailable at runtime. The VM chooses that method.
Thus, all three "SortedPrinter.print()" calls end up really calling
SortedPrinter.print(), even though the compiler/IDE believes it is
compiling a call to Printer.print() in the HashSet case. At runtime,
SortedPrinter.print() implicitly casts each element of its input to
Comparable ("for (E e : input)"), and the failure to cast HashSet gives
us a ClassCastException.
This is a hole in the type system, but the fun doesn't stop there. By adding method X, I can cause a call to method Y to become a call to method Z:
import java.util.HashSet;
import static java.util.Collections.singleton;
class Base {
static <E> Object count(Iterable<E> input) {
System.out.println("Base");
int count = 0;
for (E e : input) {
count++;
}
return count;
}
}
class Sub extends Base {
/* static <E> Integer count(Iterable<E> input) {
System.out.println("Sub");
int count = 0;
for (E e : input) {
count++;
}
return count;
}*/
}
class Subsub extends Sub {
static <E extends Comparable<? super E>> Integer count(Iterable<E> input) {
System.out.println("Subsub");
int count = 0;
for (E e : input) {
count++;
}
return count;
}
}
class Caller2 {
public static void main(String[] args) {
Subsub.count(singleton(1));
Subsub.count(singleton(null));
Subsub.count(singleton(new HashSet<Object>()));
}
}With Sub.count() commented out, we get:
Subsub Base Base
With Sub.count() restored, we get:
Subsub Subsub Subsub <the ClassCastException>
Notice that in no case is Sub.count() itself called. Its mere presence affects the behavior of the program.
Why? The existence of Sub.count() makes the compiler write "Integer Subsub.count()" instead of "Object Subsub.count()." At runtime, the former resolves to Subsub.count(); the latter, to Base.count().
If you do want Sub.count() to be called, you must change its return type to Object. Then we get:
Subsub Sub Sub
Changing the method's return type again changes which method is called. The first method the compiler finds when looking for an appropriate Subsub.count() is still Sub.count(), but now it writes "Object Subsub.count()" instead of "Integer Subsub.count()." At runtime, the former resolves to the appropriate method.
First, the controversial part: When a compiler identifies a call to method X, it should produce code that calls method X, not hypothetical method Y.
Second, programmers should generally avoid "overriding" static methods, most of all when type parameters are involved. <E extends Comparable<? super E>> ImmutableSortedSet.of(E) and its superclass's <E> ImmutableSet.of(E) do not play nicely together. Expect some gymnastics in the ImmutableSortedSet code next release.
Static factory methods can:
Static factory methods can assist in safe publication and can allow for selective type bounds.
Sometimes you want to create an object and publish a reference to it at the same time. Sometimes you publish the reference where other threads can see it. The obvious approach is to handle it all in the constructor:
public final class Request {
/** A request from some point in the past. */
public static Request sampleRequest;
private final Query query;
private final User user;
public Request(Query query, User user) {
this.query = query;
this.user = user;
sampleRequest = this;
}
public Query getQuery() { return query; }
public User getUser() { return user; }
}Notice that sampleRequest is not declared volatile. The intent is to give up the guarantee that all threads will see the most recent value in favor of the speed of a non‐volatile write. And it would work if only the code were slightly different:
public final class Request {
/** A request from some point in the past. */
public static Request sampleRequest;
private final Query query;
private final User user;
public static Request create(Query query, User user) {
Request request = new Request(query, user);
sampleRequest = request;
return request;
}
private Request(Query query, User user) {
this.query = query;
this.user = user;
}
public Query getQuery() { return query; }
public User getUser() { return user; }
}Readers of an object published by the former code can behave nondeterministically. But the latter code, by waiting until after the constructor to publish the reference (and by containing no non‐final fields), takes advantage of a feature of the memory model: the end‐of‐constructor "freeze." This freeze ensures that the object appears fully initialized (and thus immutable) to other threads. Read Jeremy Manson's article on immutability, and see also Java Concurrency in Practice pg. 41–42.
What does this esoteric knowledge gain you? Very little. The reason is that examples like the above are rare. In most cases, the act of publishing the reference is a volatile write or another synchronization action, such as adding the reference to a thread‐safe list of listeners. Such actions guarantee that all steps performed before the publishing step are visible to all threads reading the reference. The end‐of‐constructor freeze is superfluous.
All this said, if you depend on others to write defensive code and they depend on you, you'll have problems. Incomplete object initialization can be a security vulnerability: An uninitialized "immutable" object might appear to contain an innocuous request during security checks, only to transform into a malicious one before execution. Maybe spawning 0 processes is acceptable but 1,000,000 is not, or maybe 0 is a valid seed in a crypto algorithm but 1,000,000 is not.
When parameterizing a class, I can choose to set bounds on the type parameter. For example, EnumSet has type parameter <E extends Enum<E>>. Or I can leave it unbounded: HashSet has type parameter E.
Bounded or unbounded: What other options do I need? Consider TreeSet. TreeSet instances divide into two groups: those with a Comparator and those without. When the caller provides a Comparator, the TreeSet can contain any kind of element supported by the Comparator. Since I can define a Comparator for any type that I like, I can create a TreeSet<List>, a TreeSet<Rectangle>, or any other type, so long as I provide an appropriate Comparator. On the other hand, when the caller does not provide a Comparator, the TreeSet can only contain elements that implement Comparable (specifically, elements that are Comparable to one another). A TreeSet<List> without a Comparator will throw exceptions when it is used.
The class's type parameter alone cannot provide us with the flexibility to solve this problem. The result is two kinds of TreeSet constructors. The first takes a Comparator. As it should, it allows the caller to fill in any type for the type parameter, provided that it's compatible with the given Comparator. The second type of constructor takes no Comparator argument, yet it, too, lets the client fill in any type for the type parameter. This is broken, as it should allow only classes that implement Comparable.
The fix is to remove TreeSet's constructors in favor of static factory methods:
<E> TreeSet<E> newTreeSet(Comparator<? super E> comparator); <E extends Comparable<E>> TreeSet<E> newTreeSet();
As before, clients that provide a Comparator can create TreeSet instances for non‐Comparable types. But now an attempt to create a TreeSet instance for a non‐Comparable type without supplying a Comparator will fail at compile time.
Another option is to do away with the no‐arg constructor entirely and to force callers to pass Comparators.naturalOrder(), a Comparator<C> for any C that extends Comparable, to the remaining constructor. It won't take many calls to new TreeSet<T>(Comparators.<T>naturalOrder()) to suggest that a static factory method is in order.
Java trivia: Parameterized constructors are permitted:
private <T> MyClass() { ... }
However, I have not found a way to use parameterized constructors to produce an equivalent solution.
TreeSet and other SortedSet implementations are the obvious example. I could also imagine a scenario in which a class can serialize either (a) a class that knows how to convert itself to a string or (b) an arbitrary object plus an object that knows how to convert it to a string. These cases are analogous the SortedSet case: Some objects can perform the necessary tasks themselves, while others require an external converter. Static factory methods allow us to check uses of both types at compile time.
<E> Serializer<E> newStringSerializer(Stringifier<E> stringifier); <E extends Stringifiable> Serializer<E> newStringSerializer();
It's also possible to permit only a fixed set of type parameters:
Serializer<Integer> newSerializer(); Serializer<String> newSerializer();
Static factory methods can:
Static factory methods can assist in safe publication and can allow for selective type bounds.
Sometimes you want to create an object and publish a reference to it at the same time. Sometimes you publish the reference where other threads can see it. The obvious approach is to handle it all in the constructor:
public final class Request {
/** A request from some point in the past. */
public static Request sampleRequest;
private final Query query;
private final User user;
public Request(Query query, User user) {
this.query = query;
this.user = user;
sampleRequest = this;
}
public Query getQuery() { return query; }
public User getUser() { return user; }
}Notice that sampleRequest is not declared volatile. The intent is to give up the guarantee that all threads will see the most recent value in favor of the speed of a non‐volatile write. And it would work if only the code were slightly different:
public final class Request {
/** A request from some point in the past. */
public static Request sampleRequest;
private final Query query;
private final User user;
public static Request create(Query query, User user) {
Request request = new Request(query, user);
sampleRequest = request;
return request;
}
private Request(Query query, User user) {
this.query = query;
this.user = user;
}
public Query getQuery() { return query; }
public User getUser() { return user; }
}Readers of an object published by the former code can behave nondeterministically. But the latter code, by waiting until after the constructor to publish the reference (and by containing no non‐final fields), takes advantage of a feature of the memory model: the end‐of‐constructor "freeze." This freeze ensures that the object appears fully initialized (and thus immutable) to other threads. Read Jeremy Manson's article on immutability, and see also Java Concurrency in Practice pg. 41–42.
What does this esoteric knowledge gain you? Very little. The reason is that examples like the above are rare. In most cases, the act of publishing the reference is a volatile write or another synchronization action, such as adding the reference to a thread‐safe list of listeners. Such actions guarantee that all steps performed before the publishing step are visible to all threads reading the reference. The end‐of‐constructor freeze is superfluous.
All this said, if you depend on others to write defensive code and they depend on you, you'll have problems. Incomplete object initialization can be a security vulnerability: An uninitialized "immutable" object might appear to contain an innocuous request during security checks, only to transform into a malicious one before execution. Maybe spawning 0 processes is acceptable but 1,000,000 is not, or maybe 0 is a valid seed in a crypto algorithm but 1,000,000 is not.
When parameterizing a class, I can choose to set bounds on the type parameter. For example, EnumSet has type parameter <E extends Enum<E>>. Or I can leave it unbounded: HashSet has type parameter E.
Bounded or unbounded: What other options do I need? Consider TreeSet. TreeSet instances divide into two groups: those with a Comparator and those without. When the caller provides a Comparator, the TreeSet can contain any kind of element supported by the Comparator. Since I can define a Comparator for any type that I like, I can create a TreeSet<List>, a TreeSet<Rectangle>, or any other type, so long as I provide an appropriate Comparator. On the other hand, when the caller does not provide a Comparator, the TreeSet can only contain elements that implement Comparable (specifically, elements that are Comparable to one another). A TreeSet<List> without a Comparator will throw exceptions when it is used.
The class's type parameter alone cannot provide us with the flexibility to solve this problem. The result is two kinds of TreeSet constructors. The first takes a Comparator. As it should, it allows the caller to fill in any type for the type parameter, provided that it's compatible with the given Comparator. The second type of constructor takes no Comparator argument, yet it, too, lets the client fill in any type for the type parameter. This is broken, as it should allow only classes that implement Comparable.
The fix is to remove TreeSet's constructors in favor of static factory methods:
<E> TreeSet<E> newTreeSet(Comparator<? super E> comparator); <E extends Comparable<E>> TreeSet<E> newTreeSet();
As before, clients that provide a Comparator can create TreeSet instances for non‐Comparable types. But now an attempt to create a TreeSet instance for a non‐Comparable type without supplying a Comparator will fail at compile time.
Another option is to do away with the no‐arg constructor entirely and to force callers to pass Comparators.naturalOrder(), a Comparator<C> for any C that extends Comparable, to the remaining constructor. It won't take many calls to new TreeSet<T>(Comparators.<T>naturalOrder()) to suggest that a static factory method is in order.
Java trivia: Parameterized constructors are permitted:
private <T> MyClass() { ... }
However, I have not found a way to use parameterized constructors to produce an equivalent solution.
TreeSet and other SortedSet implementations are the obvious example. I could also imagine a scenario in which a class can serialize either (a) a class that knows how to convert itself to a string or (b) an arbitrary object plus an object that knows how to convert it to a string. These cases are analogous the SortedSet case: Some objects can perform the necessary tasks themselves, while others require an external converter. Static factory methods allow us to check uses of both types at compile time.
<E> Serializer<E> newStringSerializer(Stringifier<E> stringifier); <E extends Stringifiable> Serializer<E> newStringSerializer();
It's also possible to permit only a fixed set of type parameters:
Serializer<Integer> newSerializer(); Serializer<String> newSerializer();