-
Notifications
You must be signed in to change notification settings - Fork 6.3k
8357063: Document preconditions for DecimalDigits methods #25246
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
Conversation
👋 Welcome back swen! A progress list of the required criteria for merging this PR into |
@wenshao 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:
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 56 new commits pushed to the
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 |
792d16f
to
d40cad7
Compare
d40cad7
to
66f71c5
Compare
Webrevs
|
The renaming is nice and useful. |
*/ | ||
public static int getCharsUTF16(long i, int index, byte[] buf) { | ||
public static int uncheckedGetCharsUTF16(long i, int index, byte[] buf) { | ||
// Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding all methods that are prefixed with unchecked
in this PR, IMHO:
- Precondition warnings should better be moved to the JavaDoc (ala 8353197: Document preconditions for JavaLangAccess methods #24982)
- We shall also consider implementing these preconditions using
assert
statements
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wenshao, thanks for the kind effort – dropped suggestions to match the messages with the ones in JLA.
I prefer all1 public
, unchecked
-prefixed DecimalDigits
methods to start with a sufficient assert
preamble, to fail as early as possible. Though I don't want to create redundant extra work, hence double checking: @jaikiran, @minborg, @liach, WDYT?
1 Currently, only two private
methods are introduced assert
s, which are fine.
src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
Outdated
Show resolved
Hide resolved
Re assert preamble for public methods: Unfortunately this is not possible. The algorithm requires the chars to be written on demand, and it is very costly to precompute the length, aside from the fact that you can easily mess up on precomputation. The uncheckedness is from the 2 private methods, so I think safeguarding the 2 private methods with assertions is sufficient. |
Co-authored-by: Volkan Yazıcı <[email protected]>
Co-authored-by: Volkan Yazıcı <[email protected]>
Co-authored-by: Volkan Yazıcı <[email protected]>
Co-authored-by: Volkan Yazıcı <[email protected]>
Co-authored-by: Volkan Yazıcı <[email protected]>
Co-authored-by: Volkan Yazıcı <[email protected]>
Co-authored-by: Volkan Yazıcı <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This version looks good to me. Please wait for a second confirmation. (Allowing authors like @vy to review too)
/reviewers 2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Useful renames and comment placement improvements. lgtm.
* @return index of the most significant digit or minus sign, if present | ||
*/ | ||
public static int getChars(long i, int index, char[] buf) { | ||
// Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello Shaojin, I think this was a misplaced comment previously. Looking at the implementation of this method, there's no "unsafe" access happening in this method's implementation. It ends up calling putChar
which does a Java style array access and thus is backed by the language's bounds checking.
Removing this comment I believe is the right thing. Having said that, I am unsure the javadoc comment of this method should refer to DecimalDigits#uncheckedGetCharsUTF16
because that is confusing and misleading.
Should we change the javadoc text of this method to:
Places characters representing the long i into the character array buf. The characters are placed into the buffer backwards starting with the least significant digit at the specified index (exclusive), and working backwards from there.
Would that accurately describe what this method's implementation currently does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method has the same algorithm as uncheckedGetCharsUTF16, the only difference is the safe array access of char[] and the unsafe access of byte[] by uncheckedPutPairUTF16.
This method was also copied from uncheckedGetCharsUTF16 and then modified when the code was written, so I think the reference here is OK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/integrate
/integrate |
Going to push as commit 07871cd.
Your commit was automatically rebased without conflicts. |
Similar to PR #24982
Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25246/head:pull/25246
$ git checkout pull/25246
Update a local copy of the PR:
$ git checkout pull/25246
$ git pull https://git.openjdk.org/jdk.git pull/25246/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 25246
View PR using the GUI difftool:
$ git pr show -t 25246
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25246.diff
Using Webrev
Link to Webrev Comment