On Aug 7, 2007, at 1:56 PM, Patrick Linskey wrote:
Today, we discussed making our APIs more Java-5-centric; currently, OpenJPAEntityManager has a number of methods that use numeric symbolic constants instead of enums, for historical reasons mostly. Abe pointed out that this is useful for future maintenance reasons, since no work is needed when a new symbolic constant is added to the core kernel. However, if we decide to move to Java 5 in the future in the kernel, we could potentially collapse away the symbolic constants at that time anyways. If we change the org.apache.openjpa.persistence package to use enums for these constants now, we may choose to put those enums in org.apache.openjpa.persistence, in which case we will still need to do translation between kernel and JPA in the future, either converting from a kernel-specific enum to a JPA-area enum, or from a symbolic constant (as currently) to the JPA-area enum. The alternate would be for us to put the new API-visible enums in the kernel module (well, kernel-5 module, currently), and have the org.apache.openjpa.persistence API classes depend on these kernel classes. If we decided to put the enums in org.apache.openjpa.persistence, we could get maintenance help by writing a test case that asserted that for a given pair of enums, a conversion between each value was possible. I think that this is easy enough that we shouldn't be concerned about maintenance when deciding where to put the enums. So, we need to decide two things:1. should we move from symbolic constants to enums in our binding tier?
Yes.
2. if so, where should we put the enums? My opinions are: yes to 1; org.apache.openjpa.persistence to 2.
Yes. Craig
-Patrick -- Patrick Linskey 202 669 5907
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
