Bug ID: JDK-8364103 Convert existing sprintf-chains to stringStream

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 26
26 b15Fixed

The remaining code sections that still build up strings manually using a chain of snprintf-like calls and manually counting the character offsets should be transformed to use stringStream instead.

For one, that code is difficult to read and maintain. 
It is also error-prone: a common error would be to keep calling snprintf with the updated offset but the initial buffer length, which renders the snprintf truncation test void and risks overwriters.

Example (correct but cumbersome):

https://github.com/openjdk/jdk/blob/52155dbbb0107c5077a6be7edfd91d4311411fc3/src/hotspot/share/classfile/javaClasses.cpp#L2607-L2642

Note: in order to notice truncations with stringStream, we must also add a method to recognize truncation. As in `stringStream::did_truncate()`.

Changeset: cfb80934 Branch: master Author: Paul Hübner <phubner@openjdk.org> Committer: David Holmes <dholmes@openjdk.org> Date: 2025-09-09 09:01:46 +0000 URL: https://git.openjdk.org/jdk/commit/cfb809344c0205875b35991ce6807333df41c949
09-09-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26894 Date: 2025-08-22 08:49:56 +0000
22-08-2025
[~phubner] just proceed as you want, whomever integrates second can easily deal with the merge. Thanks.
22-08-2025
[~dholmes] thanks for the heads up! Would you advise for me to base my changes on your changes? I'm inclined to keep the changes separate, but happy to help solve conflicts in JDK-8347707 should this be merged in before JDK-8347707.
19-08-2025
[~phubner] also see JDK-8347707 which is out for review.
19-08-2025
[~phubner] no removal of snpritnf. But patterns where snprintf is called repeatedly over a fixed sized output buffer and the caller does (correctly or incorrectly) manually count characters, all of that can use stringStream instead. Take a look at that class, should become clear then. Truncation: If the existing pattern does something meaningful with truncation, e.g. asserting, the new code should do the same. To do that, we must recognise truncation. If stringStream was constructed over a fixed-sized buffer and it was truncated during printing, that information should be preserved inside the stringStream and be exposed as something like "was_truncated()" or similar. Maybe this already exists, not sure.
18-08-2025
Hi [~stuefe], I'm going to take a look at this. I'm going to start by going through builder-like patterns, but just to confirm, you are not proposing to replace snprintf entirely? Could you also clarify what you mean by recognizing truncation? Do you mean refactoring patterns where we snprintf and then length-based assert after, for example: int n = os::snprintf(full_name, full_name_len, "%s%s%s", path, os::file_separator(), file_name); assert((size_t)n == full_name_len - 1, "Unexpected number of characters in string"); into a stringStream call followed by a did_truncate assertion?
18-08-2025
Placing in runtime category.
28-07-2025