Hmm,
the following code

DriverManager.getConnection("jdbc:mysql://localhost:3306?user=root&sessionVariables=characterEncoding=utf8");

yelds an exception for me"Uknown system variable characterEncoding"
Indeed, a session variable with such name does not exist

Am I doing something wrong?

You need this in the connection string:

sessionVariables=character_set_server=utf8

I do not know what variable you have used before, but "character_set_server" is the one that affects create table. And yes, it can be used as session scope variable.

closing as not a bug, as clarified in the previous comment

The characterEncoding session variables stems from the use of Connector/J, and it works at least with Connector/J 5.1.17 and earlier versions og CJ, so depending on how much you want to be a drop-in replacement for Connector/J, you might consider this a bug.

Anyway, I still have the problem of tables being created with the wrong character set after changing characterEncoding to character_set_server in the connection URL, but if it works for you, it's probably something in my setup that fools me. (I have hibernate, spring etc in the mix, so i might have to come up with a simpler test-case).

It works for me, actually should for you

I wrote a small test case (pure JDBC of course) using cp1251 as character_set_server encoding, with create table with and reading "show create table" to verify the result.

Re drop-in replacement, it would be too impractical and impossible to emulate everything. While try to avoid / reduce big incompatibilities ,this one I think does not qualify (thought I might be mistaken)

I spend far too much time on various forums chasing charset issues. Wherever possible, everything should make it straightforward and easy to get to the ultimate goal, utf8mb4 (aka UTF-8 outside MySQL/MariaDB). There are current 4 or 5 places that a developer/DBA must check on to establish the desired charset. Having this incompatibility in the Connector adds yet another. Yuck!

I got here from http://stackoverflow.com/questions/41567258/mysql-server-with-mariadb-driver-produces-dates-collation-error . Without knowing this obscure incompatibility, I was unable to figure out how to solve the user's problem.

rjasdf, there is nothing more straightforward than using UTF8 with this connector. It fact it does not use anything else but UTF8 to communicate with the server. granted, UTF8mb4 is only used if it is server's default charset (this is compatible to C/J) , otherwise this client announces its encoding as UTF8mb3 (it used to talk to older versions that did not have mb4, therefore the behaviour is like this), but you still can use sessionVariables URL parameter to force utf8mb4.