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. >
