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.
- QA#6: Not your fat grandfather’s enterprise Java anymore, enterprise Java renaissance
 |
This entry comes from Paul Bakker who is is a is a trainer at Info Support in the Netherlands. He teaches about a wide range of Java related topics including Java EE, Seam, Spring and Groovy & Grails. He’s a regular speaker for the NLJUG and a Java Magazine author. |
Here is a short summary of Java EE 6 from him:
Scripting framework like productivity while still keeping all enterprise characteristics and based on standards.
Keep reading for the fun stuff …
1. How are you using Java EE 6 today ? What limits your adoption ?
I’m a trainer at Info Support which means most of my days I’m training developers and architects in using certain technology and frameworks. Our Java EE 6 course is getting very popular in the last few months now that the application server support is getting better. Application server support is also the reason that adoption is still slow. Of course the support in both Glassfish v3 and JBoss AS 6 is excellent, but most of our customers in the Netherlands are using either WebSphere or WebLogic. The problem is not only the fact that WebSphere and WebLogic only have partial Java EE 6 support, but also that most (large) customers don’t upgrade to new versions easily. This is more of a licensing problem than a technical problem in most cases. It’s too bad this holds back adoption but there’s not much we can do about it from a specification perspective.
Something that I noticed is that application server vendors are adding Java EE 6 support spec by spec. For example WebLogic supports JPA 2 and JSF 2, but no CDI and EJB 3.1 yet. To me this raises the question if an umbrella Java EE spec is still useful. Isn’t it enough to have specifications for all different APIs and technologies we use? Different specs evolve at different speeds, and it would be great if application server vendors would make it easier to upgrade to newer versions of independent specs.
2. What Java EE 6 technologies are you using and why ?
Currently in both my training and projects I’m using: CDI, JPA 2.0, EJB 3.1, JSF 2.0 and JAX-RS. All specs are useful on their own, but only when used together it dramatically simplifies the programming model. In my opinion CDI is the main reason for the greatly enhanced programming model. The other specs have some very useful new features, but none of them are game changing. CDI completely changes the programming model however. Even more important is the fact that CDI makes it possible to extend the platform in a very transparent way. The JBoss folks did an excellent job at the Weld implementation and are now extending the platform in the Seam 3 project. The beauty of Seam 3 is that it adds important features to the platform, while still keeping the same programming model. If features invented in Seam 3 will be standardized in the future it will be much easier to migrate applications to using the standards again.
The other specs are great additions too however. It’s more realistic now to build applications with just Java EE 6, without using any other frameworks. Take EJB 3.1 improved timers as an example; in the past you would need a framework such as Quartz to do scheduling because EJB timers where too limited. With EJB 3.1 you probably won’t need Quartz any more. It’s not that I’m against frameworks in general. The problem with using many frameworks is that it gets harder for new developers on your team to understand what’s going on. Standardization is key to maximize reuse of knowledge, that’s why specs are important. The same is true for web frameworks. There are so many great frameworks out there all having their strengths, but it’s hard to know them all. I’m happy to see that JSF 2.0, combined with CDI, has evolved to one of the most productive web frameworks. It’s flexible enough to support multiple styles of web development (stateful vs stateless).
3. What is your development and deployment environment ?
Because I work with many different customers I work with different deployment environments too. From full blown WebSphere / WebLogic / JBoss stacks to lightweight environments such as Tomcat and Google AppEngine. This persists to be an issue for Java EE 6 adoption. Most developers are easily convinced to use Java EE 6, but are not able to do so because the application servers are not upgraded yet.
My IDE of choice is Intellij. The most important reason for this is the excellent Java EE 6 support. Luckily the IDE support for Maven has been improved a lot in the past year so it get’s very easy to switch IDEs on a project. Eclipse still doesn’t have CDI support which breaks JSF expression language support too which makes the Java EE 6 support very weak.
4. What previous versions of Java EE / J2EE have you used ? How has the migration to Java EE 6 benefited ?
I started using J2EE in the EJB 2.x era. There were two problems with this technology which are well known; the huge amount of boilerplate code and configuration, and the fact that a bunch of other frameworks were required to do any form of decent development. Java EE 5 improved the programming model a lot but was still incomplete. Incomplete because there where holes in the specs (JSF 1.2 most notably) so you would still need additional frameworks. Even more important was the lack of a real dependency injection solution. We had the @EJB and @Resource annotations but those are limited to EJBs which is too limited. Because of those limitations I never really felt very productive when using the J2EE or Java EE 5 stack compared to frameworks such as Spring. Not to even mention Grails…
With Java EE 6 however I notice that productivity has improved to levels where only scripting frameworks such as Grails could reach before. At this moment I would even prefer to use a full Java EE 6 Web Profile stack over Spring/Grails just looking at development experience. And with that, we are still based on standardized technology without any vendor lock-in. The only problem, once again, is that the latest Spring version can be used on any Servlet container, while our Java EE 6 apps only runs on a handful of servers at this moment which.
5. Describe the benefits of Java EE 6 to you in 120 characters.
Scripting framework like productivity while still keepi
ng all enterprise characteristics and based on standards.
6. Advice for anybody who is looking at Java EE 6 for their next project ?
Start by looking at CDI. For some reason CDI is not mentioned in a few of the important Java EE 6 related books and blog posts. This is a shame because CDI is the most game changing spec in Java EE 6. Besides that, take a look at the Arquillian testing framework. This gives the ability to run in-container automated integration tests fast and easily for your Java EE 6 code. This was one of the very hard to do things in the Java EE world before.
7. What new features you’d like to see in Java EE 7 ?
Most importantly I hope to be able to evolve the Java EE world more rapidly. Releasing separate specs whenever they are ready would give this possibility. If application server vendors pick up those releases and implement them in fix packs we won’t have the problem of slow adoption after the next release. For features I’m hoping on the following:
Pretty much everything in Seam 3
* Lots of JSF improvements
* A better security framework (JAAS is too low level). We need something like Spring Security in the standards.
* Easier internationalization in all parts of an application
* Easier JMS usage
An API for non-relational databases
Specially when deploying in the cloud non-relational databases get more and more important. JPA isn’t a great fit for using those databases, so we should either create a new specification for this or adapt the JPA spec for it.
AMPQ support
AMPQ seems to become an attractive alternative to JMS because it’s less Java centric. Standardized support would be most useful if AMPQ becomes more popular.
Standardized caching
Most specially in cloud environments caching is very important. The EJB spec could for example be improved by adding a method level @Cachable annotation that allows the container to cache the data returned by a method.
Clean up the programming model
Due to history and politics there are some really strange things in the Java EE 6 programming model. The fact that JSF 2.0 has it’s own @ManagedBean annotation for example is just plainly confusing to people who get started with Java EE 6. The @EJB annotation is more or less obsolete too when using CDI’s @Inject. The same is true for the overlap between Servlet 3.0 and JAX-RS. We should get rid of those duplicate solutions and go for a more straight forward programming model.
Improve the Web Profile specification
There seems to be some missing things in the Web Profile specification that each vendor now adds anyway. Most notably are JAX-RS, EJB 3.1 timers and JMS support. I don’t really see any reason why those are not in the Web Profile, but they all make sense for moderns web/enterprise applications. To my opinion the Web Profile should contain everything to do modern application development without the burden of backwards compatibility.
A RESTful web service client framework
JAX-RS is now only about implementing the server side of services, but what about the consumer side? There is some nice support in RESTEasy already, and there should be something like that in the standard. I believe the JAX-RS guys are already working on this 
Flawless Maven support
Although Maven has it’s flaws it should be the standard way of building applications to get automated builds and multi-IDE support. It’s far from trivial to get a Java EE 6 Maven build working however, specially when using unit and integration tests. This is the way people build applications, so there shouldn’t be any difficulties in this area.
Integration testing
In container integration testing should be a standard feature but is now hard to do (in the best case). Something like Arquillian should be standard available, with a standardized API to create partial deployments and running tests. While Arquillian is now based on a per-container solution to run tests this could become a lot easier if containers are required to support this.
WebSocket support
Each application server should support HTML 5 WebSockets in a standardized way.
Lambda based Criteria API
The Criteria API in JPA 2.0 is nice, but very verbose too. When looking at .NET there’s LINQ, which is basically language support for a Criteria API. That would simplify things a lot, but we’ll at least need Java 8 for this.
Thank you Paul 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.
Also check out our youtube channel and follow us on @glassfish.
Technorati: javaee6 community feedback paulbakker glassfish v3
I’m merely a spokesperson of all these brilliant folks and just blow the horn all around the world. With GlassFish 3.1 out the door, this is going to get much more exciting!
