Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8260468: Wrong behavior of LocalDateTimeStringConverter #393

Conversation

@nlisker
Copy link
Collaborator

@nlisker nlisker commented Feb 4, 2021

Fixes a mutability issue for LocalDateTimeStringConverter (and LocalDateStringConverter) where the chronology can change during the lifetime of the instance and cause an inconsistent state. The following changes were made:

  • The input is now formatted and parsed directly with the formatter and parser (which are configured with a chronology) without the chronology field value of the class.
  • The chronology field value does not change anymore when there is an exception due to inability to format the date.
  • Logging on failed formatting was removed as it did not seem useful. The formatter will throw the same exception that the chronology field does anyway, so there is not much use to catching the exception before hand.

Added a test that fails without this patch. The test creates a converter with an explicit Chronology and null parser and formatter. The default formatter that is created with the given chronology formats a legal date (with respect to the chronology) to a string, which the parser should be able to convert back to a date. However, by forcing an exception in the formatting process using an illegal date, the chronology changes, and now when the parser is used it is configured with the new chronology and it can't parse the string correctly.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8260468: Wrong behavior of LocalDateTimeStringConverter

Reviewers

Download

$ git fetch https://git.openjdk.java.net/jfx pull/393/head:pull/393
$ git checkout pull/393

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Feb 4, 2021

👋 Welcome back nlisker! 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.

@nlisker nlisker marked this pull request as ready for review Feb 4, 2021
@openjdk openjdk bot added the rfr label Feb 4, 2021
@nlisker
Copy link
Collaborator Author

@nlisker nlisker commented Feb 4, 2021

The added test will look meaningless after the patch, since it's trying to force a change that can't happen anymore, and this can be confusing in the future. Does it still make sense to commit it? It's more of a demonstration of the bug and the fix.

I also noticed that other tests in LocalDateTimeStringConverterTest are not named with test in the beginning. Is this wrong?

@mlbridge
Copy link

@mlbridge mlbridge bot commented Feb 4, 2021

Webrevs

@kevinrushforth
Copy link
Member

@kevinrushforth kevinrushforth commented Feb 4, 2021

/reviewers 2

@openjdk
Copy link

@openjdk openjdk bot commented Feb 4, 2021

@kevinrushforth
The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers).

@kevinrushforth kevinrushforth self-requested a review Feb 4, 2021
@kevinrushforth
Copy link
Member

@kevinrushforth kevinrushforth commented Feb 9, 2021

The added test will look meaningless after the patch, since it's trying to force a change that can't happen anymore, and this can be confusing in the future. Does it still make sense to commit it? It's more of a demonstration of the bug and the fix.

This seems fine to me. We've done this sort of thing for other tests as well.

I also noticed that other tests in LocalDateTimeStringConverterTest are not named with test in the beginning. Is this wrong?

This is a loose naming convention that many classes follow, but many others do not, so it is not a problem.

Copy link
Member

@kevinrushforth kevinrushforth left a comment

The fix looks good to me, as does the test with a couple suggestions.

Copy link
Member

@kevinrushforth kevinrushforth left a comment

Looks good.

@kevinrushforth kevinrushforth requested a review from arapte Feb 13, 2021
Copy link
Collaborator

@pankaj-bansal pankaj-bansal left a comment

looks ok to me

@openjdk
Copy link

@openjdk openjdk bot commented Feb 23, 2021

@nlisker This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8260468: Wrong behavior of LocalDateTimeStringConverter

Reviewed-by: kcr, pbansal

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 20 new commits pushed to the master branch:

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready label Feb 23, 2021
@nlisker
Copy link
Collaborator Author

@nlisker nlisker commented Feb 23, 2021

/integrate

@openjdk openjdk bot closed this Feb 23, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Feb 23, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Feb 23, 2021

@nlisker Since your change was applied there have been 20 commits pushed to the master branch:

Your commit was automatically rebased without conflicts.

Pushed as commit e25d39b.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@nlisker nlisker deleted the 8260468_Wrong_behavior_of_LocalDateTimeStringConverter branch Feb 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants