The first early draft of the J2EE 5.0 specification has been made available. This specification leverages many of the changes incorporated into J2SE 5.0, and has many more changes to J2EE in it, such as more complete deployment descriptors and more diagrams.

The focus of J2EE 5.0 is ease of development. Annotations are used extensively to reduce or eliminate the need to deal with J2EE deployment descriptors in many cases, and include the ability to inject resources into J2EE components. Resource injection augments the existing JNDI lookup capability to provide a new simplified model for applications to gain access to the resources needed from the operational environment. Resource injection also works with deployment descriptors to allow the deployer to customize or override resource settings specified in the application's source code. Annotations also provide better default values.

The security section seems to be far more complete that prior specifications, which is a welcome change.

There's no comparison or revisions to previous specifications included, which might have been nice to quickly see what the differences are. Structurally, it's similar to previous J2EE specifications, but has more data, as one would expect.

This is the revision of the umbrella specification, not the underlying specifications, as well, so keep in mind that this draft mentions such technologies as EJB3, but doesn't actually directly address them, so for the new implementation technologies themselves, you'll need to look at the JSRs for each product, and as an early draft, there are still incomplete sections (such as "Compatibility and Migration"), but the spec at first glance looks like it's a great improvement.

What do you think about the draft? Has the J2EE draft adequately responded to challenges from users who state that it's too big or too difficult to use? Has it addressed ease of use adequately yet? Does the injection feature address testability enough, or is it "too little, too late" in the face of projects like Spring?

Links:

• JavaTM 2 Platform, Enterprise Edition 5.0 (J2EE 5.0) Specification

Everytime I open up one of these specifications one thought comes up in my head: "Executive summary, please!".

Having to browse through 300 pages of document just to discover what's new isn't something I particularly enjoy...

I can't find anything new in terms of security. No API-support for CRUD operations on users and roles. No instance-based security either.

I think that these issues have been neglected for too long and that they have a crucial place in enterprise computing. Relying on vendor-specific extensions is not a good idea when it can be standardized.

Mikael

Well, it's a draft, so if you want to emphasize these concerns, now is the time to do it.

+1

I can't find anything new in terms of security. No API-support for CRUD operations on users and roles. No instance-based security either. I think that these issues have been neglected for too long and that they have a crucial place in enterprise computing. Relying on vendor-specific extensions is not a good idea when it can be standardized. Mikael

I asked about this and was pointed to these two JSRs:
http://www.jcp.org/en/jsr/detail?id=115
http://www.jcp.org/en/jsr/detail?id=196

Unfortunately, nothing about a CRUD API for users and roles, which I think is one of the most glaring omissions.

I'm confused about paragraph J2EE.6.25. Is this saying that EJB3.0 entity beans might not be part of J2EE5.0 ?

Matthias

I'm confused about paragraph J2EE.6.25. Is this saying that EJB3.0 entity beans might not be part of J2EE5.0 ?Matthias

The j2ee group can't make any final decisions on unfinished specs. I think the EJB3 EG is pretty confident a public draft will be ready by Java One. This is a non-issue.

Bill

I'm confused about paragraph J2EE.6.25. Is this saying that EJB3.0 entity beans might not be part of J2EE5.0 ?Matthias

The j2ee group can't make any final decisions on unfinished specs. I think the EJB3 EG is pretty confident a public draft will be ready by Java One. This is a non-issue.Bill

That said, any time that a spec calls out a section asking for your feedback, do chime in if you've got an opinion. It certainly won't hurt for the J2EE team to hear from the public about their interest in EJB3's Persistence API.

-Patrick

--
Patrick Linskey
http://solarmetric.com

I'm confused about paragraph J2EE.6.25. Is this saying that EJB3.0 entity beans might not be part of J2EE5.0?

Well, I sure hope so! At least, not in the shape the spec for EJB 3 is in at the time.

Lars

If you have any specific concern or remark about the EJB3 spec, please forward to ejb3-edr2-feedback@sun.com

