Java Champion Antonio Goncalves talks about Java EE 6 and the future of Java EE 7

Welcome to the fourth in a series of interviews dedicated to learning more about JetBrains Development Academy Experts. This time we will interview Antonio Goncalves. Antonio is a Java Champion and senior software architect living in Paris, and his specialties are Java, Java EE, and the open source frameworks that evolve around it. Between writing books, articles, and blog posts, he also finds time to run the Paris Java User Group. As a JetBrains Development Academy member, Antonio is recognized as a champion of best development practices and innovation. Academy Members of the JetBrains Academy are recognized experts in various areas of software development. They contribute to Java and .Net communities by advocating development best practices through formal and informal publications and meetings, and serve as a versatile source of expertise.

I got a chance to sit down with Antonio and talk about the current state and future of Java EE: what he likes, what is underused, and what the next few years should hold.

Me: Hi Antonio, thanks for taking a few minutes to talk to us. I'd like to ask some questions about the current state of Java EE 6 and also get your thoughts about where Java EE 7 should head. First, a company I'm currently working with is just now migrating from Java EE 5 to Java EE 6. What's the first EE 6 feature you recommend them to use that can bring the biggest productivity gain over EE 5?

Antonio: First of all, you don't need to migrate ;o) I've taken a complete Java EE 5 application (JPA 1.0, EJB 3.0 (stateless/stateful/MDB), JMS, Swing with Remote EJBs, JAX-WS) without changing a single line of code and deploy it into a Java EE 6 application server (GlassFish 3.x). The beauty of Java EE 6 is that it's backward compatible with Java EE 5.

Once this is done and you made sure your code is portable, I will start by adding Bean Validation. It's a very simple to use API. It allows you to write constraints and use them in your code. Refactor your code, extract the constraints that are spread throughout your application, get rid of all your if (s != null && !"".equals(s)) and replace them with @NotNull and so on. Then focus on convention over configuration: XML is not always needed (the biggest improvement is in JSF 2.0 and Servlet 3.0). If you only use local EJBs remember to get rid of the local interfaces (I hate interfaces)... and this will shrink the amount of XML and Java code. In some cases I got 20% less code by migrating to Java EE 6 and following these simple rules. To make your code portable, refactor the JNDI names of your resources (in Java EE 6 all the JNDI names have been standardized) and get rid of any Delegate. Oh, and by the way, talking about design patterns, remember to get rid of some of your useless DAOs and just use the EntityManager in your Stateless EJB (KISS). Then, benefit from the new dependency injection model and get rid of your factories.

Me: Do you think there are some aspects of EE 6 that are underused or under-appreciated? Maybe something that you think is valuable but hasn't had the adoption you'd hoped for?

Antonio: CDI (Contexts and Dependency Injection) is clearly underused at the moment. The reason being it's a 1.0 specification (didn't exist at all in Java EE 5), it spreads over several specifications (EJBs, JSF and most of the Managed Beans) and therefore makes it more complex to understand than Bean Validation (which is also a 1.0 specification). CDI also allows to extend the platform by delivering an SPI. This way we will see more and more frameworks that can just be plugged and played into Java EE. Start gently, just with DI to start, replace all your resource injection with @Inject, use @Named to use your beans in expression language (e.g. JSF pages) and @Qualifier to make your life easy. If you have a stateful architecture (using Stateful EJBs) then you should also look into CDI (the 'C' stands for Contexts).

Me: Let's talk about Java EE 7. You mentioned in a recent blog post that you'd like to see some sort of flow management in Java EE, perhaps taking inspiration from Spring Web Flow or Seam Page Flow. I like this idea, too. Can you briefly explain the problem and why you need something like this? What are you doing today to solve this problem? Are there libraries are frameworks you can use today with Java EE 6 to bridge the gap until its part of the specification?

