[
https://issues.apache.org/jira/browse/OPENJPA-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836992#action_12836992
]
Kevin Sutter commented on OPENJPA-1520:
---------------------------------------
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.
> Move trunk (2.0.x) to Java 6 (build and runtime)
> ------------------------------------------------
>
> Key: OPENJPA-1520
> URL: https://issues.apache.org/jira/browse/OPENJPA-1520
> Project: OpenJPA
> Issue Type: Improvement
> Components: build / infrastructure
> Affects Versions: 2.0.0-beta
> Reporter: Kevin Sutter
> Assignee: Kevin Sutter
> Fix For: 2.0.0
>
> Attachments: openjpa-1520.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
