public static [T] Option[T] none() {return new None[T]();}

private Option[String] value = none();

and this would be illegal

private void foo(Option[Object] x) {…}
foo(value)

You have to write
private void foo(Option[? extends Object] x) {…}
foo(value)

private Option value = new None();

can be replaced with

private Option value = none();

and

public static Option none() { return new None(); }

Peace
-stephan

I’m actually not quite so extreme as to think there should be no innovation whatever in the Java language, but I wouldn’t be particularly upset if that turned out to be the case. Bruce Eckel puts it well in . I also broadly agree with Josh Bloch’s argument against the proposed closures extension at . However, change is always more exciting than stasis, so I ultimately expect reactionaries like me to be ignored.

Eamonn,
Is there such a camp? On what forum do they put submit their interests? I can’t find any. Are you worried about “innovation” being applied to Scala in the same way “innovation” has been applied to Java in the past? Reading the mailing lists in recent months, I certainly am. This puts me on the fence – maybe closures would ultimately be good for Java to appease my own personal interests.

It can be made slightly less painful using static factory methods (with type inference) instead of or as well as public constructors, for example so you could write Option[Boolean] value = None.instance(). (You could even cheat horribly and have None.instance() always return the same object.)

Neal Gafter has been suggesting for some time that Java should acquire a name for the null type, probably “null”. So here we might write public class None extends Option[null], but as you note that would require writing Option[? extends Boolean] value = new None(), which is clunky.

As for me, I’m in the camp that thinks we should probably leave the Java language alone (no closures for me) and innovate in other languages such as Scala.

Java would definitely be improved with both Null and Void types (or whatever you want to call these types, in Scala they’re called Null and Nothing). As a small nit, the null type isn’t quite the bottom type in Java because it’s not a subtype of any of the primitive types. Still, as a practical matter that wouldn’t affect this discussion since primitive types can’t be be used as parameters to type constructors in Java – e.g. in Java you can’t have Option[int].

But even if Java had a denotable bottom type (say Void) or a nearly bottom type (say Null), Java’s type system creates another pain-in-the-ass. If class None extends Option[Void] then None would not be assignable to a variable of type Option[String] – you have to change the variable’s type to Option[? extends String]. Without wildcard annotations, Java generics are invariant in their type parameters. That means that to use such an Option type your Java code would be littered with wildcards.

That’s the key reason Scala supports what it calls definition sight variance. In Scala you define class Option[+T]. The plus means that the T parameter is covariant. With it you’ve got a nicely covariant parameterized type without using Scala’s equivalent of Java wildcards (existential types) throughout your code. Then Scala’s type system prevents you from using a covariant type parameter in a contravariant way or vice versa and you can safely say

val x: Option[String] = None

Java does have an equivalent to the Nothing type, namely the null type (the type of the expression “null”), but because you can’t name it its utility is somewhat limited. As you are aware, using null would have been an alternative in your Boolean case, though decidedly error-prone so I’m not suggesting it would have been a better alternative.