Thursday, 14 May 2009

Spring configuration - java vs XML

I came to Spring from a newbie perspective, and one of the first mystifying things thrown at you are "Add the foobar bean to the spring xml and define the necessary name and autowiring type" at which point I was already in the "I've lost you.." mode.

Spring Javaconfig reached the 1.0 release at just the right time for me to start using it in a production environment. I feel that JavaConfig is better suited than XML because:

  • While XML isnt new, every new file that a developer needs to configure adds to his work. JavaConfig being defined in Java itself, means that all a developer needs to know, is a few new annotations.
  • Java files support better IDE integration. Which means that you can click on the files from which the ContextConfiguration is loaded, and look at what beans that class provides. This click-and-navigate only seems to be work in Eclipse (3.4) and not Netbeans at this point.
  • Extending from the previous point, a java method implementation allows you to control the bean scope better. The method implementation can either be
  • FactoryMethod.getInstance() //singleton instance
  • FactoryMethod.createNew() or even //factory creating a bean
  • new FooBar() //just a new.Note: If there are @autowired  dependencies here, you need AOP.

In this case, as long as the Spring application context simply calls a method with the @Bean annotation, it can leave the scope (singleton|prototype) etc to the method itself. Unfortunately, JavaConfig has to be backwards-compatible (with the XML construct <bean>) and the scope (if prototype) needs to be provided. Perhaps later releases of JavaConfig could make the default bean scope non-singleton.

What JavaConfig can improve upon:

  • The initialization and actual wiring happens at run time rather compile time, which is good. However, this means that they typical two problems with wiring, one that there is no bean available, or that there are multiple beans available, are discovered at runtime. Since beans are lazily initialized, the first successful run of a test happens only after all the bean wiring problems are sorted out. Also, the bean wiring exceptions are seen one after another, rather than all at once.
  • The error messages about bean wiring could be better. They are often at the tail end of a long stack trace and are sometimes difficult to decipher.
  • Click-through support in an IDE for ContextConfiguration is good. However, there is no way in an IDE to navigate from an @Autowired bean to the class that provides the bean, and vice versa. This problem gets compounded when the number of tests increase. Each @Autowired bean usually as multiple (bean) configurations to borrow from, and this process has to be done manually. Some of these are listed in the JIRA ticket list for SJC.

Reasons why you might still need XML configuration:

  • Configuring load-time weaving with the <context:load-time-weaver/> needs to be mentioned in XML. There is a proposed annotation to handle this requirement, though.

As a sidebar, you might want to check the difference in the DI styles of Spring vs Guice. Although Spring Javaconfig is supposed to have borrowed ideas from Guice, its not immediately apparent. Guice uses a fluent builder to define the configuration as opposed to POJO in the Spring way.

Factorial function in clojure

This example is probably the most elegant factorial function that I've seen to date, in the Clojure JVM language.

(defn factorial [n]
(reduce * (range 1 (inc n))))

There's a longer discussion on the google group too. Other languages that support "reduce" such has Python and Lisp clones probably might achieve the same succint syntax.

Wednesday, 8 April 2009

To Maven or not to Maven

In a recent project, I was mandated to use Maven for a build tool. Since then, I've heard a lot of questions about whether or not Maven is worth migrating to. Here's my take on that, but my experience with Maven is limited to the last 5 months.
If you are using an Apache foundation project, using Maven is a no-brainer since Maven is under the Apache umbrella too. The newer Apache projects such as CXF (for web services), Camel and ServiceMix have excellent support for Maven. Support for Maven at basic, means that a project's jars are available under the Maven repository. ServiceMix has support for creating new archetypes, which a Maven concept of a template for a project.
Web application projects which are the bread and butter of a Java developer are well supported by Appfuse. It took me a while to actually understand what Appfuse did, and after some poking around (I might be wrong here), it appears to a tool that creates a template for a "standard" application. By "standard" I mean that an application stack, say "Hibernate+Spring+Webwork" needs certain artifacts in certain places, and Appfuse simplifies the job for you. The Appfuse archetypes page lists the common stacks, which is usually Spring framework along with Struts2/Apache Wicket/JSF/Tapestry providing the MVC.
Spring framework itself plays well with Maven. Most of its jars (the sub projects as well) are in the Maven Repository and updated quite often. It doesn't offer any archetypes to create specific projects though.
Under the Eclipse framework umbrella where OSGI is the reigning buzzword, Maven is probably not a good choice. Late in 2008 when I tried to build my Eclipse EMF sources to Maven, I simply had to give up at some point. The maven dependency resolution mechanism didnt work with OSGI jars, and having built EMF generated sources in Eclipse, I found it hard to simply move all of that away to Maven. The default EMF generated sources also have imports from the org.eclipse.* package which are in OSGI jars, and that doesn't help again.
Perhaps OSGI jars can and will coexist with other jars in the Maven repository, at that point using Maven makes sense.
IDE support:
Although Eclipse IDE doesn't have great support for Maven, a couple of Eclipse plugins such as m2eclipse (and another that I dont recall) can be used. The plugin allows one to import a Maven project, search and update dependencies and the other day to day operations. However, there are times when the IDE just refuses to organize its imports properly.
Netbeans and Maven pretty much worked out of the box for us. It was able to import a Maven project, build ,organize depencies and the rest quite smoothly.

Java on the Google App Engine

The news is just out that Java is the second language to be available on the Google App Engine. This immediately challenges Amazon EC2's hegemony for the cloud. Python was probably seen as the biggest negative for GAE, and that is now out of the way.
Here's a rather simplistic head-to-head of the EC2 vs GAE.