If you have any specific concern or remark about the EJB3 spec, please forward to ejb3-edr2-feedback at sun dot com

Actually, I have any number of concerns. Most of them are also mentioned (and properly addressed) in the "EJB New Life" proposal by Ganesh Prasad and Rajat Taneja. [1] As the EJB 3 expert group did not even honor this proposal, I will not go into details on my own now, as I know this to be a waste of time.

The EJB component model is fundamentally flawed. EJB 3.0 will bring no fixes to most of these flaws, but instead addresses some new features (like support for annotations) which are nice to have, but not mandatory at all. Moreover, I can develop components using annotations even today (using XDoclet or the like), but will still have to suffer the broken component model of EJB with the next generation.

I'd like to see the EJB 3.0 expert group not to follow the hypes of annotations and POJO persistence, but fix the component model -- last time I checked, EJB was a component architecture, not an O/R mapping tool.

That said, what I actually like about EJB 3.0 is the notion of interceptors as well as bulk updates and deletes (to name a few).

Cheers,
Lars

[1] http://tinyurl.com/7yk3g

First of all, let me being by saying congratulations to the Java community and all those who have contribute so much over the past decade. It truly has matured to become a very broad and powerful standard.

However, success creates problems of its own nature.

Is it time for a refactoring of the Java/J2EE APIs? I’m not referring to the details of each package; rather should the stage be set for a shuffle of these packages? Some thoughts in particular are:

o Bring J2SE back to a simple core.
o Group AWT, Swing, SWT and all image related packages into their own domain.
o Do something with all the Corba stuff.
o Packages like javax.xml currently exist in both J2SE and J2EE. Perhaps all XML related packages, RMI related and Corba related could be grouped together in their own domain.
o Persistence related standards such as SQL, EJB, EJB 3.0, JDO, etc... could be grouped together in their own domain.

These are just some rough ideas. No partitioning will be perfect. However, it just seems like the time is right to revisit the foundation in order to support another decade of healthy growth.

Steve Punte
CTO
JXReports.com

Do you mean changing the package structure? If so... horror!!

Cheers and happy coding,
Martin

Martin,

Do you mean changing the package structure? If so... horror!!Cheers and happy coding,Martin

No, not what is inside each package (i.e. classes, member functions, interfaces, etc…), rather just where they placed in the greater, uhmm, what is the word we use for the J2SE and J2EE: "API bundles." Perhaps a bit more granularity at this high level. And perhaps it’s time to toss out all the deprecated classes and member functions: house cleaning! Unquestionably such a new arrangement and the "classic" arrangement would need to co-exist for a number of years. There would be some exact map between the two for clarity and to reduce support effort.

In short, a once-a-decade spring cleaning.

Steve Punte
CTO
JXReports

No, not what is inside each package (i.e. classes, member functions, interfaces, etc…), rather just where they placed in the greater, uhmm, what is the word we use for the J2SE and J2EE: "API bundles." Perhaps a bit more granularity at this high level.

Thus, you mean producing more jars, with less classes each, preserving the package structure. It would be cute, but not without some serious analisys to back it up. I don't think a per-specification criteria is enough, but perhaps that is just the case. I mean... right now, in order to evolve JDBC or Swing spec, we must evolve the whole JDK/JRE... The same goes for the J2EE SDK.
As nice as it would be to allow the independent evolution of each specification, we could eventually find ourselves in a versions compatibility hell. Having a single distribution for all of them restricts flexibility, but helps easing version considerations.

Cheers and happy coding,
Martin

"Resource Injection" ... is that the new buzzword , guys? :)

Regards
Surajeet

Refactoring is defined
 "... changing a software system in such a way that it does not alter the external behaviour of the code, yet improves its internal structure."

Reorganizing and strimming down on the java api would certainly alter it's external behaviour, a better term here would be restructuring.

After that, this sounds as highly unlikely. Every client application of J2SE that uses an api that is moved / changed / otherwise tinkered with, will need code change and recompilation if migrating to a version of java with this restructuring. Who pays for this ?