On Mar 27, 2009, at 10:04 AM, Albert Lee wrote:
Are there any products relying on using the trunk for building personalitiesother than JPA 2.0?
I'm looking right now at adding a personality that would not require any of the new shiny Java 6 dynamic class compile features. I'd prefer that we not unduly burden the majority of the code base with Java 6.
Also, database users are notoriously biased in favor of stability over features, and I can imagine many current users continuing to run their systems on their well-tested Java 5 runtimes for some time.
Changing the build to generate Java 6 binaries for all components seems to have negative consequences.
If we vote, I'd vote to build components that run on Java 5 where possible.
Craig
If we plan to "encourage" those usages, we should atleast keep the requirements to compile/run the base modules (e.g. kernel,lib, util etc.) at the 1.5 level. Whereas the jdbc, persistence andpersistence-jdbc modules can be compile and run with 1.6 JDK. This impliesOpenJPA JPA 2.0 personality will require 1.6 JDK for execution. If we cut the cord completely, we may loss developers who are able to contribute at the base modules that benefit both parties. Albert Lee.On Fri, Mar 27, 2009 at 9:56 AM, Donald Woods <[email protected]> wrote:Why do we need to support Java 5 users with OpenJPA 2.0?If someone wants to continue using Java 5 after it's end-of-service date this year, then they can continue using one of the 1.0.x/1.1.x/ 1.2.x/1.3.xbranches....Don't see why we need to bend over backwards for Java 5, consider the JPA2Spec is part of the JEE6 Spec, which requires Java 6 or later. -Donald Kevin Sutter wrote:Are there any concerns with building with Java 6 and running in a Java 5 environment? Will this just "work" out of the box? Or, do we need tobuildwith the -target option to be compatible with Java 5? Or, do we need toproduce both versions? We still need to support the Java 5 runtime environment, even if we build with Java 6. Kevin On Thu, Mar 26, 2009 at 2:17 PM, Jeremy Bauer <[email protected]> wrote:+1 for pulling the plug on Java 5 in trunk. We are on a major releaseboundary with 2.0, so now would be the time to do it. Moving to Java 6: (good) - Meets JPA 2.0 JSE 6 annotation processing requirement- Fewer Java versions to support (and less confusion regarding build vs.runtime Java version requirements)- The ability to naturally (no version checks, reflection, etc.) use newJava 6 features such as JDBC 4 Continue providing compile support for Java 5: (bad)- Additional requirement of making sure OpenJPA builds on both versionsof Java- Inability to easily use new Java 6 features without version checks andsuch - Multiple code paths to maintain for version specific codeI agree that if we pull the plug on Java 5, there should be some sort of announce & time period that gives folks ample time to prepare. One ortwo months seems reasonable. -Jeremy On Thu, Mar 26, 2009 at 10:01 AM, Kevin Sutter <[email protected]> wrote: Per the discussion with OPENJPA-5 [1], the question of continuingsupport of building with Java 5 has been brought up. Due to the annotationprocessingthat will be required for JPA 2.0, the use of Java 6 will become arequirement for trunk. But, do we have to continue to support buildingwithJava 5. Pinaki has recently committed changes to allow building witheitherJava 5 or Java 6, but these changes will affect our code path as itrelatesto connection processing. So, should we bite the bullet and pull theplugon Java 5 from a build perspective? This would be for trunk (JPA 2.0)onlyand beyond. Comments, suggestions, complaints are all welcome. Thanks, Kevin [1] https://issues.apache.org/jira/browse/OPENJPA-5-- Albert Lee.
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!
smime.p7s
Description: S/MIME cryptographic signature
