On Tue, 27 Aug 2024 23:49:50 GMT, Shaojin Wen <s...@openjdk.org> wrote:
>> By removing the redundant code logic in
>> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
>> reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains nine additional
> commits since the last revision:
>
> - Speed up Instant.toString using JavaTimeAccess
> - add JavaTimeAccess SharedSecrets
> - Merge remote-tracking branch 'upstream/master' into
> optim_instant_fmt_202407
> - breaking out the printNano methods
> - copyright
> - Update
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>
> Co-authored-by: Stephen Colebourne <scolebou...@joda.org>
> - 1. fix handle fraction == -1
> 2. Split two methods to make codeSize less than 325
> - add comment
> - optimize format instant
src/java.base/share/classes/java/time/LocalDateTime.java line 2028:
> 2026: SharedSecrets.setJavaTimeAccess(new JavaTimeAccess() {
> 2027: public void formatTo(StringBuilder buf, LocalDateTime ldt) {
> 2028: ldt.formatTo(buf);
Neither java.time nor the rest of the JDK has a convention to use acronyms like
`ldt` as variable names.
Maybe this variable should be called for example `timeToFormat` instead?
src/java.base/share/classes/jdk/internal/access/JavaTimeAccess.java line 34:
> 32: * Prints the toString result to the given buf, avoiding extra string
> allocations.
> 33: */
> 34: void formatTo(StringBuilder buf, LocalDateTime ldt);
Neither java.time nor the rest of the JDK has a convention to use acronyms like
`ldt` as variable names.
Maybe this variable should be called for example `timeToFormat` instead?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1747120332
PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1747121067
