[DISCUSS] Drop build support for Java 5?

[Kevin Sutter <kw...@gmail.com>]

Per the discussion with OPENJPA-5 [1], the question of continuing support of
building with Java 5 has been brought up.  Due to the annotation processing
that will be required for JPA 2.0, the use of Java 6 will become a
requirement for trunk.  But, do we have to continue to support building with
Java 5.  Pinaki has recently committed changes to allow building with either
Java 5 or Java 6, but these changes will affect our code path as it relates
to connection processing.  So, should we bite the bullet and pull the plug
on Java 5 from a build perspective?  This would be for trunk (JPA 2.0) only
and beyond.

Comments, suggestions, complaints are all welcome.

Thanks,
Kevin

[1] https://issues.apache.org/jira/browse/OPENJPA-5

Re: [DISCUSS] Drop build support for Java 5?

[Craig L Russell <Cr...@Sun.COM>]

On Mar 27, 2009, at 10:04 AM, Albert Lee wrote:

> Are there any products relying on using the trunk for building  
> personalities
> other than JPA 2.0?

I'm looking right now at adding a personality that would not require  
any of the new shiny Java 6 dynamic class compile features. I'd prefer  
that we not unduly burden the majority of the code base with Java 6.

Also, database users are notoriously biased in favor of stability over  
features, and I can imagine many current users continuing to run their  
systems on their well-tested Java 5 runtimes for some time.

Changing the build to generate Java 6 binaries for all components  
seems to have negative consequences.

If we vote, I'd vote to build components that run on Java 5 where  
possible.

Craig

> If we plan to "encourage" those usages, we should at
> least keep the requirements to compile/run the base modules (e.g.  
> kernel,
> lib, util etc.) at the 1.5 level. Whereas the jdbc, persistence and
> persistence-jdbc modules can be compile and run with 1.6 JDK. This  
> implies
> OpenJPA JPA 2.0 personality will require 1.6 JDK for execution.
>
> If we cut the cord completely, we may loss developers who are able to
> contribute at the base modules that benefit both parties.
>
> Albert Lee.
>
> On Fri, Mar 27, 2009 at 9:56 AM, Donald Woods <dw...@apache.org>  
> wrote:
>
>> Why do we need to support Java 5 users with OpenJPA 2.0?
>> If someone wants to continue using Java 5 after it's end-of-service  
>> date
>> this year, then they can continue using one of the 1.0.x/1.1.x/ 
>> 1.2.x/1.3.x
>> branches....
>>
>> Don't see why we need to bend over backwards for Java 5, consider  
>> the JPA2
>> Spec is part of the JEE6 Spec, which requires Java 6 or later.
>>
>>
>> -Donald
>>
>>
>>
>> Kevin Sutter wrote:
>>
>>> Are there any concerns with building with Java 6 and running in a  
>>> Java 5
>>> environment?  Will this just "work" out of the box?  Or, do we  
>>> need to
>>> build
>>> with the -target option to be compatible with Java 5?  Or, do we  
>>> need to
>>> produce both versions?  We still need to support the Java 5 runtime
>>> environment, even if we build with Java 6.
>>>
>>> Kevin
>>>
>>> On Thu, Mar 26, 2009 at 2:17 PM, Jeremy Bauer <te...@gmail.com>
>>> wrote:
>>>
>>> +1 for pulling the plug on Java 5 in trunk.  We are on a major  
>>> release
>>>> boundary with 2.0, so now would be the time to do it.
>>>>
>>>> Moving to Java 6: (good)
>>>> - Meets JPA 2.0 JSE 6 annotation processing requirement
>>>> - Fewer Java versions to support (and less confusion regarding  
>>>> build vs.
>>>> runtime Java version requirements)
>>>> - The ability to naturally (no version checks, reflection, etc.)  
>>>> use new
>>>> Java 6 features such as JDBC 4
>>>>
>>>> Continue providing compile support for Java 5: (bad)
>>>> - Additional requirement of making sure OpenJPA builds on both  
>>>> versions
>>>> of
>>>> Java
>>>> - Inability to easily use new Java 6 features without version  
>>>> checks and
>>>> such
>>>> - Multiple code paths to maintain for version specific code
>>>>
>>>> I agree that if we pull the plug on Java 5, there should be some  
>>>> sort of
>>>> announce & time period that gives folks ample time to prepare.   
>>>> One or
>>>> two
>>>> months seems reasonable.
>>>>
>>>> -Jeremy
>>>>
>>>> On Thu, Mar 26, 2009 at 10:01 AM, Kevin Sutter <kw...@gmail.com>
>>>> wrote:
>>>>
>>>> Per the discussion with OPENJPA-5 [1], the question of continuing
>>>>> support
>>>>> of
>>>>> building with Java 5 has been brought up.  Due to the annotation
>>>>>
>>>> processing
>>>>
>>>>> that will be required for JPA 2.0, the use of Java 6 will become a
>>>>> requirement for trunk.  But, do we have to continue to support  
>>>>> building
>>>>> with
>>>>> Java 5.  Pinaki has recently committed changes to allow building  
>>>>> with
>>>>> either
>>>>> Java 5 or Java 6, but these changes will affect our code path as  
>>>>> it
>>>>>
>>>> relates
>>>>
>>>>> to connection processing.  So, should we bite the bullet and  
>>>>> pull the
>>>>>
>>>> plug
>>>>
>>>>> on Java 5 from a build perspective?  This would be for trunk  
>>>>> (JPA 2.0)
>>>>>
>>>> only
>>>>
>>>>> and beyond.
>>>>>
>>>>> Comments, suggestions, complaints are all welcome.
>>>>>
>>>>> Thanks,
>>>>> Kevin
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/OPENJPA-5
>>>>>
>>>>>
>>>
>
>
> -- 
> Albert Lee.

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?

[Kevin Sutter <kw...@gmail.com>]

Albert,

On Fri, Mar 27, 2009 at 12:04 PM, Albert Lee <al...@gmail.com> wrote:

> Are there any products relying on using the trunk for building
> personalities
> other than JPA 2.0? If we plan to "encourage" those usages, we should at
> least keep the requirements to compile/run the base modules (e.g. kernel,
> lib, util etc.) at the 1.5 level. Whereas the jdbc, persistence and
> persistence-jdbc modules can be compile and run with 1.6 JDK. This implies
> OpenJPA JPA 2.0 personality will require 1.6 JDK for execution.


