Wanted Now: Your Feedback on Java EE 7!

Work on Java EE 7 presses on under JSR 342. Things are shaping up nicely and Java EE 7 is now in the Early Draft Review stage. You can find out more and get involved by visiting the Java.net project for Java EE.

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.

Help shape the future and voice your opinion on these critical open issues by taking the short survey posted here.


We want more enhancements for EJB (easier methods, and strong EJB container : killer for spring framework)
also for Java EE 7 web server, we want an option by default for portal server, portlets supports and developing java portlets in next Netbeans version.

Posted by Naoufel on November 09, 2012 at 01:12 PM PST #

Thanks! Feel free to add EJB feature requests via the EJB EG JIRA: http://java.net/jira/browse/EJB_SPEC. Similarly, here is the Java EE JIRA: http://java.net/jira/browse/JAVAEE_SPEC.

Posted by guest on November 09, 2012 at 01:18 PM PST #

I think Java EE 7 will be a hard sell. We spent way too much on the could aspects of Java EE which never made it in. In fact, we delayed Java EE release for this very reason. I see websockets as something that won't be usable without a "framework". Three years for a standard json api is questionable at best. What exactly have we been doing since 2009 (EE 6 release)? Why are we soliciting feedback 4 months before the release of EE 7 ?

We need to take a hard look at our competitors. I am not talking about Spring here. The .net platform has an excellent mvc framework with a modern template system. They have tooling on top of everthing! All the language features that we wanted in Java SE are already implemented in C# many many years ago. They just came out with TypeScript !!

I think the Java EE expert group does not get the fact that in order to get most of these **small** incremental changes we have to upgrade our app servers !!! Unlike Spring, you don't just upgrade a few jars. The value add has to be "big" for us to upgrade our app servers. I would have suspected that 4 years would have allowed us to do that but we came up real short.

Posted by guest on November 11, 2012 at 07:11 AM PST #

I think addressing developer productivity with really good standard apis is critical. It is very hard to be productive with the official JEE stack, the app servers are slow to start the edit,complie,deploy cycle is to slow, the official API's needs layers above them to make them easier, the standardization process is painfully slow.

I would love to see JEE loose its focus on the container and start focusing more on smaller API's that can be used inside and outside the container. Then put the API's on a faster release cycle. Make incremental improvements to the API's every year and publish those improvement.

Why do developers have to wait 4 years between JEE6 and JEE7 to get support for stored procedures in JPA? There are so many cases like this in the JEE world that it is no brainer to use open source libraries other than the official one. You have to to solve real world problems.

Dear JCP your customers are the developers who are using the technology, not the vendors that are implementing the APIs.

Posted by guest on November 13, 2012 at 06:39 PM PST #

Thanks for your feedback. However, I think Java EE 6 generally and GlassFish specifically is quite productive already and does not require many layers above it. Please take a look at the GlassFish/Java EE 6 testimonials here to that end: https://blogs.oracle.com/stories/. My own experience as a long time Java EE developer in the real world mirrors these stories.

In fact many Java EE APIs are already usable outside the container and on a separate release cycle. JSF and JAX-RS are examples. However, the fact of the matter is that Java EE's focus must remain on providing a standards based platform that encourages vendor neutrality, not merely providing ad-hoc APIs to be used on non-standard platforms.

As to the JPA stored procedure example, JPA implementations have made it possible to use them with JPA for a long time now. It is important to remember that no standard is a walled garden. Standards aim to provide the core features needed for the 80% use-case. Developers are encouraged to look to vendor extensions and plugins where they are needed beyond just standards defined APIs and features at any given time.

Now, it is true that the gap between Java EE 6 and Java EE 7 has been rather long (and mostly an exception in length). It is something that the EG is acutely aware of and would look to improve on in the near future.

Posted by Reza Rahman on November 13, 2012 at 08:40 PM PST #

For sake of accuracy, Java EE 6 was released on December 10th, 2009. This means that the gap between Java EE 6 and Java EE 7 will be roughly 3.25 years, not 4 years. As mentioned however, this is indeed the longest gap in Java EE release history: http://en.wikipedia.org/wiki/Java_EE_version_history.

Posted by Reza Rahman on November 13, 2012 at 08:59 PM PST #

What Java EE should be?

1. Scrap the Bean madness. There's no sanity in writing all those getters and setters when you could just use the plain field. Of course, you can generate them, but you could just live without them unless you really required them.

This would increase productivity, I'd say.

2. JPA and POJOs are a bit odd idea. What JPA should be is describing datatypes (tables) and their relations.

Metamodel tries to fix this, but is again unnecessary work. So, why can't we just use something like the metamodel itself - call it a "Descriptor", and forget all about the Entity beans (oh those beans).

An entity could then be just and instance of Entity<Descriptor> and you could access it via Descriptor.someField.get(entity) or .set(entity, value) -method. Not too bad?

Query writing would be just like with the metamodel - typesafe and easy - but without additional steps.

And you could use Descriptor.someField.validate(value) to validate the value, or some EntityValidator.validate(Descriptor.class, entity) for the whole thing. No need for separate bean validation...

The Descriptor could be easily serializable and therefore passable as e.g. json/xml/schema along with the data to an application. Just add some annotations to the fields (public ones) of the Descriptor.

3. JSF is pure and ultimate horror. First of all, even the most praised libraries generate awful HTML and do all kinds of magic trickery rendering them useless. Of course I can try to skip all the xml-stuff, but still a lot of things just change or don't work, especially when there's script or styles included.

Modern web works with HTML and CSS templates preferrably cached in the client, JSON (or XML) data transfers, and javascript MVC on the client side. And this is a good way to integrate any other system to the just created web service.

I wanna generate templates, i.e. HTML fragments, easily based on data. JSF is an overkill for that, but the faces context is ok. Just get rid of the trickery and magic. Actually, a step back towards JSP could be good.

And no XML! It's HTML5 now on.

Posted by guest on December 18, 2012 at 09:10 AM PST #

Thanks for your comments.

I'm afraid I don't quite follow your points about bean getter/setters and JPA? You don't actually need getters/setters in JPA if you don't want them? Could you provide more details, perhaps directly to the JPA EG: http://java.net/projects/jpa-spec ?

For a more client-friendly, action-oriented, stateless web framework we are considering JAX-RS MVC as an alternative to JSF (which is optimized for server-side, stateful, form-driven applications). Feel free to get involved directly with JAX-RS: http://java.net/projects/jax-rs-spec . In the meanwhile, you can continue to use action oriented web frameworks like Struts 2 with Java EE/CDI: http://struts.apache.org/2.3.7/docs/cdi-plugin.html . The conundrum of course is that JSF remains quite popular: http://www.indeed.com/jobtrends?q=jsf%2C+spring+mvc%2C+struts+2&l= .

Posted by guest on December 18, 2012 at 09:44 AM PST #

Didn't mean JPA with that. (But I meant that Pojos aren't necessarily the best solution for JPA.)

But those JSF backing beans. I had tons of variables in one (dynamic "resource" bundle). So, I built a map and a getter, initialized it via reflection. No need for getters... and easy access guaranteed!

JAX-RS is good! Java supporting existing MVCs, like Dojo, Backbone, whatever, would be great. No need to invent the wheel - just attach an engine.

Posted by guest on December 18, 2012 at 05:11 PM PST #

Post a Comment:
Comments are closed for this entry.