openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Bauer <techhu...@gmail.com>
Subject Re: [DISCUSS] Drop build support for Java 5?
Date Wed, 05 Aug 2009 18:00:48 GMT
Kevin,

Another option is to exclude the few files (AnnotationProcessor6.java,
CompileTimeLogger.java, SourceAnnotationHandler.java) which require Java 6
from the Eclipse source path.  A bit clumsy and not terribly helpful if you
plan to modify these files, though.

-Jeremy

On Wed, Aug 5, 2009 at 10:54 AM, Kevin Sutter <kwsutter@gmail.com> 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>
> > >
> > >
> >
>

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