Skip to main content

Which Java EE 5 feature appeals to you most?

EJB 3.0
35% (299 votes)
Java Persistence API
17% (147 votes)
JAX-WS 2.0
6% (47 votes)
JavaServer Faces
15% (127 votes)
JAXB 2.0
4% (30 votes)
StAX
3% (28 votes)
Something else
2% (14 votes)
Nothing in Java EE 5 appeals to me
18% (151 votes)
Total votes: 843

Comments

Java is enough to do the job

Servlets and JSP is all one needs to write server side Java. Certainly there is added value in some of the frameworks available for Java such as Hibernate etc. but apart from that to me a lot of what is summarized under buzzwords such as "web technology" or SOA etc. is either nothing really new or rather useless due to the tradeoffs of such "services" and "technologies": All kinds of "non Java" scripting, customizing, and learning for things Java can do better anyway. Besides: The server infrastructure is very proprietary for all that new "Java EE" stuff, isn't it? I stick with Java and a good design.

Java is enough to do the job

> Servlets and JSP is all one needs to write server side Java. EL expressions accepting browser input are avaliable only for JSF but not for JSP, because JSP has only one phase: the render phase. Duh. How about enhancing JSP do accept postbacks? It is not that hard. My take is Sun gave up on JSP in favor of JSF.

Java is enough to do the job

Well, all these new features in JEE are quite useful and in-line with good design principles, Java persistence API and JSF the most. The other side of story is that there still aren't realy good JSF component suits. All suck for serious development. Also hope that Java persistence API implementations will have less bugs than Hibernate (almost every day I encounter one). Of cousre, making good all round ORM implementation or good web component library is everything but easy.

Annotations

Using annotations all over the place instead of xml files - that's what I'm really looking forward to.

Annotations

Oh, yeah, mixing code and configuration metadata is always a good way to secure your job. :-)

Annotations

1. Currently, my job doesn't involve Java EE. 2. I'm mainly talking about JSP tag classes. Having the descriptions of those classes actually in the class files make a lot of sense to me. And the same with java beans. Why have two files when one will do?

Annotations

1. I was talking about the job you are looking forward to. You know, the one were you will be using annotations. 2. Because following your argument, there was no actual reason for the import statement to be defined for the Java language. Please note that separation of concerns is definitely always a good thing. And the best about annotations is that their use is not (yet) mandatory. There are more entertaining ways to make a software project unmaintainable. Cheers!

Annotations

well said. Annotations were the single worst thing to happen to Java, and the thing that caused me to restart my interest in C++ and start looking seriously at C# as a viable alternative to what is ever more becoming a messy language that's impossible to read and maintain code in.

Annotations

But in C# you have generics and annotations too and in my opinion it's right way to evolution of programmatic language. Correct using of generics and annotation can save more time with writting and repairing applications. With every aspect of every languages can do ugly and bugy code. If some implementation of annotation don't like, then don't use it.

Annotations

The single worst thing were generics. Annotations are only the second worst. Still annotations are very bad stuff.

Junk like this is added to a language if the developers are bored and if you have hired a bunch of CS majors who never worked in the real world.

I wish that instead of wasting their time with that esotheric junk they would plow through the bug parade and start fixing five year old bugs.

Interestingly, I am also looking into C# and .NET at the moment, and consider making C# my bread-and-butter lanaguage while dropping Java completely

Annotations

The single worst thing were generics. Would you care to elaborate on that bold claim? In my book, generics were the single best thing that could happen to Java type safety. It is difficult to sensibly port "legacy" applications or libraries towards using generics without breaking API compatibility, though.

Annotations

Stupid syntax, stupid semantics, stupid implementation, stupid documentation. What els is there to say about generics?

Enterprise without the EE

I work on large, high throughput, enterprise web apps, non of which run under any version of J2EE.
They all run under J2SE in tomcat.

Our older apps are built on a custom web framework and custom persistence layer (these were built many years ago when there really wasn't anything available). We are currently transitioning off some of these custom in-house frameworks, but J2EE doesn't have any big incentive. After much evaluation we've chosen Tapestry as the standard web framework going forward, and we'll probably (hopefully) move off our in-house persistence layer onto something else, but Hibernate has just as much a chance as EJB 3.0 (EJB 2 would have no chance).

There may be some nice things in J2EE, but it's sometimes hard to justify the added complexity.

Enterprise without the EE

Woah, you build web apps without using JSP or Servlets? That's amazing! And even more so as you seem to be able to use Tapestry, which builds upon the standard Java Servlet API, without actually using J2EE! Un-be-lievable!

Enterprise without the EE

like many people he seems to be under the impression that J2EE == EJB, something that is patantly not true of course

Yet I can't count the number of times I've been told exactly that, that unless you use EJB you are not using J2EE at all...

This of course is due in large part to Sun's own marketing system which downplays everything in J2EE in favour of EJB and only EJB for everything.