openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick (JIRA)" <>
Subject [jira] Commented: (OPENJPA-5) OpenJPA doesn't compile with JDBC 4
Date Wed, 25 Mar 2009 16:26:55 GMT


Michael Dick commented on OPENJPA-5:

Full disclosure : I've only built with the patch, I have not run any tests.

Setting the compiler level to 1.6 in the root pom means that we won't compile with java 1.5
which was one of the main goals of Marc's patch. We'll need to set this back to 1.5 (which
does at least compile) if we want to support using both versions. 

I don't think support for compiling with 1.5 is important anymore. From Sun's website JDK
5.0 will reach end of life October 30th 2009 which isn't really that far away. Introducing
a lot of extra code (ConcreteClassGenerator) just adds extra complications with (IMHO) very
little benefit. 

Just adding the required interfaces makes more sense to me.

> 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, openjpa-5.patch.2.txt, openjpa-5.patch.3.txt
> 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