MySQL Connector/J 8.0 Release Notes
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.
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 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
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
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
and
Configuration Properties
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 for
details, including how to use the utf8mb3
character set now for connection.
(Bug #23227334, Bug #81196)
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, Bug #92485)
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.
(Bug #18749544, Bug #72609)