On Tue, May 18, 2010 at 7:17 AM, Kevin Sutter <[email protected]> wrote: > Hi Jean-Baptiste, > I'm with you on this aspect. Producing the .java files, building them, and > then using them in a JVM seems to be a more logical means of accomplishing > this task.
OpenJPA, BTW, also supports something that might satisfy this scenario a little better: managed interfaces. If you don't bother with putting behavior in your classes and only use them as anaemic domain model objects (see http://martinfowler.com/bliki/AnemicDomainModel.html), you can define your object model in terms of interfaces instead of classes and OpenJPA will provide generated implementations of those interfaces at runtime. See http://openjpa.apache.org/builds/2.0.0/apache-openjpa-2.0.0/docs/manual/ref_guide_pc_interfaces.html Note that this feature is not standard in JPA 1.0 or 2.0, but has been standardized in JDO since version 2.0 to support not only interfaces, but also classes (abstract or concrete). It looks like this: public interface Person { String getName(); void String setName(String name); } Person p = persistenceManager.newInstance(Person.class); p.setName("Joe"); persistenceManager.makePersistent(p); See section 12.6.6 of the JDO specification for more info. -matthew PS: OpenJPA is descended from Kodo, one of the original JDO implementations, which is where this nonstandard feature comes from.
