Why Can’t Java Do That?

So this year I’m trying to make in-roads in learning some new languages, in particular Ruby and Haskell. My problem is now that since I pay my bills by writing Java code every day I’m left thinking “That’s one line in Ruby” or “Why can’t Java do this like Haskell?”

Without these changes I will spend each day being a little bit more gumpy than is necessary. This is bad because I vocalise my grumpiness. (I like to think of it as contributing to the team.) So if I’m grumpy, I’ll make those around me grumpy. And in turn, they’ll make the ones around them grumpy. So without these changes and with a few more hops like that Kevin Bacon will be grumpy.* So I think that it’s safe to say that even Kevin Bacon want’s these changes. Sun is actually making Keving Bacon grumpy. And that’s not fair.

So here’s a very quick, off-the-top-of-my-head, list of things that I’d like to see in Java. I don’t care if they’re adopted as fundamental language changes or whether they’re just syntactic sugar that the compiler removes and replaces. As long as the changes are made, I’ll be a happy bunny.

Validate Method Parameters

Like a good boy I always check my method parameters before I can use them. Most of my checks are boring and repetative, they clutter up my super-important-and-complicated business method. Why can’t they be moved out to annotations?

Code Like This…

public String complexMethod(Object someObj, String someStr, int number) {
  if(null == someObj) {
    throw new IllegalArgumentException("someObj cannot be null");
  }
  if(null == someStr || 0 == someStr.trim().length()) {
    throw new IllegalArgumentException("someStr cannot be null or empty");
  }
  if(MIN > number || MAX < number) {
    throw new IllegalArgumentException("number out of range");
  }

  // Complex code goes here
}

Is Replaced With…

@Check(NOT_NULL, IllegalArgumentException, someObj, "someObj cannot be null")
@Check(NOT_EMPTY, IllegalArgumentException, someStr, "someStr cannot be null or whitespace only")
@Check(IN_RANGE, com.mycompany.BadNumberRangeException, number, MIN, MAX)
public String complexMethod(Object someObj, String someStr, int number) {
  // Complex code goes here
}

Wrap Methods in Try-Catch

Many times a day I see code where the entire method is wrapped in a try-catch statement. Often times the stuff in the catch statement is repeated though the class (or classes). Another annotation could remove this noise and make the business code look much more plain.

Code Like This…

public void doDatabaseThing() throws SQLException {
  try {
    // some database thing
  } catch (SQLException sqle) {
    methodToRun();
  }
}

Is Replaced With…

@IfThrown(java.sql.SQLException, methodToRun)
public void doDatabaseThing() throws SQLException {
  // some database thing
}

Maybe a better approach is to abolish all checked exceptions, but that’s another post.

What was the index, please?

Java’s for-each loop is just syntactic sugar for a normal for loop, complete with counter. Why couldn’t they introduce a Perl-esque special variable that had the current iterations index in it? For example;

for(String name : names) {
  System.out.println(name + " is at index " + $_);
}

Controvertial: Easily implement the decorator pattern

Sometimes you need to wrap objects in other objects. Fine. Sometimes you can’t use a simple “extends” and just override the methods you’re interested. Annoying. But what happens when the object you want to wrap has an enormous public interface? You can argue that this is implying you have a bad object model, and I probably won’t disagree, but sometimes you just have to play the cards dealt you and that means wrapping something with a big public interface.

Code Like This…

public class Wrapper {
  private Wrapped wrapped = new Wrapped();
  public void method1() {
    wrapped.method1();
  }
  public void method2() {
    wrapped.method2();
  }
  public void method3() {
    //do something different first...
    wrapped.method3();
  }
}

Is Replaced With…

@Decorates(wrapped)
public class WrapperClass {
  private Wrapped wrapped = new Wrapped();
  public void method3() {
    //do something different first...
    wrapped.method3();
  }
}

…and have the compiler fill in all the boring pass-through methods for me.

Pattern Matching

I really like the pattern matching of methods you get in Haskell and I’m left wondering if Java might benefit from them to.

Code Like This…

public void doSomething(boolean flag, Object otherArg) {
  if (flag) {
    // some code here
  } else {
    // other code here
  }
}

Is Replaced With…

public void doSomething(Boolean.TRUE, Object otherArg) {
    // some code here
}
public void doSomething(Boolean.FALSE, Object otherArg) {
    // other code here
}

But I really don’t know if this makes things more simple.

In Closing…

I haven’t actually done much (read: any) research into how to write my own annotations in Java. I really don’t know how to write an annotation that will make the compiler behave differently and inject code into the source. I’d be interested to hear if anyone knows where I can do some reading on this.

* Okay, so it’s not a perfect application of 6-degrees, so what?