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 theStatement
interface 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
Calendar
was used in thesetDate
method 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 theSimpleDateFormat
object 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
clientInfoProvider
without using the fully qualified class name forClientInfoProviderSP
caused 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
NativeAuthenticationProvider
class 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
ResultSetUtil
class are no longer used in Connector/J 8.0.20; the class has therefore been removed. (Bug #30636056)A
NullPointerException
was returned when the connection hadcacheResultSetMetadata=true
and a query containing anySET
statements was executed. This fix corrects the issue by adding the missing variable assignment, and also a null check. (Bug #30584907, Bug #97757)A
DataConversionException
was thrown when an application tried to store a string starting with "d." [d was any digit] into aVARCHAR
column. 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 theresultSetType
parameter was not honored, so that theResultSet
type was always set toResultSet.TYPE_FORWARD_ONLY
. With this fix, theresultSetType
parameter is now honored. Also, type validation has been added so that calling the methodsbeforeFirst
,afterLast
,first
,last
,absolute
,relative
, orprevious
results in an exception if theResultSet
type isResultSet.TYPE_FORWARD_ONLY
. (Bug #30474158)-
When a
Calendar
was not used, ajava.sql.Date
value could not always be stored into and then retrieved from a MySQL server consistently. It was because Connector/J always converted aDate
value to the server's time zone when storing it on the server as a MySQLDATE
; but since a MySQLDATE
does 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, anyDate
value is converted to MySQLDATE
value using the JVM's time zone, so that the value is always consistent when being stored and then read back.Also, the
cacheDefaultTimezone
connection 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)