Version 8.3.0 is a new GA release of MySQL Connector/J. MySQL Connector/J 8.3.0 supersedes 8.2 and is recommended for use on production systems. This release can be used against MySQL Server version 8.0 and later. It supports the Java Database Connectivity (JDBC) 4.2 API, and implements the X DevAPI.
The version requirements for the third-party libraries and tools needed for running and building Connector/J have been updated. See Connector/J Installation and Installing from Source for details. (WL #16077, WL #16074)
The list of cipher suites usable by Connector/J has been updated. See
src/main/resources/com/mysql/cj/TlsSettings.properties
in the source for the updated list. (Bug #35488208)
X DevAPI: When using X DevAPI native connection pooling, it could take too long to open a new session if sessions were closed in a very fast pace. The connection pool concurrency synchronization in the X DevAPI Client class has been reimplemented to avoid unnecessary race conditions, so to increase performance significantly and prevent the observed latency for opening new connections. (Bug #35929119)
When a
CallableStatement
was used to call a stored procedure or function that did not exist on the server or that the client had no rights to access its parameters' metadata, Connector/J tried to infer the parameter metadata from the SQL call string itself, but did so wrongly. It was because Connector/J did not distinguish between a stored procedure and a stored function in its inference, and this fix makes Connector/J do so now. (Bug #29907618)-
prepareCall()
failed to handle properly comments inside aCALL
statement. With this fix, Connector/J now recognizes the following three types of comments:Text preceded by "-- " (note there has to be a space after the hyphens)
Text preceded by "#"
Text between "/*" and "*/"
(Bug #19845752)
When a procedure and a function with the same name existed in a database, Connector/J retrieved parameter information from both at the same time by default, causing various errors at statement executions. This fix leverages the JDBC 4
DatabaseMetaData
methods to return parameter information only from the procedure or function of interest, so that statements are executed without errors. (Bug #19531305, Bug #73774)Setting a very large value for query timeout caused an
IllegalArgumentException
when a query was executed. It was due to an integer overflow, which is now avoided by changing the timeout value's data type from Integer to Long. (Bug #112884, Bug #36043166)Statement.getWarnings()
did not clear the warning chain automatically each time a statement was executed, as it was expected to do. (Bug #112195, Bug #35749998)ParameterMetaData.getParameterCount()
did not report the correct number for a procedure called through aPreparedStatement
when not all the procedure parameters were specified in the query statement. (Bug #111107, Bug #36023972)Calling
PreparedStatement.executeUpdate()
on a query that was only a comment caused aSQLException
to be thrown, with the complaint thatexecuteUpdate()
"cannot issue statements that produce result sets." It was because the check on whether the query would produce results sets was faulty, and it has now been fixed. (Bug #109546, Bug #34958912)When the connection properties
useServerPrepStmts
andcachePrepStmts
were both set to true, thePreparedStatement
was reset every time after an execution, causing performance issues. With this fix, unnecessary resets are avoided. Thanks to Marcos Albe for contributing to this fix. (Bug #107107, Bug #34101635)MysqlParameterMetadata.isNullable()
ignored the value of the connection propertygenerateSimpleParameterMetadata
when returning a value. With this fix, the method returnsParameterMetaData.parameterNullableUnknown
whengenerateSimpleParameterMetadata
is true. (Bug #96582, Bug #30222032)