You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Brett Porter <br...@gmail.com> on 2006/08/01 05:33:07 UTC
Re: JDBC 4 (was: Was it just me?)
On 01/08/06, Patrick Linskey <pl...@bea.com> wrote:
> Sweet! I think that that will make you the first non-BEA employee
> committing to the codebase.
:)
>
> > 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.
Cheers,
Brett
RE: JDBC 4 (was: Was it just me?)
Posted by Patrick Linskey <pl...@bea.com>.
OPENJPA-6 was supposed to be about creating subclasses of the proxy
types that actually delegate through on the fly. Maybe I didn't capture
that difference very well. Eloquence is not my friend today.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
> -----Original Message-----
> From: Brett Porter [mailto:brett.porter@gmail.com]
> Sent: Monday, July 31, 2006 11:07 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: JDBC 4 (was: Was it just me?)
>
> 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 <Cr...@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/
>
_______________________________________________________________________
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.
Re: JDBC 4 (was: Was it just me?)
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <Cr...@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/
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!
Re: JDBC 4 (was: Was it just me?)
Posted by Brett Porter <br...@gmail.com>.
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 <Cr...@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/
Re: JDBC 4 (was: Was it just me?)
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
RE: JDBC 4 (was: Was it just me?)
Posted by Patrick Linskey <pl...@bea.com>.
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.
Re: JDBC 4 (was: Was it just me?)
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
RE: JDBC 4 (was: Was it just me?)
Posted by Patrick Linskey <pl...@bea.com>.
> > > 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.