MySQL Lists are EOL. Please join:

List:Announcements« Previous MessageNext Message »
From:Nawaz Nazeer Ahamed Date:October 22 2018 2:40pm
Subject:MySQL Connector/J 8.0.13 has been released
View as plain text  
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


Thread
MySQL Connector/J 8.0.13 has been releasedNawaz Nazeer Ahamed22 Oct