Hi Pinaki, On Mar 27, 2009, at 2:40 PM, Pinaki Poddar wrote:
my $0.017 cents (because economy is not in good shape)1. We should not pull the plug of JDK5 with a jerk, but slowly. Let us investigate whether we can support the scenario wherea) we compile OpenJPA with Java 6 compilerb) but the application compiles with Java 5 compiler and runs in JRE 5 runtime. Such a scenario will provide us forward movement without causing inconvenience to existing users who may have valid reasons of not upgrading to Java 6 in immediate future but like to use JPA 2.0 features.
This also meets my needs for a stable platform to run a new personality without the new Java 6 dependencies.
2. The adventurous ones who venture into canonical meta-model generation with JPA 2.0 annotation processing and shiny/fancy stuff like that, will likely to be in Java 6 already
+1
(if not Java 7)
which doesn't exist on any road map (unless you're really talking about JDK7 which is not a standard but a product that doesn't yet exist in production)
and, if not, they must make Common Annotation JSR libraries available to the compiler.
+1
But we should not expand our effort to support such functionality on the basis of com.sun.mirror API and/or apt command-line tool.
I'm not familiar enough with these tools to comment, but it does seem wrong to depend on any com.sun packages.
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.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.
If you read the mission statement for OpenJPA, it's not to be the reference implementation for JPA but to be broader in scope:
WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as Apache OpenJPA, related to the implementation of object persistence, including, but not limited to, Java Persistence API, for distribution at no charge to the public;
And the case I'm interested in is not related to Java 6 features at all.If we decide that some parts of OpenJPA require a Java 6 runtime, that's ok. We decided that it wasn't worthwhile to continue to split out Java5, since many components in OpenJPA can benefit from Java 5 features (especially the old shiny template classes). But the broad benefit of Java 6 is not obvious to me.
Craig
Fair point, Donald. I was just thinking that since a JPA provider is not necessarily tied to the container, there may be some environments where "JPA as a utility" needs to be usable with Java 5. But, as you point out, then maybe we should just point to previous releases. I could be convinced...:-) Kevin-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----- Pinaki Poddar http://ppoddar.blogspot.com/ http://www.linkedin.com/in/pinakipoddar OpenJPA PMC Member/Committer JPA Expert Group Member -- View this message in context: http://n2.nabble.com/-DISCUSS--Drop-build-support-for-Java-5--tp2539470p2546798.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.
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
