Anton Arhipov is a Software Developer and Product Lead for JRebel, the productivity tool for Java developers. Anton’s professional interests include Java and related, programming languages and middleware. You can follow Anton on Twitter (@antonarhipov) and find him on LinkedIn (linkd.in/aarhipov). Anton has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

Java EE 7 Public Draft was Published. I Demand Java EE Light Profile!

01.11.2013
| 3673 views |
  • submit to reddit

On December 20, 2012 a public draft of Java EE 7 has been uploaded. On first sight, the new spec is rather an improvement of the subsequent specs in Java EE 6. For instance, I really like the Web Profile idea. But it is a shame that it wasn't a part of Java EE 6 Web Profile.

The Web Profile is targeted at developers of modern web applications
IMO, most of the modern web applications make use of REST. Or at least this is my perception. In Rails world, AFAIK, violating REST principle is a subject for brutal prosecution by the colleagues :) Luckily Java EE 7 fixes that mistake and JAX-RS specification is now a part of Web Profile.
Targeting “modern” web applications then implies offering a reasonably complete stack, composed of standard APIs, and capable out-of-the-box of addressing the needs of a large class of web applications.

OK, now you can really develop "modern" web apps with Web Profile, but...

In terms of completeness, the Web Profile offers a complete stack, with technologies addressing presentation and state management. (JavaServer Faces, JavaServer Pages), core web container funtionality (Servlet), business logic (Enterprise JavaBeans Lite), transactions (Java Transaction API), persistence (Java Persistence API) and more.

Sounds like redundancy to me. For instance, why would you need EJBs there? If CDI supported interceptors properly there wouldn't be a need for EJBs in that sense. Or, JSF? Well, I'm just not a fan of that.

What I'm trying to say here is that since for compatibility reasons there wouldn't be possible to drop specs from Web Profile, maybe it is now time to create a "Light Profile"? A minimalistic set of Java EE specs that would be sufficient for building modern web applications.

Of course the term is a bit foggy - what should we consider a modern web application. These days it is a combination of a REST backend and UI technologies such as HTML5 and JavaScript. My logic says that since Java EE doesn't specify UI technology then the main specification that required is JAX-RS and the complementary specifications to support transactions (JTA/JTS), persistance (JPA), and dependency injection (CDI). Of course, there are some nice complementary specifications such as Bean Validation and Java API for JSON processing. But I would definitely drop JSF and EJBs for sure.

This would bring the containers like Tomcat and Jetty even closer to the spec and who knows maybe one day we will have a Java EE "Jetty Profile", why not :)

 

Published at DZone with permission of its author, Anton Arhipov. (source)

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

Tags:

Comments

Philopator Ptolemy replied on Fri, 2013/01/11 - 10:21am

My logic says that since Java EE doesn't specify UI technology then the main specification that required is JAX-RS and the complementary specifications to support transactions (JTA/JTS), persistance (JPA), and dependency injection (CDI). Of course, there are some nice complementary specifications such as Bean Validation and Java API for JSON processing. But I would definitely drop JSF and EJBs for sure.
Hmm, sounds like ... Spring...

Reza Rahman replied on Fri, 2013/01/11 - 1:33pm

Thanks for offering your opinion, it is most certainly a good thing. The issues of whether to include JSF and EJB into the Web Profile is not new however. They were discussed at length during the Java EE 6 time frame (I took part in that discussion  -- it was one of the longest threads in JCP history) and none of the fundemantal arguments have changed much (at least yet).

While it is true that HTML 5 may bring profound changes to how UIs are written, those changes are yet to truly materialize. In the meanwhile, the vast majority of server-side developers require a server-side web framework and JSF use is pretty pervasive, certainly amongst core Java EE adopters (like myself), even despite the abundance of web frameworks out there.

CDI was never intended to replace EJB. It makes no attempt to address concerns such as decralative transactions, security, scheduling, asynchronous processing and the like -- EJB already does that. In fact, the EJB @Asynchronous and @Schedule annotations were moved to EJB Lite (EJB Lite is an EJB sub-set targeted specifically for the Web Profile) because the community asked for these EJB features in the Web Profile. While you can certainly rewrite EJB features ad-hoc using CDI interceptors there is little reason to reinvent the wheel, not to mention it would be strictly non-standard. Now, all this might change in the near future as we start decoupling more and more EJB style services from the component model as we have started to do with the JTA @Transactional annotation in Java EE 7.

As to standardizing Jetty and Tomcat, there is aleady a Tomcat Java EE Web Profile implementation - TomEE. In fact, the total number of Web Profile implementations are now eight  -- inclusing Resin, a former "Servlet only" container. It hardly makes sense to make wholesale changes to the Web Profile based on just Jetty!

Lastly, it is indeed possible to drop specs from a profile if there is solid reasons to do so...

All views voiced are my own, not necessarily Oracle's.

Henk De Boer replied on Fri, 2013/01/11 - 3:15pm

But I would definitely drop JSF and EJBs for sure.


Sounds like a classic bias, perhaps based on experience with the legacy EJB 2 and JSF 1.2?


It's true that those emphasized a very heavyweight programming model, but EJB 3.1 and JSF 2.1 are very lightweight and definitely belong in the web profile. They are great technologies that make building web apps so much easier!

Eventually the EJB component model and JSF's own managed beans should be replaced by CDI, but that doesn't mean the services offered by EJB are needed anymore, they are! It also doesn't necessarily that things become even more lightweight, as EJBs are basically as simple as things can get (in most cases, add an @Stateless annotation on your POJO, and that's it). But it will be good for consistency if there's a single unified model.

JSF wouldn't change much if CDI replaces its native beans. CDI was inspired by those beans in the first place and is mostly a neat superset. They feel and act pretty much just as JSF native managed beans, just with more capabilities.

Stan Svec replied on Tue, 2013/01/15 - 5:39am

You do not need to wait for a Light Profile. The best parts of Java EE are available separately. For modern web application you can just use Dropwizard framework + standalone Weld (CDI) for dependency injection. For data access you can choose DeltaSpike JPA module or something else. As a bonus you get rid of all troubles associated with (re)deployments. :)

Reza Rahman replied on Tue, 2013/01/15 - 10:38am in response to: Stan Svec

This is a good point. For anyone that really has a compelling need for a very custom stack, pretty much all Java EE APIs have pluggable implementations including CDI, EJB, JTA and JAX-WS. You can simply start with plain Tomcat (as TomEE does) or Jetty (apparently as Dropwizard does) and add whatever Java EE API you want.

Not exactly sure what "all troubles" associated with deployments are :-). Most application servers these days support dynamic deployment. GlassFish certainly does and I've used it for Java EE 6 development myself. Also, ZeroTurnaround offers a pretty nice dynamic deployment plugin that's popular/widely used.

All views voiced are my own, not necessarily Oracle's.

Comment viewing options

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