Обсуждение: Improper type conversion from smallint to short
Hello,
It appears that ResultSet.getObject(String name) returns Integer for database type Types.SMALLINT (5) I expected Short.
Thanks,
Igor.
On Thu, 14 Mar 2013, Igor Urisman wrote: > Hello,It appears that ResultSet.getObject(String name) returns Integer for > database type Types.SMALLINT (5) I expected Short. > Returning Integer is correct according to the JDBC spec. See table 8.6.3 here: http://www.cis.upenn.edu/~bcpierce/courses/629/jdkdocs/guide/jdbc/getstart/mapping.doc.html Kris Jurka
Thanks, Kris. Not to argue... The spec you're quoting from is pre Java 1.1, which is when Short was introduced. (Integer was in 1.0). Just thinking... That same spec recommends primitive short. Just sayin'.
-Igor.
On Thu, Mar 14, 2013 at 5:27 PM, Kris Jurka <books@ejurka.com> wrote:
On Thu, 14 Mar 2013, Igor Urisman wrote:
> Hello,It appears that ResultSet.getObject(String name) returns Integer for> database type Types.SMALLINT (5) I expected Short.Returning Integer is correct according to the JDBC spec. See table 8.6.3
>
here:
http://www.cis.upenn.edu/~bcpierce/courses/629/jdkdocs/guide/jdbc/getstart/mapping.doc.html
Kris Jurka
On Thu, 14 Mar 2013, Igor Urisman wrote: > Thanks, Kris. Not to argue... The spec you're quoting from is pre Java 1.1, > which is when Short was introduced. (Integer was in 1.0). Just thinking... > That same spec recommends primitive short. Just sayin'. -Igor. That was just the first link I happened to find. The specs are in PDF format that makes linking tough, but if you check the current spec you'll see the same table, but with this note: Note . The JDBC 1.0 specification defined the Java object mapping for the SMALLINT and TINYINT JDBC types to be Integer. The Java language did not include the Byte and Short data types when the JDBC 1.0 specification was finalized. The mapping of SMALLINT and TINYINT to Integer is maintained to preserve backwards compatibility. Kris Jurka
Igor Urisman <igor.urisman@gmail.com> wrote: > It appears that ResultSet.getObject(String name) returns Integer > for database type Types.SMALLINT (5) I expected Short. I count on drivers complying with the published specification. The most recent version I was able to find near the top of a quick web search was this (the Final Release of the JDBC 4.0 Specification): http://download.oracle.com/otn-pub/jcp/jdbc-4.0-fr-eval-oth-JSpec/jdbc-4_0-fr-spec.zip Take a look at the "Data Type Conversion Tables" in appendix B. In particular, table B-3 specifies which Java object class should be returned by the getObject methods for each JDBC type. To do as you request would break the applications of everyone who trusts the specification published through the Java Community Process. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Thanks, Kevin & Kris.
I should have looked this up myself. Just seemed hard to fathom that the following code shouldn't work:
import java.lang.reflect.Field;
...
Field f = reflectFieldOfInterest();
f.set(this, resultSet.getObject("some_column"));
The last statement bombs on Integer to short assignment even though, by my reckoning, ResultSet.getObject() exists precisely for this use case.
-Igor.
-Igor.
On Fri, Mar 15, 2013 at 5:56 AM, Kevin Grittner <kgrittn@ymail.com> wrote:
Igor Urisman <igor.urisman@gmail.com> wrote:I count on drivers complying with the published specification. The
> It appears that ResultSet.getObject(String name) returns Integer
> for database type Types.SMALLINT (5) I expected Short.
most recent version I was able to find near the top of a quick web
search was this (the Final Release of the JDBC 4.0 Specification):
http://download.oracle.com/otn-pub/jcp/jdbc-4.0-fr-eval-oth-JSpec/jdbc-4_0-fr-spec.zip
Take a look at the "Data Type Conversion Tables" in appendix B. In
particular, table B-3 specifies which Java object class should be
returned by the getObject methods for each JDBC type. To do as you
request would break the applications of everyone who trusts the
specification published through the Java Community Process.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company