openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Java 5 and JPA extension APIs
Date Wed, 08 Aug 2007 23:41:20 GMT

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?

> 2. if so, where should we put the enums?
> My opinions are: yes to 1; org.apache.openjpa.persistence to 2.


> -Patrick
> -- 
> Patrick Linskey
> 202 669 5907

Craig Russell
Architect, Sun Java Enterprise System
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message