Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2573 posts at DZone. You can read more from them at their website. View Full User Profile

Your Chance to Shape Java EE 7

11.09.2012
| 9597 views |
  • submit to reddit

For those of you who are still in the Java EE camp, the work on JEE 7 (under JSR 342) is progressing nicely and it recently entered early draft stage. 

You can dig deep into the spec here if you like. 

It's reached the stage where the community now has an opportunity to provide feedback, so a good friend of DZone, Reza Rahman, brought this to our attention and we thought it was important to get as many Javalobby community members involved as possible. 

There are now a number of important open issues that the Java EE expert group would like to get broad community feeback on. These issues include what new JSRs to add to the Java EE Full/Web Profile as well as how to better align CDI with Java EE.   --Reza Rahman


Now's your chance to help shape the future of Java.

Java EE 7 Feedback Survey


Comments

Adam Walczak replied on Mon, 2012/11/19 - 2:45pm in response to: Henk De Boer

Having two MVC web frameworks would IMHO be highly confusing. I know it's popular to bash JSF, but it's actually quite a good framework these days. I wonder if some of this bashing isn't just coming from the people behind the other frameworks (like Wicket and Spring MVC). If JSF's main problem is that it's being blackened by its competitors, why would a new web framework from Oracle/Java EE not receive the same treatment?
Instead of having two competing MVC web frameworks within Java EE, it's probably better to give JSF more "action/request"-based properties, for those use-cases that need this. In fact, this is already happening a bit. JSF 2.2's view action is an example of this direction, and the issue about a stateless mode is the most popular one now at the spec Jira. See JAVASERVERFACES_SPEC_PUBLIC-1055.

I totally disagree.

JSF is a Component-based MVC framework.

JAX-RS MVC is not and it is more suitable in many situations.

I was evaluating the two technologies for my last project. My requirements:

  • easy SEO
  • bookmarkable
  • human readable URLs
  • front-end based on prototypes written by pure HTML/JS developers

JSF to totally unusable in this scenario. And this scenario IS very common in development of content driven sites. JSF sucks in this ares, its good for pure web applications.

As for Jersey JAX-RS + their MVC + JSP the experience of developing content driven sites  is great.

(PS. I know there are hacks and libraries to make JSF fit more to my requirements but its a over-kill compared to JAX-RS MVC)

To me it would be a bad decision to leave Java EE with no standard solution for this common scenario.

Reza Rahman replied on Mon, 2012/11/19 - 3:17pm in response to: Adam Walczak

Good points and the current situation may very well change. One of the reasons the JAX-RS MVC proposal was withdrawn was that they felt not enough work was yet done in this part of JAX-RS to go too far forward. Maybe the Jersey/RESTEasy/CXF community can step up here?

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

Adam Walczak replied on Tue, 2012/11/20 - 2:31am in response to: Adam Walczak

BTW for me the best way the JSF and JAX-RS MVC standards should go is:

  1. Decouple Facelets from JSF and even HTTP to make it a general XML/STML templating language. Almost every web applications sends HTML emails for example and we have no standard way to generate them.
  2. Make Facelets an option in JAX-RS MVC.
  3. Make a clear distinction in the documentation that JSF is best suited if you mostly need a uniform and rapid way to create component based GUIs for web applications. JAX-RS MVC is best suited for content driven websites where you want more control over the HTTP protocol, URL, HTML and JS and you don't need a big abstraction layer over them like JSF.
If we would take this direction I think we could even call JSP and JSTL deprecated. At least from my point of view I would have no reason to use them.

Grzegorz Grzybek replied on Tue, 2012/11/20 - 3:45am in response to: Adam Walczak

