Summary of JDK1.5 Language Changes

An anonymous reader writes "Over at java.sun.com, there's an informative article about the new features in JDK1.5. Some of the changes like generics are nice and should make some things easier. Some of the enhancements to me are purely sugar, like enumerators. When it comes down to it, once the code is compiled, it's the same. The thing I hope is, some of this new syntactic sugar doesn't result in more obfuscated code. Unlike some people, I feel using programming shorthand leads to increased maintenance. This is especially true when you have to debug a complex application."

Comments

Re:Generics

[gray peter]

Agreed that it's a great feature. I use collections all the time and not only is it time consuming to keep casting (especially when you write out long class names like I do...) I'd say a huge % of my runtime errors are from bad casting. I'm definitely looking forward to this. As far as the bytecode specs go, I don't see that this will cause much change at all. The compiler should do the same thing it's always done.

Article didn't mention new concurrency stuff

[dood]

One of the coolest new features of JDK 1.5 is the completely reworked concurrency stuff (JSR 166). I just listened to Doug Lea (spec lead) give a talk on this very subject and I'm pretty convince this will rocket Java performance way up for a lot of the collections stuff, concurrent programming, etc.

Bascially, the goal of JSR 166 is to do for concurrency programming what JDK 1.2 did for data structurs (Collections stuff). The gist is, you'll never need to use "new Thread()" or "synchronized" anymore, but rather you'll execute Runnables, use Locks and Semaphores, etc. Also, queues are *completely* reworked to be ultra scalable.

JSR 166 is based on Doug's concurrency package:
http://gee.cs.oswego.edu/dl/classes/EDU/ oswego/cs/ dl/util/concurrent/intro.html

OH, and there will be classes like AtomicLong which guarantee atomic 'compare and set' options for primitives. :)

Cheers!

Re:enumerators

[ProfKyne]

I don't use ints for my enumerations anymore after reading Josh Bloch's Effective Java. The type-safe enum pattern he recommends is fantastic.

For those not sure exactly how it works, you simply create a class to represent an instance of the enum, and you make the constructor private so that no one can create their own instances. Then you just provide a public static instance of the class for each enum.

I used this pattern simply to achieve its intended effect of providing an enumeration, and then later found that by adding methods to the class, I could even give behaviors to the enumeration instances! Try doing that with an int. This was far more elegant than creating a giant "if" statement and performing conditional logic to test the value of the enumeration, because I simply used a polymorphic method call.

An example:

public class SenseEnumeration {
// the action associated with this enumeration
private java.lang.reflect.Method sense;

private SenseEnumeration(Method m) {
this.sense= m;
}

// assuming we've already created some
// Method instances to use here
public static SenseEnumeration TASTE
= new SenseEnumeration(myTasteMethod);
public static SenseEnumeration HEAR
= new SenseEnumeration(myHearMethod);
public static SenseEnumeration SMELL
= new SenseEnumeration(mySmellMethod);

...etc...

public Method getSenseMethod() { return this.sense; }
public void invokeSenseMethod(Object target) {
sense.invoke(target, null);
}
}

You get the main idea. No, not as fast as an int, but far more powerful.