Yes it does. You didn't read the Generic specification didn't you?
In it, it clearly states that covariant return types is a consequence of implementing generics. I suppose I could quote the spec for you, and I guess I will if you still don't believe me. But I'd rather have you trust my word.
The trick is to create a HashMap of runnables, keyed on your type safe enum type (yes, you have to implement equals() and hashCode() but that's two-button operation in IDEA), where the value is a Runnable with the code you want to run.
You're confusing "generics" with "templates" here. Templates are C++ attempt of providing generics which is horribly ugly, and very non-OO. It also leads to huge amounts of code when the templates are instantiated.
What Java 1.5 generics do, is to provide a way of moving the type check for the downcast to comple time rather than runtime. It's still the exact same object model, and there are no templates.
The really huge advantage that generics will bring us is (and you will have to read the spec to realise this is the case) that we are getting...
(drum roll)
Covariant return types!
All of these suntactic sygar feautres can easily be worked around, but the lack of covariant return types has been a real problem for many people (often without knowing the name of the feature they miss). Especially when trying to do inheritence in EJB's, you really need them.
For those of you who are interested, what are covariant return types?
Consider the following code:
interface Company { Collection getEmployees(); }
class SomeCompany implements Company { private List employees =...;
List getEmployees() {// It will fail here without covariant return types return employees; } }
I suppose you can figure out for yourself now how this can be very useful.:-)
You should avery rarely need typesafe enums, or enums at all actually. Excessive use of enums is a typical code smell that the programmer didn't understand object orientation well enough.
Usually I have somehting like one enum per 10000 lines of code or so. While I think that the enums in 1.5 will be a great help, I certainly don't think it's a huge amazing feature.
(of course I was in such a hurry to post my last message that I missed the fact that I got all the html messed up. Should be fixed now)
You will be glad to hear that the typed collections are completely optional. The default is the same old. You can even do this:// declare a typed list
List foo = new List();// assign it to a normal list
List bar = foo;// Doing it the other way around requires a cast:
List foo = new List();
List bar = (List)foo;
All very logical, isn't it?
Download the preview and try for yourself.
You will be glad to hear that the typed collections are completely optional. The default is the same old. You can even do this:// declare a typed list List foo = new List();// assign it to a normal list List bar = foo;// Doing it the other way around requires a cast: List foo = new List(); List bar = (List)foo;
In it, it clearly states that covariant return types is a consequence of implementing generics. I suppose I could quote the spec for you, and I guess I will if you still don't believe me. But I'd rather have you trust my word.
Absolutely no information? What do you call this then? http://www.jcp.org/en/jsr/detail?id=166
The trick is to create a HashMap of runnables, keyed on your type safe enum type (yes, you have to implement equals() and hashCode() but that's two-button operation in IDEA), where the value is a Runnable with the code you want to run.
Calling the code looks something like this:
Also note my use of generics to spice things up. :-)
What Java 1.5 generics do, is to provide a way of moving the type check for the downcast to comple time rather than runtime. It's still the exact same object model, and there are no templates.
Umm... Well... "read pretty well" for appropriate values of "pretty well".
(drum roll)
Covariant return types!
All of these suntactic sygar feautres can easily be worked around, but the lack of covariant return types has been a real problem for many people (often without knowing the name of the feature they miss). Especially when trying to do inheritence in EJB's, you really need them.
For those of you who are interested, what are covariant return types?
Consider the following code:
I suppose you can figure out for yourself now how this can be very useful.You should avery rarely need typesafe enums, or enums at all actually. Excessive use of enums is a typical code smell that the programmer didn't understand object orientation well enough.
Usually I have somehting like one enum per 10000 lines of code or so. While I think that the enums in 1.5 will be a great help, I certainly don't think it's a huge amazing feature.
At other times a strongly typed language is what you need. Then I use Java. WHich happens to be most of the time, for me.
When is it a good time FOR YOU to use a loosely typed language? Hell should I know, you're the guy doing the programming.
The problem is that you can't force library writers to follow your rules. Case in point: iostream
(of course I was in such a hurry to post my last message that I missed the fact that I got all the html messed up. Should be fixed now) You will be glad to hear that the typed collections are completely optional. The default is the same old. You can even do this: // declare a typed list
List foo = new List(); // assign it to a normal list
List bar = foo; // Doing it the other way around requires a cast:
List foo = new List();
List bar = (List)foo;
All very logical, isn't it?
Download the preview and try for yourself.
You will be glad to hear that the typed collections are completely optional. The default is the same old. You can even do this: // declare a typed list // assign it to a normal list // Doing it the other way around requires a cast:
List foo = new List();
List bar = foo;
List foo = new List();
List bar = (List)foo;
All very logical, isn't it?
Download the preview and try for yourself.