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

Craig L Russell Mon, 31 Aug 2009 08:57:55 -0700

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

smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to