8368172: Make java.time.format.DateTimePrintContext immutable

[wenshao]

I propose to make j.t.f.DateTimePrintContext immutable.

Currently, DateTimePrintContext has only one mutable field, optional. This can be replaced by adding an optional parameter to the DateTimeFormatter.formatTo method.

Immutable DateTimePrintContext can be optimized by escape analysis, such as immutable object optimization.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8368172: Make java.time.format.DateTimePrintContext immutable (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26913/head:pull/26913
$ git checkout pull/26913

Update a local copy of the PR:
$ git checkout pull/26913
$ git pull https://git.openjdk.org/jdk.git pull/26913/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26913

View PR using the GUI difftool:
$ git pr show -t 26913

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26913.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back swen! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@wenshao The following labels will be automatically applied to this pull request:

• core-libs
• i18n

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 03: Full - Incremental (558fa46f)
• 02: Full - Incremental (cac20038)
• 01: Full - Incremental (6f07a475)
• 00: Full (d3c43c57)

[jodastephen]

AFAICT this seems like a good change, thanks

[RogerRiggs]

What is the performance data that makes justifies this change? Its not enough to just want to make things constant.

[wenshao]

What is the performance data that makes justifies this change? Its not enough to just want to make things constant.

The current branch is just a refactoring; there's no performance improvement on MacBook M1 Pro.

Further changes are needed to enable the "EliminateAllocations" optimization to work, achieving the goal of eliminating the allocation of DateTimePrintContext and StringBuilder objects in the j.t.f.DateTimeFormatter#format method, thus resulting in significant performance improvements.

My plan is to optimize the performance of j.t.f.DateTimeFormatter#format. I've put the proposed changes in Draft Pull Request #26807, but it's a major change, and would be difficult to review all at once.

Therefore, I've broken this process down into multiple PRs, including the current PR #26913, another PR #26911, and the already merged PR #26633.

[RogerRiggs]

This change proposes to make every PrinterParser necessarily handle the optionality that is supported by a few printer parsers. For some, like literals, it makes no sense at all. It adds complexity to the PrinterParser interface.
The optionality for nesting of printer parsers is currently handled by counting the depth in the DateTimePrintContext.
Is there another way that the optionality in a DateTimeContext can be passed on nesting without adding an argument everywhere? Supposing the optional field in DateTimePrintContext could be final boolean and when optionality is needed, a copy be made with optional = true and passed to the nested printer. This technique is already used for appendOptional.

[RogerRiggs]

This has a much more invasive impact on PrinterParsers than the version with an extra argument on the format method.
Are there other implementations of the nested depth counter in DateTimePrinterContext?

[wenshao]

This has a much more invasive impact on PrinterParsers than the version with an extra argument on the format method. Are there other implementations of the nested depth counter in DateTimePrinterContext?

I also agree that #
version 558fa46 has too many changes; I haven't found a better version yet.

The advantage of the current version is that it clearly defines "optional" as a feature that is handled during build time, rather than during formatting.