MySQL Connector/J 8.0.13 has been released

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

Connector/J 8.0.11, the Face for Your Brand New Document-oriented Database

This is exciting news: MySQL 8.0 is officially GA!

This time around we do not only offer you a new MySQL Server full of exciting new features, but also a brand new toolset that let you make the most out of MySQL, including the now GA Java database driver, MySQL Connector/J 8.0.11!

This story is about Connector/J but before even I get started I must say a few words about the new features that conducted the development of this new driver. If you prefer, you can jump directly to the Connector/J 8.0 topic below.

What’s new in MySQL Server 8.0?

There’s a new Client/Server communication protocol in MySQL: the X Protocol

The X Protocol introduced in MySQL 8.0 series is the backbone for the document-oriented paradigm in the MySQL ecosystem. The new X Protocol and the old MySQL Client/Server Protocol are both available in this new MySQL Server. It is up to the clients to choose which one to implement for connecting to MySQL servers, either through pure protocol implementations or via a MySQL C API library, for example. Clearly the easiest option is to use one of the MySQL connectors that already implement either one or both of the protocols that we offer for the programming language of your choice.

The X Protocol is implemented as a plugin for the MySQL Server—the X Plugin. By default the X Plugin is listening on TCP port 33060.

Among the main features in the X Protocol you’ll find data serialization via Protocol Buffers, Vectored I/O, Pipelining, SASL authentication, extensible messages via protobuf, and so on. We are also working on other interesting features so stay tuned. I invite you to go to the X Protocol documentation to learn all about it.

So, there’s also the new X Plugin

As mentioned before, the X Plugin implements the X Protocol on the MySQL Server side.

Besides implementing the X Protocol, the X Plugin is responsible for defining the message structure that provides the base for the X DevAPI – the API that exposes a MySQL server as a document-oriented database. It is also responsible for communicating with the internal components of the server: the storage engines, the query parser, the query optimizer, query executors, and so on. In the other end, it also manages all active X DevAPI sessions and handles clients’ requests.

As of MySQL 8.0 GA the X Plugin is loaded by default. Chances are that it is already available for you in your new server installation.

Knowledge of the X Plugin will provide you insights into the features of the X DevAPI as well as how MySQL handles those features. The X Plugin documentation is, again, your best companion for learning about the plugin.

MySQL as a document-oriented database: the X DevAPI

It is through the new X DevAPI that the document-oriented database features in MySQL are exposed. This is how you use MySQL as a document store, a schema-less, and therefore schema-flexible storage system for documents. When using MySQL as a document store you do not need to know and define all possible attributes of your data before storing and operating with it. This differs from working with a relational database and storing data in a table, where all columns of the table must be known and defined before adding data to the database.

Long ago MySQL added support for JSON data along with a large variety of functions and operations that allow creating, manipulating, and handling JSON structures and values. This new data type combined with the old and reliable InnoDB based tables, with the ability to create dynamically generated columns and indexes over them, constituted the right environment for spawning MySQL’s interpretation of our document store.

The X DevAPI provides you with a unifying API for creating and handling documents in JSON format in MySQL, which you can use to develop applications. It offers a modern programming interface with a simple yet powerful design that provides support for established industry-standard concepts. One of the major keynotes in the X DevAPI is harmony you get when working with different MySQL Connectors that implement it. It becomes so easy for a developer to switch between different programming languages and still get the same “look & feel” from different Connectors.

Although MySQL Connectors are the typical entry point for using the X DevAPI, you can actually start using it even without jumping into a programming language; just try it in the new command-line client: MySQL Shell.

MySQL Reference Manual contains an overview of MySQL as a Document Store which I recommend reading. The X DevAPI User Guide is the central source of information for all common aspects of this new and exiting API.

And here’s the new MySQL command-line client: MySQL Shell

MySQL Shell is an advanced command-line client and code editor for MySQL server. In addition to the usual SQL functionality provided by the mysql client, MySQL Shell provides scripting capabilities for JavaScript and Python and includes APIs for working with MySQL. When MySQL Shell is connected to the MySQL server through the X Protocol, the X DevAPI can be used to work with both relational tables and document data.

This is the perfect companion tool for your development work with any of the new Connectors supporting X DevAPI, as it allows viewing and manipulating documents and collections easily, so that you can prototype X DevAPI calls, expressions syntax, and a lot more before starting coding them into your projects.

As of MySQL Server 8.0.11, MySQL Shell is not included in the server’s default toolset, so you will have to install it separately. Get started with MySQL Shell by downloading it from MySQL Downloads and get more info from its User Guide.

