Slashdot Mirror
Sun to Add Variance to Java in 1.5?
Ahe writes "I have been working on a joint project between
Sun Microsystems,
The University of Aarhus,
and The Alexandra Institute.
As you might know, Sun has for long been commited to
adding generics
to Java. Our project was to extend this with variance annotations for
more flexible typing of parameterized classes and arrays. Recently
Sun has released the project result as a
new prototype
with variance. If you like variance, please vote for this bug."
Generics are at best a trade-off: compile-time type safety in exchange for less readable code. A poor trade-off at best.
Java never has and never will suffer the catastrophic consequences of type casting that C++ can. Type casts are all subject to runtime checks, so that the worst possible result is that an exception will be thrown. Where C++ has no safety without generics, Java has runtime safety.
As for readability, C++ has two major benefits over Java: a preprocessor and typedefs. Without at least one of these features, generics make code almost unreadable. Little wonder that developers new to C++ are very cautious about getting involved with generics, or that old hands know how long it has taken for the STL to become mostly stable (I say mostly, because using STL with threads in cross-platform development is a recipe for disaster).
Java is starting to look very much like something designed by a committee. A pity, because at its core it is still a good thing.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
From http://forum.java.sun.com/thread.jsp?forum=316&thr ead=389987&start=15&range=15&tstart=0&trange=1 5:
> I can't quite get my head round what combination of // legal // illegal
> VM, compiler and/or language changes would iron out
> the following incompability between arrays and
> generics:
>
> Cat[] cats = new Cat[10];
> Animal[] animals = cats;
>
> List cats = new List(10);
> List animals = cats;
> according to JSR-14
This problem is addressed in the "variance" extension to
the generic type system, which will be included in the
imminent JSR14 prototype 2.0. Details are enclosed in
the prototype.
Also a link to a MIT research paper on variance from that thread.
Ok. This is my first real drooling mad rant. Forgive me.
[rant]
about C++ casting (covariant model of generics): old-style casting was never of real use. use new_style_casts(x) and you have run-time checking, too. other stuff said about this is C++ ignorance.
[/rant]
ohboy, I had to get it off my chest.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
>ok? hope to have helped; Yes, you contributed quite a lot to common confusion with thisone.
No relation at all. That is for covariant
return types on methods, this is for
covariant (and contravariant) generic type
parameters.
En anglias:
Convariance means that, you can add a Derived to a list of Base without casting.
Contravariance means that you can unpack a Derived from a list of Base without casting.
Invariance is what you have in C++, where a list of Derived and a list of Base are two different things.
A deep unwavering belief is a sure sign you're missing something...
The term variance covers co-variance, contra-variance, and bi-variance. In the 1.5 prototype you can use variance annotations on parameterized types.
// run-time error
...;
+ means co-variant (think read-only).
- means contra-variant (think write-only).
* mean bi-variant (niether read nor write).
You are familiar with co-variance from arrays in Java.
When an array of Integer is a subtype of array of Number, arrays are said to be covariant in their element type. Consider:
Number[] ns = new Integer[10];
With generics, you can have a list of Numbers:
List<Number> nl = new List<Number>();
However, since generics are added without changing the JVM, nl can only refer to lists of exactly Number, e.g., this is wrong:
List<Number> nl = new List<Integer>();
So why is this wrong, consider arrays:
Number[] ns = new Integer[10];
ns[0] = new Double(0.0);
Since ns refers to an array of Integer, we cannot put Double in to it. The mechanism that catches this is called store-check.
Since the JVM is not modified, we cannot implement a store-check for generic classes. Variance annotations allows us more flexibility, however.
Consider this method:
void copy(Collection<+Number> src, Collection<-Number> dst) {
for (Number n : src) { dst.add(n); }
}
Here we use variance annotations to state that we will only read from src and only write to dst. In this way we are allow to make a call like this:
List<Integer> il = new List<Integer>();
List<Object> ol = new List<Object>();
copy(il, ol);
Sometimes we are not interested in reading or writing elements, so we can say:
List<*> list_of_unknown_type =
Then we can only use methods like size() on list_of_unknown_type.
Huh? Generics make code more readable!
When using non-generic containers in Java, you are usually forced to make a cast when accessing its members. For example:
String s = (String) list.get(0);
It gets worse if you are making multiple calls, because you usually need parentheses to bind the cast:
String s = ((Foo) list.get(0)).fooMethod();
However, with generics, you don't have to write the cast, because the type is implied. The bytecode is the same, but the code is much clearer:
String s = list.get(0).fooMethod();
Tell me how that is less readable. Anybody who thinks generics are unreadable is probably thinking of the worst C++ template abuses, needless complexity, and obscure syntax. Thankfully, Java generics are simple and clear.
Nope, actually "Variance". The idea is that sometimes you need to know that something is exactly of some type, sometimes you need to know that something is "at least" of some type (i.e., equal or a subtype), and sometimes you need to know that something is "at most" of some type.
Say you have a List, and you want to do:
Number num = list.get(0);
In this case, you need to know that the list contains elements which are Number or a subtype of Number, so you declare that you're taking a List<+Number>
If you want to put a Number into the list, you need to know that the list can contain Numbers, which means that it has to be a list of "at most" Numbers (i.e., it is not a List of something more specific, which would not accept a Number). You thus declare that you're taking a List<-Number>.
If you're going to do both, you require that the list contain nothing that's not a Number and that it be able to contain anything that is a Number, so you declare it to be List<=Number> (the = is optional in this case).
If you don't care what type the elements are, you can use List<*>, rather than the equivalent List<+Object> (a list which contains Objects and subtypes; unrestrictive, since everything that's not a primitive type is a subtype of Object). This is somewhat clearer, since it means that you don't care at all.
Of course, actual code is more likely to use type variables rather than Number; sort(), for instance, takes a List which is exactly of some unspecified type and a Comparator which does not require anything more specific than that type.
Variance is a neat idea, but what's the rush? The issue is dealing with arrays. Traditional arrays require that a variable of Number[] get a value of at least Number[] (i.e., +Number in the new syntax), but they allow you to store a Number in the array, even if the array is actually of a subtype of Number; if it doesn't fit, you get a runtime exception. However, the extra type information for generics isn't around at runtime, so nothing can stop a List<Number> from being stored into an array of List<Double> which has been passed into a method which takes an array of Object (at compile time, it is an array of Object getting a List<Number>, at runtime, it is an array of List getting a List, but then a[0].get(0) might be an Integer not a Double like it's supposed to be). So the idea is to get a version of arrays like the variance-using Lists above into the language to be used with generics, which implies including variance at the same time as generics, so that unsafe arrays mixed with generics can be prohibited.