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

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

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development