Skip to main content

What do you think of the current JSR-316 (Java EE 6) proposal?

I like it
27% (114 votes)
I think the main spec is missing important JSRs
7% (29 votes)
I think the web profile spec is missing important JSRs
7% (30 votes)
I don't like it for some other reason
1% (5 votes)
I haven't read it, but plan to
17% (74 votes)
I haven't read it, and don't plan to
40% (170 votes)
Something else (please comment)
2% (7 votes)
Total votes: 429

Comments

Unfortunate JSF Inclusion

It is sad to see that JSF has not been dropped from the spec. IMO, it is one of the worst parts!

Unfortunate JSF Inclusion

+1 JSF with EL completely negates the trend of reducing XML and increasing type safety.

Unfortunate JSF Inclusion

I believe that the majority of developers who dislike JSF 1.x (for a number of valid reasons) will change their opinion after giving JSF 2.0 a serious look.

+dependency & context injection; +bean validation, -jsp

Dependency & context injection is the feature that makes jsf really useful and convenient; leaving this chapter out would take away a lot of the fun and thrill. Seam core adds power and flexibility to faces development, and 299 is a great improvement on current Seam core. Please keep it in the specs. Complex bean validation is my #1 faces headache, requiring messy and massive workarounds and the raping of the framework time to time. Though I do not know much about 303, my hope are high. Please keep it in the spesc. JSP, on the other hand, has passed it's best before date, and, as far as I know, is still attractive to the Spring – Hibernate – Struts legacy folks only. It does not mix with faces 2.0. I do not think it is of any relevance outside the plain ordinary WAR container, so, if scarified, will anyone complain?

+dependency & context injection; +bean validation, -jsp

D&CI's management of the entityManager alone makes it worth adding. Allowing the entityManager to be managed in a view context will go along way towards getting out of the old archicture where DB access and transactions are restricted to the service layer. Centralizing validation meta data reduces code and increases robustness (the view only needs one kind of validator component!) It's definitely a must.

+dependency & context injection; +bean validation, -jsp

+1

Still trapped in the past

I still have to endure development with the 1.4 stack and that is not going to change any time soon. I would be very lucky if we could change to EE 5, until then I won't even bother with version 6.

Still trapped in the past

EE 5 has a number of shortcomings. It might not be worth your time, and you should either go straight to EE 6 or use the open source alternatives. * Example shortcomings: JSF 1.x makes it difficult to create components, needs facelets addon for good templating, is missing enough important things that it makes using multiple component suites together a bad idea, etc. * JPA 1.0 is missing some basic things like one-to-many unidirectional mapping, criteria API, standardized cache hints, etc. * EJB 3.0 requires you keep it in a separate jar outside the .war, doesn't have singleton beans, and a pretty useless timer API. * No WebBeans for contexts and solid dependency injection. This is a big deal. * No JAX-RS * No Beans Validation JSR (not yet decided if it will be part of EE 6 yet) * Servlets 2.x don't support Comet/AJAX Push and require vendor specific APIs for this. * etc. You might as well go the Spring/Hibernate/etc. route if you can't go with EE 6. I think EE 6 is the most significant Java EE release ever.

Still trapped in the past

Kind of agree. It's trivial to instantiate a spring container and essentially bring the "magic" down to a very testable nucleus of code which you can repurpose to do anything. not so with ee. the component model is a step back in my opinion vs the push model of templating with jsp. I think html+js+css simply works better as a "build what you need" as opposed to bduf for components. you are dependent on a container and any variety of potential deviations. plus i'm currently working on yet *another* enterprise app that is realizing hibernate is not the way to go, and is busy untangling themselves from it. I think the only thing remotely interesting these days in the java web space is JAX-RS.

Web Profile should have more

Web Profile needs JavaMail (and therefore JAF?), Bean Binds, Java Contexts and Dependency Injection (formerly WebBeans) and JAX-RS to be complete. I think that Java EE 6 will be the first version of Java EE where developers can comfortably build almost anything they need without having to use external libraries or replace pieces of it. People who think Java EE 6 is heavy weight and bloated, but then go and assemble Spring, Hibernate ORM, Hibernate Validator, Quartz, Axis/CFX/XFire, a web framework, and all of their dependencies are hypocrites. If you don't want to use the Java EE stack of libraries, then shut up and don't use them.

Web Profile should have more

I'm not at all suggesting Spring, Hibernate, etc. are any better. In fact, many of them are much worse, but if Sun is determined to provide a solution framework I just wish they'd acknowledge finally that they screwed up and go back and resolve the root problem instead of continuing to revise a bad solution.

Web Profile should have more

Why don't you share with the expert group what you think the root problem and solution is? Most developers who follow Java EE, including myself, think the JCP has done an outstanding job with Java EE 6. JPA 2.0, JSF 2.0, JAX-RS, the new Java Contexts & Dependency Injection (formerly WebBeans), EJB 3.1, Servlets 3.0, etc. all show that the expert groups have paid attention to the industry, can keep up, and innovate.

Java EE, My Obese Friend

Why does Java need the most complicated, bloated, all-inclusive web standards of any language out there? Sure, it's come a long way since J2EE 1.3, but is web development really so complex that it needs all the JSRs it already has and all the JSRs that will be added in 6?

Java EE, My Obese Friend

Java EE is not about Web Development, it is about Standardization of Enterprise Application Server APIs. This is a huge difference. Java EE is just a collection of all the APIs that an Enterprise Application Server must implement for an Enterprise Application being at-most portable among different vendors. So, yes, it MUST be as complex as it is. If you "just" want to provide another Web Application, then you do not need Java EE -- take Jersey and run it on Grizzley and you're done. But then, don't expect to get implied transactions, security, clustering, ...

Java EE, My Obese Friend

That's an interesting perspective. "Java EE is not about Web Development" I would *love* a stripped-down php-like implementation of Java Web development that could be an ease of use/quick start/ simple apps only. Some of us really don't need any of the enterprise stuff minus a simple jsp front end to a complex backend java implementation. I believe that's a need not currently met...

Java EE, My Obese Friend

Java EE is not about Web Development, it is about Standardization of Enterprise Application Server APIs. This is a huge difference. Java EE is just a collection of all the APIs that an Enterprise Application Server must implement for an Enterprise Application being at-most portable among different vendors. So, yes, it MUST be as complex as it is. If you "just" want to provide another Web Application, then you do not need Java EE -- take Jersey and run it on Grizzley and you're done. But then, don't expect to get implied transactions, security, clustering, ...

Java EE, My Obese Friend

True, and it was unfair to try to make a side-by-side comparison to other languages, but I was specifically referring to all the "stuff" related to web development within J2EE. Yes, it provides a whole lot more, but J2EE is primarily about the web and distributed computing.

Java EE, My Obese Friend

Your obese friend has gone on a diet., and you'd be amazed if you just opened your eyes. With EE6, it is really easy to get going, and you will never see the legacy bloat. But you still get the reliability and scalability that those "other languages" can only dream of.