Open Software Integrators is an open source professional services company that provides consulting,training, development and support. Andrew C. has posted 5 posts at DZone. You can read more from them at their website. View Full User Profile

Why Java EE Lost and Spring Won

10.10.2012
| 65308 views |
  • submit to reddit

Curator's note: Andy is the CEO of OSI (Open Software Integrators). He's a forward-thinker and exceptional blogger. He will be writing regularly on DZone, so I hope you enjoy his thoughts as much as we do. 

I hate to disappoint my former colleagues at JBoss, who are still keeping up the good fight to promote Java EE as a programming model, but they have lost.  Not only have they lost the present, but the future doesn’t look bright. Java EE itself will survive, but it long ago lost the programming model war. 

As early as 2005, most of the customers I worked with at JBoss were writing their applications using the Spring Framework. I was of course “on message,” and explaining about “standards” and whatever, but not even I was buying it.

There are several trends that have caused/supported this, and also a general structural problem.

Real AJAX won

JSF, MyFaces, etc. all started with the premise that sticking with the general Web 1.0 model of redrawing the page, but adding a sprinkling of links, was a good thing. However, we saw an explosion of “RESTful web services” and JSON on the backend with JQuery and HTML on the front end. Some of this was underestimating Internet users. I mean, the dumb sods could never adjust to not having the trusty back button as their main means of navigation through an application, right?

No. Users aren’t stupid. As popular applications like Gmail and Facebook, among others, brought users to an AJAXy world, users adapted their behavior. They also adapted their expectations: seemingly instantaneous response times became a practical requirement for many applications.

As AJAX won, so did SpringMVC, RESTful web services using JSON and general “statelessness.” The state-heavy, complex, session replication post-render-post-render method of application development lost.

Seam / Spring Webflow are flops

It may be odd, declaring Spring the winner and Spring Webflow the loser, but this is really about application style.

The most promising development framework in this area was JBoss Seam, but to be honest, I never “got it.” I never “got it” on a fundamental level. To me the obvious next step wasn’t to revisit and remediate JSF; it was to make AJAX meet VB5 - to make it as easy to make standard multi-form applications as it had been with Visual Basic 5, only using a web/Javascript/Java platform.

Seam had some nice features, such as letting you “switch conversations” or “web transactions” while preserving them.  However, it was 10x more complicated than SpringMVC or Struts.  Meanwhile, web browser JavaScript engines were making big advances in performance and even compatibility. AJAX applications let you switch conversations as well, by opening another tab.

This “state management” ala JBPM that Seam offered was laborious and sometimes a bit inflexible. It was like forcing a gopher model on to the free-linking HTML model. Spring WebFlow is basically the same animal as Seam. If JSF and Faces are the anchor on Seam, Spring Webflow has Dojo, aka the AJAX framework everyone wishes they could replace with JQuery.

Seam was made “a standard” in the Java EE “WebBeans” spec and then it became Weld and Java EE’s CDI spec.  However, it is still all about server-managed state. Server-managed state began as a workaround for browsers that couldn’t hold state, where each page was re-rendered and cut from whole cloth. Later, with XMLHttpRequest/AJAX, browsers could manage state, but server-managed state was still used because of how much simpler it was to code (until you have a lot of it and the server crashes). Server-managed state has become a monster and complexity is being manufactured. 

CDI as a Spring replacement

Victory was declared when JavaEE managed to create annotations (CDI) mimicking most of the core Spring annotations framework. However, @Inject simply isn’t enough anymore. As the “high rollers” in the “Enterprise Java” world move on to “Big Data” and “NoSQL” databases and then move to the cloud, we need something a whole lot better than JPA.  Spring Data is the future of Java persistence. It unifies the model of NoSQL and RDBMS databases. 

Advocates of JavaEE will point out that it had annotations when Rod Johnson and Co. were still running around telling people that they liked XML but just didn’t know it. However, Spring adopted JPA annotations with Hibernate and then for the core framework around 2006. JavaEE annotations were still tied to EJB3 and later Seam. This container-oriented design gives you way more bloat than you need per minor Java Bean that you want injected.

What does CDI offer? Well, that Spring has a compatible implementation, but so what? Spring runs on all of the profiles “CDI” gives you access to. Sure, you might use the new annotations for new stuff, why not? But then CDI is the access point to Spring not the gateway to making you use application servers like JBoss or WebSphere.

