Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Oracle Open Sources TopLink Java ORM

CowboyNeal posted more than 7 years ago | from the have-at-it dept.

Java 41

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

cancel ×


Sorry! There are no comments related to the filter you selected.

Great. Another abandonware... (-1, Troll)

joto (134244) | more than 7 years ago | (#18286286)

Who the fuck needs any of these object-persistence layers anyway?

Re:Great. Another abandonware... (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18286476)

Don't ask questions, just let the 150$/hr contractors do their job.

old bad memories (4, Informative)

rossifer (581396) | more than 7 years ago | (#18286460)

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.


Re:old bad memories (1)

H4x0r Jim Duggan (757476) | more than 7 years ago | (#18290370)

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.

Re:old bad memories (0)

Anonymous Coward | more than 7 years ago | (#18315347)

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.

If you aren't using Hibernate.... (2, Informative)

Safety Cap (253500) | more than 7 years ago | (#18286530)

WTF are you doing?

Re:If you aren't using Hibernate.... (3, Informative)

cs02rm0 (654673) | more than 7 years ago | (#18286986)

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.... (2, Interesting)

lemnik (835774) | more than 7 years ago | (#18286990)

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

Anonymous Coward | more than 7 years ago | (#18287004)

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.

Re:If you aren't using Hibernate.... (1)

Cyberax (705495) | more than 7 years ago | (#18287696)


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.

Re:If you aren't using Hibernate.... (1)

Gr8Apes (679165) | more than 7 years ago | (#18288278)

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:If you aren't using Hibernate.... (1)

Cyberax (705495) | more than 7 years ago | (#18288912)

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:If you aren't using Hibernate.... (1)

Gr8Apes (679165) | more than 7 years ago | (#18288960)

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

Re:If you aren't using Hibernate.... (1)

Cyberax (705495) | more than 7 years ago | (#18289254)

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

Re:If you aren't using Hibernate.... (1)

ChunderDownunder (709234) | more than 7 years ago | (#18294570)

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:If you aren't using Hibernate.... (1)

DuckDodgers (541817) | more than 7 years ago | (#18293300)

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:If you aren't using Hibernate.... (2, Interesting)

Shados (741919) | more than 7 years ago | (#18287262)

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

rossifer (581396) | more than 7 years ago | (#18301180)

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.

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

  • 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.
  • 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 database can be tuned and tweaked, but it's more difficult to do well since the application is interfacing against tables/views, instead of stored procedures.
  • It is nearly impossible to make this architecture perform at the same level as the data driven architecture, though the difference is usually a factor and not a different curve (O(N), O(NlogN), etc.)
  • You can only really keep a system maintainable if your developers are using personal and team processes that value maintainability.
    1. Hire great Java designer/developers.
    2. Quickly fire those who turn out to be bad team members. This is more corrosive than an underperformer.
    3. Get multiple eyeballs on all changes to the code. Pair programming, code reviews, whatever works for you.
    4. Consistently use sane coding, design, and documentation conventions. ("consistently" means everyone uses them, even if someone has his own pet conventions that he is certain are better). *
    5. Automated regression tests, hopefully lots and lots of functional/unit tests.

* this is where the data driven architecture falls down. The conventions needed are in substantial conflict with OO best practices.

In my experience, the eventual trade-off is that the data driven architecture almost inevitably becomes an unmaintainable rat's nest of tightly coupled procedural code, while the domain driven design is easier to change, but never reaches the same level of performance on the same hardware. As a systems architect, I have to say that IMNSHO, hardware is cheap, and I value the ability to add the next critical feature quickly and fix bigger bugs more than I value the last 20-30% of possible performance tuning.

Re:If you aren't using Hibernate.... (0)

Anonymous Coward | more than 7 years ago | (#18316413)


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.

Re:If you aren't using Hibernate.... (0)

Anonymous Coward | more than 7 years ago | (#18287844)

Using Cayenne...

Re:If you aren't using Hibernate.... (1)

doktorjayd (469473) | more than 7 years ago | (#18297996)


Re:If you aren't using Hibernate.... (0)

Anonymous Coward | more than 7 years ago | (#18288930)

JPA. :)

Re:If you aren't using Hibernate.... (2, Interesting)

penfern (760298) | more than 7 years ago | (#18289296)

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 (, 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.

Re:If you aren't using Hibernate.... (1)

Raenex (947668) | more than 7 years ago | (#18301890)

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:If you aren't using Hibernate.... (1)

penfern (760298) | more than 7 years ago | (#18305098)

yeah, i know it sounds like an advertisement, but it's my own personal opinion having used both products, and actively using it on 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 o-opensource.html []

Re:If you aren't using Hibernate.... (1)

ChunderDownunder (709234) | more than 7 years ago | (#18294394)

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.

You mean "SQL database".. (0)

Anonymous Coward | more than 7 years ago | (#18286638)

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

Re:You mean "SQL database".. (1)

Palshife (60519) | more than 7 years ago | (#18287704)

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.

low priority (0)

Anonymous Coward | more than 7 years ago | (#18286772)

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!


This is good news (1)

ishmalius (153450) | more than 7 years ago | (#18286784)

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.

Re:This is good news (1)

Gr8Apes (679165) | more than 7 years ago | (#18288358)

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 (4, Interesting)

JavaSavant (579820) | more than 7 years ago | (#18287460)

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:Use the Java Persistence API (1)

Gr8Apes (679165) | more than 7 years ago | (#18288386)

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:Use the Java Persistence API (1)

Raenex (947668) | more than 7 years ago | (#18301950)

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:Use the Java Persistence API (1)

Gr8Apes (679165) | more than 7 years ago | (#18314953)

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.

Re:Use the Java Persistence API (1)

ClamIAm (926466) | more than 7 years ago | (#18292920)

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

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

Re:Use the Java Persistence API (1)

McLoud (92118) | more than 7 years ago | (#18295946)

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

Re:Use the Java Persistence API (1)

teknopurge (199509) | more than 7 years ago | (#18300578)

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.

Re:Use the Java Persistence API (1)

Gr8Apes (679165) | more than 7 years ago | (#18315121)

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

iBATIS (1)

manniwood (531020) | more than 7 years ago | (#18288006)

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

Re:iBATIS (0)

Anonymous Coward | more than 7 years ago | (#18294338)

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

WTF does that mean?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>