Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Book Reviews

Java Data Objects 165

Posted by timothy from the concentrate-on-the-beans dept.
Reader java1dev submits the following brief review of O'Reilly's Java Data Objects, which he says provides excellent coverage of JDO. His capsule description of the book: "First, a high-level overview, followed by an in-depth coverage of the core features, and concluding by describing the more complex concepts in detail. Running throughout the book is an excellent intuitive example application that illustrates the features being covered." Read on for more of his review.
Java Data Objects
author David Jordan & Craig Russell
pages 356
publisher O'Reilly & Associates
rating 9
reviewer java1dev
ISBN 0596002769
summary Excellent, example-filled introduction and practical guide to Java Data Objects.

Craig Russell, at Sun Microsystems, is the specification lead for JDO and David Jordan, at Object Identity, has been an active member of the JDO expert group since its inception.

Java Data Objects provides a thorough coverage of JDO and explains how it can be used in various architectures. The reader is expected to be familiar with Java but needs only a limited knowledge of databases. In brief, Java Data Objects (JDO) insulates you from needing to know a lot about databases. JDO permits you to develop applications using your preferred Java object-oriented model, without you having to write code to translate between Java objects and how the data is stored in the database--JDO takes care of all of that for you.

The first three chapters provide a high level overview of JDO by walking through a small application, exploring each of its interfaces at a high level, and introducing the architectures it might be used in. Even if you have been away from code for a while you will be able to follow most of the code example. You can stop here if you just want to understand what JDO is all about and where it can be used. These are recommended reading for a manager.

Chapters 4 through 9 are required reading if you want to start developing JDO applications. They really get you into JDO, so you can understand it and start using it. The first three of these cover how to define persistent classes and fields, how they can be mapped to various databases (done for you) and the class enhancement process (which makes a lot of JDO transparent to you). The next three (chapter 7 through 9) bring home the power of JDO. These cover how to connect with a database, establish a transaction context and create, read, query, update and delete database objects. The material is made concrete by illustrating it with a detailed and intuitive example application. This example is carried throughout the book with sections of it explained as the concepts are covered.

Each remaining chapter covers a different JDO concept or feature (including optional features) that were introduced earlier but not covered in detail to keep the earlier chapters more understandable. These remaining topics are identity, lifecycle states & transitions, field management, cache management, nontransactional access and optimistic transactions. You can read these chapters as you feel the need for a more in-depth understanding of these concepts.

The last two chapters explain how to use JDO in an application-server environment and an Enterprise Java Beans environment. These two chapters assume you are already familiar with these environments, but I think a lot of it is understandable even if you are not.

There are five appendices with everything from the lifecycle state transitions to the collected source code for many of the classes used in the example application.

You can purchase Java Data Objects from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Java Data Objects More

Java Data Objects

