Barcode scanning into Swing textfield sometimes swaps characters

Question

We see an extremly weird behaviour with barcode scanners and a Java Swing application on Windows 7 and jre8. This is a large deployment of more than 1000 PCs and several different barcode models. We scan barcodes that represent strings with 9 characters: H06AVKTI2

Now "sometimes on some installations" some of the later characters appear in the wrong order: H06AVKTI2 H06AVKI2T H06AVKTI2

• When we scan into notepad or an outlook email, we never see the problem, only in our Swing app.
• it only happens with the 3-4 last characters of the string, the first 4-5 are always correct.
• It happens with most/all barcode scanner models and PCs, but on some installations never, on others often - no pattern so far...
• It is nowhere 100% reproducible - just on some PCs it happens often (more than 50% of scans are wrong)
• When we started two instances of our application on the same PC we saw it happen in one instance very often but never in the other.
• It does not seem to relate to the specific scanner model, barcode, user or installation
• there is no network traffic when we type into this field, hit enter or any other key when this field is focused - we checked with Wireshark.

Any idea is welcome - we are desperate ;-)

Answer 1

We eventually solved this. Turns out that this Java Swing application allows to configure keyboard shortcuts that are available to execute certain business tasks under certain conditions. Somebody had globally configured shift-t and some other shift-_ to be shortcuts for business transactions.

Now even though these business transactions were not available in the context when we scan barcodes, the app seems to interupt for a few milliseconds whenever it receives a shift-t. When the barcode-scanner scans a code containing a "T", it sends one of these shift-t combinations and the software takes a very short time just to determine, that there is nothing to do for this shortcut. In these cases the scanned characters end up being swapped. So this obviously only happend when we scanned a code containing one of the characters we had configured shortcuts for...

Solution was to change the configured shortcuts to ctrl-t instead of shift-t.

Root cause is probably the way the framework developers of the app implemented those global shortcuts, but this has not been verified.