Sunday, 27 November 2005

So, when you're coding in Java sometimes you just have to use primitives. (We'd all love to use objects all the time, but that just isn't possible in Java). However creating primitives can be a pain on occasion, so what could we do?

Defining a variable/constant is easy and just works for short/byte (and all types):

There are more issues with this one however, as Iterator also exposes the hasNext and next methods which the for loop is using. This shouldn't cause a problem, but might require some more work in detailed design.

This blog is number 4 in a series on possible language enhancements to remove boilerplate code - see code blocks, nulls and casts.
Opinions welcome as always :-)

Note, I've deliberately kept the use case 'stupid'. There are many good OO solutions to this kind of problem, but I believe that the vast majority of Java developers still end up writing nasty casts all the time.

The compiler can easily figure out that obj must be an instance of Person in the if statement. So why do we need the cast? The code without the cast is more readable and just as safe.

I still believe that casts have a useful role to play in Java, when you want to emphasise a point in conversion, or to cast without an instanceof. But when we've already checked with the instanceof, why are we have to repeat ourselves? Thats just boilerplate code.

A bit surprising at first glance, yet much much simpler to read and understand. I'm using # to indicate "ignore null for now and continue processing". I used # as javadoc already uses it instead of a dot. Implementation-wise, the compiler would expand it to the former use-case, so no big issues there.

By the way, this series of entries is inspired by Graham Hamilton's blog about boilerplate Java code. I'm just trying to show what gets in my way, and provide a Java-style (not Ruby/c#/python/... style) solution. As always, opinions welcome :-)

Monday, 21 November 2005

There has been a lot of talk on Javalobby recently about adding closures to Java. But how can this be done without destroying the style of Java?

Groovy shows one way to add closures. But groovy has the ability to create syntax, change classes and do other strange stuff that is just too way out for Java itself. So I though I'd do an experiment to see if I could figure out a way to add closures to Java following a more java style.

I started with a use case I wanted to solve, the dreaded resource close:

I saw the main benefits as being more readable, shorter, removing the common close code, scoping the variable and reducing errors. Importantly, a current Java programmer would grok the new way of woring very quickly (no complex syntax).

The key was using the do keyword to identify the special code. I believe that this keyword-usage is much more Java-style than arbitrary symbols like ->.

CloseAfter would just be a regular Java class, just limited to have one method:

Once I'd done all this and convinced myself that the compiler could implement it easily (by copying the CloseAfter code directly into the original method) I had a sudden realisation - this wasn't really closures, but surrounded code blocks.

Nevertheless, it could be very, very useful, for example to do commit and rollback...

do.DBTransaction (Connection con) {
...
}

Kind of like AOP-lite :-)

I just have this sense that a syntax like this would be easy to add to Java, and solve 80% of the issues that full-blown closures tackle (with 20% of the complexity). Opinions welcome :-)