It's my fault. I read email recent-first and didn't notice Brett created -4 (hours earlier) which I duplicated with -5. But -6 is a different issue... Imagine my surprise that we now have duplicates in our tiny JIRA repo! Craig On Jul 31, 2006, at 11:07 PM, Brett Porter wrote: > Hmm, did we all create the same JIRA issue? :) > > I crated OPENJPA-4 at the same time as the other issue, but it seems > -5 and -6 are both about the same thing. > > - Brett > > On 01/08/06, Craig L Russell wrote: >> This definitely needs a JIRA issue. We should use the JIRA to track >> our discussion of the issue, unless folks think it's better to use >> our wiki. Is it set up yet? >> >> Craig >> >> On Jul 31, 2006, at 10:15 PM, Patrick Linskey wrote: >> >> Yes, 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. >> > >> > -Patrick >> > >> > -- >> > Patrick Linskey >> > BEA Systems, Inc. >> > >> >> -----Original Message----- >> >> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM] >> >> Sent: Monday, July 31, 2006 10:02 PM >> >> To: open-jpa-dev@incubator.apache.org >> >> Subject: Re: JDBC 4 (was: Was it just me?) >> >> >> >> You can access earlier versions of jdbc to compile against >> >> using special javac properties for library jars. But I don't >> >> know how maven deals with this. >> >> >> >> What specific errors are you getting when compiling against >> jdbc 4? >> >> I'm not aware of any additions that would make programs that >> >> compile against jdbc 3 not compile against jdbc 4. You don't >> >> *implement* any jdbc interfaces, do you? >> >> >> >> Craig >> >> >> >> On Jul 31, 2006, at 8:37 PM, Patrick Linskey wrote: >> >> >> >>>>>> BTW, you may be aware, but it doesn't compile on Java 6 >> >>>> due to the >> >>>>>> JDBC interface changes. I'll add that to JIRA if its not there >> >>>>>> already. >> >>>>> >> >>>>> Yeah, we've had this problem in the past as well. >> >>>> Historically, we've >> >>>>> created special modified JDBC jars so that we can compile >> >>>> on earlier >> >>>>> VM versions. How is this type of problem typically handled >> >>>> in Apache-land? >> >>>> >> >>>> Isn't this the other way around? If the additional methods are >> >>>> implemented to make it compile on Java 6, it will continue to be >> >>>> binary compatible with the earlier JDBC versions. >> >>> >> >>> Yes, that. Meant "so that we can run on earlier VM versions." >> >>> >> >>> So... how does Apache typically deal with this? The only >> >> alternate to >> >>> the way we've done things in the past is an approach that >> >> uses dynamic >> >>> proxies / auto-generated proxies / dynamically-modified classes. >> >>> >> >>> -Patrick >> >>> >> >> >> _____________________________________________________________________ >> >> _ >> >>> _ >> >>> Notice: This email message, together with any attachments, may >> >>> contain >> >>> information of BEA Systems, Inc., its subsidiaries and >> >>> affiliated >> >>> entities, that may be confidential, proprietary, copyrighted >> >>> and/or >> >>> legally privileged, and is intended solely for the use of the >> >>> individual or entity named in this message. If you are not the >> >>> intended recipient, and have received this message in error, >> please >> >>> immediately return this by email and then delete it. >> >> >> >> Craig Russell >> >> Architect, Sun Java Enterprise System http://java.sun.com/ >> products/ >> >> jdo >> >> 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, >> Gasp! >> >> >> >> >> > >> _____________________________________________________________________ >> _ >> > _ >> > Notice: This email message, together with any attachments, may >> > contain >> > information of BEA Systems, Inc., its subsidiaries and >> > affiliated >> > entities, that may be confidential, proprietary, copyrighted >> > and/or >> > legally privileged, and is intended solely for the use of the >> > individual >> > or entity named in this message. If you are not the intended >> > recipient, >> > and have received this message in error, please immediately return >> > this >> > by email and then delete it. >> >> Craig Russell >> Architect, Sun Java Enterprise System http://java.sun.com/products/ >> jdo >> 408 276-5638 mailto:Craig.Russell@sun.com >> P.S. A good JDO? O, Gasp! >> >> >> >> > > > -- > Apache Maven - http://maven.apache.org > "Better Builds with Maven" book - http://library.mergere.com/ Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, Gasp!