This past week's java.net poll presented a list of statements related to Java EE, and asked people to select which statement they agree with most. The results suggest that many developers consider Java EE complicated, but Java EE 6 is considered a major improvement in terms of ease of use. A total of 379 votes were cast. The exact question and results were:
Which Java EE statement do you agree with most?
21% (79 votes) - Java EE is too complicated
10% (37 votes) - Java EE's complexity reflects the problems it solves
15% (55 votes) - Java EE's modularity makes it as simple or complex as your app requires
39% (146 votes) - Java EE 6 is much easier to use than previous versions
3% (10 votes) - I disagree with all of those statements!
11% (43 votes) - I don't know
2% (9 votes) - Other
The results of the non-scientific survey suggest that the view of Java EE as being overly complex remains for many people. However, even more people consider Java EE a significant improvement compared with earlier versions of Java EE with respect to ease of use. For a technology as mature as Java EE, to make additions and enhancements to the platform, while also making the technology easier to use, is a remarkable success story!
While 21% consider Java EE too complicated, a total of 25% agree that Java EE is complex, but appropriately so: 10% consider the complexity to reflect the fact that Java EE addresses difficult problems; 15% believe Java EE can be simple or complex, as required for the task at hand.
There was one comment posted, cowwoc's "Think outside the box":
While it is true that Java EE 6 is a lot nicer than previous versions, I am still left with the feeling that something is fundamentally wrong about the problems we are trying to solve. It is no coincidence that many of the "core" APIs feel right and things tend to get more complex as you drift away from the center. The ORM section of Java EE reminds me of trying to fit a square through a round hole...
New poll: GlassFish Roadmap
The new poll is related to the recent publication of the new GlassFish Roadmap. Alexis Moussine-Pouchkine summarizes the roadmap in his latest blog post, and also provides a link to the slides.
JavaFX's node-based infrastructure is problematic for complex
scenes such as fireworks or fractals. These scenes require the
creation of many nodes and (possibly)
javafx.scene.shape.Path objects (such as
javafx.scene.shape.LineTo), which can occupy a lot of
memory. Last June, I posted my
Painter's Canvas article to present an alternative that
reduces storage overhead. That article introduced the concepts of
painter and canvas to create...
I think that it will be helpful for the JavaFX community to understand what JavaFX-related activities each other is working on, including successes that we're having and challenges that we're facing. Doing this will help us discover ways that we can help each other, collaborate, learn from each other's mistakes, etc...
There's been some FUD around GlassFish since the Oracle acquisition closed in January (and in fact even before) and it was hard for the team to dispel it until now. The GlassFish Roadmap Community Update slides used during today's live presentation are now available. In a nutshell, the v3.1 release will offer centralized admin, clustering and Coherence support...
The GlassFish Certificate Realm in V2.X and V3.0 releases is somewhat limiting. Many users expressed the need to able to do some custom authentication based on the client-certificate (or extensions within) in a Mutual-SSL scenario. And subsequently do custom group assignment's which ultimately affect the authorization results. With V2.X/V3.0 the only two things that were possible are...
Embedded GlassFish v3 is a delivery vehicle of GFv3 so that applications and tools can use GFv3 just as a library, inside their JVM. More details on this can be found on the separate project page that has been created for Embedded GlassFish. One would thus expect that even secure applications which use security annotations on an EJB or security-constraints in a web application to work on the Embedded Server...
For most of the year, I've been working on session replication code for Sailfin. When I came back to work with the Glassfish performance team, I found that we had some pretty aggressive goals around performance, particularly considering that Glassfish V3 had a completely new architecture, was a major rewrite of major sections of code, and implements the new Java EE 6 specification. Glassfish V3 in those terms is essentially a .0 release, and I was convinced we'd see major performance regressions from the excellent performance we achieved with Glassfish V2. Color me surprised; in the end, we met or exceeded all of our goals for V3 performance...
In the Forums, Wei Xiong has a question in the Metro and JAXB forum on usage about HandlerTubeFactory: hi, all experts who know how to use HandlerTubeFactory? I think there must be a config file somewhere to HandlerTubeFactory to load handler. is it right? any sample code? ...
mmckenna asks about the Best Way to Generate RI Compatible MPEG-2 Transport Streams: Hello, Does anyone have advice or suggestions on the best way to create compliant MPEG-2 transport streams for use in the OCAP RI? I haven't had much success using either FFMPEG or tsmuxer. Thanks! Matt
sveinni is getting an InstantiationException in WS client for abstract complexType with jax-ws 2: Short version: I need to emulate the effect of the @XmlSeeAlso annotation in a jax-ws 2.0 client application. What are my options? Long version: I'm developing a standalone web service client, using JDK 1.6.0_18 in the...
Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.
Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.
Previous Topic
