On Wed, 14 Jul 2021 11:13:31 GMT, Alexander Zuev wrote:
> Do not test situation where UIResource icon is returned
> Added a whole bunch of debug information to see what file test is filed
> upon.
Thank you!
-
PR: https://git.openjdk.java.net/jdk/pull/4776
On Wed, 14 Jul 2021 11:13:31 GMT, Alexander Zuev wrote:
> Do not test situation where UIResource icon is returned
> Added a whole bunch of debug information to see what file test is filed
> upon.
> @azuev-java I thought we agreed to fix the product bug mentioned here?
> [openjdk/jdk17#178
>
On Wed, 14 Jul 2021 11:13:31 GMT, Alexander Zuev wrote:
> Do not test situation where UIResource icon is returned
> Added a whole bunch of debug information to see what file test is filed
> upon.
@azuev-java I thought we agreed to fix the product bug mentioned here?
On Wed, 14 Jul 2021 11:13:31 GMT, Alexander Zuev wrote:
> Do not test situation where UIResource icon is returned
> Added a whole bunch of debug information to see what file test is filed
> upon.
Documents that changes to the specification made between Java SE 15 and Java SE
16. This document
On Thu, 15 Jul 2021 07:55:11 GMT, Jayathirth D V wrote:
>> Do not test situation where UIResource icon is returned
>> Added a whole bunch of debug information to see what file test is filed
>> upon.
>
> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 85:
>
>> 83:
On Wed, 14 Jul 2021 11:13:31 GMT, Alexander Zuev wrote:
> Do not test situation where UIResource icon is returned
> Added a whole bunch of debug information to see what file test is filed
> upon.
This issue is not specific to macOS 11, it is reproducible in my 10.15.7 also.
Test fails with
On Thu, 1 Jul 2021 21:19:37 GMT, Alexander Zuev wrote:
>> Added check for the icon class type
>> Added check if file or folder we are testing against exists and
>> accessible
>> Removed test from problem list
>
> Alexander Zuev has updated the pull request incrementally with one additional
>
On Thu, 8 Jul 2021 15:40:16 GMT, Alexander Zuev wrote:
>>> so under some circumstances and it is within spec to return single
>>> resolution icon
>>
>> Under what circumstances? Above we found a code path that may incorrectly
>> return the non-MRI images. Do we have some other similar
On Fri, 2 Jul 2021 19:51:27 GMT, Sergey Bylokhov wrote:
> Do we have some other similar places?
No, i do not see any other places where we return direct result of OS giving
out an icon.
-
PR: https://git.openjdk.java.net/jdk17/pull/178
On Thu, 1 Jul 2021 21:15:45 GMT, Alexander Zuev wrote:
> so under some circumstances and it is within spec to return single resolution
> icon
Under what circumstances? Above we found a code path that may incorrectly
return the non-MRI images. Do we have some other similar places?
On Thu, 1 Jul 2021 20:58:59 GMT, Alexander Zuev wrote:
>> When in what line of code we got a null from the native code so the
>> UIManager was used?
>
>> When in what line of code we got a null from the native code so the
>> UIManager was used?
>
> I haven't got into the exact native part
> Added check for the icon class type
> Added check if file or folder we are testing against exists and
> accessible
> Removed test from problem list
Alexander Zuev has updated the pull request incrementally with one additional
commit since the last revision:
Make test headless again
Do not
On Thu, 1 Jul 2021 17:14:24 GMT, Sergey Bylokhov wrote:
> When in what line of code we got a null from the native code so the UIManager
> was used?
I haven't got into the exact native part which is failing. The problem is that
i was able to reproduce it only twice in a couple of weeks - both
On Thu, 1 Jul 2021 17:09:06 GMT, Alexander Zuev wrote:
>> That test was not marked as headful because this API should work in the
>> headless environment as well, if it does not work when we have a bug in the
>> shell classes which should return the icon from the UIManager on any error.
>> I
On Thu, 1 Jul 2021 16:20:42 GMT, Sergey Bylokhov wrote:
> we get the icon of the correct size and skip the creation of
> "MultiResolutionIconImage"? As a result, the test fails because the icon is
> not multi-resolution.
Well, it might be this case sometimes but in the case when i was able to
On Wed, 30 Jun 2021 20:11:53 GMT, Alexander Zuev wrote:
>> I am a bit surprised the tests for this are not already headful. I can
>> imagine all sorts of platform reasons why making them headless is not
>> testing the "real" use case making the tests less than useful.
>> Ever seen a hidpi
On Wed, 30 Jun 2021 18:31:13 GMT, Alexander Zuev wrote:
>> Not in this case, you cannot change the public signature.
>
>> Not in this case, you cannot change the public signature.
>
> Well, it is a change in API and should be done within the same process as any
> API change. But it definitely
> Added check for the icon class type
> Added check if file or folder we are testing against exists and
> accessible
> Removed test from problem list
Alexander Zuev has updated the pull request incrementally with one additional
commit since the last revision:
Mark test as headful
On Wed, 30 Jun 2021 19:27:25 GMT, Phil Race wrote:
> I am a bit surprised the tests for this are not already headful
Fixed.
-
PR: https://git.openjdk.java.net/jdk17/pull/178
On Wed, 30 Jun 2021 19:19:24 GMT, Alexander Zuev wrote:
>>> No, the native code will fail to load the icon
>> So what call will fail? Is the "sf.getIcon()" return null? in what line of
>> code?
>
> Yes, from my remote debugging it happens in sf.getIcon() but the
> circumstances are quite rare
On Wed, 30 Jun 2021 04:51:04 GMT, Sergey Bylokhov wrote:
>>> * but what happens if the file cannot be read? We will call the "sf =
>>> ShellFolder.getShellFolder" and then we call "sf.getIcon()" and it returns
>>> what? As far as I understand it always return MultiResolutionIconImage, no?
>>>
On Wed, 30 Jun 2021 04:43:20 GMT, Sergey Bylokhov wrote:
> Not in this case, you cannot change the public signature.
Well, it is a change in API and should be done within the same process as any
API change. But it definitely can be done in the future major release.
-
PR:
On Wed, 30 Jun 2021 04:45:45 GMT, Sergey Bylokhov wrote:
> Even now, on Windows it is necessary to check is the returned object
> ImageIcon or not.
Yes but since API states that returned type is an Icon it should be done
anyways - because we might wrap up Icon in ImageIcon locally but we
On Wed, 30 Jun 2021 04:23:45 GMT, Alexander Zuev wrote:
>> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 76:
>>
>>> 74: int[] sizes = new int[] {16, 32, 48, 64, 128};
>>> 75: for (int size : sizes) {
>>> 76: ImageIcon icon = (ImageIcon)
On Wed, 30 Jun 2021 04:22:37 GMT, Alexander Zuev wrote:
> No, the native code will fail to load the icon
So what call will fail? Is the "sf.getIcon()" return null? in what line of code?
>> But you cannot change the return type later, so all these instanceof+casts
>> will be there forever.
>
>>
On Wed, 30 Jun 2021 03:01:03 GMT, Sergey Bylokhov wrote:
> * but what happens if the file cannot be read? We will call the "sf =
> ShellFolder.getShellFolder" and then we call "sf.getIcon()" and it returns
> what? As far as I understand it always return MultiResolutionIconImage, no?
> *
No,
On Tue, 29 Jun 2021 23:47:27 GMT, Sergey Bylokhov wrote:
> Probably we can wrap the "UIManager.getIcon" in the "ImageIcon"?
Why? In some LaFs that might be a procedural image that generates it content
every time paint() is called on it - i do not think wrapping it in the
ImageIcon will solve
On Wed, 30 Jun 2021 02:54:21 GMT, Sergey Bylokhov wrote:
> But you cannot change the return type later, so all these instanceof+casts
> will be there forever.
Well, if there is a reason the API can be amended in the future version of
Java. It is not cast in stone. Yes, it will require some
On Wed, 30 Jun 2021 01:13:29 GMT, Alexander Zuev wrote:
>> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 75:
>>
>>> 73: static void testSystemIcon(File file, boolean implComplete) {
>>> 74: int[] sizes = new int[] {16, 32, 48, 64, 128};
>>> 75: if
On Tue, 29 Jun 2021 23:51:06 GMT, Sergey Bylokhov wrote:
> One more time would like to highlight that to get the data of the requested
> image the user need to do one "if" and two "instanceof". Still hope that we
> can improve this.
We might when the implementation will be complete on all the
On Tue, 29 Jun 2021 23:44:04 GMT, Sergey Bylokhov wrote:
> If this file is not accessible the "getSystemIcon" should return "null" you
> can check it here.
If file is not accessible we still return default icon for file or folder - if
we, for example, looking at the folder in file explorer
On Tue, 29 Jun 2021 22:10:46 GMT, Alexander Zuev wrote:
> Added check for the icon class type
> Added check if file or folder we are testing against exists and
> accessible
> Removed test from problem list
test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 75:
> 73:
On Tue, 29 Jun 2021 22:10:46 GMT, Alexander Zuev wrote:
> Added check for the icon class type
> Added check if file or folder we are testing against exists and
> accessible
> Removed test from problem list
@prsadhuk @azvegint please review
-
PR:
On Tue, 29 Jun 2021 22:06:37 GMT, Alexander Zuev wrote:
>> 8268280: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails
>> on windows
>
> Alexander Zuev has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated
Added check for the icon class type
Added check if file or folder we are testing against exists and
accessible
Removed test from problem list
-
Commit messages:
- 8269269: [macos11] SystemIconTest fails with ClassCastException
Changes:
> 8268280: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on
> windows
Alexander Zuev has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request
On Tue, 29 Jun 2021 19:11:32 GMT, Alexander Zuev wrote:
> 8268280: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on
> windows
test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 75:
> 73: static void testSystemIcon(File file, boolean implComplete)
8268280: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on
windows
-
Commit messages:
- 8269269: [macos11] SystemIconTest fails with ClassCastException
Changes: https://git.openjdk.java.net/jdk17/pull/176/files
Webrev:
38 matches
Mail list logo
