From dev-return-5357-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Tue Aug 07 20:57:05 2007
Return-Path:
Delivered-To: apmail-openjpa-dev-archive@www.apache.org
Received: (qmail 27122 invoked from network); 7 Aug 2007 20:57:05 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 7 Aug 2007 20:57:05 -0000
Received: (qmail 10069 invoked by uid 500); 7 Aug 2007 20:57:03 -0000
Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org
Received: (qmail 10032 invoked by uid 500); 7 Aug 2007 20:57:03 -0000
Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@openjpa.apache.org
Delivered-To: mailing list dev@openjpa.apache.org
Received: (qmail 10023 invoked by uid 99); 7 Aug 2007 20:57:03 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Aug 2007 13:57:03 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of plinskey@gmail.com designates 64.233.166.181 as permitted sender)
Received: from [64.233.166.181] (HELO py-out-1112.google.com) (64.233.166.181)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Aug 2007 20:57:01 +0000
Received: by py-out-1112.google.com with SMTP id f31so3185579pyh
for ; Tue, 07 Aug 2007 13:56:40 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
d=gmail.com; s=beta;
h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
b=IXAYJZC53xQRm0feuOImlV6t+2uwh9GNpvD82ScCCVvGKtFY9MK7U4RSB+4wVVZ7UxFNxvFx4crfRkfGqHdt27tAqIdg9sTunvOE07Iet6hAXlpQZlurN1wxWPa5Lvdlgjl0TGWdECgziTq+GSKYAtb21BWcgs+O7FoKIfqWOyA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=beta;
h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
b=sad+1cPNtz8GsRV2niW8MQAzzbjgb249p1/XDV5Z5t9mpPSyz+VtPQdOGbW8LQZqP0JVbL1SF/DbexxOWj4R0rQjFO7VyBdc/R7UVpm8M/EbJ7iFhvJucOIcrQ3WoIvdYPBEUvMK4imbiCiNq9jgEABwC5aPlz0jiUUXcszoUbU=
Received: by 10.35.44.16 with SMTP id w16mr12287767pyj.1186520200103;
Tue, 07 Aug 2007 13:56:40 -0700 (PDT)
Received: by 10.35.100.9 with HTTP; Tue, 7 Aug 2007 13:56:40 -0700 (PDT)
Message-ID: <7262f25e0708071356i5d6eee36i269801cacce6db11@mail.gmail.com>
Date: Tue, 7 Aug 2007 13:56:40 -0700
From: "Patrick Linskey"
To: dev@openjpa.apache.org
Subject: Java 5 and JPA extension APIs
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Checked: Checked by ClamAV on apache.org
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