I recently interviewed Java Champion Adam Bien, asking him about Java EE 6 and some other currently prominent issues in Java technology. Here's our discussion.
Editor: The Java EE 6 platform has been approved. What are the most significant features in the newly approved platform for Java developers?
Adam: Java EE 5 was the revolution - Java EE 6 is the evolution. JSF 2.0 is a significant step in the right direction. Introduction of annotations, easy creation of components, and integration with facelets are huge news. You can create a JSF 2.0 application in minutes without having sophisticated tools.
EJB 3.1 / REST synergy is very interesting and the Context and Dependency Injection JSR-299 / JSR-330 marriage greatly extends the DI capabilities of the platform. Now even a spec led by the head of Spring (Rod Johnson) is a part of the Java EE 6 spec.
Editor: What do you make of the final vote, where several JCP committee members voted against the approval (Apache) or abstained, due to licensing concerns? Is this significant for Java developers? For companies that develop Java EE solutions?
Adam: Apache votes every spec with "no" and the same comment. This is nothing new. SAP seems to be concerned about the full licensing terms for the TCK. The question is whether Sun didn't manage to provide the licensing terms, or didn't intend to do so. The majority of the appserver vendors voted with "yes" and SAP had no objection about the technology or programming model. From my perspective the future of Java EE 6 is very bright.
Java EE 5 is supported already by 14 vendors - a huge adoption story. Java EE 5/6 are the only vendor-neutral component model. You are not only able to run your application on different application servers without any modification, but you can only pick and choose the right licensing and support model. Java EE 5/6 are very portable and the "ancient" J2EE 1.X apps can be also very easily be migrated to Java EE 6.
Editor: Along with the Java EE 6 platform approval, several related component technology specifications were also approved. Which of these do you consider most significant?
Adam: CDI - together with JSR-330. Now Java EE 6 is a very capable Dependency Injection platform.
Editor: At DEVOXX, it was announced that closures will be included in Java 7. What's your view of this?
Adam: All Java SE APIs were developed without closures in mind already. It is actually too late. However: closures are huge news for application developers. They really can stream line the application code. I'm really looking forward to hack some closure code with JDK 1.7.
Editor: Do you agree that adding closures to Java is needed to enable Java to meet "the Multicore Challenge"?
Adam: I'm not sure about that. You can run perfectly scalable code right now with plain Java. Closures could make it more convenient - but it isn't impossible to write multicore code without them.
Editor: Since EJBs are now lightweight, can't EJBs, an established, proven, rock-solid, technology be effectively applied to desktop applications that run on multicore processors to deliver maximal performance? Thus, meeting the "Multicore Challenge" without changing the Java language?
Adam: EJBs are lightweight since 2006. They were always perfectly scalable on multicore systems because of their procedural nature. I actual never had any scalability problems with EJBs and was always surprised by their good performance.
Even more important: EJB 3.0/3.1 do follow the Convention Over Configuration / Configuration By Exception principle, what makes them the simplest possible choice for building distributed systems.
With the availability of the embeddable container in EJB 3.1 you could even run them on a desktop, or at least in a JUnit test. Glassfish EJB 3.1 container is about 1 MB, openEJB and JBoss are also very lightweight - it could really work.
Editor: Adam, thanks for providing your insight to the java.net community!
Adam: Thanks for the interview!