Subject Re: [Firebird-Java] Re: Approaches at JB-to-FB conenctions regarding charsets
Author Roman Rokytskyy
>> > To me it looks quite opposite.
>> > http://www.trackstudio.ru/forum/download/file.php?id=212
>> > 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
support.

> 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.

Roman