Subject Re: [Firebird-Java] Re: Approaches at JB-to-FB conenctions regarding charsets
Author Roman Rokytskyy
>> > To me it looks quite opposite.
>> >
>> > Users would instantly detect and "cry early"
>> Aha, and what about the applications that compute in background?
> And you start them without user interactions at all ?

Any web application producing a garbage like the screen you published
would simply cause user to close the web browser, not to call the

> And u change database/jaybird without shutting them down ?

Firebird allows to change that on the fly. But I do not create
databases with NONE character set, so no need to worry about.

>> > In a way that users would see garbage, cease operations and
>> request
>> > admin to fix it.
>> Not an option, since things might get screwed before somebody
>> notices.
> In some very specific circumstances.
> And for the rest NONEers things might get screwed at any time due to
> environment change.
> One time chance to screw rather non-typical installments vs continuos
> chances to screw typical ones.
> That is "breaking changes in JB 2.2.0" not mere "release notes for
> 2.1.7"

I am not ready to introduce such change in 2.2.0.

>> No double conversion - neither piece of code will apply any
>> conversion
>> if NONE is used (explicitly or implicitly). The conversion to
>> string
>> with platform's default encoding will happen far above the code that
>> performs network calls.
> So you rely on FBClient VERY UNLIKELY would transcode on it's own.

FBClient won't do this anyway - I know how it works. It will pass the
DPB in unchanged way to server and will pass byte array with string
contents to Jaybird. The lower-level part of Jaybird will process bytes
arrays and pass them to the upper levels. The upper level will construct
a string applying the environment's default encoding if NONE is used.

>> That is the requirement of Java, you have to
>> live with it.
> You can workaround it.

That's what we do - we use environment's default encoding.

> You can explicitly fail.

Yes, that is possible. Not for 2.2.0, since that is too late.

> Or You can implicitly apply some heuristics.

No heuristics - only simple rules.

> You rely on FBClient not trying to Query GetThreadLocale and start
> transcoding to ANSI or OEM.
> I rely upon Jaybird doing the same until explicitly .

I guess all your confusion is caused because you're new to Java. When
you get some experience in Java, especially in web area, you will be
very carefull about string-to-byte conversion and back and will pay
attention to it.

>> Below that level only bytes are shifted over the wire.
> I was talking not about wire protocol, but about Jaybird working via
> FBClient.dll

Yes. FBClient.dll shifts only bytes - it does not interpret them. The
buffer received from the server is passed without the modification to
the layer above. In our case that is Jaybird, which also has it's
low-level part that performs no conversions and does not use strings and
the JDBC API part where we have to convert the data accordingly. The
rules are straightforward - if no charset is specified, we have to use
the default one. That is the Java convention. That might be different
from your expectations, but it is how Java world looks like.