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.
-b
smime.p7s
Description: S/MIME Cryptographic Signature