TL;DR: After all, this post is about Connector/J!

Connector/J 8.0, the new GA JDBC/X DevAPI driver for MySQL databases

I am particularly proud to announce that Connector/J 8.0 is now GA. This is the officially recommended version to use in your projects from now on. And it doesn’t matter what server version you are using.

Note that Connector/J became GA with version 8.0.11, skipping version 8.0.10, which was expected to appear after the last Release Candidate. If you haven’t heard about it, just know that several MySQL products, including Connector/J, will be version aligned with MySQL Server releases from now on. This means that you can expect new releases of Connector/J every time there is a MySQL Server 8.0 release. This doesn’t mean, however, that you must also align the Connector/J library in your projects with the server version you are connecting to. As always, our recommendation is to use the latest Connector/J library, no matter what server version you use.

Connector/J 8.0 is the rightful successor of the widely used Connector/J 5.1. Now compiled in Java 8 only, it comes with huge refactoring. Connector/J 8.0 is better organized and follows better and more up-to-date coding practices, as well as many of the exciting features of Java 8. This is also the driver to use with the new X DevAPI in the Java ecosystem.

We know that, despite our best efforts, no code is ever perfect. This is why we are continuously working on it and we really appreciate your comments and suggestions for improving this product. Therefore, please continue to use the resources we provide to get in touch with us, including the MySQL bug system, the Connector/J forum, the GitHub repository or MySQL Community Slack, with which you can talk to us directly.

Connector/J 8.0 does not only implement the JDBC 4.2 API, but also the X DevAPI for new document store features, so you can use them interchangeably. As matter of fact, the two API implementations share a lot of core base code. This is so to offer you a better user experience and versatility in your projects.

The new X DevAPI implementation provides an up to date and more user-friendly programming method with its Fluent Interface API. It all starts with obtaining a Session object, which is similar to getting a JDBC Connection, and, from then on, you have a tool to work with with Schemas, Collections and even old-style Tables. Always remember to keep Connector/J Developer Guide and the Connector/J X DevAPI Reference handy for quick reference.

Getting started with Connector/J 8.0 and X DevAPI

Initial setup & getting Connector/J binaries

Your first step should be setting up a new Java project using whatever method you prefer, immediately followed by attaching the Connector/J library. You can do it either by setting up a Maven dependency in your pom.xml or by downloading the Connector/J bundle from the official MySQL Downloads page.

In order to setup a Maven dependency just add the following in the <dependencies> section of your project’s pom.xml file, then proceed with the usual Maven commands to build and run your project:

If you choose to download the Connector/J bundle from the MySQL repositories, you must extract its contents to some temporary place and copy the following files to your project’s libraries directory:

  • mysql-connector-java-8.0.11.jar
  • lib/protobuf-java-2.6.0.jar

Instead of using the provided Protocol Buffers Java API library, you could also get protobuf-java-2.6.0.jar from its official repositories. Note that there are a few other Java libraries in the libs directory and you are not required to add them to your project if you don’t use any of the features that need them.

If you are bold enough, you can even grab the Connector/J source code and compile it yourself. This is not a task for a Java novice but you will find some help in Connector/J Developer Guide – Installing from source.

I will not go into more details but you must make sure the classpath settings include the two libraries in all further Java commands or project configurations in your IDE.

Needless to say that you will also need a MySQL Server 8.0.11 (at least) in order to proceed. If you don’t have one, you can install it in few easy steps; just choose the right package for you and follow the instructions in the Reference Manual.

Hello World, using JSON documents and X DevAPI

It is time to create the a simple demo Java class. Lets call it HelloWorld.java.

You should implement proper exception handling in your application. For the sake of this demo I’ll just throw Exception  in the method main .

First thing to do is to establish a connection to the MySQL server, that is, obtaining a Session in X DevAPI terminology. Lets assume the X Plugin is listening on the default port 33060. To do this in Connector/J you first need to instantiate a SessionFactory  and then use it to create the Session  object for you:

Replace the user and password according to your database setup. The same goes for the host and port parts.

Note that jonhdoe is just a standard MySQL user. Since this user will be used to create objects in the database, please make sure that it has the required permissions to do so.

The connection string in this sample is pretty straightforward. It identifies the protocol to use (mysqlx), the user, password, hostname and port. Except for the part johndoe:password@ this is quite similar to the old JDBC connection strings. In fact, Connector/J 8.0 lets you use this same syntax for JDBC connections too.

