Java Data Objects (JDO) Spec Lead Craig Russell of Sun has announced the public availability of the JDO 1.0 spec, reference implementation and test compatibility kit. JDO defines standard API's for storing plain Java objects persistently in transactional data stores. JDO's can be used at any tier, and integrate well behind a Session Facade.

Download the JDO 1.0 Specification, the Reference Implementation, and the Technology Compatibility Kit (registration required for these links).

Also check out the announcement on JDOCentral.com, and Craig's JDO Announcements Page

Heiko.

Glad it's finally here. Kudos to the JDO team for a job well done.

Some questions, tho: anybody know what happened to the JDBC implementation?

From Craig's page: "The JDO reference implementation is being developed with two variants [...file store... and] SQL storage. This variant stores persistent instances in a relational database using JDBC as the underlying persistence mechanism".

While the filestore implementation looks good it's going to be a lot more interesting to point a JDBC implementation at an existing datastore.

The "Items deferred to the next release" shows that there is some good stuff still to come:

- no nested transactions
- no blob or clob support (is there ever blob or clob support in a first release of anything besides oracle drivers?)
- readonly fields (performance impact?)
- prefetch api (no bulk loads?
- ...

I went to http://java.sun.com, expecting a front page announcement that the JDO spec, RI and TCK is now out... Nothing.

Similarly, when the vendors ratified the JDO spec a few weeks ago... nothing.

Can anyone enlighten me on what JavaSoft's position is on JDO. Why do they seem to not be supporting it as publicly as they could, given how important JDO will be?

Cheers,
Ian

---
Ian Daniel
Lead Developer and Training Specialist
Left Brain Right Brain Pty Limited
Phone: +61 2 9712 0234, Mobile: 0417 024 837
Web: http://www.LeftBrainRightBrain.com.au

It's good to hear that thing,I am working for a software company and we are developing a large management software,during the development,I realize the session/entity bean with BMP based on JDBC has a lot of work to do to make the data persistent,so many code to write,I am tired.so with the release of the specification, we hope the verdor give a good implements quickly,and the expert give some good instruction in the web,thaks.

Yuguisuo
Beijing china

Hi
Can anyone explain where does JDO stand in an EJB based system, because the local Interface will solve the issue of the overhead of remote calls or will SUN ultimately replace Entity beans with JDO's...

this has been explanined in other threads in great detail. For example, have a look here:
https://theserverside.com/discussion/thread.jsp?thread_id=771
(its linked on the TSS front page). Basically, JDO allows you to make any object persistent without having to implement multiple interfaces/classes, callbacks and the like. It also supports essential object-oriented features like inheritance and polymorphism. Of course, it can easily be integrated with session beans for remote callability and automatic transaction management.

regards,
Chris

> you to make any object persistent without having to
> implement multiple interfaces/classes, callbacks and the
> like.

Actually this isn't true, you do need special interfaces
and callbacks with JDO, but you can let a bytecode
mutilator do it for you if you don't want to code it
yourself into the object models. It's one of the
major flaws of the

True Transparent persistence is something like CocoBase
that uses Java facilities and doesn't actually require
any bytecode manipulation or object model inheritance
changes. The current JDO implementation took too many
assumptions from Microsoft ADO & ODMG which are largely
C/C# limited without a real JVM. In the JVM world, there's
no need to do bytecode invasive designs to achieve
transparent persistence, and in fact they limit the
useability of an object in both distributed and enterprise
deployment because the instance is self aware of its
changes, and therefore can only exist in one tuple space
at a time. This becomes a VERY important issue in a
replicated or heterogeneous environment...

Oh well - there's always hope for a 2.0 fix :)

> It also supports essential object-oriented features like
> inheritance and polymorphism. Of course, it can easily be
> integrated with session beans for remote callability and
> automatic transaction management.

Yes, but the automatic transaction management was defined
in a way that it interferes with integration into app
servers. Once again CocoBase by contrast works with almost
30 app server versions from a variety of vendors.

Also it doesn't support many key features such as Blob/Clob
interfaces, integration with distributed environments
(developers are expected to write their own distributed
facades), etc. If you look at the CocoBase Transparent
Persistence system, a developer can run the same object
model locally or in a J2EE app server using our Generic
Session bean facade just by changing a connection parameter.
No Session bean programming, no code of Entity beans,
and complex object models, centralized O/R mapping
repositories, etc. And the facade apis are significantly
more streamlined and easy to use than JDO.

Customer c = new Customer();
c.setName("My Customer");
Customer cust = cbfacade.load(c, "Customer");
Vector orders = cust.getOrders(); // automatic lazy loads
Order o = (Order)orders.elementAt(0);
Vector orderlines = o.getOrderlines(); // automatic lazy
Orderline ol = (Orderline)orderlines.elementAt(0);
ol.setDetail("New Detail");
cbfacade.save(cust, "Customer"); // Only changes are issued

This will automatically detect any changes in the graphs
and save them. You can also make a couple of lines of
changes in the facade and have this all magically occur
with cbfacade.commit(), but many times customers need
more concrete control over particular object models, so
this more explicit API is typically more useful...

Anyway, I can't wait until sun does an update to JDO with
O/R mapping support, and REAL object types, but in the
meantime products like CocoBase offer dynamic transparent
persistence with no waiting.

Oh and in case you hadn't heard, the Forte JDO TP
implementation has been discontinued, and CocoBase is
the recommended TP replacement. You might want to give
it a try, it delivers all of those 'future promises' of
the spec - today... Not to mention the fact that our
entire deployment runtime archive is less than half of
the size of JDO Reference implementation, and this includes
the support for local and distributed persistence,
integration with standard app servers and, runtime map
creation, full JDBC 2.0 type support, stored procedures
support, extensible caching, change event system,
distributed lazy loading, and a host of other features...

Our guys are still looking at ways we could use the JDO
APIs with CocoBase, but we're not convinced customers are
willing to give up so many features to have compliance
with an incomplete 1.0 spec. I'm always open to hearing
customer feedback however :)

