Whoops...this didn't make much sense:
>> less than 10% of iBATIS 2.0 users are dependent upon iBATIS 2.0
I meant to say: less than 10% of iBATIS 2.0 users are dependent upon JDBC 2.0
Cheers,
Clinton
On 6/11/05, Clinton Begin <[EMAIL PROTECTED]> wrote:
Only 13% of our users are still dependent upon JDBC 2.0. I wonder if there is an option whereby we simply increment our supported JDKs?
Originally the iBATIS commitment was to support the current JDK version N, and version N-1. But my question would be....what is the current Java version? Sun says it's 1.5/5.0, but the majority of users use 1.4. An ibatis usage breakdown by JDK version:
1.3 = 13%
1.4 = 72%
1.5 = 15%
and by iBATIS version:
1.x = 5%
2.x = 95%
So we can probably conclude that less than 10% of iBATIS 2.0 users are dependent upon iBATIS 2.0. If they aren't updating their JDK, I wonder what the chances are that they'll need to upgrade iBATIS?
Is it possible that iBATIS 2.1.x could be the last version to support JDK 1.3?
If you're dependent upon JDK 1.3 and you're reading this....tell us!
Cheers,
Clinton
On 6/11/05, Brandon Goodin <[EMAIL PROTECTED] > wrote:okay... sounds good.
So, we can still have the <setting> attribute that states compatibilit
with using 2 or 3 as values (eventually 4 as well). But, if you are
not explicit we will set it by using class.forName and finding out
whether a jdbc 3 specific class exists and setting the compliance on
our own. Does that sound good?
Brandon
On 6/11/05, Larry Meadors < [EMAIL PROTECTED] > wrote:
> I agree with Sven, we can check for the existence of
> classes/interfaces/methods that are new in each release to auto-detect
> the JDBC version if the settings did not provide a value.
>
> Larry
>
> On 6/11/05, Sven Boden <[EMAIL PROTECTED]> wrote:
> >
> > Very personal preference.... auto-detection, but tag can override if
> > required.
> >
> > Regards,
> > Sven
> >
> >
> > On Sat, 11 Jun 2005 00:05:41 -0600, you wrote:
> >
> > >Hey guys,
> > >
> > >I'm reposting this because i'm not sure it got out with all the email
> > >hiccups over the last day. I'd really like to get some feedback on
> > >this. It will help us to move forward with adding jdbc 3 support...
> > >
> > >We need to start supporting some jdbc 3 functionality. I was thinking
> > >we can use the <settings> tag and add a compatibility attribute to it.
> > >The default would be 2 but could be configured to support 3. Then when
> > >we add support for savepoints, generated keys, etc... we can throw a
> > >sensible exception when someone tries to use jdbc 3 functionality in a
> > >jdbc 2 compatibility mode.
> > >
> > >My question is, do we want the support to be explicit with the setting
> > >tag? or do we want to use an autodetection means?
> > >
> > ><settings ... [compatibility="3"]/>
> > >
> > >thoughts?
> > >
> > >Brandon
> >
> >
>
