Programming at the speed of thought II: JRebel

In my last blog post, I lamented the slow turnaround and overall heaviness of enterprise Java development. I also said that I would be checking out JRebel, a tool designed to let you make code changes and push them out to a running application without restarting the application. My verdict? I loved it, convinced my boss to buy it, and am an enthusiastic user. But it is not flawless, so adopters should keep expectations realistic.

Programming at the speed of thought

In his classic "No Silver Bullets" paper in 1986, Fred Brooks claimed that the "accidents" of software development had been substantially addressed. He used the word "accident" in the Aristotelian sense, meaning tasks not inherently essential to programming like waiting for a program to compile. We were getting close to the being limited only by the essential tasks, where the limit is the human mind. I wonder how he might amend his views had he known how enterprise Java would introduce one bad accident after another to the profession. Fortunately, I think things are turning around.

The contrast between accident and essence came into sharp relief to me recently because of two things that happened one day. The first was when a colleague mentioned to me that he had wasted half a day trying to get Maven to build our application. He wasn't changing the build system: all he wanted to do was check out the latest code, build it, and work on it in Eclipse. This took literally hours to get working. The second thing was that I had been working on a personal project based on Grails.

Let's get rid of middle management

Let's get rid of middle management.

No, not you, boss.

I'm talking about middle management in Java code. At one presentation in the New England Software Symposium in Boston last year, some Java-bashing guy (Stuart Halloway) described Java as the language that invented middle management. You have probably seen them: these classes often end with "Manager.java". I'm wondering whether we really need them.

On the lightness of Spring

Shortly after I blogged about the direction of Spring, I came across a blog entry asking "Is Spring still lightweight?" The resulting DZone discussion is spirited, but last I checked it nobody actually defined what it means to be lightweight. That seems unfortunate. If the Spring folks are no longer right in their claim to be lightweight, we should at least have a falsifiable proposition. Way back in 2004, Rod Johnson in his book "J2EE Development without EJB" defined the characteristics of a lightweight container (summary of chapter 6):

• Non-invasiveness: imposing minimal special requirements on application objects run within it
• Quick start up
• Lack of any special deployment steps
• Light footprint, enabling it to run in any architectural tier
• Ability to manage objects of any granularity, including fine-grained objects that cannot be modelled as EJBs.

Now when we look at SpringSource's mission statement today concerning the Spring framework, we see pretty much the same ideas. They no longer talk about a light footprint, though the spring.jar super-bundle in the 2.5.6 release is still under 3 MB. While you can get the footprint much smaller by using the individual Spring modules (spring-core.jar, spring-context.jar etc), I don't think the footprint is an issue.

What Spring really stands for is the non-invasiveness: the framework helped make POJO development trendy. We have Spring to thank for the new status quo in enterprise Java, where we don't have to inherit from mandatory classes, write unnecessary boilerplate or otherwise deal with much accidental complexity. Spring's idea of lightweight containers --along with Hibernate -- gave us dependency injection, AOP, declarative transactions and POJO object persistence. When we think of Spring as being lightweight, we really mean its adherence to the principles I quoted above.

There are some aspects of Spring that I find unnecessarily tedious, verbose and complex. Sometimes, I am tempted to apply the word "heavyweight" to Spring. And it is true that SpringSource has become a big company with a confusing proliferation of commercial products. But I would not deny the title of "lightweight" to the core Spring framework according to principles defined by Spring, nor would I begrudge a measure of gratitude to a programming paradigm that transformed an industry.

NESS 2009: The Coming Spring

One of the sessions I attended at the recent New England Software Symposium is the one on new features in Spring 3. This covers Spring Core functionality. This session got my attention because the presenter was Craig Walls, who wrote Spring in Action. The main features he covered were:

• Spring Expression Language (SpEL)
• Spring MVC annotations (@PathVariable, @RequestHeader, @CookieValue, @RequestParam defaults), some to support REST.
• jsp tag to generate context-sensitive URL
• Declarative validation of some sort that may or may not make it
• Etag support
• HiddenHttpMethodFilter (more Spring MVC REST support)
• ContentNegotiatingViewResolver
• RestTemplate
• JavaConfig (Java-based alternative to XML wiring). This has been around for a while, but is being bundled in Spring 3. 
• Object-to-XML mapping from Spring-WS
• Java 5 support

Logging: should I wrap?

Once upon a time, there was a de facto logging standard, log4j. Then Sun decided to confuse matters by introducing another -- and many say inferior -- logging API in JDK 1.4. Some people responded with Jakarta Commons Logging (JCL), a wrapper that abstracts away these two APIs. Some other people decided that JCL was awful, and wrote SLF4J, a wrapper that abstracts away the first two APIs and JCL. There are also other logging implementations like Logback and x4juli, but fortunately these natively implement the existing APIs so they don't multiply the confusion.

If you start work on an existing project, I suppose you'd use whatever logging API is already in use. If on the other hand you are lucky enough to start a brand new project, you have to choose from a number of logging APIs:

• log4j
• JDK Logging
• JCL
• SLF4J

The conventional wisdom is that if you are writing a component or library, you'd likely choose one of the wrapper APIs (JCL or SLF4J) since you won't have control over what logging implementation the actual app will use. On the other hand, the conventional wisdom continues, if you are working on a standalone application you might as well code directly to the native APIs since you can pick the logging engine and are unlikely to switch. Even SLF4J's docs say that you needn't bother with SLF4J for standalone applications.

I have joined projects that build J2EE applications almost from scratch, so we got to pick the logging API. My initial inclination was the direct approach: we'd code directly to log4j. After all, why add an unnecessary abstraction? In one project, we ended up using SLF4J, even though we had no intention of switching logging engines. Why? Well, it turns out that SLF4J has a useful feature that log4j does not: parameterized logging. Ordinary logging messages incur the overhead of building the log message even if the message will not be logged at the current log level:

logger.debug("Value of obj#" + i + " = " + obj.toString());

All that work will be wasted if you are logging at the INFO level. The performance penalty could be significant if obj.toString() is particularly heavy. You could wrap that line in an "if (logger.isDebugEnabled()) {...}" block, but that adds clutter. SLF4J lets you defer evaluation of any String conversions until the line is actually written:

logger.debug("Value of obj#{} = {}", i, obj);

Does this minor convenience justify throwing in yet another 3rd party library? We did not need to answer that question. In a substantial app, there is no extra overhead. Quite likely, as in our case, the third party libraries you use will require JCL (e.g., Spring) and SLF4J (e.g., Hibernate) anyway. It's up to you to choose the API for your own logging. For us, SLF4J came along for the ride, gave us the parameterized expressions and still exposed powerful features like Mapped Diagnostic Context (MDC). Where is the downside?

In another project, we coded straight to the log4j API. This project was coded almost entirely in Groovy. In Groovy, we get lazy evaluation for free, so SLF4J offered no API benefits. The Groovy logging code below lazily evaluates its parameters regardless of logging implementation, and more concisely than SLF4J:

logger.debug "Value of obj#${i} = ${obj}"