No, no code will need recompiling. The generics code has a fallback where all classes are defined as using T, which is exactly how the collections classes work at the moment - as collections of Ob jects.
Cas :_
No, no code will need recompiling. The generics code has a fallback where all classes are defined as using T, which is exactly how the collections classes work at the moment - as collections of Ob jects.
Cas :_
[quote]My personal favorite that I can’t wait for (though it isn’t as important construct-wise) is the foreach statement.
That thing just rocks.
But I guess the most important significant change is either autoboxing or generics; I have not yet decided which is most important to me. Probably both.
[/quote]
Actually, foreach combined with autoboxing and generics, really rocks.
public class MyClass {
public void myMethod(String[] args) {
Map m = new TreeMap();
for (int i = 0; i < args.length; i++) {
Integer freq = (Integer) m.get(args[i]);
Integer incrInteger;
if(freq==null) {
incrInteger = new Integer(1);
} else {
int oldInt = freq.intValue();
int newInt = oldInt + 1;
incrInteger = new Integer(newInt);
}
m.put(args[i], incrInteger );
}
}
}
becomes:
public class MyClass {
public void myMethod(String[] args) {
Map<String, Integer> m = new TreeMap<String, Integer>();
for (String word : args)
m.put(word, m.get(word) + 1);
}
}
*This example was adapted from an interview with Josh Bloch on the new features in 1.5
Actually, I’m looking forward to the java.util.concurrency.* classes (ThreadPool, PriorityQueue, etc). As someone who’s been doing multithreaded programming for a long time, and learning the hard way how to get it right, it’s understandable why people frequently avoid multi-threading at all costs. I think these classes will be as significant as the Collections classes were to how Java is used.
So now Java’s really, really becoming “C++ done right” ;D
Things like that little code snippet you just put there should look really attractive to a C++ programmer who hasn’t done any Java yet.
If I was learning Java, and came across…
public class MyClass {
public void myMethod(String[] args) {
Map<String, Integer> m = new TreeMap<String, Integer>();
for (String word : args)
m.put(word, m.get(word) + 1);
}
}
… I would be totally lost.
Coding shortcuts are good… when the meaning of the code isn’t lost.
I agree, it is going to be nice to have the ability to use these tools when its appropriate, but the readability isn’t that great.
Isn’t it also going to lead to ppl who are moving from other languages to java using primitives for keys everywhere, instead of considering if it might be more elegant to use an object?
Kev
PS. Thanks for pointing out the default impl, mind at rest again
The syntax is foreign at first but I think it improves readability quite nicely. The intention is made more clear while the implementation (which is rarely necessary to know about) is nicely hidden.
When the implementation is necessary, it becomes visible, but it also becomes a part of the intention when that happens too. Sounds good to me.
Yeah, it’ll be a little weird at first because it doesn’t look like Java1.4 - but once we start playing with it I’m sure it’ll be fine! That example rather compresses several themes into one place, anyway - most code won’t be anything like as alien as that!