The previous code returns a Session  object you can to use manage schemas. A Schema is essentially a MySQL database. Lets create one for this demo:

By now there should be a new database named demo in your MySQL server instance.

The Schema object you have got lets you manage collections and tables in the database. Just keep in mind that collections are just tables with a specific column structure, which you shouldn’t modify in any way other than through a X DevAPI interface.

Let’s now create a collection and add a few documents to it:

So, this creates a table named greetings in the demo database. This table has two columns: doc and _id:

The X DevAPI, through the X Plugin, manages this 1:1 mapping between the collection greetings and the table with the same name. Following X DevAPI code related to this collection operates over this relational table using a panoply of JSON functions available in MySQL server, however, all this happens internally in the server and it is transparent to clients.

Lets wrap this demo up with a couple of data retrieving operations:

This time we work with the Collection instance in order to fetch its data using two simple filters, exactly as what you would do using standard SQL tables.

The returned object DocResult  can then be used to get the list of the documents filtered from the collection. Each document is exposed as a DbDoc  instance. DbDoc  is particularly important in Connector/J X DevAPI implementation, because it represents a JSON object, something that Java doesn’t support natively.

This should be the end result of this simple demo:

With exception of the _id values, which are generated each time you add a document to a collection, you should get the same results as me, if you try out the demo.

What else?

This little demo was about a few basic CRUD operations on Collections, but there’s a lot more in the X DevAPI:

  • CRUD operations on Collections and Tables;
  • Parameter binding;
  • Document patching;
  • Various types of results and metadata;
  • Raw (SQL) statements execution;
  • Transaction save-points;
  • Row locking mechanisms;
  • Simplified expression syntax, etc.

Closing comments

MySQL Connector/J 8.0.11 is the new GA version of Connector/J for MySQL databases. It implements the X DevAPI, an exciting new feature that enables the use of MySQL Server 8.0 as a document-oriented database.

The 8.0 series of the Connector/J driver, fully re-factored from the previous GA version 5.1, requires Java 8 or above to work with. If that is a limitation for you, you can still use the Connector/J 5.1 series that supports Java 5 up to Java 8. We’ll keep maintaining the 5.1 series for the time being, but be mindful that you will only be able to use JDBC with it.

Although a feature preview version of the X DevAPI is also available in the MySQL Server 5.7 series, which you could use with Connector/J 8.0.11 and later, I recommend that you use the X DevAPI with MySQL 8.0. The X Plugin implementation in the  5.7 series has some known limitations and, most likely, no new features will be back ported to MySQL 5.7.

Exiting times are coming for all of us. Enjoy the new features we offer you and let us know what you think about them.

On behalf of the MySQL Connector/J development team, I wish you a pleasant programming experience with Connector/J 8.0.

MySQL Connector/Java 8.0.9-rc has been released

Dear MySQL users,

MySQL Connector/Java 8.0.9-rc is the first Release Candidate
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.

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-9.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/Java 8.0.9-rc, see the “Development
Releases” tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

Changes in MySQL Connector/J 8.0.9 (2018-01-30, Release
Candidate)

Functionality Added or Changed

* X DevAPI: In the process of refining the definition of
the X DevAPI to cover the most relevant usage scenarios,
the following API components have been removed from the X
DevAPI implementation for Connector/J:

+ Components that support DDLs for views, including
the createView(), dropView(), and modifyView()
methods.

+ Components that support DDLS for tables, including
the createTable(), dropTable(), and modifyTable()
methods.

+ Components that support session configurations,
including the SessionConfig object, the
PersistenceHandler interface, the PasswordHandler
interface, and the SessionConfigManager class.

