[
https://issues.apache.org/jira/browse/OPENJPA-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688306#action_12688306
]
Pinaki Poddar commented on OPENJPA-5:
-------------------------------------
The time for this change has come.
JPA 2.0 requires quite a lot of compile-time annotation processing to support
newly added meta-model related features (source code generation etc.). Two
issues in this regard make JDK version dependecy a critical factor.
1. The spec requires generated meta-model classes to import
javax.annotation.GeneratedValue. This is a JDK6 annotation. Does the spec
implicitly saying that JPA2.0 applications require JDK6?
2. Annotation processing has gone through some core changes from JDK5 to JDK6.
In JDK5 it is supported by a tool apt -- and a com.sun.* class library in
tools.jar. While in JDK6 it is more closely bundled with javax.annotation
package. Moreover, the lifecycle/API in apt vs. javax.annotation are not the
same. It is possible to build two different implementations and switch based on
available JDK version -- but is it worth the effort?
Given that this important issue has been dormant for 2 years -- it is time to
revive this thread.
I have integrated Marc's patch (with few minor changes) and found that working
locally with Slice test cases because a) Slice is not covered in Marc's patch
and b) they heavily exercise construction of the JDBC counterparts of OpenJPA
(which are the main focus of Marc's solution and dynamically generated in his
approach). I will post the changes shortly.
> OpenJPA doesn't compile with JDBC 4
> -----------------------------------
>
> Key: OPENJPA-5
> URL: https://issues.apache.org/jira/browse/OPENJPA-5
> Project: OpenJPA
> Issue Type: Improvement
> Components: build / infrastructure
> Affects Versions: 0.9.0, 0.9.6
> Reporter: Craig Russell
> Attachments: OPENJPA-5.patch
>
>
> Patrick opines:
> OpenJPA implements Statement, ResultSet, Connection, and maybe a
> couple other JDBC interfaces. See
> org.apache.openjpa.lib.jdbc.Delegating*. We do this for a number of
> reasons: to resolve database-specific bugs in a transparent fashion, to
> provide logging, to handle reference counting, etc.
> The pressing issue is that we must provide implementations of all of the
> methods in the various java.sql interfaces. The fact that we do not
> implement the new JDBC4 methods is why OpenJPA won't currently compile
> against JDK6. This is pretty easy to fix; take a look at
> org.apache.openjpa.lib.jdbc.DelegatingStatement to see how we handled
> this for JDBC3. Since we know that we never invoke the new methods, we
> can happily throw unsupported operation exceptions for the new methods.
> However, these unsupported methods do provide a challenge. While Kodo
> doesn't use any of these methods, our mechanism for implementing them is
> limiting, in that users who obtain Connections from Kodo will not be
> able to use the new JDBC3/JDBC4 methods in their own code. Ideally, we
> should provide some means for people to designate to OpenJPA that it
> should use a dynamic proxy to implement the unimplemented methods. This
> shouldn't be the default behavior, as the dynamic proxy will add
> overhead, but certainly could be desirable for some. I'll file an issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
