Re: "null", polymorphism and TCO
On 10.02.15 05.35, Kevin McMurtrie wrote:
An enum named something like EOF is, of course, much better but it can't
be put into BlockingDeque<String>.
Since Java uses type erasure I would not bet on it. With some cast to a
non-generic container you will probably succeed. But you will also
dislike the exception when extracting it as a String.
Every once in a while I hear talk of adding automatic String interning
or optimizing away the String(String) constructor such that this becomes
true:
new String("foo") == "foo"
It would surely break tons of code. Not only would it break unique
tokens, but it would break WeakHashMap<String, ?> too.
Probably no one will ever remove an explicit constructor call.
But this does not apply if you assign string constants. E.g.
String s1 = "foo";
s1 == "foo" // might be true
Probably it will be true in most cases since the Java compiler will
likely not create two instances of the same constant. But I am unsure
what happens if the two lines are in different java or jar files. I
think it is simply undefined behavior.
So in your example
static final String endOfQueue= new String();
should do the job as well.
This is similar to the old style typesafe enum pattern:
final class MyEnum
{ private final int Value;
private MyEnum(int value) { Value = value; }
public static final MyEnum AVALUE = new MyEnum(1);
public static final MyEnum ANOTHERVALUE = new MyEnum(2);
...
}
This commonly used pattern is stupid. The integer is entirely superfluous.
final class MyEnum
{ private MyEnum() {}
public static final MyEnum AVALUE = new MyEnum();
public static final MyEnum ANOTHERVALUE = new MyEnum();
...
}
This will do the job as well.
Of course, the new type safe enums in Java are more convenient.
Marcel