[ https://issues.apache.org/jira/browse/OPENJPA-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467626 ]
Kevin Sutter commented on OPENJPA-5: ------------------------------------ Oops... We have so many of these JDBC 4 type Issues that I screwed up with my earlier comment. :-) I should have been referencing this Issue (OPENJPA-5) as the "make it buildable" Issue. And, the OPENJPA-6 should be the "exploitable" Issue. But, maybe Marc is right. OPENJPA-6 could be used to make the Connection objects returned by OpenJPA more JDBC like. And, then create a totally separate Issue for exploiting new JDBC 4 features. I'll do that. > OpenJPA doesn't compile with JDBC 4 > ----------------------------------- > > Key: OPENJPA-5 > URL: https://issues.apache.org/jira/browse/OPENJPA-5 > 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.