You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Craig L Russell <Cr...@Sun.COM> on 2009/08/05 20:13:48 UTC
Re: [DISCUSS] Drop build support for Java 5?
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 <pp...@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!
Re: [DISCUSS] Drop build support for Java 5?
Posted by Pinaki Poddar <pp...@apache.org>.
1. "OpenJPA 2.0 requires JDK 6 compiler to build and JRE 6 runtime" -- that
sounds reasonable. I think we should move to that position and
streamline/simplify build for OpenJPA 2.0 branch.
2. "OpenJPA 1.2.x requires JDK 5 compiler to build and JRE 5 runtime. Will
not run on JRE 6" -- that is a fact. right?
3. 1.3.x is tricky. As soon as consider a version running in *both* JRE 5
and 6 --we run into JDBC 4 related issues. We do have a solution in terms of
dynamic code generation -- but it is not an easy configuration to maintain
and work (as Kevin mentions his experience)
-----
Pinaki
--
View this message in context: http://n2.nabble.com/Re%3A--DISCUSS--Drop-build-support-for-Java-5--tp3393970p3395032.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: [DISCUSS] Drop build support for Java 5?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Kevin,
A vote might get people's attention, but it's not strictly necessary.
I'd just give it a day or so to let all the active committers prepare
for the change, and do it.
If there is substantial disruption of work, we can always roll back
the change. But the direction is clear, JPA 2.0 will use Java 6, and
the sooner we make the change, the more reliable the release will be.
Craig
On Aug 31, 2009, at 6:33 AM, Kevin Sutter wrote:
> We've been having this discussion for months (I started this thread
> back in
> March). From a trunk perspective, I'm not sure why we need a 2 month
> warning period. And, with the EOL fast approaching for Java 5, I'd be
> inclined to go ahead with this change "now". As Mike points out,
> this will
> help with shaking out any potential problems before we attempt to
> finalize a
> JPA 2.0 offering. Do we need a [VOTE] thread to get this kicked off?
>
> Kevin
>
> On Mon, Aug 31, 2009 at 8:27 AM, Michael Dick <michael.d.dick@gmail.com
> >wrote:
>
>> I think we've reached at least a rough consensus about dropping JDK5
>> support
>> for 2.0.0 / trunk..
>>
>> Are there any concerns about the timing for making the change? Pinaki
>> suggested a warning period of two months which would line up with
>> with EOL
>> for Java 5 (October 31st). I have a few reservations about waiting
>> that
>> long
>> to remove the JDK5 wrappers. We'll be close to a release of OpenJPA
>> 2.0.0
>> in
>> October and it'd be nice to make sure the wrapper-less code gets
>> tested in
>> advance.
>>
>> Are there any objections to making the change sooner (ie this
>> week / early
>> next week)?
>>
>> -mike
>>
>> On Fri, Aug 28, 2009 at 3:33 PM, Surya Duggirala <ja...@hotmail.com>
>> wrote:
>>
>>>
>>> I see that we are in agreement to keep JPA 2.0 work only with Java
>>> 6.0
>>> without any support for Java 5.0. By sticking to only Java 6.0, we
>>> will
>>> increase the performance by avoiding those extra reflection costs
>>> that we
>>> have now.
>>>
>>> -Surya
>>>
>>> Michael Dick wrote:
>>>>
>>>> Hi Craig,
>>>>
>>>> On Wed, Aug 5, 2009 at 1:13 PM, Craig L Russell
>>>> <Cr...@sun.com>wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> This is my thinking too. One concern I have is that we have classes
>> which
>>>> do
>>>> not compile with Java 5 (we skip them). So unwary contributors
>>>> might
>>> think
>>>> they've built OpenJPA but they're actually missing a few bits.
>>>>
>>>> But is it a problem staying with Java 5 for the 1.x lines?
>>>>>
>>>>
>>>> I'm definitely not proposing that. I don't think we can do
>>>> something
>> like
>>>> this in a shipped release and 1.3.x doesn't *need* Java 6 (at
>>>> least not
>>>> yet).
>>>>
>>>> -mike
>>>>
>>>>
>>>>>
>>>>> 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!
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>>
>> http://n2.nabble.com/DISCUSS-Drop-build-support-for-Java-5-tp2539470p3537304.html
>>> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>>>
>>
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!
Re: [DISCUSS] Drop build support for Java 5?
Posted by Kevin Sutter <kw...@gmail.com>.
We've been having this discussion for months (I started this thread back in
March). From a trunk perspective, I'm not sure why we need a 2 month
warning period. And, with the EOL fast approaching for Java 5, I'd be
inclined to go ahead with this change "now". As Mike points out, this will
help with shaking out any potential problems before we attempt to finalize a
JPA 2.0 offering. Do we need a [VOTE] thread to get this kicked off?
Kevin
On Mon, Aug 31, 2009 at 8:27 AM, Michael Dick <mi...@gmail.com>wrote:
> I think we've reached at least a rough consensus about dropping JDK5
> support
> for 2.0.0 / trunk..
>
> Are there any concerns about the timing for making the change? Pinaki
> suggested a warning period of two months which would line up with with EOL
> for Java 5 (October 31st). I have a few reservations about waiting that
> long
> to remove the JDK5 wrappers. We'll be close to a release of OpenJPA 2.0.0
> in
> October and it'd be nice to make sure the wrapper-less code gets tested in
> advance.
>
> Are there any objections to making the change sooner (ie this week / early
> next week)?
>
> -mike
>
> On Fri, Aug 28, 2009 at 3:33 PM, Surya Duggirala <ja...@hotmail.com>
> wrote:
>
> >
> > I see that we are in agreement to keep JPA 2.0 work only with Java 6.0
> > without any support for Java 5.0. By sticking to only Java 6.0, we will
> > increase the performance by avoiding those extra reflection costs that we
> > have now.
> >
> > -Surya
> >
> > Michael Dick wrote:
> > >
> > > Hi Craig,
> > >
> > > On Wed, Aug 5, 2009 at 1:13 PM, Craig L Russell
> > > <Cr...@sun.com>wrote:
> > >
> > >> 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.
> > >>
> > >
> > > This is my thinking too. One concern I have is that we have classes
> which
> > > do
> > > not compile with Java 5 (we skip them). So unwary contributors might
> > think
> > > they've built OpenJPA but they're actually missing a few bits.
> > >
> > > But is it a problem staying with Java 5 for the 1.x lines?
> > >>
> > >
> > > I'm definitely not proposing that. I don't think we can do something
> like
> > > this in a shipped release and 1.3.x doesn't *need* Java 6 (at least not
> > > yet).
> > >
> > > -mike
> > >
> > >
> > >>
> > >> 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!
> > >>
> > >>
> > >
> > >
> >
> > --
> > View this message in context:
> >
> http://n2.nabble.com/DISCUSS-Drop-build-support-for-Java-5-tp2539470p3537304.html
> > Sent from the OpenJPA Developers mailing list archive at Nabble.com.
> >
>
Re: [DISCUSS] Drop build support for Java 5?
Posted by Donald Woods <dw...@apache.org>.
+1 for sooner than later.
-Donald
Michael Dick wrote:
> I think we've reached at least a rough consensus about dropping JDK5 support
> for 2.0.0 / trunk..
>
> Are there any concerns about the timing for making the change? Pinaki
> suggested a warning period of two months which would line up with with EOL
> for Java 5 (October 31st). I have a few reservations about waiting that long
> to remove the JDK5 wrappers. We'll be close to a release of OpenJPA 2.0.0 in
> October and it'd be nice to make sure the wrapper-less code gets tested in
> advance.
>
> Are there any objections to making the change sooner (ie this week / early
> next week)?
>
> -mike
>
> On Fri, Aug 28, 2009 at 3:33 PM, Surya Duggirala <ja...@hotmail.com> wrote:
>
>> I see that we are in agreement to keep JPA 2.0 work only with Java 6.0
>> without any support for Java 5.0. By sticking to only Java 6.0, we will
>> increase the performance by avoiding those extra reflection costs that we
>> have now.
>>
>> -Surya
>>
>> Michael Dick wrote:
>>> Hi Craig,
>>>
>>> On Wed, Aug 5, 2009 at 1:13 PM, Craig L Russell
>>> <Cr...@sun.com>wrote:
>>>
>>>> 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.
>>>>
>>> This is my thinking too. One concern I have is that we have classes which
>>> do
>>> not compile with Java 5 (we skip them). So unwary contributors might
>> think
>>> they've built OpenJPA but they're actually missing a few bits.
>>>
>>> But is it a problem staying with Java 5 for the 1.x lines?
>>> I'm definitely not proposing that. I don't think we can do something like
>>> this in a shipped release and 1.3.x doesn't *need* Java 6 (at least not
>>> yet).
>>>
>>> -mike
>>>
>>>
>>>> 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 <pp...@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!
>>>>
>>>>
>>>
>> --
>> View this message in context:
>> http://n2.nabble.com/DISCUSS-Drop-build-support-for-Java-5-tp2539470p3537304.html
>> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>>
>
Re: [DISCUSS] Drop build support for Java 5?
Posted by Michael Dick <mi...@gmail.com>.
I think we've reached at least a rough consensus about dropping JDK5 support
for 2.0.0 / trunk..
Are there any concerns about the timing for making the change? Pinaki
suggested a warning period of two months which would line up with with EOL
for Java 5 (October 31st). I have a few reservations about waiting that long
to remove the JDK5 wrappers. We'll be close to a release of OpenJPA 2.0.0 in
October and it'd be nice to make sure the wrapper-less code gets tested in
advance.
Are there any objections to making the change sooner (ie this week / early
next week)?
-mike
On Fri, Aug 28, 2009 at 3:33 PM, Surya Duggirala <ja...@hotmail.com> wrote:
>
> I see that we are in agreement to keep JPA 2.0 work only with Java 6.0
> without any support for Java 5.0. By sticking to only Java 6.0, we will
> increase the performance by avoiding those extra reflection costs that we
> have now.
>
> -Surya
>
> Michael Dick wrote:
> >
> > Hi Craig,
> >
> > On Wed, Aug 5, 2009 at 1:13 PM, Craig L Russell
> > <Cr...@sun.com>wrote:
> >
> >> 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.
> >>
> >
> > This is my thinking too. One concern I have is that we have classes which
> > do
> > not compile with Java 5 (we skip them). So unwary contributors might
> think
> > they've built OpenJPA but they're actually missing a few bits.
> >
> > But is it a problem staying with Java 5 for the 1.x lines?
> >>
> >
> > I'm definitely not proposing that. I don't think we can do something like
> > this in a shipped release and 1.3.x doesn't *need* Java 6 (at least not
> > yet).
> >
> > -mike
> >
> >
> >>
> >> 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 <pp...@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!
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/DISCUSS-Drop-build-support-for-Java-5-tp2539470p3537304.html
> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>
Re: [DISCUSS] Drop build support for Java 5?
Posted by Surya Duggirala <ja...@hotmail.com>.
I see that we are in agreement to keep JPA 2.0 work only with Java 6.0
without any support for Java 5.0. By sticking to only Java 6.0, we will
increase the performance by avoiding those extra reflection costs that we
have now.
-Surya
Michael Dick wrote:
>
> Hi Craig,
>
> On Wed, Aug 5, 2009 at 1:13 PM, Craig L Russell
> <Cr...@sun.com>wrote:
>
>> 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.
>>
>
> This is my thinking too. One concern I have is that we have classes which
> do
> not compile with Java 5 (we skip them). So unwary contributors might think
> they've built OpenJPA but they're actually missing a few bits.
>
> But is it a problem staying with Java 5 for the 1.x lines?
>>
>
> I'm definitely not proposing that. I don't think we can do something like
> this in a shipped release and 1.3.x doesn't *need* Java 6 (at least not
> yet).
>
> -mike
>
>
>>
>> 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 <pp...@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!
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/DISCUSS-Drop-build-support-for-Java-5-tp2539470p3537304.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
Re: [DISCUSS] Drop build support for Java 5?
Posted by Michael Dick <mi...@gmail.com>.
Hi Craig,
On Wed, Aug 5, 2009 at 1:13 PM, Craig L Russell <Cr...@sun.com>wrote:
> 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.
>
This is my thinking too. One concern I have is that we have classes which do
not compile with Java 5 (we skip them). So unwary contributors might think
they've built OpenJPA but they're actually missing a few bits.
But is it a problem staying with Java 5 for the 1.x lines?
>
I'm definitely not proposing that. I don't think we can do something like
this in a shipped release and 1.3.x doesn't *need* Java 6 (at least not
yet).
-mike
>
> 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 <pp...@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!
>
>
Re: [DISCUSS] Drop build support for Java 5?
Posted by Michael Dick <mi...@gmail.com>.
Hi Craig,
On Wed, Aug 5, 2009 at 1:13 PM, Craig L Russell <Cr...@sun.com>wrote:
> 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.
>
This is my thinking too. One concern I have is that we have classes which do
not compile with Java 5 (we skip them). So unwary contributors might think
they've built OpenJPA but they're actually missing a few bits.
But is it a problem staying with Java 5 for the 1.x lines?
>
I'm definitely not proposing that. I don't think we can do something like
this in a shipped release and 1.3.x doesn't *need* Java 6 (at least not
yet).
-mike
>
> 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 <pp...@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!
>
>
Re: [DISCUSS] Drop build support for Java 5?
Posted by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com>.
+1
Java 5 for 1.0.x and 1.3.x
Java 6 for 2.x
I think this could better for OpenJPA adoption.
Concerning my own usage, I'm no more using Java 5 ... so I would be
pleased with everything Java 6.
On Aug 6, 2009, at 16:11 , Donald Woods wrote:
>
>
> Craig L Russell wrote:
>> 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.
>
> Agree. I'd like us to require Java SE 6 for build and runtime.
>
>> But is it a problem staying with Java 5 for the 1.x lines?
>
> No, I'd expect us to stay with the Java SE 5 binary compatible
> requirement for 1.0.x - 1.3.x, but allow 1.2.x and 1.3.x to be
> tested and used on Java SE 6.
>
>> 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
>>>>> <pp...@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!
>
Re: [DISCUSS] Drop build support for Java 5?
Posted by David Beer <da...@googlemail.com>.
On Thu, 06 Aug 2009 10:11:48 -0400
Donald Woods <dw...@apache.org> wrote:
> > 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.
>
> Agree. I'd like us to require Java SE 6 for build and runtime.
Agree.
>
> >
> > But is it a problem staying with Java 5 for the 1.x lines?
>
> No, I'd expect us to stay with the Java SE 5 binary compatible
> requirement for 1.0.x - 1.3.x, but allow 1.2.x and 1.3.x to be tested
> and used on Java SE 6.
Agree again it is important that 1.x can use both Java 5 and Java 6 as
that is what a lot of people use including web applications.
--
Best Regards
David Beer
http://www.thebeerfamily.com
Re: [DISCUSS] Drop build support for Java 5?
Posted by Donald Woods <dw...@apache.org>.
Craig L Russell wrote:
> 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.
Agree. I'd like us to require Java SE 6 for build and runtime.
>
> But is it a problem staying with Java 5 for the 1.x lines?
No, I'd expect us to stay with the Java SE 5 binary compatible
requirement for 1.0.x - 1.3.x, but allow 1.2.x and 1.3.x to be tested
and used on Java SE 6.
>
> 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
>> <mi...@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 <pp...@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!
>