And now for our show

So we end up with another 3 year cycle of Java EE playing catch up. Sure it will come up with another “standard” which requires proprietary vendor extensions to run efficiently -- but really was the JCP ever REALLY a standards board.  Clearly most of the energy and drive (nearly all of the new ideas and most of the actual work) is still coming from JBoss (since JavaEE) and then Oracle and IBM delay while they figure out how to get their product to support it and then finally “agree” with some “compromises.” Meanwhile the market moves on and I certainly don’t want to wait 3 more years for a standard Java programming model for NoSQL or BigData, created by the same process that brought us EJB and CMP. Especially not when the “everyman” can participate today in an open source project.

And therein lies the structural problem. It is one thing for all the vendors to get together and bless protocols and agree on how their transaction managers will be compatible or low level tie-in SPIs, but the market really doesn’t wait for the programming APIs. The three or four layers of abstraction and corruption just take too long and create things, which look like an ugly JCP factory, to create the locator to create the factory to locate the singleton style pattern that we’ve all come to love.

Move on, JavaEE. Give up on trying to dictate the programming model and focus on the SPIs that you’re actually not half bad at.

 

Published at DZone with permission of its author, Andrew C. Oliver. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Grzegorz Grzybek replied on Wed, 2012/10/10 - 2:13am

Wow - that's strong and great opinion.

Indeed - JavaEE's most important theme was "standard and implementations interchangeability”, but in fact it's a quite a lot of upfront design made by several people. CDI 1.0 (a.k.a. WebBeans) is lead by “Gavin King, Red Hat Middleware, LLC”, main person behind JSF is Ed Burns. Of course it's not a problem, but I wonder what's the *real* difference between this and SpringSource? Calling something standard doesn't automatically makes other solutions *proprietary*.

JavaEE 7 was to change everything, but it will be lacking cloud features and multitenancy – so what's left? JSON? Batch? Common...

JavaSE 8 won't be modular, so modularity won't come to JavaEE 8 either...

So please do not put an equal sign between “standard” and “the only way Java developers should work”.

Regards

Grzegorz Grzybek

Dmitry Buzdin replied on Wed, 2012/10/10 - 4:56am

From my experience since the release of JavaEE 6 a lot of customers started talking about "standards" being basically the only argument against Spring and other Open Source stacks. It did not happen when JavaEE 5 was out.

The biggest benefit of standards is that you do not have to choose and therefore you do not have any consequences from making a wrong choice. While this style of thinking is unacceptable if you are developing a system your business depends on, it turns out to be completely acceptable if you have to "sell" your architecture to non-technical stakeholders. Waiving with standard signed by respectable organizations helps indeed.

I would like to note that CDI is no longer about @Inject, but provides with at least 80% of Spring DI functionality and few interesting unique features as well. I would say CDI is enough for most of the cases as it is now. The problem of JavaEE compared to Spring starts to reveal itself when you try to integrate your technology stack together and some parts do not fit as they have been designed by independent comittees. Spring has a better component integration level and tons of utility/helper classes. The biggest problem with Spring is it's legacy. There are multiple approaches in Spring how you do things and it is incredibly hard for newbies to see the "right way" behind dozens of different interfaces and XML notations. Spring's almost ideal backward compatibility through the years plays a big role in this legacy situation. And thank you Spring Source for that!

My personal opinion is that many of the standards in JavaEE6 are quite good, namely CDI, JAX-RS, JPA and few others. Of course they all have limited area of applicability and should be evaluated against Open Source alternatives. But what actually happened in JavaEE6 and what vendors do not try to popularize is that YOU DO NOT HAVE TO HAVE AN APPLICATION CONTAINER TO RUN JAVAEE6 standard APIs anymore! Check out TomEE project for reference how to run CDI, EJB, JCA, JPA enabled app in plain "public static void main". Most, if not all, of JavaEE standards are usable in Servlet container or in Swing applications nowadays. And there is no requirement to package EJBs in EARs anymore.

Liam Knox replied on Wed, 2012/10/10 - 8:47am

The "standard" argument has always been a complete bunch of nonsense and should be rejected by any developer on that basis alone.  If you are not evaluating the quality of the "standard" then it means nothing.