I understand your point, but I hated this setup when we had to support JDK
1.4 in the past.  Developers, including myself, accidentally and continually
forgot to build and test with the right environments to enforce this rule. I
would really like to avoid this situation, if possible.

Kevin


>
> If we cut the cord completely, we may loss developers who are able to
> contribute at the base modules that benefit both parties.
>
> Albert Lee.
>
> On Fri, Mar 27, 2009 at 9:56 AM, Donald Woods <dw...@apache.org> wrote:
>
> > Why do we need to support Java 5 users with OpenJPA 2.0?
> > If someone wants to continue using Java 5 after it's end-of-service date
> > this year, then they can continue using one of the
> 1.0.x/1.1.x/1.2.x/1.3.x
> > branches....
> >
> > Don't see why we need to bend over backwards for Java 5, consider the
> JPA2
> > Spec is part of the JEE6 Spec, which requires Java 6 or later.
> >
> >
> > -Donald
> >
> >
> >
> > Kevin Sutter wrote:
> >
> >> Are there any concerns with building with Java 6 and running in a Java 5
> >> environment?  Will this just "work" out of the box?  Or, do we need to
> >> build
> >> with the -target option to be compatible with Java 5?  Or, do we need to
> >> produce both versions?  We still need to support the Java 5 runtime
> >> environment, even if we build with Java 6.
> >>
> >> Kevin
> >>
> >> On Thu, Mar 26, 2009 at 2:17 PM, Jeremy Bauer <te...@gmail.com>
> >> wrote:
> >>
> >>  +1 for pulling the plug on Java 5 in trunk.  We are on a major release
> >>> boundary with 2.0, so now would be the time to do it.
> >>>
> >>> Moving to Java 6: (good)
> >>> - Meets JPA 2.0 JSE 6 annotation processing requirement
> >>> - Fewer Java versions to support (and less confusion regarding build
> vs.
> >>> runtime Java version requirements)
> >>> - The ability to naturally (no version checks, reflection, etc.) use
> new
> >>> Java 6 features such as JDBC 4
> >>>
> >>> Continue providing compile support for Java 5: (bad)
> >>> - Additional requirement of making sure OpenJPA builds on both versions
> >>> of
> >>> Java
> >>> - Inability to easily use new Java 6 features without version checks
> and
> >>> such
> >>> - Multiple code paths to maintain for version specific code
> >>>
> >>> I agree that if we pull the plug on Java 5, there should be some sort
> of
> >>> announce & time period that gives folks ample time to prepare.  One or
> >>> two
> >>> months seems reasonable.
> >>>
> >>> -Jeremy
> >>>
> >>> On Thu, Mar 26, 2009 at 10:01 AM, Kevin Sutter <kw...@gmail.com>
> >>> wrote:
> >>>
> >>>  Per the discussion with OPENJPA-5 [1], the question of continuing
> >>>> support
> >>>> of
> >>>> building with Java 5 has been brought up.  Due to the annotation
> >>>>
> >>> processing
> >>>
> >>>> that will be required for JPA 2.0, the use of Java 6 will become a
> >>>> requirement for trunk.  But, do we have to continue to support
> building
> >>>> with
> >>>> Java 5.  Pinaki has recently committed changes to allow building with
> >>>> either
> >>>> Java 5 or Java 6, but these changes will affect our code path as it
> >>>>
> >>> relates
> >>>
> >>>> to connection processing.  So, should we bite the bullet and pull the
> >>>>
> >>> plug
> >>>
> >>>> on Java 5 from a build perspective?  This would be for trunk (JPA 2.0)
> >>>>
> >>> only
> >>>
> >>>> and beyond.
> >>>>
> >>>> Comments, suggestions, complaints are all welcome.
> >>>>
> >>>> Thanks,
> >>>> Kevin
> >>>>
> >>>> [1] https://issues.apache.org/jira/browse/OPENJPA-5
> >>>>
> >>>>
> >>
>
>
> --
> Albert Lee.
>

Re: [DISCUSS] Drop build support for Java 5?

[Albert Lee <al...@gmail.com>]

Are there any products relying on using the trunk for building personalities
other than JPA 2.0? If we plan to "encourage" those usages, we should at
least keep the requirements to compile/run the base modules (e.g. kernel,
lib, util etc.) at the 1.5 level. Whereas the jdbc, persistence and
persistence-jdbc modules can be compile and run with 1.6 JDK. This implies
OpenJPA JPA 2.0 personality will require 1.6 JDK for execution.

If we cut the cord completely, we may loss developers who are able to
contribute at the base modules that benefit both parties.

Albert Lee.

On Fri, Mar 27, 2009 at 9:56 AM, Donald Woods <dw...@apache.org> wrote:

