You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Patrick Linskey <pl...@gmail.com> on 2007/08/07 22:56:40 UTC
Java 5 and JPA extension APIs
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
Re: Java 5 and JPA extension APIs
Posted by Craig L Russell <Cr...@Sun.COM>.
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Java 5 and JPA extension APIs
Posted by Michael Dick <mi...@apache.org>.
On 8/8/07, Marc Prud'hommeaux <mp...@apache.org> wrote:
>
>
>
> > 1. should we move from symbolic constants to enums in our binding
> > tier?
+1
> 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).
+1
What does everyone else think? Does anyone else have experience with
> "-target jsr14" and any attendant problems with using the flag?
I have no personal experience with the target jsr14 flag. Past experience
suggests that the flag won't be perfect and we'll run into some minor
(hopefully) headaches with it. IMHO it's well worth investigating further.
-Mike
Re: Java 5 and JPA extension APIs
Posted by Marc Prud'hommeaux <mp...@apache.org>.
> 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