openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: [DISCUSS] Drop build support for Java 5?
Date Mon, 31 Aug 2009 17:32:23 GMT
+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 <jaydvs@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
>>> <Craig.Russell@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.
>>
> 

Mime
View raw message