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
8304717: Declaration aliasing between boolean and jboolean is wrong #13139
Conversation
👋 Welcome back jwaters! A progress list of the required criteria for merging this PR into |
@TheShermanTanker The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
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.
One change has an issue but the others seem fine. You really need reviewers from each component area though.
Thanks.
@@ -682,7 +682,7 @@ static void createTreeForPath(CFStringRef path, CFStringRef name, | |||
CFDictionaryRef node; | |||
CFStringRef topKey; | |||
CFMutableDictionaryRef topValue; | |||
Boolean beforeAdd = false; |
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.
The return value from CFDictionaryContainsKey
is a Boolean and is assigned to this variable. So I think these changes are the wrong way round. Keep this as a Boolean but convert the return value to jboolean:
return beforeAdd ? JNI_TRUE : JNI_FALSE;
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.
Argh, looks like Apple and Objective-C still use the ancient Boolean types from Carbon for the CoreFoundation APIs. Sigh...
/label add awt Adding AWT folk. |
@dholmes-ora
|
Correct label for awt is client to my knowledge |
/label client |
@TheShermanTanker |
Thanks for the correction I thought the mailing list was awt-dev similar to swing-dev. |
Is this needed? A boolean-to-int conversion returns |
I'd argue it's more for correctness: Indeed it will still compile fine as of now, but the type of jboolean is not the only thing that can change; the other typedef'd boolean type can also be modified later on. Additionally, with compilers getting stricter as newer releases drop, it's a good idea to make sure the signatures match as best as possible, especially between declarations and definitions of the same method |
@@ -695,9 +695,9 @@ static void createTreeForPath(CFStringRef path, CFStringRef name, | |||
beforeAdd = CFDictionaryContainsKey(parent, child); | |||
CFDictionaryAddValue(parent, child, node); | |||
if (!beforeAdd) | |||
beforeAdd = CFDictionaryContainsKey(parent, child); | |||
beforeAdd = CFDictionaryContainsKey(parent, child) ? JNI_TRUE : JNI_FALSE; |
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.
If you do this here you need something similar on line 695. Still say it is simpler to use Boolean internally and convert to jboolean on return expression.
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.
The single java.desktop change looks OK, so when anyone approves the rest that's implicitly approved.
Alright, thanks Phil |
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.
Okay. Thanks.
@TheShermanTanker 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 235 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 |
Thanks David! |
/integrate |
Going to push as commit cd7d53c.
Your commit was automatically rebased without conflicts. |
@TheShermanTanker Pushed as commit cd7d53c. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13139/head:pull/13139
$ git checkout pull/13139
Update a local copy of the PR:
$ git checkout pull/13139
$ git pull https://git.openjdk.org/jdk.git pull/13139/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 13139
View PR using the GUI difftool:
$ git pr show -t 13139
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13139.diff
Webrev
Link to Webrev Comment