db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Topping <topp...@codehaus.org>
Subject Re: Apache JDO 2.0
Date Thu, 07 Apr 2005 05:52:00 GMT
Craig Russell wrote:

> Hi Brian,
> On Apr 6, 2005, at 6:09 PM, Brian Topping wrote:
>> Hi gang,
>> I started on a Maven plugin for the project (trivial, really), but it
>> struck me that I don't know what the plan is for 2.0 so I thought I
>> would ask.  Are we planning on rewriting everything from scratch?  As I
>> was looking over things today, I got to thinking that the enhancement
>> could be helped along by using something like ASM or CGLib.
> There are a number of people whose opinions I respect that have come 
> around to the opinion that ASM is the way to go. If we need to go. The 
> JDO 1 reference enhancer needs and uses a proprietary byte code 
> analysis and generation tool and it's not clear that changing it out 
> is a priority, but I'm not the expert on this code base. I do know 
> that it's been very reliable and almost functional enough for our 
> purposes. But for J2SE 5, we will need to add functionality to 
> accommodate enums, assert, annotations, and possibly generics. These 
> requirements might be added to the current library or we might want to 
> redo the tool to use ASM.

J5 is the reason I was bringing this up really.  We know that they are 
going to keep moving forward with support for future JDK classfile 
formats, and with different features as well.  I haven't gotten too deep 
with the enhancer code yet, but know a few things about the two bytecode 
libraries (was ready to get into it for my MOF project).  ASM is good if 
you just want to generate bytecode but want something that is a little 
higher level than pushing bytes out to a ByteArrayStream.  OTOH, CGLib 
is much more OO, but since it uses ASM, the two can be used together if 
you don't mind coding with compatible semantics to CGLib.  From the very 
cursory look at the output of other enhancers, I believe CGLib can 
probably to everything we need in about 20% of the time, and we could go 
back and hand-optimize what constructions we don't like after getting 
some experience with the code.

>> And I
>> remembered from distant past that there was some motion to use TranQL.
> There are a few things that I want to do but I've been focusing on 
> getting the JCP requirements finished before going off defining the 
> rest of the project.
> Briefly, I'd like to implement a JDO 2.0 (not the JPOX RI) that can be 
> tightly integrated with Geronimo (hence, use TranQL as the persistence 
> engine). I also want to have a database model and mapping that can be 
> used by tools (IDE, batch) to generate schema from data models and 
> vice versa. Some of this code is already in open source projects 
> (Netbeans specifically) but needs serious work to be viable for use by 
> us.

FWIW, use of TQL doesn't really provide integration with Geronimo, it 
only means that we would be sharing code (as a shared library when used 
together).  It makes a lot of sense because both projects can leverage 
each other's work on query tokenization and transformation.  The great 
thing about TQL is we can substantially increase the number of databases 
we support out of the box, although it doesn't provide any kind of query 
executive or optimizer, so it would not replace the manner by which the 
b-tree code is currently used for file storage.  (But as you can 
imagine, the b-tree code would need to be refactored or mated with a TQL 
transform to be modularly used.)  As Gianny pointed out, it makes a lot 
of sense to use it, and it is easy to use once you are moving with it.

>> Seems to me that things would be easier to start from scratch, stealing
>> code as we go.  What does everyone else think?
> Aside from the unfortunate use of the word "stealing": I think it 
> makes sense to see what is out there that we need, and import binarily 
> [sic] instead of forking, which is what I assume you meant.

Yes, but my reference was just in the context of JDORI, we do have 
permission to use that code when it fits our needs, correct?  Regarding 
other projects, it's a very different story.  Apologies if I gave you a 
shudder with the wrong impression on using code from other projects.


View raw message