Documentation Home
MySQL Connector/J Release Notes
Related Documentation Download these Release Notes
PDF (US Ltr) - 362.7Kb
PDF (A4) - 361.4Kb


MySQL Connector/J Release Notes  /  Changes in MySQL Connector/J Version 8.x  /  Changes in MySQL Connector/J 8.0.28 (2022-01-18, General Availability)

Changes in MySQL Connector/J 8.0.28 (2022-01-18, General Availability)

Version 8.0.28 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 and 5.7. It supports the Java Database Connectivity (JDBC) 4.2 API, and implements the X DevAPI.

Deprecation and Removal Notes

  • The TLSv1 and TLSv1.1 connection protocols were deprecated in Connector/J 8.0.26 and are now removed in this release. The removed values are considered invalid for use with connection options and session settings. Connections can be made using the more-secure TLSv1.2 and TLSv1.3 protocols. Using TLSv1.3 requires that the server be compiled with OpenSSL 1.1.1 or higher and Connector/J be run with a JVM that supports TLSv1.3 (for example, Oracle Java 8u261 and above).

    Also, the following connection properties have been renamed:

    • enabledTLSProtocols renamed to tlsVersions; the original name remains as an alias.

    • enabledSSLCipherSuites renamed to tlsCiphersuites; the original name remains as an alias.

    (WL #14805)

Functionality Added or Changed

  • X DevAPI: A document _id check has been added to the Collection.addOrReplaceOne(id, doc) and Collection.replaceOne(id, doc) methods: If the id supplied as an argument for the functions does not match the _id in doc (the supplied JSON document), the operation fails. (Bug #32770013)

  • Connector/J now supports multifactor authentication for connections to MySQL Servers. Three new connection properties, password1, password2, and password3, have been added for that purpose. See Connecting Using Multifactor Authentication for details. (WL #14650)

Bugs Fixed

  • The README file in the Connector/J distribution contained broken links in the Additional Resources section. (Bug #33507321)

  • Storing a java.time.LocalDate object onto the server as a DATE value using a batched PreparedStatement failed with the complaint that java.time.LocalDate could not be cast to java.sql.Date. With this fix, the object is encoded correctly into a DATE value. (Bug #33468860, Bug #105211)

  • ResultSet navigation methods like absolute(), relative(), first(), last(), and so on returned a NullPointerException when they were applied to a non-navigable ResultSet. This was because the methods did not check if the ResultSet really had any rows before trying to navigate it. This patch makes all navigation methods perform the check and throw a proper SQLException when the ResultSet has no rows. (Bug #33461744)

  • Running a PreparedStatement in the form of INSERT INTO ... VALUE ... ON DUPLICATE KEY UPDATE ... VALUES(...) resulted in a StringIndexOutOfBoundsException. It was because Connector/J did not recognize VALUE as an alias for VALUES in an INSERT statement, and mistook the VALUES() function as a VALUES clause for the statement. With this fix, statements like this are parsed properly. (Bug #33425867, Bug #84365)

  • When the connection session's character set was SJIS, BLOB values could not be handled properly by client-side prepared statements. (Bug #33350185)

  • Some Java frameworks prevent changes of the autocommit value on the MySQL Server. When an application tried to change autocommit, the value was changed for the connection Session on the client side, but it failed to change on the server, so the settings became out of sync. With this fix, Connector/J resets autocommit to its original value for the Session under the situation. Thanks to Tingyu Wei for contributing to the fix. (Bug #33054827, Bug #104067)

  • getWarnings() always sent a SHOW WARNINGS query to the server. With this fix, the query is sent only if there really are warnings to be shown, in order to save resources. (Bug #32089018, Bug #101389)

  • After calling Statement.setQueryTimeout(), when a query timeout was reached, a connection to the server was established to terminate the query, but the connection remained open afterward. With this fix, the new connection is closed after the query termination. (Bug #31189960, Bug #99260)

  • A new session created for executing Statement.cancel() remained open after the Statement had been cancelled. With this fix, the session is closed after the Statement cancellation. (Bug #30355150, Bug #96900)

  • Using the setString() method on an SQLXML object resulted in a NullPointerException. (Bug #25656020, Bug #85223)