openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <kwsut...@gmail.com>
Subject Re: [DISCUSS] Drop build support for Java 5?
Date Wed, 05 Aug 2009 15:54:54 GMT
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>
> >
> >
>

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