Decouple Facelets from JSF and even HTTP to make it a general XML/STML templating language. Almost every web applications sends HTML emails for example and we have no standard way to generate them.
There are such templating engines as Velocity, Freemarker or (recent, very active and promising) Thymeleaf. Thymeleaf may be used outside any container and allows for natural templating - i.e., writing templates that will look the same when opened both from local disk and in working application. As for facelets - if it were decoupled from JSF (maybe that's possible?) it could be used as template engine... regards Grzegorz Grzybek

Grzegorz Grzybek replied on Tue, 2012/11/20 - 4:03am in response to: Reza Rahman

In fact, forking is likely to be sucessful only when original developers are involved in it and even then it's a rocky road. That's precisely why standards are that much better for ensuring vendor neutrality from any practical standpoint.

For Hudson/Jenkins, Open/Libre Office and MySQL/MariaDB original developers actually were (are) involved. With Jenkins and Libre Office it's rather not a rocky road. We can't know what would happen if VMware would close the Spring-* projects. I don't want to speculate.

Standards should ensure vendor neutrality - I agree. But it's much easier with XML and HTML when you can stick with W3 Recommendation documents than with JavaEE when pure JPA spec is not enough to use e.g. Hibernate...

Any guarantee of compatibility is meaningless without a certification and verification process (although I'm sure some people would love it so that they start calling themselves Java EE compatible even if they are not). Also, certification has little to do with the overall factors involved in the timelines for WebSphere or any other app server (and I can say that because I've run the TCK against Resin myself).

I understand that the verification process involves TCKs. It's hard for me to understand why some TCKs are not available to mortals (I tried looking for JAX-WS TCK, but found nothing...). But there may be some reasoning/IP protection.

As to your suggestion of frequent releases, that certainly applies well to implementations, extensions and plugins (the GlassFish ecosystem does indeed follow the principal). It is ill applied when it comes to standardization where ideas must incubate/mature before they are baked in to a long lasting standard, broad consensus is needed and essential artifacts like the specification, the compatibility test kit and the reference implementation must be produced

I know JBoss much more than I know Glassfish, but I agree in your point - JBoss also contains some ideas which matured and succeded - e.g. JBoss Modules (I don't list products which do not directly relate to JavaEE, such as drools, arquillian, Netty, GateIn, ...).

But we're talking about JavaEE here. And by JavaEE I mean programming model and APIs which determine programming style, the manner of creating/packaging artifacts and deploying them.

At the API level I'd like to see less factories of factories depending on what's declared in META-INF/services/. This declarative style of services selection is much abused. And leads to problems with selecting e.g. XML parsers. There's much more to it then XML of course. How about revising JavaMail specification? All these static classes and methods (Transport.send())...

regards Grzegorz Grzybek

Adam Walczak replied on Tue, 2012/11/20 - 4:22am in response to: Grzegorz Grzybek

There are such templating engines as VelocityFreemarker or (recent, very active and promising) Thymeleaf. Thymeleaf may be used outside any container and allows for natural templating

Yes I know. I even experimented with Freemarker + RestEasy + Seam Rest. Nice combo.

But this also proves that the topic of tempting engines is mature enough to include it in the standard. I think that Facelets would be the way to go in JavaEE. The implementation is already there. It just has the design flaw of being hardwired to Servlets, HTTP, JSF, etc.

Reza Rahman replied on Tue, 2012/11/20 - 11:57am in response to: Adam Walczak

This is excellent feedback. If you don't mind, I suggest sending it directly to the Java EE, JAX-RS or JSF EGs. They are easy enough to reach through here. The truth is that getting usable feedback from developers is far more effective than second-hand feedback from me (but it's certainly better than nothing).

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

Reza Rahman replied on Tue, 2012/11/20 - 12:33pm in response to: Grzegorz Grzybek

One way to understand TCK licensing is the fact that it's the only revenue stream for the JCP as a somewhat semi-autonomous body (which I assume we all want it to be). It is a fairly modest amount especially for Java EE and helps fund the folks that try to keep the JCP running smoothly behind the scenes. However, the Java EE TCK is still granted freely upon request to projects like Geronimo (despite the fact that Geronimo is available commercially).

The other important consideration is trying to maintain the integrity of the TCK against copying for spurious use that goes against the core goals of compatibility and vendor-neutrality.

As to your concern about META-INF/services/, if you can provide some more details on what you mean, that'll be great. Please make sure to make a case for why this is important to developers (as opposed to vendors that mostly deal with META-INF/services/ factories and are implicitly expected to have a different level of SPI insight/skill level).

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

Grzegorz Grzybek replied on Wed, 2012/11/21 - 12:59am in response to: Reza Rahman

One way to understand TCK licensing is the fact that it's the only revenue stream for the JCP as a somewhat semi-autonomous body (which I assume we all want it to be). It is a fairly modest amount especially for Java EE and helps fund the folks that try to keep the JCP running smoothly behind the scenes. However, the Java EE TCK is still granted freely upon request to projects like Geronimo (despite the fact that Geronimo is available commercially).

OK, I understand. So one more thing - why CDI's TCK is available, but JAX-WS isn't? (For a long time there was a dead link on jax-ws.java.net site...).

As to your concern about META-INF/services/, if you can provide some more details on what you mean, that'll be great

A specific example - I was trying to use my own (newest) version of CXF of an app running on JBoss 6 without an impact on other applications running there. Not so quick search lead me to JBOSS_HOME/lib/endorsed/jbossws-cxf-factories.jar!/META-INF/services/javax.xml.ws.spi.Provider containing a line org.jboss.wsf.stack.cxf.client.ProviderImpl.

I know that I'm not doing it the JavaEE way, I should upgrade libs in JBoss (which isn't hard).

