As suggested in JDK-8364103, code that builds up strings manually, using a chaining of snprintf-like calls and manually counting the character offsets should be transformed to use stringStream instead. And the reason to do so is that the snprintf-chains are difficult to read and maintain, and are error-prone.

JDK-8364103 addressed the remaining uses of that kind that were using os::snprintf. But there are many more that are using jio_snprintf. Those should be similarly fixed.

The only thing jio_snprintf does differently from os::snprintf and os::snprintf_checked is treat a buffer size > INT_MAX as an error, returning -1 in that case. And NOT ensuring the buffer is null terminated! The idea is that such a value is really an underflow, probably from not properly handling an jio_snprintf-chain. But as suggested here, those shouldn't exist. Also, stringStream has its own internal notion of what a "reasonable" maximum string size might be. So we shouldn't be losing anything by moving away from jio_snprintf.

As there are a fair number of jio_snprintf chains, scattered across HotSpot, it may be desirable to break the work down into multiple changes.