Typically when you use advanced polymorphism techniques is when errors come up.
Generics can allow you to do fancy things to avoid these errors.
I honestly want to see performance gains.
Casting from Object to “Type” is very slow.
That article states that most of the time there is no casting, at compile time Object is replaced by “Type” and if “Type” cannot be found, it is then casted to “Type”.
Can anyone confirm if this is the case?
Now blah, you really don’t want to know what those errors were, we’ve got 0.5mb of source code and you’re suprised that generifying it didn’t catch a bunch of class cast exceptions ahead of time?
Cas 
I’ve gone through the Java bytecode and it inded does treat as Object.
There are no compile time replacements.
Oh well.
well, I thought you could perhaps describe an example or two in plain text, perhaps quote some small sample code fragments involved?
Haa, haven’t got the time to go fiddling around looking for this stuff The errors were all in my minions’ code, anyway 8)
Cas
One example that I have seen a few times is with the Collection api, where you want to add the content of one collection to another collection, but mistakenly type just add instead of addAll.
I guess i agree with the sumamtion that generics add run-time checking at the cost of readability.
To me its a bad trade. There are a few mistakes of the type that Mark mentions that you cna make if not careful that wont be caught at run time. (ANother is calling map.remove(…) on the value rather then the key) but if your awake and watching what you are doing they are pretty easy to catch and fix and I contend that ocne you’ve done them once you never will again.
FOr the rest of the errors you can make, run-time type checks catch then quick enough for my tsates.
Generics might make sense in some absolutely time-ciritcal places in code if they eliminated those run-time checks, but I don’t think they can as they are pure syntactic sugar. There were no VM changes made to support them.
Edit: And I should add that in general the VM is pretty savvy about minizing the impact of the run-time type checking.
To go slightly off topic…
Autroboxing though IMHO is just evil and a mistake and was added in a fervor of C# me-too-ism.
Note: I have no read the complete discussion, so please apologize if I will reapeat something previously mentioned.
Hm, I’m perferctly happy with the new features, which become avaible in the tiger release. This may be because I’ve worked with C# 2.0 since the .NET Framework 2 Beta was availbale and don’t want wot miss anything now in programming in Java.
At first I like the new enumeration type. Although IMHO it wasn’t really needed, it is saves a little bit code using the BitVector class and it offers great flexibility compared to other languages.
Auto-boxing is the ony feature I’m watching with a good and a bad eye. The implementation shouldn’t be compared to the one of C# since the C# compiler only performs (forward) auto-boxing. In contrast to that the Java version can do auto-unboxing (back from the reference type to a value type).
Although in most cases the amount of code reduces, there are some issues I don’t like because the lack of constancy, e.g.
Integer i1 = 100, i2 = 100; // same as Integer.valueOf(100), i2 = Integer.valueOf(100);
Integer j1 = 100, j2 = 200; // same as Integer.valueOf(200), j2 = Integer.valueOf(200);
System.out.println(i1==i2); // true
System.out.println(j1==j2); //false
Of course the comparison is done on the reference and not the values, but i0,i1 share the same object while j1 and j2 don’t. That is because the wrapper classes only have a cache for often used numbers between [-128 /or 0.0,127].
As it comes for generics, I won’t take my hands on Java without them. I’m very happy with the implementation, especially that value types cannot be used with them. In C# it is o.k., because you can define own value types. However In Java, you cannot due to generality of reference objects, which I really prefer. (A simple language can be used and optimized more easily).
The reason I don’t want to miss generics is not because it reduces potentially number of ClassCastExceptions thrown, I love them because they enable Meta-Programming. See the algebra packe in the code I have uploaded (for Jeff) in another thread, although the code isn’t a fast as other, the matrix and vector functionality has to be programmed ones for all types, for which a field is defined. (In this sample case implemented fields are float, double and BigDecimal).
Go Java Go
Argh! I’ve done that :(. Twice, in fact >:(. First time it took several days to fix, second time several hours. Since then, as you say, I’ve never forgotten. Even seing the method name, my first throught is “key not value” ;D.
IMHO this would be a fantastic thing to get rid of. It’s worth, oh, about 1 programmer day per year per project. Um. Generics costs, what, tens?, hundreds? of programmer days per year per project. Not a good trade (as Jeff says).
Jeff - I must be ill, I completely and utterly agree with you in all ways :P.
Covariant returns may eliminate some runtime checks. This didn’t require a VM change because the return type was already part of the signature at VM level. It is a pity we had to wait for generics to get covariant returns.
Interesting, thanks.
I just learned something new about coding Java
I dislike generics because they took what was once a very simple and elegant language and made it look like C++. I think Java’s readability was one of its strong points.
I like generics because they also in their own way increase readability. Specifying what type of objects a container contains is very helpful in reminding what it was for (this was a life saver after coming back to some code I hadn’t touched in months). And of course increased type safety is always a plus as often mentioned.
I’ve finally focused why I dislike genreics.
They are incomplete syntax.
For example, take this statement
private MyClass foo();
What does that synatx mean? The answer is its not competely defined. I have no idea what is being used for without consulting the definition of MyClass.
We avoided a mcro pre-processort in Java originally for just thsi reason-- its the fastest way in C to unreadable code.
But now we’ve brought it in anyway.
And i thin kthe oroginal decision was the right one.
I think Java should have is either runtime generics or auto casting without generics.
Any chance this will happen?
Sun? Go back on a publically made decision that’s now crafted in API stone?
Chances it’ll change are somewhere between nil to zero.
I’ve read something positive about generics for a change:
http://www.thepostmodern.net/blog/BlogEntry.jsp?id=151