Women in Technology

Hear us Roar



Article:
  Flawed Understanding of JDO Leads to FUD
Subject:   Both articles miss the mark
Date:   2002-06-05 16:26:35
From:   jherr2002
In all this talk of lines of code, simplicity and object mapping, where is the talk of problem applicability?


Where is a discussion on where JDO is a fit as a solution, and where it is not? Is JDO the one size fits all database access solution for all customer problems?


What I would like to see is some real world examples of SHIPPING large scale applications that have used these technologies to provide a comparison study.


Lack of case studies gives me the impression that this technology is bleeding edge. Some projects will want to be on the bleeding edge while others may not. Unbiased information on these matters aids developers in making informed decisions about what is acceptable risks for projects. It's also, coincidently, what makes for a good article, and what is lacking from these articles.


There is nothing wrong with saying, "For mission critical projects you will probably want to stay within the proven technologies of SQL and (to some extent) JDBC. However, for cutting edge experimental projects where (state a good customer requirements case here) we suggest that you might want to invest some time looking at the feasibility of a JDO solution."


On a specific point, there is some talk of JDO's shortcomings against direct SQL access, but no proposed solutions.


In short this artice continues the onjava.com tradition of empty marketing hyperbole that imparts little real world data or experience.


Full Threads Newest First

Showing messages 1 through 1 of 1.

  • Both articles miss the mark
    2002-07-30 22:39:59  eepstein [View]

    Definitely NOT bleeding edge.

    If you look at most J2EE applications you will see huge mounds of custome object-relational mapping code. Some of the "cooler" newer versions have the mapping driven my xml files that are most often used to drive code generation. Simply put, JDO, finally, gives all those folks a rest: code the business logic and let the tedium of OR mapping be part of the infrastructure.