Java EE 6 Platform Draft Published

synodinos writes "The public draft of the Java EE 6 Platform specification has been published and will remain open for public review and feedback until the 23rd of Feb, 2009. Perhaps the most notable part of this delayed draft is the Web Profile, which is first profile in the history of the Java EE platform. The draft is available for download and contains both the Java EE 6 Spec and the Web Profile Spec. There is a poll running at java.net regarding what the community thinks about the new spec. Although participation is yet rather small the results tend to show that the released draft did not cause any excitement."

Comments

Java.net

[goombah99]

that's got to be sacrilege?

Not surpisingly, uninteresting

[DiegoBravo]

From TFA:

There is a poll running at java.net regarding what the community thinks about the new spec...

I like it 12.1%
I think the main spec is missing important JSRs 3%
I think the web profile spec is missing important JSRs 6%
I don't like it for some other reason 6%
I haven't read it, but plan to 9%
I haven't read it, and don't plan to 63.6%

Well, most people never read the specs (that are normally boring and with a lawyer-like style) but most Sun specs appear to being ignored because of bad timing for appearance (usually too late.) The "hot thing" are mostly the open source frameworks, from which Sun ends copying at the end.

The same is happening, albeit radically, in the Mobile editions with Android, despite the Sun auto-acclaimed ubiquity of Jave ME.

Look at my face - is it bothered?

[sgodden]

I've been leading the development of Java applications for around 8 years. On that journey, I have used fewer and fewer features of it with each succesive project.

Nowadays, it seems that specs are a kind of summary of what has been learned from the frameworks which were created in the trenches by people that actually needed to deliver.

My latest project, which has been in development for around 1 year, delivers as a plain web application, and uses Hibernate, Google Guice, AspectJ and Echo3.

It's wonderful.

Sun don't have the capability, and I'm not sure that anyone has, to provide a full and relevant specification that will allow code to be developed that will run on any application server from any vendor.

Instead, choose your implementations and go back to good old OO basics to design interfaces behind which to hide those implementation choices. You don't need Sun to do that for you.

Re:Look at my face - is it bothered?

[CynicTheHedgehog]

I've never seen a serious commercial product shipped independently of an application server. I've always though of an application server to be more of a framework. As a product author/vendor, I make choices about which application server best serves my product. Then I build around it. When I sell to end users, I either enter into some kind of licensing/support agreement with the application vendor, or I require the end user to purchase licenses and support themselves.

The spec exists so that developers can write components that can interoperate with various application servers. For example, I can write a data connector for a proprietary mainframe application and use JCA to include that in distributed XA transactions. That resource adaptor can be used on virtually any application server, but the way it is deployed and configured will differ.

Or I might write a custom JAAS LoginModule to support some kind of proprietary authentication requirements. Again, the ability to integrate into an application server is undisputed, thanks to the specifications, but the mechanisms by which it is integrated is left to the implementor.

To support full drop-in interoperability, Sun would have to control all of the details of deployment and configuration, and then there goes competition. Everyone would just grab a copy Glassfish and rebrand it, because how then would you innovate?

As a developer I'm glad that there are differences in application servers. The various classloading strategies, configuration interfaces, and monitoring tools ensure healthy competition and innovation. And if something becomes ubiquitous (or problematic enough) then it gets added to the standard. (EJB3 is largely Spring+Hibernate, standardized, and Seam+Facelets is on its way to standardization through JSF 2 and WebObjects.)

One last thing. I've worked in shops that ran Tomcat plus a few third party libs (i.e. Struts and Hibernate), and I've worked in shops that have used the full JEE stack. In the former, we had infrequent but persistent problems with transactions (lost updates, etc.) that required implementing a lot of proprietary transaction management code. Using the full JEE stack you have things like JTA and JPA that manage locking for you, which can be painful if you don't know what you're doing. But it forces you to deal with real issues rather than pretending they don't exist, which is a must for true enterprise applications. The same can be said for resource pooling, security, managing web sessions and conversations, and many other issues.

Kudos to the JCP

[thammoud]

It might be slow but it has been very successful. Sure many specs never saw the light of day. That is to be expected from every committee.

Like it or not, Java is king on the enterprise server-side. J2EE sucked at the beginning but successive versions addressed many issues required by the enterprise. Persistence (Hibernate, Toplink), transactions and messaging (JMS) and the many available and free implementations. Thank you Sun for sticking with the JCP. Standards are wonderful.

We have an ASP platform built on J2EE 5.0 handling hundreds of millions of transactions a day all on a free stack thanks for the JCP and Linux.

I will duck now since this is /. home of the anti-Java.

Re:JEE 6?

[wawannem]

The answer is "no," but for a different reason than what you may be thinking. Certain language features have been introduced recently that are used in these draft specs. For instance, for Servlet 3.0, one can configure a servlet with annotations (rather than configuring in the web.xml). Annotations weren't introduced until JDK 1.5. So, the JEE spec isn't tied to a specific JDK, but the JDK you choose at least needs to be able to support all the constructs referred to.

Re:JEE 6?

[canistel]

I feel the same way about c / c++ software... if it doesn't come in the standard package for my system (i.e. in the repository) you can forget about getting it working on your system. The sheer mess of libraries and versions needed for this and that, never mind the build systems etc., make it impossible to get anything to compile and run.

Pick your poison... I'm a java developer, and the first applications I grab (when there are more then one available for the "problem") is one built in Java.