db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: Apache JDO 2.0
Date Thu, 07 Apr 2005 23:55:39 GMT
Hi Brian,

On Apr 6, 2005, at 10:52 PM, Brian Topping wrote:

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

I agree that the motivator here is J5. We *must* upgrade the enhancer 
to work with that platform. I think the work needs to be done first in 
ri11 and then migrated to JDO 2 project where we need to add features.

I've discussed our options with the author of the ri11 enhancer and 
will try to document our discussion, but you can appreciate it's a bit 
tough not least because the author isn't officially working on our 
project.
>
>>
>>> 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.

Yeah, I didn't clearly communicate my understanding of the relationship 
between TQL, JDO, and Geronimo.

I have to say, though, that I would not reuse the query tree 
walk/evaluator or the fostore b-tree implementation with TQL. Instead, 
I'd implement a different tree walker to generate SQL trees and 
implement a completely different StoreManager to talk SQL to a back 
end. That's where I'd use TQL.

I'd like to use TQL not least in order to share the cache of objects 
between CMP, EJB3, and JDO. To the extent possible, I'd like to allow 
users to choose among these technologies for each piece of an 
application instead of choosing at a very high level. So adding some 
EJB3 entities to an existing CMP application should not be impossible. 
Likewise, enhancing an EJB3 application to use some JDO should be easy.
>
>>>
>>> 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.

We are free to exploit everything in the xxx11 projects to use in our 
yyy20 projects. I've actually been thinking about splitting out the 
ri11 into several yyy20 projects: enhancer, query, runtime, model, a 
few others. I don't think that ri11 is granular enough to e.g. add TQL 
as the back end, or use a mapping model from other open source 
implementations.

Craig

>
> -b
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Mime
View raw message