Gavin King is the founder of Hibernate and JBoss Seam, open source projects that attempt to make life as an enterprise Java developer easier.

We sat down with Gavin to discuss enterprise Java, open source and other tidbits related to Java.

Is Seam JBoss’s answer to Enterprise 2.0?

Seam’s our answer to the problem of a lack of integration between the various technologies that are available in the J2EE environment.

In the EE world there are a lot of specifications and technologies which solve narrow technical concerns, but there is no unifying component model which says “this is the easy way to develop your business logic” so that you can take advantage of these technologies.

There are various component models which are specific to a narrow technical concern: Servlets solves the problem of serving HTTP, EJB solves the problem of accessing transactional resources, JSF solves the problem of developing pages with rich user interfaces for the Web. But they were solved individually by expert groups sitting in a room and working on that technical problem. They don’t mesh together very well.

What parts of developing with J2EE are harder than using Ruby On Rails?

The Java ecosystem is very rich, there are a lot of technologies there. We can make them all work very well together so you don’t have to write a whole lot of code. But to truly understand everything that’s going on in the small amount of code that you have to write, you do have to have an understanding of the various enterprise level technologies.

The flip side of the fact that the environment offers a lot more is that the learning curve for people that are new to Java EE development is longer.

To learn JSF (JavaServer Faces) is definitely a lot slower, there is a lot more to learn in JSF than there is to learn Ruby’s RHTML. JSF is a lot richer in what it can offer you, but it will take longer to get used to the paradigm.

The scripting languages environment still does offer some coding level advantages over a Java, things like closures and dynamic typing. Things that some developers like, other don’t like so much.

There’s pluses and minuses on both sides.

No longer can people from the world of PHP/Ruby look at Java and say it takes three weeks to get a CRUD application up and running, that’s in the past now.

Are you seeing scripting language programmers taking another look at Java?

I keep hearing stories of people who heard scripting was the next big thing, adopted it, tried it out on a project, it seemed to work well for the first few months. Then they tried to deploy it and discovered that the deployment options are very limited, they discovered that the code was a lot harder to maintain long-term without refactoring.

One of the things about Java is that it is a relatively limited language. Jumping through hoops can be a little bit of a chore, on the other hand it means that there is a lot of crazy things that people can’t do. When you work in a larger team with people with a range of experience and ability, you actually don’t want to be in an environment where people can do crazy things too easily.

How have you found it being on the JSR committees?

Working on a JSR is extremely rewarding, very formal and quite emotionally demanding at times. The process of getting together 20 people who work for 20 organisations, who [are] often vicious competitors, is very difficult. But I do believe that what comes out of a JSR tends to be more elegant, more beautiful than what any of the individual companies would have designed by themselves.

If you look at JPA (Java Persistence API), I think it is significantly cleaner and more elegant than Hibernate, Toplink or any of the other solutions that influenced it.

If you look at Web Beans, which is the JSR I am currently leading, it is significantly more elegant than Seam or Juice from Google.

It can be an immensely painful process, but it is a process that can really be worked on if you have the right expert group, if you have the right people at the right time.

The downside to the current JSR process is a certain lack of leadership. It’s been traditionally difficult to help the expert groups to work together to develop a platform which is compelling rather than individual compelling technologies.

My big hope is that Web Beans will take this approach to integration that we pioneered with Seam and become the standard model for EE development.

Has the open sourcing of Java affected your work at all?

It doesn’t effect me because fundamentally JVMs are done in a mishmash of C/C++ and I don’t develop in either of those.

Potentially it could have a profound impact several years down the road, definitely the new open source nature of the compiler and JVM mean that there are a number of new people coming in and prototyping new features of the language. It’s definitely going to profoundly effect the evolution of Java — but it also opens up the other thing, which is the potential for forks.

Java is at a difficult point in its evolution now.

It’s really unclear whether we should keep adding new features to the language or whether we would be better off making a clean break and working with a different new language on the same JVM.

There’s definitely a big increase in excitement about alternate languages on the JVM like JRuby, but there is also people who want to bring features that are popular in those languages into Java like closures.

It’s very unclear what route to go there, it’s not clear to me at all.

There are people who say “Java has to have closures” and early on I was one of those people, and now that I look at it with a little more thinking, I’m not sure Java should really have closures.

Maybe a different language should be created which is like Java and has closures.

It’s not clear to me that bolting these things on afterwards works.

How is this different from the open source projects that Red Hat and JBoss use?

We have always had a problem in the open source world of things changing fast. You can see it as a bad thing, or you could see it as a good thing. Traditionally, when you take an open sourced project, there is a problem with developers getting bored or fixing the errors in a release from a year ago, calling it 2.0 and break everything.

To an extent all software has the problem with tension between backwards compatibility or fixing mistakes, and the open source world typically goes with fixing mistakes rather than backwards compatibility.

I think that’s actually a good thing, you should fix your mistakes even if it causes pain for your users — it’s an up front pain rather than a continuous tax upon them as time goes by.

To mitigate that, what we’ve needed is companies like Red Hat which will commit to support existing versions of projects for five or seven years.

I think that commercial backing for the open source project is critical if open source is to succeed in the enterprise where people are planning projects that have decade long lifecycles.

People are often uncomfortable with the split business/distribution model that Red Hat has with RHEL and Fedora. They often ask “Does that mean that the enterprise version is better?” No, Fedora is the better version.

Fedora has all the latest and greatest stuff that someone thought of in the shower in the morning and thought “this is the coolest thing ever”. Trouble it is that you cannot support that for seven years.

I think you mitigate the problem of a lot of crazy features by having the split model that we have at Red Hat.

The other half of it is the problem of forking. Forking is one of these great selling points of open source — the freedom to fork. But, if you look around, you tend to see that well run projects fork very rarely. I know they had a whole lot of forking in the BSD world.

JBoss has basically never been forked, Hibernate has never been forked — most of our projects have never been forked at JBoss.

The reason for that seems to be that the threat of forking seems to keep the owners of the main branch honest. It forces us to keep our user community happy, to actually solve the problems that our community are having. We know that if we don’t solves those problems, someone will start their own fork of Hibernate, solve the problems and compete against us.

I think forking tends to be a good thing — it forces us to do the right thing instead of providing much of a threat.

Now on the other hand, a language is different to a Hibernate or JBoss. A language has a much greater cost in complexity, in lack of stability than there is for an API, purely because of the vast amount of software that is written to it and the depth of coupling available there.