Bug #77766 CallableStatement.getObject have inconsistent behavior
Submitted: 17 Jul 2015 15:12 Modified: 25 Jul 2015 10:10
Reporter: Hamid Nazari Email Updates:
Status: Verified Impact on me:
None 
Category:Connector / J Severity:S2 (Serious)
Version: 5.1.34 OS:Microsoft Windows (8.1 x64)
Assigned to: Filipe Silva CPU Architecture:Any

[17 Jul 2015 15:12] Hamid Nazari
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.
[25 Jul 2015 10:10] Filipe Silva
Hi Hamid,

Thank you for this bug report.
Verified as described.