Draft 3 of the J2EE 1.4 specification has been released. This draft adds the requirement for the WS-I Basic Profile 1.0 support (resulting in updates to the JAX-RPC and SAAJ specs), and removes all support for deployment descriptor extensibility.

Download J2EE 1.4 PFD3.

TSS will be publishing an interview with J2EE 1.4 spec lead Mark Hapner in the next couple of weeks, so stay tuned. Meanwhile, the OTN has an article that I wrote about whats new in J2EE 1.4.

Looking at what is changed in this draft (page 241 in the PDF) I noticed this:

"Removed requirement for J2EE products to include a JSR-88 deployment tool"

This sucks. The one thing I was looking forward to in J2EE 1.4 is standardized deployment, and it would seem that if the JSR-88 requirement is dropped that I have nothing to look forward to. Hopefully I'm misreading this...

Any mention of JDO in J2EE 1.4 PFD 3? I haven't looked yet.

I would like to see the javax.jdo package included in j2ee.jar so that the extra download was unnecessary. There is a precident - JMS was included in j2ee.jar without initially requiring compliant servers to ship with a JMS implementation, although this did follow.

How much support would there be there amongst TSS readers for the inclusion of javax.jdo in j2ee.jar?

Kind regards, Robin.

Hey I enjoyed your JDO book. Regarding your post, I personally don't want to see JDO in J2EE. I think it is fine to leave it seperate. I don't want it to get muddles up. KISS.

Also, one comment on something I read in your book. I don't have the book in front of me, but I thought you said that one should prefer Unconditional operators to Conditional operators in JDOQL. I want to comment that if ignoreCache is set false, that evaluation of JDOQL written with conditional operators will be significantly faster than JDOQL with unconditional operators. The reason is because evaluating jdoql on the cache means traversing the object relationships of the cache, which is slow. Conditional operators can lop off parts of the JDOQL and thus avoid lots of cache exploration.

So I think that in general one ought to write all JDOQL using conditional operators as it gives the implementation an opportunity to optimize queries that must check the cache.

Hi Geoff

Thanks for your kind words.

On the JDOQL point, I immediately cross-checked what you suggest. I think you'll find my text agrees with your perspective. Here's a brief quote from the Chapter 8, "JDOQL":

"JDOQL filters must be non-mutating, which means that their evaluation will have no side effects. Thus there is no justification for using the unconditional operators (&, |), and the conditional ones (&&, ||) should be used as a matter of course. Indeed, many JDO implementations replace & with && and | with || during query execution."

- Java Data Objects by Robin M. Roos (Addison-Wesley)
- PDF Edition available from http://www.OgilviePartners.com

So, do we agree?

Kind regards, Robin.

I am disappointed that jsr-88 is dropped from j2ee 1.4.

Perfecting J2EE!

Disappointing if JSR-88 about standard deployment is droped.
How about standard administration JSR? (I forgot the number of the JSR)

Ditto!

The whole "tons of vendor specific junk xml files" required is getting annoying, plus it makes it a pain for portability and for tools vendors (which means weaker tools).

<sigh>

Rob

My understanding:
API support is still a requirement, but the vendor no longer has to supply a tool (see section 6.18, page 109 of the specification).

I don't see this as a problem as there will likely be no shortage of tools available. Just as long as there is an Ant task for it...

That's right.

J2EE vendors MUST provides a JSR88 plugin that allow the interaction with the server. If this plugin follows the specs, any deployment tool from other vendor could use it.

Thanks for clearing that up!