From dev-return-13133-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Wed Aug 05 20:26:55 2009 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 6329 invoked from network); 5 Aug 2009 20:26:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Aug 2009 20:26:54 -0000 Received: (qmail 27695 invoked by uid 500); 5 Aug 2009 20:27:01 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 27612 invoked by uid 500); 5 Aug 2009 20:27:01 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 27593 invoked by uid 99); 5 Aug 2009 20:27:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Aug 2009 20:27:01 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of michael.d.dick@gmail.com designates 209.85.218.220 as permitted sender) Received: from [209.85.218.220] (HELO mail-bw0-f220.google.com) (209.85.218.220) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Aug 2009 20:26:50 +0000 Received: by bwz20 with SMTP id 20so319683bwz.9 for ; Wed, 05 Aug 2009 13:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=3o2k0U0K5XdK9mhInSw/f79Bjx02ulJnMWp70gC7xBY=; b=eH72N2qNCFLiMEFwEy04RCUcKe0v9ShNvpbB0Ahtiuuy92M+rO4wkL4CjPkWi+FGGk VSViV/YoFAvRPwpc3S11+Y59uN0L14JGNcJeK1eqt3nGcmDaH9iFojH1SO/Xwhs3iK3Q owpTmykl4yHrYiHGKqEu+u3RnrFG6iwW280/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=KRJOsBKYrgCPE63LV170hWelf56bk0OBR6ei7UZNe2x+izl/ux94fTqw52R0sdbCG1 9iytH0FSY+ecjkYlnqL092pg6kiaU9GUGhRGASzzc8UBvkL716jjgb8rI4wannLuhjgi GdrPGMZv3O97fNn6x/CfqoKTOOuYVgKeuQpz4= MIME-Version: 1.0 Received: by 10.204.122.141 with SMTP id l13mr1247510bkr.106.1249503990025; Wed, 05 Aug 2009 13:26:30 -0700 (PDT) In-Reply-To: References: <89c0c52c0903260801md1512b4oa0d0df8ace043c99@mail.gmail.com> <49CCE929.5010207@apache.org> <89c0c52c0903271107g612bdf0cud397c6ffdebd349@mail.gmail.com> <1238190001967-2546798.post@n2.nabble.com> <2FCEAAB8-5FF8-47D6-AC9C-2580772FD356@SUN.com> <1238526473439-2564871.post@n2.nabble.com> <72c1350f0903311229s129236f7o562ab69598349daa@mail.gmail.com> <72c1350f0908050834n15be1bboe124f61aad4a33f@mail.gmail.com> <89c0c52c0908050854x35f96f05nf6fb45b1c83a05de@mail.gmail.com> Date: Wed, 5 Aug 2009 15:26:29 -0500 Message-ID: <72c1350f0908051326i58018ae0id910a7dd389ec8fd@mail.gmail.com> Subject: Re: [DISCUSS] Drop build support for Java 5? From: Michael Dick To: dev@openjpa.apache.org, users@openjpa.apache.org Content-Type: multipart/alternative; boundary=001636c5a2d8788f5904706ad14a X-Virus-Checked: Checked by ClamAV on apache.org --001636c5a2d8788f5904706ad14a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Craig, On Wed, Aug 5, 2009 at 1:13 PM, Craig L Russell 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 > >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 >> >>>> wrote: >>>> >>> >>> >>>> >>>> On Tue, Mar 31, 2009 at 2:07 PM, Pinaki Poddar >>>> >>> 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. >>>> >>>> >>>> >>>> >>>> 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 >>>> >>>> >>>> >>>> >>>> >>> > 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! > > --001636c5a2d8788f5904706ad14a--