openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: Java 5 and JPA extension APIs
Date Wed, 08 Aug 2007 19:53:35 GMT


> 1. should we move from symbolic constants to enums in our binding  
> tier?

+1. Might as well. Also, while it is true that (for example)  
OpenJPAEntityManager.setDetachState(int mode) doesn't need to change  
if we were to add a new constant to DetachState, we could come up  
with some semi-self-maintaining code for it. Currently, DetachState  
defines the symbolic integer constants, and OpenJPAEntityManager  
implements DetachState (in order to make it convenient to access the  
constants without having to import from the kernel package). Rather,  
we could do something like this:

package org.apache.openjpa.kernel;

public interface DetachState {
     public static final int DETACH_FETCH_GROUPS = 0;
     ... etc ...

     public abstract boolean isDetachFetchGroups(Object constant);
}

and then our implementation in the binding API would be something like:

package org.apache.openjpa.persistence;

public enum DetachStateConstant implements  
org.apache.openjpa.kernel.DetachState {
     DETACH_FETCH_GROUPS_CONST(DetachState.DETACH_FETCH_GROUPS),
     ... etc ...

     private final int _value;

     private DetachStateConstant(int value) {
         _value = value;
     }

     public int value() {
         return _value;
     }

     public boolean isDetachFetchGroups(Object constant) {
         return DETACH_FETCH_GROUPS_CONST.value() ==  
DetachState.DETACH_FETCH_GROUPS;
     }
}


That way, any time someone adds to or modified DetachState (and adds  
the appropriate method to DetachState, as the comments in that class  
would clearly outline), then the DetachStateConstant in their binding  
tier would fail to compile until they properly implemented the new  
method(s).


> 2. if so, where should we put the enums?

I'd say put it at the same level as the rest of the persistence  
stuff, which is where our other enums currently are (e.g.,  
org.apache.openjpa.persistence.MetaDataTag).


While we are on the topic of JDK 1.5-related activities, I was very  
interested to hear Bill Pugh talk about the "-target jsr14" flag the  
other day, which sounds like it would allow us to use generics (but  
not enums) in our kernel code and still compile to 1.4-compliant  
jars. There is a good summary of it at http://www-128.ibm.com/ 
developerworks/java/library/j-jtp02277.html#2.1 . I think it would be  
very nice, both from a code-management point of view, as well as from  
a javadoc standpoint, to have our collections in the kernel level be  
strongly typed.

What does everyone else think? Does anyone else have experience with  
"-target jsr14" and any attendant problems with using the flag?



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


Mime
View raw message