When connecting to a MySQL server 5.7 instance that supports TLS, Connector/J now prefers a TLS over a plain TCP connection. (Bug #21947042)

Two new connection properties, allowSlaveDownConnections and readFromMasterWhenNoSlaves, have been introduced for configuring replication-aware connections. See Configuring Source/Replica Replication with Connector/J and the entries for the new properties in Configuration Properties for Connector/J for details. (Bug #21286268)

In a Fabric environment, a ClassCastException resulted when a stored procedure was called with an INOUT parameter. This was because in this situation, what was being cast was a proxied version of the object. This fix extracts the underlying object from its proxy, allowing it to be cast to the implementing class. (Bug #22096981)

getTypeInfo() erroneously returned a PRECISION value of “255” instead of “65535” for the data type VARBINARY. (Bug #21978216)

A deadlock was observed when in the same server group, two concurrent threads were using different Fabric connections, and one executed a failover procedure while the other simultaneously called a method that acquired a lock on the underlying replication connection instance monitor. This fix revised the locking mechanism of replication connections, in order to prevent the observed deadlocks. (Bug #21966391, Bug #21934573, Bug #78710)

State information of a Fabric group was not updated by Connector/J after a local cache's Time to Live (TTL) expired, which resulted in the client not recognizing any topology changes happening to the group like a master failover, a server rejoining, and so on. (Bug #21296840, Bug #17910835)

Connector/J threw an AbstractMethodError when a JDBC 4 functionality (for example, createBlob()) was used on a replication-aware connection. This has been fixed by putting replication connections under the multi-host connection proxy structure that Connector/J has been using for load-balanced and failover connections. (Bug #11763419)

References: See also: Bug #11763401.

After the initial call of Connection.setReadOnly() following the creation of a replication-aware connection, subsequent calls of Connection.setReadOnly() could not change the nature of the connection. This has been fixed by putting replication connections under the multi-host connection proxy structure that Connector/J has been using for load-balanced and failover connections. (Bug #11763401)

References: See also: Bug #11763419.