What do you think of this perspective, backed by Sun? Agree, disagree? Chime in with your perspective.
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 57 of 57.

• query about data persistancy in SWT with db4o
  2005-09-14 07:25:32  vin32001 [Reply | View]
  
  
  how can i persist data using db4o in SWT, when the window is closed than data should not be removed, how to use onclose condition.

• I won't buy David Jordan's book
  2003-02-03 13:28:20  anonymous2 [Reply | View]
  
  
  If David Jordan must resort to mud slinging and slander to promote his book and his consulting services, I, for one, want NO part of it. I just love it when people demonstrate their true colors.
• I won't buy David Jordan's book
  2003-04-18 12:26:28  anonymous2 [Reply | View]
  
  
  Thank you for demonstrating your true colors mister Anonymous.
  
  At lest my true colors are anonymous.

• Talk about false advertising
  2003-01-24 16:38:23  anonymous2 [Reply | View]
  
  
  At first it seems that perhaps Mr. Jordan's pride is hurt because another project has chosen to "incorrectly" implement his pet standard (the JSR-12 JDO.) But then he readily admits that Castor was using the name JDO first. At least before there was any public draft of JSR-12, and he claims Exolab could not have seen it beforehand.
  
  He also admits that Sun does not dispute Exolab's use of the acronym JDO. While anyone can see that there is potential for confusion, it is difficult to understand Mr. Jordan's vitriol over their use of the name (possibly not so difficult to usenet veterans.)
  
  Which is all within his right, but then he goes on to claim that Castor JDO is "proprietary" and implies that if you use it you will be locked in by a "single vendor." Such irrational statments do not usually turn up, even in usenet flame wars until shortly before Godwin's Law is invoked. But then, in the last sentence, we see the where Mr. Jordan's line of reasoning is going:
  
  "You should consider one of the many commercial implementations now available"
  
  It turns out that he is advocating (due, no doubt to his vested interest) proprietary solutions --yes, JSR-12 compliant, but proprietary nonetheless-- over an open source one.
  
  Talk about false advertising

• Rather than complaining
  2003-01-08 08:50:50  anonymous2 [Reply | View]
  
  
  ... You'd do better to help Exolab with their product by providing a real life project data, performance measurement, and other useful constructive criticism.
  
  

• Best marketing practices, not
  2002-12-17 05:51:14  anonymous2 [Reply | View]
  
  
  Software and Infrastructure Software in particular has proven to have one of the worst marketing practices possible, trying to sway flocks of developers towards the promised land of free for all, better, super, duper, ultimate ... crap.
  
  I find it very refreshing that someone has the guts to show the mechanisms of shameless marketers which eventually serve no purpose except bring complete confusion to the market and level off this same market from the bottom.
  
  Having been involved in BPMI.org and BPML, I find it very interesting that the same people that developed Castor and BPML/WSCI, use the same techniques to position their cruds on top of the heap.
  
  thanks david, this work is very important to bring back the discussion at the level of technical merits and stop the confusion.
  
  Jean-Jacques Dubray

• JDO thoughts
  2002-12-17 01:02:26  anonymous2 [Reply | View]
  
  
  I've spent a lot of time keeping tabs on object persistence technology options over the last few years. I've examined, at various times, almost all of the products/technologies mentioned in previous posts. I don't imagine I'm unique in that respect. Here are some thoughts:
  
  - I had no trouble distinguishing Castor JDO and Sun JDO. Anyone seriously considering either technology would discover their non-equivalence in short order. It seems like a mildly unfortunate naming conflict, whatever the reason.
  
  - Different software, even different parts of a single software project, will have diverse requirements and characteristics regarding object persistence. Scaling requirements, transactional behavior, data structure complexity, hardware environment, programming skills, all sorts of other things, will differ, sometimes dramatically, from each other. There is room for many approaches to co-exist.
  
  Saying, for instance, that because Castor uses "slow" reflection, and is therefor less desireable, is making stupid assumptions about the speed requirements of all data persistence problems.
  
  - After reading the JDO spec, and other available JDO material from Sun and others, my feeling is that, while JDO is interesting, and may even become the only sensible option in many situations, it has suffered greatly by clearly being designed in part by a commitee of existing middleware tool vendors, each of whom needs to ensure their existing product's viability.
  
  Designing by committee is a challenging process in the best of situations, adding in the commercial interests of a dozen vendors, many of whom have VERY expensive enterprise relational mapping software packages and corresponding business models, seems like a bad idea. In fact, I'm surprised that JDO turned out as well as it did, and I don't doubt there was a lot of sincere effort put into it- it shows. But the relationship to pre-existing vendor products also shows.
  
  JDOCentral, the "Developers community for Java Data Objects", mentioned in a previous post, also reflects this unfortunate focus on the middleware/tools vendors who participated in the spec-writing. It has a strong smell of "fake-community". It's not all that bad, but it doesn't even bother to hide it's commercial connections, and it's clear use as a marketing tool for those same vendors.
  
  - JDO, like J2EE/EJB, suffers from requiring what often seems like a bit too much of architectural buy-in on the part of developers. Part of this comes from the requirements of playing in the Sun technology sandbox. APIs that make it through the various JCP/JSR wringers tend to not end up as a-la-cart as they might otherwise be.
  
  Sun's desire to avoid angering tools-vendors means that they do a little too much of the "here's a spec, you'll have to pay for a vendor implementation to do anything serious with it". Sure, it's nice to have designs reflect the seperation between interface and implementation, but I'd rather have them come with a basic but serious, solid implementation as a starting point, which is certainly and notoriously not the case with the JDO reference implementation, at least not when I looked at it not too long ago.
  
  - I'm glad that there are as many open-source and low-cost object persistence projects as there are. I don't see a need to create one spec to unify every persistence API out there. Even if one wanted to do such a thing, JDO certainly doesn't succeed.
  
  - I want to suggest an addition to previous posters' mentioned list of persistence APIs. Db4o is an interesting light-weight alternative object persistence framework. I find it interesting because it doesn't map object data to a conventional relational database like most of the other approaches. It, too, has it's quirks, but I wish the JDO team had demonstrated similar willingness to explore designs not based on the assumptions of years of legacy persistence products. it's at db4o.com. I have no relationship with them aside from having tried out their product.
  
  Back to work now, I guess...
  
  -Dave F.
  
  
  
