Support EOL for MySQL Connector/J 5.1

Per Oracle’s Lifetime Support policy, as of Feb 9th, 2021, MySQL Connector/J 5.1 series is covered under Oracle Sustaining Support. Downloadable binaries can be found in the MySQL Products Archives and in the Maven Central Repository.

MySQL Connector/J 5.1.49 has been the last release of Connector/J 5.1 series.

It is time to move on. Users are encouraged to upgrade to MySQL Connector/J 8.0 series which provides the same features as Connector/J 5.1 and a lot more, including a brand new date/time handling support, introduced in version 8.0.23, and the X DevAPI that empowers the MySQL Document Store.

We like to hear from you. Please join us in the MySQL Forums or in #connectors channel in:

X DevAPI Traffic Compression With Connector/J

X Protocol traffic compression is available on MySQL Server since version 8.0.19. A connector that also supports compression on its end can leverage this feature and reduce the byte streams that are exchanged with the Server.

By default, connections to a MySQL server are uncompressed, thus permitting exchanging data with a client or connector that doesn’t support compression. However, given a client or connector that also supports compression, it is recommended that client and server negotiate the connection compression by default. If this negotiation concludes successfully, both ends can then compress the data they send.

Compression at this level allows reducing the amount of bytes exchanged over the network, but at the cost of additional CPU resources required to run data inflate and deflate operations. The benefits of compression, therefore, occur primarily on low network bandwidth. One can assess the gain or loss due to the compression only after measuring properly the average traffic sizes for a period of time for both the compressed and uncompressed connections.

Connector/J version 8.0.20 came out with basic support for traffic compression over X Protocol connections. For this purpose, a new connection option: xdevapi.compression, was introduced. As of Connector/J 8.0.22, this feature was leveled up with the introduction of two additional connection options: xdevapi.compression-extensions and xdevapi.compression-algorithms.

Let it be clear that the new compression features in the X DevAPI has no impact whatsoever on the existing compression behavior or settings of Connector/J JDBC implementation.

Continue reading

MySQL Connector/J 8.0.15 has been released


Dear MySQL users,

MySQL Connector/J Version 8.0.15 is the GA release of the 8.0
branch 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

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.15 GA, see the “Generally Available
(GA) Releases” tab at


Changes in MySQL Connector/J 8.0.15 (2019-02-01, General Availability)

Functionality Added or Changed

