-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
8320692: Null icon returned for .exe without custom icon #17475
Conversation
Replaced asserts with NullPointerException calls because outside of testing that would be more informative - i do not think many people running their applications with assertions in system libraries enabled; Added a code that will analyze the result of the getIcon and will fall back to the default icon for the file type retrieved from the ShellFolder; Added a test case made by Aleksei Ivanov.
👋 Welcome back kizune! A progress list of the required criteria for merging this PR into |
/label client |
@azuev-java 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. |
@azuev-java The |
Webrevs
|
if (multiResolutionIcon.containsValue(null)) { | ||
return null; | ||
} else { | ||
return new MultiResolutionIconImage(size, multiResolutionIcon); | ||
} |
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.
Can we return null
immediately if an icon that we're about to put into multiResolutionIcon
is null
?
That is change the line 1198(1195)
multiResolutionIcon.put(s, newIcon); |
to
if (newIcon == null) {
return null;
}
multiResolutionIcon.put(s, newIcon);
I assume if newIcon == null
then hIcon
is also null
, in which case we can move this condition to the line 1195(1192)
newIcon = makeIcon(hIcon); |
before calling makeIcon
.
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.
Ok, i will move it to the line 1198 because i can not guarantee that we do not need to dispose hIcon if we can not make icon out of it so i would rather avoid potential resource leak.
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.
We need to dispose of hIcon
if it's non-null. I see that in this case hIcon
is not null yet makeIcon
fails to get the bitmap for whatever reason.
It would be good to understand why makeIcon
fails even though hIcon
is not null.
It is possible that makeIcon
fails to extract an icon, so the added null-check ensures null
is returned instead of returning a broken MRI.
assert !resolutionVariants.containsValue(null) | ||
: "There are null icons in the MRI variants map"; | ||
if (resolutionVariants.containsValue(null)) { | ||
throw new NullPointerException("There are null icons in the MRI variants map"); | ||
} |
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.
I'm unsure about this. The idea with assert was to provide a debugging aid without affecting regular runtime. We control all the paths that call this constructor and, therefore, we should ensure it's never called if resolutionVariants
contains null
.
It's exactly what you've done in this PR.
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.
Ok, i will revert that part.
/contributor add @aivanov-jdk |
@azuev-java |
Move null check inside the loop so we do not retrieve extra icons if we encounter a null one
: "There are null icons in the MRI variants map"; | ||
: "There are null icons in the MRI variants map"; |
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.
Here's an extra space. The colon aligned with !
which starts the condition.
Could you please revert it too?
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.
Sure.
@azuev-java 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 118 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 |
|
||
FileSystemView fsv = FileSystemView.getFileSystemView(); | ||
// No NullPointerException is expected | ||
fsv.getSystemIcon(hello.toFile()); |
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.
Maybe we should check that something useful is returned? at least non-null VS null value?
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.
Maybe we should check that something useful is returned? at least non-null VS null value?
Makes sense to ensure the returned value is not null
.
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.
Sure.
Test now checks for returned icon not to be null
/integrate |
Going to push as commit 6212264.
Your commit was automatically rebased without conflicts. |
@azuev-java Pushed as commit 6212264. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Replaced asserts with NullPointerException calls because outside of testing that would be more informative - i do not think many people running their applications with assertions in system libraries enabled;
Added a code that will analyze the result of the getIcon and will fall back to the default icon for the file type retrieved from the ShellFolder;
Added a test case made by Aleksei Ivanov.
Progress
Issue
Reviewers
Contributors
<aivanov@openjdk.org>
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/17475/head:pull/17475
$ git checkout pull/17475
Update a local copy of the PR:
$ git checkout pull/17475
$ git pull https://git.openjdk.org/jdk.git pull/17475/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 17475
View PR using the GUI difftool:
$ git pr show -t 17475
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/17475.diff
Webrev
Link to Webrev Comment