MySQL Bugs: #59456: com.mysql.jdbc.PreparedStatement.setObject(int,Object) doesn't handle Character

Bug #59456	com.mysql.jdbc.PreparedStatement.setObject(int,Object) doesn't handle Character
Submitted:	12 Jan 2011 18:29	Modified:	20 Jan 2011 7:00
Reporter:	Yura Nakonechnyy	Email Updates:
Status:	Verified	Impact on me:	None
Category:	Connector / J	Severity:	S4 (Feature request)
Version:		OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	jdbc, PreparedStatement, setObject

Description:
After setting PreparedStatement's parameter to char value using setObject(int, Object) method, query execution fails with strange message like:
java.sql.SQLException: Incorrect string value: '\xAC\xED\x00\x05sr...' for column 'column_with_type_char'.

After short investigation of com.mysql.jdbc.PreparedStatement.setObject(int,Object) method it turned out that it is checking all possible types of passed object, except for the Character type. So the Character objects (or primitive char) falls through all the checks being not recognized and are serialized (as Character implements Serializable) to binary String representing Character instance innards.

How to repeat:
Actually, everything is understood from description I guess and simple code inspection from Your side would be enough, but in order to conform to bug reporting requirements:

Create MySQL table using:
CREATE TABLE chars (
   c VARCHAR(1)
);

Then try to run following Java code snippet:
final PreparedStatement statement = readyConnection.prepareStatement("INSERT INTO chars (c) VALUES (?)");
statement.setObject(1, 'c'); // 'c' is being serialized into long binary string
statement.execute();

This will lead to above mentioned exception

Added jdbc tag

Technically not a bug, there is no JDBC specification-defined mapping for java.lang.Character (or char[]). The driver is doing the right thing as far as the JDBC spec is concerned, i.e. if there's no mapping defined, it's a java.lang.Object.

We'll have to consider whether we want to do something custom here or not.

In this case still cannot understand why according to JDBC specialization char should be serialized as object in PreparedStatement.setObject(int,Object) and other primitive types (int, double, float) are treated like their counterparts in SQL. As for me, this looks like char was ommitted by mistake in JDBC specialization and this mistake can be easily fixed in Connector/J.

Anyway, thank You for the quick feedback on this!

In previous comment, instead of "specialization" should be "specification", sorry.

Based on Mar's comment I'd say we have a valid feature request here.

What is the status of this bug? Is it possible it's five years unfixed?

It's a feature request, we implement it as time allows.