Antonio: On my current contract I use Spring Web Flow. I clearly see the benefit of such framework. It nicely decouples the pages from the navigation in a much richer way that the faces-config.xml can. You can use Expression Language in your flow so you can invoke services, use some conditions for navigation and so on. To navigate we had Struts, then JSF and the faces-config.xml... with flow management we can go much further. And to a certain extent we could use flow management in other aspects of the platform (not just page flows but, why not, process flows). The problem with Spring Web Flow is that it took time to support JSF 2.0, it's not standard and it's sooooooo XML (have a look at Seam Config and see how XML can be a bit more "type safe ;o) Hopefully we will see a better flow management in JSF 2.2 (coming with Java EE 7) which will embrace the new Expression Language 3.0 (the Expression Language has been taken out the JSP spec and evolves on its own).

Me: Your recent Java EE 7 blog post also mentioned the desire for standardized batch processing feature. There are batch processing frameworks available today, such as Spring Batch, and this type of feature seems orthogonal to typical Java EE concerns. Why do you think a batch processing specification is better as part of Java EE instead of left up to the ecosystem and 3rd parties to develop?

Antonio: We live in a virtual web world where everything fits into a web page. Well, that's what we think. Most of my customers have more lines of code running back-end processes than in the front-end. There are millions of batches out there and we have no standard way to write them. On the opposite we have dozens of web frameworks to help us design web pages with a bit of blue and red to make them look nice. It would be about time to have a specification for batch processing. But your question also raises the point of why and when to standardize something. In the JCP history there are some cases where standards have been created without enough experience, leading to failure (remember the Entity Beans while TopLink was already being used?). So we need not hurry. Look around for experiences, frameworks, real life feedback and then standardize. We have been doing batch processing for decades, so we know how they work. Let's make a standard and go further: Java EE 7 will focus on the Cloud, well let's be able to process and chain processes in a distributed manner.

Me: You were part of the Java EE 6 expert group. Are you going to be part of the Java EE 7 expert group? Also, what are some things that people can do to help the process without being part of the expert group? For instance, imagine a person is willing to commit one or two hours a week to furthering Java. What can they do with their time to help the community?

Antonio: Yes I can tell you that I'm definitely part of the Java EE 7 expert group that was created a few weeks ago. I can't be 100% sure about what I'm saying here, but hopefully Java EE 7 (and the specs that make EE 7) will be lead in a much more open way. I was in a conference call with Patrick Curran (chair of the JCP) recently and he really wants spec leaders to use open mailing lists to exchange information. If that really happens, anybody will be able to read the mailing list and give their input. Also most of the reference implementations are open source now, the other way to give your input could be to join one of these projects.

Me: On my current project we're also starting to migrate some EE deployments from WebLogic to Glassfish. Now that Glassfish has been around a while, and it's fully open source, is there a good reason to pick a vendor's EE container over an open-source one like Glassfish? Why are people still paying for EE containers?

Antonio: Open source doesn't mean free. I know plenty of customers running JBoss and GlassFish in production: they all pay to get some support (you don't want your production to stop because of a bug that will take you ages to find and fix). So, open source application servers can cost you money too. Open source doesn't mean free but it does mean open: open access to the code, open access to JIRA, open access to the documentation, mailing list, forum and so on. That makes the community grow bigger. I am a former BEA employee and used Weblogic extensively for many years. Today I know better what happens within GlassFish than Weblogic (it is not open). IBM has Websphere and Geronimo. Clearly, not much effort is put into Geronimo, so customers don't have much choice, they are stuck with Websphere. Oracle has Weblogic and GlassFish. Both servers share more and more codebase. Maybe one day Oracle will only have one open source app server with commercial support if you need.

Me: Thanks for the time Antonio. Do you have a book, or an upcoming speaking engagement you want to promote? This might be a good time to invite everyone to Paris JUG!

Antonio: Last year I did a lot of JUG touring during winter. Not a good idea, it's too cold. This year I will be going to some JUGs (France, Germany, Czech Republic) in Spring and Summer so I can enjoy the weather. I'll be speaking at the GeeCon in Kracow and maybe at Devoxx (I love Devoxx, I feel at home there). In terms of books I will update the Java EE 6 to a third edition... but more at the end of the year. I also do some Java EE 6 training, so feel free to contact me through my website. And yes, if you want to come to a beautiful city to talk in front of 200 people, the Paris JUG is the place to come ;o)