Changes in MySQL Connector/J 5.1.42 (2017-04-28)

Version 5.1.42 is a maintenance release of the production 5.1 branch. It is suitable for use with MySQL Server versions 5.5, 5.6, and 5.7. It supports the Java Database Connectivity (JDBC) 4.2 API.

• Functionality Added or Changed

• Bugs Fixed

Functionality Added or Changed

• A null value can now be extracted from a result set to a class belonging to the java.time package. Before, such an extraction resulted in a NullPointerException being thrown. Thanks to Martin Desharnais for contributing to the fix. (Bug #25250938, Bug #84189)

• Connector/J now checks that a MySQL server's SSL certificate and the Certificate Authority (CA) that issued it are not expired before establishing an SSL connection with the server, even if the connection property verifyServerCertificate is set to false. (Bug #20515688)

• Name-value pairs contained in the connection property sessionVariables can now be separated by either commas or a semicolons. (Bug #17757070)

• Added Japanese collation for the utf8mb4 character set.

Bugs Fixed

• An invalid timezone identifier was used in StatementRegressionTest.java of the Connector/J testsuite. (Bug #25687718, Bug #85351)

• A mysql client failed to establish an SSL connection to the server using the SSL certificates provided in the Connector/J source package. It was because the certificates have been generated with the same Common Name. This fix corrects the Common Names and regenerates the SSL certificates. (Bug #25636947)

• The unit test testsuite.simple.ResultSetTest.testPadding failed with the error Unknown character set: 'gb18030' after the collation map updates in release 5.1.40. (Bug #25556597)

• In a multi-host connection, query timeouts did not occur as configured. It was because the CancelTask thread, when trying to access the top level, virtual connection object, ran into a race condition with the connection monitor and then hung. With this fix, the CancelTask thread is passed a direct reference to the underlying physical connection, with which it can execute the cancellation. (Bug #25490163, Bug #84783)

• CallableStatement.extractProcedureName() did not return the correct result when the procedure name contained a dash. This was due to an error in the stripComments() method of the StringUtils class, which has now been corrected. (Bug #25321524, Bug #84324)

• The ConnectionImpl.isReadOnly() method returned a confusing error message when it could not retrieve the read-only status of the server. The message has now been changed to “Could not retrieve transaction read-only status from server.” (Bug #25101890, Bug #83834)

• A NullPointerException was thrown when a null boolean value was being read from the database. (Bug #25048406, Bug #83662)

• After a BIT value had been retrieved from a result set, the wasNull() method of the result set returned value for the last wasNull() query instead of the value for the last retrieved column. (Bug #24841670, Bug #83368)

• Using a partially-quoted identifier (with only the database or the procedure name quoted) or a non-existent parameter to register an output parameter in a CallableStatement caused a NullPointerException. With this fix, a partially-quoted identifier is accepted, and a non-existent parameter causes a SQLError to be thrown. (Bug #22333996, Bug #79561)

• DatabaseMetaData.getProcedureColumns() and DatabaseMetaData.getFunctionColumns() did not return expected results. This was due to the errors with the matching algorithm for the column names, which have now been fixed. Notice that, however, the effects of the connection parameter getProceduresReturnsFunctions on the two methods when JDBC 4 is used remain unchanged. (Bug #19531384, Bug #73775)

• When an UpdatableResultSet was used, trying to close the result set and its prepared statement simultaneously by different threads might result in a deadlock. This fix updates the synchronization mechanism for UpdatableResultSet to avoid the issue. (Bug #17653733, Bug #70704)

• After a connection had already switched catalog with setCatalog(), cached data from the old catalog was returned for a reused server-side prepared statement. With this fix, the cache of a server-side prepared statement cache now includes the catalog in its key to avoid wrong cache hits when the statement is reused on another catalog. (Bug #16714868, Bug #66430)