openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Porter" <brett.por...@gmail.com>
Subject Re: JDBC 4 (was: Was it just me?)
Date Tue, 01 Aug 2006 06:07:21 GMT
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 <Craig.Russell@sun.com> 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/

Mime
View raw message