madbean

In a previous entry, I issued a little doom-and-gloom regarding the increased complexity of JDK1.5.

In short, I’m saying “get ready”. Java is getting harder. You use Java. Java is getting harder *for you*.

Alan has done some hacking on the JDK1.5 early-access, and says:

Enhanced for loop is useful.

…

The generics enhancements are way cool.

…

[With "variance"] more things ‘just work’.

…

Frankly, programmers will need to be discouraged from writing generic classes. … The newly genericised java.util collections classes should be all the generics most of us need, most of the time.

…

‘The Masses’ will find their day-to-day coding simplified

Actually, I like the message that I think Alan is getting across. Okay, so maybe there is a little more rope with which to hang yourself, but maybe this allows more room for simplicity when each feature is used appropriately by the right people. Maybe I should change my statement to:

JDK1.5 is giving tools to the API/library writers¹ to make it easier for them to make life easier for us².

On coding standards

No matter how you feel about the new Java features, you should think about updating your coding standards. Sure, we are going to need rules about where whitespace goes around generic’s < and > etc., but that’s not going to be the important bit.

We need to think about some rules that ensure Java stays simple to use (for people on both sides of the Smart/Masses boundry). For example, some C++ project have a rule something like “Only overload operators for ‘numeric’ types”. This is an attempt by those projects to make life easier for the Masses; curtailing the wanton excesses of any Joe Hackers.

So what coding guidelines might be called for with the new JDK 1.5 stuff? Some quick ideas³:

• static import with .*. Only use it for java.lang.Math. Otherwise, import each method as needed. Never import enum constants (*shrug*).
• Always use the ‘for each’ loop when simply iterating over a collection or array, never use the old ‘for’ syntax.
• Avoid creating new generic classes. New generic classes are acceptable if they are some sort of ‘container’ class (like a Pair or a Triplet, etc.).
• Some guidelines about ‘variance’ here, something like: Always ensure Pair<Integer> can be assigned to a Pair<Number>.
• Avoid adding methods to enum classes. Except for “formatter” methods (just made that exception up, don’t know enough about enums yet).

¹ Who should be the proverbial ‘Smart People’.

² Us unwashed ‘Masses’.

³ These are just to get you brain ticking, we’ll all need some real-world experience with JDK1.5 before good coding standards are formed.