Slashdot Mirror
Oracle Open Sources TopLink Java ORM
Eric^2 writes "Oracle announced on Tuesday that TopLink will now be open source and a full-fledged Eclipse project. TopLink is an object-persistence layer for Java that maps Java objects to a relational database."
Way back in the day (2001), I was evaluating ORM solutions to replace the "roll-our-own" orm in our Java app. Took a look at Cocobase, TopLink, JDO (just appearing), and Java Relational Bridge. Hibernate was not ready for prime time (yet).
TopLink was the only offering that ate it's own database on a regular basis. I fell back to hourly saves, and making full copies of the XML text that they were using to save the O-R mapping information. At one point, I accidentally overwrote one of the prior saves and discovered that all saves over the last day had been corrupt anyway, and I gave up on the pretty tool. Then we went to fell back to hand-editing mapping files and modifying our domain objects to fit into the framework. Ouch. Lots of references to *.toplink.* appeared in the import lists. Several relationships didn't have strong support (map of named sets: had to make a new object type for the map, trinary relation: again, make a new kludge class).
Nowadays, if you don't HAVE to use stored procedures, use Hibernate. You'll have to adapt your code to it in a few small ways (cascade delete sequencing, persisting inherited properties), but basically, it just works.
Ross
Using ibatis because it's easy if you already have SQL gurus, performs better and integrates with an existing data model more easily.
While I applaud Oracle's move - I still don't know why any developer would consciously choose a single persistence solution and code to it when the Java Persistence API (JPA) standardizes the whole mess into a single, platform portable specification. Case in point - with my employers latest enterprise application, we decided to migrate to a true EE5 stack over some convoluted analgum of Spring/Hibernate/ActiveMQ/Acegi/XFire/Kitchen Sink, and originally pursued Glassfish as our container. After months of some successes and a lot of pain with some of Glassfish's less mature features and bugs, we decided to give JBoss 4.0.5 a run. Because we coded our persistence to JPA and not specifically to Hibernate or Toplink, we were able to pretty much effortlessly migrate between platforms, with the only real work being required when setting up container resources in each container (JMS Destinations, Connection Pools, et. al.). Glassfish uses TL as its underlying persistence implementation, and JBoss uses Hibernate. It was all the same to us.