Slashdot Mirror

← Back to Stories (view on slashdot.org)

Oracle Open Sources TopLink Java ORM

Posted by CowboyNeal on from the have-at-it dept.

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

41 comments

  1. old bad memories by rossifer · · Score: 4, Informative

    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

    1. Re:old bad memories by H4x0r+Jim+Duggan · · Score: 1

      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, 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. Stallman explained this well last November in Tokyo:

      So this is good news.

      --
      Please help publicise swpat.org - the software patents wiki
    2. Re:old bad memories by Anonymous Coward · · Score: 0

      In this case, the technically superior product is... Java EE 5.

      It has been out for almost a year now. I suggest the parent and grand parent get out of the dark ages (Hibernate, J2EE), and get with the program.

  2. If you aren't using Hibernate.... by Safety+Cap · · Score: 2, Informative

    WTF are you doing?

    --
    Yeah, right.
    1. Re:If you aren't using Hibernate.... by cs02rm0 · · Score: 3, Informative

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

    2. Re:If you aren't using Hibernate.... by lemnik · · Score: 2, Interesting

      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!

    3. Re:If you aren't using Hibernate.... by Anonymous Coward · · Score: 0

      You might like to try ibatis. I have the same issues with Hibernate and JDO that you do, but I find ibatis does a pretty good job of taking the best of both worlds, weird name aside.

    4. Re:If you aren't using Hibernate.... by Shados · · Score: 2, Interesting

      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)

    5. Re:If you aren't using Hibernate.... by Cyberax · · Score: 1

      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 nicely. Recently, we've converted a _very_ legacy application with 500 tables in Sybase to Hibernate+Postgres, it required changing about 15 tables of accumulated cruft (and rewriting SPs, of course).

      iBatis and raw JDBC is fine, if you have a brain-damaged schema and can't work around it.

      BTW, Hibernate data objects can used in business layer quite nicely and they can double as DTOs.

    6. Re:If you aren't using Hibernate.... by Anonymous Coward · · Score: 0

      Using Cayenne...

    7. Re:If you aren't using Hibernate.... by Gr8Apes · · Score: 1

      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....
      --
      The cesspool just got a check and balance.
    8. Re:If you aren't using Hibernate.... by Cyberax · · Score: 1

      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.

    9. Re:If you aren't using Hibernate.... by Anonymous Coward · · Score: 0

      JPA. :)

    10. Re:If you aren't using Hibernate.... by Gr8Apes · · Score: 1

      And yes, JDO (I won't even mention EJB2) sucks. I won't mention EJB3 either... ;)
      --
      The cesspool just got a check and balance.
    11. Re:If you aren't using Hibernate.... by Cyberax · · Score: 1

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

    12. Re:If you aren't using Hibernate.... by penfern · · Score: 2, Interesting

      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.

    13. Re:If you aren't using Hibernate.... by DuckDodgers · · Score: 1

      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.

    14. Re:If you aren't using Hibernate.... by ChunderDownunder · · Score: 1

      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.

    15. Re:If you aren't using Hibernate.... by ChunderDownunder · · Score: 1

      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.

    16. Re:If you aren't using Hibernate.... by doktorjayd · · Score: 1

      +1

    17. Re:If you aren't using Hibernate.... by rossifer · · Score: 1
      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, designed exactly the way your DBA's think it should be designed.
      • If your dev cycle takes more than a week to produce and deploy a patch to the app server code, it's fairly simple to change stored procedures, tables, and anything else in the database to respond to scalability issues in production without disrupting the running application.
      • This architecture usually offers more "knobs" with which to tune performance, and can usually be made to perform faster than the object driven system. (in my experience, YMMV...)

      Cons:

      • Your Java devs will chafe because from a Java developer's perspective, the Java part of the app has a crap design. You're going to get constant whining about the lack of OO, interfaces, etc.
      • Your DBA's will have lots of opportunities to "fiddle", which can be very risky because although they can tune the living shit out of what the system is doing right now, but won't understand what their fiddling will do to the maintainability of the presentation (Java) layer.
      • Locating business logic sanely is an enormous challenge. This app is largely owned by your DBA's, but a significant fraction of the business logic should be in the Java because it will be easier to answer many questions there. Remember the DBA's fiddling and what that does to system maintainability?
      • It's hard to write good procedural code using an OO language. Skilled Java developers will perpetually be trying to write OO code, which will conflict with the role of the Java application: to be a procedural presentation layer.
      • The Java guys will eventually force some limitations on the DBA's, who will chafe that the Java guys don't understand data.

      If you choose a domain model driven architecture, you rely on one or two people with both Java and database design skills (it's a huge mistake to assume that even great Java devs have the slightest clue about data modeling, you need to find people with both skills) to create a clean, performant data model along with a set of domain objects that represent that data in the Java portion of your app.

      Pros:

      • Your Java can be Object Oriented, well-designed, interface/implementation separation, etc.
      • Your database can still be cleanly designed, though it won't look exactly the same as if DBA's had designed it. Basically, some normalization decisions will end up different because of the additional information available to the designer(s).
      • The Java group is happy.
      • The domain objects are loosely coupled to the tables/views instead of tightly coupled to the stored procedure result sets. This is good because changes to the system have to take both Java and RDBMS portions into account and the system likely to remain maintainable.

      Cons:

      • No matter how much expertise your Java/database guys have, your DBA's will chafe, because:
        • they didn't design the database and they wouldn't have come up with the same design.
        • They don't have full freedom to use all of their DBA skills on the app tables.
        • Caveat: your best DBA's will realize that this means they can focus on higher-level database problems and will actually be happier.
      • The domain objects are loosely coupled to the tables/views instead of tightly coupled to the stored procedure result sets. This is bad because the clean break under the stored procedures allowed easier optimization of the database, separate from the app server.
      • The
    18. Re:If you aren't using Hibernate.... by Raenex · · Score: 1

      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.

    19. Re:If you aren't using Hibernate.... by penfern · · Score: 1

      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

    20. Re:If you aren't using Hibernate.... by Anonymous Coward · · Score: 0

      Rossifer,

      Very nice post.

      I'd like to suggest a third alternative, which I have found combines the best of both worlds. I would call this approach "Logical Data Model Driven Approach". Basically, get your DBAs and your Java devs to agree on a logical data model. The logical data model is neither a physical data model nor an object domain model. I've found that you will have to use some type of ERD to capture this design, because the vast majority of DBAs don't speak UML, but a fair number of Java devs are conversant with an ERD. If you're a large enough shop, you might actually have a modeling team that can help. If not, my experience has been that a design in which the Java devs worked out an ERD before a UML object model is usually superior. The reason is that in most cases, it makes more sense to model the data in its right, rather than believing the data is just there to serve the application. Both the domain model approach and the table driven approach can easily lead to a situation in which the data is too closely coupled with the application. The view layer is a good way of encapsulating the logical design. OO purists cringe, but there are other ways of encapsulation besides an OO class hierarchy. Any third party tool that speaks SQL can interface with the logical design view layer. The same cannot be said if the domain model maps directly to a set of physical tables.

      Given a logical design as a starting point, the DBAs can then implement a physical design based on this logical design. The logical design can be a set of views, and the physical design includes the tables, triggers, procedures, sequences, constraints, and indexes. Logic in the triggers and procedures is "data logic" rather than business logic. This logic is solely responsible for translating between logical and physical, as well as implementing other data constraints that are not directly representable as a formal constraint. This gives the DBAs lots of opportunity to tweak performance without violating the logical data design contract expressed by the views.

      The Java devs in turn can build whatever ORM mapping they need based on the logical data model, and can implement the business logic on top of that, without having to deal with nitty-gritty issues such as sequence number generation.

      The amount of chafing from both the DBA and Java sides of the house will be minor in comparison with the chafing that the "marginalized" side will utter in either the data table approach or the domain model approach.

      If you build a logical data model first, you can leverage the unique strengths of the database layer and the application server layer. The data quality and application quality will be demonstrably higher.

      Bear in mind though that just as there are multiple distinct skill sets within the Java sphere, so to with the DBA sphere. The skill sets to be a good operational DBA are different than to be a good development DBA. Make sure you select individuals appropriately.

  3. You mean "SQL database".. by Anonymous Coward · · Score: 0

    Java objects to a relational database

    A "relational" database would store objects directly, avoiding this need for the clusterfuckage known as "ORM".

    Question for the ORM-lovers: what class does the table returned by this query map to:

    SELECT "banana" AS fruit, Customer.first_name, Order.order_id FROM Customer NATURAL JOIN Order

    1. Re:You mean "SQL database".. by Palshife · · Score: 1

      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.

      --
      Attention deficit disorder is a complicated issue, spanning several major... HEY LET'S GO RIDE BIKES!
  4. low priority by Anonymous Coward · · Score: 0

    If, by this stage, you have suffered through not *knowing* what is wrong with your magical persistence machine, you might have some value for this.

    Hibernate, iBatis, all the rest ended up winning the "battle" because you could hyperlink your way into the java bowels of the middleware and figure out why your stuff isn't working. Well, that and you didn't need bizarre-o transfer objects...

    So, this is great if you're still using it (probably lots of people are) but, wow! Talk about a day late and a dollar short!

    -G

  5. This is good news by ishmalius · · Score: 1

    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 implementations. I imagine that this new code contribution will be able to provide a lot of the add-on tools that the average guy needs.

    At first I didn't know what Persistence could add to my app. But I have been very impressed by the speed increase that caching the business object tree on the server side provides over low-level SQL manipulation.

    1. Re:This is good news by Gr8Apes · · Score: 1

      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.

      --
      The cesspool just got a check and balance.
  6. Use the Java Persistence API by JavaSavant · · Score: 4, Interesting

    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.

    1. Re:Use the Java Persistence API by Gr8Apes · · Score: 1

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

      --
      The cesspool just got a check and balance.
    2. Re:Use the Java Persistence API by ClamIAm · · Score: 1

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

      Oh wow, for a sec I thought you were talking about a different Xfire... ...or being sarcastic :)
    3. Re:Use the Java Persistence API by McLoud · · Score: 1

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

      --
      sign(c14n(envelop(this)), x509)
    4. Re:Use the Java Persistence API by teknopurge · · Score: 0

      Please mod parent up.

      And don't be a sheep. I have screened more then 50 resumes in the past year for my proejct.(I'm the application architect) and the sheer amount of buzzwords is staggering. I especially love to probe the "Hibernate/Spring/Strus" crowd and see if they really know what they are talking about.

      With regards to Hibernate, please, PLEASE, don't just use it because it is trendy. Hibernate is not a cure-all and works well only when your schema is object oriented. If you have lots of intersection tables, like many large(>1 billion records) applications, kiss your performance goodbye.

      Use the right tool for the right job. There is not one tool for every job, except for the JLS.(Java language Spec.) When you get into implementations, you need to pick-and-choose.

      --
      Website Hosting
    5. Re:Use the Java Persistence API by Raenex · · Score: 1

      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.

    6. Re:Use the Java Persistence API by Gr8Apes · · Score: 1

      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 locally and remotely by default" is beyond me. Yes, you may not want them all visible, but that's the exception to the rule - you are, after all, writing a bean to plug in somewhere. That's the entire point of EJBs. (Overly simplified)

      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. If you've rolled your own and coded to standards, generally migration costs are close to nil if you even need to migrate in the first place. If you've used some off the shelf solution that is not following standards, you sometimes get into big hairy updates. Here are a few offenders: BEA (Weblogic, Portal), IBM (Websphere), ATG (Dynamo), and ECM (Documentum). All four of those have had issues with their proprietary implementations between even point releases. ATG even had issues if you didn't use their proprietary tags. Documentum has issues merely installing on the latest JDK releases.

      And the kicker? You have to upgrade all of these products because maintenance on them skyrockets after they've been "sunsetted". When your business depends on such a product, not having maintenance is not an option (the CYA issue).

      Of course, if you didn't use their proprietary hooks in the three appservers listed, updating is usually a minor issue other than testing. If you did use any, or any products that did, the upgrade cycle becomes a rather painful process as things break, or behave differently than you're expecting, and your entire dev team gets sucked into discovering what all the little flaws are. I've seen ATG and Websphere updates take almost 12 months before being vetted by QA to run in production. Weblogic took over 6 months. And those were the entire dev teams involved. And this isn't a one-time cost, almost every must-do upgrade is that painful, and you'll have to do one at least every 2 years.

      So I ask you - what did running COTS "save" you in the end?

      Now, I should also point out that I use tools like log4j, struts (yick:), and various other packages. I've also used a home-grown data abastraction layer that survived unchanged through 5 years of various upgrades on multiple systems. They all have one thing in common though - they're all designed to run on a standard implementation of the JVM/EE. Upgrades of the underlying infrastructure that these tools run on are usually painless.
      --
      The cesspool just got a check and balance.
    7. Re:Use the Java Persistence API by Gr8Apes · · Score: 1

      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 have this "feature" purely to allow for testing. The other bad thing about dependency injection is that you've now broken compile time checks and have to depend upon runtime checks. This can also tie a two ton anchor around your developers necks.

      You're also spot on about Hibernate. Nice product, worlds better than JDO, but sometimes you just need custom actions with your DB that only SQL/custom code can perform. If you're already writing the custom code, you might as well access your data directly through SQL/stored procs, especially in cases that involve tens of thousands or more rows in multiple tables. ORM solutions do not handle those scenarios well. (In my case, I've almost always needed this capability, we've tried EJB persistence BLEAH!!, JDO - even bigger BLEAH!!! as it took much longer to get to the point that you could affirmatively state that JDO sucks rocks, and Hibernate bleah as it was only a couple of days to realize it wasn't going to handle our needs. (Hibernate's quick turn around is one of the reasons I like it, at least you don't spend weeks or months building and testing and tuning things before realizing its innappropriate:)

      --
      The cesspool just got a check and balance.
  7. iBATIS by manniwood · · Score: 1

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

    1. Re:iBATIS by Anonymous Coward · · Score: 0

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

      WTF does that mean?