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

Wed, 05 Aug 2009 11:14:38 -0700

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 <[email protected] 
>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 <[email protected]

wrote:





On Tue, Mar 31, 2009 at 2:07 PM, Pinaki Poddar <[email protected]>

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:[email protected]
P.S. A good JDO? O, Gasp!




Attachment:
smime.p7s

Description: S/MIME cryptographic signature


























					Reply via email to