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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