Java EE and J2EE advocates has always use this floored view that standard == quality.  Yet they say this about probably one of the biggest debacles of ill thought though API's and Implementations ever to have been let leash on the Software world.

Thanks for the good article. 

 

 

Bill Burke replied on Wed, 2012/10/10 - 8:51am

Andy, Java EE lost because of JSF?  All Java web frameworks suck so this is just a lame argument from you.  Still JSF + CDI is only a small portion of Java EE.  You're forgetting JAX-RS, JTA, JPA, CDI without JSF, JMS, Servlet.  If "RESTful web services" and AJAX won, why can you not write JAX-RS + JTA + CDI + JPA and still have a strong backend platform in Java EE?

Mike Dzone replied on Wed, 2012/10/10 - 8:54am

Spring only exists to try and make Tomcat into an enterprise server which, if you need an enterprise server, then just use an enterprise server!  Most people who advocate for Spring are basically people who are not continuing to educate themselves and because of it shouldn't be making any recomendations when choosing technology. I typically show people how the same things can be done in EE5 or EE6, easier and without hundreds of lines of XML and they are amazed because they didn't know Java EE can do it. 

Grzegorz Grzybek replied on Wed, 2012/10/10 - 9:01am in response to: Mike Dzone

Most people who advocate for Spring are basically people who are not continuing to educate themselves

Actually Spring advocates continue to educate because there's always something going on. For JavaEE all stopped on 10th December 2009.

hundreds of lines of XML

Hello! Please educate yourself on Spring - see some of the showcases on Github/SpringSource and grep for XML code - you won't find much of it nowadays.

Can JavaEE do security? Can you please pass me a link to JaxWs TCK source code?

Mike Dzone replied on Wed, 2012/10/10 - 9:01am in response to: Liam Knox

And you think Spring with it's dozens of projects, and multiple confliciting ways of doing things is any better? The EE API may not be the best, but it's far better than the mess that Spring has become.

Mashama Mcfarlane replied on Wed, 2012/10/10 - 10:02am

All this cantankerous dogmatic hyperbole is unconstructive.  There is nothing wrong with reevaluating and reassessing the lay of the land.  Now just about everything is a question of cost and benefit, and I think the value proposition of a standards based approach or as I put it "coalescing around standards" is validated by the example of Spring Data and its integration with CDI and JPA.  This provides our company the opportunity to choose VMWare SQLFire over JBoss Infinispan in the likely case that Infinispan won't fit our current needs.  What is wrong with a hybrid approach?  At the end of the day we should all aspire for greater freedom and greater choice.  Doesn't look like Spring won over the standards based approached prosecuted by JBoss.  Looks like we are all winning!  But this is just my humble opinion!  Personally I like the warm comfy forward-looking blanket a good standard provides.  At the same time if my team needs to go out into the cold dark forest to bring back some meat then so be it.

 

Andrew Oliver replied on Wed, 2012/10/10 - 10:17am in response to: Dmitry Buzdin