> Why do we need to support Java 5 users with OpenJPA 2.0?
> If someone wants to continue using Java 5 after it's end-of-service date
> this year, then they can continue using one of the 1.0.x/1.1.x/1.2.x/1.3.x
> branches....
>
> Don't see why we need to bend over backwards for Java 5, consider the JPA2
> Spec is part of the JEE6 Spec, which requires Java 6 or later.
>
>
> -Donald
>
>
>
> Kevin Sutter wrote:
>
>> Are there any concerns with building with Java 6 and running in a Java 5
>> environment?  Will this just "work" out of the box?  Or, do we need to
>> build
>> with the -target option to be compatible with Java 5?  Or, do we need to
>> produce both versions?  We still need to support the Java 5 runtime
>> environment, even if we build with Java 6.
>>
>> Kevin
>>
>> On Thu, Mar 26, 2009 at 2:17 PM, Jeremy Bauer <te...@gmail.com>
>> wrote:
>>
>>  +1 for pulling the plug on Java 5 in trunk.  We are on a major release
>>> boundary with 2.0, so now would be the time to do it.
>>>
>>> Moving to Java 6: (good)
>>> - Meets JPA 2.0 JSE 6 annotation processing requirement
>>> - Fewer Java versions to support (and less confusion regarding build vs.
>>> runtime Java version requirements)
>>> - The ability to naturally (no version checks, reflection, etc.) use new
>>> Java 6 features such as JDBC 4
>>>
>>> Continue providing compile support for Java 5: (bad)
>>> - Additional requirement of making sure OpenJPA builds on both versions
>>> of
>>> Java
>>> - Inability to easily use new Java 6 features without version checks and
>>> such
>>> - Multiple code paths to maintain for version specific code
>>>
>>> I agree that if we pull the plug on Java 5, there should be some sort of
>>> announce & time period that gives folks ample time to prepare.  One or
>>> two
>>> months seems reasonable.
>>>
>>> -Jeremy
>>>
>>> On Thu, Mar 26, 2009 at 10:01 AM, Kevin Sutter <kw...@gmail.com>
>>> wrote:
>>>
>>>  Per the discussion with OPENJPA-5 [1], the question of continuing
>>>> support
>>>> of
>>>> building with Java 5 has been brought up.  Due to the annotation
>>>>
>>> processing
>>>
>>>> that will be required for JPA 2.0, the use of Java 6 will become a
>>>> requirement for trunk.  But, do we have to continue to support building
>>>> with
>>>> Java 5.  Pinaki has recently committed changes to allow building with
>>>> either
>>>> Java 5 or Java 6, but these changes will affect our code path as it
>>>>
>>> relates
>>>
>>>> to connection processing.  So, should we bite the bullet and pull the
>>>>
>>> plug
>>>
>>>> on Java 5 from a build perspective?  This would be for trunk (JPA 2.0)
>>>>
>>> only
>>>
>>>> and beyond.
>>>>
>>>> Comments, suggestions, complaints are all welcome.
>>>>
>>>> Thanks,
>>>> Kevin
>>>>
>>>> [1] https://issues.apache.org/jira/browse/OPENJPA-5
>>>>
>>>>
>>


-- 
Albert Lee.

Re: [DISCUSS] Drop build support for Java 5?

[Jeremy Bauer <te...@gmail.com>]

Kevin,

Another option is to exclude the few files (AnnotationProcessor6.java,
CompileTimeLogger.java, SourceAnnotationHandler.java) which require Java 6
from the Eclipse source path.  A bit clumsy and not terribly helpful if you
plan to modify these files, though.

-Jeremy

On Wed, Aug 5, 2009 at 10:54 AM, Kevin Sutter <kw...@gmail.com> 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>
> > >
> > >
> >
>

Re: [DISCUSS] Drop build support for Java 5?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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!
> 

Re: [DISCUSS] Drop build support for Java 5?

[Craig L Russell <Cr...@Sun.COM>]

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?

[Craig L Russell <Cr...@Sun.COM>]

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?

[Kevin Sutter <kw...@gmail.com>]

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>
> >
> >
>

Re: [DISCUSS] Drop build support for Java 5?

[Michael Dick <mi...@gmail.com>]

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 <mi...@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>
>
>

Re: [DISCUSS] Drop build support for Java 5?

[Michael Dick <mi...@gmail.com>]

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>

Re: [DISCUSS] Drop build support for Java 5?

[Pinaki Poddar <pp...@apache.org>]

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?)

> 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.




Hi Pinaki,

On Mar 27, 2009, at 2:40 PM, Pinaki Poddar wrote:

>
> my $0.017 cents (because economy is not in good shape)
>
> 1. We should not pull the plug of JDK5 with a jerk, but slowly. Let  
> us investigate whether we can support the scenario where
>  a) we compile OpenJPA with Java 6 compiler
>  b) but the application compiles with Java 5 compiler and runs in  
> JRE 5 runtime.
> Such a scenario will provide us forward movement without causing  
> inconvenience to existing users who may have valid reasons of not  
> upgrading to Java 6 in immediate future but like to use JPA 2.0  
> features.

This also meets my needs for a stable platform to run a new  
personality without the new Java 6 dependencies.
>
>
> 2. The adventurous ones who venture into canonical meta-model  
> generation with JPA 2.0 annotation processing and shiny/fancy stuff  
> like that, will likely to be in Java 6 already

+1

> (if not Java 7)

which doesn't exist on any road map (unless you're really talking  
about JDK7 which is not a standard but a product that doesn't yet  
exist in production)

> and, if not, they must make Common Annotation JSR libraries  
> available to the compiler.

+1

> But we should not expand our effort to support such functionality on  
> the basis of com.sun.mirror API and/or apt command-line tool.

I'm not familiar enough with these tools to comment, but it does seem  
wrong to depend on any com.sun packages.

>
>
> 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.
>
>
>
> On Fri, Mar 27, 2009 at 9:56 AM, Donald Woods <dw...@apache.org>  
> wrote:
>
>> Why do we need to support Java 5 users with OpenJPA 2.0?
>> If someone wants to continue using Java 5 after it's end-of-service  
>> date
>> this year, then they can continue using one of the 1.0.x/1.1.x/ 
>> 1.2.x/1.3.x
>> branches....
>>
>> Don't see why we need to bend over backwards for Java 5, consider  
>> the JPA2
>> Spec is part of the JEE6 Spec, which requires Java 6 or later.

If you read the mission statement for OpenJPA, it's not to be the  
reference implementation for JPA but to be broader in scope:

        WHEREAS, the Board of Directors deems it to be in the best  
interests of the Foundation and consistent with the Foundation's  
purpose to establish a Project, to be known as Apache OpenJPA, related  
to the implementation of object persistence, including, but not  
limited to, Java Persistence API, for distribution at no charge to the  
public;

And the case I'm interested in is not related to Java 6 features at all.

If we decide that some parts of OpenJPA require a Java 6 runtime,  
that's ok. We decided that it wasn't worthwhile to continue to split  
out Java5, since many components in OpenJPA can benefit from Java 5  
features (especially the old shiny template classes). But the broad  
benefit of Java 6 is not obvious to me.

Craig

