A page on the wikiweb entitled "Object Relational Tool Comparison" has been published that lists all the O/R products and frameworks available for java developers. The page lists them by criteria such as which ones have GUI mappers, which are free, which support ternary relationships, etc.
See the Object Relational Tool Comparison here:
I read the article with interest, but noted that JDatabase Wizard (http://www.j3ltd.com
) is not mentioned.
It's a wiki page - list it yourself.
So it's possible for a vendor to go in and answer "yes" to all the questions, right?? ;-)
It is possible for Wiki Pages to be editted by anyone, so yes someone could corrupt them. Of course, the community tends to monitor for such occurances and such changes would get detected, corrected and the perpetrator would be appropriately abused.
I added info there: TopLink provides
jdo implementation in 903 (Oracle).
I added Release Version No. Please enter the version nos. so that it reduces the confusion and serves as a reference.
Thanks for putting out this page. Great work
I updated OJB's ODMG note. It doesn't fully support OQL, but rather some portions of it. (Unfortunately it isn't well documented what is defined and what is in progress, which makes debugging code somewhat difficult.)
As a side question.. any recomendations on ODMG compliant mapping tools?
Hibernate is one of the top projects at sourceforge and I am impressed by it. It appears mature and robust. It's easy to use and the documentation is very good. Writing a simple xml document, can generate java code and sql code. Or it can work with a legacy database and legacy objects, the xml document links the two together. The only problem is why is it not talked about much? Why aren't there articles on javaworld about it, or books written about it? If there were, I would have an easier time convincing my boss we should use it.
I've used hibernate with tremendous success. It's really easy to use and performs well too (though I have no numbers). The simplicity of the design, and how well it stays decoupled from your application logic, are some of the reasons why I like it so much. The documentation is great and it's free. The author provides pretty quick support in the source forge forums. I'd do a quick test of it to prove its worth to your boss. I really can't think of any reason why it wouldn't be useful unless you had some kind of insane performance requirement (which you could probably still deal with). Neither of you would be sorry.
Anyone used both (or seriously looked into both)? I'd appreciate a brief comparison of what you like/don't like as well as day-to-day development experiences, and overall which one you prefer.
I have a dream. That all you talented and concerned java programmers in the universe collaborate in the true spirit of Objects and produce A SOLUTION. I plead for a website or forum where we clarify the array of java technologies that germinate everyday in fields like: OR Mapping, App Servers, Development Environments, Web App Frameworks, API implementations, Web Services implementation, blah, blah, blah.
Let's define, compare, clarify, integrate these solutions. Let's create a single simple complete point of convergence where everything has one meaning.
I have a dream.
>"I would have an easier time convincing my boss we should use it."
Possibly you need to convince your boss you have looked at a good amount of the other tools just so you can emphasize what a good tool Hibernate is and why you advocate it in comparison.
It does sound excellent. Possibly your boss is already attached to some other tool.
By the way, there are over 50 of OR Mapping tools available.
>"Why aren't there articles on javaworld about it, or books written about it?"
- There are almost as many O/R capabilities as there are tools.
- Of the 50+ products listed, at least 8 use JDO. Several have some forms of lazy loads and/or caching. A number have coherence.
- O/R tools have changed dramatically over time.
- They also get plugged into and out of other tools. For instance, Expresso, is not just an O/R tool as suggested by the C2 page, but JCorporate has a separate O/R tool called DBObjects. Maybe it's now part of Expresso - but you should ask JCorporate because they do have a separate Web page for DBObjects.
Regards and all the best,
We now return you to the future - already in progress.
DBObjects are a series of classes that are one part of the overall Expresso framework. DBObjects aren't purely standalone since they use Cache, DBConnectionPool and the configuration framework. However you CAN use DBObjects in a straight Servlet class [rather that, say, a Struts Action].
I am currently in the process of better isolating DBObjects from other parts of the framework for those that want the O/R capabilities in command lines programs, for example. You should see much of this come to fruition as of Expresso 5.1.
[Lead Developer, Expresso Project]
The only problem is why is it not talked about much?
Well, I suppose partly because we have strong user community centered around the project *itself*. There plently of "talk" going on in the user forum!
And, like many open source projects, we dont have a marketing budget ;)
> Why aren't there articles on javaworld about it, or books written about it? If there were, I would have an easier time convincing my boss we should use it.
Tell your boss to stay tuned .... thats all ima say for now ;)
Well, as far as I'm concerned, Hibernate is my O/R layer of choice for the short to medium term. I continue to be impresed by its quality and speed. Very good work.
Is Hibernate JDO complaint?
No, Hibernate is not JDO compliant, which in my view is a strength. It gives you the advantages of JDO (seamless persistence of your Java classes with no coupling or interface changes) without the disadvantages (byte-code compliation). I think that JDO would make sense if there were no tools out there that could do what JDO can do without adding an unnecessary step in the development process. I would only consider JDO if I wanted to avoid the performance hit of runtime reflection, and even then, i'd do a really careful comparison. Hibernate is pretty performant.
Thanks. But does it mean for a product to be JDO complaint, it has to implement byte-code compilation? I thought JDO is just a standard for API, does not define implementation (whether to use byte code compliation or not). Please correct me if I am wrong.
I thought JDO is just a standard for API, does not define implementation <
Yes, you would think that. Unfortunately, if you read the spec, you would find that you would be wrong :(
This is the real problem with the JDO spec; unlike other successful open standards, JDO goes to great lengths to lock you into a particular implementation technology. (If JDO would be a simple API specification then certainly Hibernate would provide an implementation of that API, in the same way we provide an ODMG-style API.)
On the other hand, Hibernate has a very powerful API that is optimized for use in O/R mapping, as opposed to the ODMG and JDO apis which were designed more with object databases in mind.
>> unlike other successful open standards, JDO goes to great lengths to lock you into a particular implementation technology <<
JDO defines a sophisticated client programming model that really is transparent. If you run a JDOQL query uncomitted modifications to instances in memory are considered without flushing their state to the database first.
For this to be portable accross implementations the spec needs to go into a lot of detail. The enhancement process may be done before compilation by modifying source code. However most vendors process class files because this is more convienient. It only adds a couple seconds to your compile target.
>> On the other hand, Hibernate has a very powerful API that is optimized for use in O/R mapping, as opposed to the ODMG and JDO apis which were designed more with object databases in mind. <<
The JDO API is not hard to implement for relational databases - there are at least 6 JDBC implementations out already.
Have a look at ours:
Sam Cheung asked:
>> I thought JDO is just a standard for API, does not define implementation
and Gavin King responded:
> Yes, you would think that. Unfortunately, if you read the spec, you would find that you would be wrong :(
Uh, I read the spec, and I think you're wrong. The spec defines a contract that JDO compliant classes must meet: implementation of the PersistenceCapable interface. The reference implementation supplies a reference enhancer to make classes PersistenceCapable, but enhancement isn't required to meet the spec.
From "Java Data Objects, JSR12, Version 1.0" spec. on page 17 paragraph 2:
"JDO instances implement the PersistenceCapable interface, either explicitly by the class writer, or implicitly by the results of the enhancer. The objective of JDO is that most
user-written classes, including both entity-type classes and utility-type classes, might be persistence capable. The limitations are that the persistent state of the class must be represented entirely by the state of its Java fields, and that the class be enhanced (or otherwise be written to implement the PersistenceCapable interface) prior to being loaded into the execution environment of the Java Virtual Machine."
From page 18 paragraph 1 of the spec:
"Alternative approaches to byte code enhancement are preprocessing or code generation. If one of the alternatives is used instead of byte code enhancement, the PersistenceCapable contract must be implemented."
So, it would seem that the requirements of the spec could be met if classes implement PersistenceCapable through a mechanism other than enhancement, as long as the design contract is met.
So, Sam is right.
The point is that JDO shouldn't define a contract between persistent classes and the JDO implementation. Sorry, but thats a no-brainer. Its of absolutely no interest to JDO *applications* how the implementation communicates with the persistent classes. JDO should define persistence semantics from the client point of view. That way:
1. Applications have a consistent programming model
2. Implementations have freedom to innovate
And as to your incorrect comment that JDO does not require enhancement, let me be _slightly_ more specific:
To support TRANSPARENT persistence (which is the whole point of the exercise), JDO requires either source or bytecode enhancement. And no-one will seriously dispute this.
(Yes, it is technically possible to have persistent classes inherit a superclass but thats just insane...)
Sam's question was (more or less) "Does the JDO spec require bytecode enhancement?"
Gavin's answer was (more or less) "Yes."
My response was (more or less) "You're wrong. The JDO spec does NOT require bytecode enhancement."
I neither attempted to evaluate the efficacy of Sun's JDO, nor to explain why "MyOpenSource" or any other object persistence mechanism is better than JDO.
The point of my post was that your response was inaccurate.
No, we weren't discussing bytecode enhancement (only). We were discussing wether or not, in Sam's words:
"I thought JDO is just a standard for API, does not define implementation"
Which is clearly NOT true. JDO is NOT just an API (APPLICATION programming interface). And no-one with half an ounce of understanding of the JDO spec and what it means for JDO implementations would seriously argue that it IS true. JDO seriously restricts the possible approaches to implementing transparent persistence and this is one of the main reasons why JDO is SO contreversial.
I *wish* JDO were "just" an API. I would love to be able to provide a great opensource implementation, alongside our own (arguably better) API. But it isn't.
Me thinks you selectively edit too much. Let's parse Sam's post together, shall we, hmmm?
Sam asked (shown in it's entirety):
> Thanks. But does it mean for a product to be JDO
> complaint, it has to implement byte-code compilation? I
> thought JDO is just a standard for API, does not define
> implementation (whether to use byte code compliation or
> not). Please correct me if I am wrong.
Sentence 1: Self explanatory.
Sentence 2: Does JDO compliancy dictate bytecode enhancement?
Sentence 3: Does JDO dictate an API AND a specific implementation?
Sentence 4: Self explanatory.
Whether or not I have an ounce of understanding about anything is irrelevant. I'm not trying to defend the JDO spec, nor to suggest that it's the best method to persist object state. I'm responding to your misleading response to Sam's questions in this post. Sam was clearly asking whether JDO compliancy requires bytecode enhancement (see Sentences 2 and 3). You said 'Yes', which it clearly does not. While the JDO clearly limits the implementation options, the spec doesn't dictate a bytecode enhancement implementation.
It is true that the JDO spec does not dictate the use of bytecode enhancement. However, it seems to me that it would be the ONLY viable implementation. Why? Consider the alternatives:
1) Generating a base class that implements PersistenceCapable: this is unacceptable because the client code would have to extend the generated class, poluting the domain model with extraneous code.
2) Generating the domain class itself, with an implementation of PersistenceCapable: even more unacceptable.
3) Generating other classes that implement PersistenceCapable, and are responsible for creating and modifying the domain objects: also unacceptable, for obvious reasons.
So, in practice, any usable JDO implementation would have to do some kind of bytecode manipulation.
Just my 2 cents,
It is true that the JDO spec does not dictate the use of bytecode enhancement. However, it seems to me that it would be the ONLY viable implementation.
We at hywy Software (http://www.hywy.com/
) provide JDO Source Code Enhancement of the user's sources. This is in deference to our customers' wishes. All of them want to see what modifications were made to add persistence hooks to their code. The generated code heavily cross-references the JDO spec in comments so users know what changes were made to their sources.
2) Generating the domain class itself, with an implementation of PersistenceCapable: even more unacceptable.
Says who? In fact this is what our customers want. They find this really useful in situations where code needs to be certifiable for big contract projects.
We dont over-write your existing domain class. We make a copy of it and make changes to the copy so your original domain class is intact and stored away.
1. Professional JMS Programming (Wrox Press)
2. Enterprise Java Computing : Applications and Architecture (Cambridge University Press)
3. The Awesome Power of JavaBeans (Manning Publications)
Copyright (c) 2002, Gopalan Suresh Raj. All Rights Reserved.
Visit me at Web Cornucopia at http://my.execpc.com/~gopalan/
Web Cornucopia - The Ultimate Resource for developing Distributed, multi-tier, Enterprise Solutions using CCM/CORBA 3.0, Java/J2EE, COM+/Windows DNA, The Microsoft .NET Framework, and all their related technologies.
I think that generating domain classes with an implementation of PersistenceCapable or any other interface IS unacceptable. The ideal O-R mapping system would leave domain classes alone. It wouldn't dictate any interfaces they need to implement and it wouldn't force you to "transparently" regenerate them as an implementation of an interface (which achieves the same undesirable result with a little less effort). I personally think that leaving domain classes alone also means not doing a byte-code regeneration, which is the most prevalent form of JDO implementation. Consider a situation where you are given a set of domain classes from another group that you cannot edit, or from 3rd party library. My options are pretty limited on what I can do with the code in that situation. As to code generation, Hibernate's website has some interesting comments on this and how Smalltalk and C++ have handled the reflection versus generation dilemma in the past.
Also, I'll come to Gavin's aid in the "he said/he really said" debate. Sam's question (in response to my post, actually) was whether or not JDO forced byte-code compilation. Sam's understanding was that it was just an API that didn't force implementation. Gavin's response, in so many words, was that you would think so, since it's just an API, but the nature of the API is such that there is little practical choice in the manner of implementation. While the spec MAY allow for other implementations, it is so restrictive that none of the other implementations are practical, or desirable in most situations.
The JDO spec, as John pointed out, does not specifically force an implementation. Gavin's whole point is that it essentially does because the alternatives to the most popular one (byte code generation) are mostly untenable (according the majority of users, myself included). We could play semantic games and say that the API doesn't specifically force an implementation but for all practical purposes it essentially does. I think Sam is probably more interested in how the API affects implementations in the real world than a syntactical debate about the text of the API.
Fair enough. While bytecode enhancement may be the only practicable implementation of the JDO that's been developed thus far, that doesn't mean that some person smarter than me, or Gavin even (perish the thought!), couldn't come up with an implementation that doesn't require bytecode enhancement (however unlikely that might appear).
JDO mandates that JDO classes implement PersistenceCapable interface. Period. It does not mandate bytecode enhancement. The implementation of the interface however is specified in a very detailed manner, and this is done so that any class that implements the interface can avail persistence from any JDO implementation, which is very, very good.
While there have been a lot of negative postings here as well as in other forums on byte code enhancement, intrusion etc, but till date there have been no convincing aruguments that justify this. But that is not the real requirement of JDO. It is the implementation of PersistenceCapable interface. Period (for emphasis).
Why is it so difficult to accept the requirement of interface implementation contracts ? No one seems to have any objections to EJB requiring that. The fact that EJB does not specify how to implement that is immaterial. Ultimately it is the implementations/servers which implement the contract - never the developer. And since the spec guarantees the same functionality before and after the implementation of contract, where is the harm ? We provide a EJB persistence manager as well as a JDO implementation and till date we have had no complaints from any of our customers on why bytecode enhancement is required or why the implementation requires an Interface.
Maybe the way to make this entire controversy go away is to use AOP model being used by JBoss to generate interafce implementations dynamically. Who knows ? This may also happen very soon. And then the issue will rest at last.
I think that people are not giving JDO a fair chance because of some really obscure reasons. Give it a try. I think that most of you will like for the functionality, ease of development it provides. And more.
(S Rajesh Babu)
is new Java Object Relational Mapping open source project. Its novel generalized design requires Minimal reflection, no pre processing, and certainly no byte code post processing. Not even an XML file to configure!
SimpleORM takes great care with database semantics. Locking, quality of information, and caching are all treated properly. SimpleORM allows for raw JDBC and non-Java database access and constraints without compromising database integrity. Optimistic locks can be used for web like applications.
The whitepaper is comprehensive so you do not need to install anything to work out what SimpleORM does and does not do. If you want a simple, light weight reliable ORM this may be for you.
[This posting is a totally biased account from the primary author! But SimpleORM does offer a different perspective on the problem.]