Comments Filter:

  • suggestion (Score:5, Insightful)

    by newsdee ( 629448 ) on Tuesday May 06, 2003 @11:03AM (#5891770) Homepage Journal
    Would it be possible to add the suggested retail price (MSRP) of a book in a review?
    Yes, it can be found by searching the web, but it's just extra comfort brought by a small database tweak. :-)

  • JDO vs EJB Entity Beans? (Score:5, Insightful)

    by kisrael ( 134664 ) on Tuesday May 06, 2003 @11:04AM (#5891782) Homepage
    I've heard that JDO is much better, tighter solution to O/R mapping than EJB Entity Beans, that the latter are designed to be SO flexible that you can use them as a wrapper to your legacy mainframes, but the former is a lot closer to the problem most Java folks need to solve. Anyone know if that's a reasonable viewpoint?

    (For the record, at this point I hate, hate EJBs. I think they're speficially responsible for the failure of multitudinous Java server projects, way to much overhead for 95% of all things you'd want to do in Java on the server, and the bad apple that risks spoiling the whole J2EE barrel.)
    • I have to agree - its got to the point where I question _anyones_ use of EJBs - that last 5% is far too specialized.

      I've started using Castor which aint quite JDO, but very close and a damn site easier than EJBs...

    • Re:JDO vs EJB Entity Beans? (Score:5, Informative)

      by ideonode ( 163753 ) on Tuesday May 06, 2003 @11:17AM (#5891925)
      There's an interesting thread [theserverside.com] over at TheServerSide which discusses JDO vs. Entity beans.

    • You are right on. EJBs are very easy to miuse and generally are cumbersome to wrap around smaller projects. It looks like JDO might be a nice alternative to rolling your own persistance layer. I'd like to see a comparision between JDO and other products like Toplink.
      • EJBs are very easy to miuse -

        This is what I've seen being the biggest issue with Entity EJBs. Where I work, they've taken a bunch of old mainframe coders (who weren't very good there as far as I can tell), sent them to _a_ Java class, then to _an_ IDE class and turned them loose.

        They all heard EJB and went wild. So the result is a bunch of junior programmers with little understanding of Java, much less J2EE writing "Enterprise Applications". Needless to say we've had some problems - performance and

        • "Baby with a gun" isn't extreme enough to really describe the current situation...

          So, who gave that baby the gun? EJB is hardly at fault, here.
          • Ah yes, well one cannot really "type expression", things like sarcasm can easily be mis-interpreted. My point was that this is clearly the fault of the company.

            However, I do feel that the overhead, complexity and hence pitfalls of ENTITY EJBs (Stateless Session beans are fine, really) made a bad situation MUCH worse

      • Toplink is becoming JDO (Score:3, Informative)

        by olip ( 203119 )
        Comparing is not the best way to go.
        From what I've heard, Toplink is due to implement somehow the JDO specs in a few months.
        Seems they are trying to change the spec (making the "code enhancement" feature optional), since enhancement is not the way they have chosen. And since they are backed by Oracle, their voice has become louder.
        Probably there will be two levels of JDO spec : level one for Toplink, level 2 corresponding to JDO as we now know it.
        Anyway JDO is the thing all Java developpers have been wa

    • Re:JDO vs EJB Entity Beans? (Score:5, Informative)

      by haystor ( 102186 ) on Tuesday May 06, 2003 @11:18AM (#5891938)
      I've been using torque (from Apache, under the DB project).

      One row in the db equates to one object with all the appropriate getters and setters.

      I haven't been using Torque for anything too complicated, but it definitely passes the test of making the simple things simple, and area I find Java to be weak in.

      For instance:
      Torque.init("Torque.properties");
      Empl oyee emp = new Employee();
      e.setName("Dave");
      e.save();

      That's all there is to creating a row in the db. There are correspondingly simple operations for select, update and delete so long as you are working on one table at a time. Its a bit messier working with joins.

      Its also messy and poorly documented when doing work on the select side of the statement. While "select max(emp_id) from employees" is doable, its not as simple as it could be considering how common select max() is.
      • Its a bit messier working with joins.

        That's a giveaway. If it can't deal with joins there is probably a lot more it can't deal with. Views, class hierarchies, transactions etc. I don't know torque but your example isn't enough to sell me on its simplicity.

      • JDO and Torque are both the same sorts of tools, Object-Relational Mapping (O-RM) tools. In the Java world there are also about a few dozen other O-RM tools (Apache Jakarta hosts two different ones even). (Note, we could split hairs here. JDO is an API specification, there are several vendors implementing it.)

        However, the difference between JDO and all the other ones is that JDO, for better or worse, is now the "standard" O-RM interface. Standard in the sense that it's the one Sun is promoting through the

    • Re:JDO vs EJB Entity Beans? (Score:4, Insightful)

      by Furry Ice ( 136126 ) on Tuesday May 06, 2003 @11:18AM (#5891947)
      I think your rant against EJB probably has more to do with entity beans than EJB in general. You can actually use JDO as the persistence layer from session beans, and that's pretty much what my company does. We wrote our own JDO-like code which works pretty well. Perhaps I'll pick this book up to see if it's worth switching, or maybe just to get some ideas to enhance our JDO-like code.
      • Well, I've heard the official recommendation is to use stateless session beans whenever possible. And if you're in a Serverside situation (actually, getting a Swing frontend to access EJBs seems a little strange to me, but it might just be I've been in Servlet/JSP land for so long), why not just use static methods and classes to provide your service???
    • [EJBs are] the bad apple that risks spoiling the whole J2EE barrel

      I thought that was Swing.
    • I've heard the opposite.

      Of course he's biased, but Marc Fleury (of JBoss) is very enthusiastic about CMP (Container Managed Persistence) v2.0 EJB's.
      In his "Blue" Whitepaper on the subject he wrote that the CMP (Container Managed Persistence) v1.1 of EJBs was seriously lacking in various critical aspects, and goes on to say the following:

      From Marc Fleury's "Why I love EJB's" [jboss.org] (PDF, page 7):

      In other words, if the CMP2.0 engine s applicability goes beyond EJB alone, why couldn t we imagine a CMP engin

      • Re:JDO vs EJB Entity Beans? (Score:4, Interesting)

        by awhite ( 179035 ) on Tuesday May 06, 2003 @11:54AM (#5892352)
        While it was widely used in designs a year ago, JDO will probably go down in history as the proverbial chicken that crossed the road when the CMP2.0 truck came along.

        If you read a lot of Marc Fleury's public comments carefully, it is clear that he doesn't know what JDO is. He equates JDO with Castor JDO [exolab.org], which is a relatively simplistic persistence solution that happens to have "JDO" in its name; it is not a Java Data Objects implementation. The quote above is a perfect example: the JDO spec is barely a year old! So JDO was not widely used a year ago: Castor, however, was getting a lot of publicity around that time.

        Fleury would do well to research the JDO spec, because a lot of the things he's proposing in his new vision for CMP are things that real JDO already does. JDO can persist vanilla Java classes with no code changes. Persistent fields and relations are completely transparent. Just declare a field of some other persistent type, and the relation is managed for you. Same with Collections and Maps and so forth (including collections and maps of relations to other objects). Data is lazily loaded as you access it, and change tracking is automatic. The runtime API for managing persisting objects consists of only a few classes. The query language looks just like Java boolean expressions. The whole system is elegant, but powerful. It stays out of your way. It's everything EJB is not :)
    • The one thing I think that kills Entity Beans for me is that they don't scale very well, in their design alone.

      For example: Say you have a findBy method that returns a 10000 row result set, but since it's EJB, it just returns the Primary Keys, then there's a second lookup for each of the 10000 keys to refresh the bean information. Now, take that to 100000. It really starts to get slow.

      I know no one said Entity Beans are a magic bullet, but when I think of "Enterprise Applications", I think large data sets
    • I did a pretty extensive evaluation of both. Turned out the 2 technologies were very similar, as long as you use XDoclet with CMP Entity Beans. JDO's biggest advantage over CMP is built-in support for polymorphism and inheritance. CMP Entity Beans' biggest advantage over JDO is Container Managed Relationships. The code base for both sets of code was basically the same. JDO doesn't have declarative transactions, but I was able to simulate this using an Aspect. We ended up going with EJB, largely becaus
    • My main gripe with EJBs is that once you use them you're tied to a platform. That platform is an application server.

      Using JDO (or Hibernate or other solutions) allows you to deploy your solution inside an app container, inside a web container, or simply standalone.

      The biggest benefit I've seen from deploying standalone comes from unit testing (using JUnit). My most recent projects have all had sizeable sets of standalone functionality tests. Once those several hundred tests succeed in a standalone context

    • Re:JDO vs EJB Entity Beans? (Score:4, Insightful)

      by MSBob ( 307239 ) on Tuesday May 06, 2003 @12:21PM (#5892688)
      EJB is simple. Really. It isn't as bad as people say. Entity beans make sense once you read the spec and understand it.

      The sucky part of J2EE is deployment. If I don't have to look at another 500K deployment descriptor file I'll be a happy man. They moved so much functionality out of code into deployment descriptors that now it's more complicated to manipulate descriptors than code! We went full circle. Instead of keeping complexity in the code it has been shifted to XML i.e. the weakly typed, unchecked format that's responsible for 90% of J2EE project delays.

      Kill deployment descriptors and we'll all be winners. The tools to manipulate deployment descriptors have not materialised. It's time to cut the losses and ditch that XML madness in J2EE.

    • Try hibernate http://hibernate.bluemars.net.
      Inheritance, composition, lazy loading, proxies. Very easy. Sun seems to treat JDO as the black sheep of the J2EE family and who knows what they'll do with it. Besides, there's no truely compliant open source implementations availible.

    • JDO usability (Score:2, Informative)

      by elindauer ( 520825 )
      I've been working with JDO essentially since it was released, and have found it to be a very effective tool. As with any technology, it takes some time to learn, and it has areas which aren't as transparent as you'd like them to be.

      I have always been the "JDO-guru" for my development team. As such, I've spent a lot of time trying to smooth out the various issues we've run into, so that other members of the team can work with this technology as transparently as possible. The main thrust of this w
    • I'm no expert on JDO, but I feel EJB's have gotten a really bad PR from mis-use. I've slammed EJB's myself when lead architects think using EJB's is a good idea when the app doesn't require transactional support. The thing is, JDO and EJB can work together, though not necessarily. If you have a multi-query/transaction process, JDO will provide some level of benefit, but it won't allow you to handle the transactional aspects. Again, most people don't have these kinds of requirements, but say you have to acce
    • JDO is a massive step up from EJB entity beans, giving you inheritance, sophisticated state behavior, fairly low overhead (especially at the object layer) and several advantages besides.

      But JDO's goal, of insulating you from the database, means that you can't get to the database even if you need to. In my opinion, this limits JDO apps to the same "toy" class of applications that entity EJB's are limited to.

      For instance, the way JDO stores a polymorphic reference is to store the object id and the object t
      • Sorry to reply to my own post, but the super killer that JDO doesn't manage and falls flat on is the update problem.

        Sometimes called "object evolution", "schema evolution", "schema upgrade", or a few other names, this is the problem you have when your objects (and therefore your schema) change from V1.0 to V1.1. Your customers will expect the upgrade to happen and the app to keep running, but a schema change will require that you do db manipulations to preserve their data across changing columns and table
      • Actually most relational JDO implementations already let you bypass the JDO layer and deal with SQL when you want to, and let you map classes to an existing schema (or even generate classes and O/R mapping data from an existing schema). At least, I know you can do all this with Kodo JDO [solarmetric.com]. If you haven't checked out JDO lately, I'd say you should give it another shot. Keep in mind that the spec is barely a year old... implementations are adding features very rapidly.
        • That's what I figured would happen. But what I don't get is why being able to ignore the db is touted as one of the advantages of JDO. It's a serious problem in the spec which leaves you tied to the vendor-specific extensions.

          By leaving the gap in the specification, they prevent someone who's using JDO from easily swapping vendors. At that point, I still say that the application interface is nice, but I'll take an approach that blew off the cruft the first time around and did it the right way from the s
    • A. There is nothing stopping a container from using JDO as its persistence implementation EJB Entity Beands.

      B. Entity beans also offer security, transactions and remoteness. None of that you get inherently with JDO.

  • JDO (Score:5, Insightful)

    by HunkyBrewster ( 578901 ) on Tuesday May 06, 2003 @11:07AM (#5891810)
    "In brief, Java Data Objects (JDO) insulates you from needing to know a lot about databases."

    First of all, I wouldn't want to hire that developer. Secondly, that is not entirely correct. O/R frameworks are useful in that they provide a consistent interface

    • Re:JDO (Score:3, Insightful)

      by rutledjw ( 447990 )
      First of all, I agree - on both points. However, I think a batter description of JDO is that is provides a model which logically abstracts a persistence layer. Within the model it provides a good method of implementing DB interaction along the same "thought lines" of Entity EJB function.

      IMHO, the concept of encapsulating DB interactions (CRUD) in objects is a no-brainer. But the EJB implementation was out of control as far as overhead and complexity. JDO brings us back to the basics and eliminates a l

    • Re:JDO (Score:2)

      by pmz ( 462998 )
      "In brief, Java Data Objects (JDO) insulates you from needing to know a lot about databases."

      First of all, I wouldn't want to hire that developer.

      Agreed. The quote about JDO above is like saying VisualBasic frees programmers from needing to know, well, basically anything. It's marketing statements like this that get embedded in the minds of project managers, who, then, send a project free-wheeling into a pit of despair. I find it immensly disappointing that for each step the software industry takes fo
    • That's a gross generalization. A better statement would be "JDO insulates you from needing to know a lot about database implementations". That is, your businless logic need not be concerned with which SQL dialect it needs to use depending on which RDBMS you are talking to. JDBC syntax goes a long way towards insulating you from quirky non-standard syntax, but java to SQL type mappings are a different story altogether. When you know that you are always going to deploy against a certain flavor of database, t
      • Nice to hear that someone else is basing their business on TJDO (my company puts the the "T" in TJDO, though the bulk of active development is now coming from outside the co.)

        Your remark about "JDO insulates..." is spot-on; JDO isn't a panacea, by any means. It uses some resources that a hand-coded approach wouldn't, and naive programmers can tie a program in knots with bottlenecks or even resource deadlocks if they're sufficiently "inventive". However, being able to run the same code base against Oracle

  • Java Data Objects are nice but Hibernate is Better (Score:5, Informative)

    by TheNarrator ( 200498 ) on Tuesday May 06, 2003 @11:09AM (#5891844)
    I looked into JDO and was excited. Here was a much simpler alternative to EJB. In EJB there are many many things that can go wrong during deployment of beans which leads and quite a bit of replication. YOu define your object once in the bean, once in the remote interface, once in the local interface, etc. It seems to take a while to debug. JDO is better but it requires a class file enhancer. Hibernate [bluemars.net] is a lot better. There is 1 config file that defines your whole object model and it requires no special class file enhancer. That and unlike EJB it supports inheritance in object models well.
    • I agree - anyone looking for a Java solution for database access that makes sense, instead of just following the latest corporate craze for cookie-cutter coding, should check out Hibernate.
    • Hibernate [bluemars.net] is a lot better. There is 1 config file that defines your whole object model and it requires no special class file enhancer.

      That is precisely the problem with the majority of non-JDO persistence architectures that use standard reflection (Toplink, Hibernate, CocoBase, Castor). While people tend to get nervous about bytecode enhancement, it is just an additional step in the compilation process.

      Bytecode enhancement allows JDO to perform change tracking without intruding on the a

  • good book, bad topic (Score:2, Informative)

    by Anonymous Coward
    I read this book a couple weeks ago. It's a good book (some o'reilly's are essential, some were a waste of paper and ink, and some are good). However, Java Data Objects should be avoided if possible.


    I know that sounds like a harsh statement to the uninitiated. I'll admit, the idea sounds good. But the implementation is a headache and maintenance nightmare.


    I've worked with Java Data Objects for 3 years now, and everyone I know who has experience with it feels the same.

  • I'm too much of a Star Trek fan (Score:4, Funny)

    by product byproduct ( 628318 ) on Tuesday May 06, 2003 @11:13AM (#5891887)
    I read the title as "Java Android Complains".
  • according to slashdot, the user 'java1dev' doesn't exist. What does this mean?

  • Annoying book (Score:2, Insightful)

    by Anonymous Coward
    I read this and thought that it was very much a downer on C++. In fact the authors even go so far as to suggest that Java is simply better in all but the rarest of cases. There is also a brief mention of JDK availability and also VMs in Red Hat, but I really didn't see how this was relevant.
  • I am concerned about learning another query language. Each has its limitations and that is why I was slow to adopt EJB-QL. EJB-QL is odd to learn and still not as feature rich as pure SQL. Now there's JDO-QL... yet another query language to learn. I found that in my previous projects, it is not that bad to embed SQL into DAO objects. You have complete power and control that way. You don't have to learn another QL, and you have the benefits of SQL.
    • The above post is by no means off topic! You bring up a great point. I believe in EJB session beans you can still write your own SQL. Not sure if that is what you meant by DAO objects...

      In my experience every one of these "Java Architects" seem to spew the same old crap.
      1. With this you don't care what DB you use.
      2. Speed won't be an issue because of cacheing.

      Yeah right... These are the same people that haven't written more than a 1,000 lines of code in their life.

      Do I think JBO deserves a look? Y

  • Well, for those who missed it (Score:5, Interesting)

    by WndrBr3d ( 219963 ) * on Tuesday May 06, 2003 @11:38AM (#5892160) Homepage Journal
    I've said it once, and i'll say it again.

    These book reviews on Slashdot, at times informative, really just are letting people know about the book and not as much reviewing that.

    This demonstrated is that in the last two months, no book has received less than a 80% approval rating by the author (unless you rate a 'very good' as < 8). It's like Homer Simpson is writing these reviews, "This (book) gets my lowest rating ever, seven thumbs up."

    I mean honestly, a review needs to have a few lemons on its record. I think someone should review a Wrox book on Linux and have it summarized with, "This book really gobbled the cob. it wouldn't be fit to line the kitchen floor for my puppy to soil in the evenings."

    Instead of calling it 'Slashdot Book Review', it should just be called 'Slashdots list of books that rule'.

    That's just my opinion though, I could be wrong.

    • It really makes the most sense to post the reviews of books that are actually good. If I'm interested in a new topic, I really don't care to read or wade through a detailed review of a book that is bad. Just give me one or two good books to start me in the right direction.

      If I'm buying a car, sure list what's good and bad for my money, but if I'm looking for a book on new technology I'm into, just send me the ones people are passionate enough about to send in a glowing review.

    • This demonstrated is that in the last two months, no book has received less than a 80% approval rating by the author

      To have an honest book review, you should read the full book. Unfortunately, it's very difficult to fully read a book when it sucks.

      So maybe this is the reason slashdot readers review only books that rule...

  • Alternatives (Score:5, Informative)

    by tdrury ( 49462 ) on Tuesday May 06, 2003 @11:41AM (#5892188) Homepage
    Before you commit to JDO or entity beans, do yourself a favor and also look at OJB [apache.org] and Hibernate [bluemars.net]. Both of these object-relational mapping (ORM) tools offer unintrusive presistence to your existing beans (unlike Toplink and Cocobase which require you use their collection types) and don't require you to run a byte-code mangler like JDO.
    • I agree with the Hibernate suggestion. However, I'm not so sure about the collection type comment. Yes, in a sense the interface is a standard Collections interface (Set, List, etc) but the actual underlying implementation is a Hibernate data type. IIRC, this was done to allow lazy-loading of collections.
    • Before you commit to JDO or entity beans, do yourself a favor and also look at OJB [apache.org] and Hibernate [bluemars.net].

      Okay, everyone, get it out of your system: reply, now, with the other 1,345 APIs that we should consider in addition to EJB, JDO, and, now, OJB and Hibernate. Don't be shy, now. Post!
      • Okay, everyone, get it out of your system: reply, now, with the other 1,345 APIs that we should consider in addition to EJB, JDO, and, now, OJB and Hibernate. Don't be shy, now. Post!

        Just do it with the database vendor's db specific interface API.. CLI for DB2, for example.

        Better yet, just use low-level ODBC calls.

        Or, better yet, do it in ADO, or DAO or OLE-DB ,or whateverthehellmicrosoftiscallingitthismonth, and write a JNI wrapper around it for Java....

    • fud again? (Score:4, Informative)

      by geoff_hendrey ( 655157 ) on Tuesday May 06, 2003 @01:32PM (#5893426)
      here we go with the FUD again. "Mangler"??? I suppose you consider javac a "mangler" or aspectj a "mangler". I think the "mangler" you refer to is the bytecode enhancer. What you forgot to mention is what the "mangler" does. Rather than scare people off, I'd like to explain the clear advantage to bytecode enhancement over reflection for dirty detection. Let's say you do a query which returns a single object. Your application then modifies a single field of the object and commits the transaction. Before commit you have to perform "dirty detection" to find out what fields have been dirtied, and need to be updated in the DB. If you don't use an enhancer you have to compare the object, field by field, with either a cached copy of the object, or worse, issue a select into the database to get the old values. The latter is particlularly bad not just for the obvious performance hit, but because it forces the table or rows to be locked for the duration of the transaction, thus making optimistic transactions impossible. Now imaging your select returned 100 objects, or 1000 objects. With an enhancer, the bytecodes for 'putfield' and 'getfield' are replaced with calls to the bvendor provided state manager. The JDO driver knows instantly what fields were dirtied, needs to keep no cached copies and never hits the database with a select before update. Furthermore, with enhancement you don't force the user to extend any classes. There is zero intrusion on the domain model. I understand that Castor, Hibernate, etc. are good open source projects, and very viable. I do, however, think that JDO is elegant and has advantages, on paper at least, over other methods.

  • How do you .. (Score:3, Insightful)

    by 1337_h4x0r ( 643377 ) on Tuesday May 06, 2003 @11:42AM (#5892198)

    Tell it which objects are mapped to which tables? And what about objects that map to multiple tables? Seems like you'd still have to have SOMEONE who knew how to do a proper database schema to set up your object structures and mappings, and make the database itself. :)

    That said, this would free your developers from having to be intimately knowledgable about your database schema, which, if you have done any outsourcing, you would recognize the benefits of right away.

  • Hard problem... (Score:4, Insightful)

    by Hard_Code ( 49548 ) on Tuesday May 06, 2003 @12:00PM (#5892420)
    There are several Object-Relational mapping packages for Java out there. Hibernate is another one.

    However, I have to say, that I have not found any complete O/R mapping package that implements everything transparently. In specific, I'm talking about recursive map structures, and "long transactions". Most of these packages are aimed towards short lived transactions on one object, or on a unidirectional tree of relationships.

    I sunk absolutely OBSCENE amounts of time and effort into trying to make various packages work with a many-to-many self-recursive database structure only to realize it cannot currently be done with the packages out there. I would be glad to be proven wrong.

    I would love to be able to keep a cache of a recursive map structure in memory (indefinately!) and have modifications automatically cascade the required updates to all nodes and revoke/expire any checked out nodes.

    Finally I gave up trying to cache the actual structure in memory and now I just cache data, descend over the structure in the database for each request (it's not so bad, it turns out to be rather fast anyway).
    • I would love to be able to keep a cache of a recursive map structure in memory (indefinately!) and have modifications automatically cascade the required updates to all nodes and revoke/expire any checked out nodes.

      Haven't some of these problems already been solved in the RDBMS systems themselves? Are databases really so slow (meaning misapplied, misdesigned, and misconfigured) that all these layers upon layers upon layers of APIs and abstractions are necessary to get the job done?

      Why not just two racks
      • Like I said, the performance wasn't all that bad anyway. Object-Relational Mapping does not (typically) solve a performance problem, it solves the impedence mismatch between Object Oriented Programming (the way most anything important is written these days) and relational databases and their declarative[ish] languages like SQL.

        I also had the good fortune that the application I was writing had VERY little data, so the iteration was very fast, even when hitting the db each time, and was 99.999% read-only (an
      • Haven't some of these problems already been solved in the RDBMS systems themselves? Are databases really so slow (meaning misapplied, misdesigned, and misconfigured) that all these layers upon layers upon layers of APIs and abstractions are necessary to get the job done?

        The goal is to make life easier and more productive for developers, and to handle more complex systems with less code, less repetition, and just generally better-engineered solutions.

        Database languages, i.e. the vendor-specific varieties

        • The goal is to make life easier and more productive for developers, and to handle more complex systems with less code, less repetition, and just generally better-engineered solutions.

          Has this actually occurred in practice? I have yet to see it. The explosion in the number of APIs with these goals has arguably made the developer's job much much harder, where the learning curve leading to informed decision making is becoming impassable. Specialization of jobs is not improved from before, where the "Oracl
          • I really think the software industry needs to step back and take a breath.

            I think it needs more than that. Where my perspective is coming from, though, is getting work done within the confines of the current software industry.

            Has this actually occurred in practice? I have yet to see it.

            I've seen it in some systems, and I try to develop systems like that. However, it doesn't happen automatically, by any means. A big aspect is being sensible about choice of tools. E.g., the obvious one that most peo

    • Have you tried EOF [apple.com] (part of WebObjects [apple.com])? It uses an extensive caching structure and cascades modifications. It's not completely transparent though, but I doubt that any package can provide that given the complexities of such a solution. This [stepwise.com] explains how to extract EOF for use in a pure Java app.
  • Object-Relations Mapping isn't very new, even in the realm of Java. Apple, TopLink, CocoBase, have been there for years without JDO. I haven't had much time to evaluate JDO but I'd be surprised if it's as well designed or as comprehensive as Apple's Enterprise Objects Framework [apple.com] and EOModeler [apple.com].

    EOF is available with WebObjects [apple.com] which is a much easier way to build 100% Java web applications than any jsp/ejb solution.

    in summary:
    Object-relational mapping - good.
    WebObjects/EOF - good.
    JDO - undecided.
  • I tried putting JDO in an app I was using. Seemed pretty cool initially. The OQL through me off at first. Despite being around for a really long time (10+ years), there was little documentation on the Object Query Language.

    This got me into what I thought was the biggest problem. Too much abstration. JDO ran too slow for me. And rather than making things simple, it made them more complex.

    Bottom line: Object databased and query languages have been around for a long time. Few people use the, prefering the re
    • I believe you are confusing JDO with something else. JDO does not use OQL. It has its own query language that looks exactly like Java boolean expressions. For example:

      name == "John" && address.zip == 77096 && nickNames.contains ("JJ")

      Also, JDO is certainly not slow. In fact, a good implementation with object caching and (if relational) prepared statement pooling and statement batching can be as fast or faster than staight JDBC.

      You might be thinking of Castor JDO, which has "JDO" in
      • I was thinking of Castor JDO. Thank you, you are wise.

      • Also, JDO is certainly not slow. In fact, a good implementation with object caching and (if relational) prepared statement pooling and statement batching can be as fast or faster than straight JDBC.

        Thank you ever so much for elaborating on a long standing joke of mine.

        More than ten years ago I heard the first cries of "... given the complexity of current processors, modern C compilers outperform hand coded assembly in most cases.".

        Then "... just-in-time compilation allows Java to be optimized further

  • OJB is better... (Score:3, Informative)

    by JohnnyCannuk ( 19863 ) on Tuesday May 06, 2003 @12:29PM (#5892787)
    While JDO is interesting, the Apache OJB (Object Relational Bridge) [apache.org] project is even better. It provides a JDO implementation as well as an ODMG impelemtation and a low level PersistenceBroker API. Lots of choice. More than one way to do things, allowing the developer to trade-off make trade-off when they are appropriate. It is fully transactional and supports the latest JDO as well as ODMG specs.

    And it can be used to persist objects transparently...you can set it up to persist objects you already have and completely control how the object relation mapping takes place in a few config files.

    We've used it on projects since November, and I don't think we'll ever go back to Entity Beans. This project allows you to choose when you would like to use byte code enhancment techniques (JDO) or reflection techniques(ODMG) or even combine the two.

    Best of both worlds.

  • Question:

    Is Jdo a clone of Ado?

    It seems to provide the same kind of functionality.
    If sun was smart they would release newer libraries to compete with C#.net as well. You can create apps with similiar functionality like Microsofts petshop demo with 1/4th the code compared to java. Bussiness customers notice this. Especially if project deadlines are always a problem. The quicker something is done the better.

    • Re:ado?? (Score:2, Informative)

      by f00zbll ( 526151 )
      Bussiness customers notice this. Especially if project deadlines are always a problem. The quicker something is done the better.

      I'll bite. Although this statement may seem accurate it is not. Let's take for example companies that provide application services, be it insurance, financial or enterprise resource management. There's nothing wrong with hardcoding everything and removing abstraction layers all together, if the application will stay that way for 1-2 yrs. Having said that, none of the projects I'v

  • Hibernate [bluemars.net]

    It uses XML files to map between databases and Java. Good support for transactions, and more complicated cases.

    A good overview can be found here [bluemars.net]...

  • Online JDO Overview (Score:2, Insightful)

    by awhite ( 179035 )
    If you want to get a technical feel for JDO, Solarmetric [solarmetric.com] has an online document that covers all the spec basics here [solarmetric.com]. It's not as in-depth as a full JDO book, but it covers JDO concepts pretty nicely in about 40 pages (if it were printed).

  • What's after relational? (Score:3, Interesting)

    by Trinition ( 114758 ) on Tuesday May 06, 2003 @08:16PM (#5897466) Homepage
    In my databases 102 class in college (yeah, I passed databases 101), we covered heirarchial, network, and relational databases. More recently, I've learned of object oriented databases (for a free, 100% Java poor-man's OODB, see XL2 [xl2.net]). From everything I've read about OODBs, they would be better solution than RDBMSs for 90% of the stuff I've seen as a Java programmer.

    The negatives I've heard from people in coversation are "they're not as fast", "there ae no tools", etc. BUt each of these are either false, not entirely true, or jyst due to immaturity:

    Too slow Actually, because there is no impedance mismatch (converting from related rows into an Object, and converting the data types between disparate systems), they can be faster than an RDBMS. Where you might have to pull up a person record, and then their home address record, convert their homepage into a URL object, etc... in an OODBMS, your data is (can be) already in the proper Object format. You wouldn't needs things like JDO.

    Tools no available Well, the haven't been around for as many decades as RDBMSs either. And, one of the other things that makes RDBMS tools so numerous is that they have a standard language, SQL. However, you must still rebuild what the data means in your reporting system separately from your online system. In an OODBMS, you would theoretically only build the Classes for the Objects once, and they would have with them the business rules.

    Any thoughts? I'm not an OODBMS bigot, but I'm trying to be an advocate in the hopes that it will have some truly educational dialogue.

    • I've never understood what's special about OO databases - as far as I can tell, they're just either making the rows into objects, or allowing objects to be stored as column data. It may make interfacing with the database easier from an external language like Java, but doesn't actually enhance the database itself - the expressiveness is the same. It may even be worse, if you can't access the data within object columns for selects.

      Something that is a genuine enhancement to databases is deductive databases,

      • OODBMS are not supposed to objectivy rows, and tables. In fact, XL2 (whcih is the only OODBMS I've worked with) does nothing of the sort. It's more like serializing the graph of objects and references you have in memory to disk.

        Now, perhaps some OODBMSs are really object-relational mapping solutions behind the scenes, but I know for a fact that XL2 is not. I've been through the source code and was awed at the simplicity. It is very much like a snapshot of memory on disk.

        Now XL2 is primitive in that it
        • That sounds roughly like what I though, though maybe the terms differ. The object "type" or class corresponds to a set (or table, in RDBMS), and each object of that class is a tuple (or record or row). The object references are basically dataless foreign keys (constraints are implicit - the reference is added when the tuple/object is created, and garbage collection ensures that the object is never destroyed as long as the reference is still there, where in a RDBMS you explicitly delete tuples, and it raises

Slashdot Top Deals

Whatever is not nailed down is mine. Whatever I can pry up is not nailed down. -- Collis P. Huntingdon, railroad tycoon

Close