I think that JAX-RS is a fine decorator for Spring, the default programming model for Java applications.  JCA is an "SPI" and not "programming model" (thus I fully support it so long as I don't have to write it because it is winding) and irrelevant to the argument.  It is not clear to me why I would write an EJB at this point.  Between CDI, Spring, WebBeans, etc -- what is the role of EJB other than "legacy" at this point?

Don't get me wrong, I think it was bad branding and the illogic of the market that caused EJB3 (in particular) to be beat out by Spring.  It took forever for Spring to support annotations and it seemed like forever that Rod & Co were trying to Jedi mindtrick us with "you like XML, XML is good"...  However, the market decided.  JavaEE is mostly dead as a programming model.

Karl Peterbauer replied on Wed, 2012/10/10 - 10:32am

Move on, you grumpy old warrior of the long gone Spring vs. JEE Wars.

JEE does not "dictate" a programming model anymore. CDI is a highly open and extensible architecture, and the Spring guys happily offer a CDI integration for Spring Data.

Andrew Oliver replied on Wed, 2012/10/10 - 10:44am in response to: Bill Burke

Because it is too much work.  Why should I?  Why not just use the SpringMVC annotations, Jackson and Spring Data?  Then if I want to go to Mongo it is less work.

Ken Wong replied on Wed, 2012/10/10 - 12:19pm in response to: Andrew Oliver

Yes, you do not have to.

You can choose whatever you think is the best for yourself, and nobody shout at you that you shall do things in one single way. 

but please allow others have the same freedom, and do not push your choices upon them.

If you like and prefer Spring, good for you, and really hope it serves you better.

 

Ken Wong replied on Wed, 2012/10/10 - 12:24pm

Do not know what happened recently to re-fuel the old war.

According to the title, it seems or implies a fact has been observed, or a verdict has been made.

But who is the judge? Based on what data? By what measure the data is collected? From who and where the data is collected and by whom?

I do not like the silly kindergarten kids game since I think IT people are quite reasonable grown ups.

 

 

 

 

 

Fernando Paz replied on Wed, 2012/10/10 - 12:35pm

I used JSF, GWT, SpringMVC, Struts, Strust2 and JSP... and GUI development is a pain and time.  So I decide to user SOA style haviing more choices for GUI development... like Rails

 I don't consider right tell that JEE is bat and Spring is better.  In fact I have a nice experience with CDI and a bat experiencie with JSF... but is my choice the technology for GUI.  In other side Spring was the inspiration over EJB3 because since EJB2 was a pain.  The context is important for deciding "what you have to do" and both Spring with Data, Integration, MVC, etc. and JEE with CDI, EJB, JMS are options.

I hope that in the future both options will be present for leave us a choise...

Regards 

David Blevins replied on Wed, 2012/10/10 - 12:42pm

I think it gets harder and harder to polarize what is increasingly more integrated.  "Spring" and "JavaEE" are brands, not single mutually exclussive pieces of technology that explode if found in the same application.

There are so many people using bits of both.

Shane Johnson replied on Wed, 2012/10/10 - 4:07pm in response to: Andrew Oliver

You do realize how silly these statements are, right?

"Spring, the default programming model for Java applications."
"JavaEE is mostly dead as a programming model."

Now you can certainly rephrase these statements as a matter of opinion.

"Spring, my default programming model."
"JavaEE is mostly dead as a programming model to me."

However, attempting to present these statements as facts is rather immature. I'm guessing most rational readers feel the same way. The same way they would feel if someone declared Spring to be dead as a programming model.

That being said, what a great way to get some attention!

Andrew Oliver replied on Wed, 2012/10/10 - 4:49pm in response to: Shane Johnson

You can prove these statements on jobtrends or any similar site.  

Shane Johnson replied on Wed, 2012/10/10 - 6:13pm in response to: Andrew Oliver

So you are claiming these statements as facts based on your interpretation of job trends generated with a specific set of search terms?

One might interpret trends that indicate an increase in job openings for developers with Spring Framework knowledge as a) an indication of developers migrating to Java EE positions and b) a lack of developers with legacy knowledge ;)

Liam Knox replied on Wed, 2012/10/10 - 8:50pm in response to: Mike Dzone

On the whole yes, Spring API's are very good.  And the core API's are very good because they were prototyped and actually built by Johnson in his career for use in his contracts.  I think he mentioned 3/4 iterations at least on the core Bean API.

Compare that to the complete nonsense of design by committee of the JCP and the original J2EE designers. What did they manage first effort with no real business use exposure.  To invent a API that basically assumed all IO cost was zero!  Why didn't they also claim the speed of light could be broken at the same time.  That was the level of their total idiocy.

The view that standard and quality are interchangeable just has to go now.

Look at any API and apply this. Google-guava, not a standard great API. JAX-WS is dog food. 

EE - is becoming a bit like a legacy beast trying to retro standardize emerging technologies for little to zero benefit for the community which moves on.  Spring has always had the base core IoC, AOP, Transactions, designed from experience, but has been agile enough to bridge other emerging technologies without falling behind the curve.  Indeed Spring can post fit to any good 'standards'that emerge.

I could say Spring is the defacto 'standard' model for Java Enterprise Development, period.That should make you all happy now as it is the rubber stamp of quality isn't it ;-)

Andrew Oliver replied on Wed, 2012/10/10 - 8:59pm

You're reading only parts of the statements out of context and reinterpreting them to mean what you want the to mean.  I said I've watched this since 2005 while working at JBoss, I continue to watch it while running a consulting company (even with clients who use JavaEE application servers) and that YOU can prove it to yourself with jobtrends or whatever sites you like (ironically when we started I trained everyone on EJB3 and not Spring). 