>
> Fair point, Donald.  I was just thinking that since a JPA provider  
> is not
> necessarily tied to the container, there may be some environments  
> where "JPA
> as a utility" needs to be usable with Java 5.  But, as you point  
> out, then
> maybe we should just point to previous releases.  I could be  
> convinced...
> :-)
>
>
> Kevin
>
>
>>
>>
>> -Donald
>>
>>
>>
>> Kevin Sutter wrote:
>>
>>> Are there any concerns with building with Java 6 and running in a  
>>> Java 5
>>> environment?  Will this just "work" out of the box?  Or, do we  
>>> need to
>>> build
>>> with the -target option to be compatible with Java 5?  Or, do we  
>>> need to
>>> produce both versions?  We still need to support the Java 5 runtime
>>> environment, even if we build with Java 6.
>>>
>>> Kevin
>>>
>>> On Thu, Mar 26, 2009 at 2:17 PM, Jeremy Bauer <te...@gmail.com>
>>> wrote:
>>>
>>> +1 for pulling the plug on Java 5 in trunk.  We are on a major  
>>> release
>>>> boundary with 2.0, so now would be the time to do it.
>>>>
>>>> Moving to Java 6: (good)
>>>> - Meets JPA 2.0 JSE 6 annotation processing requirement
>>>> - Fewer Java versions to support (and less confusion regarding  
>>>> build vs.
>>>> runtime Java version requirements)
>>>> - The ability to naturally (no version checks, reflection, etc.)  
>>>> use new
>>>> Java 6 features such as JDBC 4
>>>>
>>>> Continue providing compile support for Java 5: (bad)
>>>> - Additional requirement of making sure OpenJPA builds on both  
>>>> versions
>>>> of
>>>> Java
>>>> - Inability to easily use new Java 6 features without version  
>>>> checks and
>>>> such
>>>> - Multiple code paths to maintain for version specific code
>>>>
>>>> I agree that if we pull the plug on Java 5, there should be some  
>>>> sort of
>>>> announce & time period that gives folks ample time to prepare.   
>>>> One or
>>>> two
>>>> months seems reasonable.
>>>>
>>>> -Jeremy
>>>>
>>>> On Thu, Mar 26, 2009 at 10:01 AM, Kevin Sutter <kw...@gmail.com>
>>>> wrote:
>>>>
>>>> Per the discussion with OPENJPA-5 [1], the question of continuing
>>>>> support
>>>>> of
>>>>> building with Java 5 has been brought up.  Due to the annotation
>>>>>
>>>> processing
>>>>
>>>>> that will be required for JPA 2.0, the use of Java 6 will become a
>>>>> requirement for trunk.  But, do we have to continue to support  
>>>>> building
>>>>> with
>>>>> Java 5.  Pinaki has recently committed changes to allow building  
>>>>> with
>>>>> either
>>>>> Java 5 or Java 6, but these changes will affect our code path as  
>>>>> it
>>>>>
>>>> relates
>>>>
>>>>> to connection processing.  So, should we bite the bullet and  
>>>>> pull the
>>>>>
>>>> plug
>>>>
>>>>> on Java 5 from a build perspective?  This would be for trunk  
>>>>> (JPA 2.0)
>>>>>
>>>> only
>>>>
>>>>> and beyond.
>>>>>
>>>>> Comments, suggestions, complaints are all welcome.
>>>>>
>>>>> Thanks,
>>>>> Kevin
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/OPENJPA-5
>>>>>
>>>>>
>>>
>
>
>
>
> -----
> Pinaki Poddar                      http://ppoddar.blogspot.com/
>
> http://www.linkedin.com/in/pinakipoddar
> OpenJPA PMC Member/Committer
> JPA Expert Group Member
> -- 
> View this message in context: http://n2.nabble.com/-DISCUSS--Drop-build-support-for-Java-5--tp2539470p2546798.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!


 



-----
Pinaki Poddar                      http://ppoddar.blogspot.com/
                                      
http://www.linkedin.com/in/pinakipoddar
OpenJPA PMC Member/Committer
JPA Expert Group Member
-- 
View this message in context: http://n2.nabble.com/-DISCUSS--Drop-build-support-for-Java-5--tp2539470p2564871.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.

Re: [DISCUSS] Drop build support for Java 5?

[Craig L Russell <Cr...@Sun.COM>]

Hi Pinaki,

On Mar 27, 2009, at 2:40 PM, Pinaki Poddar wrote:

>
> my $0.017 cents (because economy is not in good shape)
>
> 1. We should not pull the plug of JDK5 with a jerk, but slowly. Let  
> us investigate whether we can support the scenario where
>  a) we compile OpenJPA with Java 6 compiler
>  b) but the application compiles with Java 5 compiler and runs in  
> JRE 5 runtime.
> Such a scenario will provide us forward movement without causing  
> inconvenience to existing users who may have valid reasons of not  
> upgrading to Java 6 in immediate future but like to use JPA 2.0  
> features.

This also meets my needs for a stable platform to run a new  
personality without the new Java 6 dependencies.
>
>
> 2. The adventurous ones who venture into canonical meta-model  
> generation with JPA 2.0 annotation processing and shiny/fancy stuff  
> like that, will likely to be in Java 6 already

+1

> (if not Java 7)

which doesn't exist on any road map (unless you're really talking  
about JDK7 which is not a standard but a product that doesn't yet  
exist in production)

> and, if not, they must make Common Annotation JSR libraries  
> available to the compiler.

+1

> But we should not expand our effort to support such functionality on  
> the basis of com.sun.mirror API and/or apt command-line tool.

I'm not familiar enough with these tools to comment, but it does seem  
wrong to depend on any com.sun packages.

>
>
> 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.
>
>
>
> On Fri, Mar 27, 2009 at 9:56 AM, Donald Woods <dw...@apache.org>  
> wrote:
>
>> Why do we need to support Java 5 users with OpenJPA 2.0?
>> If someone wants to continue using Java 5 after it's end-of-service  
>> date
>> this year, then they can continue using one of the 1.0.x/1.1.x/ 
>> 1.2.x/1.3.x
>> branches....
>>
>> Don't see why we need to bend over backwards for Java 5, consider  
>> the JPA2
>> Spec is part of the JEE6 Spec, which requires Java 6 or later.

If you read the mission statement for OpenJPA, it's not to be the  
reference implementation for JPA but to be broader in scope:

        WHEREAS, the Board of Directors deems it to be in the best  
interests of the Foundation and consistent with the Foundation's  
purpose to establish a Project, to be known as Apache OpenJPA, related  
to the implementation of object persistence, including, but not  
limited to, Java Persistence API, for distribution at no charge to the  
public;

And the case I'm interested in is not related to Java 6 features at all.

