QA#6: Java EE 6: Not your fat grandfather's enterprise Java anymore, enterprise Java renaissance - by Julien Ponge
By arungupta on Feb 10, 2011
This Q&A session is part of the community feedback on Java EE 6. So far the highlighted benefits are:
- QA#1 - Standards compliance, vendor independence, milliseconds and kilobyte deployment.
- QA#2 - Higher integrated specifications, simple and annotation driven, single-classloader WARs. Next level of industry standard
- QA#3 - Jigsaw puzzle, Modular, standard, less xml, easy, easy, have I said easy?
- QA#4 - Developers can concentrate on business logic, JavaEE6 is providing a standard for the infrastructure.
- QA#5 - Faster development, less frameworks, less complexity, more great code shipped.
|This entry comes from Julien Ponge who is is a long-time opensource craftsman. He created the IzPack installer framework and has participated in several other projects, including the GlassFish application server in cooperation with Sun Microsystems. Holding a PhD in computer science from UNSW Sydney and UBP Clermont-Ferrand, he is currently an associate professor in computer science at INSA de Lyon and a researcher as part of the Amazones INRIA group. Speaking both industrial and academic languages, he is highly motivated in further developing synergies between those worlds.|
Here is a short summary of Java EE 6 from him:
Java EE 6 is not your fat grandfather's enterprise Java anymore.
And more details follow ...
1. How are you using Java EE 6 today ? What limits your adoption today ?
I am using Java EE 6 on several fronts. As an Associate Professor in one of the top french engineering school (http://telecom.insa-lyon.fr/), I teach middlewares. We do not teach Java EE technology per-se, as understanding why distributed / enterprise computing is hard is of higher importance, but the practical side of our teaching involves developing with Java EE, so it's fair to say that our students become proficient with the essentials of the technology.
Apart from that I use Java EE 6 for internal and research projects. In the first case, it serves as a solid, standards-based framework for building small applications that we need. In the later case, Java EE 6 is not where the focus is, but it provides a solid foundation for building the server-side counterpart in a few xperimental settings where we have mobile / ambient devices.
I am clearly lucky to be in a setting where the latest and greatest in technology can be used, so no infrastructure and/or skill issues hinder Java EE 6 adoption. But I reckon that adopting Java EE 6 requires longer cycles in larger organizations.
2. What Java EE 6 technologies are you using and why ?
I mostly use EJBs 3.1, CDI, JMS, Servlets, JPA and JAX-RS.
EJBs 3.1 are a truly solid foundation for business components, especially as they are transacted by default. Applying security constraints is easy, and you can still easily inject further cross-cutting concerns code. What's more, they can easily be exposed as web services and reused in web parts.
CDI covers most of the needs for dependency injection frameworks while remaining very easy to grasp. The default scopes that you get with Java EE 6
applications (application, request, session, ...) not only force you to think properly in terms of objects lifespan: you also get to write much less code! I recently wrote an small app where stateful EJBs where session-scoped, which eliminated the need for dealing with HTTP session code. Code being absorbed by a framework is always a big win.
JPA is now a mature object-relational mapping foundation, while Servlets gained 2 useful features: @WebServlet and the possibility to (finally) handle multipart HTTP POST requests in a reasonable way. No more commons-fileupload :-)
Finally, JAX-RS allows for rapidly building REST-based interfaces that seamlessly handle multiple resource representation formats such as JSON and XML. This is important, as a growing number of applications blend URLs for web and remote applications. This is also important for monitoring purposes too, with a good example being the GlassFish administration console which is RESTful.
3. What is your development and deployment environment ?
I use Glassfish v3 and Maven.
When I teach, we force our students to work in the console for building and doing most deployment tasks. We also require them to use a text editor (VIM, no troll please). IDEs are great when you have some experience, but I realized that they add too much complexity and overhead on their own when you are a starter. It is good to be "close" to the code when you learn a technology.
This is also possible with Java EE 6 being so lean/minimalistic in terms of code one has to write. You don't have to deal with configuration matters in
most cases. Coupled with Maven and Glassfish, one is no less productive than with other technologies that are said to be... well... "lightweight".
Otherwise I use IntelliJ IDEA, as it's my IDE of choice. I also happen to try Netbeans from time to time, and it is clearly as good as IDEA for any Java development. The only IDE I would recommend against is Eclipse, provided you have a choice of course.
Finally, we don't have a vast amount of data to handle, so Java DB / MySQL are just fine, although I have a clear preference for PostgreSQL in production settings whenever I can use it. PostgreSQL is rock-solid.
4. What previous versions of Java EE / J2EE have you used ? How has the migration to Java EE 6 benefited ?
I've never liked J2EE 1.x. For me, this was the typical "design by committee" mistake. I really started to use Java EE full stack when version 5 was released, as it clearly marked the standard enterprise Java renaissance. The migration to Java EE 6 is just a natural evolution from Java EE 5, with lots of added benefits such as @WebServlet and the ability to blend EJBs and web applications into WAR archives. This clearly simplifies the packaging and deployment of Java EE applications.
Before that, I had used what I would call "plain webapps", i.e., Java applications based on Servlets but with no EJB container (think Tomcat). I also sparingly
used Spring, but with the advent of Java EE 5+, there are less compelling reasons to use it. If you have a strong Spring experience in your teams then you can happily stick with it. You may still give Java EE 6 a shot, as it is now much more lightweight than Spring. Essentially, you don't have to spend any quality time choosing which pieces of a middleware stack you need to configure and assemble. With Java EE 6, it's just here and ready to go. This also yields small artifacts to deploy, often weighing less than a megabyte, as you typically have few dependencies. This is more than an convenience: it also saves a lot of memory and classloader overhead.
5. Describe the benefits of Java EE 6 to you in 120 characters.
Java EE 6 is not your fat grandfather's enterprise Java anymore.
6. Advice for anybody who is looking at Java EE 6 for their next project ?
Do not scream every time you realize that a given feature is a breeze in Java EE 6 compared to the frameworks you were used to. They still helped you before, so please show a little bit of respect ;-)
7. What new features you'd like to see in Java EE 7 ?
Allow CDI injection of remote EJB references, and deprecate the use of Java EE 5 injection annotations (@EJB, @Resource).
Remove the need for empty beans.xml just to activate CDI. Make it the default for containers, and have it turned off on the server configuration side.
Push JAX-RS foremost for web development, by making it the first choice not only for web services, but also for dealing with HTML / web browsers.
I have never really been a fan of stateful components a-la JSF for web development, so I would love to see some efforts to have a template engine in the same spirit as what we have with Grails / Play! Framework / RestHub.
There is clearly a big push toward cloud computing in our industry. I see 3 priorities here:
\* having a cache API, which is clearly lacking in Java EE at the moment, and
\* a standard API for NoSQL-store (like we have JDBC), and
\* a standard API for Object-NoSQL mapping (like we have JPA).
That is a push towards large-scale systems, but I would also love to see a push toward smaller systems, perhaps in Java EE 8. A significant part of my research activities are middlewares on "constrained devices", which include gateways and similar devices where applications and services are deployed. This is in the trend of the so-called Internet of Things. Such devices are even more and more providing an HTTP console for remote management, monitoring and administration, and their hardware allow specific Java virtual machines to run. Perhaps a "constrained devices" Java EE profile could be elaborated for such devices? Java EE should really play a big role here I think. The research team that I am part of (INRIA Amazones) could certainly help the Java community in standardization efforts if such profile would be of interest.
Thank you Julien for taking time to prepare the answers!
Are you developing, deploying, consulting, training, authoring books, etc in Java EE 6 and would like to express your opinion in a similar format ? Drop acomment on this blog and I'll line you up for the Q&A session :-)
The Java EE 6 hub is your key resource to learn all about the technology.
And you can always try all Java EE 6 features in GlassFish and refer to an extensive set of Java EE 6 & GlassFish demos.