Changes in MySQL Connector/J 8.0.13 (2018-10-22, General Availability)

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

• Functionality Added or Changed

• Bugs Fixed

Functionality Added or Changed

• Important Change: Connector/J now requires Protocol Buffers 3.6.1 as an external library for using X DevAPI and for building Connector/J from source.

  See Connector/J Installation on installation requirements for Connector/J. (Bug #28499094)

• X DevAPI: X DevAPI now provides a connection pooling feature, which can reduce overhead for applications by allowing idle connections to be reused. Connection pools are managed by the new Client objects, from which sessions can be obtained. See Connecting to a Single MySQL Server Using Connection Pooling in the X DevAPI User Guide for details. (WL #11857)

• X DevAPI: A new connection property, xdevapi.connect-timeout, now defines the timeout (in milliseconds) for establishing an X-Protocol connection to the server. Default value is 10000 (10s), and a value of 0 disables timeout, which makes Connector/J wait for the underlying socket to time out instead. See Configuration Properties for details.

  Note that if xdevapi.connect-timeout is not set explicitly and connectTimeout is, xdevapi.connect-timeout takes up the value of connectTimeout. (WL #12245)

• The connection property useOldUTF8Behavior is no longer supported. The connection property never had any meaning for the MySQL Server versions supported by Connector/J 8.0, but actually corrupted the data when it was used with them. (Bug #28444461)

• Connector/J now translates the legacy value of convertToNull for the connection property zeroDateTimeBehavior to CONVERT_TO_NULL. This allows applications or frameworks that use the legacy value (for example, NetBeans) to work with Connector/J 8.0. (Bug #28246270, Bug #91421)

• A new connection property, sslMode, has been introduced to replace the connection properties useSSL, requireSSL, and verifyServerCertificate, which are now deprecated. Also, when not explicitly set, the connection properties xdevapi.ssl-mode, xdevapi.ssl-truststore, xdevapi.ssl-truststore-password, and xdevapi.ssl-truststore-type now take up the values of sslMode, trustCertificateKeyStoreUrl, trustCertificateKeyStorePassword, and trustCertificateKeyStoreType, respectively. See Connecting Securely Using SSL and Configuration Properties for details.

  Note that for ALL server versions, the default setting of sslMode is PREFERRED, and it is equivalent to the legacy settings of useSSL=true, requireSSL=false, and verifyServerCertificate=false, which are different from their default settings for Connector/J 8.0.12 and earlier in some situations. Applications that continue to use the deprecated properties and rely on their old default settings should be reviewed. (Bug #27102307)

• The value UTF-8 for the connection property characterEncoding now maps to the utf8mb4 character set on the server and, for MySQL Server 5.5.2 and later, characterEncoding=UTF-8 can now be used to set the connection character set to utf8mb4 even if character_set_server has been set to something else on the server. (Before this change, the server must have character_set_server=utf8mb4 for Connector/J to use that character set.)

  Also, if the connection property connectionCollation is also set and is incompatible with the value of characterEncoding, characterEncoding will be overridden with the encoding corresponding to connectionCollation.

  See Using Character Sets and Unicode for details, including how to use the utf8mb3 character set now for connection. (Bug #23227334, Bug #81196)

Bugs Fixed

• X DevAPI: Connector/J threw a WrongArgumentException when it encountered a JSON number with more than ten digits. This was due to an error in the JSON parser, which has now been fixed. (Bug #28594434, Bug #92264)

• X DevAPI: Session.getUri() returned a NullPointerException when the default value is null for any of the connection properties contained in the connection URL; and when Session.getUri() returned a URL, the URL contained a comma (“,”) before its first connection property. (Bug #23045604)

• X DevAPI: When handling an invalid JSON document, Connector/J threw a NullPointerException. With this fix, a WrongArgumentException is thrown instead in the situation. (Bug #21914769)

• Setting the connection property characterEncoding to an encoding that maps to the MySQL character set latin1 or utf8mb4 did not result in the corresponding default connection collation (latin1_swedish_ci or utf8mb4_0900_ai_ci, respectively) to be used on the server. With this fix, the server default is used in the situation. (Bug #28207422)

• Calling UpdatableResultSet.updateClob() resulted in an SQLFeatureNotSupportedException. It was because the implementation of the method was missing from Connector/J, and it has been added with this fix. (Bug #28207088)

• When a connection property's value contained an equal sign (“=”) in itself, an exception (“WrongArgumentException: Malformed database URL”) was thrown. This was due to an error in the parser for the connection URL, which has been corrected by this fix. (Bug #28150662, Bug #92485)

• Connector/J threw a SQLSyntaxErrorException when the parameter tableName for DatabaseMetaDataUsingInfoSchema.getTables() had a null argument. (Bug #28034570, Bug #90887)

• Setting rewriteBatchedStatements=true and useLocalTransactionState=true caused transactions to be uncommitted for batched UPDATE and DELETE statements. It was due to the intermediate queries for enabling multiquery support on the server resetting the local transaction state as a side effect. With this fix, the local transaction state is preserved when the intermediate queries are executed. (Bug #27658489, Bug #89948)

• Rewriting prepared INSERT statements in a multiquery batch failed with a BatchUpdateException when the statements did not contain place holders. This was due a faulty mechanism for query rewriting, which has been corrected by this fix. (Bug #25501750, Bug #84813)

• When using batched prepared statements with multiple queries per statement, queries rewriting was incorrect, resulting in the wrong queries being sent to the server. (Bug #23098159, Bug #81063)

• Record updates failed for a scrollable and updatable PreparedStatement when the WHERE clause for the updater or refresher contained fractional timestamp values and the connection property sendFractionalSeconds was set to false. It was because in the situation, Connector/J did not perform the proper adjustments of the fractional parts in the WHERE clause values according to the length of the field’s fractional part as defined in the database. This fix makes Connector/J perform the proper adjustment to the fractional part, so that the WHERE clause value can be properly compared to the value fetched from the database. (Bug #22305979)

• Some tests in the testsuite failed as they could not recognize system time zone values like CEST or WEST, even with the connection property serverTimezone set. This was because the value of serverTimezone in the testsuite URLs, after being processed by the testsuite, was not actually propagated as a connection property to Connector/J. This fix makes sure the property is in the actual URLs passed to Connector/J. (Bug #21774249)

• When a Java Date value was bound to a PreparedStatement parameter, attempts to format the value by a proleptic GregorianCalendar failed to make the dates proleptic, so that dates before the Julian-Gregorian cutover (October 15, 1582) were stored wrongly. With this fix, a proleptic calendar is properly used if supplied to the setDate() method.

  Note that when trying to set or retrieve dates before the Julian-Gregorian cutover with PreparedSatement methods, a proleptic GregorianCalendar should always be explicitly supplied to the setDate() and getDate() method. For details, see Known Issues and Limitations. (Bug #18749544, Bug #72609)