More generic example - XML parsers configuration. We have all got accustomed to the way all these factories work, how it may be overrode using endorsed dirs. And it's more related to JavaSE than to JavaEE, but the "feature" of JavaSE causes problems in JavaEE environments. I had problems with WebSphere (I know, I'm getting boring) where you can't really know what version of JAXP you're using.

I've tried using JBoss-Modules with IBM JDK (from WebSphere App Client) and without a patch it didn't work.

If only there were so many JAXP implementations, but there's only Xerces in wide use (I don't count others, less used)

I've also got used to META-INF/services, so I don't want to start a revolution. All I would thank for is to allow child classloaders (in standard JavaEE model for EARs and WARs) to be able to override more (than now) classes from javax packages without changing internal app server libraries (which may influence other applications). See existing attempts.

And by the way - I've mentioned that earlier: The META-INF contents is used in so many areas of JavaEE (JPA, CDI's beans.xml, OSGi, services, ...), I'd very like to see it (especially MANIFEST.MF) improved. I'd like to connect to app server with JConsole (using e.g., JMX) and see all meta information of all deployment units and entire server. JMX could use META-INF information to present the meta-state of application.

  • for services: resolved JAXP factories, JAX-WS providers, etc.
  • for OSGi: a graph of dependencies, problems and conflicts (MANIFEST.MF should be XML format!)
  • etc.
Maybe in JMX 2.0?

regards Grzegorz Grzybek

Reza Rahman replied on Wed, 2012/11/21 - 10:49am in response to: Grzegorz Grzybek

How individual TCKs are made available is up to the spec lead as to where they see value. JBoss chooses to make theirs publicly available primarily due to their ideological stance on open source (and the fact that they are not the primary stakeholders of Java so they can have a weaker idea of compatibility/self-funding), while Sun/Oracle generally do not for pretty pragmatic reason's already mentioned.

Java is not an open source monoculture, it's an open technical standard. The fact that it can support a hybrid ecosystem of both the open and closed source models is a fundamental strength, not a weakness.

I already explained modularity will be addressed when it is more foundationally addressed at the Java SE level. Besides the fact that the community at large has already spoken clearly on this, the other way round simply makes no sense. For example, you can't start standardizing some feature in Java EE that is simply not congruent with the underlying Java SE platform that it depends upon.

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

Adam Walczak replied on Sun, 2012/12/16 - 9:42pm

PS. As for the JAX-RS MVC vs JSF discussion I posted a summary and my point of view on the Java EE spec mailing list: http://java.net/projects/javaee-spec/lists/users/archive/2012-12/message/64

Sorry for the delay but I didn't find time to do it earlier.

Comment viewing options

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