You can spot check that your suggestion is not true by looking at a few ads on monster or whatever people use for job sites.  You can also go spelunking linkedin and see how many people's most recent project was JavaEE vs Spring based.  Spring won the programming model.  Pure, simple and true.   

JavaEE has a place but continuing to try and recapture the programming model is a waste of resources.  

Sivaprasadreddy... replied on Wed, 2012/10/10 - 9:58pm

I am surprised by not seeing Reza Rahman(the man who fights for promoting JavaEE forever) on this discussion yet :-)

-Siva 

Kenneth Mark replied on Wed, 2012/10/10 - 10:13pm

I can't believe people still discussing on this issue over and over again.

People are free to use whatever they want and I believe focusing on the problem and then find a suitable technology for the solution is the best way to go.

IMHO comparing "vaguely" frameworks (or specifications) is pure waste of time.

I like chinese noodle and my wife love spagethi, that's all !

Shane Johnson replied on Wed, 2012/10/10 - 10:18pm in response to: Andrew Oliver

Of course. I suppose Red Hat, IBM, and Oracle will be closing up shop soon. After all, VMWare via SpringSource has completely dominated the market. Do enterprise organizations even use Java EE application servers anymore?

I think technical comparisons of Spring and Java EE are helpful to folks on both sides. Articles that show comparisons of code examples based on best practices for example. Even better might be quantitative analysises that include lines of code, the number of libraries, the file size of the generated artifact, and more.

But quoting your experience from 2005? Really? I think even today's Java EE advocates will admit that EJB2 was a failure. I'm sure they used Spring quite a bit. I know I did. Then EE 5 arrived and things improved. Then EE 6 arrived and things were great.

And then there is this crazy tangent on how Java EE lost to AJAX. I don't even know where to begin. Java EE is a server side framework. AJAX is one the core concepts of client side frameworks.

You write as though RESTful services are a Spring concept. They are not. After all, JAX-RS. It is an elegant API. JSON, that is not a Spring concept either. REST + JSON with Java EE? Yes. I use Jackson with RESTEasy and JBoss EAP 6 myself.

Then you write as though stateless applications are a Spring concept as well. They are not. I prefer to write stateless applications myself whether it is with Spring, Java EE, or any other framework.

Then you start comparing CDI to application state. Odd. They have nothing to do with each other. I might suggest you get better acquainted with Java EE and CDI.

Then you compare jBPM to Seam. I'm not even going to bother.

I can't really comment on Spring Data as I'm not too familiar with it. However, the entire section on CDI is all over the place. It doesn't even bother to compare CDI to Spring DI. It's just some rambling about Spring Data.

Then we have some ramblings about the JCP. That you don't want to wait 3 years for an updated API. Interesting, doesn't Spring 3 date back to 2009? Then you mentioned something about singletons. Couldn't quite make it out. How about @Singleton. Easy. Multiple layers of abstraction? Isn't that Spring?

To be honest, this article was rather incoherent.

Sivaprasadreddy... replied on Wed, 2012/10/10 - 10:18pm

A little story.

There is a small company called  CompanyAAA with a couple of s/w dev teams. They clearly know for their application there could be 100's of requests only per day. Their architects are smart people. So they considered the scope of the project, skill levels of their dev team and then choose Spring because they don't need any enterprise features like JMS, Distributed transactions etc etc for their app and their dev team is more familiar/comfirtable with Spring than JavaEE. And they built wonderful working app which serve their business needs well. Everyone is happy :-)

There is another medium sized company called CompanyBBB with 8 s/w dev teams and some of the applications written using Spring/J2EE/JavaEE are already in production. Here also Architects are smart guys. For their new app they know they want some messaging(JMS), nightly Job processing(Job Scheduling) , distributed transaction management etc etc. By considering the application required features and the lot of JavaEE/J2EE experience their dev team has they decided to use JavaEE6. And they built wonderful working app which serve their business needs well. Everyone is happy :-)

And there is another stupid company called CompanyCCC. Their architects stopped coding years back, but they keep talking about architecture, scalability, high availability blah blah based on their assumptions. They forget about the criteria(application needs and team skills) to use for technology selection and keep arguing which technology is better irrespective of their application needs. As expected the status of the project is still at technology selection process and it will be in that stage forever. :-)

 -Siva 

