MySQL Blog Archive
For the latest blogs go to blogs.oracle.com/mysql
MySQL Connector/J 8.0.13 has been released
Posted on Oct 22, 2018 by MySQL Release Engineering
Category: Release Announcements
Tags: connectors, mysql-development, connector-j

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

 Search
Categories