• JDO thoughts
  2002-12-17 14:38:37  robin@ogilviepartners.com [Reply | View]
  
  
  Hi Dave F.
  
  Thanks for your input. I'm glad that the distinction between Castor JDO and JDO (JSR12) was clear to you and presumably to others that are "seriously considering either technology". I wish that everyone making decisions on persistence infrastructure adoption would exert the same due dilligence!
  
  I'd be genuinely interested in the areas you believe JDO suffers because of its "design by committee" origins. Of the vendors who currently market JDO-compliant products I can think of only two who had "pre-existing vendor products" at the time the spec was under consideration. Both of these are ODBMS manufacturers.
  
  On the Object-Relational side all of the companies currently marketing JDO-compliant implementations who were involved in the spec's evolution were created in order to provide JDO implementations, and had no substantial pre-JDO offering in that area. I'm not trying to be facetious here, nor am I guarranteeing that my analysis is correct, but I don't think there was substantial "pre-existing vendor product" bias. Unless you count SQL as one such influence.... Anyway I'd be interested in your (and others) comments.
  
  Of course Sun Microsystems has Forte Transparent Persistence, support for which was dropped as JDO approached specification maturity. I think Forte Transparent Persistence formed a useful technology base from which JDO was grown, rather than Sun exerting any undue influence to steer JDO in its own direction. Once again I might have missed something, I suppose.
  
  As for JDOcentral, it is quite unashamedly sponsored by the JDO vendor community (see the "Steering Committee" page, from "About JDOcentral". Thanks to this financial and directional input, evaluators and users of JDO have a useful forum in which discussions are regularly read and responded-to by experts in the field; some vendor-based and some (like myself) vendor-independent.
  
  Ok, I have a book to promote, so perhaps I'm not as neutral as I claim! At least I disclosed it up-front to this OnJava thread. And whilst it remains the only book dedicated to the topic it can certainly be said to be the best (and, I suppose, the worst!) one....
  
  Now that the spec has been published, Sun's marketing department is faced with quite a dilemma: how should JDO be positioned? Given the recent fuss and expense of EJB 2.0 and CMR, they are understandably careful of JDO's positioning regarding Entity Beans. Currently Sun says "Here is the API" but does not directly advocate its use in any specific architectural tier.
  
  From a JDO-based perspective, the choice to use JDO is reasonably clear in a Client-Server architecture or a Web-based one with no other reason to involve an Enterprise container. I say "reasonably clear" because you have correctly stated that one size does not necessarily fit all as far as persistence infrastructure middleware goes. I will claim JDO is an appropriate choice in "many if not most" of the above scenarios to leave some room for debate.
  
  Once you have an Enterprise container in the architecture, Entity Beans become an alternative. I've tried to highlight some of the pros and cons objectively in a sub-topic to this thread, but my posting has given rise to no subsequent debate, where I had expected substantial debate.
  
  Perhaps that's for another day....
  
  Kind regards, Robin.
  Robin M. Roos
  www.OgilviePartners.com
  
• JDO thoughts
  2002-12-18 01:29:47  anonymous2 [Reply | View]
  
  
  Robin-
  
  Well, of course I don't really know much about what really went on behind the scenes during the specification process for JDO. From checkin the JCP page for JDO, it seems like you were on the Expert Group panel, so I'd be curious to hear what that was like, from you.
  
  Again, from the the JDO JCP page on jcp.org, the JDO expert group includes the following list of large software companies, (many with pre-existing data persistence tools) forming the majority of the JDO Expert Group membership.
  
  IBM
  Ericsson Inc.
  Informix Software
  Oracle
  Rational Software
  SAP AG
  Sun Microsystems, Inc
  Silverstream Software
  IONA Technologies PLC
  Objectivity, Inc.
  Secant Technologies, Inc.
  Software AG
  Versant Corporation
  
  David Jordan, author of the above article, was Ericcson's representative.
  
  A quick overview of the JDOCentral Vendors include:
  
  FastObjects, Inc - "wholly owned subsidiary of Poet Software GmbH, Hamburg, founded in 1993"
  products include fully ODMG/OQL support in C++ and Java, as well as JDO - seem like mature products
  
  ObjectFrontier, Inc. - "ObjectFrontier was founded in 1997 with offices in Atlanta, USA and an R & D Lab in Chennai, India."
  They say " ObjectFrontier specializes in persistence management for enterprise applications, providing persistence engines, O/R mapping and caching solutions."
  Their earlier product: FrontierSuite J2EE version 3.0, new product: in FrontierSuite JDO
  
  SolarMetric Inc. - "is a global company with corporate headquarters in Washington, D.C., USA. [..] founded Solarmetric in 2001. The core technology team has been together since 1997"
  
  Versant, Inc. - "Since the company’s founding in 1988, Versant Corporation (NASDAQ: VSNT) has led the industry in providing highly scalable and reliable object management solutions for complex, enterprise-level systems."
  Previous product: Versant Developer Suite (VDS) 6.0, "is a 6th generation object database."
  
  Hemisphere Technologies and Libelis were founded in 1999 and 2000, respectively. I couldn't figure out when Object Industries was founded.
  
  
  Clearly, it is desireable to have a specification written by people who are experienced in the appropriate domain, and those people will often be involved in other, related businesses. The above list of Expert Group companies, however, seems like overkill with respect to simply ensuring that experienced viewpoints are part of the process, and seems dangerous with respect to the potential for biased architectural decisions.
  
  Again, it would be great to hear from you, Robin, your impressions of the JDO spec development process, in particular, why is it that the JDO reference implementation isn't as useful an implementation of the JDO spec as, for example, Apache Tomcat, the Servlet spec R.I. is a useful form of the Servlet spec. One hopes that it's just a matter of time, but...
  
  -David F.
  
  
• JDO thoughts
  2002-12-20 03:16:15  robin@ogilviepartners.com [Reply | View]
  
  
  Hello again David,
  
  Yes, I am a member of the JDO Expert Group. However my membership was only ratified about 6 months before JDO was submitted to JCP for final approval, at which stage the first Proposed Final Draft was already published. I had input on usability, from a non-Vendor's perspective, but the key architectural decisions had been bedded down by that stage. Someone who could give a better impression of any "undue influence" on these decisions would be David Jordan, author of the "Castor JDO - Simply False Advertising" article, as he was there from the beginning.
  
  Versant and FastObjects were the vendors I had in mind as having pre-existing products in the space. I'm not sure what FrontierSuite for J2EE comprised. The rest are companies which may, I suppose, have had experience implementing aspects of the ODMG spec in some past life!
  
  To be approved a JSR must provide the specification, the Toolset Compatibility Kit (TCK) tests, and a Reference Implementation (RI). The RI needs to be functionally correct so that it can be used by Vendors to identify the correct behaviour of an implementation.
  
  It happens that Tomcat is a reference implementation that is so good it is also widely used as a servlet container in real web applications. Unfortunately Sun Microsystems was going through the pain of the current downturn in IT revenues at the time that the JDO RI was being implemented. As a result the amount of resource dedicated to that project was significantly reduced. Finally, the presence of so many commercial implementations in Beta at the time the RI was under development meant that there was no scope for the RI to become the de-facto standard, even if additional resource had been made available.
  
  Hence we have an RI that is used by JDO Vendors to verify the functionality of their products, but which is generally not employed by JDO Users.
  
  Happy Christmas!
  
  Robin.
  Robin M. Roos
  www.OgilviePartners.com

• Re: On the contrary...
  2002-12-16 19:30:45  anonymous2 [Reply | View]
  
  
  I do not claim to know anything about ExoLab's legal infringement on Sun's trademarks. If ExoLab has crossed this line, then they are wrong.
  
  However, if you are suggesting that Sun has some inherited right to naming because they created Java, I think you should find something worthwhile to write about.
  
  In my opinion, Castor is accurately described as "Java Data Objects" and well represented by the JDO acronym. They explicitly indicate in their documentation and are very upfront that they are not compliant with the Sun JDO specification. If Sun wanted to carve out the name, they should have selected a more specific name than "Java Data Objects". This would be similar to Microsoft asking everyone with an xxxxx.net URL to change their domain name.
  
  Perhaps it would be different if Castor was claiming to be a Sun JDO implementation. Their product is open source and they would gain nothing from this. I think you should move on to a more valuable topic.
  
  

• "Castor JDO": Simply False Advertising
  2002-12-15 05:40:05  tksrajan [Reply | View]
  
  
  Apparently a lot of water has flown under Thames, since the David Jordan first looked at Castor and the writing of the above article.
  CASTOR does not support Sun's JDO standard and that probably saved it from obscurity.Castor like Hibernate,OJB( which proposes to implement the Sun's JDO) use Runtime Reflection very effectively to provide Object Relational mapping and it works perfectly.Infact, OJB uses a persistence broker layer which uses Runtime Reflection to support Sun's JDO and ODMG standards.Source and Bytecode enhancements are not ideas that the developer community will like very much
  
  I don't know ODMG standard , but Castors XML to Java Data binding is pretty cool and works like a peach. Can't say the same about their Object Relational Bridge ( I don't want to associate the JDO name with any one other than Sun).That can be improved. But I hope they do not implement the Sun's JDO spec.Rather, they should look at memory management issues and try to make their implementation leaner.
  
  One advice to all there looking for a tool that will map java objects to database table(s).If you want one, go ahead and build one yourself. It is not that tough. I have a version that I developed, which works pretty well. If you can keep your Attribute name and database column names the same( case does not matter), for most part you won't need any XML mapping as well.If you do, then you may use Castor XML( no kidding, this is a cool tool)
  
  Finally, why is it that Sun and their partners believe that SQL is difficult and we developers find it difficult to use? Why do they thrust languages such as OQL and EJB-QL on us when most of us are perfectly comfortable with SQL? In fact SQL syntax is very simple and as close to a natural language as it can get.The whole stuff is really a lot of hype and only makes things more difficult to an already hapless developer fighting obsolescense.
  
  Therefore, if you must use an Object to Relational Mapping tool, here is my preference, in theorder of greatest importnace
  
  1. Build one yourself and use good old SQL
  2. OJB(jakarta.apache.org/ojb/) - Use the
  Persistence Broker API
  3. Hibernate
  4. Castor - tread warily. Memory issues and
  problems with nested objects
  
  I am open to comments . My mail id is tksrajan@yahoo.com. You may also find what you see at this site interesting http://www.geocities.com/sundar_rajan_in/
  
• "Castor JDO": Simply False Advertising
  2003-05-04 19:59:40  tomdavies [Reply | View]
  
  
  You say:"Source and Bytecode enhancements are not ideas that the developer community will like very much". Why would people object to Bytecode enhancements?
  
  If you think that building an ORM yourself is easy, then you probably don't understand all the things which a JDO implementation can do for you:
  
  - transparency, due to persistence by reachability you don't need to explicitly make instances persistent.
  
  - support for inheritence.
  
  - management of relationships between instances, again transparently.
  
  - caching.
  
  I too have written a simple ORM, but I now use JDO extensively, and find that it saves a lot of effort.
  
  Tom
• "Castor JDO": Simply False Advertising
  2002-12-16 11:49:03  robin@ogilviepartners.com [Reply | View]
  
  
  Hi Sundar
  
  Firstly, thanks for posting under your own name instead of anonymously. It is easy for readers to dismiss the credibility of anonymous replies.
  
  I had a look at your site but found no "category" for object-relational mapping or relational database access. Are your views on this subject covered under another topic?
  
  SQL allows field-level access to data. As such it is a very efficient API, its only big drawback being the lack of syntax-checking available for SQL at java compile time, which itself is quite understandable.
  
  If you like working with SQL and believe it is no hinderence to your application development efforts you should probably continue to use it.
  
  However, if you feel that:
  1. Your SQL development is time-consuming, or
  2. Your home-grown infrastructure is not sufficiently flexible (e.g. lack of true polymorphism), or
  3. Your applications depend on the presence of a relational database when another paradigm may better suit some deployments (e.g. binary file, ODBMS, etc), or
  4. Your SQL infrastructure is making your domain model inflexible (field names matching column names, and classes not spanning multiple tables, would be prime examples), or
  5. Your SQL infrastructure is "castrating" your object model (value objects with little domain-specific behaviour, but lots of load-save-from-db behaviour), or
  6. Your SQL infrastructure requires developers to have a significant level of skill in (a) SQL and (b) your proprietary infrastructure, or
  7. Your application is based on an infrastructure known in detail by only one or two developers who might (a) leave or (b) make excessive wage demands (I put that one in for fun!)
  
  ...then you should consider JDO.
  
  JDO provides a standard infrastructure that:
  1. Is a standard, and
  2. Is widely implemented by vendors competing on Quality of Service, and
  3. Enables applications to be independent of data store paradigm (relational DB, object DB, etc.), and
  4. Still lets you use SQL if you wish (the Query interface lets you specify a query language other than JDOQL), and
  5. Provides "Transparent Persistence" - for more info read my book "Java Data Objects" in paperback or PDF, or email me, and
  6. Deploys in a client-server, web, or enterprise context, with all the scalability characteristics you'd expect (particularly on the web/enterprise tier), and
  7. Is really cool (I put that one in for fun too!).
  
  No-one said you must use JDO...but I suggest that those who employ JDO wisely will have strategic advantage in software development over competitors who do not, which could be cruicial in the current IT marketplace.
  
  And if you do choose the JDO standard, remember to exclude so-called "Castor JDO" from your evalautions! Ok, I think we've rammed that one home now ;-)
  
  Kind regards, Robin.
  Robin M. Roos
  www.OgilviePartners.com

• Castor JDO
  2002-12-15 05:18:25  anonymous2 [Reply | View]
  
  
  Apparently a lot of water has flown, since the Author first looked at Castor and the writing of this article.
  
  CASTOR does not support Sun's JDO standard and that probably saved it from obscurity.Castor like Hibernate,OJB( which proposes to implement the Sun's JDO) use Runtime Reflection very effectively to provide Object Relational mapping and it works perfectly.Infact, OJB uses a persistence broker layer which uses Runtime Reflection to support Sun's JDO and ODMG standards.
  
  I don't know ODMG standard , but Castors XML to Java Data binding is pretty cool and works like a peach. Can't say the same about their Object Relational Bridge ( I don't want to associate the JDO name with any one other than Sun).That can be improved. But I hope they do not implement the Sun's JDO spec.Rather, they should look at memory management issues and try to make their implementation leaner.
  
  One advice to all there looking for a tool that will map java objects to database table(s).If you want one, go ahead and build one yourself. It is not that tough. I have a version that I developed, which works pretty well. If you can keep your Attribute name and database column names the same( case does not matter), for most parm you won't need any XML mapping as well.If you do, then you may use Castor XML( no kidding, this is a cool tool)
  
  I am open to comments . My mail id is tksrajan@yahoo.com. You may also find what you see at this site interesting http://www.geocities.com/sundar_rajan_in/

• who should change name?
  2002-12-13 23:57:11  anonymous2 [Reply | View]
  
  
  Who's first? Castor Java Data Objects or Sun's Java Data Objects
  
  Duh!
• who should change name?
  2002-12-16 11:26:03  robin@ogilviepartners.com [Reply | View]
  
  
  It would appear that Exolabs changed from "Castor" to "Castor JDO" AFTER JSR12 had been accepted and work begun under the name "Java Data Objects (JDO)", but BEFORE JSR12 was actually standardized.
  
  Kind regards, Robin.
  Robin M. Roos
  www.OgilviePartners.com

• JDO vs Entity Beans
  2002-12-13 08:29:48  robin@ogilviepartners.com [Reply | View]
  
  
  "JDO vs. Entity Beans", now that's a sensitive and politically-charged topic.
  
  In an earlier message titled "Real Talk", Chester asked about comparisons between Entity Beans and JDO. I've put together a few thoughts.
  
  I'd be interested in having frank and objective discussions on the merits of the two technologies. My current opinion is that Entity Beans do not compete with JDO on most of the essential issues. However I'm not a CMR expert yet, and there may be places where CMR is more advanced than JDO. The moment these discussions start, however, they seem rapidly to become "heated".
  
  I've put down a list of points that I feel to be of significance. I've tried to be objective. Be aware, however, that this is necessarily a LONG post, and please read all of it before passing comment.
  
  My suggestions regarding the motivation of JDO for a project in the face of Entity Beans would be along the lines of:
  
  REMOTENESS
  
  Entity Beans were originally (EJB 1.1) remote components, and this was the root of many problems. J2EE design patterns advise against using Entity Beans remotely, so there is little benefit in their having remote capabilities. Now, with EJB 2.0, Entity Beans can support local interfaces as well as remote ones. This mitigates earlier performance concerns of remote invocation.
  
  JDO instances are not remote objects. They satisfy the requirements for persistent data in the JVM that employs JDO, and do not attempt to address other concerns.
  
  CACHING
  
  Entity Beans are cached by the application server. Advanced J2EE application servers support distributed caches with inter-cache messaging to prevent applications from receiving dirty data.
  
  JDO instances are cached by the persistence manager. Advanced JDO implementations support distributed caches with inter-cache messaging to prevent applications from receiving dirty data.
  
  COMPONENT COMPLEXITY
  
  Entity Beans are "complex" components involving two interfaces, one class and potentially a primary key class as well. This is in addition to the complexity of component-based service lookup through JNDI (e.g. ejb-references).
  
  JDO instances are objects that you have decided should be stored in databases. The source code does not have to implement any JDO-specific infrastructure interfaces. You must have a no-arg constructor, but it may be private if so desired.
  
  IMPLEMENTATION COMPLEXITY
  
  Entity Beans have to be written as entity beans. They must abide by certain contracts and conventions. These are embodied by the lifecycle-methods and implementation of the EntityBean interface. Conventions include public fields for data (CMP1) and abstract methods for data (CMP2), and others.
  
  With JDO, you can take an object you wrote yesterday (when you didn't think it needed to be persistent) and store it through JDO today. No JDO-specific design or coding is required (bar having a no-arg constructor that might be private).
  
  With JDO you can even take a class that is not persistence-capable and create a subclass that is.
  
  LOOKUP COMPLEXITY
  
  To use an Entity Bean you usually have to look up its Home Object through JNDI. Each class of entity bean has its own home object that must be looked up independently.
  
  To use a JDO instance you need access to a PersistenceManager, obtained from a PersistenceManagerFactory that is looked up from JNDI. However the PersistenceManager is good for all classes of JDO instance - no separate lookups for different classes of instance.
  
  POLYMORPHISM
  
  A big word for managers, but it should be clear to developers.
  
  Entity Beans are not polymorphic. They do not support inheritance in a meaningful way (inheritance of component interfaces is possible). The finder methods return instance of the Entity Bean class on which they are invoked, even though the data may conceptually pertain to a "subclass" thereof.
  
  It could be said that Entity Beans were conceived to represent the contents of a particular database table, and since relational tables have no concept of "subclasses" an equivalent concept is unnecessary in Entity Beans. However, techniques for mapping inheritance hierarchies to combinations of one or more relational tables are well known, as are the heuristics for using inheritance to best effect when building a model.
  
  JDO instances are polymorphic. What you get back is what you stored. If you store a subclass of Customer, then queries of the Extent of Customer will include the subclass, and the instance returned as part of the query result will be an "instanceof" the subclass. Queries can even be executed against the Extent of abstract classes; what you get back is a Collection of concrete subclasses matching the filter criteria.
  
  QUERY PATHS
  
  Entity Beans provide searching functionality through find methods. The parameterization and implementation of these query paths is expressed by the developer in terms of find method signatures and EJBQL queries. This cannot be changed after the component is deployed. Searching beans in a "new" way requires the developers of the entity bean components to implement support for the "new" query path.
  
  JDO provides a query language (JDOQL). Most O/R vendors also support SQL. These query languages return collections of instances. However the query path is chosen by the Application developer, and is not reliant on the provision of supporting query methods by developer of the domain object model.
  
  TRANSPARENT PERSISTENCE
  
  Entity Beans have their data Loaded from and Saved to the database at the discretion of the J2EE application server. Thus the client does not have to explicitly "load" and "save" the entity bean. However the client does have to "find" the entity bean first.
  
  JDO supports transparent persistence. This means that
  
  1. If you want to "save" a new object, which will not be referenced by any other persistent instance, then you call makePersistent() to do so. However this is not the usual case. Usually you add a new (transient) object to an already persistent instance (e.g. adding a new Order to an existing persistent Customer). The developer does not have to make the instance persistent; it will become persistent on commit. This is known as Persistence-by-Reachability. (There's no Entity Bean equivalent.)
  
  2. If you change an object and make it dirty these changes will be transparently made durable on commit. You never have to "save" an instance. (This is analogous to Entity Beans).
  
  3. If you navigate a reference (this.orderline.order.customer) JDO will load the appropriate instance from the database (the orderline, the order, the customer) if it's not already in the cache. (I believe Container-Managed Relationships (CMR) provides equivalent capabilities for Entity Beans where the relationships are to other Entity Beans and are appropriately declared.)
  
  TRANSACTIONALITY
  
  Entity Beans support Container Managed Transactions, by which transaction semantics are declared in the bean's deployment descriptor and may be changed without changing the source code of the bean. Entity Beans must execute within a J2EE application server, which provides these services.
  
  JDO instances can and usually do operate transactionally. The transaction management is XA-compliant, and can integrate with the J2EE UserTransaction if required. This allows JDO instances to be enrolled in the same transaction as any of your J2EE components (including Session/Entity/Message-driven beans).
  
  However JDO also facilitates non-transactional operation. More usefully, JDO supports the transactional operation of non-persistent instances (Plain old java objects that have their state rolled back in sync with transaction rollback). Entity Beans do not support this, although a similar effect can be achieved (but not transparently) with Stateful Session Beans and the SessionSynchronization interface.
  
  Finally JDO persistence managers support transaction demarcation outside a J2EE context if required. This is great for Web applications needing transactional data access but not wishing to involve an EJB tier. Thus you don't need a J2EE application server to use JDO as a persistence infrastructure.
  
  SECURITY
  
  Entity Beans allow authorization to be enforced on a per-method basis. The implementation is transparent to the bean, based on properties set in the deployment descriptor.
  
  JDO does not have an analogous mechanism.
  
  SESSION FACADE
  
  Usually, Entity Beans are fronted by Session Facade objects that handle transaction demarcation and method-level permissions. JDO instances can also be fronted by Session Facades in the same way.
  
  REUSE
  
  With Entity Beans you can only achieve reuse if all applications seek to manipulate persistent data through the EJB container. Session Beans and Servlets/Custom Tags that go direct to the database bypass the entity bean and reduce the reuse of Entity Bean components.
  
  JDO instances can be used components within a J2EE application server, or without one by Servlets/Custom Tags, by command-line command-line Java applications, and by Client-Server Swing/AWT/SWT applications. This variety of deployment options massively improves reuse.
  
  OBJECT MODEL
  
  ** this section strays towards the subjective, but is an important point never-the-less **
  
  Traditionally, usage of Entity Beans has caused developers to create mere Value Objects (entity beans) that manage persistent state, whilst putting behavior relevant to that state into one or more Session Facade (Session Bean) components. This is not mandated by J2EE, but is my personal experience of consulting in the field.
  
  Object Orientation says Objects have State and Behavior. By putting the state into one component (the Entity Bean), and the behavior in another (the Session Bean), object orientation is compromised. This in turn affects the reusability of components.
  
  JDO abstracts developers, designers and architects from the complexities of object persistence. Relationships of arbitrary complexity can be managed transparently. Thus we can now build object models where objects have State and Behavior. Such objects are inherently reusable.
  
  CONCLUSION
  
  This is an emotive topic and personally I have a reputation for "not liking" Entity Beans. However I have tried to be as objective as possible. I also admit to not being an expert as far as CMR is concerned. Where CMR affects the points I have raised I would like to know, to further my own expertise and provide better clarification to readers.
  
  So, I've said my piece. What do you all think?
  
  Kind regards, Robin.
  Robin M. Roos
  www.OgilviePartners.com
  
  

• Ant, XDoclet and bytecode enhancement
  2002-12-11 08:41:48  robin@ogilviepartners.com [Reply | View]
  
  
  A previous anonymous poster commented regarding enhancement:
  
  [QUOTE]
  However, most seasoned programmers will cringe over class mutilation (or implementing PersistenceCapable manually).
  [/QUOTE]
  
  Personally I agree that manually implementing PersistenceCapable would be an unlikely choice, although people should never-the-less know that they have that choice.
  
  In my experience, perfectly seasoned and rationally-minded developers are actually taking the other approach. I've seen clients with complex systems gaining great productivity benefits through the combination of Ant, XDoclet and bytecode enhancement.
  
  They put XDoclet comments into their domain classes which identify the persistence descriptor information relevant to that class. (Usually the defaults are fine, but the number of items grows if you're overriding default persistence attibutes, identifying persistence-capable superclasses, or specifying the O/R mapping to an existing relational schema) By locating these structured comments in the actual java source file for each class the information is more readily changed as the class evolves.
  
  The Ant build script then includes a step to run an XDoclet task which parses the source code and builds the persistence descriptor XML file.
  
  Finally, after Ant has done the compilation steps, it invokes the JDO enhancer, generating enhanced classes into a different directory structure from the location of the un-enhanced .class files.
  
  Although a build structure such as this is non-trivial to establish, it results in a high degree of developer productivity.
  
  One more thing about enhancement: remember that enhanced classes share the same "serialveruid" value as their un-enhanced counterparts. This means that is is possible to serialize instances of enhanced classes from one VM into another (client?) VM where only the un-enhanced classes are available. If you have manually implemented the PersistenceCapable interface, or used an automated source-code enhancer (as opposed to a bytecode one), then you will not have this deployment flexibility.
  
  Kind regards, Robin.
  Robin M. Roos
  www.OgilviePartners.com

• Stealing the name
  2002-12-11 06:51:23  anonymous2 [Reply | View]
  
  
  The Java Data Objects JSR-12 Call for Experts
  went out in June 1999 and the expert group was
  formed and had their first meeting in August 1999.
  At that time, Exolab was using the ODMG name for
  their Castor tool. But when word started spreading
  about Java Data Objects (JDO), they switched their
  Castor product to use the JDO name, but this
  occurred after Sun announced they would use JDO
  as the name of the JSR-12 API in June 1999.
  When Exolab started using the JDO name,
  several people contacted them and asked them to
  refrain from using the JDO name, but they refused.
  
  David's article is not criticizing Castor on
  a technical basis. He is just addressing the
  confusion that has existed in the market as a
  result of Exolab using the JDO name, which
  they definitely stole after the fact.
  
  Exolab's use of the JDO name is like a street
  merchant with an armful of cheap wristwatches
  claiming to have Timex watches for sale real cheap.
  

• On becoming persistence-capable
  2002-12-11 04:55:12  robin@ogilviepartners.com [Reply | View]
  
  
  This may be the first of several messages I write here, so let me begin by saying I'm Robin Roos, author of the book "Java Data Objects" and a member of the JSR12 (JDO) Expert Group. My services portfolio includes vendor-neutral JDO training and consultancy, alongside more "traditional" J2EE equivalents.
  
  Now that I've declared my interests up-front, let's talk about JDO.
  
  David Jordan's commentary is certainly what might be called "spirited". That aside, it serves an important purpose. There is a new standard - JDO (JSR12) - which a lot of people have associated with the product "CastorJDO". The term "JDO" certainly appears regularly on the index page at http://castor.exolab.org/ so this confusion is understandable.
  
  It is unhelpful for JDO (JSR12) that this branding confusion exists, although resolution is only likely if the Exolab Group decides of its own vollition to rebrand their existing product....
  
  Suffice it to say that CastorJDO and JDO (JSR12) differ in such substantive ways as to make direct comparison largely irrelevant. This can be expanded upon in separate message threads if required.
  
  BECOMING PERSISTENCE-CAPABLE
  
  On the bytecode enhancement front, users of JDO (JSR12) are not under any obligation in this regard. If you wish, you may code your class to implement the javax.jdo.spi.PersistenceCapable interface. You must then provide the concrete method implementations required for support of the interface. The fact that these are entirely predictable and inherently boring to implement makes bytecode enhancement my preferred approach. But you do have the choice.
  
  On a final note, and at the risk of confusing the thread, we have Java Generics coming down the track (JSR14, in which I am not directly involved). This will introduce new language elements, so that a Vector known to contain only instances-of Customer, could be declared as:
  
  Vector<Customer> customers;
  
  These changes introduce specific class type-safety for methods of the generically-defined Vector class. Support for "generics" will introduce new language elements, potentially alter the bytecode structure of compiled classes, and represent a major step in the evolution of Java technology.
  
  Do I have a point? Yes, I do, and here it is:
  
  Should we be targeting this same timeframe - in which the language will change anyway to support "generics" - for the introduction of a "persistent" modifier for the "class" statement? E.g.
  
  public persistent class Customer {
  }
  
  which might create a class which implicitly implements the PersistenceCapable interface, providing all of the requisite method implementations. This would remove the requirement for bytecode enhancement.
  
  What do you, the readers of this thread, think of that as an idea? It's not something that the JSR12 group is actively working towards, but it would certainly remove the bytecode enhancement debate and integrate object persistence into the heart of the java platform.
  
  At this stage I am not suggesting that the introduction of a "persistent" keyword is likely, or that it is a "good idea". However I think it is an interesting concept, and look forward to your comments.
  
  Kind regards, Robin.
  Robin M. Roos
  www.OgilviePartners.com
  
  
• On becoming persistence-capable
  2002-12-11 22:07:13  srdrucker [Reply | View]
  
  
  I think the best would be doing what you stated in a previous post:
  
  [A "technically pure" JDO implementation would rely on JVM-level hooks into the transient object lifecycle which could be used to trigger corresponding events in a persistent object cache.]
  
  A JVM-Level hook would support three Major Goals:
  -Provide ability to populate hollow data.
  -Easily sense when an object becomes dirty.
  -Support both field-level and public-interface level persistence (Sun JDO vs. java.bean.XMLEncoder style).
  
  The hook could be modeled as follows:
  
  -Add two new methods to Object:
  addObjectListener(ObjectListener listener, String[] fields, Method[] methods) and removeObjectListener(ObjectListener listener).
  -ObjectListener would have three methods, fieldRead(FieldEvent e), fieldWrite(FieldEvent e), invocation(InvocationEvent e)
  -fieldRead(FieldEvent e) would provide opportunity to populate hollow data.
  -fieldWrite(FieldEvent e) would provide sensing of dirty objects.
  -invocation(InvocationEvent e) would provide both FieldRead and FieldWrite functionality for public interface persistence through monitoring of methods (usually getters and setters).
  
  The fieldRead method would only be called once on the first access of each field registered (to provide the appropriate value if hollow). fieldWrite would be used to sense dirty state. invocation() would only be called the first time the method is invoked.
  
  Finally, in my view, Object Persistence is the last hurdle to Java in the business world. I worry that Sun is not going to modify the VM for object persistence. There should be a jcp on this.
  
  My 2 cents.
• On becoming persistence-capable
  2002-12-13 03:06:20  robin@ogilviepartners.com [Reply | View]
  
  
  You deliver good value for just 2c!
  
  I know that most members of the JDO (JSR12) Expert Group are reading this forum and we should have further input on this. However any alteration involving the JVM spec should be considered a long road to go down.
  
  In the mean-time the PersistenceCapable interface is facilitating persistence hooks that execute very quickly for enhanced versions of classes, whilst having no impact on un-enhanced classes.
  
  The domain object models and applications you persist with JDO today should be portable to future strategies of JDO implementation (VM hooks, "persistent" class modifier, etc.) when and if these arise.
  
  And remember that enhanced classes are not enhanced in a vendor-specific manner, but the same enhanced bytecode can be used with alternative JDO implementations. On the whole I believe that JDO provides a sound and future-proof architecture for transparent persistence.
  
  But that's my opinion. What do others think?
  
  Kind regards, Robin.
• On becoming persistence-capable
  2002-12-13 07:56:59  srdrucker [Reply | View]
  
  
  The other route that would be acceptable to the anti-byte-code manipulation (I can't seem to stomach the word "enhancement") and anti-PersistenceCapable crowd would be to have an "Explicit Mode". This would be based on the following methods:
  
  PersistenceManager.retrieve(Object object)
  -This method already exists and could be used to explicitly retrieve all hollow instances in an object.
  
  PersistenceManager.retrieve(Object object, String field)
  -This method would retrieve a specific hollow field (or property).
  
  PersistenceManager.makeDirty(Object object)
  -Add method based on StateManager.makeDirty(Object object, String string) to make an object dirty.
  
  In "Explicit Mode", the application has the resposibility to retrieve hollow instances and make objects dirty. True, this violates transparent persistence, however, it is technically pure.
  
  Sun JDO can not get around the problem of completely eliminating JDOHelper.makeDirty. So, Sun JDO is not truely transparent persistence. And you wisely added retrieve(). In my view, you are already there.
  
  Personally, I use an enhanced -) Sun JDO interface (with the above methods) to wrap the non-PersistenceCapable mechanisms (JNDI, XMLEncoder, Serialization, Apache OJB, etc).
  
  Until Sun updates the JVM, this is the only technically pure route and ensures my objects can run agains any persistence capable mechanism. I think you guys have done an excellent job developing an API and are 99% there. If Sun added the JVM hooks to support hollow and dirty, you would have a universal peristence interface that could be used with all persistence mechanisms. Until then, it will be viewed by many that Sun JDO is dissing the non PersistenceCapable implementations. Make those simple changes to the API and the Sun JDO interface will become the universal standard.

• Sun JDO standard is more flexible than Castor JDO impl !
  2002-12-11 03:09:04  anonymous2 [Reply | View]
  
  
  Hi,
  
  Sun JDO standard is much more than an implementation like Castore JDO.
  
  Sun JDO aims to make a very flexible standard to handle persistent objects without sacrifing performance and without to privilege vendor specific features.
  
  JDO published a contract to be persistent. This may be done using bytecode enhancement, source code enhancement, or limiting the class to inherit a class that implements JDO contract (a class that inherit PersistenceCapable).
  
  Castor works with SLOW reflection, dot. Since it doesn't define a "contract" there are no standard way (in Java) to know object attributes without using the reflection !!!
  
  This is only one aspect of superiority of Sun JDO against other custom approach like Castor.
  
  bye,
  Luca Garulli (Member of Sun JDO Expert Group)
  Orient Technologies
  www.OrienTechnologies.com
  
• Sun JDO standard is more flexible than Castor JDO impl !
  2003-09-05 09:59:52  anonymous2 [Reply | View]
  
  
  Maybe a benchmark is in order, but what is the real cost of CACHED reflection? From my _off-hand_ experience with castor and webmacros it wasn't noticeable.

• Real Talk
  2002-12-10 21:10:44  chester8170 [Reply | View]
  
  
  Please define "hack job". Hack job would imply that the code is miserable. Ironically, I got a part-time CS student to work with my code and get up to speed in minutes.
  
  Please clarify "It will NOT work with an unmodified object model and creates an implementation headache." One of the biggest values of JDO is the separation of the object and data model.
  
  All of this said, I recommended JDO to my management and was shot down in favor of CMP 2.0. You want to talk about real headaches, welcome to the world of CMP 2.0. Coded my own inheritance, polymorphism, and funny, I had to run everything through beans requiring additional hardware thereby increasing the cost of my app server.
  
  Hack job or not, compared to JDO, I find CMP 2.0 miserable; in the 2 days I was able to divine from my management to eval JDO, I've coded more persistence classes than in 3 weeks with CMP 2.0.
  
  Please give me more than buzz words to either challenge my managment or continue to acquiesce.
  
  Thanks,
  C
• Real Talk
  2002-12-13 08:37:36  robin@ogilviepartners.com [Reply | View]
  
  
  Chester, I've replied on this theme in a separate message thread titled "JDO vs Entity Beans".

• About Fear and Fuss
  2002-12-10 14:34:43  anonymous2 [Reply | View]
  
  
  The main point in this article is not whether
  Castor has the right to call it JDO or must call
  it somehow else or ... (As I understood right,
  they *could* call it JDO, if they state that
  'J' is not the 'J' in Java anyway, which would
  be much more confusing)
  
  The point is that there is a specification (JDO)
  started at some point in time, and a product (Castor)
  available even some time before this other specification
  project finally produced an output. An old proverb says:
  The early bird catches the worm. If Castor would be so
  much inferior to JDO, no one would use it. Even if they
  would have gathered some attraction by using a misleading
  advertisement, it would certainly have create a loud cry
  'foul play' if their product would have been unusable or
  some inferior experiment.
  
  The problem that pops up here lies deeper. The is not a
  competition when it goes to finding good solutions to
  for common application scenarios. There is an organized
  mechanism that allows a 'junta' of application vendors which
  pay the price to join the club to mark their stuff (more or
  less modified) as a Java Specification. If you look at some
  standards, you will clearly notice sometimes the handwriting
  of a particular vendor. And it can be assumed that the vendor's
  primary intention in creating what did later grew into an JSR
  was not making some specification. It was (and this is clearly the
  right of any vendor) the creation of a software product.
  
  Perhaps you remember other things on that Java Specification
  Requests and that Java Community Process. There was
  fuss with the Jakarta project. There is still fuss regarding
  clean room implementations of a standard (and, studying some
  reference implementations, this would sometimes be more than
  just a benefit). There was fuss with Java logging.
  
  The intention of a specification process is also comparing different
  approaches, approaches which even may not have originated by one of
  the people doing the specification work, which is of course not only
  difficult for the ego, but sadly also often politically impossible.
  
  Just my 2 cents.
  

• Byte Code Enhancement vs. Class Mutilation
  2002-12-10 13:36:53  anonymous2 [Reply | View]
  
  
  I had the same concerns when I looked at byte code enhancement via JDO for the first time. Then I educated myself.
  
  Byte code is a language specified in the Java language spec. It a very clearly specified language with very specific rules.
  
  Also, you compile your classes don't you? Is that mutilation of your code also?
  
  The positives of byte code enhancement are clear. No line number issues when debugging, no problems using tools like CVS, etc. JDO is extremely lightweight relative to other proprietary and standardized persistence options. Part of this is because of enhancement.
  
  Many of the enhancers used by JDO vendors are open sourced (RI and others). If you are uncomfortable with byte code manipulation see what they are doing.
  
  Finally, JDO doesn't prescribe a byte code enhancer. I beleive there are vendors out there with source code enhancers. If you don't want the so called "mutilation", you can choose not to use a byte code enhancer.
  
  I for one, will happily take the benefits of JDO (30% code reduction, much cleaner code) and byte code enhancement, over the other options.
• Byte Code Enhancement vs. Class Mutilation
  2003-06-14 15:47:38  anonymous2 [Reply | View]
  
  
  
  Bytecode enhancement (manipulation)
  
  Open source libraries
  
  Jakarta Byte Code Engineering Library
  http://jakarta.apache.org/bcel/
  
  JBoss Javassist
  http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projects/javassist
  
  http://asm.objectweb.org/
  
  http://serp.sourceforge.net/
  
• Byte Code Enhancement vs. Class Mutilation
  2002-12-10 17:15:09  anonymous2 [Reply | View]
  
  
  Byte code enhancement, class mutliation, source code enhancement --- it all sounds like a hack job to me. A technically pure JDO implementation would not make any requirements regarding source code changes or class file changes. However, you are right, the benefits do outweigh the hack.
• Byte Code Enhancement vs. Class Mutilation
  2002-12-11 08:23:55  robin@ogilviepartners.com [Reply | View]
  
  
  A "technically pure" JDO implementation, as you put it, would rely on JVM-level hooks into the transient object lifecycle which could be used to trigger corresponding events in a persistent object cache.
  
  When JDO was being scoped such design choices were discussed with the JVM team. The upshot was two-fold:
  
  1. In the timeframe for releasing JDO, the JVM would not be changed to provide these hooks.
  
  2. Implementing a custom JVM, which all JDO-based application would then be forced to use, would make JDO "undesirable".
  
  These were the basis for the current model with its PersistenceCapable interface.
  
  However, do bear the following in mind.... Neither the application objects (which invoke PersistenceManager services) nor the domain objects (which are persistence-capable) actually depend upon the PersistenceCapable interface. If you are coding against the PersistenceCapable interface then you are doing it wrong (or you're a vendor writing a JDO implementation). That's why PersistenceCapable is in the JDO SPI (javax.jdo.spi) and not the JDO API (javax.jdo).
  
  This means it is conceivable that, with sufficient direct support from some future JVM, the underpinning mechanism of JDO's transparent persistence could be changed. (There are no plans for this in hand, I'm merely hypothesizing about some futuristic environment.) At that point the current requirement for "bytecode mutilation", as you so objectively term, it would be removed. However, your application and domain object source code would not need to be altered to function correctly in this new environment.
  
  My point? PersistenceCapable, and the requirement for domain objects to implement it, is an implementation detail of the current internal JDO architecture, and is - at least conceivably - subject to change. Good encapsulation, as exhibited by JDO's external architecture, insulates your classes from any dependency on this implementation detail.
  
  Kind regards, Robin.
  Robin M. Roos
  www.OgilviePartners.com
• Byte Code Enhancement vs. Class Mutilation
  2002-12-17 05:38:21  markusp [Reply | View]
  
  
  As you all might be aware of, at least one such custom JVM exist already. Although it currently does not fully support JDO 1.0, GemStone Facets has a HotSpot-derived JVM that doesn't require byte code enhancement (but allows it) for transparent persistence. Drawbacks include that they still only support JDK 1.3.1_something, Win2k and Solaris.
  
  /Markus
  

• Castor is dead ?
  2002-12-10 13:12:53  anonymous2 [Reply | View]
  
  
  Castor is almost a dead projet. They never publish new releases.
  If looking for a good open source product goes to www.hibernate.org.
  They don't use the JDO name for counter-advertising.
• Castor is dead ?
  2002-12-20 08:19:06  gchen77 [Reply | View]
  
  
  November 04, 2002 Version 0.9.4.1 is now available for download.
  
  The above is from the castor exolabs site.
  How fast are u expecting releases?? ;)

• Save a tree...
  2002-12-10 13:09:22  anonymous2 [Reply | View]
  
  
  kill a Castor !

• Agreed David
  2002-12-10 13:06:11  anonymous2 [Reply | View]
  
  
  The question is not about Castor being a good O/R mapping tool or not:
  * there are other good open source O/R mapping tools (hibernate...) and they don't need to use the name JDO to promote themselves
  * there are some open source JDO implementations and they CAN freely use the JDO acronym (TJDO, OJB...)
  * whether or not Castor JDO was named before or after the first JDO draft is not interesting, they should change their name to CastO/R for instance in order to have a clear position.
  
  Using "Castor JDO" is simply creating confusion, it seems that Exolab guys wants to take benefits from a standard on which they never contribute. Doing like that they try to kill the standard. Not a clean approach for a company that claims to promote open source.
  
  cheers.

• And your point is?
  2002-12-10 08:03:47  anonymous2 [Reply | View]
  
  

• JDO Is Awesome
  2002-12-09 17:29:48  anonymous2 [Reply | View]
  
  
  As a user of an implementation of JDO specification from Sun (JSR-12), I'd have to say it is quite good. I am a little confused by all of the complaints about it in this thread. Can some one please explain why JDO is an inferior standard as it works very well for me? Has anyone done a real comparison of the two?
  
  As a former Toplink user who watched Toplink prices go through the roof when sold to Webgain, I know the pain of using a proprietary persistence solution. Although Castor is free, I am not sure if I'll receive the same support levels as I have come to expect with Sun JDO where the standard provides me with many alternatives for getting support, training, etc.
  
  Finally, the value of spec is seen in one last place - with where JDO vendors have brought the spec in the 8 months since it was released, it is amazing. The rate of innovation seems to be driven by a common spec and the many vendors (and open source projects) supporting the spec. It appears that Sun's JDO may have been late to the game but is catching up very quickly.
• Why Sun JDO is inferior
  2002-12-09 19:44:41  anonymous2 [Reply | View]
  
  
  I agree, JDO is awesome. It will solve business problems and will work very well for most users. However, the technology needed to modify the class files is a hack. This all relates the class mutilation (termed byte-code enhancement) in JSR-12. Again, most business users will not care, and the Sun JDO standard will work great as it does for you. However, most seasoned programmers will cringe over class mutilation (or implementing PersistenceCapable manually).
• Why Sun JDO is inferior
  2002-12-10 13:47:43  chester8170 [Reply | View]
  
  
  Why would most seasoned programmers "cringe" over byte code enhancement?
  
  Solving business problems doesn't sound like a bad thing especially if I want to keep my job in this market.

• Sun JDO Flawed
  2002-12-09 14:14:19  anonymous2 [Reply | View]
  
  
  In any event, the Sun JDO implementation is flawed. It requires that your objects either implement a PersistenceCapable interface explicitly or have your class files mutilated by a so-called "enhancer". It will NOT work with an unmodified object model and creates an implementation headache. Unless, of course, you are using Sun's Forte -- which happens to be developed by ... you guessed it, the head of the JSR 12 committee. Very interesting....

• whatever the name
  2002-12-08 18:41:59  anonymous2 [Reply | View]
  
  
  Whatever the name, Castor works for me.

• Very Dissapointing
  2002-12-07 22:07:30  cmurrell [Reply | View]
  
  
  I'm dissapointed in O'Reilly. I look forward to the ONJava.com newsletter to provide me with constructive information. This article seems to be a rant and a self promotion of of an author's book. He should realize he is doing himself a dis-service by taking this approach. If you would like us (O'Reilly readers) to take you seriously maybe you should write a detailed article comparing the Castor JDO with Sun's JDO spec. Of course this has already been done, but if the author feels so strongly he should take us through this exercise. As far as the naming of the a product, this industry is full of re-used acronyms and terminologies.
• Very Dissapointing
  2002-12-20 08:14:50  gchen77 [Reply | View]
  
  
  Completely agree with you cmurrell.
  Instead of playing the whiny baby "He took my toy".
  Why dont you write something useful?
  Come up with a test comparison of Castor's vs Sun's JDO to demostrate the viability of one over the other. Demonstrate it with a practical applicaton.
  Because for those of us NOT on a experts group. We really dont care about anything other than:
  - does it do what we need?
  - does it do what is needed well?

• JDO Impersonation?
  2002-12-07 05:38:41  delta-vee [Reply | View]
  
  
  I really can't speak to the technical merits of JDO vs Exolab's implementation.
  
  But Sun is extremely intolerant of anyone thinking that they have a better implementation of something of anything connected with Java.
  
  The history of this pattern:
  
  1. Java Generic Library -- Sun had to create the Collections Classes
  2. Apache Xerces - Sun has create it's own XML doc handling
  3. Apache LOG4J - Sun created its own, less flexible implementation that was based off of LOG4J and placed it into java.util.*
  4. JUNIT - Sun couldnt STAND that, and placed assertions into the language itself. I personally dont think it adds to the language.
  5. Now STRUTS - a great idea, great implementation, didnt cost Sun anything -- is now under attack with JFACES.
  
  Instead of rationalizing the Java language, Sun just keeps throwing more kitchen sinks into it.
  
  

• Sorry, David...
  2002-12-06 14:26:31  anonymous2 [Reply | View]
  
  
  Looks like you struck out on this rant. It seems most of the comments tout Castor as the first to market and the better approach... Good luck with your book..
  
  

• Maybe Sun should change IT'S JDO
  2002-12-06 08:31:24  anonymous2 [Reply | View]
  
  
  Your main points seem to be:

  
  

  
  
  1. Castor released a O/R data binding tool for Java around the time Sun got around to creating a committee to spend 2 years designing an inferior standard.
  
  
  2. 
     Castor uses the name JDO when they are not JDO compliant
  
  
  3. 
     Castor has been using the name JDO since the above named committee formed, releasing real, usable technology.
  
  
  4. Castor is attempting to implement ODMG OQL as their query language, instead of creating YANOQL (Yet Another Object Query Language), like Sun's JDO did with JDOQL (which includes OQL in the acronum, and yet is not at all related to OQL? Maybe ODMG should come after Sun...)
  
  
  5. 
     Sun has now finally pushed the JDO standard out the door, requiring either code generation or byte code modification, two options that are plainly inferior to Castor's reflective methods, and Castor doesn't want to jump on board our little bandwagon, so let's go after them.
  
  

  
  From the above points I would suggest one of 2 things:

  
  

  
  
  1. Sun recall the JDO spec and make it more like Castor JDO (being a more sensible design, altogether), like they did with JAXB and the first design.
  
  
  2. Sun rename their inferior technology so as not to pollute the good name and reputation of Castor JDO
     
  
  

• JDO rant is FoS
  2002-12-05 15:24:53  perrin [Reply | View]
  
  
  I find it hard to believe that Exolab did it on purpose. "Java data objects" is about as generic a term as I can imagine, and the idea that use of that phrase could be a violation of trademark is outrageous. They are data objects for the Java language -- what else would you call them?!
  
  Having said that, I do think that Exolab should consider changing the name to avoid confusion.

• Facts?
  2002-12-05 12:03:35  anonymous2 [Reply | View]
  
  
  Many organizations (including large commercial companies) "using the names" of different technologies in order to "capitalize on the recognition of ... names". One of the clearest examples is SQL (see http://builder.com.com/article.jhtml?id=u00320020604dol01.htm). Considering the authors position with JDO, this simply sounds like advertising for JDO by attacking another product. I would like to know if any of the "several organizations have requested that they change the name of their product" are NOT supporters of JDO in some way (as vendors, consultants, etc.), and if so who?
  
  As far as the OQL claims go, Castor also makes it clear that they are still finishing their support. What isn't pointed out in this article is that Castor has NOT yet achieved a final release (1.0 version), and is still actively developing.
  
  I started looking for a persistence layer a year ago (based on articles from Scott Ambler), and Castor was the best one I could find (free and open) at the time. Now that JDO has been finalized, I looked at switching over to the standard, but it is dominated by proprietary implementations currently. Until a freely available implementation is available, and relatively bug-free (ie at least as good as Castor), I don't see what the benefits of switching over are (except for the JDO vendors).
• Facts?
  2002-12-06 12:54:36  bobd [Reply | View]
  
  
  Another thing is that Exolab does state that Castor JDO is not an implmentaion of Sun's Java Data Objects spec.
  http://www.castor.org/jdo-faq.html
  
  With that said, I find it hard to believe that "lead architects of several leading application server vendors" did not check things out throughly enough to know that it was not an implementaion of the spec. Perhaps the author could list those companies and architects for reference :)
  

• jdo
  2002-12-05 07:02:40  anonymous2 [Reply | View]
  
  
  Castor was using the acronym JDO long before Sun's JSR was public knowledge. I was trying Castor out, and it was from them that I found out about the "beta" JSR (I believe it was versioned 0.8.1 or some such) which had languished in that position for some time (the most current Sun doc's were 6 months old at that time). The fellows at Exolab claim to have attempted to work with the JSR folks to come to some compromise on their architectural differences.
  Castor has never made any claims to supporting Sun's JDO, quite the opposite. And there were several O/R tools that touted "java data objects" even before EJB.
  Finally, I read the JDO spec (at the 0.8.1 time) and found it just as intrusive to business objects as EJB. The vendor-lock potential was stupendous.
  
  Lance Lavandowska
• jdo
  2004-01-07 08:35:36  anonymous2 [Reply | View]
  
  
  Maybe Micro$oft should consider suing SUN - JDO sounds an aweful lot like ADO
  
  ...hummmmmm

• Hmm again...
  2002-12-05 05:54:17  anonymous2 [Reply | View]
  
  
  Hmmm again...
  
  Reading between the lines. At the bottom of this article.
  
  "David Jordan founded Object Identity, Inc. to provide Java Data Objects (JDO) consulting and training services. Currently, David is co-authoring an upcoming O'Reilly book on JDO with Craig Russell, as well. "
  
  Its hard to take this article too seriously considering the writer has his own company promoting JDO...
  
  Castor is a great product but aybe they should consider dropping the 'Java' prefix and simply calling it 'Castor Data Objects' instead...

• hmmm...
  2002-12-05 00:29:43  anonymous2 [Reply | View]
  
  
  Can't comment much on the JDO part of Castor,
  since I've been mainly following their XML thread.
  
  But on that one I can tell that they've been *way*
  ahead of JAXB for a long while -- while JAXB was
  stuck with DTDs and not making any progress,
  Castor was happily supporting XML schema and had
  a working implementation. From what I see today,
  the Castor XML marshalling framework still seems
  easier to use than JAXB (but this may be just a
  personal preference of mine).
  
  Another example of where Castor is ahead today --
  it exposes (and implements) an API for XML schema
  manipulation (JAXB doesn't provide that).
  
• hmmm...
  2002-12-05 14:05:46  rkarimov [Reply | View]
  
  
  I agree. I've spent many hours looking for a good Java/XML binding framework and Castor XML is the best. I didn't have a chance to use Castor JDO but it also looks good.