* X DevAPI: Added the setSavepoint(), rollbackTo(), and
releaseSavepoint() methods to the Session interface to
support the SAVEPOINT
(http://dev.mysql.com/doc/refman/8.0/en/savepoint.html),
ROLLBACK TO SAVEPOINT
(http://dev.mysql.com/doc/refman/8.0/en/savepoint.html),
and RELEASE SAVEPOINT
(http://dev.mysql.com/doc/refman/8.0/en/savepoint.html)
statements. See MySQL Connector/J X DevAPI Reference
(http://dev.mysql.com/doc/dev/connector-j) for more
details.

* X DevAPI: A new patch() function has been added to the
ModifyStatement interface. The function accepts an
JSON-like object describing document changes and applies
them to documents matched by the modify() filter. See
MySQL Connector/J X DevAPI Reference
(http://dev.mysql.com/doc/dev/connector-j) for more
details.

* X DevAPI: The createIndex() method for the Collection
interface now has a new syntax. See MySQL Connector/J X
DevAPI Reference
(http://dev.mysql.com/doc/dev/connector-j) for more
details.

* X DevAPI: Added the following methods for single-document
operations in the X DevAPI:

+ replaceOne()

+ addOrReplaceOne()

+ getOne()

+ removeOne()
See MySQL Connector/J X DevAPI Reference
(http://dev.mysql.com/doc/dev/connector-j) for more
details.

* X DevAPI: Setters and getters methods have been added for
the configuration properties with the MysqlDataSource,
MysqlXADataSource, and MysqlConnectionPoolDataSource
classes.

* X DevAPI: The connection property enabledTLSProtocols can
now be used to select the allowed TLS versions for an X
Protocol connection to the server.

* Connector/J now supports the new caching_sha2_password
authentication plugin, which is the default
authentication plugin for MySQL 8.0.4 and later (see
Caching SHA-2 Pluggable Authentication
(http://dev.mysql.com/doc/refman/8.0/en/caching-sha2-plug
gable-authentication.html) for details).
Note
To authenticate accounts with the caching_sha2_password
plugin, either a secure connection to the server using
SSL
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-using-ssl.html)
or an unencrypted connection that supports password exchange
using an RSA key pair (enabled by setting one or both of the
connecting properties allowPublicKeyRetrieval and
serverRSAPublicKeyFile) must be used.
Because earlier versions of Connector/J 8.0 do not
support the caching_sha2_password authentication plugin
and therefore will not be able to connect to accounts
that authenticate with the new plugin (which might
include the root account created by default during a new
installation of a MySQL 8.0 Server), it is highly
recommended that you upgrade now to Connector/J 8.0.9, to
help ensure that your applications continue to work
smoothly with the latest MySQL 8.0 Server.

* Connector/J now takes advantage of the MySQL Server 8.0
data dictionary by making the connection property
useInformationSchema true by default; this makes
Connector/J, by default, access the data dictionary more
efficiently by querying tables in the INFORMATION_SCHEME.
See INFORMATION_SCHEMA and Data Dictionary Integration
(http://dev.mysql.com/doc/refman/8.0/en/data-dictionary-information-schema.html)
for details. Users can still set useInformationSchema to false,
but for MySQL 8.0.3 and later, some data dictionary queries might
then fail, due to deprecations of older data dictionary features.

* In the past, query texts were always passed as strings to
QueryInterceptor methods, even if the texts were not
actually used by them. Now, only suppliers for the texts
are passed, and the texts are only extracted by get()
calls on the suppliers.

Bugs Fixed

* The connection property nullNamePatternMatchesAll, when
set to false (which was the default value), caused some
DatabaseMetaData methods to throw an error when a null
search string was used with them. The behavior was not
compliant with the JDBC specification, which requires
that a search criterion be ignored when a null search
string is used for it. The connection property has now
been removed from Connector/J 8.0. (Bug #26846249, Bug
#87826)

* Trying to print the query in a PreparedStatement using
the toString() method after it has been closed resulted
in an exception (No operations allowed after statement
closed) being thrown. (Bug #26748909)

* When working with MySQL Server 8.0, an update or delete
statement for a CONCUR_UPDATABLE ResultSet failed when
the ResultSet’s primary keys included a boolean column
and the character set used was not latin1. (Bug
#26266731)

* Connector/J failed to recognize a server greeting error
it received during a handshake with the server and parsed
the error message as a normal greeting packet, causing an
ArrayIndexOutOfBoundsException to be thrown. (Bug
#24924097)

On Behalf of the MySQL/Oracle Release Engineering Team,
Hery Ramilison

MySQL Connector/J 5.1.45 has been released

Dear MySQL Users,

MySQL Connector/J 5.1.45, a maintenance release of the production 5.1
branch has been released. Connector/J is the Type-IV pure-Java JDBC
driver for MySQL.

MySQL Connector Java is available in source and binary form from the
Connector/J download pages at
http://dev.mysql.com/downloads/connector/j/5.1.html
and mirror sites as well as Maven-2 repositories.

MySQL Connector Java (Commercial) is already available for download on the
My Oracle Support (MOS) website. This release will shortly be available on
eDelivery (OSDC).

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.

MySQL Connector/J 5.1.45 includes the following general bug fixes and
improvements, also available in more detail on
http://dev.mysql.com/doc/relnotes/connector-j/en/news-5-1-45.html

Changes in MySQL Connector/J 5.1.45 (2017-11-30)

Version 5.1.45 is a maintenance release of the production 5.1
branch. It is suitable for use with MySQL Server versions
5.5, 5.6, and 5.7. It supports the Java Database Connectivity
(JDBC) 4.2 API.

Functionality Added or Changed

* Character set mappings have been added for the following
collations:

+ utf8mb4_ja_0900_as_cs_ks

+ utf8mb4_0900_as_ci

+ utf8mb4_ru_0900_ai_ci

+ utf8mb4_ru_0900_as_cs
(Bug #26724085)

Bugs Fixed

* With the combination of the connection properties
useServerPrepStmts=true, useInformationSchema=true,
useCursorFetch=true, and defaultFetchSize=N, if a warning
was returned for a query during connection
initialization, a NullPointerException would result when
Connector/J tried to get the warning. That was because
the charsets were not yet initialized in the connection
at the time. This fix corrects the problem by preventing
cursors from being used when Connector/J fetches warnings
from the server. (Bug #27131768)

* When a communications exception was thrown by Connector/J
after a socket timeout event, because the current
transaction did not get rolled back automatically, if
autoReconnect=true, the next statement execution by
Connector/J might reuse the old server session and
continued with the previous transaction. This might
confuse the client application on the transaction status
of the statements it was handling. This fix corrects the
issue by forcibly closing the network resources after a
communication or IO exception, causing the server to
rollback the transaction. (Bug #27047676, Bug #88232)

* Normally, when the socketTimeout option has been set and
a socket timeout occurs on the client side, the server
may continue working and returning query results. At the
next query executed after the timeout, Connector/J first
clears the socket input stream and then sends a ping
request to the server.
However, an error occurred if the autoReconnect option
was set to true and, after reconnection, a new query was
executed by Connector/J, and the results from the
previous queries arrived before Connector/J sent its ping
request to the server, in which case the old packages
might be mistaken as results for the new query. This fix
corrects the issue by forcibly closing the network
resources after a communication or IO exception. The next
statement execution recreates the IO stream if
autoReconnect=true; otherwise, the connection stays
closed. (Bug #27040063, Bug #88242)

* High garbage collection pressure was observed when there
were a lot of queries performed using server-side
prepared statements. This patch reduces the pressure by
optimizing the generation process of the cache keys for
the prepared statements. Thanks to Johnathan Crawford for
contributing the patch. (Bug #26939943, Bug #88021)

* A number of regression tests for former bug fixes failed
when they were run against MySQL Server 8.0.3, because
binary logging has been enabled by default on the server.
The tests have now been fixed. (Bug #26794652)

* A number of regression tests for former bug fixes failed
when they were run against MySQL Server 8.0.3 because of
the name changes of some of the INFORMATION_SCHEMA tables
on the server. The tests have now been fixed. (Bug
#26794602)

* When server-side prepared statements and cursor-based
result sets were used, exceptions were thrown when
applications made calls to get output parameters of
INTEGER or BIGINT type from a result set. (Bug #26771560,
Bug #87704)

On Behalf of the MySQL/ORACLE RE Team,
-Sreedhar S

MySQL Connector/Java 8.0.8-dmr has been released

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

     * 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

MySQL Connector/J 5.1.44 has been released

Dear MySQL Users,

MySQL Connector/J 5.1.44, a maintenance release of the production 5.1
branch has been released. Connector/J is the Type-IV pure-Java JDBC
driver for MySQL.

MySQL Connector Java is available in source and binary form from the
Connector/J download pages at
http://dev.mysql.com/downloads/connector/j/5.1.html
and mirror sites as well as Maven-2 repositories.

MySQL Connector Java (Commercial) is already available for download on the
My Oracle Support (MOS) website. This release will be available on eDelivery
(OSDC) in next month’s upload cycle.

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.

MySQL Connector/J 5.1.44 includes the following general bug fixes and
improvements, also available in more detail on
http://dev.mysql.com/doc/relnotes/connector-j/en/news-5-1-44.html

Changes in MySQL Connector/J 5.1.44 (2017-08-30)

Version 5.1.44 is a maintenance release of the production 5.1
branch. It is suitable for use with MySQL Server versions
5.5, 5.6, and 5.7. It supports the Java Database Connectivity
(JDBC) 4.2 API.

Functionality Added or Changed

* 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 Driver/Datasource Class Names, URL Syntax and
Configuration Properties for Connector/J
(http://dev.mysql.com/doc/connector-j/5.1/en/connector-j-
reference-configuration-properties.html) for details.
Thanks to Todd Farmer for contributing the code. (Bug
#26646676)

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)

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

On Behalf of the MySQL/ORACLE RE Team,
-Sreedhar S

MySQL Connector/J 5.1.43 has been released

Dear MySQL Users,

MySQL Connector/J 5.1.43, a maintenance release of the production 5.1 branch has been released. Connector/J is the Type-IV pure-Java JDBC driver for MySQL.

MySQL Connector Java is available in source and binary form from the Connector/J download pages at http://dev.mysql.com/downloads/connector/j/5.1.html and mirror sit
repositories.

MySQL Connector Java (Commercial) is already available for download on the My Oracle Support (MOS) website. This release will be available on eDelivery
(OSDC) in next month’s upload cycle.

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.

MySQL Connector/J 5.1.43 includes the following general bug fixes and improvements, also available in more detail on http://dev.mysql.com/doc/relnotes/connector-j/en
nges in MySQL Connector/J 5.1.43 (2017-07-21)

Version 5.1.43 is a maintenance release of the production 5.1 branch. It is suitable for use with MySQL Server versions 5.5, 5.6, and 5.7. It supports the Java Da
(JDBC) 4.2 API.

Functionality Added or Changed

* Update the time zone 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 serverA
hould 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
at which point a random load-balancing strategy is used with the hosts not listed by serverAffinityOrder. See descriptions for loadBalancingStrategy and serverAffin
tasource Class Names, URL Syntax and Configuration Properties for Connector/J
(http://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-configuration-properties.html)
for details. (Bug #20182108)

Bugs Fixed

* Secure JDBC connections did not fall back to the default truststore when a custom one was not provided. (Bug
#26243128)

* Connector/J failed a number of regression tests in the testsuite related to geographic information system (GIS)
functions because of changes to GIS support by the MySQL server. The fix corrects the tests. (Bug #26239946, Bug
#26140577)

* Attempts to connect to a server started with collation utf8mb4_de_pb_0900_ai_ci resulted in null pointer exceptions. (Bug #26090721)

* In com/mysql/jdbc/ServerPreparedStatement.java, the arguments resultSetType and resultSetConcurrency for a call of Connection.preparedStatement() were swapped
#25874048, Bug #85885)

* A NullPointerException was returned when getDate(),
getTime(), or getTimestamp() was called with a null Calendar. This fix makes Connector/J throw an SQLException in the case. (Bug #25650305)

* Some JDBC proxied objects were missing the proper handling of the equals() methods, thus even comparison of one of these proxied objects to its own self with
e. This patch introduces proper handling 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 cause
cement 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 exceede
e 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 the MySQL/Oracle Release Engineering Team,
Hery Ramilison

MySQL Connector/Java 8.0.7-dmr has been released

Dear MySQL users,

MySQL Connector/J 8.0.7 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-7.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.

Connector/J 8.0.7 is the first release to use the new numbering. It is the successor to Connector/J 6.0.6

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.7 dmr, see the “Development Releases” tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!


Changes in MySQL Connector/J 8.0.7 (2017-07-10, Development Milestone)

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.

Connector/J 8.0.7 is the first release to use the new
numbering. It is the successor to Connector/J 6.0.6.

* Functionality Added or Changed

* Bugs Fixed

Functionality Added or Changed

* X DevAPI: There are changes to some methods related to
the Result interface:

+ getLastDocumentId() and getLastDocumentIds() have
been replaced with getDocumentId() and
getDocumentIds(), which are put under a new
AddResult interface that extends Result.

+ A new getAutoIncrementValue() method is added to the
new InsertResult interface that extends Result.
See MySQL Connector/J X DevAPI Reference
(http://dev.mysql.com/doc/dev/connector-j) for more
details. (Bug #25207784)

* X DevAPI: It is no longer permitted to pass an empty
search condition, such as the NULL value or an empty
string, to the Collection.Modify() and
Collection.Remove() methods.

* X DevAPI: Connections using the X Protocol are now secure
by default. Also, the xdevapi.ssl-enable connection
option has been replaced by the xdevapi.ssl-mode option,
which has DISABLED, REQUIRED (default), VERIFY_CA, and
VERIFY_IDENTITY as its permitted values; see the
description for the new option in Configuration
Properties
http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-
reference-configuration-properties.html
for details.

* X DevAPI: Consolidated the BaseSession, NodeSession, and
XSession interfaces into a single
com.mysql.cj.api.xdevapi.Session interface. The following
related changes were also made:

+ Renamed XSessionFactory to SessionFactory.

+ Consolidated the AbstractSession, NodeSessionImpl,
and XSessionImpl classes into the
com.mysql.cj.xdevapi.SessionImpl class.

+ Removed the Session.bindToDefaultShard() method and
the VirtualNodeSession interface.

+ The mysqlx.getNodeSession() method has been renamed
to mysqlx.getSession() and it now returns a Session
object.

+ The DatabaseObject.getSession() method now returns a
Session object (instead of the old Session
interface).
See MySQL Connector/J X DevAPI Reference
(http://dev.mysql.com/doc/dev/connector-j) for more
details.

* To avoid using JDBC statements inside core Connector/J
classes, the following changes have been implemented:

+ Created a new com.mysql.cj.api.Query interface,
which is implemented by StatementImpl.

+ Replaced the
com.mysql.cj.api.jdbc.interceptors.StatementIntercep
tor interface with the
com.mysql.cj.api.interceptors.QueryInterceptor
interface.

+ Added a new method, PacketPayload
preProcess(PacketPayload queryPacket), to
QueryInterceptor.

+ Renamed the connection property
statementInterceptors to queryInterceptors. See
Configuration Properties
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-
reference-configuration-properties.html)
for details.

* Added Japanese collation for the utf8mb4 character set.

Bugs Fixed

* X DevAPI: createView() failed with a NullPointerException
when there were null inputs to it. This fix adds checks
for nulls, and makes Connector/J throw the proper errors
for them. (Bug #25575156)

* X DevAPI: createaTable() failed with a
NullPointerException when there were null inputs to it.
This fix adds checks for nulls, and makes Connector/J
throw the proper errors for them. (Bug #25575103)

* X DevAPI: The connection properties
enabledSSLCipherSuites, clientCertificateKeyStoreUrl,
clientCertificateKeyStoreType, and
clientCertificateKeyStorePassword were ignored for
connections using the X Protocol. (Bug #25494338)

* X DevAPI: Calling getNodeSession() with an URL string
containing SSL parameters caused a
CJCommunicationsException. This has been fixed by
creating a byte buffer to handle SSL handshake data.
(Notice that getNodeSession() has since been consolidated
into getSession().) (Bug #23597281)

* X DevAPI: Concurrent asynchronous operations resulted in
hangs, null pointer exceptions, or other unexpected
exceptions. This has been fixed by correcting a number of
problems with the SerializingBufferWriter and by limiting
the number of buffers sent with a gathering write. (Bug
#23510958)

* X DevAPI: When a thread failed to make a connection to
the server using the X Protocol, the client application
hung. A new connection property,
xdevapi.asyncResponseTimeout (default value is 300s), now
provides a duration beyond which the attempt to connect
timeouts, and a proper error is then thrown. See
description for the new option in Configuration
Properties
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-
reference-configuration-properties.html)
for details. (Bug #22972057)

* Connector/J failed a number of regression tests in the
test suite related to geographic information system (GIS)
functions, because of changes to GIS support by the MySQL
server. The fix corrects the tests. (Bug #26239946, Bug
#26140577)

* Configuration templates named by the connection property
useConfigs were not recognized by Connector/J. (Bug
#25757019, Bug #85555)

* A NullPointerException was returned when getDate(),
getTime(), or getTimestamp() was called with a null
Calendar. This fix makes Connector/J throw an
SQLException in the case. (Bug #25650305)

* An ArrayIndexOutOfBoundsException was thrown when a
server-side prepared statement was used and there was a
NULL in a BLOB, TEXT, or JSON type column in the
ResultSet. (Bug #25215008, Bug #84084)

On Behalf of MySQL/ORACLE RE Team
Gipson Pulla

MySQL Connector/J 5.1.40 has been released

I’m pleased to announce the newest MySQL Connector/J 5.1 Maintenance Release.

As usual, MySQL Connector/J 5.1 can be downloaded from the official distribution channels MySQL Downloads and The Central Repository. The commercially licensed version is available for download at My Oracle Support.

Please don’t forget to consult the CHANGES file in the download archive and/or the release notes page to know what is new and if there are any changes that might affect your applications.

MySQL Connector/J 5.1.40 is the official JDBC driver for MySQL databases and, as such, we are continuously working to make it better, more reliable and faster. This new version delivers several bug fixes and upgrades. This is the current recommend  version and you should upgrade to it as soon as possible.

I’d like to highlight the most relevant fixes and improvements in this release:

Recovered & new features

Previous versions used to silently disable local transaction states management (connection property useLocalTransactionState=true) when server side query cache was enable. This used to be workaround for a know server bug that it’s long time gone. The workaround in Connector/J side, though, survived till these days. I’m pretty sure that the effects will be almost unnoticed but certainly this helps empowering the developer and provides better control over the Connector.

The XA errors mapping in Connector/J was updated with the missing error codes that the server may throw back.

MySQL Fabric support issues

Connector/J 5.1 maintains support for MySQL Fabric, as such, this release comes with a couple fixes to it. Fabric connections are especially prone to problems as they rely on both a connection to a Fabric node and multiple connections to MySQL servers while having to be able to refresh themselves to topology changes, failures and such. A couple of issues caused by communication failures to the Fabric node are now fixed.

Continuous improvement of MySQL data types support

The JSON data type is relatively new in Connector/J. As such, every now and then there is something that needs to be fixed or adjusted. This time it was an encoding issue observed when the JSON strings contained non Latin characters. Additionally, the specific combination of updatable result sets with cursor based fetches was missing the support for the JSON type.

Getting data from BIT columns as numeric values was behaving inconsistently when binary values and ASCII values of numbers matched. As a result, instead of the expected value, it was occurring an extra conversion to String before the data was returned. Also fixed in this release.

Improved internals

Although we aim to, it’s almost impossible to guarantee that the code is free from memory leaks, deadlocks, NPEs and so on. A few of those where caused by some bugs that are now fixed.

Under certain situations the exception interceptor mechanism was being triggered twice. This, not only caused an unwanted additional  processing, but also was hiding the real cause that triggered the interceptor.

Client-side caching of prepared statements while using server-side prepared statements requires extra care because it can easily be a source of memory leaks, both on client and server sides. In this particular scenario, setting a statement as non-poolable was causing a never ending number of prepared statements on server and never deallocated. Per se, this wasn’t a problem for the driver because it is prepared to switch-over to client prepared statements as soon as it is unable to create more on the server, but it wasn’t the desired behavior for sure.

Transactions states managed locally got fixed for when there were exceptions while on the middle of one. Without the fix the rollback and commit wasn’t operating as expected.

The database connection URL syntax got support for several extensions over the year. With that also increased the corner cases that its parsers have to deal with. A couple of them were fixed in this release, specifically a NPE and an incompatibility with host names starting with the word “address”.

Thanks!

Enjoy this new Connector/J release. Get the most out of it by reading its official documentation or by getting the developer’s support directly from the forum channel.

Special thanks to Dong Song Ling and Ryosuke Yamazaki for their valuable contributions.

Thank you all for your support and feedback, and keep in touch!

On behalf of the MySQL Connector/J Team

MySQL Connector/J 6.0.4 has been released

We are pleased to announce the next development release of MySQL Connector/J 6.0 which supports both JDBC 4.2 API and the new X DevAPI.

MySQL Connector/J 6.0.4 can be downloaded from the official distribution channels MySQL Downloads (see the “Development Releases” tab) and The Central repository. MySQL Connector/J source is also available on GitHub.

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

For documentation please visit the MySQL Connector/J 6.0 Developer Guide.

Note that Connector/J 6.0.4 is a milestone release and not intended for production usage.

I’d like to highlight the most important changes in this release:

X DevAPI connection string

The prefix used in connection string for X DevAPI is now unified between MySQL connectors. The “mysql:x:” we used in previous Connector/J 6.0 releases doesn’t work anymore, please use the “mysqlx:” one to establish XSession:

X DevAPI support for views

The com.mysql.cj.api.x.Table interface now represents both database tables and views. Schema.getTables() returns a list of Table objects for each existing database Table and View. Schema.getTable(name) also returns a Table object if the object with a given name is a View.

A new Table interface method was added:

The com.mysql.cj.api.x.View interface existed in previous Connector/J 6.0 releases isn’t available in Connector/J 6.0.4.

MySQL server compliance

MySQL Connector/J 6.0.4 is suitable for use with MySQL server versions 5.5, 5.6, and 5.7 via Java Database Connectivity (JDBC) 4.2 API.

Due to changes in X Protocol implementation MySQL Connector/J 6.0.4 requires at least MySQL 5.7.14 server when working via X DevAPI.

Thanks!

Enjoy this new Connector/J and thank you all for your support!

On behalf of the MySQL Connector/J Team.