Women in Technology

Hear us Roar



Subject:   "Castor JDO": Simply False Advertising
Date:   2002-12-15 05:40:05
From:   tksrajan
Apparently a lot of water has flown under Thames, since the David Jordan first looked at Castor and the writing of the above article.
CASTOR does not support Sun's JDO standard and that probably saved it from obscurity.Castor like Hibernate,OJB( which proposes to implement the Sun's JDO) use Runtime Reflection very effectively to provide Object Relational mapping and it works perfectly.Infact, OJB uses a persistence broker layer which uses Runtime Reflection to support Sun's JDO and ODMG standards.Source and Bytecode enhancements are not ideas that the developer community will like very much


I don't know ODMG standard , but Castors XML to Java Data binding is pretty cool and works like a peach. Can't say the same about their Object Relational Bridge ( I don't want to associate the JDO name with any one other than Sun).That can be improved. But I hope they do not implement the Sun's JDO spec.Rather, they should look at memory management issues and try to make their implementation leaner.


One advice to all there looking for a tool that will map java objects to database table(s).If you want one, go ahead and build one yourself. It is not that tough. I have a version that I developed, which works pretty well. If you can keep your Attribute name and database column names the same( case does not matter), for most part you won't need any XML mapping as well.If you do, then you may use Castor XML( no kidding, this is a cool tool)


Finally, why is it that Sun and their partners believe that SQL is difficult and we developers find it difficult to use? Why do they thrust languages such as OQL and EJB-QL on us when most of us are perfectly comfortable with SQL? In fact SQL syntax is very simple and as close to a natural language as it can get.The whole stuff is really a lot of hype and only makes things more difficult to an already hapless developer fighting obsolescense.


Therefore, if you must use an Object to Relational Mapping tool, here is my preference, in theorder of greatest importnace


1. Build one yourself and use good old SQL
2. OJB(jakarta.apache.org/ojb/) - Use the
Persistence Broker API
3. Hibernate
4. Castor - tread warily. Memory issues and
problems with nested objects


I am open to comments . My mail id is tksrajan@yahoo.com. You may also find what you see at this site interesting http://www.geocities.com/sundar_rajan_in/

Main Topics Newest First

Showing messages 1 through 2 of 2.

  • "Castor JDO": Simply False Advertising
    2002-12-16 11:49:03  robin@ogilviepartners.com [View]

    Hi Sundar

    Firstly, thanks for posting under your own name instead of anonymously. It is easy for readers to dismiss the credibility of anonymous replies.

    I had a look at your site but found no "category" for object-relational mapping or relational database access. Are your views on this subject covered under another topic?

    SQL allows field-level access to data. As such it is a very efficient API, its only big drawback being the lack of syntax-checking available for SQL at java compile time, which itself is quite understandable.

    If you like working with SQL and believe it is no hinderence to your application development efforts you should probably continue to use it.

    However, if you feel that:
    1. Your SQL development is time-consuming, or
    2. Your home-grown infrastructure is not sufficiently flexible (e.g. lack of true polymorphism), or
    3. Your applications depend on the presence of a relational database when another paradigm may better suit some deployments (e.g. binary file, ODBMS, etc), or
    4. Your SQL infrastructure is making your domain model inflexible (field names matching column names, and classes not spanning multiple tables, would be prime examples), or
    5. Your SQL infrastructure is "castrating" your object model (value objects with little domain-specific behaviour, but lots of load-save-from-db behaviour), or
    6. Your SQL infrastructure requires developers to have a significant level of skill in (a) SQL and (b) your proprietary infrastructure, or
    7. Your application is based on an infrastructure known in detail by only one or two developers who might (a) leave or (b) make excessive wage demands (I put that one in for fun!)

    ...then you should consider JDO.

    JDO provides a standard infrastructure that:
    1. Is a standard, and
    2. Is widely implemented by vendors competing on Quality of Service, and
    3. Enables applications to be independent of data store paradigm (relational DB, object DB, etc.), and
    4. Still lets you use SQL if you wish (the Query interface lets you specify a query language other than JDOQL), and
    5. Provides "Transparent Persistence" - for more info read my book "Java Data Objects" in paperback or PDF, or email me, and
    6. Deploys in a client-server, web, or enterprise context, with all the scalability characteristics you'd expect (particularly on the web/enterprise tier), and
    7. Is really cool (I put that one in for fun too!).

    No-one said you must use JDO...but I suggest that those who employ JDO wisely will have strategic advantage in software development over competitors who do not, which could be cruicial in the current IT marketplace.

    And if you do choose the JDO standard, remember to exclude so-called "Castor JDO" from your evalautions! Ok, I think we've rammed that one home now ;-)

    Kind regards, Robin.
    Robin M. Roos
    www.OgilviePartners.com
  • "Castor JDO": Simply False Advertising
    2003-05-04 19:59:40  tomdavies [View]

    You say:"Source and Bytecode enhancements are not ideas that the developer community will like very much". Why would people object to Bytecode enhancements?

    If you think that building an ORM yourself is easy, then you probably don't understand all the things which a JDO implementation can do for you:

    - transparency, due to persistence by reachability you don't need to explicitly make instances persistent.

    - support for inheritence.

    - management of relationships between instances, again transparently.

    - caching.

    I too have written a simple ORM, but I now use JDO extensively, and find that it saves a lot of effort.

    Tom