* Default value of the connection property
allowLoadLocalInfile has been changed to false.
Applications that use the LOAD DATA LOCAL INFILE
statement on MySQL Server needs to set this property to
true explicitly. (Bug #29261254)

Enjoy and thanks for the support!

On Behalf of MySQL/ORACLE RE Team
Gipson Pulla

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

public class HelloWorld {
    public static void main(String[] args) throws Exception {
        // your code goes here.

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:

// add to imports:
import com.mysql.cj.xdevapi.Session;
import com.mysql.cj.xdevapi.SessionFactory;

// put inside the main() method:
SessionFactory sFact = new SessionFactory();
Session sess = sFact.getSession("mysqlx://johndoe:password@localhost:33060");

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:

// add to imports:
import com.mysql.cj.xdevapi.Schema;

// put inside the main() method:
Schema schema = sess.createSchema("demo", true);

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:

// add to imports:
import com.mysql.cj.xdevapi.Collection;

// put inside the main() method:
Collection col = schema.createCollection("greetings");
col.add("{\"language\":\"English\", \"greeting\":\"Hello World\"}")
        .add("{\"language\":\"Português\", \"greeting\":\"Olá Mundo\"}")
        .add("{\"language\":\"Français\", \"greeting\":\"Bonjour Monde\"}")

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

> desc demo.greetings;
| Field | Type          | Null | Key | Default | Extra            |
| doc   | json          | YES  |     | NULL    |                  |
| _id   | varbinary(32) | NO   | PRI | NULL    | STORED GENERATED |

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:

// add to imports:
import com.mysql.cj.api.xdevapi.DocResult;
import com.mysql.cj.xdevapi.DbDoc;

// put inside the main() method:
DocResult res = col.find("$.language='Português'").execute();
for (DbDoc doc : res.fetchAll()) {

res = col.find("greeting LIKE '%World%'").execute();
for (DbDoc doc : res.fetchAll()) {

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:

"_id" : "c8075d720b0cb5894eabec605229e304",
"greeting" : "Olá Mundo",
"language" : "Português"
"_id" : "a10ea22f459b8c974f10994d278c653d",
"greeting" : "Hello World",
"language" : "English"

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

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


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
( 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
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

+ The DatabaseObject.getSession() method now returns a
Session object (instead of the old Session
See MySQL Connector/J X DevAPI Reference
( for more

* 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
tor interface with the

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

+ Renamed the connection property
statementInterceptors to queryInterceptors. See
Configuration Properties
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

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

* 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”.


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:

// Connect to server on localhost
String url = "mysqlx://localhost:33060/test?user=mike&password=s3cr3t!"
XSession mySession = new MysqlxSessionFactory().getSession(url);

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:

     * Check if the underlying object is a view or not.
     * @return true if this Table is a View
    boolean isView();

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.


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

On behalf of the MySQL Connector/J Team.

MySQL Connector/J 5.1.39 has been released

I’m pleased to announce that MySQL Connector/J 5.1.39 Maintenance Release is now generally available.

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

As always, we recommend that you check 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.

With MySQL Connector/J 5.1.39 you get the continuously improved JDBC driver for MySQL databases, now including several fixes and upgrades. Even if you didn’t face any of the fixed issues, we do recommend that you upgrade to the latest version.

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

MySQL Fabric support related issues

As you well know by now, MySQL Fabric support in Connector/J is built on its generic multi-host connections feature, more specifically on replication connections. This feature, along with load-balanced connections support, have received several improvements all over the latest releases. This time, we fixed and tuned up a few incoherences that were spotted on a few corner cases, namely when, due to the Fabric management process, the list of known hosts in an active connection could actually become empty for a short period of time while performing the fail-over, and so causing a whole set of new problems. As a consequence of these developments, we introduced a new connection property:

loadBalanceHostRemovalGracePeriod. This property sets the time, in milliseconds, that the driver should wait for a load-balanced connection to be allowed to switch to a different host when the currently active one is being removed, either by an internal process such as in a Fabric or a replication connection, or by dynamic hosts management, through the JMX interfaces the driver provides. Default value is 15000 milliseconds.


Additional improvements and fixes

  • Unnecessary exception throwing and capturing when establishing connections.
  • Temporal data corruption in prepared statements under special circumstances.
  • Incorrect JDBC 4.2 Java 8 Time support when using cached prepared statements.
  • Application server using multiple class loaders could face a NullPointerException when setting up the driver’s time zone configurations.
  • Exception caused by missing metadata information in updatable result sets.
  • Concurrent modification issue on closing statements and connections concurrently from different threads.
  • Maintenance fixes in the test suite.
  • Source code formatting, Copyright notice fixes.
  • Build script adjustments, new code coverage reports, compiler warnings cleanup.
  • Manifest fixed to expose Fabric connections.
  • Support for latest changes in MySQL protocol, introduced in MySQL 5.7, namely the deprecation of EOF packets.


Enjoy this new release of Connector/J and stay tuned for the next releases as there is still much to deliver.

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

Thank you all for your support and keep in touch!

On behalf of the MySQL Connector/J Team

Announcing MySQL Connector/J 6.0

We are pleased to announce the first release of MySQL Connector/J 6.0! This is a new branch of development, which breaks from some of the traditions of the very stable and very mature Connector/J 5.1 branch. We have combed through lots of code and refactored it in order to support development of future features including our X DevAPI implementation and support for X Protocol. This work manifests in a number of visible changes, including revising the growing set of connection and build properties.

Beginning with Connector/J 6.0, we are moving away from having one jar that supports all versions of Java. Instead we are building one jar/package for every supported version of Java. This simplifies the build process as well as lots of code that was required to support many versions of Java. The current package is built for Java 8.

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

All changes are documented in the MySQL Connector/J 6.0 Developer Guide.

Updates to connection properties, including removal of several options that are no longer needed with the latest versions of MySQL and Java. Additionally, we removed some legacy behavioral options. You can see the changes in the documentation:
Connector/J 6.0 Changes in Connection Properties

If you are building from source or running the test suite, check the following:
Connector/J 6.0 Changes for Build Properties
Connector/J 6.0 Changes for Test Properties

Finally, API changes and package reorganizations are documented at:
Changes in the Connector/J API

Release notes are available at Changes in MySQL Connector/J 6.0.2 (2016-04-11, Milestone 1).

MySQL Connector/J 5.1.38 has been released

I’m pleased to announce that MySQL Connector/J 5.1.38 Maintenance Release is now generally available.

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

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.

MySQL Connector/J 5.1.38, although released shortly after its predecessor, includes several important fixes and improvements. Most of them related to MySQL Fabric, multi-host replication aware connections support and support for TLSv1.2 and new encryption defaults. Even if you don’t require such features, we do recommend the upgrade to the latest version.

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

MySQL Fabric and Multi-Host Replication Connections Revision

MySQL Fabric support in Connector/J is based on multi-host replication aware connections and the ability to dynamically manage server groups. Most of the server groups management is done automatically and, possibly, concurrently. The combination of all these features was never thoroughly used and stressed as much as now and the consequence is that they were effectively in need of some improvements.

This release ships with a fully re-factored multi-host replication aware connections support, which now inherits from the same base architecture as the remaining multi-host connections alternatives, the fail-over connections and load-balanced connections. This architecture provides a layered connection support structure and an improved statement execution routing model that effectively determines the correct physical connection to use at execution time, also fixing, by this way, a couple of existing bugs. The synchronization model in the server groups management was revised as well in order to overcome a few known thread deadlock situations. As a direct result the fail-over in MySQL Fabric support is now way more robust.

In the process of the improvements made in multi-host replication aware connections, two new connection properties were added:

allowSlaveDownConnections. This property sets the behavior for establishing replication aware connections when no slave hosts available. While, previously, this would result in a failed connection attempt, now we can define the behavior we prefer. This property takes a boolean value:


readFromMasterWhenNoSlaves. This property sets the behavior for the situations where, at run-time, all slave hosts in a replication aware connection become unavailable. The alternatives “should it fail?”, the only possible outcome before introducing this property, or “should the master host(s) be used in their place?”, are now available to the developer. Mind that when you set the option to use the master host(s), they will be used in read-only state as if they were slave hosts. Also mind that setting this property to true might, transparently, incur in extra load to the master host(s). This property takes a boolean value:


Security Compliance and Improvements

In its way of complying with the up-to-date security regulations and requirements, MySQL server 5.7 is now shipped with SSL/TLS enabled by default and any clients connecting to it should make use of such data protection features by default as well. Following this path, Connector/J 5.1.38 prioritizes the usage of SSL/TLS when establishing connections to this server. The missing support for TLSv1.2 and TLSv1.1 was additionally included in this release.

Connector/J now attempts to use the highest security layer available at run-time, starting from TLSv1.2 and, at the end, providing the best encryption system possible for the moment. This obviously depends on the MySQL server version we are connecting to and on the JVM version in use. In some situations it may be somewhat complex to find a compatible set of cyphers that can be used in both ends and some tweaks or adjustments could be required. The connection property enabledSSLCipherSuites may be a good companion in such cases.

Additional Bug Fixes

This release also includes a few other minor bug fixes. Although not especially relevant, these fixes help improving the overall quality of this Connector/J release.


Thank you all for your support. Enjoy this new Connector/J and keep in touch!

On behalf of the MySQL Connector/J Team.