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( - 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 You may also find what you see at this site interesting

Full Threads Oldest First

Showing messages 1 through 4 of 4.

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

    • "Castor JDO": Simply False Advertising
      2004-03-16 17:35:04  tksrajan [View]

      I am not aganist any frmawork or tool that makes life easier for the developer.

      Unfortunately, most of these do the reverse.I have just completed a project that uses OJB for ORM.This was the tool I had recommended from a host of tools evaluated.

      Guess what? I found this wanting in many areas, with bugs that the auhors do not think worth fixing

      For example if I want to insert records in a batch , ojb.0.9.xx version has no support for it.Likewise if database restarts , I am left with stale connections from the pool.There could be others as well.

      This is of course the issue with open source tools.(You can't complain when the stuff is free).My own experience is to use home grown stuff in areas whose execution is critical for the success of the project, or use products that have support from the vendor,else you will end up debugging the vedor's code instead of your own :)

      As regards developer comunity not comfortable with bytecode manipulation,this becoes a problem when you have a globally distributed develpoment team that uses the same source from a central repository. versioning binaly files in CVS that are actually source, somehow doesn't make sense

      As regards homegrown implemenations, these start at a very simple scale and evelove into full fledged frameworks that support XML mapping, polymorphism, multiple table queries ,complex joins,Object caching and life cycle management.The point is in any well managed project that follows a development methodology( not XP),there is a full set of collateral pertaining to archiecture design and implemenation with profuse documenation will exist. I can vouch for this for all CMM level 3+ or ISO 9001 companies in India.So knowledge transfer is never a problem

      Anyway I don't think what Sun dishes out is always holy writ( same about Microsoft as well).So my suggestion about building on our own if time and money permits


  • "Castor JDO": Simply False Advertising
    2002-12-16 11:49:03 [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
    • "Castor JDO": Simply False Advertising
      2004-03-16 18:04:27  tksrajan [View]


      The problem that I have faced when using third party frameworks (JD, ORM, others) are

      1. Bt their very nature, they tend to include code that I might never have any use for, but which can contain bugs. So I have to be often clever enough to bypas the bug(s) , but yet extract the required functionality

      2. Very little documentation when they are open source.Whatever documenation there is, normally talks about only what works and very often you would want to know about what does not work.Here is a case in point.

      If you hav used JBOSS MQ series(I am refering to the one bundled with JBOSS 3.0.8) , there is a strange problem. A QueueListener that you have registered receives messages whenever some code posts a message to the Queue.This is normal behaviour. However,if JMS server node restarts for whatever reason, the connection factory and connections are stale and so we obtain fresh connection after closing the old listener.We are still able to receive messages on the new connection.

      However there is a clock daemon that runs(don't know where, possibly inside the listener?) which checks for the validty of the connection and throws some spyJmsException every one minute with a message that the ping task failed etc.This is fine when JBOSS is down.But this stacktrace is printed even when normalcy is restored.

      You might ask, so what is the big deal? It works , does it not? Yes, but if my UAT is dependent on my showing a clean log to the client after a 12 hour load test, I need to hack the log4J file so that the messages emitted by the [Connection Monitor Thread] of JBOSS are not logged at all

      Even the $10 documentaion of JBOSS does not contain any reference to this

      So I will state my point slightly differently

      1. If you have the money, go for an implemenation or framework that you know will be supported or that (even open source) where you have extensive experience

      2. If you don't have the money, build one yourself. Simple , initially just concentrating on your immediate needs and slowly developing this to a full fledged framework