If we decide that some parts of OpenJPA require a Java 6 runtime,  
that's ok. We decided that it wasn't worthwhile to continue to split  
out Java5, since many components in OpenJPA can benefit from Java 5  
features (especially the old shiny template classes). But the broad  
benefit of Java 6 is not obvious to me.

Craig

>
> Fair point, Donald.  I was just thinking that since a JPA provider  
> is not
> necessarily tied to the container, there may be some environments  
> where "JPA
> as a utility" needs to be usable with Java 5.  But, as you point  
> out, then
> maybe we should just point to previous releases.  I could be  
> convinced...
> :-)
>
>
> Kevin
>
>
>>
>>
>> -Donald
>>
>>
>>
>> Kevin Sutter wrote:
>>
>>> Are there any concerns with building with Java 6 and running in a  
>>> Java 5
>>> environment?  Will this just "work" out of the box?  Or, do we  
>>> need to
>>> build
>>> with the -target option to be compatible with Java 5?  Or, do we  
>>> need to
>>> produce both versions?  We still need to support the Java 5 runtime
>>> environment, even if we build with Java 6.
>>>
>>> Kevin
>>>
>>> On Thu, Mar 26, 2009 at 2:17 PM, Jeremy Bauer <te...@gmail.com>
>>> wrote:
>>>
>>> +1 for pulling the plug on Java 5 in trunk.  We are on a major  
>>> release
>>>> boundary with 2.0, so now would be the time to do it.
>>>>
>>>> Moving to Java 6: (good)
>>>> - Meets JPA 2.0 JSE 6 annotation processing requirement
>>>> - Fewer Java versions to support (and less confusion regarding  
>>>> build vs.
>>>> runtime Java version requirements)
>>>> - The ability to naturally (no version checks, reflection, etc.)  
>>>> use new
>>>> Java 6 features such as JDBC 4
>>>>
>>>> Continue providing compile support for Java 5: (bad)
>>>> - Additional requirement of making sure OpenJPA builds on both  
>>>> versions
>>>> of
>>>> Java
>>>> - Inability to easily use new Java 6 features without version  
>>>> checks and
>>>> such
>>>> - Multiple code paths to maintain for version specific code
>>>>
>>>> I agree that if we pull the plug on Java 5, there should be some  
>>>> sort of
>>>> announce & time period that gives folks ample time to prepare.   
>>>> One or
>>>> two
>>>> months seems reasonable.
>>>>
>>>> -Jeremy
>>>>
>>>> On Thu, Mar 26, 2009 at 10:01 AM, Kevin Sutter <kw...@gmail.com>
>>>> wrote:
>>>>
>>>> Per the discussion with OPENJPA-5 [1], the question of continuing
>>>>> support
>>>>> of
>>>>> building with Java 5 has been brought up.  Due to the annotation
>>>>>
>>>> processing
>>>>
>>>>> that will be required for JPA 2.0, the use of Java 6 will become a
>>>>> requirement for trunk.  But, do we have to continue to support  
>>>>> building
>>>>> with
>>>>> Java 5.  Pinaki has recently committed changes to allow building  
>>>>> with
>>>>> either
>>>>> Java 5 or Java 6, but these changes will affect our code path as  
>>>>> it
>>>>>
>>>> relates
>>>>
>>>>> to connection processing.  So, should we bite the bullet and  
>>>>> pull the
>>>>>
>>>> plug
>>>>
>>>>> on Java 5 from a build perspective?  This would be for trunk  
>>>>> (JPA 2.0)
>>>>>
>>>> only
>>>>
>>>>> and beyond.
>>>>>
>>>>> Comments, suggestions, complaints are all welcome.
>>>>>
>>>>> Thanks,
>>>>> Kevin
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/OPENJPA-5
>>>>>
>>>>>
>>>
>
>
>
>
> -----
> Pinaki Poddar                      http://ppoddar.blogspot.com/
>
> http://www.linkedin.com/in/pinakipoddar
> OpenJPA PMC Member/Committer
> JPA Expert Group Member
> -- 
> View this message in context: http://n2.nabble.com/-DISCUSS--Drop-build-support-for-Java-5--tp2539470p2546798.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?

[Pinaki Poddar <pp...@apache.org>]

my $0.017 cents (because economy is not in good shape)

1. We should not pull the plug of JDK5 with a jerk, but slowly. Let us investigate whether we can support the scenario where 
  a) we compile OpenJPA with Java 6 compiler 
  b) but the application compiles with Java 5 compiler and runs in JRE 5 runtime. 
Such a scenario will provide us forward movement without causing inconvenience to existing users who may have valid reasons of not upgrading to Java 6 in immediate future but like to use JPA 2.0 features.

2. The adventurous ones who venture into canonical meta-model generation with JPA 2.0 annotation processing and shiny/fancy stuff like that, will likely to be in Java 6 already (if not Java 7) and, if not, they must make Common Annotation JSR libraries available to the compiler. But we should not expand our effort to support such functionality on the basis of com.sun.mirror API and/or apt command-line tool. 

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. 
 


On Fri, Mar 27, 2009 at 9:56 AM, Donald Woods <dw...@apache.org> wrote:

> Why do we need to support Java 5 users with OpenJPA 2.0?
> If someone wants to continue using Java 5 after it's end-of-service date
> this year, then they can continue using one of the 1.0.x/1.1.x/1.2.x/1.3.x
> branches....
>
> Don't see why we need to bend over backwards for Java 5, consider the JPA2
> Spec is part of the JEE6 Spec, which requires Java 6 or later.


Fair point, Donald.  I was just thinking that since a JPA provider is not
necessarily tied to the container, there may be some environments where "JPA
as a utility" needs to be usable with Java 5.  But, as you point out, then
maybe we should just point to previous releases.  I could be convinced...
:-)

Kevin


