MySQL Connector/Java 8.0.8-dmr has been released

Balasubramanian Kandasamy <[email protected]> Thu, 28 Sep 2017 18:59:22 +0530
Newsgroups gmane.comp.db.mysql.general,gmane.comp.db.mysql.packagers,gmane.comp.db.mysql.java
Message-ID <[email protected]>
--------------5B4747C9C21514B71996F44C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Dear MySQL users,

MySQL Connector/J 8.0.8 Development Release is a development milestone
release for the 8.0.x series.

This release includes the following new features and changes, also
described in more detail on

https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8-0-8.html

MySQL Connectors and other MySQL client tools and applications now
synchronize the first digit of their version number with the (highest)
MySQL server version they support.
This change makes it easy and intuitive to decide which client version
to use for which server version.

As always, we recommend that you check the "CHANGES" file in the download
archive to be aware of changes in behavior that might affect your 
application.

To download MySQL Connector/J 8.0.8 dmr, see the "Development
Releases" tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

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

      * Bugs Fixed

    Functionality Added or Changed

      * Packaging: RPM and Debian packages for installing
        Connector/J are now available from the Connector/J
        Download page
        (http://dev.mysql.com/downloads/connector/j/).

      * 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
        (http://dev.mysql.com/doc/dev/connector-j) for more
        details.

      * 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
  (http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-configuration-properties.html)
        for details.

      * X DevAPI: To support row locks
(http://dev.mysql.com/doc/refman/5.7/en/innodb-locking-reads.html)
        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
        (http://dev.mysql.com/doc/dev/connector-j) for more
        details.

      * 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();


      * 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.

      * 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
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-configuration-properties.html) 

        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
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-configuration-properties.html) 

        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)


On behalf of Oracle MySQL Release Team
Balasubramanian Kandasamy



--------------5B4747C9C21514B71996F44C--