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 Mon, 31 Aug 2009 13:27:48 GMT
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 <jaydvs@hotmail.com> 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
> > <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!
> >>
> >>
> >
> >
>
> --
> 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.
>

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