openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <>
Subject [jira] Commented: (OPENJPA-5) OpenJPA doesn't compile with JDBC 4
Date Thu, 25 Jan 2007 20:32:49 GMT


Kevin Sutter commented on OPENJPA-5:

To follow on to one of Marc's earlier comments...  These updates to support the new JDBC 4
interfaces brings up another question.  What about the support for the new data types introduced
by JDBC 4 (NCHAR, NVARCHAR, LONGNVARCHAR, NCLOB)?  Or, some of the new functionality provided
by JDBC 4 (SQLException extensions, event listeners, etc).  

There is a lot of overlap between OPENJPA-4 and OPENJPA-5.  Are these new JDBC 4 features
another new JIRA issue?  Maybe we have two main goals -- 1)  Is just to get us buildable and
runnable in a JDK 6 (JDBC 4) environment, and 2) exploit the new functions provided by JDK
6 (JDBC 4).  Is (1) for OPENJPA-4 and (2) for OPENJPA-5?  The discussions seem be blurring
the lines and I'm just trying to get a handle on how much we're going to bite off with each
JIRA Issue.  Thanks.

> OpenJPA doesn't compile with JDBC 4
> -----------------------------------
>                 Key: OPENJPA-5
>                 URL:
>             Project: OpenJPA
>          Issue Type: Improvement
>            Reporter: Craig Russell
> 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