Just my $.02
Ward Mullins
CTO
THOUGHT Inc.
http://www.thoughtinc.com

EJBs are not scalable. My clients are converting from EJB to ... roll your own beans that use SQL.
JDO ... does not use SQL and it will be not much better than EJBs.
Sun is losing credibility with this "you do not need to know SQL". You do need to know SQL! to build large volume high performance sites.
I think EJBs is a major reason companies are switching to MS .NET, since there were oversold. EJBs helped Sun sell HW becuase they are so slow, but that's over.

Best thing for Java is everyone started understanding that the slow part of a JAVA web site is DB, and hence SQL.
So RowSets with full SQL strings have worked for me in production. Before everyone goes to ADO and .NET, consider roll your own beans that are based on ANY valid SQL string.

For scalability, you should avoid JDO.

Vic@baseBeans.com

> SQL". You do need to know SQL! to build large volume high
> performance sites.

I second your statement. The theme seems to be

- Use whatever data source (RDBMS, file system, XML DB, ERP or any EIS)
- Let the container manage the persistence magically
- Developers don't have to tell the container (or whatever manages persistence) what the usage patters are.

Atleast that's what the opening paragraphs in both the spec and other articles appeared elsewhere start with.

I think there are some fundamental flaws in such a theme:

- One can't possibly create such a "generic" abstraction to transperantly manage persistence. The more abstract the contract is, the less useful the abstaction becomes. There is no magic here.

- Without any clue on how a persistent object (CMP/JDO) is used at run time, it is very difficult for the container to optimize the persistence mapping. Theoretically it may be possible to derive such information statically or dynamically, but that only increases the complexity of the problem and the solution.

Subbu

> SQL". You do need to know SQL! to build large volume high
> performance sites.

I second your statement. The theme seems to be

- Use whatever data source (RDBMS, file system, XML DB, ERP or any EIS)
- Let the container manage the persistence magically
- Developers don't have to tell the container (or whatever manages persistence) what the usage patters are.

Atleast that's what the opening paragraphs in both the spec and other articles appeared elsewhere start with.

I think there are some fundamental flaws in such a theme:

- One can't possibly create such a "generic" abstraction to transperantly manage persistence. The more abstract the contract is, the less useful the abstaction becomes. There is no magic here.

- Without any clue on how a persistent object (CMP/JDO) is used at run time, it is very difficult for the container to optimize the persistence mapping. Theoretically it may be possible to derive such information statically or dynamically, but that only increases the complexity of the problem and the solution.

Subbu

Subbu

- Let the container manage the persistence magically
- Developers don't have to tell the container (or whatever manages persistence) what the usage patters are.

Marc: that's definitely not true. With JDO you don't put any database code in your source, but you have differents ways to tune and optimize how mapping is done and how SQL statements are issued.


- Without any clue on how a persistent object (CMP/JDO) is used at run time, it is very difficult for the container to optimize the persistence mapping. Theoretically it may be possible to derive such information statically or dynamically, but that only increases the complexity of the problem and the solution.

Marc: the fact is that JDO can probably save 50% development effort on 99% of your project code. For the remaining 1%, most (good) JDO implementations already provides several ways to tune the underlying DB access.

cheers,

I disagree.. if the persistence layer is well written why would you need to know SQL? It makes no sense.

Here comes Ward again.
My questions to ward as simple as :
* is there any good reason to work with Cocobase instead of working with the well-known leader on the O/R mapping market (TopLink)
* why paying the costly Cocobase instead of a free Castor, or almost free (excellent) MVCSoft
* is there any reason why Ward is always ranting JDO instead of entering the expert group and try to improve the standard ? From what I can see on the JSR pages WebGain (formerly known as TheObjectPeople, ie the TopLink guys) are participating to this standard.
* is there any reason why Ward seems to be so proud of its so-called Transparent Persistence that is far from being so Transparent (not even speaking about the thousands of proprietary lines you must write in the mapping files)

Ward: each time you speak in a forum you put a huge discredit on your company. Is there somebody at Thought that can turn him off ?

<quote>
Also check out the announcement on JDOCentral.com
</quote>

JDOCentral.com appears to be running on NT/W2K with IIS. I'd rather prefer to see it running on a 'friendlier' platform for java (e.g. Linux with Apache).