[Opensource] JDO resources

[Jan.Moons at alcatel.be]

Another opensource JDO implementation is XORM (http://xorm.org).
The introduction I found on their web site :

XORM uses the API described by the Java Data Objects (JDO) specification
(JSR 12) and implements many of the interfaces specified by JDO. In contrast
to most JDO implementations, XORM does not require you to run a class-file
enhancer before deploying your persistence-capable classes. Instead, XORM
allows you to specify persistence-capable classes using abstract classes or
interfaces; bean-style get()/set() methods are enhanced at runtime to be
managed for persistence.

XORM has been engineered to provide a rapid application development
environment, so you can build and persist Java objects with as little effort
as possible. XORM does not require a custom database schema and does not
create special tables in your database: you can map your Java objects to
most existing schemas, or start from scratch.

I have not used or tested it, maybe in the near future.
I used Castor JDO, but this package isn't actually a 'real' JDO
implementation but it does what I want it to do. So do I need a real JDO
implementation, if I want to use standards : yes !?

If Expresso is eventually going to use JDO maybe we should think about some
test cases for selecting a suitable JDO implementation (open source or
commercial).
And then let people use these test cases to evaluate a certain JDO
implementation. Use these results to select the one that's most suitable for
Expresso ?! Good idea, or not ?!

Kind regards,
Jan


----- Original Message -----
From: "Marc Schipperheyn" <m.schipperheyn at thefactore.com>
To: <opensource at jcorporate.com>
Sent: Friday, January 03, 2003 11:12 AM
Subject: [Opensource] JDO resources


> Mike,
>
> Some resources on JDO:
> http://jdocentral.com
>
> Open source implementations:
> http://jakarta.apache.org/ojb (partial implementation right now)
> http://www.tjdo.org (full implementation)
>
> I haven't tried any yet.
>
> There are also some commercial implementations you can check out on
> jdocentral.com
>
> For my part, it looks very promising. My major gripe right now is that you
> need a bytecode enhancer to make your beans JDO compatible. Apparently
this
> was done to make live easier for programmers and not to convolute code but
> it 'feels' funny. Also, there is a heated debate between an EJB evangelist
> and the JDO evangelist on whether there should be a new standard at all.
The
> basic idea of JDO is to have the programmer not program SQL but program
> against an object API. The expectation is that it may evolve to a layer on
> top of JDBC. I also saw some integration with JCache on some
implementations
> to address performance issues.
>
> It is early days still, but you can check out some thoughts on JDO 2.0 on
> the community forums on jdocentral.
>
> Kind regards,
>
> Marc Schipperheyn
> <theFactor.e>
> Alliance Partner for Macromedia
>
> The future is technological, but it will not be a world of gray steel
>
>
> _______________________________________________
> Opensource mailing list
> Opensource at jcorporate.com
> http://mail.jcorporate.com/mailman/listinfo/opensource
> Archives: http://mail.jcorporate.com/pipermail/opensource/
>