How to make Java Developers 200% more productive

I was fortunate enough to attend a class this week on Ruby on Rails from Chad Fowler. It really opened my eyes about why Ruby on Rails is getting so much buzz in the programming community.

Many in the Java world are feeling less and less productive these days. I know I am. I've told people many times that as crazy as it sounds -- I was able to build useful apps much more quickly in old platforms like PowerBuilder and VisualBasic. (And I'm a Java Trainer for gods sake!). This feeling is very well documented in Bruce Tate's book "Beyond Java".

Java is just too BIG

Rails is referred to as a "full-stack framework for developing database-backed web applications according to the Model-View-Control pattern". WTF? Well, here's my interpretation of it -- it means there's less choice on things that your business users don't care about!

Most of the libraries, and plumbing that you would need in a typical Java Application -- have been chosen or created created for you. You don't have to think about how to make your web application Model 2 (MVC) compliant, or how to communicate to the database properly, or how to perform Ajax web updates, or how to create a REST interface, or what naming convention to use or how to structure your project. It's all there for you! You just concentrate on solving business problems. That's the biggest magic I saw in Ruby on Rails.

Can this level of productivity be achieved in Java? Not quite, Java (as the Ruby people seem to say) isn't as expressive....but we can certainly narrow the gap. Java People...wait...don't head for the exits yet...I say there is still hope!

Java is just drowning in choices.

Let's take Database connectivity -- we have many: JDBC, EJB2-CMP Entity, EJB2-BMP Entity, JDO, Toplink, Ibatis, Hibernate.

What about IDEs? We have eclipse, NetBeans, Java Studio Enterprise, JBuilder, Workshop, Together, Rational XDE, IDEA. And once you choose your IDE -- there's the plug-ins and mods...it just goes on and on....

And what about those design patterns architects like to sledgehammer into developer's minds to a point where they feel inadequate if they don't apply the right patterns. When you start a Java app -- you effectively have a blank sheet of paper -- you got nothing -- everybody writes the same stuff over and over again.

...not a week goes by where I don't stumble across some bizarre Java acronym or relatively-unknown Java open-source library that's in use.


Here's a thought -- apply the 80/20 rule to Java Web Development...80% of the Java Web Developers would agree to design and organize their applications the same way. It's like a world where 80% of the drivers in Washington DC drive Honda Accords and Toyota Camrys (which is almost the case!). An Accord and a Camry are more than adequate to get people from point A to point B. If you truly need an SUV, or a minivan, or a sports car...that's the other 20%. That type of mentality is happening in the Ruby on Rails community. "convention over configuration"

* Agree to only use a Java Web Container (ex: Tomcat)
* Agree on a common directory structure (think Maven)
* Agree on a common naming convention
(how we name models, controllers, tables, columns)
* Agree to use the Spring Framework
* Agree to use the Hibernate ORM library
* Agree to Unit-Test! JUnit, MockObjects, and EasyMock
* Agree on the same basic Ant template for builds, tests and deployments
* Agree to use the same IDE such as eclipse
* etc...

In other words -- minimize or eliminate CHOICE. And for those that have special requirements, those 20% can go off into the weeds and hack their way to the next generation of standards.

Microsoft DotNet has some advantages -- you don't have to decide what server to use, and you don't have to decide what IDE to use (Visual Studio). That's 2 major choices which completely fracture and confuse the Java community. Can't we all just get along?

Less Choice! More Productivity! We need to stop spinning wheels and wasting time on things that should be no-brainers such as database, XML creation, and unit-testing. Business users certainly don't care what ORM package was used...so Shut-up and start building solutions!

Updating the SpringBlog App from "Pro Spring" to Spring v2 and Hibernate v3.2

I've been refreshing my skills with Hibernate and Spring lately, and one of the activities I took upon myself was to update the SpringBlog application provided in the book Pro Spring from Apress.

Since the book was written in 2005, it is based on previous releases of Spring (v1.1) and Hibernate (v2.1). The current release of Spring is v2.02, and the current version of Hibernate is v3.2. (as of Jan 2007)

Here is a list of some of some upgrades I made to take advantage of improvements in Spring v2 and Hibernate v3 features:

• Changed from declarative transaction to annotation-based transactional support


• Modified the HibernateDAO classes so they do not rely on HibernateDaoSupport. The SessionFactory is injected via Spring.

I also had to make several changes due to runtime problems with the newer libraries. Maybe these worked in Spring v1.1 and Hibernate 2, they didn't work for me with Spring v2 and Hibernate v3 without modification:

• HibernateCommentDao.save() - I had to create a new Comment class and copy the data from the incoming comment variable (which is really based on CommentForm). This is the exact same things that existing code in the HibernateEntryDao.save() class had to do with EntryForm.


• Hibernate*Dao.delete() -- The delete() feature did not work for any of the Domain classes. There were errors because you cannot create objects with null values in non-null properties. And therefore - you couldn't delete those objects. So the technique used in the downloaded app doesn't work. Instead I had to perform a load() followed by a delete(). The book Java Persistence with Hibernate describes this type of logic in Section 9.3.1 (page#407).


• I had to add a Filter based on the Spring class OpenSessionInViewFilter in my web.xml. The reasons it were necessary are described in this link from the Hibernate site.


• Updated all package references to use the newer hibernate3 package provided in the spring-hibernate3.jar

It took me several hours to get this working -- I hope these suggestions save others some time!