Subject Re: [Firebird-Java] Rejecting connection without explicit character set in Jaybird 3: Keep it or remove it.
Author Ivan Arabadzhiev
The way I see it - "NONE" is a design flaw :) People (including yours truly) tend not to pay enough attention to warnings, some times because there's simply too much of them.
Switching to Jaybird 3+ would generally require intervention from the developer (if nothing else - to update the dependency), so hardcoding a suitable charset should not be too much to ask from people.
There is the middle ground of specifying some default, which would 1: make things less 'random'; 2: work for a reasonable amount of people. What I've done with https://github.com/korma/Korma was to set UTF8.

2017-01-06 12:06 GMT+02:00 Mark Rotteveel mark@... [Firebird-Java] <Firebird-Java@yahoogroups.com>:
 

In Jaybird 3 I made a change to reject connections without explicit
character set, see also http://bit.ly/2iLa5jl

The reason for that is that 1) the original default of NONE is usually
not the right option, and changing the default could break existing
applications in subtle ways, and 2) the way NONE works is slightly
different in Jaybird 3: we now take explicit character sets of columns
into account with NONE, so this could also break in subtle ways. The
choice was between a sternly worded warning in the release notes (which
probably will be ignored), or to be very explicit and annoying by
rejecting the connection in the hope that people pay attention.

However this change is still pretty aggressive, so I'd like to know your
opinions: should I keep it, or remove it (and fallback to the warning I
introduced in Jaybird 2.2).

I also had one report - which I have not been able to reproduce so far -
that using system property
org.firebirdsql.jdbc. defaultConnectionEncoding sometimes doesn't work. I
haven't been able to get more information as the reporter left a comment
on an existing ticket instead of creating a new one, and I get a
delivery error on the registration email address in the tracker.

Mark
--
Mark Rotteveel