In a recent discussion on the Magnolia developers list, Nicolas referred to a post discussing the negative side-effects of using JDK 1.5 to code readability. This pretty well demonstrates one of the reasons Java bugs: the developers want a language that guarantees code readability.
I'm all for code readability, but Java programmers seem to have an irrational fear of giving out tools that could be used for evil. This is a pretty irrational fear since Java already has features like the reflection API, which is like a programmer's version of the nuclear option, one mistep and you've blown up half the planet and it makes some of the worst code I've ever seen.
Anyway, David Flanagan points out that the new import static can make your code less readable. He contrives a couple examples of poor uses of the new construct and warns folks. Now, I want to say that Flanagan has it correct, "This isn't meant as criticism of static import; just an exploration of it." My criticism is of Nicolas and others that make statements like, "I would tend to think it's better to stay with 1.4, especially as the code is easier to read. (in my own opinion). [sic]" JDK 1.5 is not any less readable than JDK 1.4. That's like saying British English is less readable than American English, it's not a valid comparison. It's the usage that matters.
If someone engages in irresponsible coding via the static import mechanism, is this any worse than some of the issues one can have with regular imports? For example, look at:
import com.boomer.mgnl.firmadmin.User;// Later...
public info.magnolia.mgnl.user.external.bean.User copyToExternalUser(User firmUser) {
info.magnolia.user.external.bean.User user = new info.magnolia.user.external.bean.User();
user.setFirstName(firmUser.getFirstName());
return user;
}
I have some of that crap in my code because User was used to name an interface in one package, a bean implementation in another, and an extension of that bean in another, and then used in a totally different module to connect to external users in another place. This is an example of poor choice in names. If your application is going to have multiple user classes that might be used in the same object now or in the future, name them something different from each other! The code above works in JDK 1.4, so JDK 1.4 code can also be hard to read.
Thus, the point for any programmer in any language, is think when you write your code. You can write horrible code in even the simplest language with the best enforced rules and weakest capabilities. Adding powerful tools that can be abused does not mean that the code will suddenly become unreadable, it just means that you've got a few extra pitfalls that you need to put railings around (i.e., corporate/project policies to make sure no one does the stupid). And then, you have to have code reviews and enforce these policies on yourselves or via a community.
I hope that wasn't too much of a rant and I hope my ramble didn't negate what I said too much. Cheers.
