A need for const?

[Preston]

You give people an utterly misusuable tool, and they'll misuse it utterly!  You know they do!

Yes, my recent C++ years in mid sized dev teams proved that. This is why I think Java is such a great and (more) "clean" language. I really like it. Very good work @ Gosling and all other contributors at SUN !

[cfmdobbie]

http://developer.java.sun.com/developer/community/chat/JavaLive/2003/jl0729.html

My word, that is some good reading!  I didn't realise the full extent of the changes being included in Java 1.5.

Generics, Static Import and Enumerations get all the attention, but there's also Autoboxing, Foreach, Metadata, Concurrency Utilities API, StringBuilder (unsynchronised StringBuffer), Varargs, C-style printf-type library, and use of generics in things like Comparable<T>.  Wow!

[GergisKhan]

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.

Games published by our own members! Check 'em out!

[Athomas Goldberg]

I know. Every time they release another version spec, I start thinking about all the places I could use the new features in whatever project I'm working on. It gets really depressing.

[tortoise]

I think generics are going to rock. A compile time error as opposed to a ClassCastException? Especially if eclipse will be able to pick up the error on the fly? Oh hell yeah

[swpalmer]

When 1.5 is available it's going to take me a while to get used to not doing things the old way

[GergisKhan]

When 1.5 is available it's going to take me a while to get used to not doing things the old way  

This reminds me of your other comment about not using switch and using polymorphism instead.

I tell you, I think generics are going to rock, but I think they're going to be a PITA to remember to USE them.  

[kevglass]

Any news on what's going to happen to container classes when generics turn up? We going to get a bunch on new version in util.generic which support generics?

Kev

[Preston]

Any news on what's going to happen to container classes when generics turn up? We going to get a bunch on new version in util.generic which support generics?

Kev

The affected classes (=many :-) will be these:
http://jcp.org/aboutJava/communityprocess/review/jsr014/

[kevglass]

Had a quick read, does this mean all old code that uses collections will be broken if compiled against 1.5?

Kev

Games published by our own members! Check 'em out!

[princec]

No, no code will need recompiling. The generics code has a fallback where all classes are defined as using T<Object>, which is exactly how the collections classes work at the moment - as collections of Ob jects.

Cas :_

[Athomas Goldberg]

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.

Actually, foreach combined with autoboxing and generics, really rocks.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19

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:

1   2   3   4   5   6   7

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.

[tortoise]

So now Java's really, really becoming "C++ done right"  

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.

[Abuse]

If I was learning Java, and came across.....

1   2   3   4   5   6   7

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.

[kevglass]

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 <Object> impl, mind at rest again  

[tortoise]

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.

[cfmdobbie]

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!