openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <>
Subject [jira] Commented: (OPENJPA-1520) Move trunk (2.0.x) to Java 6 (build and runtime)
Date Mon, 22 Feb 2010 23:40:27 GMT


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

View raw message