Through the Java looking glass
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.
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
Many Java developers tend to write off AOP at the mere mention of aspects. It’s a shame because they really are simple to learn and very powerful. I suspect the biggest reason for this is that they appear to be too invisible to developers. Java developers have in the past dismissed aspects because they are not objects as such in the OO paradigm. But now they want closures and dynamic type inference in a non functional and statically typed language. The upcoming Java 7 looks set to be very powerful. I hope that with all it’s power that it too, like aspects, is not too overwhelming or too magical for most developers. It does take a lot of effort to wrap your head around all the new Java 7 features.
Josh Bloch’s closures talk at JavaPolis is a great companion to my ruminations above. And it might just scare you off of Java closures!
Hi Alex, very nice post (once again). I’ve been wondering about same things myself, here are some semi-humorous musings on the topic.
Java carries too much baggage IMO. There are both technology and people factors. Technology-wise, backwards compatibility is adding sour taste to any new major language feature. And as far as people are concerned, sometimes I feel that many Java programmers are in the business only because Java made it so easy to program. This folks know no other language and are reluctant to learn new stuff, perhaps realistically seeing their own programming capabilities, and not less importantly – those of their peers. Which is fair enough, I can identify myself with this crowd – it’s software proletariat and “working class hero is something to be”. They are the majority and they deserve to keep the safe and simple tool they hold on to so preciously.
So future will tell what comes out of all this, but maybe JVM is better at providing common grounds than Java itself.
I’m on a Hell-bent crusade to point out that it’s not static typing which makes closures ugly and awkward: it’s explicit static typing. Type inference allows static typing and closures to get along just fine, thankyouverymuch — see Ocaml for a good example of this in play.
Yardena, I couldn’t agree with you more. Rather than trying to squeeze a square peg through a round hole I think its high time for a new version of Java. Java’s foundations are 15 years old, lessons have been learned both in and around Java.
I wholeheartedly have to say that Java is no longer “easy to program in”, not compared to languages which have a less conservative attitude towards codified constructs. I’ve seen this many times, the classic example I pull out is telling a junior developer to hook events to a button in both C# and Java and witness the difference.
Other language have have embraced contractual development which Java really made mainstream, but also moved the art forward since then with productivity in mind. If the pseudo-generics/auto-boxing addition in Tiger is a representative example of the complexity added if we get closures, then perhaps we aren’t really doing Java a favor in the long run unless we also start to lax backwards compatibility – cutting off the legacy tail.
Interesting post. Got me thinking, and I think I agree with your “fear” for the future
I think that Tim Bray’s comment about 80/20 (which you linked to elsewhere) really hits the nail on the head. Do you go and (painfully) retrofit a language with features for which it was never really designed in order to go after that last 20 percent? I was pretty excited initially about closures in Java, but started to feel just about the opposite after reading all the proposals.
I think that dynamically typed (or at least statically inferred ) languages have a much easier time representing closures in a natural way. Perhaps JavaFX Script would be a better vehicle for this feature?
The mocking framework JMockit is a good example of Java Instrumentation working to great effect.
http://code.google.com/p/jmockit/