Pure Danger Tech


navigation
home

Through the Java looking glass

14 Dec 2007

I went to the St. Louis Java User Group talk tonight on Scala and it got me thinking a bit about AOP again. AOP was definitely all the rage a few years ago as a way to get more power out of Java and reduce boilerplate code due to “cross-cutting concerns”.

What happened to all that AOP stuff anyways? The hype died off but the ideas got pushed down into the foundation of a lot of technologies people use every day like Spring, JBoss, Hibernate, etc. If you really look around, you’ll see byte code modification and weaving happening in all sorts of places. But I don’t see people using compile-time weaving stuff like AspectJ anymore – maybe I just travel in the wrong circles but that sort of overt project-level AOP seems to have gone way down.

But I see a lot of interesting similarities between the things AOP touted and the things being marketed about dynamic and functional languages (like Ruby, Groovy, Scala, etc). These languages provide more flexibility about how you structure your code. They let you do things like interception and proxying more easily (via blocks), weave the same function into many use locations (via closures), dynamically modify classes, objects, etc (via mixins, traits, whatever), and more.

Java 7 seems to be pulling at the coat-tails of this feature set, with the slow but steady progress on closures, extension methods, and type inference. But when you look a little closer at the proposals for these, they’ve kind of gone through the looking glass to fit into Java’s static typing and backwards compatibility requirements. And what’s on the other side is a little weird.

The thing is that when I look at Ruby, or maybe Groovy or Scala is even better since they’re closer to Java, these languages have sets of features that support each other. Closures are great but without dynamic typing, man they are ugly in Java. Scala addresses this through some aggressive type inference but even there you still see those same ugly static types on the closures.

I guess if I had to summarize this rambling thought, it would be that we as developers have a need for more flexibility, more power, and better abstractions, and Java is not satisfying this need. And because of that, some developers are jumping ship for more flexible languages. Personally, I really like Java and I still enjoy writing code in it even though I occasionally find it frustrating or annoying. Maybe I’m too spoiled by the libraries, the tools, and the wonderful portability of the JVM.

What I really wonder is whether Java 7, in reaching towards this greater flexibility, is going to succeed in creating an environment that still makes sense or whether it will be just the ugly step-child of these ideas which are better executed in their own environments. I can’t answer this question yet.