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:
-
J2EE 5.0 Specification Early Draft Released (17 messages)
- Posted by: Luo Shifei
- Posted on: April 07 2005 03:59 EDT
Threaded Messages (17)
- J2EE 5.0 Specification Early Draft Released by Wille Faler on April 07 2005 07:35 EDT
- What is new regarding security? by Mikael Berglund on April 07 2005 08:28 EDT
- What is new regarding security? by Joseph Ottinger on April 07 2005 08:47 EDT
- What is new regarding security? by joost de vries on April 07 2005 13:48 EDT
- What is new regarding security? by Nils Kilden-Pedersen on April 08 2005 12:17 EDT
- J2EE 5.0 Specification Early Draft Released by Matthias Weidmann on April 07 2005 09:07 EDT
- J2EE 5.0 Specification Early Draft Released by Bill Burke on April 07 2005 10:06 EDT
- ... but do provide your feedback! by Patrick Linskey on April 07 2005 10:43 EDT
- J2EE 5.0 Specification Early Draft Released by Lars Stitz on April 07 2005 10:53 EDT
-
Any concern? by Emmanuel Bernard on April 07 2005 11:20 EDT
- Any concern? by Lars Stitz on April 07 2005 01:11 EDT
-
Any concern? by Emmanuel Bernard on April 07 2005 11:20 EDT
- J2EE 5.0 Specification Early Draft Released by Bill Burke on April 07 2005 10:06 EDT
- Is it time for a J2SE/J2EE API Refactoring? by Steve Punte on April 07 2005 14:36 EDT
- Is it time for a J2SE/J2EE API Refactoring? by Martin Straus on April 07 2005 15:25 EDT
-
Is it time for a J2SE/J2EE API Refactoring? by Steve Punte on April 07 2005 04:06 EDT
-
Is it time for a J2SE/J2EE API Refactoring? by Martin Straus on April 11 2005 09:00 EDT
- Is it time for a J2SE/J2EE API Refactoring? by surajeet dev on April 11 2005 03:50 EDT
-
Is it time for a J2SE/J2EE API Refactoring? by Martin Straus on April 11 2005 09:00 EDT
-
Is it time for a J2SE/J2EE API Refactoring? by Steve Punte on April 07 2005 04:06 EDT
- Is it time for a J2SE/J2EE API Refactoring? by David Waddell on April 18 2005 08:36 EDT
- Is it time for a J2SE/J2EE API Refactoring? by Martin Straus on April 07 2005 15:25 EDT
-
J2EE 5.0 Specification Early Draft Released[ Go to top ]
- Posted by: Wille Faler
- Posted on: April 07 2005 07:35 EDT
- in response to Luo Shifei
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... -
What is new regarding security?[ Go to top ]
- Posted by: Mikael Berglund
- Posted on: April 07 2005 08:28 EDT
- in response to Luo Shifei
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 -
What is new regarding security?[ Go to top ]
- Posted by: Joseph Ottinger
- Posted on: April 07 2005 08:47 EDT
- in response to Mikael Berglund
Well, it's a draft, so if you want to emphasize these concerns, now is the time to do it. -
What is new regarding security?[ Go to top ]
- Posted by: joost de vries
- Posted on: April 07 2005 13:48 EDT
- in response to Mikael Berglund
+1 -
What is new regarding security?[ Go to top ]
- Posted by: Nils Kilden-Pedersen
- Posted on: April 08 2005 12:17 EDT
- in response to Mikael Berglund
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. -
J2EE 5.0 Specification Early Draft Released[ Go to top ]
- Posted by: Matthias Weidmann
- Posted on: April 07 2005 09:07 EDT
- in response to Luo Shifei
I'm confused about paragraph J2EE.6.25. Is this saying that EJB3.0 entity beans might not be part of J2EE5.0 ?
Matthias -
J2EE 5.0 Specification Early Draft Released[ Go to top ]
- Posted by: Bill Burke
- Posted on: April 07 2005 10:06 EDT
- in response to Matthias Weidmann
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 -
... but do provide your feedback![ Go to top ]
- Posted by: Patrick Linskey
- Posted on: April 07 2005 10:43 EDT
- in response to Bill Burke
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 -
J2EE 5.0 Specification Early Draft Released[ Go to top ]
- Posted by: Lars Stitz
- Posted on: April 07 2005 10:53 EDT
- in response to Matthias Weidmann
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 -
Any concern?[ Go to top ]
- Posted by: Emmanuel Bernard
- Posted on: April 07 2005 11:20 EDT
- in response to Lars Stitz
If you have any specific concern or remark about the EJB3 spec, please forward to [email protected] -
Any concern?[ Go to top ]
- Posted by: Lars Stitz
- Posted on: April 07 2005 13:11 EDT
- in response to Emmanuel Bernard
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 -
Is it time for a J2SE/J2EE API Refactoring?[ Go to top ]
- Posted by: Steve Punte
- Posted on: April 07 2005 14:36 EDT
- in response to Luo Shifei
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 -
Is it time for a J2SE/J2EE API Refactoring?[ Go to top ]
- Posted by: Martin Straus
- Posted on: April 07 2005 15:25 EDT
- in response to Steve Punte
Do you mean changing the package structure? If so... horror!!
Cheers and happy coding,
Martin -
Is it time for a J2SE/J2EE API Refactoring?[ Go to top ]
- Posted by: Steve Punte
- Posted on: April 07 2005 16:06 EDT
- in response to Martin Straus
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 -
Is it time for a J2SE/J2EE API Refactoring?[ Go to top ]
- Posted by: Martin Straus
- Posted on: April 11 2005 09:00 EDT
- in response to Steve Punte
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 -
Is it time for a J2SE/J2EE API Refactoring?[ Go to top ]
- Posted by: surajeet dev
- Posted on: April 11 2005 15:50 EDT
- in response to Martin Straus
"Resource Injection" ... is that the new buzzword , guys? :)
Regards
Surajeet -
Is it time for a J2SE/J2EE API Refactoring?[ Go to top ]
- Posted by: David Waddell
- Posted on: April 18 2005 08:36 EDT
- in response to Steve Punte
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 ?