OpenJPA
  1. OpenJPA
  2. OPENJPA-1520

Move trunk (2.0.x) to require Java 6 to build (but target 1.5 runtime)

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-beta
    • Fix Version/s: 2.0.0-beta2
    • Component/s: build / infrastructure
    • Labels:
      None
    • Patch Info:
      Patch Available

      Description

      http://n2.nabble.com/DISCUSS-Drop-build-support-for-Java-5-td2539470.html#a2540533

      We've had the discussion about dropping Java 5 support (build and runtime) from trunk. The above referenced string of notes indicates a favorable response. Before we do an official 2.0.0 release, we should make this change.

      Besides the build aspects, I believe we still have some Java 5 runtime implications in our runtime as well – some reflection processing due to the jdbc4 support. We should clean that up as well.

      I've talked to Donald about this and he's game to start this process, but please contribute ideas and testing as you see fit. Thanks.

      1. openjpa-1520.patch
        101 kB
        Kevin Sutter

        Issue Links

          Activity

          Kevin Sutter created issue -
          Donald Woods made changes -
          Field Original Value New Value
          Status Open [ 1 ] In Progress [ 3 ]
          Darren Woods committed 911520 (1 file)
          Reviews: none

          OPENJPA-1520 remove jdk5 profile

          Darren Woods committed 911522 (1 file)
          Reviews: none

          OPENJPA-1520 Require Java SE 6 or later to compile and require Maven 2.0.9 or later

          Hide
          Milosz Tylenda added a comment -

          I remember the following:
          1. Remove ConcreteClassGenerator usages.
          2. Update and simplify JDBC delegates (Delegating* classes) to match JDBC4. Many of them are currently at JDK 1.3 level throwing UnsupportedOperationExceptions from JDBC3 methods or having now unnecessary JDBC3 reflection code.
          3. Update user manual links to point to JSE6/JEE6 javadocs.

          Show
          Milosz Tylenda added a comment - I remember the following: 1. Remove ConcreteClassGenerator usages. 2. Update and simplify JDBC delegates (Delegating* classes) to match JDBC4. Many of them are currently at JDK 1.3 level throwing UnsupportedOperationExceptions from JDBC3 methods or having now unnecessary JDBC3 reflection code. 3. Update user manual links to point to JSE6/JEE6 javadocs.
          Darren Woods committed 911538 (1 file)
          Reviews: none

          OPENJPA-1520 Upgrade to Derby 10.5.3 which has lots of JDBC4 fixes since 10.2.2

          Hide
          Kevin Sutter added a comment -

          I'm doing #3 from Milosz's list (thanks for the list, Milosz, to jog the memory banks):
          3. Update user manual links to point to JSE6/JEE6 javadocs.

          Show
          Kevin Sutter added a comment - I'm doing #3 from Milosz's list (thanks for the list, Milosz, to jog the memory banks): 3. Update user manual links to point to JSE6/JEE6 javadocs.
          Hide
          Kevin Sutter added a comment -

          The first two items in Milosz's list are a bit more work... Since I don't have a ton of dedicated time, I'll bite off a chunk and attempt to get it cleaned up. I decided to go with the JDBCStoreManager and all of it's associated Delegating classes. This might be the majority of the usage of the ConcreteClassGenerator, but it also seems to be where we could get the most bang for the buck. Wish me luck...

          Show
          Kevin Sutter added a comment - The first two items in Milosz's list are a bit more work... Since I don't have a ton of dedicated time, I'll bite off a chunk and attempt to get it cleaned up. I decided to go with the JDBCStoreManager and all of it's associated Delegating classes. This might be the majority of the usage of the ConcreteClassGenerator, but it also seems to be where we could get the most bang for the buck. Wish me luck...
          Hide
          Milosz Tylenda added a comment -

          Kevin, good luck with the bang then BTW, I will be out of the source till around 03/03.

          Show
          Milosz Tylenda added a comment - Kevin, good luck with the bang then BTW, I will be out of the source till around 03/03.
          Hide
          Jeremy Bauer added a comment -

          I think this change may be worth posting a news item now and after the switchover is complete.

          Show
          Jeremy Bauer added a comment - I think this change may be worth posting a news item now and after the switchover is complete.
          Hide
          Kevin Sutter added a comment -

          The majority of the ConcreteClassGenerator and Delegating* class updates are complete in my workspace. The JUnit bucket is working. I'm working through some additional verification and testing before posting these changes. If all of this pans out, then I will finish the last changes (logging and dictionary support) as well.

          Show
          Kevin Sutter added a comment - The majority of the ConcreteClassGenerator and Delegating* class updates are complete in my workspace. The JUnit bucket is working. I'm working through some additional verification and testing before posting these changes. If all of this pans out, then I will finish the last changes (logging and dictionary support) as well.
          Hide
          Donald Woods added a comment -

          Looks like you're working on the other items, so assigning to you for now....

          Show
          Donald Woods added a comment - Looks like you're working on the other items, so assigning to you for now....
          Donald Woods made changes -
          Assignee Donald Woods [ drwoods ] Kevin Sutter [ kwsutter ]
          Hide
          Kevin Sutter added a comment -

          Initial patch for removing the use of ConcreteClassGenerator for the JDBC3/JDBC4 interfaces. If these patches check out okay (the JUnits are passing, doing some perf analysis), then there are still some updates necessary for Logging and DB Dictionary usage of this ConcreteClassGenerator.

          Show
          Kevin Sutter added a comment - Initial patch for removing the use of ConcreteClassGenerator for the JDBC3/JDBC4 interfaces. If these patches check out okay (the JUnits are passing, doing some perf analysis), then there are still some updates necessary for Logging and DB Dictionary usage of this ConcreteClassGenerator.
          Kevin Sutter made changes -
          Attachment openjpa-1520.patch [ 12436614 ]
          Kevin Sutter made changes -
          Patch Info [Patch Available]
          Hide
          Kevin Sutter added a comment -

          We've done a few things thus far with this JIRA...

          o We've modified the build pom.xml to use the Java 6 compiler exclusively.
          o We've modified the source/target levels for the compiler to be 1.6.
          o My patch has removed the ConcreteClassGenerator usage for the JDBC3/4 interfaces.

          With these build and coding updates, the performance improvement is minimal (at best). Our code is a little cleaner, but it doesn't seem to have affected performance all that much.

          Couple these results with the removal of Java 5 runtime support, and I think we have to ask whether this is the right thing to do at this point. Although Java 5 is (or is going) out of service, we could possibly be alienating some potential customers by limiting us to Java 6. And, for what benefit?

          Maybe we should still move to Java 6 as our official build compiler, but go back to the source/target levels of 1.5 to be compliant with the old runtime.

          I know we had this [DISCUSS] item on our mailing list, but given the results, maybe we should reconsider the intent of this JIRA.

          Show
          Kevin Sutter added a comment - We've done a few things thus far with this JIRA... o We've modified the build pom.xml to use the Java 6 compiler exclusively. o We've modified the source/target levels for the compiler to be 1.6. o My patch has removed the ConcreteClassGenerator usage for the JDBC3/4 interfaces. With these build and coding updates, the performance improvement is minimal (at best). Our code is a little cleaner, but it doesn't seem to have affected performance all that much. Couple these results with the removal of Java 5 runtime support, and I think we have to ask whether this is the right thing to do at this point. Although Java 5 is (or is going) out of service, we could possibly be alienating some potential customers by limiting us to Java 6. And, for what benefit? Maybe we should still move to Java 6 as our official build compiler, but go back to the source/target levels of 1.5 to be compliant with the old runtime. I know we had this [DISCUSS] item on our mailing list, but given the results, maybe we should reconsider the intent of this JIRA.
          Darren Woods committed 915410 (2 files)
          Reviews: none

          OPENJPA-1520 Require Java SE 6 to compile but target Java SE 5 so users can still run trunk on 1.5 and 1.6 JVMs for now, given the lack of performance improvements found with the patch to drop JDBC3 support...

          Hide
          Donald Woods added a comment -

          OK, as of trunk r915410, we now require Java SE 6 to build, but compile for 1.5 environments until we resolve this....

          Show
          Donald Woods added a comment - OK, as of trunk r915410, we now require Java SE 6 to build, but compile for 1.5 environments until we resolve this....
          Darren Woods committed 915539 (1 file)
          Reviews: none

          OPENJPA-1520 Allow using JDK 1.5 to compile/run the junits by using -Ptest-java5,test-derby -Djava5.home=<1.5 JDK home>, so we can verify that the 1.6 built artifacts will still work for 1.5 users.

          Hide
          Donald Woods added a comment -

          Updating title to match the final usage of this issue.

          Show
          Donald Woods added a comment - Updating title to match the final usage of this issue.
          Donald Woods made changes -
          Summary Move trunk (2.0.x) to Java 6 (build and runtime) Move trunk (2.0.x) to require Java 6 to build (but target 1.5 runtime)
          Assignee Kevin Sutter [ kwsutter ] Donald Woods [ drwoods ]
          Hide
          Donald Woods added a comment -

          So, the final decision was to require 1.6 or later to build but still configure maven-compiler-plugin to target 1.5. Also, you can build and run the tests with a 1.5 JDK, by using the -Ptest-java5 profile (which the junits are still passing with both the Sun 1.5 JDK and IBM 1.6 SDK using Derby.)

          Show
          Donald Woods added a comment - So, the final decision was to require 1.6 or later to build but still configure maven-compiler-plugin to target 1.5. Also, you can build and run the tests with a 1.5 JDK, by using the -Ptest-java5 profile (which the junits are still passing with both the Sun 1.5 JDK and IBM 1.6 SDK using Derby.)
          Donald Woods made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Donald Woods made changes -
          Fix Version/s 2.0.0-beta2 [ 12314802 ]
          Fix Version/s 2.0.0 [ 12314019 ]
          Darren Woods committed 915975 (2 files)
          Reviews: none

          OPENJPA-1520 revert some refs back to Java SE 5 docs

          Donald Woods made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Milosz Tylenda made changes -
          Link This issue is related to OPENJPA-1932 [ OPENJPA-1932 ]
          Jacob Nowosatka made changes -
          Link This issue relates to OPENJPA-2087 [ OPENJPA-2087 ]

            People

            • Assignee:
              Donald Woods
              Reporter:
              Kevin Sutter
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development