Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: local policy)
MIME-version: 1.0
Date: Wed, 05 Aug 2009 11:13:48 -0700
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Re: [DISCUSS] Drop build support for Java 5?
In-reply-to: <89c0c52c0908050854x35f96f05nf6fb45b1c83a05de@mail.gmail.com>
Sender: Craig.Russell@Sun.COM
To: dev@openjpa.apache.org, users@openjpa.apache.org
Message-id: <DE8FC54E-0F4B-4CCA-A300-1294D0520EA4@SUN.com>
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha1; boundary=Apple-Mail-29-605888822
References: <89c0c52c0903260801md1512b4oa0d0df8ace043c99@mail.gmail.com>
 <c4a1048f0903261217l548d7affy3133b0af731f6d99@mail.gmail.com>
 <89c0c52c0903270749h14ff4a47t784d522a1c9f54ac@mail.gmail.com>
 <49CCE929.5010207@apache.org>
 <89c0c52c0903271107g612bdf0cud397c6ffdebd349@mail.gmail.com>
 <1238190001967-2546798.post@n2.nabble.com>
 <2FCEAAB8-5FF8-47D6-AC9C-2580772FD356@SUN.com>
 <1238526473439-2564871.post@n2.nabble.com>
 <72c1350f0903311229s129236f7o562ab69598349daa@mail.gmail.com>
 <72c1350f0908050834n15be1bboe124f61aad4a33f@mail.gmail.com>
 <89c0c52c0908050854x35f96f05nf6fb45b1c83a05de@mail.gmail.com>

--Apple-Mail-29-605888822
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Database users are notorious for wanting stability, even if it means  
running back-level releases. Somehow they manage to coerce vendors  
into supporting them on their running systems.

To get an accurate idea of our users' requirements, perhaps we need to  
include users@ in this discussion. Done. See" To:" line above.

But it's also clear that OpenJPA 2.0 will require Java 6. So I have no  
issues with making the switch for 2.0.

But is it a problem staying with Java 5 for the 1.x lines?

Craig

On Aug 5, 2009, at 8:54 AM, Kevin Sutter wrote:

