Why does code alternative(1) compile without warnings, and code alternative(2) produce an \"unchecked cast\" warning?
Common for both:
class Foo
I'm unable to find anything in the JLS, both the @SuppressWarnings
(JLS 9.6.3.5) and unchecked warnings (JLS 5.1.9) sections don't seem to have any issues that could lead to this problem. My guess (without testing your SSCE myself) is that you've found a bug in the compiler. I'd recommend filing a bug report with Oracle and adding the report link to your question.
In short, the order of members in the class should be completely independent about how warnings are processed. It may be an edge case in just the unchecked warning code, or it may be a larger problem.
In the meantime, you can eliminate all of your problems by doing what you should have done in the first place, and dynamically generate the empty array instead of casting an existing one, as outlined in this question.
Edit
I don't see how the linked proposal would work in case of my
EMPTY_ARRAY
that is astatic final
.
Don't make it static final
anymore, and provide a Class<T>
in your constructor:
@SuppressWarnings("unchecked") // Still need this
public Bar(Class<T> clazz) {
super((T[]) Array.newInstance(clazz, 0));
}
Java pretty much never uses the value of a final
variable for warnings except in cases of dead code. Otherwise, you'd get edge cases like this:
class Bar<T> extends Foo<T> {
// Is it really empty?
protected static final Object [] EMPTY_ARRAY = SomeOtherClass.getEmptyArray();
@SuppressWarnings("unchecked")
Bar() {
super( (T []) EMPTY_ARRAY );
}
}
They'd have to write that logic into the compiler. It's unnecessary complication for edge cases like "empty arrays", and besides, this casting like this is all code smell in the end.
Another option you might have besides that answer is to use var args. Foo
:
class Foo<T> {
Foo( T ... arg ) {
}
}
And Bar
:
class Bar<T> extends Foo<T> {
Bar() {
super();
}
}
That should work, and it eliminates all casting, empty arrays, warnings, etc. See more about var args and their possible invocations here.
I was able to reproduce the behavior with this simplified setup:
class Bar<T> {
@SuppressWarnings("unchecked")
Bar() {
T[]dummy = (T[]) EMPTY_ARRAY;
}
private static final Object [] EMPTY_ARRAY = {};
}
As Brian suggested, it seems to be a bug in the compiler. Additionally, this behavior is restricted to Arrays - replacing the EMPTY_ARRAY with an Object
and casting it to a T
does not issue a warning as expected.
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)
I'm able to emulate this strange behaviour on my Windows 7 64b machine with:
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
OpenJDK Runtime Environment (build 1.8.0-ea-lambda-nightly-h1669-20121030-b63-b00)
Which means both the OpenJDK and the Oracle JDK are affected, both JDK7 and JDK8 (yes, you can already download it).
Eclipse, since it uses its own JDT compiler, doesn't have this problem.
So it seems that this is indeed a javac
bug. If you report it, please keep me updated.
I've also located a JDK6 installation on my computer, so I tried that one and actually, it works without a warning in both cases, which is the correct behaviour:
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Although my Windows are 64b, all the said JDKs are only 32b.
It's a bug in both Oracle and OpenJDK 7 and 8.
You can't (shouldn't) get compile warnings/errors from reordering declarations in a class.
Runtime errors, yes; compiler errors, no.
This is Bug 8016636 (thanks for filing it), but there's been no activity in over a year.
Unfortunately, that is not uncommon in Oracle's bug tracker.
Additional weirdness:
The warning is suppressed if EMPTY_ARRAY
is not final
.
Ironically, the warning is suppressed with if you initialize it with a non-array, e.g. Object EMPTY_ARRAY = new Object()
. (But don't do that...)