Curious locale issue with bus names

[brett-smith]

A user has reported that our software is failing to start on Windows 11 running in a Turkish locale. We are using an embedded DBus daemon here, and use the following code to get a bus address.

var busAddress = TransportBuilder.createDynamicSession("unix", true);

This returns null on this Turkish installation, but will correctly return a valid address everywhere else.

It turns out that it's the _busType.toUpperCase() in createDynamicSession(). This actually results in UN¦X (the 'I' is actually U+00A6) and so the provider is never found.

"unix".toUpperCase().equals("UN¦X");
"UNIX".toUpperCase().equals("UNIX");
"unix".toUpperCase(Locale.ENGLISH).equals("UNIX");

In TransportBuilder, the providers are registered by upper casing the the already upper case names provided by the ITransportProvider implementations, so the upper casing here is effectively a noop,. and the providers are registered with the correct name.

So client code can work around this by making sure the already upper-cased "UNIX" is always passed when string bus names are used.

But it does seem that a better solution is needed inside dbus-java. I suppose using enum is probably out because of the pluggable nature of transport providers.

[hypfvieh]

mhh.. why do those issues always appear shortly after I created a release? Maybe I should as Murphy why this always happens...

I looked through the code and checked the usages of toUpperCase/toLowerCase and added a locale to those calls when I think the String is/should be in ASCII/US locale.
This is mainly the case for the busType comparison and for checking on which OS the library is used.

Using enum instead of a String was my first intention when I designed the transports. But as you already said, this will not work because a enum is not extendable and every new transport would require changes in dbus-java (and will add transports which are third party in the library).

Using integer here is always awkward, because it is confusing (what should transport 1 mean? Or transport 999? A nightmare when debugging).
Using some sort of Interface is also difficult because I need to compare which transport is used / which are available in the library.
In case of the unix transport I want to detect them as being 'the same' to avoid using both randomly, but when a interface is used how should I detect that?

[brett-smith]

Thanks for the fix, our application is now working in the Turkish locale. I've been doing some reading up on this particular problem, seems it is well known. I have never come across this in my entire career, I guess I've been lucky!

mhh.. why do those issues always appear shortly after I created a release? Maybe I should as Murphy why this always happens...

Hah, know this one!

In order to be able to get a fix to our customer, I have published 4.2.1-SNAPSHOT to our company Artifactory if anyone else is interested.

Using enum instead of a String was my first intention when I designed the transports. But as you already said, this will not work because a enum is not extendable and every new transport would require changes in dbus-java (and will add transports which are third party in the library).

Using integer here is always awkward, because it is confusing (what should transport 1 mean? Or transport 999? A nightmare when debugging). Using some sort of Interface is also difficult because I need to compare which transport is used / which are available in the library. In case of the unix transport I want to detect them as being 'the same' to avoid using both randomly, but when a interface is used how should I detect that?

Yeh, this is an interesting problem. I know you can kind of simulate extending enum using it with an interface (like java.nio.file.CopyOption), but you would still need to solve the problem of enumerating the extended values.

Feel free to close this if you'd rather deal with the improvements separately as the committed fix solves the original problem.