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.
-
Java Data Objects 1.0 Final Spec, RI and TCK Released (13 messages)
- Posted by: Heiko Bobzin
- Posted on: April 29 2002 08:27 EDT
Threaded Messages (13)
- Java Data Objects 1.0 Final Spec, RI and TCK Released by jamie mccrindle on April 29 2002 13:03 EDT
- Where is Sun's public support for JDO? by Ian Daniel on April 29 2002 20:14 EDT
- Java Data Objects 1.0 Final Spec, RI and TCK Released by yu guisuo on April 29 2002 21:28 EDT
- Java Data Objects 1.0 Final Spec, RI and TCK Released by Rajeev Jayaram on April 30 2002 02:18 EDT
- Java Data Objects 1.0 Final Spec, RI and TCK Released by Christian Sell on April 30 2002 03:47 EDT
-
Java Data Objects 1.0 Final Spec, RI and TCK Released by Ward Mullins on May 01 2002 09:42 EDT
-
Java Data Objects 1.0 Final Spec, RI and TCK Released by Vic Cekvenich on May 03 2002 02:07 EDT
- Java Data Objects 1.0 Final Spec, RI and TCK Released by Subbu Allamaraju on May 03 2002 04:35 EDT
-
Java Data Objects 1.0 Final Spec, RI and TCK Released by Subbu Allamaraju on May 03 2002 05:29 EDT
-
Java Data Objects 1.0 Final Spec, RI and TCK Released by Marc Noises on May 04 2002 02:48 EDT
- Java Data Objects 1.0 Final Spec, RI and TCK Released by Ian Pojman on May 06 2002 02:23 EDT
-
Java Data Objects 1.0 Final Spec, RI and TCK Released by Marc Noises on May 04 2002 02:48 EDT
- Java Data Objects 1.0 Final Spec, RI and TCK Released by Marc Noises on May 03 2002 04:15 EDT
-
Java Data Objects 1.0 Final Spec, RI and TCK Released by Vic Cekvenich on May 03 2002 02:07 EDT
-
Java Data Objects 1.0 Final Spec, RI and TCK Released by Ward Mullins on May 01 2002 09:42 EDT
- Java Data Objects 1.0 Final Spec, RI and TCK Released by Christian Sell on April 30 2002 03:47 EDT
- Java Data Objects 1.0 Final Spec, RI and TCK Released by One Way on May 01 2002 00:58 EDT
-
Java Data Objects 1.0 Final Spec, RI and TCK Released[ Go to top ]
- Posted by: jamie mccrindle
- Posted on: April 29 2002 13:03 EDT
- in response to Heiko Bobzin
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?
- ...
-
Where is Sun's public support for JDO?[ Go to top ]
- Posted by: Ian Daniel
- Posted on: April 29 2002 20:14 EDT
- in response to jamie mccrindle
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
-
Java Data Objects 1.0 Final Spec, RI and TCK Released[ Go to top ]
- Posted by: yu guisuo
- Posted on: April 29 2002 21:28 EDT
- in response to Heiko Bobzin
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 -
Java Data Objects 1.0 Final Spec, RI and TCK Released[ Go to top ]
- Posted by: Rajeev Jayaram
- Posted on: April 30 2002 02:18 EDT
- in response to Heiko Bobzin
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... -
Java Data Objects 1.0 Final Spec, RI and TCK Released[ Go to top ]
- Posted by: Christian Sell
- Posted on: April 30 2002 03:47 EDT
- in response to Rajeev Jayaram
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 -
Java Data Objects 1.0 Final Spec, RI and TCK Released[ Go to top ]
- Posted by: Ward Mullins
- Posted on: May 01 2002 21:42 EDT
- in response to Christian Sell
(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.
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 -
Java Data Objects 1.0 Final Spec, RI and TCK Released[ Go to top ]
- Posted by: Vic Cekvenich
- Posted on: May 03 2002 02:07 EDT
- in response to Ward Mullins
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 -
Java Data Objects 1.0 Final Spec, RI and TCK Released[ Go to top ]
- Posted by: Subbu Allamaraju
- Posted on: May 03 2002 16:35 EDT
- in response to Vic Cekvenich
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 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 -
Java Data Objects 1.0 Final Spec, RI and TCK Released[ Go to top ]
- Posted by: Subbu Allamaraju
- Posted on: May 03 2002 17:29 EDT
- in response to Vic Cekvenich
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 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 -
Java Data Objects 1.0 Final Spec, RI and TCK Released[ Go to top ]
- Posted by: Marc Noises
- Posted on: May 04 2002 02:48 EDT
- in response to Subbu Allamaraju
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, -
Java Data Objects 1.0 Final Spec, RI and TCK Released[ Go to top ]
- Posted by: Ian Pojman
- Posted on: May 06 2002 14:23 EDT
- in response to Marc Noises
I disagree.. if the persistence layer is well written why would you need to know SQL? It makes no sense. -
Java Data Objects 1.0 Final Spec, RI and TCK Released[ Go to top ]
- Posted by: Marc Noises
- Posted on: May 03 2002 04:15 EDT
- in response to Ward Mullins
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 ? -
Java Data Objects 1.0 Final Spec, RI and TCK Released[ Go to top ]
- Posted by: One Way
- Posted on: May 01 2002 00:58 EDT
- in response to Heiko Bobzin
<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).