The reported milliseconds since the last server packets were received/sent was incorrect by a factor of 1000. For example, the following method call:

SQLError.createLinkFailureMessageBasedOnHeuristics(
(ConnectionImpl) this.conn, 
System.currentTimeMillis() - 1000,
System.currentTimeMillis() - 2000,
e, 
false);

returned the following string:

The last packet successfully received from the server 
was 2 milliseconds ago. The last packet sent successfully to the 
server was 1 milliseconds ago.

(Bug#45419)

Calling Connection.serverPrepareStatement() variants that do not take result set type or concurrency arguments returned statements that produced result sets with incorrect defaults, namely TYPE_SCROLL_SENSITIVE. (Bug#45171)

The result set returned by getIndexInfo() did not have the format defined in the JDBC API specifications. The fourth column, DATA_TYPE, of the result set should be of type BOOLEAN. Connector/J however returns CHAR. (Bug#44869)

The result set returned by getTypeInfo() did not have the format defined in the JDBC API specifications. The second column, DATA_TYPE, of the result set should be of type INTEGER. Connector/J however returns SMALLINT. (Bug#44868)

The DEFERRABILITY column in database metadata result sets was expected to be of type SHORT. However, Connector/J returned it as INTEGER.

This affected the following methods: getImportedKeys(), getExportedKeys(), getCrossReference(). (Bug#44867)

The result set returned by getColumns() did not have the format defined in the JDBC API specifications. The fifth column, DATA_TYPE, of the result set should be of type INTEGER. Connector/J however returns SMALLINT. (Bug#44865)

The result set returned by getVersionColumns() did not have the format defined in the JDBC API specifications. The third column, DATA_TYPE, of the result set should be of type INTEGER. Connector/J however returns SMALLINT. (Bug#44863)

The result set returned by getBestRowIdentifier() did not have the format defined in the JDBC API specifications. The third column, DATA_TYPE, of the result set should be of type INTEGER. Connector/J however returns SMALLINT. (Bug#44862)

Connector/J contains logic to generate a message text specifically for streaming result sets when there are CommunicationsException exceptions generated. However, this code was never reached.

In the CommunicationsException code:

private boolean streamingResultSetInPlay = false;

public CommunicationsException(ConnectionImpl conn, long lastPacketSentTimeMs,
long lastPacketReceivedTimeMs, Exception underlyingException) {

this.exceptionMessage = SQLError.createLinkFailureMessageBasedOnHeuristics(conn,
      lastPacketSentTimeMs, lastPacketReceivedTimeMs, underlyingException,
      this.streamingResultSetInPlay);

streamingResultSetInPlay was always false, which in the following code in SQLError.createLinkFailureMessageBasedOnHeuristics() never being executed:

if (streamingResultSetInPlay) {
    exceptionMessageBuf.append(
    Messages.getString("CommunicationsException.ClientWasStreaming")); //$NON-NLS-1$
} else {
...

(Bug#44588)

The SQLError.createLinkFailureMessageBasedOnHeuristics() method created a message text for communication link failures. When certain conditions were met, this message included both “last packet sent” and “last packet received” information, but when those conditions were not met, only “last packet sent” information was provided.

Information about when the last packet was successfully received should be provided in all cases. (Bug#44587)

Statement.getGeneratedKeys() retained result set instances until the statement was closed. This caused memory leaks for long-lived statements, or statements used in tight loops. (Bug#44056)

Using useInformationSchema with DatabaseMetaData.getExportedKeys() generated the following exception:

com.mysql.jdbc.exceptions.MySQLIntegrityConstraintViolationException: Column
'REFERENCED_TABLE_NAME' in where clause is ambiguous
...
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1772)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1923)
at
com.mysql.jdbc.DatabaseMetaDataUsingInfoSchema.executeMetadataQuery(
DatabaseMetaDataUsingInfoSchema.java:50)
at
com.mysql.jdbc.DatabaseMetaDataUsingInfoSchema.getExportedKeys(
DatabaseMetaDataUsingInfoSchema.java:603)

(Bug#43714)

LoadBalancingConnectionProxy.doPing() did not have blacklist awareness.

LoadBalancingConnectionProxy implemented doPing() to ping all underlying connections, but it threw any exceptions it encountered during this process.

With the global blacklist enabled, it catches these exceptions, adds the host to the global blacklist, and only throws an exception if all hosts are down. (Bug#43421)

The method Statement.getGeneratedKeys() did not return values for UNSIGNED BIGINTS with values greater than Long.MAX_VALUE.

Unfortunately, because the server does not tell clients what TYPE the auto increment value is, the driver cannot consistently return BigIntegers for the result set returned from getGeneratedKeys(), it will only return them if the value is greater than Long.MAX_VALUE. If your application needs this consistency, it will need to check the class of the return value from .getObject() on the ResultSet returned by Statement.getGeneratedKeys() and if it is not a BigInteger, create one based on the java.lang.Long that is returned. (Bug#43196)

When the MySQL Server was upgraded from 4.0 to 5.0, the Connector/J application then failed to connect to the server. This was because authentication failed when the application ran from EBCDIC platforms such as z/OS. (Bug#43071)

When connecting with traceProtocol=true, no trace data was generated for the server greeting or login request. (Bug#43070)

Connector/J generated an unhandled StringIndexOutOfBoundsException:

java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1938)
at com.mysql.jdbc.EscapeProcessor.processTimeToken(EscapeProcessor.java:353)
at com.mysql.jdbc.EscapeProcessor.escapeSQL(EscapeProcessor.java:257)
at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1546)
at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1524)

(Bug#42253)

A ConcurrentModificationException was generated in LoadBalancingConnectionProxy:

java.util.ConcurrentModificationException
 at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
 at java.util.HashMap$KeyIterator.next(Unknown Source)
 at
com.mysql.jdbc.LoadBalancingConnectionProxy.getGlobalBlacklist(LoadBalancingConnectionProxy.java:520)
 at com.mysql.jdbc.RandomBalanceStrategy.pickConnection(RandomBalanceStrategy.java:55)
 at
com.mysql.jdbc.LoadBalancingConnectionProxy.pickNewConnection(LoadBalancingConnectionProxy.java:414)
 at
com.mysql.jdbc.LoadBalancingConnectionProxy.invoke(LoadBalancingConnectionProxy.java:390)

(Bug#42055)

SQL injection was possible when using a string containing U+00A5 in a client-side prepared statement, and the character set being used was SJIS/Windows-31J. (Bug#41730)

If there was an apostrophe in a comment in a statement that was being sent through Connector/J, the apostrophe was still recognized as a quote and put the state machine in EscapeTokenizer into the inQuotes state. This led to further parse errors.

For example, consider the following statement:

String sql = "-- Customer's zip code will be fixed\n" +
  "update address set zip_code = 99999\n" +
  "where not regexp '^[0-9]{5}([[.-.]])?([0-9]{4})?$'";

When passed through Connector/J, the EscapeTokenizer did not recognize that the first apostrophe was in a comment and thus set inQuotes to true. When that happened, the quote count was incorrect and thus the regular expression did not appear to be in quotes. With the parser not detecting that the regular expression was in quotes, the curly braces were recognized as escape sequences and were removed from the regular expression, breaking it. The server thus received SQL such as:

-- Customer's zip code will be fixed
update address set zip_code = '99999'
where not regexp '^[0-9]([[.-.]])?([0-9])?$'

(Bug#41566)

MySQL Connector/J 5.1.7 was slower than previous versions when the rewriteBatchedStatements option was set to true.

(Bug#41532)

When accessing a result set column by name using ResultSetImpl.findColumn() an exception was generated:

java.lang.NullPointerException
at com.mysql.jdbc.ResultSetImpl.findColumn(ResultSetImpl.java:1103)
at com.mysql.jdbc.ResultSetImpl.getShort(ResultSetImpl.java:5415)
at org.apache.commons.dbcp.DelegatingResultSet.getShort(DelegatingResultSet.java:219)
at com.zimbra.cs.db.DbVolume.constructVolume(DbVolume.java:297)
at com.zimbra.cs.db.DbVolume.get(DbVolume.java:197)
at com.zimbra.cs.db.DbVolume.create(DbVolume.java:95)
at com.zimbra.cs.store.Volume.create(Volume.java:227)
at com.zimbra.cs.store.Volume.create(Volume.java:189)
at com.zimbra.cs.service.admin.CreateVolume.handle(CreateVolume.java:48)
at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEngine.java:428)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:285)

(Bug#41484)

The RETURN_GENERATED_KEYS flag was being ignored. For example, in the following code the RETURN_GENERATED_KEYS flag was ignored:

PreparedStatement ps = connection.prepareStatement("INSERT INTO table
  values(?,?)",PreparedStatement.RETURN_GENERATED_KEYS);

(Bug#41448)

When using Connector/J 5.1.7 to connect to MySQL Server 4.1.18 the following error message was generated:

Thu Dec 11 17:38:21 PST 2008 WARN: Invalid value {1} for server variable named {0},
falling back to sane default of {2}

This occurred with MySQL Server version that did not support auto_increment_increment. The error message should not have been generated. (Bug#41416)

When DatabaseMetaData.getProcedureColumns() was called, the value for LENGTH was always returned as 65535, regardless of the column type (fixed or variable) or the actual length of the column.

However, if you obtained the PRECISION value, this was correct for both fixed and variable length columns. (Bug#41269)

PreparedStatement.addBatch() did not check for all parameters being set, which led to inconsistent behavior in executeBatch(), especially when rewriting batched statements into multi-value INSERTs. (Bug#41161)

Error message strings contained variable values that were not expanded. For example:

Mon Nov 17 11:43:18 JST 2008 WARN: Invalid value {1} for server variable named {0},
falling back to sane default of {2}

(Bug#40772)

When using rewriteBatchedStatements=true with:

INSERT INTO table_name_values (...) VALUES (...)

Query rewriting failed because “values” at the end of the table name was mistaken for the reserved keyword. The error generated was as follows:

testBug40439(testsuite.simple.TestBug40439)java.sql.BatchUpdateException: You have an
error in your SQL syntax; check the manual that corresponds to your MySQL server version
for the right syntax to use near 'values (2,'toto',2),(id,data, ordr) values
(3,'toto',3),(id,data, ordr) values (' at line 1
at com.mysql.jdbc.PreparedStatement.executeBatchedInserts(PreparedStatement.java:1495)
at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:1097)
at testsuite.simple.TestBug40439.testBug40439(TestBug40439.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at testsuite.simple.TestBug40439.main(TestBug40439.java:57)

(Bug#40439)

A statement interceptor received the incorrect parameters when used with a batched statement. (Bug#39426)

Using Connector/J 5.1.6 the method ResultSet.getObject returned a BYTE[] for following:

SELECT TRIM(rowid) FROM tbl

Where rowid had a type of INT(11) PRIMARY KEY AUTO_INCREMENT.

The expected return type was one of CHAR, VARCHAR, CLOB, however, a BYTE[] was returned.

Further, adding functionsNeverReturnBlobs=true to the connection string did not have any effect on the return type. (Bug#38387)