On Mon, 6 Sep 2021 11:35:05 GMT, Amresh Sahu
wrote:
> Problem: In Windows look and feel, Button(in test case ui) starts animating
> to show the selection and test case captures the animated button image to do
> the comparisons with initial button image and this comparison fails with
>
On Wed, 25 Aug 2021 10:39:42 GMT, Pankaj Bansal wrote:
>> A container may include few default components as children, which are added
>> to it during creation. Due to this, calling function getChildrenCount on a
>> new created instance may return non zero value. This behaviour may vary
>>
On Fri, 3 Sep 2021 04:13:46 GMT, Prasanta Sadhukhan
wrote:
>> src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java line 419:
>>
>>> 417: } else {
>>> 418: arrowIcon.paintIcon(c, g, arrowIconRect.x,
>>> arrowIconRect.y);
>>> 419: }
>>
>>
On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be don
On Thu, 2 Sep 2021 12:41:58 GMT, Prasanta Sadhukhan
wrote:
>> It is seen in macos disabled JMenuItem arrow is not disabled even though
>> JMenuItem itself is disabled.
>> In native app, same menuitem arrow is disabled for disabled menuitem.
>>
>> Issue is when AquaMenuPainter#paintMenuItem()
On Thu, 2 Sep 2021 09:53:34 GMT, Prasanta Sadhukhan
wrote:
> That is for MenuArrowIcon which is also there for Metal and Windows L in
> addition with MenuItemArrowIcon(). Aqua does not have it for MenuItem.
But this icon is used for the menuitem as well, isn't it? You can add this line
to
On Thu, 2 Sep 2021 09:17:50 GMT, Prasanta Sadhukhan
wrote:
> but for AquaL it does not create it's own factory icon and rely on
> BasicIconFactory$MenuItemArrowIcon, so tweaking aqua arrow icon inline with
> how other do will cause design change, so I think this fix caters to the
> problem
On Thu, 2 Sep 2021 04:18:47 GMT, Prasanta Sadhukhan
wrote:
>> src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java line 301:
>>
>>> 299: arrowIcon = new ImageIconUIResource(GrayFilter.
>>> 300:
>>>
On Tue, 31 Aug 2021 06:09:38 GMT, Prasanta Sadhukhan
wrote:
> It is seen in macos disabled JMenuItem arrow is not disabled even though
> JMenuItem itself is disabled.
> In native app, same menuitem arrow is disabled for disabled menuitem.
>
> Issue is when AquaMenuPainter#paintMenuItem() is
On Tue, 31 Aug 2021 19:10:53 GMT, Alexey Ivanov wrote:
>> Automated NimbusJTreeSelTextColor.java test which is added under
>> [JDK-8271315](https://bugs.openjdk.java.net/browse/JDK-8271315).
>>
>> It passes with the recent build of JDK 18.
>> It fails with JDK 18 build 7 where
>>
On Tue, 31 Aug 2021 06:09:38 GMT, Prasanta Sadhukhan
wrote:
> In native app, same menuitem arrow is disabled for disabled menuitem.
How it will work if the "apple.laf.useScreenMenuBar" property is set, will the
arrow look the same(disabled) as after this fix?
-
PR:
n this fix: the Xerces library(should be fixed upstream),
> J2DBench(should be compatible to 1.4), some code in the network(the change
> there are not straightforward, will do it later).
>
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
Sergey Bylokhov has updated the
n this fix: the Xerces library(should be fixed upstream),
> J2DBench(should be compatible to 1.4), some code in the network(the change
> there are not straightforward, will do it later).
>
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
Sergey Bylokhov has updated the
On Fri, 27 Aug 2021 09:10:54 GMT, Alexey Ivanov wrote:
> Yes, the test passes. The only exception is macOS: the test fails there
> either way because the text is rendered with antialiasing and I can't disable
> font smoothing on macOS. Does anyone know how to disable it?
>
> I'm thinking
On Thu, 26 Aug 2021 07:18:43 GMT, Pankaj Bansal wrote:
> The function documentation for oneTouchExpandableChanged states that the
> function does couple of things, but in reality it only does those things if
> the Look and Feel supports the supportsOneTouchButtons. In case the Look and
>
On Thu, 26 Aug 2021 19:21:13 GMT, Alexey Ivanov wrote:
> Automated NimbusJTreeSelTextColor.java test which is added under
> [JDK-8271315](https://bugs.openjdk.java.net/browse/JDK-8271315).
>
> It passes with the recent build of JDK 18.
> It fails with JDK 18 build 7 where
>
On Wed, 25 Aug 2021 06:17:56 GMT, Prasanta Sadhukhan
wrote:
>> This is another attempt of fixing JDK-8249674 which created a regression
>> JDK-8266510 for which it was backed out.
>> This fix reinstates the UIResource properties for "Tree.leafIcon",
>> "Tree.closedIcon", "Tree.openIcon",
On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov wrote:
>> Sergey Bylokhov 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 cont
On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote:
>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>>
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>>
&
On Wed, 25 Aug 2021 04:03:56 GMT, Prasanta Sadhukhan
wrote:
> I tried creating automated test for that but not able to..I can create manual
> test but sInce it is easily seen in SwingSet2 JTree demo, we can verify that
> using SwingSet2.
I do not think it is so easy reproducible, it was
On Thu, 19 Aug 2021 06:13:39 GMT, Prasanta Sadhukhan
wrote:
> This is another attempt of fixing JDK-8249674 which created a regression
> JDK-8266510 for which it was backed out.
> This fix reinstates the UIResource properties for "Tree.leafIcon",
> "Tree.closedIcon", "Tree.openIcon",
On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov
wrote:
> Collections.sort is just a wrapper, so it is better to use an instance method
> directly.
The changes in the src/java.desktop/ looks fine.
Filed: https://bugs.openjdk.java.net/browse/JDK-8272863
-
Marked as reviewed by
On Mon, 23 Aug 2021 16:58:51 GMT, Phil Race wrote:
>> A container may include few default components as children, which are added
>> to it during creation. Due to this, calling function getChildrenCount on a
>> new created instance may return non zero value. This behaviour may vary
>>
On Sun, 22 Aug 2021 15:09:26 GMT, Alan Bateman wrote:
>> Sergey Bylokhov 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 cont
On Sun, 22 Aug 2021 18:31:02 GMT, Andrey Turbanov
wrote:
> I think it's worth to update _static_ initializer in
> `sun.datatransfer.DataFlavorUtil.CharsetComparator` too.
Updated as suggested.
-
PR: https://git.openjdk.java.net/jdk/pull/5210
On Mon, 23 Aug 2021 13:08:02 GMT, Alexey Ivanov wrote:
>> Looks like there's no purpose, `tags` is not used after assignment
>
> Maybe it's kind of a protection from a race. Yet it's possible either way:
> another thread could see `essentialTags == null` before this one initialises
> the
n this fix: the Xerces library(should be fixed upstream),
> J2DBench(should be compatible to 1.4), some code in the network(the change
> there are not straightforward, will do it later).
>
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
Sergey Bylokhov has updated the
This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
See https://github.com/openjdk/jdk/pull/5063 and
https://github.com/openjdk/jdk/pull/4951
In many places standard charsets are looked up via their names, for example:
absolutePath.getBytes("UTF-8");
This could be done more
On Fri, 20 Aug 2021 09:41:15 GMT, Сергей Цыпанов
wrote:
> This is a continuation of
>
> - https://bugs.openjdk.java.net/browse/JDK-6736490
> - https://bugs.openjdk.java.net/browse/JDK-8035284
> - https://bugs.openjdk.java.net/browse/JDK-8145680
> -
On Thu, 19 Aug 2021 16:48:46 GMT, Prasanta Sadhukhan
wrote:
>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be
>> called with null value. There are many places in JInternalFrame where
>> getDesktopIcon() is accessed without null check which might cause NPE.
>> Added
On Mon, 16 Aug 2021 08:22:35 GMT, Pankaj Bansal wrote:
> A container may include few default components as children, which are added
> to it during creation. Due to this, calling function getChildrenCount on a
> new created instance may return non zero value. This behaviour may vary
>
On Tue, 17 Aug 2021 06:09:51 GMT, Alexander Zuev wrote:
>> Initial implementation and a test case.
>>
>> The problem is that Aqua LaF shows the focused component with the glow on
>> the border, hence when the border is not painted the foxus is not displayed.
>> The idea is to paint the
On Tue, 17 Aug 2021 04:47:43 GMT, Prasanta Sadhukhan
wrote:
>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be
>> called with null value. There are many places in JInternalFrame where
>> getDesktopIcon() is accessed without null check which might cause NPE.
>> Added
On Mon, 16 Aug 2021 23:39:05 GMT, Alexander Zuev wrote:
>> What about the color property?
>
>> What about the color property?
>
> That would be unnecessary, whoever does painting does not just assumes that
> the color is set to his preferred choice, everywhere in the code color is set
> up
On Mon, 16 Aug 2021 19:45:11 GMT, Alexander Zuev wrote:
>> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 340:
>>
>>> 338: Color ringColor = UIManager.getColor("Focus.color");
>>> 339: g.setColor(ringColor);
>>> 340: g.drawRoundRect(5, 3,
On Mon, 16 Aug 2021 08:22:35 GMT, Pankaj Bansal wrote:
> A container may include few default components as children, which are added
> to it during creation. Due to this, calling function getChildrenCount on a
> new created instance may return non zero value. This behaviour may vary
>
On Fri, 13 Aug 2021 19:17:13 GMT, Alexander Zuev wrote:
>> Initial implementation and a test case.
>>
>> The problem is that Aqua LaF shows the focused component with the glow on
>> the border, hence when the border is not painted the foxus is not displayed.
>> The idea is to paint the
On Fri, 13 Aug 2021 19:17:13 GMT, Alexander Zuev wrote:
>> Initial implementation and a test case.
>>
>> The problem is that Aqua LaF shows the focused component with the glow on
>> the border, hence when the border is not painted the foxus is not displayed.
>> The idea is to paint the
On Wed, 11 Aug 2021 09:03:57 GMT, Prasanta Sadhukhan
wrote:
> The test fails in CI testing citing expected "rededited" but found
> "redEDITED", which seems to point to fact that either there is a CAPS_LOCK
> key switched on or some other test did not use SHIFT key corectly ie,
> pressed but
On Sat, 14 Aug 2021 22:31:42 GMT, Phil Race wrote:
> Not true ! stdout has everything ! All runs.Just a summary for a pass but all
> the data for a failure In one contoguous log file so there is no question.
Ok, so now we know that: according to this "contiguous log", the shift or
capslock
On Sat, 14 Aug 2021 22:34:37 GMT, Phil Race wrote:
> Just add advisory doc on the protected field too.
ok, this is part of what this change do, probably the text should be rephrased
there?
-
PR: https://git.openjdk.java.net/jdk/pull/4989
On Sat, 14 Aug 2021 18:50:58 GMT, Phil Race wrote:
> Folks who are doing it are likely seeing random exceptions anyway at a later
> time !
What we will do if the field will be set to null directly? Throw NPE at any
point later when we will found null?
-
PR:
On Sat, 14 Aug 2021 19:14:06 GMT, Phil Race wrote:
> I don't believe any of the scenarios.
>
> As you well know these headful tests will be re-run 2 more times if they fail.
But we know the log information only for the last failure, probably the button
was pressed only for the last rerun. And
On Thu, 12 Aug 2021 04:09:18 GMT, Prasanta Sadhukhan
wrote:
>> src/java.desktop/share/classes/javax/swing/JInternalFrame.java line 1308:
>>
>>> 1306: * Sets the JDesktopIcon associated with this
>>> 1307: * JInternalFrame.
>>> 1308: * Setting null icon is unsupported and may
On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote:
> Initial implementation and a test case.
>
> The problem is that Aqua LaF shows the focused component with the glow on the
> border, hence when the border is not painted the foxus is not displayed. The
> idea is to paint the glowing
On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote:
> Initial implementation and a test case.
>
> The problem is that Aqua LaF shows the focused component with the glow on the
> border, hence when the border is not painted the foxus is not displayed. The
> idea is to paint the glowing
On Wed, 11 Aug 2021 09:03:57 GMT, Prasanta Sadhukhan
wrote:
> The test fails in CI testing citing expected "rededited" but found
> "redEDITED", which seems to point to fact that either there is a CAPS_LOCK
> key switched on or some other test did not use SHIFT key corectly ie,
> pressed but
On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote:
> Initial implementation and a test case.
>
> The problem is that Aqua LaF shows the focused component with the glow on the
> border, hence when the border is not painted the foxus is not displayed. The
> idea is to paint the glowing
On Wed, 11 Aug 2021 09:03:57 GMT, Prasanta Sadhukhan
wrote:
> The test fails in CI testing citing expected "rededited" but found
> "redEDITED", which seems to point to fact that either there is a CAPS_LOCK
> key switched on or some other test did not use SHIFT key corectly ie,
> pressed but
On Mon, 9 Aug 2021 04:21:08 GMT, Prasanta Sadhukhan
wrote:
>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be
>> called with null value. There are many places in JInternalFrame where
>> getDesktopIcon() is accessed without null check which might cause NPE.
>> Added
On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote:
> Initial implementation and a test case.
>
> The problem is that Aqua LaF shows the focused component with the glow on the
> border, hence when the border is not painted the foxus is not displayed. The
> idea is to paint the glowing
On Tue, 10 Aug 2021 09:41:11 GMT, Prasanta Sadhukhan
wrote:
>> The Nimbus look and feel ignores the configured background color of a
>> JTextPane and always uses white.
>> Every other look and feel tested (Metal, Motif, and Windows) correctly
>> honors the configured background color of a
On Tue, 10 Aug 2021 09:41:11 GMT, Prasanta Sadhukhan
wrote:
>> The Nimbus look and feel ignores the configured background color of a
>> JTextPane and always uses white.
>> Every other look and feel tested (Metal, Motif, and Windows) correctly
>> honors the configured background color of a
On Mon, 9 Aug 2021 03:17:20 GMT, Phil Race wrote:
> As per the bug comments, these tests fail too often on macOS arm.
> This will be too noisy for CI. So I would like to problem list them for
> mac-arm
test/jdk/ProblemList.txt line 532:
> 530:
> 531:
On Thu, 5 Aug 2021 04:59:18 GMT, Prasanta Sadhukhan
wrote:
> Will just stating null icon is unsupported do? I think in that case should we
> throw IAE?
This icon field is protected so technically it can be changed w/o constructor
and set method. So we have a choice:
1. Specify that the null
On Wed, 4 Aug 2021 20:10:50 GMT, Phil Race wrote:
>> These fields
>> - have not been used by the implementation since JDK8,
>> - are not supposed to be used by applications,
>> - have been deprecated for removal since JDK 9
>> - are non-standard, JDK not Java, classes
>> - very few clients are
On Wed, 4 Aug 2021 21:19:04 GMT, Alexey Ivanov wrote:
>> I think we should give this fix a chance...sInce this is solving 2
>> long-standing issue where setBackground() contract is not honoured plus
>> causing no regression to existing tests.
>> If we do find any testcase with "shape" in
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, 4 Aug 2021 09:02:25 GMT, Prasanta Sadhukhan
wrote:
> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called
> with null value. There are many places in JInternalFrame where
> getDesktopIcon() is accessed without null check which might cause NPE.
> Added null
On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote:
> This is a request to clean up a desktop module as was done in JDK-8233884 for
> "java.base" module.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes(
ore efficiently(x20 time faster) with use of
> java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
>
> The later variant also makes the code cleaner, as it is known not to throw
> UnsupportedEncodingException in contrary to the former variant.
>
> Tested b
On Tue, 3 Aug 2021 22:42:55 GMT, Alexey Ivanov wrote:
>> I am fine to do that, if there are no objections I can change the whole fix.
>
>>
>> I am fine to do that, if there are no objections I can change the whole fix.
>
> Modifying the entire changeset seems like an overkill.
> Using static
On Tue, 3 Aug 2021 06:25:07 GMT, Prasanta Sadhukhan
wrote:
>> In the linke above the
>> nimbusBlueGrey #a9b0be (169,176,190)
>> While the "EditorPane.background and TextPane.background" are:
>> TextPane.background #d6d9df (214,217,223)
>> EditorPane.background#d6d9df
On Tue, 3 Aug 2021 05:44:53 GMT, Prasanta Sadhukhan
wrote:
>> src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 25750:
>>
>>> (failed to retrieve contents of file, check the PR for context)
>> What is the difference between background and shape tags?
>
> I have looked at
>
On Mon, 2 Aug 2021 04:52:27 GMT, Prasanta Sadhukhan
wrote:
>> test/jdk/javax/swing/plaf/nimbus/TestNimbusJTextPaneColor.java line 74:
>>
>>> 72: if (frame != null) {
>>> 73: SwingUtilities.invokeAndWait(frame::dispose);
>>> 74: }
>>
>> `frame` is
On Mon, 2 Aug 2021 05:00:18 GMT, Prasanta Sadhukhan
wrote:
>> The Nimbus look and feel ignores the configured background color of a
>> JTextPane and always uses white.
>> Every other look and feel tested (Metal, Motif, and Windows) correctly
>> honors the configured background color of a
This is a request to clean up a desktop module as was done in JDK-8233884 for
"java.base" module.
In many places standard charsets are looked up via their names, for example:
absolutePath.getBytes("UTF-8");
This could be done more efficiently(x20 time faster) with use of
On Fri, 30 Jul 2021 18:26:56 GMT, Alexey Ivanov wrote:
> I believe it was an optimisation to make comparison as quick as possible.
> There are many places in Swing where property keys are compared as object
> identity rather than using `equals`. If this place is changed, probably all
> other
On Thu, 29 Jul 2021 11:44:31 GMT, Prasanta Sadhukhan
wrote:
> The Nimbus look and feel ignores the configured background color of a
> JTextPane and always uses white.
> Every other look and feel tested (Metal, Motif, and Windows) correctly honors
> the configured background color of a
On Fri, 30 Jul 2021 10:38:58 GMT, Prasanta Sadhukhan
wrote:
>> JComponent.setUIProperty method uses string identity check (==) rather than
>> string equality checks (.equals) when comparing against the property name.
>> This is suspicious since string identity and equality and equivalent only
On Tue, 27 Jul 2021 05:03:38 GMT, Tejpal Rebari wrote:
> Yes, https://bugs.openjdk.java.net/browse/JDK-8271315.
Thank you, looks fine.
-
PR: https://git.openjdk.java.net/jdk/pull/4903
On Mon, 26 Jul 2021 05:46:44 GMT, Tejpal Rebari wrote:
> Please review the following fix for JDK-18.
> This is revert of the fix for nimbus jtree renderer properties persist
> across L(https://bugs.openjdk.java.net/browse/JDK-8249674), This fixed
> caused nimbus jtree default tree cell
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 Fri, 16 Jul 2021 20:52:08 GMT, Weijun Wang wrote:
> This is the last part of Post JEP 411 refactoring that makes
> `@SuppressWarnings("removal")` more fine grained. This fix deals with all
> client libs annotations that cover more than 10K bytes of code.
After the requested change to the
On Fri, 16 Jul 2021 11:19:23 GMT, Alexander Zuev wrote:
>> Reducing the height of the analyzed area to get rid of the rounded edges
>> at the botom of the frame. Apparently shadow outside of it being
>> rendered by Mac OS X Big Sur inconsistently which gives random test
>> failures on M1 macs
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 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 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 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
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 Thu, 24 Jun 2021 04:39:12 GMT, Alexander Zuev wrote:
>> src/java.desktop/share/classes/javax/swing/JPasswordField.java line 634:
>>
>>> 632: Arrays.fill(password, getEchoChar());
>>> 633: String text = new String(password);
>>> 634: return new
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 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 Mon, 28 Jun 2021 15:43:35 GMT, Christoph Langer wrote:
>> Exclude test on Windows if VM is from a debug build.
>
> Christoph Langer has refreshed the contents of this pull request, and
> previous commits have been removed. The incremental views will show
> differences compared to the
On Wed, 2 Jun 2021 01:14:39 GMT, Sergey Bylokhov wrote:
> Some useful documentation was added to the JPasswordField.
This pull request has now been integrated.
Changeset: b2e9eb9e
Author: Sergey Bylokhov
URL:
https://git.openjdk.java.net/jdk/com
> Some useful documentation was added to the JPasswordField.
Sergey Bylokhov has updated the pull request incrementally with one additional
commit since the last revision:
Update JPasswordField.java
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/4296/files
-
On Thu, 3 Jun 2021 21:31:20 GMT, Sergey Bylokhov wrote:
>> Some useful documentation was added to the JPasswordField.
>
> Sergey Bylokhov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Update JPasswordField.ja
On Wed, 2 Jun 2021 01:14:39 GMT, Sergey Bylokhov wrote:
> Some useful documentation was added to the JPasswordField.
> _Mailing list message from [Alan Snyder](mailto:javali...@cbfiddle.com) on
> [swing-dev](mailto:swing-...@mail.openjdk.java.net):_
> How about:
> For s
On Thu, 3 Jun 2021 01:02:56 GMT, Sergey Bylokhov wrote:
>> Another way of phrasing it would be
>>
>> The text displayed in {@code JPasswordField} shows you that something was
>> typed but does not show the original characters.
>>
>> Note "that som
On Thu, 3 Jun 2021 00:57:02 GMT, Phil Race wrote:
>> So in case that wasn't clear, please change it to ny version
>
> Another way of phrasing it would be
>
> The text displayed in {@code JPasswordField} shows you that something was
> typed but does not show the original characters.
>
> Note
On Thu, 3 Jun 2021 00:16:28 GMT, Phil Race wrote:
>> Some useful documentation was added to the JPasswordField.
>
> src/java.desktop/share/classes/javax/swing/JPasswordField.java line 64:
>
>> 62: *
>> 63: * Warning: The text entered in {@code JPasswordField}
>> displays
>> 64: * something
On Wed, 2 Jun 2021 01:14:39 GMT, Sergey Bylokhov wrote:
> Some useful documentation was added to the JPasswordField.
The CSR is filed: https://bugs.openjdk.java.net/browse/JDK-8268149
Please take a look.
-
PR: https://git.openjdk.java.net/jdk/pull/4296
...placeholder...
-
Commit messages:
- Update JPasswordField.java
- Update JPasswordField.java
Changes: https://git.openjdk.java.net/jdk/pull/4296/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4296=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8268087
Stats: 8
On Mon, 24 May 2021 18:55:38 GMT, rajat mahajan
wrote:
> Summary: Removed redundant usage of final modifier from static methods in
> javax.swing.Utilities, since static methods are not inherited and cannot be
> overridden.
This is not a noop fix, the final keyword in the static method
On Fri, 7 May 2021 17:53:49 GMT, Alexander Zuev wrote:
>> This comment is also about the case of not fetching icons of sizes smaller
>> than requested size.
>
> Sorry, missed that in my latest fix. Indeed there is no legitimate ways to
> set scaling factor to less than 100% on Windows so yes,
On Thu, 27 May 2021 16:38:02 GMT, Alexander Zuev wrote:
>> Is this requirement is so important? can we return an MRI(same as on
>> Windows) which will have just one resolution? Otherwise what the user should
>> do if the requested size was 32x32 but returned image will be 21x21? Paint
>> the
On Wed, 26 May 2021 21:39:19 GMT, Alexander Zuev wrote:
>> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 87:
>>
>>> 85: }
>>> 86:
>>> 87: if (implComplete && icon.getIconWidth() != size) {
>>
>> Why the size of the returned images might be
On Wed, 26 May 2021 16:52:38 GMT, Alexander Zuev wrote:
>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Fixed small errors
>Adjustments in the test
> - Grammar fix in
1 - 100 of 1923 matches
Mail list logo