>
>
> -Donald
>
>
>
> Kevin Sutter wrote:
>
>> Are there any concerns with building with Java 6 and running in a Java 5
>> environment?  Will this just "work" out of the box?  Or, do we need to
>> build
>> with the -target option to be compatible with Java 5?  Or, do we need to
>> produce both versions?  We still need to support the Java 5 runtime
>> environment, even if we build with Java 6.
>>
>> Kevin
>>
>> On Thu, Mar 26, 2009 at 2:17 PM, Jeremy Bauer <te...@gmail.com>
>> wrote:
>>
>>  +1 for pulling the plug on Java 5 in trunk.  We are on a major release
>>> boundary with 2.0, so now would be the time to do it.
>>>
>>> Moving to Java 6: (good)
>>> - Meets JPA 2.0 JSE 6 annotation processing requirement
>>> - Fewer Java versions to support (and less confusion regarding build vs.
>>> runtime Java version requirements)
>>> - The ability to naturally (no version checks, reflection, etc.) use new
>>> Java 6 features such as JDBC 4
>>>
>>> Continue providing compile support for Java 5: (bad)
>>> - Additional requirement of making sure OpenJPA builds on both versions
>>> of
>>> Java
>>> - Inability to easily use new Java 6 features without version checks and
>>> such
>>> - Multiple code paths to maintain for version specific code
>>>
>>> I agree that if we pull the plug on Java 5, there should be some sort of
>>> announce & time period that gives folks ample time to prepare.  One or
>>> two
>>> months seems reasonable.
>>>
>>> -Jeremy
>>>
>>> On Thu, Mar 26, 2009 at 10:01 AM, Kevin Sutter <kw...@gmail.com>
>>> wrote:
>>>
>>>  Per the discussion with OPENJPA-5 [1], the question of continuing
>>>> support
>>>> of
>>>> building with Java 5 has been brought up.  Due to the annotation
>>>>
>>> processing
>>>
>>>> that will be required for JPA 2.0, the use of Java 6 will become a
>>>> requirement for trunk.  But, do we have to continue to support building
>>>> with
>>>> Java 5.  Pinaki has recently committed changes to allow building with
>>>> either
>>>> Java 5 or Java 6, but these changes will affect our code path as it
>>>>
>>> relates
>>>
>>>> to connection processing.  So, should we bite the bullet and pull the
>>>>
>>> plug
>>>
>>>> on Java 5 from a build perspective?  This would be for trunk (JPA 2.0)
>>>>
>>> only
>>>
>>>> and beyond.
>>>>
>>>> Comments, suggestions, complaints are all welcome.
>>>>
>>>> Thanks,
>>>> Kevin
>>>>
>>>> [1] https://issues.apache.org/jira/browse/OPENJPA-5
>>>>
>>>>
>>




-----
Pinaki Poddar                      http://ppoddar.blogspot.com/
                                      
http://www.linkedin.com/in/pinakipoddar
OpenJPA PMC Member/Committer
JPA Expert Group Member
-- 
View this message in context: http://n2.nabble.com/-DISCUSS--Drop-build-support-for-Java-5--tp2539470p2546798.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.

Re: [DISCUSS] Drop build support for Java 5?

[Kevin Sutter <kw...@gmail.com>]

On Fri, Mar 27, 2009 at 9:56 AM, Donald Woods <dw...@apache.org> wrote:

> Why do we need to support Java 5 users with OpenJPA 2.0?
> If someone wants to continue using Java 5 after it's end-of-service date
> this year, then they can continue using one of the 1.0.x/1.1.x/1.2.x/1.3.x
> branches....
>
> Don't see why we need to bend over backwards for Java 5, consider the JPA2
> Spec is part of the JEE6 Spec, which requires Java 6 or later.


Fair point, Donald.  I was just thinking that since a JPA provider is not
necessarily tied to the container, there may be some environments where "JPA
as a utility" needs to be usable with Java 5.  But, as you point out, then
maybe we should just point to previous releases.  I could be convinced...
:-)

Kevin


>
>
> -Donald
>
>
>
> Kevin Sutter wrote:
>
>> Are there any concerns with building with Java 6 and running in a Java 5
>> environment?  Will this just "work" out of the box?  Or, do we need to
>> build
>> with the -target option to be compatible with Java 5?  Or, do we need to
>> produce both versions?  We still need to support the Java 5 runtime
>> environment, even if we build with Java 6.
>>
>> Kevin
>>
>> On Thu, Mar 26, 2009 at 2:17 PM, Jeremy Bauer <te...@gmail.com>
>> wrote:
>>
>>  +1 for pulling the plug on Java 5 in trunk.  We are on a major release
>>> boundary with 2.0, so now would be the time to do it.
>>>
>>> Moving to Java 6: (good)
>>> - Meets JPA 2.0 JSE 6 annotation processing requirement
>>> - Fewer Java versions to support (and less confusion regarding build vs.
>>> runtime Java version requirements)
>>> - The ability to naturally (no version checks, reflection, etc.) use new
>>> Java 6 features such as JDBC 4
>>>
>>> Continue providing compile support for Java 5: (bad)
>>> - Additional requirement of making sure OpenJPA builds on both versions
>>> of
>>> Java
>>> - Inability to easily use new Java 6 features without version checks and
>>> such
>>> - Multiple code paths to maintain for version specific code
>>>
>>> I agree that if we pull the plug on Java 5, there should be some sort of
>>> announce & time period that gives folks ample time to prepare.  One or
>>> two
>>> months seems reasonable.
>>>
>>> -Jeremy
>>>
>>> On Thu, Mar 26, 2009 at 10:01 AM, Kevin Sutter <kw...@gmail.com>
>>> wrote:
>>>
>>>  Per the discussion with OPENJPA-5 [1], the question of continuing
>>>> support
>>>> of
>>>> building with Java 5 has been brought up.  Due to the annotation
>>>>
>>> processing
>>>
>>>> that will be required for JPA 2.0, the use of Java 6 will become a
>>>> requirement for trunk.  But, do we have to continue to support building
>>>> with
>>>> Java 5.  Pinaki has recently committed changes to allow building with
>>>> either
>>>> Java 5 or Java 6, but these changes will affect our code path as it
>>>>
>>> relates
>>>
>>>> to connection processing.  So, should we bite the bullet and pull the
>>>>
>>> plug
>>>
>>>> on Java 5 from a build perspective?  This would be for trunk (JPA 2.0)
>>>>
>>> only
>>>
>>>> and beyond.
>>>>
>>>> Comments, suggestions, complaints are all welcome.
>>>>
>>>> Thanks,
>>>> Kevin
>>>>
>>>> [1] https://issues.apache.org/jira/browse/OPENJPA-5
>>>>
>>>>
>>

