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."

Comments

old bad memories

[rossifer]

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

If you aren't using Hibernate....

[Safety Cap]

WTF are you doing?

Re:If you aren't using Hibernate....

[cs02rm0]

Using ibatis because it's easy if you already have SQL gurus, performs better and integrates with an existing data model more easily.

Re:If you aren't using Hibernate....

[lemnik]

Hibernate is a very heavy OR mapping layer, and I've never had much joy using it. It detracts massively from what the database is truly capable of, in effect removing the power that SQL gives you by replacing it with a crippled Object query language. Hibernate is great, as is JDO, but they are both heavy weight tools that take away much of what a database gives you in the first place.

I find using JDBC far more powerful, since I can actually use my database without having to create hundreds of VIEW's on top of my actual tables. The fact that OR mapping layers take SQL out of my hands is the entire reason I started a clone of the EoD RI layer from Java 6 beta. So far it's been the only system I've worked with that allows me to model objects (rather than my database), but retains lets me use SQL directly.

Hibernate and JDO and such are great for new projects, but when trying to work with a legacy >200 table Informix database, they just doesn't cut it. The database has been modeled for SQL, not your lovely Object model (which winds up behind a business object layer anyway). In the end, deal with your database, or don't use one. They're hugely powerful systems, don't cripple them just because you don't understand how to make them work!

Re:If you aren't using Hibernate....

[Shados]

There are architectural concerns in using something like Hibernate, that forces you into using a domain model type of software design to your application. I personally think that if there is a good architect around, it can be done smoothly and the time saving benifits are amazing, so I'm all for using ORMs, but there's another side of the story where some architect (mostly in the windows world, but it is -far- from being limited to it) who think that its the job of the RDBMS (and thus, stored procedures, etc) to handle all of this stuff, and that an application should never make its own SQL, siting certain headaches for the DBAs, and some theoritical architectural issues with it.

Anyhow, all that to say, Hibernate is awesome, but from a certain point of view, its similar to putting business logic straight in the JSP file (I disagree though)

Re:If you aren't using Hibernate....

[penfern]

I am definite that Hibernate is not up to the task - at least for our systems. We tried it, we disliked it, and eventually moved away from it. And I am sooo glad we did, because it really would not have handled out load properly!

I strongly, strongly recommend any java developers to look at Kodo (http://www.bea.com/kodo), it is an ORM with both JDO and EJB3 interfaces so it can do both .jdo mappings or ejb3 annotations. It really is enterprise quality, with many features and flexibility all well implemented. The developers behind it are really smart. And yes it's open source!

Anyway, I just owe them a debt of gratitude, our tech would not be the quality it is now if we had gone the hibernate route.. but that's just my opinion.. just go have a look at Kodo.

Use the Java Persistence API

[JavaSavant]

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.