Version 8.0.17 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, and 5.6. It supports the Java Database Connectivity (JDBC) 4.2 API, and implements the X DevAPI.
X DevAPI: The following methods have been deprecated:
X DevAPI: Two new operators for JSON objects and arrays,
NOT OVERLAPS, are now supported.
LICENSEfiles are now included inside the Connector/J JAR archive delivered in the platform-independent tarballs and zip files. (Bug #29591275)
A number of private parameters of
hostname) had no getters for accessing them from outside of the class instance. Getter methods have now been added for all the parameters of the class. (Bug #20010454, Bug #74690)
A new connection property,
databaseTerm, sets which of the two terms is used in an application to refer to a database. The property takes one of the two values
SCHEMAand uses it to determine which
Connectionmethods can be used to set/get the current database, which arguments can be used within the various
DatabaseMetaDatamethods to filter results, and which fields in the
DatabaseMetaDatamethods contain the database identification information. See the entry for
databaseTermin Configuration Properties for details.
Also, the connection property
nullCatalogMeansCurrenthas been renamed to
nullDatabaseMeansCurrent. The old name remains an alias for the connection property.
Thanks to Harald Aamot for contributing to the patch. (Bug #11891000, Bug #27356869, Bug #89133)
CONTRIBUTINGfile has been added to the Connector/J repository on GitHub, which provides guidelines for code contribution and bug reporting.
The MySQL Connector/J X DevAPI Reference can now be generated from the Connector/J source code as an Ant target,
Added support for host names that are longer than 60 characters (up to 255 characters), as they are now supported by MySQL Server 8.0.17.
Added support for the
utf8mb4_0900_bincollation, which is now supported by MySQL Server 8.0.17.
A cached server-side prepared statement can no longer be effectively closed by calling
Statement.close()twice. To close and de-cache the statement, do one of the following:
Close the connection (assuming the connection is tracking all open resources).
Use the implementation-specific method
Set the statement as non-poolable by calling the method
Statement.setPoolable(false)before or after closing it.
X DevAPI: The
INoperator in X DevAPI expressions, when followed by a square bracket (
[), got mapped onto the wrong operation in X Protocol. (Bug #29821029)
When using a replication connection, retrieving data from
BlobFromLocatorresulted in a
ClassCastException. It was due to some wrong and unnecessary casting, which has been removed by this fix. (Bug #29807741, Bug #95210)
ResultSetMetaData.getTableName()returned null when no applicable results could be returned for a column. However, the JDBC documentation specified an empty string to be returned in that case. This fix makes the method behave as documented. The same correction has been made for
getSchemaName(). (Bug #29452669, Bug #94585)
ResultSetImpl.getObject(), when autoboxing a value of a primitive type retrieved from a column, returned a non-null object when the retrieved value was null. (Bug #29446100, Bug #94533)
ResultSetImpl.getDouble()was very inefficient because it called
FloatingPointBoundsEnforcer.createFromBigDecimal, which needlessly recreated
BigDecimalobjects for the fixed minimum and maximum bounds. With this fix, the objects
BigDecimal.valueOf(max)are cached after they are first created, thus avoiding their recreations. (Bug #29446059, Bug #94442)
logSlowQueriesresulted in many unnecessary calls of
LogUtils.findCallingClassAndMethod(). With this fix,
LogUtils.findCallingClassAndMethod()is called only when
profileSQLis true and even in that case, the number of calls are reduced to a minimal to avoid the excessive stack trace data the function used to generate. Thanks to Florian Agsteiner for contributing to the fix. (Bug #29277648, Bug #94101, Bug #17640628, Bug #70677)
Characters returned in a
ResultSetwere garbled when a server-side
PreparedStatementwas used, and the query involved concatenation of a number and a string with multi-byte characters. That was due to an issue with the number-to-string conversion involved, which has been corrected by this fix. (Bug #27453692)
ProfilerEvent.pack()resulted in an
ArrayIndexOutOfBoundsException. It was due to a mishandling of data types, which has been corrected by this fix. (Bug #11750577, Bug #41172)