Re: [DISCUSS] Drop build support for Java 5?

[Donald Woods <dw...@apache.org>]

Why do we need to support Java 5 users with OpenJPA 2.0?
If someone wants to continue using Java 5 after it's end-of-service date 
this year, then they can continue using one of the 
1.0.x/1.1.x/1.2.x/1.3.x branches....

Don't see why we need to bend over backwards for Java 5, consider the 
JPA2 Spec is part of the JEE6 Spec, which requires Java 6 or later.


-Donald


Kevin Sutter wrote:
> Are there any concerns with building with Java 6 and running in a Java 5
> environment?  Will this just "work" out of the box?  Or, do we need to build
> with the -target option to be compatible with Java 5?  Or, do we need to
> produce both versions?  We still need to support the Java 5 runtime
> environment, even if we build with Java 6.
> 
> Kevin
> 
> On Thu, Mar 26, 2009 at 2:17 PM, Jeremy Bauer <te...@gmail.com> wrote:
> 
>> +1 for pulling the plug on Java 5 in trunk.  We are on a major release
>> boundary with 2.0, so now would be the time to do it.
>>
>> Moving to Java 6: (good)
>> - Meets JPA 2.0 JSE 6 annotation processing requirement
>> - Fewer Java versions to support (and less confusion regarding build vs.
>> runtime Java version requirements)
>> - The ability to naturally (no version checks, reflection, etc.) use new
>> Java 6 features such as JDBC 4
>>
>> Continue providing compile support for Java 5: (bad)
>> - Additional requirement of making sure OpenJPA builds on both versions of
>> Java
>> - Inability to easily use new Java 6 features without version checks and
>> such
>> - Multiple code paths to maintain for version specific code
>>
>> I agree that if we pull the plug on Java 5, there should be some sort of
>> announce & time period that gives folks ample time to prepare.  One or two
>> months seems reasonable.
>>
>> -Jeremy
>>
>> On Thu, Mar 26, 2009 at 10:01 AM, Kevin Sutter <kw...@gmail.com> wrote:
>>
>>> Per the discussion with OPENJPA-5 [1], the question of continuing support
>>> of
>>> building with Java 5 has been brought up.  Due to the annotation
>> processing
>>> that will be required for JPA 2.0, the use of Java 6 will become a
>>> requirement for trunk.  But, do we have to continue to support building
>>> with
>>> Java 5.  Pinaki has recently committed changes to allow building with
>>> either
>>> Java 5 or Java 6, but these changes will affect our code path as it
>> relates
>>> to connection processing.  So, should we bite the bullet and pull the
>> plug
>>> on Java 5 from a build perspective?  This would be for trunk (JPA 2.0)
>> only
>>> and beyond.
>>>
>>> Comments, suggestions, complaints are all welcome.
>>>
>>> Thanks,
>>> Kevin
>>>
>>> [1] https://issues.apache.org/jira/browse/OPENJPA-5
>>>
> 

Re: [DISCUSS] Drop build support for Java 5?

[Kevin Sutter <kw...@gmail.com>]

Are there any concerns with building with Java 6 and running in a Java 5
environment?  Will this just "work" out of the box?  Or, do we need to build
with the -target option to be compatible with Java 5?  Or, do we need to
produce both versions?  We still need to support the Java 5 runtime
environment, even if we build with Java 6.

Kevin

On Thu, Mar 26, 2009 at 2:17 PM, Jeremy Bauer <te...@gmail.com> wrote:

> +1 for pulling the plug on Java 5 in trunk.  We are on a major release
> boundary with 2.0, so now would be the time to do it.
>
> Moving to Java 6: (good)
> - Meets JPA 2.0 JSE 6 annotation processing requirement
> - Fewer Java versions to support (and less confusion regarding build vs.
> runtime Java version requirements)
> - The ability to naturally (no version checks, reflection, etc.) use new
> Java 6 features such as JDBC 4
>
> Continue providing compile support for Java 5: (bad)
> - Additional requirement of making sure OpenJPA builds on both versions of
> Java
> - Inability to easily use new Java 6 features without version checks and
> such
> - Multiple code paths to maintain for version specific code
>
> I agree that if we pull the plug on Java 5, there should be some sort of
> announce & time period that gives folks ample time to prepare.  One or two
> months seems reasonable.
>
> -Jeremy
>
> On Thu, Mar 26, 2009 at 10:01 AM, Kevin Sutter <kw...@gmail.com> wrote:
>
> > Per the discussion with OPENJPA-5 [1], the question of continuing support
> > of
> > building with Java 5 has been brought up.  Due to the annotation
> processing
> > that will be required for JPA 2.0, the use of Java 6 will become a
> > requirement for trunk.  But, do we have to continue to support building
> > with
> > Java 5.  Pinaki has recently committed changes to allow building with
> > either
> > Java 5 or Java 6, but these changes will affect our code path as it
> relates
> > to connection processing.  So, should we bite the bullet and pull the
> plug
> > on Java 5 from a build perspective?  This would be for trunk (JPA 2.0)
> only
> > and beyond.
> >
> > Comments, suggestions, complaints are all welcome.
> >
> > Thanks,
> > Kevin
> >
> > [1] https://issues.apache.org/jira/browse/OPENJPA-5
> >
>

Re: [DISCUSS] Drop build support for Java 5?

[Jeremy Bauer <te...@gmail.com>]

+1 for pulling the plug on Java 5 in trunk.  We are on a major release
boundary with 2.0, so now would be the time to do it.

Moving to Java 6: (good)
- Meets JPA 2.0 JSE 6 annotation processing requirement
- Fewer Java versions to support (and less confusion regarding build vs.
runtime Java version requirements)
- The ability to naturally (no version checks, reflection, etc.) use new
Java 6 features such as JDBC 4

Continue providing compile support for Java 5: (bad)
- Additional requirement of making sure OpenJPA builds on both versions of
Java
- Inability to easily use new Java 6 features without version checks and
such
- Multiple code paths to maintain for version specific code

I agree that if we pull the plug on Java 5, there should be some sort of
announce & time period that gives folks ample time to prepare.  One or two
months seems reasonable.

-Jeremy

On Thu, Mar 26, 2009 at 10:01 AM, Kevin Sutter <kw...@gmail.com> wrote:

