openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <michael.d.d...@gmail.com>
Subject Re: [DISCUSS] Drop build support for Java 5?
Date Wed, 05 Aug 2009 20:26:29 GMT
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!
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message