I took a look at the code and think this is very cool. There are actually two independent (but most often used together) things being demonstrated in the prototype:
1) extracting the SDO metamodel from an annotated Java interface. 2) runtime generation of an implementation class for an existing Java interface. The first one could also be used to import a model and then generate a static implementation at development time. The second one could be seamlessly added as a fallback (instead of throwing an exception) when an SDO object is created (e.g., with DataFactory.create) for a Type where instanceClass is set, but no corresponding implementation class exists (not sure how best to determine that though). I think it would be pretty easy to make #2 work with the existing EMF-based impl, by simply changing the base class and the signature of the generated indexed-get call. Of course there's still the change recording, container management, reference handshaking, etc., code to generate, but I think this would be a very valuable feature. I'd like to help with this, but have no ASM experience myself, so I would definitely need help with that. Doing #1 also seems pretty straightforward, but we would need to propose an API because the SDO spec does not currently provide a define() method that takes a Java class. We'd also need to design the necessary Java annotations and propose them for a future version of SDO. I'd also be willing to help with this if someone else can take the lead. Frank Jeremy Boynes <[EMAIL PROTECTED]> wrote on 01/23/2006 09:48:44 AM: > Daniel Berg wrote: > > Development time generation will still be necessary for the static > > interfaces so client code can compile against the static types. > > Do you agree? > > > > The interfaces need to be there at development time but the user has the > option of generating them from XSD or other metadata source or simply > just writing/reusing them. Having a generation step is the user's choice > rather than a requirement imposed by the SDO implementation. > > -- > Jeremy
