JavaWorld Forums: Taming Tiger, Part 1

public interface Switchable {

public class Mode {

private String mode_description;

private Mode(String mode_description) {
this.mode_description = mode_description;
}

public void append_to_string_buffer(StringBuffer buffer) {
buffer.append(this.mode_description);
}

}

public abstract final Switchable.Mode SWITCH_ON = new Switchable.Mode("this switch is on");

public abstract final Switchable.Mode SWITCH_OFF = new Switchable.Mode("this switch is off");

public abstract void switch_mode(Switchable.Mode mode);
public abstract Switchable.Mode get_mode();

}

1) Boxing, unboxing
> I have mixed feelings about this...
I agree. It's not particularly good or bad. It's a minor convenience in typing and reader offsetted by a minor inconvenience of having to know a little "gotcha".

2) Enhanced for loop
> As said, the unenhanced for loop is "cumbersome", ...
I disagree. The enhanced for loop is a good concept. Do we need another loop construct? No, we only need one, but we have three: for, while, do-while. The only problem with the enhanced for loop is its syntax. It should have been constructed like this:

for each String name in myCollectionOfNames

It would be more readable like the C# foreach. I would have like to see a space between the for and the each, making them separate reserve words. As for reserve words being expensive, that's marketing b.s. Java has had the unused reserve word goto since its inception. They probably didnt want it to look like Java was stealing an idea from C#. I say why not? C# stole all of its ideas from Java. Come to think of it, Java stole many ideas from SmallTalk. Thats the nature of the evolution of programming languages. You throw out the bad, and keep the good.

3) Variable method arguments and printf
> [Paraphrasing: both are bad]
I agree that variable number arguments are unnecessary and always a worse solution that what you would come up with as an alternative. You can use an array of objects, a hashmap, a collection, etc. These solutions always end up being more readable than a variable number of arguments. I think the main reason the variable number of arguments was added was to support printf (just like in C).

As for the printf method itself, I don't mind that so much. You rarely want to do console output unless you're throwing together some temporary code. Even logging is better done through an API. Most often I'll continue to use the print and println methods, but it doesn't do any harm to have a formatted printing method for those times that you are writing throw-away code.

4) Enumerations
> Personally, I'm still confused about enumerations...
Enumerations should be considered a special kind of class, like arrays are. You can always write a generic enumeration class that has all the functionality of the Java 1.5 or C# enumeration construction including type safety and converting the ordinal value to a string automatically. However, the price has always been efficiency. Since you can't write VM code directly in source code (although there are ways around that), the performance and memory requirements are always much more than for ints.

The great thing about the enumeration construct is that, at least in principle, the enumerations can be accessed as quickly as ints and the text equivalent of the ordinal value can be accessed as quickly as a static string. Hopefully, the actual implementation is close to this ideal.

Enumerations should have been in JDK 1.0. The original Java team left some C/C++ things out because they wanted to make sure there was only one way to accomplish things: the best way. In general, this is a very good principle. However, there is always a little disagreement as to what constitutes the best way. Enumerations offer range check, type safety, and readability. That's why they should have been in Java from the beginning. The other stuff left out of Java was probably for the best...

The one thing we need is a way to systematically Javadoc enumerations. With final static int fields, you can Javadoc each field to describe its meaning in detail. Is there a way to do this with enumerations without having to add a <p> tag or equivalent in your class documentation? Granted, for enum Color {red, green, blue} thats not important. But it is important for enum OracleSqlExceptionCode {}. It would be nice to be able to do

enum XmlExceptionCode
{
/** Indicates that the given node cannot be added to the tree at the current location. This commonly occurs because the given nodes type does not match the types allowed by the XML schema. */
nodeCannotBeAdded,

/** Indicates that no node with the given value of the id attribute was found in this XML tree */
idNotFound
}

One final thought on enumerations. Which convention should everyone adopt? enum Color {red, green, blue}; enum Color (Red, Green, Blue); or enum Color (RED, GREEN, BLUE); You can make a case for each of them. I prefer using all lowercase letters just like I prefer to say Color.red instead of Color.RED when using java.awt.Color. Using lowercase also prevents having to use underscores when your enumerated values contain two or more human-readable words.

4 and 1/2) Generics
First of all, it's important that all Java programmers realize that Generics are NOTHING BUT TEMPLATES going under a new name. Templates have been around since the (mid?) eighties. In principle, templates are a good idea. They provide the flexibility of runtime type checking with the safety of compile time type checking. If used properly, templates are elegant solution that does not compromise readability or usability.

In practice templates are pure evil. In the entire history of the know universe, there has never been a programmer who has used templates correctly. The Active Template Library (ATL) and the Standard Template Library (STL) are prime examples of this. Boy, did those libraries stink like a scruffy looking nerf herder.

So the Java team took a stand, got on a soap box, and declared that template were bad -- unnecessary and prone to misuse, I believe they said -- and to be preemptively banished from Java. And they were right to do so. It saved us many years of crappy template libraries and poorly written code. I guess a new team of developers or managers made the decision to forego the original principles behind the Java language. Perhaps they forgot or never knew the reasons templates were not included in Java to begin with.

However, Java programmers should be aware of this history. Templates have a long history of misuse and bad programming practices. Thats not to say templates cant be used properly. Its just that they havent ever been used so. Hopefully, Java programmers will take more care to write better template libraries than they did when they were C++ programmers (lets face it, most of us Java programmers use to and still could program in C++). My concern is that most Java programmers will haphazardly use templates like they were in C++ making the same mistakes you see in C++ codes.

This is a big philosophical and design issue. You could write a book on the proper way to write templates actually, there probably are many C++ books for that. The important thing to remember is that changing the name of templates to generics does not change the beast. If programmers avoid the misuses of C++ templates, then Java generics will be a great asset to the language. Otherwise, were in for a lot of bad code.

5) Static imports
> I'm not too hot on this, either...
I agree. Static imports are not necessary and remove the self-documenting nature of code in the form DescriptiveClassName.descriptiveMethodName. The only justification for them is laziness, but typing has never been the bottleneck of programming. They dont contribute to readability, they subtract from it.

6) Compatibility
An issue not discussed so far is a major drawback of using the new Java 1.5 features. New features, by definition, are not backwards compatible. Before you decide to use generics, enumerations, or the enhanced for loop, make sure you are committed to abandoning the prior JDKs. Like always, many people will not migrate to the new JDK for years. It may also take a long time for these features to trickle down to the microedition of Java. (Does anyone know which if any of these features are supported in JME or when they will be?) You dont want to publish a fantastic class library that uses these features and then everybody emails you begging for a JDK 1.4.2 compliant version of the library.

InfoWorld: Modernizing IT

JavaWorld: Solutions for Java Developers