openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pinaki Poddar (JIRA)" <>
Subject [jira] Commented: (OPENJPA-5) OpenJPA doesn't compile with JDBC 4
Date Mon, 23 Mar 2009 15:49:51 GMT


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

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

View raw message