MySQL Connector/J Release Notes  /  Changes in MySQL Connector/J Version 8.x  /  Changes in MySQL Connector/J 8.0.8 (2017-09-28, Development Milestone)

Changes in MySQL Connector/J 8.0.8 (2017-09-28, Development Milestone)

Version 8.0.8 Development Milestone is the latest development release of the 8.0 branch of MySQL Connector/J, providing an insight into upcoming features. It is suitable for use with MySQL Server versions 5.5, 5.6, 5.7, and 8.0. It supports the Java Database Connectivity (JDBC) 4.2 API.

Functionality Added or Changed

  • Packaging: RPM and Debian packages for installing Connector/J are now available from the Connector/J Download page. (WL #9875)

  • X DevAPI: Connector/J has implemented a new interface of the X Dev API that allows the retrieving, adding, removing, and updating of persistent session continuation data. The implementation includes the following:

    • A SessionConfig object that holds the information for a session configuration data set.

    • A PersistenceHandler interface that allows custom implementations of persistence handlers.

    • A PasswordHandler interface that allows custom implementations of password handling code.

    • A SessionConfigManager class for editing and fetching Sessionconfig objects, and defining instances of the PersistenceHandler and PasswordHandler.

    See MySQL Connector/J X DevAPI Reference for more details. (WL #9868)

  • X DevAPI: A new connection property, xdevapi.auth, has been added for specifying the authentication mechanism for connections using the X Protocol. Allowed values are MYSQL41, PLAIN, and EXTERNAL. See the entry for the new property in Configuration Properties for details. (WL #10620)

  • X DevAPI: To support row locks for the find() method of the X DevAPI, the FindStatement and the SelecStatement interfaces have been extended with the following methods:

    • lockExclusive(), which works like SELECT ... FOR UPDATE for relational tables.

    • lockShared(), which works like the SELECT ... LOCK IN SHARED MODE (for MySQL 5.7) or SELECT ... FOR SHARE (for MySQL 8.0) for relational tables.

    See MySQL Connector/J X DevAPI Reference for more details. (WL #10936)

  • X DevAPI: Connector/J now supports the expanded syntax for the IN and NOT IN operator, which can check if a sub-expression is contained inside another one; for example:

    // For documents
    coll.find("$.b IN [100,101,102]").execute();
    coll.find("'some text with 5432' in $.a").execute();
    coll.find("1 in [1, 2, 4]").execute();
    coll.find("{'a': 3} not in {'a': 1, 'b': 2}").execute();
    // For relational tables
    tbl.select().where("3 not in [1, 2, 4]").execute();
    tbl.select().where("'qqq' not in $.a").execute();
    tbl.select().where("{'a': 1} in {'a': 1, 'b': 2}").execute();

    (WL #10935)

  • X DevAPI: A number of changes have been implemented for the drop methods for the X DevAPI:

    • Removed dropCollection(schemaName, collectionName) and dropTable(schemaName, tableName) from Session.

    • Added dropCollection(collectionName) and dropTable(tableName) to Schema.

    • Schema.dropView() now executes immediately and returns void; also, the ViewDrop interface has been removed.

    • Collection.dropIndex() now executes immediately and returns void; also the DropCollectionIndexStatement interface has been removed.

    • The drop methods now succeed even if the objects to be dropped do not exist.

    (WL #10532)

  • Conversion from the MySQL TIME data to java.sql.Date is now supported. In the past, a getDate() retrieving data from a TIME column would throw an SQLException. Now, such a retrieval returns a java.sql.Date object containing the time value expressed in number of milliseconds from the Java epoch; also returned is the warning: Date part does not exist in SQL TIME field, thus it is set to January 1, 1970 GMT while converting to java.sql.Date. (Bug #26750807)

  • A new connection property, enabledTLSProtocols, can now be used to override the default restrictions on the TLS versions to be used for connections, which are determined by the version of the MySQL Server that is being connected to. By providing a comma-separated list of values to this option (for example, TLSv1,TLSv1.1,TLSv1.2) users can, for example, prevent connections from using older TLS version, or allow connections to use TLS versions only supported by a user-compiled MySQL Server. See the entry for the new property in Configuration Properties for details. Thanks to Todd Farmer for contributing the code. (Bug #26646676)

  • Updated the timezone mappings using the latest IANA and CLDR time zone databases. (Bug #25946965)

  • A new option for the loadBalancingStrategy connection property called serverAffinity has been added. The servers listed in the new connection property serverAffinityOrder (which should be a subset of the servers in the host list of the connection URL) are contacted in the order they are listed until a server is available or until the list of servers is exhausted, at which point a random load-balancing strategy is used with the hosts not listed by serverAffinityOrder. See descriptions for loadBalancingStrategy and serverAffinityOrder in Configuration Properties for details. (Bug #20182108)

Bugs Fixed

  • Important Change: Following the changes in MySQL Server 8.0.3, the system variables tx_isolation and tx_read_only have been replaced with transaction_isolation and transaction_read_only in the code of Connector/J. Users should update Connector/J to this latest release in order to connect to MySQL 8.0.3. They should also make the same adjustments to their own applications if they use the old variables in their codes. (Bug #26440544)

  • X DevAPI: Calling schema.dropView() with a null argument resulted in a NullPointerException. (Bug #26750807)

  • X DevAPI: When dropCollection() was applied on a null collection, a NullPointerException occurred. (Bug #26393132)

  • When using cached server-side prepared statements, a memory leak occurred as references to opened statements were being kept while the statements were being decached; it happened when either the close() method has been called twice on a statement, or when there were conflicting cache entries for a statement and the older entry had not been closed and removed from the opened statement list. This fix makes sure the statements are properly closed in both cases. Thanks to Eduard Gurskiy for contributing to the fix. (Bug #26633984, Bug #87429)

  • The regression test for Bug#63800 failed because the default value of the system variable explicit_defaults_for_timestamp of MySQL Server has been changed since release 8.0.2. The test has been adjusted to take the change into consideration. (Bug #26501245)

  • Running callable statements against MySQL Server 8.0 resulted in the SQLException: ResultSet is from UPDATE. No Data. (Bug #26259384)

  • Secure JDBC connections did not fall back to the default truststore when a custom one was not provided. (Bug #26243128)

  • In com/mysql/jdbc/ServerPreparedStatement.java, the arguments resultSetType and resultSetConcurrency for a call of Connection.preparedStatement() were swapped. (Bug #25874048, Bug #85885)

  • Some JDBC proxied objects were missing the proper handlings of the equals() methods, thus even comparison of one of these proxied objects to its own self with equals() yielded false. This patch introduces proper handlings for the equals() method in all the relevant proxies. (Bug #21931572, Bug #78313)

  • A server-side prepared statement was not closed when the same statement was being prepared again while the original statement was being cached. This was caused by the silent replacement of the cache entry of the old statement by the new. When this happened repeatedly, it caused eventually the complaint that max_prepared_stmt_count was exceeded. This fix makes sure that when a cache entry for a statement replaces an older one, the older statement is immediately closed. (Bug #20066806, Bug #74932)