There’s been a lot of new innovations going on in programming languages and development techniques in general lately, but there’s a really key missing element: metrics.

Seeing posts like Stephan Schmidt’s Go Ahead: Next Generation Java Programming Style and the response from Cedric Otaku really should make any professional software engineer concerned about the future of their craft. Not because either of them are necessarily right or wrong, but because two highly skilled engineers are engaged in debate based purely on pure personal preference. There’s barely even any anecdotal evidence provided, let alone actual measurements to see what impact on productivity, quality or other desirable qualities the proposed approaches have.

There’s a huge amount of new technology pouring out into the world these days – lots of it focussed around the web and consumers and the key term that keeps being talked about it ubiquity. Flash brought video to the web because it was ubiquitous, HTML5 will kill flash once it’s ubiquitous, mobile web access is becoming ubiquitous etc. The most striking thing in all of this is just how quickly these new technologies are actually finding their way into real world usage.

Emmanuel Lécharny – Pick good names for your methods/data structures…

5 years later, when I come back into this crap, I have *no* bloody idea about what is what. Is Twix for the frontend or the backend ?

When you pick a name, and when you think it’s funny, just think about those, and probably you, who will not have fun at all when it’ll be time to fix some code in this area, with no clue about what Twix and Snickers are…

At first glance, Ivy looks like a re-implementation of Maven’s dependency management that works nicely with ant, and to some degree it is, but it also adds some pretty significant improvements and some pretty significant complexity.

Maven Compatibility

Firstly, Ivy is compatible with Maven repositories, so if you think the way Maven manages dependencies is perfect, but don’t want to buy into the rest of Maven, Ivy provides a good answer. The configuration is a little bit different and you’ll have to learn a little bit about Ivy’s configurations which are both more powerful and more complex than Maven’s dependency “scope”, but you won’t have to go too far into them.

Here’s an important lesson for people combining ant scripts – the way basedir is calculated is very unlikely to be what you expect. In particular, if you combine the task with the task you’re probably in for a surprise.

I learnt this important life lesson when the improved build scripts I’d been working on failed on the build server even though it worked perfectly on my machine. The difference is that the build server is running cruise control and it has a wrapper ant script which checks out a fresh copy of the project then uses the task to build it. The ant task was:

Bryan comments on the three types of ant scripts:

In my experience, there are three types of Ant scripts that you encounter “in the wild”:

• Small Ant scripts, generally Java-only, which can use most of Ant’s default behaviors and are clear and simple. A lot of open source build scripts are this way.
• Serious commercial Ant scripts written before macrodef and import became available. These are generally impossible to understand and evolve, and the reality is that a small cadre of Build Wizards keep them running. Such systems often involve a substantial number of custom Ant tasks.
• Serious commercial Ant scripts written to use macrodef and import. In my experience, the need for custom Ant tasks drops way off with Ant releases post-1.6.

This really does ring true to me. Ant scripts can fairly quickly become unwieldy and difficult to work with if you aren’t using import and macrodef, but with them you can achieve so much more without the complexity getting out of hand. They won’t absolve you of the need to properly understand ant and the declarative paradigm it wants you to work with, but it’s much more approachable.

Thanks to a tweet from @bdelacretaz I discovered Apache Pivot today. It does indeed have a nice website, and the library itself looks great. It’s pitched as an RIA framework and mostly seems focussed on browser based deployment via applets. However, pivot apps can also be deployed as standalone applications which is where I think it’s most promising.

The killer feature as far as I can see, is the much richer set of components that are available, combined with a better set of customisation points such as effects, transitions, web queries and data binding. There are libraries to do most or all of this with Swing, but since it wasn’t designed for it up front, they tend to feel pretty clunky and “bolted-on”. Hopefully Pivot can avoid that.

Dylan complained about the lack of testability with file system APIs, which reminded me of a neat looking library I stumbled across while looking at build systems: EntityFS. Among a bunch of other useful sounding things it provides:

File system APIs are backend-independent. File systems can be created in RAM memory, on Zip files, on file system directories, etcetera Sadly it’s under the LGPL which makes it difficult if you happen to sell to big enterprises that are still somewhat scared of GPL type licenses, but they’re nowhere near as common as they used to be. I should note though that Holocene Software are offering commercial licenses for an undisclosed price.

After spending some time thinking about and using different build systems, I can’t say I really like any of them all that much. I know have a reasonably complex project, using submodules that can be built with ant, buildr, maven and gradle – with varying degrees of support for the Ephox specific requirements and reporting.

Maven

Ah, the Java world’s favorite whipping boy. The more I play with Maven, the more I start to understand why it gets such a bad wrap: it’s too easy to get started and do it all wrong. Maven is not a build tool that is quick to start using – it requires planning, common conventions, a number of extras systems such as repository servers be set up and templates to be designed. However, Maven does an unfortunately good job of working if you just create a simple pom.xml and run mvn.

Chris J Davis in Lessons for the Newly Minted:

As you can clearly see, when you have tight deadlines, and mountains of work, refactoring existing code that works is highly unadvisable. As a developer you must make strategic decisions about where your time is spent, and this must be informed and balanced by the needs of the company. Should you strive to craft breathtakingly beautiful code? Yes, but not at the expense of the overall velocity of your development schedule. Sometimes good enough is beautiful. Amen to that.

Having spent a bunch of time looking at various build systems and tools, one of the simplest and most effective improvements I’ve discovered is to always use the Maven project structure. It doesn’t matter if you’re not using Maven, there’s no downside to using it and every build tool that uses convention over configuration uses the Maven structure.

Previously I’ve been of the opinion that the directory structure really didn’t matter much – I went with whatever happened to be auto-generated by whatever tool I was using that day. There is a small overhead in remembering to look for the JavaSource directory instead of src or source when you switch projects but it’s incredibly minimal and not worth worrying about on its own. When it comes to build scripts, getting these basics in the same place saves a whole lot of configuration and makes everything simpler.

I’ve been doing a bit more Googling and seem to have hit onto a few key articles that tie into a web of articles around build systems. There’s certainly a lot more options that I’d originally thought.

Build Tools

• Gant – Not really a build tool itself but an interesting library for scripting ant tasks in Groovy.
• Gradle – Came out of the work on Gant and provides a full build tool with Groovy scripting and leveraging Ant tasks quite heavily under the hood. Uses Ivy for dependency management and promises good things for multi-project builds. Most interestingly though it has transitive dependency support without the need for remote repositories or pom/ivy files.
• Schmant – Aims to be comparable to Ant in features but nicer and easier to work with. Uses Java 6 scripting to let you use a wide range of languages to script the build, but the sample build files look a little complex still. Most interesting is the TaskExecutor support for running different build tasks in parallel threads – not sure if it’s easier to use than ant’s parallel task though.
• Apache Buildr – rake for Java I guess. Could also be described as maven done right – the build files are kind of POM like, but are actually full ruby classes. I played with this one a bit and it’s very impressive, though its transitive dependency support is still a bit immature.

Maven Info

Also stumbled across some good Maven articles: