JSR 244, the umbrella spec that defines what other specs and capabilities will be included as part of Java EE 5 (formerly J2EE 1.5), has had it's public review spec approved by the JCP EC. The theme of the release is ease of development, focused on redefining the platform in light of annotations and pojo-driven development, with major additions including the Java Persistence API 1.0 (EJB 3 entities), JSF, JSTL, and more.

From the spec:

The focus of J2EE 5.0 is ease of development. To simplify the development process for programmers just starting with J2EE, or developing small to medium applications, we've made extensive use of Java language annotations that were introduced by J2SE 5.0. Annotations reduce or eliminate the need to deal with J2EE deployment descriptors in many cases. Even large applications can benefit from the simplifications provided by annotations.

As expected, the EC passed it unanimously, with IBM still making the usual comments about licensing they've included on all JSR votes in the last 6 months:

IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.

The specific API's mandated for Java EE 5 are:

Enterprise JavaBeans (EJB) 3.0
Servlet 2.4
JavaServer Pages (JSP) 2.1
Java Message Service (JMS) 1.1
Java Transaction API (JTA) 1.0
JavaMail 1.3
JavaBeans Activation Framework 1.1
J2EE Connector Architecture 1.5
Web Services for J2EE 1.1
Java API for XML-based RPC (JAX-RPC) 1.1
Java API for XML Web Services (JAX-WS) 2.0
Java Architecture for XML Binding (JAXB) 2.0
SOAP with Attachments API for Java (SAAJ) 1.3
Java API for XML Registries (JAXR) 1.0
Java 2 Platform, Enterprise Edition Management API 1.0
Java 2 Platform, Enterprise Edition Deployment API 1.1
Java Authorization Service Provider Contract for Containers 1.0
Debugging Support for Other Languages (JSR-45)
Standard Tag Library for JavaServer Pages (JSTL) 1.1
Web Services Metadata for the Java Platform 1.0
JavaServer Faces 1.2 Requirements
Common Annotations for the Java Platform 1.0
Streaming API for XML (StAX) 1.0
Java Persistence API 1.0

The spec does not mention JSR 223 scripting integration, Service Data Objects, or the Work Manager API.

Awesome!! Can't wait, just finished reading EJB 3.0 spec. It definitely seems to be a much easier and elegant approach to developing enterprise apps!

"J2EE" Connector Architecture
Web Services for "J2EE "
"Java 2 Platform, Enterprise Edition"
"Java 2 Platform, Enterprise Edition "

So "J2EE" , "Java 2 platform" are official terms still used under Java EE . I thought theres no more "Java 2".

i think i am going to have to a tough time in near future, explaining to recruiting managers which edition / version of java i have worked on.

Regards
Surajeet

"J2EE" Connector Architecture Web Services for "J2EE ""Java 2 Platform, Enterprise Edition" "Java 2 Platform, Enterprise Edition "So "J2EE" , "Java 2 platform" are official terms still used under Java EE . I thought theres no more "Java 2".

Not all of the component JSR's that make up Java EE have been renamed, but they probably will be after Sun people read your post. :)

What's "Java Persistence API 1.0"?

What's "Java Persistence API 1.0"?

Its the "persistence" part of the EJB3 spec (CMP).

Java Message Service (JMS) still in 1.1 ? Aren't there lots of desirable things that the current spec does not define ?

What's "Java Persistence API 1.0"?

Look like "EJB3 pojo persistence" has been removed from EJB 3.0 to a separate API of its own.

What's "Java Persistence API 1.0"?

Look like "EJB3 pojo persistence" has been removed from EJB 3.0 to a separate API of its own.

So that it could work without application server, even in standalone applications.
It has its own package javax.persistence

Look like "EJB3 pojo persistence" has been removed from EJB 3.0 to a separate API of its own.

Maybe because it is not so coupled anymore with application server. Now we can unit test entity bean outside of container, or effectively us it in desktop applications. That's nice.

Look like "EJB3 pojo persistence" has been removed from EJB 3.0 to a separate API of its own.

Maybe because it is not so coupled anymore with application server. Now we can unit test entity bean outside of container, or effectively us it in desktop applications. That's nice.

That has always been the case for "EJB3 pojo persistence".

What's new here is a renaming of "EJB3 pojo persistence" to "Java Persistence API 1.0" or "JPA 1.0", is it not?

The problem is that "EJB 3.0 pojo persistence" has been sold for long to the developer community (a comminity initially opposed the PoJo persistence spec being part of EJB 3.0),
even the Java EE 5.0 committee will have to revert the name from "Java Persistence API 1.0" (or JPA 1.0) to "EJB 3.0 PoJo 1.0". :-)

A Persistence API that works only with RDBMS databases. Should not Java be portable? <<<Another lockin>>>

No.

which project you developped had as a requirement that it should be portable?

No. which project you developped had as a requirement that it should be portable?

I have an example. I have been working on programs that perform mathematical analysis for various scientific data. It would be very useful to have those programs able to the persist results of their analyses to a variety of stores, depending on the requirements of the users. These could include tables in a relational database, XML files, CSV files etc.

Fortunately I can use JDO for this.

Fortunately I can use JDO for this.

Now u can use new java persistence API for the same.

Fortunately I can use JDO for this.

Now u can use new java persistence API for the same.

I don't believe I can. JDO was designed to allow persistence to both relational and non-relational stores. EJB 3.0 is designed for relational systems only. If I am wrong about this, and JDO/EJB 3.0 convergence now means that EJB 3.0 is more general-purpose I would be very interested!

If I am wrong about this, and JDO/EJB 3.0 convergence now means that EJB 3.0 is more general-purpose I would be very interested!

I'm interested in knowing more about this too.

I don't know a lot about JDO, so maybe my question will seem off the wall, but here goes. Would it be possible for a JDO implementation to support EJB3 spec? I understand that a big part of what people think of JDO are the user facing API's, but if there is a JDO implementation out there that has very flexible back-end persistance options it seems that they could gain more marketshare by supporting java.persistance.* too.

I think that Patrick Linskey from SolarMetric is on the EJB3 group? It would be interesting to heard form him on this.

Patrick, are you there? Any thoughts on this?

I'm interested in knowing more about this too.I don't know a lot about JDO, so maybe my question will seem off the wall, but here goes. Would it be possible for a JDO implementation to support EJB3 spec?

My understanding is that almost all current JDO implementations are going to do exactly this, as the specifications are pretty close in many ways. You will be able to use JDO 2.0 and EJB 3.0 at the same time on the same objects in the same application.

My particular interest is as to whether EJB 3.0 alone can be used to persist to more than relational stores.

My particular interest is as to whether EJB 3.0 alone can be used to persist to more than relational stores.

Any data access or connectivity API including JDBC or ODBC can be used as adapter or bridge (there is ODBC adapter implemented on top of EJB itself to integrate EJB with VB). I think EJB is designed for RDBMS in the same way as JDO is designed for OODBMS.

My particular interest is as to whether EJB 3.0 alone can be used to persist to more than relational stores.

Any data access or connectivity API including JDBC or ODBC can be used as adapter or bridge (there is ODBC adapter implemented on top of EJB itself to integrate EJB with VB). I think EJB is designed for RDBMS in the same way as JDO is designed for OODBMS.

JDO is not designed for OODBMS. I don't know where you picked up that piece of misinformation. JDO is store neutral. It works equally well with OODBMS, RDBMS and other forms of persistence. The main use of JDO today is with relational stores.

Both JDO and EJB are store neutral in the same way as JDBC or any data access API. I can paste link to JDBC implementations for OODBMS too, but I am sure you know it yourself. So JDBC is designed for OODBMS in the same way as JDO is designed for RDBMS.

Both JDO and EJB are store neutral in the same way as JDBC or any data access API.

No. To quote from the JCP website:

"JDBC is a Java API for executing SQL statements"

Hardly store neutral!

I can paste link to JDBC implementations for OODBMS too, but I am sure you know it yourself.

Please post such links - I would be interested. They don't mean that JDBC was designed for this - they only mean that an OODBMs may allow some small subset of SQL to work.

So JDBC is designed for OODBMS in the same way as JDO is designed for RDBMS.

No, because JDBC is basically a pass-through API for executing SQL and handling the results. This is fundamentally different from JDO, which allows a guaranteed full and rich API and query language on a range of stores, even (if the implementation provides is) CSV files and XML stores. But of course, I'm sure you already know this as we have covered this in detail in other threads.

SQL is store neutral, it is just a query language.

BTW this is a link to FAQ
http://www.versant.com/resources/faqs/faq_vsql.html

SQL is store neutral, it is just a query language.

It is, of course, not neutral. From wikipedia:

"SQL is the most popular computer language used to create, modify and retrieve data from relational database management systems"

BTW this is a link to FAQhttp://www.versant.com/resources/faqs/faq_vsql.html

Sorry, but this isn't SQL. It is a language that provides an SQL-like dialect.

I do hope you aren't going to try and argue that we should all use some hypothetical 'portable SQL' as a universal way of accessing all data stores...

Probably some vendors fail to implement SQL and probably same vendors fail to implement JDO too, but Versant claims "The version of standard it support is SQL/92" (I think SQL 92 is not so bad too) and this fact doe's not make SQL or JDO not portable.
JDOQL is based on object model. Using your analogy JDOQL is OODBMS specific, but as we all know JDOQL is store neutral. SQL is not RDBMS specific too, it is just based on relational model in the same way as JDOQL is based on object model.

Probably some vendors fail to implement SQL and probably same vendors fail to implement JDO too,

No. If they fail to implement JDO, it's not JDO. This is not a comparable situation to SQL, where a huge range of incompatible languages call themselves 'SQL'.

We have already discussed this in detail in previous threads.

SQL is not RDBMS specific too, it is just based on relational model in the same way as JDOQL is based on object model.

JDOQL is not based on an object model. It is simply a querying language that has a Java-like syntax.

SQL is store neutral, it is just a query language.BTW this is a link to FAQhttp://www.versant.com/resources/faqs/faq_vsql.html

SQL assumes a relational store, it is unsuitable for hierarchical or less structured stores (OODBs, XML files).

Why it is unsuitable for less structured stores ? Just less structured stores are unsuitable for data.

Why it is unsuitable for less structured stores ? Just less structured stores are unsuitable for data.

Better tell CERN that. They use relatively unstructured OODBs to handle petabytes of data.

Why it is unsuitable for less structured stores ? Just less structured stores are unsuitable for data.

Better tell CERN that. They use relatively unstructured OODBs to handle petabytes of data.

CERN can find the best database without my help.
BTW Aree they going to use JDO to port this stuff to RDBMS ?

It was a joke, but it looks like CERN realy has this dealema:
"Faced with such a dilemma, the inescapable conclusion is that we need to build a system ourselves"
http://wwwasd.web.cern.ch/wwwasd/rd45/presentations/ecoop99/ecoop-paper.html

It was interesting to read how CERN uses OODBMS technology, thanks.

It was a joke, but it looks like CERN realy has this dealema:"Faced with such a dilemma, the inescapable conclusion is that we need to build a system ourselves"http://wwwasd.web.cern.ch/wwwasd/rd45/presentations/ecoop99/ecoop-paper.htmlIt was interesting to read how CERN uses OODBMS technology, thanks.

The point of mentioning CERN was to illustrate that relational databases are not a universally appropriate way to handle data, and are not required to guarantee data integrity.

A Persistence API that works only with RDBMS databases. Should not Java be portable? <<<Another lockin>>>

Guess they've gazed a bit too long at Hibernate instead of folllowing the broader, independent path JDO shows us. (JDO being DS indept e.g.)

No matter, as soon as even more JDO implementations start supporting Object DBs, XML (to FileSystem) etc, (aside from RDBMS) the market will understand even more its value (having one API for all this!) and decide once again, like they have this time. (already now Spring & JDO are a killer combo)
Then you'll see Sun come with new promises for EJB X.0 again "that will solve all those issues". Yeah Right. :-)

this is not news. Most anything is better. Has that changed?

I think groovy, ibatis and jdnc are best parts of Java.
.V

Seems there is nothing in Java EE 5.0 so far to cure the monolithic server syndrom used to exist in J2EE. The Java EE 5.0 servers will even become more bloated (with new APIs such as JSF and JPA 1.0 etc becoming mandatory).

To save Java EE, server side "plug and play" needs to be intoduced into the spec so that Java EE 5.0 servers will no longer be required to implement every single API in the spec (only the core APIs). The problem with this approach is that it will generate less license fee for Sun, or no license fee at all?

Seems there is nothing in Java EE 5.0 so far to cure the monolithic server syndrom used to exist in J2EE. The Java EE 5.0 servers will even become more bloated (with new APIs such as JSF and JPA 1.0 etc becoming mandatory). To save Java EE, server side "plug and play" needs to be intoduced into the spec so that Java EE 5.0 servers will no longer be required to implement every single API in the spec (only the core APIs). The problem with this approach is that it will generate less license fee for Sun, or no license fee at all?

Removing these files will just save you a few megs of HDD space. A few megs of appserver install won't make much difference to anyone. Besides, I like the fact that any certified app server will support all the APIs I need.

Why Java Business Integration is not added to Java EE 5? How about JSR94 (Rule Engine)?

Could someone from JSR explain?

We alredy have JDO, Entity beans, Hibernate, Coherence etc. So,what's the need for persistence api. what's that going to add?. I think it will make tougher to decide between these and you finally endup choosing DAO.

We alredy have JDO, Entity beans, Hibernate, Coherence etc. So,what's the need for persistence api. what's that going to add?. I think it will make tougher to decide between these and you finally endup choosing DAO.

There's lots of different persistence technologies in Java because there's no such thing as the "perfect choice" for all applications.


DAOs are another matter - that is an architectural/best practice decision - DAOs can and should be used with any of the APIs (JDO, JDBC, EJB 3.0 persistence, etc).

If fact, using DAOs mean that you can switch the underlying persistence API/technology without affecting the rest of the application.


 PJ Murray

CodeFutures Software

Code Generation for Java Persistence

POJO + Annotations = EJB (I like it)
JSP + JSF = ??? (Mangled presentation layer)