> Per the discussion with OPENJPA-5 [1], the question of continuing support
> of
> building with Java 5 has been brought up.  Due to the annotation processing
> that will be required for JPA 2.0, the use of Java 6 will become a
> requirement for trunk.  But, do we have to continue to support building
> with
> Java 5.  Pinaki has recently committed changes to allow building with
> either
> Java 5 or Java 6, but these changes will affect our code path as it relates
> to connection processing.  So, should we bite the bullet and pull the plug
> on Java 5 from a build perspective?  This would be for trunk (JPA 2.0) only
> and beyond.
>
> Comments, suggestions, complaints are all welcome.
>
> Thanks,
> Kevin
>
> [1] https://issues.apache.org/jira/browse/OPENJPA-5
>

Re: [DISCUSS] Drop build support for Java 5?

[Donald Woods <dw...@apache.org>]

+1 to requiring Java SE 6 for builds and runtime.


-Donald


Kevin Sutter wrote:
> Per the discussion with OPENJPA-5 [1], the question of continuing support of
> building with Java 5 has been brought up.  Due to the annotation processing
> that will be required for JPA 2.0, the use of Java 6 will become a
> requirement for trunk.  But, do we have to continue to support building with
> Java 5.  Pinaki has recently committed changes to allow building with either
> Java 5 or Java 6, but these changes will affect our code path as it relates
> to connection processing.  So, should we bite the bullet and pull the plug
> on Java 5 from a build perspective?  This would be for trunk (JPA 2.0) only
> and beyond.
> 
> Comments, suggestions, complaints are all welcome.
> 
> Thanks,
> Kevin
> 
> [1] https://issues.apache.org/jira/browse/OPENJPA-5
> 

Re: [DISCUSS] Drop build support for Java 5?

[Michael Dick <mi...@gmail.com>]

Comments below.

On Thu, Mar 26, 2009 at 12:36 PM, Pinaki Poddar <pp...@apache.org> wrote:

>
> It will be a fair assumption that OpenJPA version x.y that is compliant to
> official JPA 2.0 based *only on* JDK6 will not generate too much discomfort
> of the user. Because the adventurous type who will upgrade to JPA 2.0 will
> be on JDK6 anyway by then. Also the time frame of JDK5 eol and OpenJPA x.y
> will kind of match.
>
> Few points regarding such a change :
> 1. The eol of JDK5 support for OpenJPA should be announced at
> http://openjpa.apache.org/ at least 2 months prior to its actual
> occurrence.


What's the significance of 2 months? I agree that there should be some
length of time before we make the change - just wondering if there's a
reason for that particular timeframe.

2. The change should be across a major version upgrade of OpenJPA.


+1. In a minor release I could see using the dynamic approach that Pinaki
committed last night or some other hybrid approach. I can't see any way we'd
consider this change for patch releases.


> 3. The upgrade to JDK6 via dynamically generated JDBC artifacts should be
> temporary. Before we pull the plug on JDK5 support for OpenJPA publicly
> (i.e. on a released version), we should follow a concrete implementation
> (OPENJPA-6?) approach for JDBC artifacts.
>

+1. The dynamically generated JDBC artifacts are primarily a bridge for the
2 month interval discussed above.

Per the discussion with OPENJPA-5 [1], the question of continuing support of
> building with Java 5 has been brought up.  Due to the annotation processing
> that will be required for JPA 2.0, the use of Java 6 will become a
> requirement for trunk.  But, do we have to continue to support building
> with
> Java 5.  Pinaki has recently committed changes to allow building with
> either
> Java 5 or Java 6, but these changes will affect our code path as it relates
> to connection processing.  So, should we bite the bullet and pull the plug
> on Java 5 from a build perspective?  This would be for trunk (JPA 2.0) only
> and beyond.
>
> Comments, suggestions, complaints are all welcome.
>
> Thanks,
> Kevin
>
> [1] https://issues.apache.org/jira/browse/OPENJPA-5
>
>
>
>
> -----
> Pinaki Poddar                      http://ppoddar.blogspot.com/
>
> http://www.linkedin.com/in/pinakipoddar
> OpenJPA PMC Member/Committer
> JPA Expert Group Member
> --
> View this message in context:
> http://n2.nabble.com/-DISCUSS--Drop-build-support-for-Java-5--tp2539470p2539914.html
> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>
>

Re: [DISCUSS] Drop build support for Java 5?

[Pinaki Poddar <pp...@apache.org>]

It will be a fair assumption that OpenJPA version x.y that is compliant to official JPA 2.0 based *only on* JDK6 will not generate too much discomfort of the user. Because the adventurous type who will upgrade to JPA 2.0 will be on JDK6 anyway by then. Also the time frame of JDK5 eol and OpenJPA x.y will kind of match.

Few points regarding such a change :
1. The eol of JDK5 support for OpenJPA should be announced at http://openjpa.apache.org/ at least 2 months prior to its actual occurrence.
2. The change should be across a major version upgrade of OpenJPA.
3. The upgrade to JDK6 via dynamically generated JDBC artifacts should be temporary. Before we pull the plug on JDK5 support for OpenJPA publicly (i.e. on a released version), we should follow a concrete implementation (OPENJPA-6?) approach for JDBC artifacts.  


Per the discussion with OPENJPA-5 [1], the question of continuing support of
building with Java 5 has been brought up.  Due to the annotation processing
that will be required for JPA 2.0, the use of Java 6 will become a
requirement for trunk.  But, do we have to continue to support building with
Java 5.  Pinaki has recently committed changes to allow building with either
Java 5 or Java 6, but these changes will affect our code path as it relates
to connection processing.  So, should we bite the bullet and pull the plug
on Java 5 from a build perspective?  This would be for trunk (JPA 2.0) only
and beyond.

Comments, suggestions, complaints are all welcome.

Thanks,
Kevin

[1] https://issues.apache.org/jira/browse/OPENJPA-5




-----
Pinaki Poddar                      http://ppoddar.blogspot.com/
                                      
http://www.linkedin.com/in/pinakipoddar
OpenJPA PMC Member/Committer
JPA Expert Group Member
-- 
View this message in context: http://n2.nabble.com/-DISCUSS--Drop-build-support-for-Java-5--tp2539470p2539914.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.