> I agree that we need to do something.  Running with our current  
> module setup
> requires additional configuration to ensure that everything compiles  
> cleanly
> [1].  Right now, I have to change openjpa-jdbc, openjpa-persistence,  
> and
> openjpa-persistence-jdbc to Java 6 in order to get a clean compile  
> within
> Eclipse.  This is due to the JDBC 4 requirements and the annotation
> processor changes.  I'm okay with only doing the proposed compiler  
> update
> change for these three modules to start with.  As it stands right  
> now, it
> looks and feels clumsy...
>
> Kevin
>
> [1]  http://openjpa.apache.org/building.html
>
> On Wed, Aug 5, 2009 at 10:34 AM, Michael Dick <michael.d.dick@gmail.com 
> >wrote:
>
>> Resurrecting this thread.
>>
>> We're nearing the EOL for the non business version of Java SE 5.0  
>> (business
>> edition will be available for quite a while - unless the new  
>> management
>> changes the plan) [1] .
>>
>> When 5.0 goes out of service I'd propose upgrading OpenJPA to  
>> require JDK
>> 6.0 to compile. The compiled bytecode can be set to 1.5 if that's a
>> concern.
>> I'd prefer to have all the modules use jdk 6 to avoid some of the  
>> headaches
>> we had in OpenJPA 1.0.x with supporting 1.4 but we can restrict it  
>> to only
>> the ones that need it (persistence, persistence-jdbc) if that's more
>> amenable.
>>
>> In addition we can set up a new integration module which runs a  
>> subset of
>> tests with Java 5. It will be optional (since Java 5 won't be readily
>> available in 3 months), but at least we'd have some barometer for  
>> whether
>> OpenJPA works in that environment. We'll have to do some classpath
>> swizzling
>> (like we did for 1.4 in the 1.0.x stream) but it *should* be  
>> possible.
>>
>> Thoughts, objections, stuff I've missed?
>>
>> [1] http://java.sun.com/products/archive/eol.policy.html
>>
>> -mike
>>
>> On Tue, Mar 31, 2009 at 2:29 PM, Michael Dick <michael.d.dick@gmail.com
>>> wrote:
>>
>>>
>>>
>>> On Tue, Mar 31, 2009 at 2:07 PM, Pinaki Poddar <ppoddar@apache.org>
>> wrote:
>>>
>>>>
>>>> Hi Craig,
>>>>> This also meets my needs for a stable platform to run a new
>>>>> personality without the new Java 6 dependencies.
>>>>  The current update in trunk runs a configuration that builds  
>>>> OpenJPA
>>>> libraries with JDK6 compiler. But other configuration compiles  
>>>> and runs
>> our
>>>> test corpus with JDK5. I do not think we have a configuration that
>> compiles
>>>> OpenJPA with JDK6, compiles test cases with JDK5 and runs test  
>>>> cases
>> with
>>>> JDK5. May be we should create one. Such configuration will  
>>>> simulate the
>>>> target JDK5 user environment with JDK6-compiled OpenJPA where the  
>>>> test
>> case
>>>> will play the equivalent role of user application.
>>>> (Mike/Jeremy, are you tuned to this channel?)
>>>>
>>>
>>> This is easier said than done. Depending on how strict one wants  
>>> to be.
>> If
>>> we rely on the compiler settings (source=1.5, target=1.5) when we  
>>> compile
>>> the testcases then at worst we'd have to add a separate maven  
>>> module for
>>> JDK5 testcases.
>>>
>>> As we've seen in the past with JDK 1.4 this won't necessarily  
>>> suffice. We
>>> may need to do some additional tweaking to put the 1.5 class  
>>> libraries on
>>> the classpath, or (even more strict) we may need to rebuild with  
>>> maven's
>>> JAVA_HOME set differently.
>>>
>>> I'd be fine with the first approach as part of a normal build  
>>> (provided
>> it
>>> doesn't double execution time). Either of the later two would need  
>>> to be
>>> optional (like we did with jdk 1.4).
>>>
>>>
>>>>> mission statement for OpenJPA
>>>>> "to the implementation of object persistence, including, but not
>>>>> limited to, Java Persistence API, for distribution at no charge  
>>>>> to the
>>>> public;"
>>>>
>>>> I fully agree and support this view. Compliance to a spec is a  
>>>> necessary
>>>> but not sufficient condition for sustainable interest in a  
>>>> project of
>>>> OpenJPA's scope and breadth. Also one of the strongest feature of
>> OpenJPA is
>>>> its 'agnostic architecture' to promote the above charter.
>>>> As a group we will benefit if we keep the charter in mind and  
>>>> consider
>>>> possibilities to augment OpenJPA functionality that are beyond a
>> standard
>>>> specification.
>>>>
>>>
>>> I agree that the agnostic architecture is a strength of OpenJPA  
>>> and one
>>> that we can leverage to promote additional solutions in the ORM  
>>> space.
>> That
>>> said we are a JPA provider first and foremost and there are limits  
>>> to the
>>> contortions that the "core" OpenJPA engine should make to support  
>>> other
>>> persistence frameworks. Especially those that have not been  
>>> contributed
>> to
>>> Apache.
>>>
>>> To put it another way, our default behavior should be as JPA-like as
>>> possible with the option for other frameworks to change the  
>>> configuration
>> to
>>> suit their needs.
>>>
>>> <snip>
>>>
>>>
>>>>> 3. If the above appears to be a worthwhile target scenario to
>>>>> support, then the dynamic class construction approach perhaps can
>>>>> prove useful than hand-coding JDBC 4 dependency.
>>>>
>>>>> 4. We take a decision regarding these aspects by mid-April and
>>>>> announce it to be effective from, say, mid-June. I am not keen on
>>>>> exact duration of the prior notice but 2 months looked to be
>>>>> reasonable.
>>>>
>>>
>>> Fair enough. My concern lies mainly with the dynamic class  
>>> construction
>> and
>>> the impact on performance. Introducing additional code path in  
>>> order to
>>> support a backleveled JDK seems wrong to me. Maybe I'm too anxious  
>>> to be
>> on
>>> the bleeding edge.
>>>
>>> -mike
>>>
>>> <more message history snipped>
>>>
>>>
>>

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


--Apple-Mail-29-605888822
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw
ggJyoAMCAQICEDXZ+Ig/3d9DjJZ8u++ZnC0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwOTE4MTYwMloXDTA5MTIwOTE4MTYw
MlowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny
YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOe3oksetTgSiqqWllhIYBT0dWhR4CitzXDf
+ETyrtEF2HWRRpfwixLpV1Az8wwFzNKfjvQn3tQh0A/VDDeepDEM9TKLP+D6qShLR/KTf5kCMyT4
mILJYIDo/JMmTIH5jceojvlTDFd0gd+XXNAGGz1Wu2XxfvFDE/lpFnQkKYE+VjjENONy4JlkJnOI
rSfMlb+zHPAUmMTtmhxYIDLgov4Jv2Z5pUKZMpNcYr+7jJeUxkxKwWm4im56h7CGP0Yhkq2Je506
mqKCFImxofBjkHZISVS5m7WaGs4lViDtwLQEPtyUt7RcaoYWTvEQtvoy1TE2oZDUaAYFxVu0cHUW
bU0CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQEFBQADgYEAQaqAADs5GLyk9iO1xfmNFySpOXXofJPEbfbt77BK/WLhLOwS
69WIxSmGMpGGUlLd6FJ1xfLzsvP9/N5tmZQlpGcBoEwrn830JcbNyEG0ANcmdeAy2yBjNjWoIDhV
QmQw8OgJDk0xi0Tv/UYm9uPxOhDJOA67a3v6FHvSAbLqBScwggM/MIICqKADAgECAgENMA0GCSqG
SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH
EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp
Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw
NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE
cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef
kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB
AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js
LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD
VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+
hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC
3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEDXZ+Ig/3d9DjJZ8u++ZnC0wCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwODA1MTgxMzQ4WjAjBgkqhkiG9w0B
CQQxFgQUgJbZv7A0QCUQiGURyB1huPg0rHowgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA12fiIP93fQ4yWfLvvmZwtMIGHBgsqhkiG
9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA1
2fiIP93fQ4yWfLvvmZwtMA0GCSqGSIb3DQEBAQUABIIBAE0gAaqh5ioDyFaWmBqnyfm/oEbZtzjL
P+YCEPbEMDwPRPaKYTL/khH3AhOJTjQ/e4HGcX5P3yo5kn9hSifY4SLL8ROgYgiCgtcymjfzNh3Q
iMVa8Q8Bxcowkl56TqiHucomJIpBym1K+ikRMac7nnt38u86G8ptQYzu6nSVStwy8vuu+ZelUhZA
xpzo0Zwn5uO3uMZO5PCbzPcsnBEFvNJoHKOUNyFIhFng7WRrJVsk1GwHZXVTxc+HSk8qZuve2D52
hVNnsO4JkVtCEp05grgH9YQhJy7/yXDuQAyvjKwZYVZMgePds7nplgW+vcjTdM+g7p/sUQuortGn
7Wh3K+gAAAAAAAA=

--Apple-Mail-29-605888822--