Description:
CallableStatement.getObject overloads behave differently regarding the actual returned type of integral types which results in implementation inconsistency and run-time issues.
I first asked this on SO (http://stackoverflow.com/questions/31231298/mysql-callablestatement-getobject-have-inconsi...) but since I got no answer after 12 days, I decided to report it here since I definitely think this is a bug.
How to repeat:
I have the following simple procedure defined within in a test schema, _test_jdbc_inconsistency, in an instance of MySQL on my development system
CREATE PROCEDURE _test_jdbc_inconsistency.proc(IN param1 boolean, OUT param2 boolean)
BEGIN
IF (param1 IS NULL)
THEN
SET param2 = NULL;
ELSE
set param2 = not param1;
END IF;
END
But much to my surprise, the following simple test fails
@Test(dataProvider = "connectionPool")
public void testJdbcInconsitencyOutParameterType(Connection con) throws SQLException, IOException
{
con.setCatalog("_test_jdbc_inconsistency");
try (CallableStatement statement = con.prepareCall("{call proc(?, ?)}"))
{
statement.setInt("param1", 5);
statement.registerOutParameter("param2", Types.INTEGER);
statement.execute();
assertTrue(statement.getObject(2) instanceof Integer);
assertEquals(statement.getObject(2), 25);
assertTrue(statement.getObject("param2") instanceof Integer);
}
}
The inconsistency is flagged on last assertTrue statement; while calling the overload of CallableStatement.getObject which accepts a parameter-index returns a result of expected type (java.lang.Integer), the other overload accepting parameter-name returns inconsistent result of type java.lang.Long. Since I'm using signed integers and based on many instructions on using out parameters with JDBC, specifically the one provided by MySQL documentation, the process seems correct and this looks like an inconsistent behavior.
Can anyone else confirm this issue?
My Environment:
Windows 8.1 x64
JDK 1.8.0_45 (x64/x86)
MySQL Connector/J 5.1.34
MySQL Server 5.6.24
TestNG 6.9.5
Suggested fix:
Use the index-accepting-overload which works as expected until the bug is fixed.
