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

8262744: Formatter '%g' conversion uses wrong format for BigDecimal rounding up to limits #3363

Closed

Conversation

@igraves
Copy link
Member

@igraves igraves commented Apr 6, 2021

This fixes a bug where the formatting code for %g flags incorrectly tries to round BigDecimal after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.


Progress

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

Issue

  • JDK-8262744: Formatter '%g' conversion uses wrong format for BigDecimal rounding up to limits

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3363/head:pull/3363
$ git checkout pull/3363

Update a local copy of the PR:
$ git checkout pull/3363
$ git pull https://git.openjdk.java.net/jdk pull/3363/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3363

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3363.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Apr 6, 2021

👋 Welcome back igraves! 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 openjdk bot added the rfr label Apr 6, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 6, 2021

@igraves 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
Copy link

@mlbridge mlbridge bot commented Apr 6, 2021

Webrevs

@openjdk
Copy link

@openjdk openjdk bot commented Apr 16, 2021

@igraves 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:

8262744: Formatter '%g' conversion uses wrong format for BigDecimal rounding up to limits

Reviewed-by: rriggs, bpb

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 179 new commits pushed to the master branch:

  • 74d03ab: 8039270: The background color of the button can't be displayed and when pressed the button, the background color can not be changed in accordance with the case described.
  • 7c37c02: 8244190: JFR: When starting a JVM with -XX:StartFlightRecording, output is written to stdout
  • 79adc16: 8264152: javax/net/ssl/DTLS/RespondToRetransmit.java timed out
  • 1c3fd46: 8265175: (fs) Files.copy(Path,Path,CopyOption...) should use sendfile on Linux
  • cee4f1d: 8203925: tools/javac/importscope/T8193717.java ran out of java heap
  • 694e1cd: 8262060: compiler/whitebox/BlockingCompilation.java timed out
  • 6946d91: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF
  • 714298a: 8265259: G1: Fix HeapRegion::block_is_obj for unloading class in full gc
  • ff5bb8c: 8265239: Shenandoah: Shenandoah heap region count could be off by 1
  • 17b6592: 8265335: Epsilon: Minor typo in EpsilonElasticTLABDecay description
  • ... and 169 more: https://git.openjdk.java.net/jdk/compare/920189918ed81391024b6da011289d851b2098ac...master

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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@RogerRiggs, @bplb) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready label Apr 16, 2021
@bplb
bplb approved these changes Apr 16, 2021
Copy link
Member

@bplb bplb left a comment

I think this looks all right. I assume you ran all the java.math tests.

@igraves
Copy link
Member Author

@igraves igraves commented Apr 16, 2021

That's correct. Passes java.math tests. Ran it again, just to be sure.

@igraves
Copy link
Member Author

@igraves igraves commented Apr 16, 2021

/integrate

@openjdk openjdk bot added the sponsor label Apr 16, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 16, 2021

@igraves
Your change (at version 4552260) is now ready to be sponsored by a Committer.

@RogerRiggs
Copy link
Contributor

@RogerRiggs RogerRiggs commented Apr 16, 2021

/sponsor

@openjdk
Copy link

@openjdk openjdk bot commented Apr 16, 2021

@RogerRiggs @igraves Since your change was applied there have been 180 commits pushed to the master branch:

  • 4413dbf: 8263395: Incorrect use of Objects.nonNull
  • 74d03ab: 8039270: The background color of the button can't be displayed and when pressed the button, the background color can not be changed in accordance with the case described.
  • 7c37c02: 8244190: JFR: When starting a JVM with -XX:StartFlightRecording, output is written to stdout
  • 79adc16: 8264152: javax/net/ssl/DTLS/RespondToRetransmit.java timed out
  • 1c3fd46: 8265175: (fs) Files.copy(Path,Path,CopyOption...) should use sendfile on Linux
  • cee4f1d: 8203925: tools/javac/importscope/T8193717.java ran out of java heap
  • 694e1cd: 8262060: compiler/whitebox/BlockingCompilation.java timed out
  • 6946d91: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF
  • 714298a: 8265259: G1: Fix HeapRegion::block_is_obj for unloading class in full gc
  • ff5bb8c: 8265239: Shenandoah: Shenandoah heap region count could be off by 1
  • ... and 170 more: https://git.openjdk.java.net/jdk/compare/920189918ed81391024b6da011289d851b2098ac...master

Your commit was automatically rebased without conflicts.

Pushed as commit 0bdc3e7.

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

|| ((value.compareTo(tenToTheNegFour) != -1)
&& (value.compareTo(tenToThePrec) == -1))) {
|| ((value.compareTo(BigDecimal.valueOf(1, 4)) != -1)
&& (value.compareTo(BigDecimal.valueOf(1, -prec)) == -1))) {

This comment has been minimized.

@stuart-marks

stuart-marks Apr 21, 2021
Member

Note that compareTo in general specifies a negative, zero, or positive return value, but BigDecimal and BigInteger specify a return value of -1, 0, and 1. So the code here that compares against -1 is strictly correct. However, the BigDecimal/BigInteger.compareTo docs say "The suggested idiom..." is a relative comparison against zero.

Indeed, the BigDecimal::compareTo method does always seem to return -1, 0, or 1 so this code is not incorrect. Well, maybe. I checked quickly and the BigDecimal comparison logic is fairly intricate (and also runs through BigInteger) so I might have missed something. Also, BigDecimal is subclassable, so an override of compareTo might return something other than -1, 0, or 1, even though strictly speaking this would violate the BigDecimal spec.

I'm wondering if there should be a followup bug that changes these tests to >= 0 and < 0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
5 participants