What I originally thought about was not dropping support of deprecated
API methods, but implementing them in pool using non-deprecated methods.
For example instead of using
"impl.setUnicodeStream(idx, stream, len);"
we could write something like
"impl.setCharacterStream(idx, new InputStreamReader(stream,"UTF-8"), len);"
and same for other stream methods. From spec it seems that both methods
would (and should) do the same - pass UTF-8 encoded data to JDBC driver.
Same for ResultSetInPool and "getUnicodeStream(..)" method.
Another issue is "ResultSet.getBigDecimal(...,int)". We could replace
this definition by "bd = new BigDecimal(rs.getString(int));
bd.setScale(scle)", but there are two problems - wether
String/BigDecimal representations, that underlying JDBC driver supplies,
are compatible, and overhead of creating temporary String. First issue
is much more important, because second, from real-world apps point of
view, is practically non-existent.
This changes would remove deprecation warnings *in JBoss* still
providing necessary deprecated functionality in *client code*.
Conclusion:
- We *can* remove deprecation warnings from "ResultSetInPool" and
"PreparedStatementInPool" generated by setUnicodeStream/getUnicodeStream
methods, which costs us restricting ourselved to JDBC 2.0 drivers only
(setCharacterStream is available since JDBC 2.0). Anyways I'm not so
good in deep-JDBC issues, so I'd like to share this idea with some
people that might have more experience with diffrent JDBC drivers. What
do you think/know about passing character streams to JDBC drivers ?
- We *can* remove deprecation warning from "ResultSetInPool" *if*
underlying JDBC driver "String" and "BigDecimal" representations are
equivalent. But this is probably resolvable only on per-driver basis. Is
there on jboss-development someone that has experience with this issues
to comment on ?
The only thing I'm not sure is wether it's worth investigating those
issues to remove these deprecation warnings.
Scooter
Jason Dillon wrote:
> Some deprecated warnings are to be expected. Lets get the warnings down to
> compatiblity apis and perhaps we could turn it off (let the nightly build
> leave it on so we can deprecated use though).
>
> --jason
>
>
> On Tue, 11 Sep 2001, David Jencks wrote:
>
>
>><snip>
>>
>>>connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java
>>>connector/src/main/org/jboss/resource/adapter/jdbc/local/PreparedStatementInPool.java
>>>
>>>
>>>
>>> These two generate deprecation warnings, because they use deprecated
>>> methods of JDBC spec (namely [get|set]UnicodeStream and
>>> getBigDecimal). Resolving this would require all drivers to support
>>> JDBC 2.1 (am I wrong ?). I'm not quite sure wether this is
>>> reasonable. Can someone give me a hint about this ? I'll investigate
>>> more before correcting (if ever) and submitting patch...
>>>
>>>
>>I don't think we can change this, client code can call these methods: we
>>can't require all client code to not use deprecated methods.
>>
>>david jencks
>>
>>_______________________________________________
>>Jboss-development mailing list
>>[EMAIL PROTECTED]
>>https://lists.sourceforge.net/lists/listinfo/jboss-development
>>
>>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
