SQLLine uses default encoding which is hard to predict when the library is embedded

[vlsi]

sqlline/src/main/java/sqlline/SqlLine.java

Lines 58 to 59 in 2633cd9

	private PrintStream outputStream = new PrintStream(System.out, true);
	private PrintStream errorStream = new PrintStream(System.err, true);

sqlline/src/main/java/sqlline/SqlLine.java

Line 1753 in 2633cd9

this.outputStream = new PrintStream(outputStream, true);

sqlline/src/main/java/sqlline/SqlLine.java

Line 1761 in 2633cd9

this.errorStream = new PrintStream(errorStream, true);

[julianhyde]

fobiddenapis could probably catch this. (We use it in Calcite to remind us to call String.toUpper(Locale.ROOT) rather than String.toUpper().)

[snuyanzin]

There is an option to use something like java.nio.charset.StandardCharsets for instance

private PrintStream outputStream = new PrintStream(System.out, true, StandardCharsets.UTF_8);

I think it may also make sense to add variable default-character-set like the existing in MySQL [1] or PostgreSQL[2].
The issue is that java.nio.charset.StandardCharsets is accessible since jdk 1.7 so what about moving to 1.8 with upgrading to jline3 first?
[1] https://dev.mysql.com/doc/refman/5.7/en/mysql-command-options.html#option_mysql_default-character-set
[2] https://www.postgresql.org/docs/9.3/static/runtime-config-client.html#GUC-CLIENT-ENCODING

[julianhyde]

StandardCharsets makes sense. We did the same in https://issues.apache.org/jira/browse/CALCITE-1667.

Yes, let's do JDK 8 and jline3 first. As soon as I get a moment I will review/merge that change, then we can revisit this issue.

[snuyanzin]

As I understand committed at f4bfb5c with adding forbiddenapis and fixing all the errors based on its report

[snuyanzin]

cc @julianhyde
If I am not mistaken it could closed as fixed

[julianhyde]

Fixed in f4bfb5c. Thanks for reminding me, @snuyanzin!