On Mon, 8 Sep 2025 02:27:10 GMT, Shaojin Wen <s...@openjdk.org> wrote:
>> This PR introduces a new efficient API for appending two-digit integers to >> StringBuilders and refactors DateTimeHelper to leverage this new >> functionality. >> >> Changes include: >> >> 1. New `appendPair` method for efficient two-digit integer formatting >> (00-99): >> - Added `AbstractStringBuilder.appendPair(int i)` with core implementation >> - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal >> access >> - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge >> - Added `DecimalDigits.appendPair(StringBuilder, int)` public static >> utility method >> - Enhanced Javadoc documentation for all new methods >> >> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: >> - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and >> `LocalTime` >> - Replaced manual formatting logic with the new efficient two-digit >> appending >> - Improved code clarity and consistency in date/time formatting >> >> These changes improve code clarity and performance when formatting two-digit >> numbers, particularly in date/time formatting scenarios. > > Shaojin Wen has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains six commits: > > - Merge remote-tracking branch 'upstream/master' into appendPair_202508 > > # Conflicts: > # src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java > - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 > encoding > - Use DecimalDigits.appendPair for formatting in time classes > > This change modifies the toString() methods in MonthDay, YearMonth, > ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for > formatting two-digit numbers. This provides a more efficient and consistent > way to format these values. > > Also added a comment in ChronoLocalDateImpl.toString() to explain why > get() is used instead of getLong() for performance reasons, as the values are > guaranteed to be within the int range for all chronologies. > > Co-authored-by: Qwen-Coder <qwen-co...@alibabacloud.com> > - Optimize year formatting in DateTimeHelper by reducing modulo operation > > Co-authored-by: Qwen-Coder <qwen-co...@alibabacloud.com> > > Refactored the year formatting logic to use subtraction instead of modulo > for calculating the lower two digits, which can be slightly more efficient. > Added a comment to clarify the safety of the input range for > DecimalDigits.appendPair. > - Refactor DateTimeHelper to use DecimalDigits.appendPair for date/time > formatting\n\nThis change updates DateTimeHelper.formatTo methods for > LocalDate and LocalTime\nto use the new DecimalDigits.appendPair method for > formatting month, day, hour,\nminute, and second components. This improves > code clarity and leverages the\nnewly introduced efficient two-digit integer > appending functionality. > > Co-authored-by: Qwen-Coder <qwen-co...@alibabacloud.com> > - Introduce appendPair method for efficient two-digit integer > appending\n\nThis change adds a new internal API to efficiently append > two-digit integers\n(00-99) to a StringBuilder. It includes:\n- > AbstractStringBuilder.appendPair(int i): The core implementation.\n- > JavaLangAccess.appendPair(StringBuilder, int): For internal access.\n- > System.JavaLangAccessImpl.appendPair(StringBuilder, int): Bridge to > AbstractStringBuilder.\n- DecimalDigits.appendPair(StringBuilder, int): > Public static utility method.\n\nImproved Javadoc comments for clarity and > consistency across all new methods. > > Co-authored-by: Qwen-Coder <qwen-co...@alibabacloud.com> This solution, if it is to be accepted, can only be a stopgap measure - I think the most likely feature to replace this hack would be String Templates. What abilities do you think that String Templates should support so that you can cover this use case (when we migrate the DateTimeFormatter to be String template instead of StringBuilder based)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3290328094
