Enterprise Java: Coming together at the Seam
Published: 18 Feb 2008 15:42 GMT
Gavin King is the founder of Hibernate and JBoss Seam, open-source projects that aim to make life easier for enterprise Java developers.
King recently met up with ZDNet.co.uk's colleagues at Builder AU to discuss enterprise Java, open source and other titbits related to Java.
Q: Is Seam JBoss's answer to Enterprise 2.0?
A: Seam's our answer to the problem of a lack of integration between the various technologies that are available in the J2EE [Java 2 Enterprise Edition] environment.
In the EE world, there are a lot of specifications and technologies that 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 that are specific to a narrow technical concern: servlets solve the problem of serving HTTP, EJB [Enterprise JavaBeans] solves the problem of accessing transactional resources, JSF [JavaServer Faces] 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 who are new to Java EE development is longer.
To learn JSF is definitely a lot slower; there is a lot more to learn in JSF than there is to learn in 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 Java, things like closures and dynamic typing; things that some developers like, [and] other don't like so much. There are pluses and minuses on both sides.
No longer can people from the world of PHP [or] 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.
No longer can people from the world of PHP [or] Ruby look at Java and say it takes three weeks to get a Crud application up and running; that's in the past now
Gavin King, JBoss
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 Java Specification Requests (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 (the 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 affect me because, fundamentally, JVMs [Java virtual machines] 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 means that there are a number of new people coming in and prototyping new features of the language. It's definitely going to profoundly affect 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...
Previous
Did you find this article useful?
4 out of 4 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
