MySQL Connector/J 8.0.13 has been released

--------------5A9DB63BF74848F051A19696
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Dear MySQL users,

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.

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-13.html

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.13 GA, see the "Generally Available
(GA) Releases" tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

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


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
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-installing.html)
        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
        (http://dev.mysql.com/doc/x-devapi-userguide/en/) for details.

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

        for details.

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

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

      * 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
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html). 

        (Bug #18749544, Bug #72609)


Enjoy and thanks for the support!

On behalf of the MySQL Release Team,
Nawaz Nazeer Ahamed


--------------5A9DB63BF74848F051A19696--