Version 8.0.20 is the latest General Availability release of the 8.0 series of MySQL Connector/J. It is suitable for use with MySQL Server versions 8.0, 5.7, and 5.6. It supports the Java Database Connectivity (JDBC) 4.2 API, and implements the X DevAPI.
X DevAPI: Connector/J now supports data compression for X Protocol connections. See Connection Compression Using X DevAPI for details. (WL #12248)
A new method,
getElapsedTime(), has been added to the implementation of theStatementinterface in Connector/J, to expose the elapsed time for a query. Thanks to Matti Sillanpää for contributing the code. (Bug #30570249, Bug #97714)
When a custom
Calendarwas used in thesetDatemethod for aPreparedStatement, it was being used by subsequent calls of the same method that did not use the same calendar, resulting in the wrong date being set. It was because theSimpleDateFormatobject created internally with the custom calendar was cached and reused. With this fix, the object is no longer cached. (Bug #30877755)Setting the connection property
clientInfoProviderwithout using the fully qualified class name forClientInfoProviderSPcaused aNullPointerException. This was due to some wrong exception handling, which has been corrected by this fix. (Bug #30832513)Authentication failed when a client tried to connect to a server that used Windows Authentication Plugin and the Kerberos protocol. It was because the implementation of the
NativeAuthenticationProviderclass by Connector/J did not interact correctly with a custom-made Kerberos authentication plugin, and this patch fixes the issue. (Bug #30805426)Methods from the
ResultSetUtilclass are no longer used in Connector/J 8.0.20; the class has therefore been removed. (Bug #30636056)A
NullPointerExceptionwas returned when the connection hadcacheResultSetMetadata=trueand a query containing anySETstatements was executed. This fix corrects the issue by adding the missing variable assignment, and also a null check. (Bug #30584907, Bug #97757)A
DataConversionExceptionwas thrown when an application tried to store a string starting with "d." [d was any digit] into aVARCHARcolumn. It was due to a parsing error in theAbstractNumericValueFactory, which has been fixed by this patch. Thanks to Nick Pollett for contributing the code. (Bug #30570721, Bug #97724)When creating a
Statement, the specification for theresultSetTypeparameter was not honored, so that theResultSettype was always set toResultSet.TYPE_FORWARD_ONLY. With this fix, theresultSetTypeparameter is now honored. Also, type validation has been added so that calling the methodsbeforeFirst,afterLast,first,last,absolute,relative, orpreviousresults in an exception if theResultSettype isResultSet.TYPE_FORWARD_ONLY. (Bug #30474158)-
When a
Calendarwas not used, ajava.sql.Datevalue could not always be stored into and then retrieved from a MySQL server consistently. It was because Connector/J always converted aDatevalue to the server's time zone when storing it on the server as a MySQLDATE; but since a MySQLDATEdoes not have any time value, the hour, minute, and second parts of the original date was effectively lost. If the converted value is one day ahead of or behind the original value, when the value was retrieved through Connector/J and converted back to the local time zone, there was no time value for adjusting the date back to its original value, resulting in a one-day error. With this fix, anyDatevalue is converted to MySQLDATEvalue using the JVM's time zone, so that the value is always consistent when being stored and then read back.Also, the
cacheDefaultTimezoneconnection property, previously removed from Connector/J 8.0, has now been restored so that when it is set tofalse, Connector/J becomes aware of the time zone changes of the JVM during runtime and converts dates with the updated time zone. (Bug #28125069, Bug #91112)