If I Could Remove Two Keywords from Java...

Java is pretty boring as far as programming languages go. There are plenty of things I'd like to be able to do in it that I can't do, but there are a couple of things that you can do that I think are fairly stupid.

void

The first item on my hitlist is void. void communicates that a method exists for its side-effects. That's perfectly fine, but it also means that there is no return value from the method. In practice, this means you can't build and shape an object before assignment. This isn't really that big of a deal, but some APIs do smalltalk-style mutators that allow you to build stuff out as you go.

Examples of such APIs are StringBuilder, Mock, and the Wicket stuff I've been working with lately. Here's an example of using StringBuilder as it exists today:

String s=new StringBuilder()
  .add("Some string")
  .add(new SomeObject())
  .add(9325)
  .add(true)
  .toString();

Although that's an extremely common example, it's more typically generated by a compiler than typed by a user. Contrast that to doing the same type of operation with a collection (which I also want to make into a String for some reason).

Collection c=new ArrayList();
a.add("Some string");
a.add(new SomeObject());
a.add(9325);
a.add(true);
String s=a.toString();

It's subtle, but it makes a difference when you're constructing stuff to add to other stuff. void specifically disallows this, but without providing any terribly good reason.

return

I've had this argument with several people, but I just don't like the return keyword. Scheme, ML, Haskell, Eiffel, and countless other languages get along well without it. It's sort of optional in perl, but that's true for almost everything.

Call me old-fashioned or whatever, but if there's only one way to get into my function, there should be only one (normal) way to get out. Exceptions are often cited as a problem with the concept of Single-Entry, Single-Exit methods, but they're exceptions. They indicate something went horribly wrong.

More often, I see people stick returns in methods seemingly just to make me nervous or confused.

For example, I'm looking at a method that is used to get some information from a context and that has three return statements in it. The first one is a sanity check on the context. If the state is invalid, return null. Next, we do something to get a collection of things, if this doesn't return null (a bug if it does), we grab the zeroth element from it (which, of course, may not be there). If that element is not null (a bug if it is), we return it. By the end of the method, if we haven't returned yet, we return null.

Now, let's say I invoke this method, and it returns null. WTF does that mean? Is the state bad? Did we hit a bug in one of the two points where we're getting and/or working on a collection of things? Did we just not find what we're looking for? Of course, when I see stuff like this, I often don't see logging, either. IMO, this is better written with one IllegalStateException, two assertions, and one return. One return means we can also toss a line of log above it to say, Hey, that thing you asked for, yeah, this is what I'm returning.

If not return, then what? Well, the languages listed above have one of two mechanisms:

1. Scheme, ML, Haskell - return the result of the last statement in the function
2. Eiffel - Have a specific Result variable that must be populated

Now that java is open source, maybe I can sneak in these changes without anyone noticing it. I mean, sure, your programs won't compile anymore, but they'll otherwise be easier to use.