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

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

Re:

[H4x0r Jim Duggan]

Technology solves some problems, and being free to help yourself and cooperate with others solves other problems. If you want both technical superiorty and the freedoms of free software [fsfeurope.org], it's best to use the free software product.

With the technically superior product, you can't do anything to make it free. But with the free software product, you can make and support technical improvements to it - in the directions that you want them.

So the good long term bet is the free software package. S

If you aren't using Hibernate....

[Safety Cap]

WTF are you doing?

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

[cs02rm0]

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

Re:

[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 t

Re:

[Cyberax]

BS.

HQL is just another way of writing SQL, it doesn't insulate you from the database. Of course, it's not easy to use special DB-specific features in HQL, but that's why it's possible to use raw SQL in Hibernate. And you usually need these features only in 10% of queries with other 90% working nicely with HQL.

And most often 'unusable for Hibernate' database scheme just means that your 'SQL gurus' know nothing about normalization and treat tables as plain text files.

Good legacy schemes can be converted very

Re:

[Gr8Apes]

BS. ...
And most often 'unusable for Hibernate' database scheme just means that your 'SQL gurus' know nothing about normalization and treat tables as plain text files.

Good legacy schemes can be converted very nicely. ...

Actually, "unusable for Hibernate" DB schemes come about from a lack of good DBAs being around to say "HEY - DON'T DO THAT!!!". I have, unfortunately, had to deal with more of those than well-designed DBs. Those bad DBs make JDO or Hibernate suck wind to use, if you can get them to work at all. Oh, and JDO sucks anyways. I'm still on the fence about Hibernate. Looks nice, but....

Re:

[Cyberax]

Yes, good DB schemas designed by real DBAs usually work fine with Hibernate.

Unfortunately, a lot (most?) of legacy applications are not designed properly so Hibernate doesn't work well with such schemes (iBatis does, BTW). But it has nothing to do with HQL insulating you from the power of database.

And yes, JDO (I won't even mention EJB2) sucks.

Re:

[Gr8Apes]

And yes, JDO (I won't even mention EJB2) sucks.

I won't mention EJB3 either... ;)

Re:

[Cyberax]

Actually, EJB3 is not that bad, because it is Hibernate :)

Re:

[ChunderDownunder]

To clarify, EJB3 uses the Java Persistence API. Hibernate's creator had a hand in designing these.

JPA is used as a layer above ORM implementations such as TopLink and Hibernate.

Re:

[DuckDodgers]

Nothing stops you from using plain SQL in hibernate. I use the Hibernate Query Language or Query By Criteria for anything that involves one or two tables, but for queries that involve more than that I use named SQL queries and stored procedures.

On the other hand, the learning curve is really steep. I don't have experience with any other ORM for comparison, but it took me almost a year of occasional use to get really comfortable with it.

Re:

[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, et

Re:

[rossifer]

In my experience, when building a significant database/Java app, you've got two choices:

• Table data driven.
• Domain model driven.

If you choose table data driven, you rely on one or two skilled database developers (it's a huge mistake to assume that even great DBA's have any clue at database design, though all will claim they do) to create a clean, performant data model. The Java portion of the system is basically just a procedural presentation layer for the database.

Pros:

• You can make a very clean database, de

Re:

[doktorjayd]

+1

Re:

[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 implement

Re:

[Raenex]

This reads like an advertisement. It is also deceptive to say it is open source. Part of it is based on open source, but Kodo proper contains open source and non-open source code.

Re:

[penfern]

yeah, i know it sounds like an advertisement, but it's my own personal opinion having used both products, and actively using it on protrade.com. I would personally discourage anyone from using hibernate and encourage a look at kodo for any large commercial/production site.

Yup, the core "kernel" is open and the ejb3 interface is open, but not the JDO interfaces, but they are both implemented by the shared "kernel".. sorry http://dev2dev.bea.com/pub/a/2006/02/interview-kod o-opensource.html [bea.com]

Re:

[ChunderDownunder]

Using JPA, perhaps. Hibernate has a specific implementation of JPA, as does TopLink.

Gavin King, Hibernate visionary, had a hand in designing the JPA through his role on the EJB3 committee.

Using an implementation-neutral API for ORM enables flexibility. One can choose from multiple J2EE servers, servlet engines, databases and now JPA implementations.

Hibernate can now be a deployment option, of several JPA implementations; it doesn't have to be coupled to one's code.

Re:

[Palshife]

It doesn't. In ORM, you want to map your tables and their fields to classes directly, then use the ORM's query engine to accomplish such feats. So for your example, Customer and Order would be classes. The query itself would be similar, but adapted for the ORM system you're using.

This is good news

[ishmalius]

I have been a Java programmer ever since it existed, but have only delved into the EJB side of things recently. I started using JPA a few months ago, and have tried Hibernate and TopLink Essentials (the default engine in J5EE). Hibernate is large and all-powerful, but for my needs, I have found TopLink to be a light, fast, and very clean design. The Glassfish developers have refactored and cleaned up a lot of the legacy code, and have cherry-picked a lot of the best design features from the other impleme

Re:

[Gr8Apes]

Umm, you didn't use a data abstraction layer (framework) with caching in your own code?

That's like rule #1 for improving performance and increasing scalability of your application.

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.

Re:

[Gr8Apes]

Absolutely!!!! That hits the nail squarely on the head.

Code to standards or roll your own. Forget these proprietary one-off solutions. All they do is tie you to a single vendor's single version. (Take a look at the pain involved in even migrating between versions of a single vendor's solution.)

Re:

[Raenex]

Code to standards or roll your own.

Well if you had coded to the original EJB standard you'd still be stuck with a painful migration, since it was a piece of crap. EJB only started looking reasonable after they copied the ideas from the very open source projects you are disparaging.

Rolling your own is not necessarily a good solution either, if it costs you more time and money than an off-the-shelf solution. Either way you have to pay the migration cost if something better comes along.

Re:

[Gr8Apes]

Code to standards or roll your own.

Well if you had coded to the original EJB standard you'd still be stuck with a painful migration, since it was a piece of crap. EJB only started looking reasonable after they copied the ideas from the very open source projects you are disparaging.

EJB only started looking reasonable? You've been drinking the kool-aid.

EJB sucks.

I have yet to see a problem that EJB "solves" that isn't better served by some other solution, including distributed transactions. It's a klunky overly verbose boilerplate generating POS. Annotations remove some of the tedium of the boilerplate, but still leaves you with the manual generation of a slew of crap to dictate visibility and so on. WTF it couldn't just have been "write a POJO - all public methods are visible both l

Re:

[ClamIAm]

Spring/Hibernate/ActiveMQ/Acegi/XFire/Kitchen Sink

Oh wow, for a sec I thought you were talking about a different Xfire [xfire.com]... ...or being sarcastic :)

Re:

[McLoud]

Mod points! My DAO's for modpoints! Mod parent way up!

Re:

[Gr8Apes]

Heck - you should be modded up.

Spring's primary raison d'etre is a solution looking for a problem. In their about page, they even mention it as a primary reason for its existence: "Testability is essential, and a framework such as Spring should help make your code easier to test." This can be read as "use dependency injection to easily test your code". Last time I looked, adding code specifically for testing into your production code is considered a "bad practice". Most implementations of Spring I've seen h

iBATIS

[manniwood]

For many (most?) needs, iBATIS is actually better. It does SQL mapping instead of O/R mapping.