Java Goofs: Enhanced For Loop

One of the “big deals” in Java 5 was the enhanced for-loop. Basically you could trim this:

for(int i=0;i<collection.size();i++) {
Object object = collection.get(i);
doSomething(object);
}

down to this:
for(Object object:collection) {
doSomething(object);
}

I don’t think such an improvement was really necessary, but combine this with generics and I have to admit your code does look a little cleaner, so I use them when possible. However, the for-loop is basically a half-implemented hack with two major goofs.

1. It works with anything implementing Iterable, and arrays. Despite working with anything Iterable, it does not work actual iterators, which seems just silly to me.
2. If the collection is null, it throws a NullPointerException. The only defense I’ve seen for this is that “a null collection is not the same as an empty collection”. Agreed, and those people clearly missed the point. The point was to clean up the code and now we have to add the same silly if(collection==null) around the loop. If your code really did need to know if the collection was null (e.g. lazy-loading), it’s going to check anyways, but this would save at least one more repetitive line if the loop just treated null as empty and did nothing.

Missing Java Annotations

@SelfExplanatory – I’d love to be able to turn on JavaDoc warnings in Eclipse, but I can’t. Why? Because 90% + of the code is self explanatory. Do I really need to see that getName() “Returns the name”, or that setName(String name) has the utter audacity to “Set the name”? No, I don’t. Put a @SelfExplanatory and JavaDoc can create these braindead comments without cluttering up my code, while Eclipse can reserve its warnings for the more interesting methods.

@NotNull – Other languages may have solved or avoided this problem, but I’d like to be able to dictate that a variable can be set to anything except null, and also that a method will never return null. It would just save so many headaches (of the onerous Runtime variety, no less), as well as lots of “if (foo == null)”…

The ulterior purpose of this post is to test the upgrade to WordPress 2.6.

Generics: All or nothing?

I am a big fan of strong typing, so when Java 5 added support for generics, I started using them heavily. I don’t agree that that they “clean up” your code, because I see as many or more instances of type parameters, <Class>, as I used to see type casts, (Class). However, they do make code easier to read and follow.

I’ve also been using interfaces more and more over the years, and these days I’d say I use them on almost all of my beans. The lightweight multiple inheritance helps with organization, and when you’re dealing with libraries that monkey with the internal working of your code like proxied beans in Spring and Hibernate objects, interfaces are helpful if not required.

A while back, I inadvertently discovered a pitfall that had been plaguing a project of mine in a very confusing manner. Parameterizing a class should avoid class cast exceptions because of strong typing, but you have to be careful to keep it parameterized, or you can end up causing some very nasty runtime bugs. To illustrate, here is a simple example:

(forgive the formatting, WordPress’ editor is poor at handling code…

First we have a Person interface. People have IDs and vehicles.

package com.efsavage.generic;
import java.util.Set;
public interface Person<PK extends Comparable> {
public PK getId();
public void setId(PK id);
public Set<Vehicle> getVehicles();
public void setVehicles(Set<Vehicle> vehicles);
}

We also have a Vehicle interface, the fields of which are unimportant here:

package com.efsavage.generic;
public interface Vehicle { }

And we have an implementation of the Person interface:

package com.efsavage.generic;
import java.util.Set;
public class PersonImpl implements Person {
private Integer id;
private Set vehicles;
public Integer getId() {
return id;
}
public void setId(Integer id) {
this.id = id;
}
public Set getVehicles() {
return vehicles;
}
public void setVehicles(Set vehicles) {
this.vehicles = vehicles;
}
}

So now let’s write a little test:

package com.efsavage.generic;
import java.util.Set;
public class PersonTest {
public static void main(String[] args) {
Person me = new PersonImpl();
Person<Integer> you = new PersonImpl();
me.setId("5");
you.setId(5);
Set<String> myVehicles = me.getVehicles();
Set<Vehicle> yourVehicles = you.getVehicles();
}
}

This code compiles fine (though Eclipse will flag a few warnings). There’s two problems here.

Despite the fact that PersonImpl implements Person<Integer>, I’m able to set a string via me.setId(“5”), because I did not keep that parameter when I cast me to Person, without a parameter. I would have expected the parameter to be inferred here.

The other problem is that I’m able to cast myVehicles to Set<String>! This wasn’t even a parameter I defined, it’s right in Person. However, by using Person without the PK parameter, Java ignores all other parameters too!

I’m sure someone thought this was a good idea, and there’s a reasonable explanation deep in the JCP forums, but it just seems wrong to me, so be careful to check your parameters if you find weird class cast exceptions showing up in your logs.

Wish List: Session Moratorium

DetourA feature that the major open-source/free servlet containers (Tomcat, Jetty, Resin) lack, AFAIK, is the ability to tell the container to stop issuing new sessions, and more importantly, make this flag known to the HTTP server connector. One or more of Websphere, Weblogic, and ATG Dynamo (I forget which) has this ability, and it’s extremely useful for higher-volume websites.

How it works: Server Bank A is running, Server Bank B is dormant. When you have a new release, you push it to B. Once B is up and running (this can take a while with some advanced applications), you tell A to stop issuing new sessions, and the load balancers send all new traffic to B. Once traffic has bled off of A entirely, A becomes dormant, and is ready for the next release.

Why it’s valuable: You can do a release without interrupting any sessions. This was particularly valuable on the project we used it on, because there was plenty of time to pre-compile pages, and the transactions were relatively high-value ones, so it was worth the price of the commercial license to ensure that none were lost or interrupted.

Considering all of the containers are relatively close performance-wise, and feature-wise, I think this would be a “killer feature” for any OSS container that had it.

Naming Conventions: Java Packages

When developing, conventions can mean the difference between producing something clear and concise and producing something confusing and arcane. They exist at all levels, from the industry and the language down to specific modules of applications. I’m going to attempt to codify some conventions for aspects I use heavily, and I’ll start with one of the easier ones, Java package names. Sun has some basic ones, but I think some more specific guidelines are warranted.

  1. Names should be all lowercase. Uppercase and mixed case denote other concepts in Java and there’s no need to muddy the waters further.
  2. Names should be alphanumeric, preferably just alphabetical.
  3. Do not use version numbers or dates (see below for a possible exception).
  4. Use tld.domain-you-own.project/library.* for distributed or published code. This follows with Sun’s convention, and is the only way to know a name is globally unique, or at least that you are the one that’s allowed to use it.
  5. Do not use tld.domain-you-own.* for internal code that should not be distributed. I typically just use the project or library’s name as the first segment. This convention can be useful in signaling other developers that code is for internal use only, and if something is converted from internal to external usage, this will help identify which version an application was built against.
  6. Package names that are nouns should be singular (mycompany.myproject.account). This maintains consistency with packages that are named for actions (mycompany.myproject.search) and adjectives (mycompany.myproject.common).
  7. Store DAOs in a “data” subpackage. This helps the tree-views in IDEs and also allows for easier control of logging. If you’re being formal and encapsulate DAO operations in a manager class, the manager class should not be in the data package because it’s grammar is business-based, not persistence-based.
  8. Classes that are heavily dependent on third-party packages should be in a subpackage named for the primary dependency. A Hibernate implementation of your DAO should live in mycompany.myproject.data.hibernate. This helps greatly with logging configuration. This is one place where version numbers are permissible, such as mycompany.myproject.data.hibernate3. Use this exception very sparingly, as it can be confusing with regards to forward compatibility.
  9. Classes that are extensions of third-party code should be named for the dependency and be outside of the project’s or product’s context. For example, if you are creating a new type of controller for Spring MVC that does not depend on project-specific code, put it in mycompany.spring.controller. If it is integrated with the application, see the previous point.
  10. Don’t expose organizational details in the package structure (mycompany.mydepartment.myproject). Naming packages by department, office, or region will surely be confusing soon due to management’s penchant to reorganize and reassign.

I consider the above a work in-progress, and welcome comments.

The Toolbox: Introduction & Log4J

In my own semantics, software development is a blend between a conventional profession and a craft. As a craftsman, I have a preferred set of tools with which I build and create. Of course, as a contract developer, I don’t always get to use what I want, but these days I more often find myself in a position to do so. I figure it might be useful to others, especially those just getting into the game, to see what an experienced developer actually uses, and why. So let’s start with an easy one, Log4J.



Log4J.There are essentially 3 major choices when it comes to logging in Java. Log4J, Commons Logging, and Java Logging. My current preference is Log4J. Why?

Commons Logging is an abstraction layer, and defaults to using Log4J for its actual logging. The main idea behind CL is that you aren’t tied to a specific logger. I think CL is flawed in two ways:

1. Log4J is itself extensible. Writing a custom appender (the piece that actually writes the log message) is a fairly trivial task, and if your project makes such a fundamental shift as to change its logging API, writing a bridge appender is a negligible amount of effort. So if you’re going to be using Log4J anyways, as most projects do, why add unnecessary complexity?
2. Commons Logging is always more difficult to configure. I honestly can’t figure out why, but almost every project I’ve worked on that uses CL has had issues, especially when you have a mix of libraries which do or do not use it.

Java Logging, added several years ago in Java 1.4, was supposed to eliminate the need for third party logging APIs. It was, and remains, a good idea, but it does not make a compelling case to switch from the vastly more popular Log4J. Last time I checked, the standard logging API was missing a rolling file appender, which is essential for any production environment. It is also slightly less flexible to configure, but the main reason it has largely been irrelevant is that it doesn’t offer anything that Log4J does not.

What would make me switch?

I’m a very heavy logger. I will often write code with as many log statements as regular lines of code, and of course most of these statements are debug/trace level. The problem this introduces is performance. Let’s look at this example:

Person person = PersonFactory.getPerson(name);
log.debug("Found " + person.getName());
precinct.register(person);

The problem is that even if logging is at a level above debug, getName() will be invoked. In practice these statements rarely do anything expensive, but it can be the proverbial death by a thousand cuts. The Log4J way to avoid this is to do the following:

Person person = PersonFactory.getPerson(name);
if(log.isDebugEnabled()) {
log.debug("Found " + person.getName());
}
precinct.register(person);

Messy huh? What I would like to see is the ability for the java compiler to skip these statements entirely, without the cruft currently required. If this ended up being some special case that required the use of the standard logging API, I would switch. The slick way to do this would be to have the ability to annotate methods for lazy reads of parameters being passed to them, but that, as Alton Brown would say, is another show.