aysther evenstar replied on Thu, 2012/10/11 - 1:48am

Nothing says, "Don't hire me back!" like a bridge-burning email trashing your old colleagues. Nice.

Antonio Goncalves replied on Thu, 2012/10/11 - 3:57am

Hum, I will not go into this sterile "Java EE vs Spring" war. But two things :

The right architecture to the right application. Not all of us work for Facebook or Twitter. If you look at their "web site" the navigation is quite simple. As you say, their problem is elsewhere : managing heavy load and heavy amounts of data. For them, statelessness and NoSQL is mandatory. But when you work on a "web application" (completelly different from a "web site") then you deal with complex flow management. Their problem is elsewhere : few users but complex long time running transactional flows. Statefull architecture are mandatory. 

And second I really hoped that "everyman can participate today in an open source project". But you know it's less and less true. Open source is becoming professional and my personal "spare 4 hours a week at night to work on OS" is ridiculous compare to a company who pays dozens of developpers to work full time on their OS project.

As a friend of mind said "stateless is priceless" but "stateful is beautiful". The right tool for the right job 

Dapeng Liu replied on Thu, 2012/10/11 - 2:38am

+1 for Siva's comment

we are using GWT + JAX-RS + CDI + EJB (for transactioin and scheduling) on glassfish 3.1.2.2, everything is fine  

Shailendra Kumar replied on Thu, 2012/10/11 - 7:34am

Show me your requirements and resources  and I will tell you which one  to use  - Spring or EE ! Period !

P.S. I have a soft corner for Spring and so thanks to Rod Johnson and community for giving us Spring platform and I also appreciate the prudence of EE designers for learning from community and trying to incorporate something useful into EE which would be backed by heavyweights for atleast sometime to come.

 

Tom W-dzone replied on Thu, 2012/10/11 - 9:29am

I want to believe that JavaEE6 will do the job needed for my client (since that is what they say they prefer). In looking into using it, the first thing I looked into raises concern: I'd like to use a single model, CDI, for all of my injectable units (keeps things simpler). CDI, doesn't (as far I can tell) support transaction management out of the box. The suggested way then to do tx mgmt appears to be either:

a) use EJBs at transactional boundaries,
or
b) use CDI interception to provide TX mgmt.

Going route a) EJBs, means having two seemingly incompatible models to work with (whereas I'd like only one to work with for simplicity). I say incompatible because it appears from (http://docs.oracle.com/javaee/6/tutorial/doc/gjfzi.html) that a CDI bean cannot be an EJB. So, for isntance if I switch a CDI beanA to an EJB to make it transactional, all other beanBs that inject beanA now need to switch from @Inject to @EJB, and that bean can no longer just live in ear/lib as a regular jar, it needs to be part of an ejb jar (as far as I know). Even assuming there are ways to address some of those points, I'd still like to just advise one way of doing things, and not have to concern the team with EJB semantics on top of CDI semantics.

Alternatively, going b) use a tx mgmt interceptors with CDI seems to be the suggested alternative. I then assumed there would be a fully-baked open-source implementation of such an tx mgmt interceptor, but I'm not coming up with anything. Seam Persistence appears to be a candidate, but it is not complete: for instance, REQUIRES_NEW (which my client uses) is not supported (The Seam persistence docs say it is coming in the final release, but isn't, and a feature request(https://issues.jboss.org/browse/JBSEAM-4391) for REQUIRES_NEW is from 2009 and is not implemented).  I also found side projects such as https://code.google.com/p/transaction-cdi/, but nothing that seems complete and highly used. I realize I was expecting an out-of-the-box equivalent to the Spring tx mgmt functionality (just another annotation on a regular bean, simple ways to mark certain exceptions as rollback vs non-rollback, get*==readOnly style simplifications, etc), but I'm not yet seeing it.

 

Shane Johnson replied on Thu, 2012/10/11 - 9:48am in response to: Tom W-dzone

If you really want to believe that Java EE 6 will do the job, you should learn what it is.

a) We are not talking about two incompatible models. You don't have to use @EJB anymore. You can use @Inject instead.

b) That, and you no longer have to package the EJB in an EJB-JAR. It can be included with the web application (WAR).

Honestly, these were two of the more notable improvements brought about with Java EE 6.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.