Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Message-ID: <14967400.1176738195353.JavaMail.jira@brutus>
Date: Mon, 16 Apr 2007 08:43:15 -0700 (PDT)
From: "Patrick Linskey (JIRA)" <jira@apache.org>
To: open-jpa-dev@incubator.apache.org
Subject: [jira] Commented: (OPENJPA-5) OpenJPA doesn't compile with JDBC 4
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Patrick Linskey commented on OPENJPA-5:
---------------------------------------

We do similar work for mutable type proxies. Is there an opportunity to unify the two different mechanisms in some way? Also, we pre-build some mutable type proxy classes during our compilation to reduce initialization time; should we look at doing a similar thing here? Without significant build changes, we should at least be able to pre-build the JDK1.5 classes.

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