[jira] Updated: (OPENJPA-5) OpenJPA doesn't compile with JDBC 4

["Marc Prud'hommeaux (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OPENJPA-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marc Prud'hommeaux updated OPENJPA-5:
-------------------------------------

    Attachment: OPENJPA-5.patch

The attached patch solves this problem by making all the JDBC implementations abstract, and handles construction them using a new ConcreteClassGenerator class, which will synamically create a concrete subclass and return it. I've been able to build and run all the tests under JDK 1.6 (which includes JDBC 4) after applying this patch.

The instance construction is somewhat cumbersome, and loses some compiler validation, but as far as I can tell this is the only way to resolve the problem without having separate builds for JDK 1.5 and JDK 1.6.

> 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
>             Fix For: 1.0.0
>
>         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.