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 Fri, 15 Apr 2005 03:57:33 GMT
Hi Brian,

Perhaps we can discuss this at tomorow's TCK meeting.


On Apr 14, 2005, at 7:35 AM, Brian Topping wrote:

> Hi Craig,
> Craig Russell wrote:
>> Hi Brian,
>> On Apr 6, 2005, at 10:52 PM, Brian Topping wrote:
>>> Craig Russell wrote:
>>> 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.
> I'd like to take this work on, but need to segue it with 1)  the 
> existing work that I am signed up for on the XML Schema stuff (which 
> will take very little time and just needs to close out the questions 
> that I had on it) and 2) whether the results are going to be usable 
> from a project that I am currently developing.  I'll probably regret 
> saying this, but I don't think it's that difficult a problem with 
> CGLib, it just remains to be seen whether the problem and solution 
> domains overlap properly.
>>> 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.
> Hmm, I hadn't ever considered why this would be advantageous.  Could 
> you elaborate?  From my perspective, using the existing TQL AST code 
> gives us query compatibility with more databases as they are supported 
> by TQL, something we have to write ourselves if we don't use their 
> code.
>> 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.
> Last I looked, TQL was not architected with personalities as loadable 
> libraries.  But it strikes me that these personalities could be made 
> into IoC components themselves, thus enabling the functionality you 
> speak of.  This would be the first time this has been done though.  Is 
> it something that is a high priority for the implementation?  I would 
> vote for this as a 2.1 or 3.0.
>>> 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.
> That being said, is it worth adding J5 enhancement capability to ri11 
> first?  I would assert that CGLib is the way to go here, and if so, we 
> are fundamentally changing the way we enhance and it would be better 
> to include this as a part of a rewrite, not mash it into existing code 
> and port it.
> This leaves me wanting to get the 2.0 project started this week if 
> possible.  What am I missing?
> -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!

View raw message