| HTML element.

Thank you very much in advance,
Alexey

On 22.12.2015 12:54, Rajeev Chamyal wrote:
> Hello All,
>
> Please review the following fix for Jdk9:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8078489
>
> Webrev:http://cr.openjdk.java.net/~rchamyal/8078489/webrev.00/ 
> 
>
> Issue: Jspinner text in Aqua LAF is not following Right to left 
> component orientation.
>
> Cause: Code for JSpinner Component orientation is missing.
> Fix: Updated the property change listener of Aqua LAF to update editor 
> text orientation.
> Regards,
> Rajeev Chamyal
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alexey.ivanov at oracle.com  Wed Dec 23 13:57:16 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 23 Dec 2015 16:57:16 +0300
Subject:  Review request for JDK-4769772
 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong
 state
In-Reply-To: <567AA5A5.3090901@oracle.com>
References: <34136115-bd25-43f6-bbdd-c98bc1dbfe17@default>
	<567AA5A5.3090901@oracle.com>
Message-ID: <567AA83C.9080308@oracle.com>

Hi Rajeev,

One more comment:
You should call dispose() in finally block in main so that the frame is 
closed automatically if the test fails.

Regards,
Alexey

On 23.12.2015 16:46, Alexey Ivanov wrote:
> Hi Rajeev,
>
> There's a potential NullPointerException in this line of 
> BasicInternalFrameUI.java:
>     if(value.equals(Boolean.FALSE))
>
> I suggest eliminating it using this construct:
>     if (Boolean.FALSE.equals(value))
>
> This way the code is safer.
>
>
> Can the test be simplified? Is it really required to create menu and 
> use robot to invoke commands?
> Wouldn't it be enough to programmatically add minimized internal frame 
> and then check its properties?
>
> JFrame in test should also be instantiated on EDT, in createUI() method.
>
>
> And a general recommendation to follow Java Coding Style [1] and in 
> particular to add a space [2] after 'if',  after comma in argument 
> lists, and after cast operator.
>
> Regards,
> Alexey
>
> [1] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
> [2] 
> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#682
>
> On 18.12.2015 11:44, Rajeev Chamyal wrote:
>> Hello All,
>>
>> Please review the following fix for Jdk9:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-4769772
>>
>> Webrev:http://cr.openjdk.java.net/~rchamyal/4769772/webrev.00/ 
>> 
>>
>> Issue: Iconifying a frame before adding it to desktop pane is not 
>> working.
>>
>> Cause: Setting setIcon property of a JInternalFrame before addition 
>> to desktop pane fails to find the desktop as a result its always in 
>> maximized state.
>> Fix: Added method to check if frame is already iconified before 
>> addition.
>> Verified the fix on windows,Ubuntu and Mac with all layouts.
>> Also, removed unused imports from JDesktopPane.java as part of fix.
>> Regards,
>> Rajeev Chamyal
>>
>

From alexandr.scherbatiy at oracle.com  Wed Dec 23 13:59:27 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 23 Dec 2015 16:59:27 +0300
Subject:  Review request for 8015748: JProgressbar with Aqua
 LaF ignores
 JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
 call
In-Reply-To: 
References: 
Message-ID: <567AA8BF.5030407@oracle.com>

An HTML attachment was scrubbed...
URL: 

From alexandr.scherbatiy at oracle.com  Wed Dec 23 14:02:56 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 23 Dec 2015 17:02:56 +0300
Subject:  Review request for 8016665: [macosx] JComponent
 behaviour doesn't comply API documentation (setComponentOrientation method),
 Aqua LAF
In-Reply-To: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
References: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
Message-ID: <567AA990.5080806@oracle.com>

An HTML attachment was scrubbed...
URL: 

From alexandr.scherbatiy at oracle.com  Wed Dec 23 14:14:04 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 23 Dec 2015 17:14:04 +0300
Subject:  Review request for JDK-8145896 JInternalFrame
 setMaximum before adding to desktop throws null pointer exception
In-Reply-To: 
References: 
Message-ID: <567AAC2C.4060203@oracle.com>

An HTML attachment was scrubbed...
URL: 

From roger.riggs at oracle.com  Wed Dec 23 14:28:58 2015
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 23 Dec 2015 09:28:58 -0500
Subject:  Reviews in plain text?
In-Reply-To: <567AA696.60208@oracle.com>
References: <572f1e83-752d-41a9-be86-95084234bc35@default>
	<567AA696.60208@oracle.com>
Message-ID: <567AAFAA.9050304@oracle.com>

Hi,

Each webrev includes the text patch,  follow the jdk.patch link in the 
header.

Webrev is the normal mechanism for code reviews and provides several 
different
views of the original and modifications.

Roger

On 12/23/15 8:50 AM, Alexey Ivanov wrote:
> Hi Rajeev,
>
> Could you please create code reviews in plain text format or at least 
> not as preformatted HTML text?
> It's very inconvenient to scroll the message horizontally because the 
> text does not wrap automatically in || HTML element.
>
> Thank you very much in advance,
> Alexey
>
> On 22.12.2015 12:54, Rajeev Chamyal wrote:
>> Hello All,
>>
>> Please review the following fix for Jdk9:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078489
>>
>> Webrev:http://cr.openjdk.java.net/~rchamyal/8078489/webrev.00/ 
>> 
>>
>> Issue: Jspinner text in Aqua LAF is not following Right to left 
>> component orientation.
>>
>> Cause: Code for JSpinner Component orientation is missing.
>> Fix: Updated the property change listener of Aqua LAF to update 
>> editor text orientation.
>> Regards,
>> Rajeev Chamyal
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Wed Dec 23 14:41:51 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 23 Dec 2015 17:41:51 +0300
Subject:  [9] Review request for 8132119 Provide public API
 for text related methods in SwingUtilities2
In-Reply-To: <5669D379.5070007@oracle.com>
References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com>
	<55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com>
	<5655D3AB.9050503@oracle.com> <5668051E.7090401@oracle.com>
	<5668E226.5000604@oracle.com> <5669646E.4070305@oracle.com>
	<566986FD.9020207@oracle.com> <5669D379.5070007@oracle.com>
Message-ID: <567AB2AF.7040106@oracle.com>

+1
On 10/12/15 22:33, Alexey Ivanov wrote:
> Hi Alexandr,
>
> The updated code looks fine to me.
>
> Thanks,
> Alexey
>
> On 10.12.2015 17:06, Alexander Scherbatiy wrote:
>>
>>  Hello,
>>
>>  Could you review the updated fix:
>>    http://cr.openjdk.java.net/~alexsch/8132119/webrev.04/
>>
>> On 12/10/2015 2:39 PM, Alexey Ivanov wrote:
>>> Hi Alexandr,
>>>
>>> I suggest using {@code underlinedIndex} in this sentence:
>>>
>>> * The {@code underlinedIndex} parameter points to a char value
>>> (Unicode code unit) in the
>>> * given string.
>>>
>>> in the Javadoc for drawStringUnderlineCharAt().
>>>
>>>
>>> And I suggest using "fits" instead of "can fit" in @return for
>>> getClippedString() and rephrasing the conditions where empty string
>>> is returned:
>>>
>>> * @return the clipped string that fits in the provided space, an empty
>>> *         string if the given string argument is {@code null} or empty.
>>
>>    The fix is updated according to the provided comments.
>>
>>    Thanks,
>>    Alexandr.
>>>
>>>
>>> Regards,
>>> Alexey
>>>
>>> On 10.12.2015 5:23, Alexander Scherbatiy wrote:
>>>> Hello,
>>>>
>>>> Could you review the updated fix:
>>>>   http://cr.openjdk.java.net/~alexsch/8132119/webrev.03/
>>>>
>>>> - methods description is updated to mention used text properties and
>>>> anti-aliasing hints from the provided component
>>>> - the drawStringUnderlineCharAt method description is updated
>>>> - @since tag is added for the drawString() method
>>>> - the description that some parameters may/must not be null is added
>>>> - the test is updated to call the methods on EDT
>>>> - the test is updated to check passed null arguments
>>>>
>>>> On 09/12/15 14:40, Alexey Ivanov wrote:
>>>>> Hi Alexandr,
>>>>>
>>>>> Shouldn't drawString() also have @since tag?
>>>>>
>>>>>
>>>>> Could you please also clarify whether underlinedIndex in
>>>>> drawStringUnderlineCharAt refers to the char index in the string?
>>>>>
>>>>> The statement
>>>>> * The underlined index refers to char values (Unicode code units).
>>>>> makes it unclear: underlinedIndex is an *index* or a *char*
>>>>> (Unicode code point).
>>>>
>>>>  I updated it to "The underlined index points to a char value
>>>> (Unicode code unit) in the given string."
>>>>  The 'refers' word was used for a value at the given index.
>>>>  However, I am not sure that the new variant is better.
>>>>>
>>>>>
>>>>> * Nothing is drawn for null string. No character is underlined for the
>>>>> * index {@code < 0}, {@code >=} than the string width or if the
>>>>> char value
>>>>> * specified at the given index is in the low-surrogate range.
>>>>>
>>>>> I think it will be better to spell comparison operators, I mean to
>>>>> use  "greater than" rather than ">=". And "length" must be used
>>>>> instead of "width".
>>>>>
>>>>> I propose the following text:
>>>>>
>>>>> No character is underlined if the index is negative or greater than
>>>>> the string length or if the char value specified at the given index
>>>>> is in the low-surrogate range.
>>>>>
>>>>> For the first part of condition, you can add clarification in
>>>>> parenthesis: {@code index < 0 || index >= string.length()}.
>>>>  Updated.
>>>>>
>>>>>
>>>>> For consistency, please remove the full stop in @return tag in
>>>>> description of getClippedString.
>>>>
>>>> Updated.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>>>
>>>>> Regards,
>>>>> Alexey
>>>>>
>>>>> On 25.11.2015 18:28, Alexandr Scherbatiy wrote:
>>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.02
>>>>>>
>>>>>> The javadoc references for the #drawStringUnderlineCharAt and
>>>>>> #getClippedString methods are moved after parameters description.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>>
>>>>>> 14.09.2015 17:39, Alexander Scherbatiy ?????:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/
>>>>>>>
>>>>>>> I tried to use Utilities.drawStringUnderlineCharAt(...) with
>>>>>>> chars that have
>>>>>>> - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01)
>>>>>>> The whole glyph is underlined.
>>>>>>> - 2 characters: 1 glyph mapping (supplementary char U+10400)
>>>>>>>
>>>>>>> The char value specified the the underlined index should point to
>>>>>>> the high-surrogate range of a supplementary character.
>>>>>>> I updated the javadoc for the
>>>>>>> Utilities.drawStringUnderlineCharAt(...) method to:
>>>>>>> -----------------------------
>>>>>>> /**
>>>>>>> * Draws the given string at the specified location underlining
>>>>>>> * the specified character.
>>>>>>> * 
>>>>>>> * The underlined index refers to char values (Unicode code units).
>>>>>>> * If the char value specified at the given underlined index is in
>>>>>>> * the high-surrogate range and the char value at the following
>>>>>>> index is in
>>>>>>> * the low-surrogate range then the supplementary character
>>>>>>> corresponding
>>>>>>> * to this surrogate pair is underlined.
>>>>>>> * 

>>>>>>> * Nothing is drawn for null string. No character is underlined
>>>>>>> for the
>>>>>>> * index {@code < 0}, {@code >=} than the string width or if the
>>>>>>> char value
>>>>>>> * specified at the given index is in the low-surrogate range.
>>>>>>> -----------------------------
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>> On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote:
>>>>>>>> On 9/2/2015 8:09 PM, Phil Race wrote:
>>>>>>>>> I don't remember or know how Swing resolves this but the
>>>>>>>>> measurement ones
>>>>>>>>> are not reliable since they do not take a Graphics context, so
>>>>>>>>> you cannot
>>>>>>>>> measure the string properly. You need a FontRenderContext to
>>>>>>>>> measure.
>>>>>>>>
>>>>>>>> The provided methods use
>>>>>>>> SwingUtilities2.getFontRenderContext(JComponent) method which
>>>>>>>> returns the FontRenderContext associated with the component.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> So as it stands these APIs do not appear suitable to be made
>>>>>>>>> public as they
>>>>>>>>> are not reliable.
>>>>>>>>>
>>>>>>>>> Whilst I could look at the code, if I instead just look at the
>>>>>>>>> API, I am scratching my
>>>>>>>>> head over :-
>>>>>>>>>
>>>>>>>>> public static void drawString(JComponent c, Graphics g, String
>>>>>>>>> text, int x, int y)
>>>>>>>>>
>>>>>>>>> Here you provide the Graphics *and* the Component.
>>>>>>>>> And it says the JComponent may be null.
>>>>>>>>> So I am supposing that there is optional information that may
>>>>>>>>> be pulled from the
>>>>>>>>> JComponent regarding rendering mode ?
>>>>>>>>
>>>>>>>> The optional information provided by the component is:
>>>>>>>> - java.awt.font.NumericShaper
>>>>>>>> - java.awt.font.FontRenderContext
>>>>>>>> - antialiasing hints
>>>>>>>>
>>>>>>>>>
>>>>>>>>> drawStringUnderlineCharAt(..) probably needs to explain if the
>>>>>>>>> index is code point
>>>>>>>>> or UTF16 char index and what happens if there is not 1:1 code
>>>>>>>>> point:glyph mapping.
>>>>>>>> I will update this.
>>>>>>>>>
>>>>>>>>> Are we sure that (any of) these really ought/need to be public
>>>>>>>>> - particularly given the
>>>>>>>>> resolution of https://bugs.openjdk.java.net/browse/JDK-6302464
>>>>>>>>
>>>>>>>> These methods are used by JDK L&Fs to draw text. The initial
>>>>>>>> request was to provide public methods that can be used by a
>>>>>>>> custom L&F to draw strings consistently with other L&Fs.
>>>>>>>>
>>>>>>>> They are also designed to properly render text for printing. To
>>>>>>>> do that they use call to internal ProxyPrintGraphics class to
>>>>>>>> obtain the print graphics context.
>>>>>>>>
>>>>>>>> Even if printing staff will be public, these methods are just
>>>>>>>> utility methods (in the same way as other text methods in the
>>>>>>>> javax.swing.text.Utilities class) that help easily to draw and
>>>>>>>> print text in the same way as JDK L&Fs do that.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -phil.
>>>>>>>>>
>>>>>>>>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Could you review the fix:
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8132119/webrev.00
>>>>>>>>>>
>>>>>>>>>> The suggested drawString, drawStringUnderlineCharAt,
>>>>>>>>>> clipStringIfNecessary, and stringWidth methods are
>>>>>>>>>> added to the javax.swing.text.Utilities class.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-- 
Best regards, Sergey.

From alexandr.scherbatiy at oracle.com  Wed Dec 23 14:43:02 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 23 Dec 2015 17:43:02 +0300
Subject:  Review request for JDK-8145060 Minimizing a
 JInternal frame not shifting focus to frame below it
In-Reply-To: <6e594a8b-fc5b-4d4d-abfa-ed54d5718323@default>
References: <6e594a8b-fc5b-4d4d-abfa-ed54d5718323@default>
Message-ID: <567AB2F6.3090202@oracle.com>

An HTML attachment was scrubbed...
URL: 

From alexandr.scherbatiy at oracle.com  Wed Dec 23 14:46:45 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 23 Dec 2015 17:46:45 +0300
Subject:  Review request for JDK-8078489 JSpinner using
 SpinnerNumberModel doesn't honor orientation flag
In-Reply-To: <572f1e83-752d-41a9-be86-95084234bc35@default>
References: <572f1e83-752d-41a9-be86-95084234bc35@default>
Message-ID: <567AB3D5.3080008@oracle.com>

An HTML attachment was scrubbed...
URL: 

From matthijs at stdin.nl  Thu Dec 10 09:24:15 2015
From: matthijs at stdin.nl (Matthijs Kooijman)
Date: Thu, 10 Dec 2015 10:24:15 +0100
Subject:  Incorrect / unexpected handling of keybindings using
 non-standard keyboard layouts
Message-ID: <20151210092415.GD2078@login.tika.stderr.nl>

(Please keep my CC'd, I'm not subscribed to the list)

Hi folks,

while going over the Java keybinding code (trying to solve a different
problem), I found some strangeness in how KeyboardManager and JComponent
handle keystrokes. In particular, they try to match any registered
keybindings to both the normal keycode, as well as the extended keycode
from the KeyEvent.

According to the documentation, the normal keycode relates to the
physical position of the key on the keyboard and is not influenced by
the keyboard layout. The extended keycode relates to the key pressed,
according to the current keyboard layout. When a US QWERTY layout is
used, both keycodes will be identical.

Matching the extended keycode makes sense, if a keybinding is CTRL-Q,
then you want it to work whenever you press the key labeled "Q" on the
keyboard. Matching the normal keycode makes less sense to me - why would
the "key-that-is-Q-on-a-QWERTY-keyboard" trigger a Ctrl-Q binding? I
presume this is a sort of backward compatibility feature, but I wonder
if the application should be in control of this? In any case, in the
current implementation, this approach causes a problem, which I will
describe below.

Handling of keybindings happens by letting each JComponent track a
number of "input maps", mapping keystrokes to actions. There is a map
for when the component is focused, when it is the ancestor of a focused
component, and when the component is in a focused window. The first two
mappings are resolved by traversing the component hierarchy and letting
each component check its maps, the latter map is resolved by
KeyboardManager, which keeps one big map of bindings for each window.

In summary, resolving keypress works like this:

 1. SwingUtilities.processKeyBindings() / JComponent.processKeyBindings():
    Starting with the focused component, going upwards, each component
    checks its keybindings for the current keyEvent. Each component first
    checks against the extended keycode, then the normal keycode.

 2. KeyboardManager.fireKeyboardAction(), via JComponent.processKeyBindingsForAllComponents():
    In the map of WHEN_IN_FOCUSED_WINDOW bindings kept by
    KeyboardManager for the current window, the key event is looked up
    and, if found, forwarded to the right JComponent. Again, this checks
    the extended keycode first, then the normal keycode.

 3. KeyboardManager.fireKeyboardAction() / JMenuBar.processKeyBinding():
    For each JMenuBar in the current window (tracked in a separate map
    by KeyboardManager), JMenuBar.processKeyBinding() is called, which
    recurses through the menu hierarchy to check the
    WHEN_IN_FOCUSED_WINDOW keybindings of each menu item. I assume this
    is needed because children of JMenus are not added to the hierarchy
    directly, but through a (detached) JPopupMenu instance.

Note that in step 1, it actually seems like the component hierarchy is
traversed in both SwingUtilities.processKeyBindings() as well as in
JComponent.processKeyBindings(), which seems like it is doing double
work (and applies the WHEN_FOCUSED maps even to ancestors of the focused
component). However, this doesn't seem relevant to the subject of this
mail, so I'll not investigate this further here.

In my examples below, I will be using the Belgian AZERTY layout. For
these examples, the only relevant changes are that the Q is swapped with
the A, and the W is swapped with the Z.

This resolution process has, AFAICS, two problems:

 1. A given shortcut can be triggered by two keys. For example, when
    using the Belgian AZERTY layout, a Ctrl-Q shortcut will be triggered
    by both CTRL-Q (matching the extended keycode) as well as by CTRL-A
    (the key in the same place as the Q on a QWERTY keyboard, by
    matching the normal keycode).

    I guess this is really intended as a feature, but it might be
    confusing. One unintended side effect seems to be that, on OSX, some
    keyboard shortcuts (such as Ctrl-, to open preferences) are handled
    by the windowing system and passed to the application using a
    seperate notification (e.g. "Open your preferences"), in *addition*
    to passing the original keystroke to the application. This was
    reported in https://bugs.openjdk.java.net/browse/JDK-8019498 where
    a keybinding for Ctrl-M was triggered by pressing Ctrl-, in
    *addition* to opening the preferences. Note that the preferences
    event handling uses some OSX specific code, e.g.
    http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c021b855f51e/src/java.desktop/macosx/classes/com/apple/eawt/_AppEventHandler.java#l192

 2. The second problem is that a component that is checked earlier in
    the resolution order can "hijack" keystrokes from later components.
    Normally, this is intentional - WHEN_FOCUSED and
    WHEN_ANCESTOR_OF_FOCUSED_COMPONENTS favor the focused component, or
    components close to them, and for WHEN_IN_FOCUSED_WINDOW bindings,
    no duplicate bindings should exist.

    However, because each step in the resolution matches both the
    extended and normal keycode, a component can hijack the even using
    the "backward compatible" normal keycode matching, even when a later
    component would have succesfully matched against the extended
    keycode.

    For example, when using a Belgian AZERTY layout, a button in the
    window binds Ctrl-Z, and a menu item binds Ctrl-W, you would expect
    both keypresses to trigger the corresponding action. However, in
    practice the button will match the Ctrl-W keypress too (by matching
    the normal keycode), preventing the menu bar (which comes later in
    the resolution procedure) from matching the keypress, so both
    Ctrl-W and Ctrl-Z trigger the button.

The latter problem is of course the bigger one. The obvious solution is
to run through the entire resolution twice, once matching the extended
keycode, then once more matching the normal keycode. To fix the first
problem too, the last step could perhaps be made optional, or perhaps
KeyStroke can be modified to match the normal keycode, extended keycode,
or both. Not sure if this can be done in a compatible way, though, since
some of the methods involved are public or protected.

To confirm my analisis, I wrote a small testcase (inline below, and at
https://gist.github.com/matthijskooijman/4d016e7a9e3fb07d0699). It shows
both of the problems outlined above. It contains a menu item bound to
Ctrl-Q, which triggers on both Ctrl-Q and Ctrl-A when using the Belgian
AZERTY layout.  It also contains a button binding to Ctrl-Z, which
prevents a menu item bound to Ctrl-W from working when using the Belgian
AZERTY layout. I have tested this on Linux, by selecting a different
keyboard layout ("Input source") in the Gnome keyboard settings (without
actually switching the keyboard).

There seem to be a few related bug reports already. I suspect that most
or all of these are caused by this problem, though not all of them have
enough details to be sure.

https://bugs.openjdk.java.net/browse/JDK-8087915
https://bugs.openjdk.java.net/browse/JDK-8022079
https://bugs.openjdk.java.net/browse/JDK-8019498
https://bugs.openjdk.java.net/browse/JDK-8141096

Interestingly, all of these reports are about OSX, but I'm pretty sure
the problem I'm describing will occur on all platforms, being caused by
platform-independent code. There might be additional OSX-specific
problems, of course, but I do not have access to OSX to test.

Gr.

Matthijs

import javax.swing.*;
import java.awt.event.*;
import java.awt.*;

class Item extends JMenuItem {
    public void addNotify() {
        System.out.println("Add\n");
    }
    public Item(String s) { super(s); }
}

public class Test {
    public static void main(String[] args) {
        SwingUtilities.invokeLater(() -> {
            JFrame frame = new JFrame();
            JMenuBar bar = new JMenuBar();
            JButton button = new JButton("Button Ctrl-Z");
            JTextArea text = new JTextArea("");
            JMenu menu = new JMenu("Menu");
            JMenuItem item1 = new Item( "Item 1" );
            JMenuItem item2 = new JMenuItem( "Item 2" );

            item1.addActionListener((ActionEvent e) -> text.append("Menuitem 1\n"));
            item2.addActionListener((ActionEvent e) -> text.append("Menuitem 2\n"));
            button.addActionListener((ActionEvent e) -> text.append("Button click\n"));

            item1.setAccelerator(KeyStroke.getKeyStroke('Q', KeyEvent.CTRL_MASK));
            item2.setAccelerator(KeyStroke.getKeyStroke('W', KeyEvent.CTRL_MASK));
            KeyStroke keyStroke = KeyStroke.getKeyStroke('Z', KeyEvent.CTRL_MASK);
            ActionListener action = (ActionEvent) -> text.append("Button key\n");
            button.registerKeyboardAction(action, "action", keyStroke, JComponent.WHEN_IN_FOCUSED_WINDOW);

            menu.add(item1);
            menu.add(item2);
            bar.add(menu);

            text.setEnabled(false);
            frame.setLayout(new BorderLayout());
            frame.add(button, BorderLayout.SOUTH);
            frame.add(text, BorderLayout.CENTER);
            frame.setJMenuBar(bar);
            frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
            frame.setSize(200,200);
            frame.setVisible(true);
        });
    }
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 

From alexey.ivanov at oracle.com  Wed Dec 23 14:58:41 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 23 Dec 2015 17:58:41 +0300
Subject:  Reviews in plain text?
In-Reply-To: <567AAFAA.9050304@oracle.com>
References: <572f1e83-752d-41a9-be86-95084234bc35@default>
	<567AA696.60208@oracle.com> <567AAFAA.9050304@oracle.com>
Message-ID: <567AB6A1.7090004@oracle.com>

I am sorry for broadcasting, I meant to send the message privately but 
apparently I forgot to remove swing-dev from addressee list.

Roger,

I'm talking about email message format. The text is usually wrapped to 
the mail client window width, but if the text is placed in 
 HTML 
element, it does not wrap. If a line of text is quite long, one has to 
scroll right to read the rest of the line, then scroll to the left to 
read the following paragraph?

Webrevs are the standard. I know I can use jdk.patch link to download 
the patch suitable for feeding to ?patch? command.

Regards,
Alexey

On 23.12.2015 17:28, Roger Riggs wrote:
> Hi,
>
> Each webrev includes the text patch,  follow the jdk.patch link in the 
> header.
>
> Webrev is the normal mechanism for code reviews and provides several 
> different
> views of the original and modifications.
>
> Roger
>
> On 12/23/15 8:50 AM, Alexey Ivanov wrote:
>> Hi Rajeev,
>>
>> Could you please create code reviews in plain text format or at least 
>> not as preformatted HTML text?
>> It's very inconvenient to scroll the message horizontally because the 
>> text does not wrap automatically in || HTML element.
>>
>> Thank you very much in advance,
>> Alexey
>>
>> On 22.12.2015 12:54, Rajeev Chamyal wrote:
>>> Hello All,
>>>
>>> Please review the following fix for Jdk9:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078489
>>>
>>> Webrev:http://cr.openjdk.java.net/~rchamyal/8078489/webrev.00/ 
>>> 
>>>
>>> Issue: Jspinner text in Aqua LAF is not following Right to left 
>>> component orientation.
>>>
>>> Cause: Code for JSpinner Component orientation is missing.
>>> Fix: Updated the property change listener of Aqua LAF to update 
>>> editor text orientation.
>>> Regards,
>>> Rajeev Chamyal
>>>
>>
>

From Sergey.Bylokhov at oracle.com  Wed Dec 23 15:37:41 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 23 Dec 2015 18:37:41 +0300
Subject:  Review request for JDK-8078489 JSpinner using
 SpinnerNumberModel doesn't honor orientation flag
In-Reply-To: <572f1e83-752d-41a9-be86-95084234bc35@default>
References: <572f1e83-752d-41a9-be86-95084234bc35@default>
Message-ID: <567ABFC5.2040807@oracle.com>

Hi, Rajeev.
A few notes:
  - the cast in the "if (o != (ComponentOrientation) e.getOldValue())" 
is not necessary.
  - Is it possible to cover all look and feels in the test?
  - Why the test is for osx only?

On 22/12/15 12:54, Rajeev Chamyal wrote:
> Hello All,
>
> Please review the following fix for Jdk9:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8078489
>
> Webrev:http://cr.openjdk.java.net/~rchamyal/8078489/webrev.00/
>
> Issue: Jspinner text in Aqua LAF is not following Right to left
> component orientation.
>
> Cause: Code for JSpinner Component orientation is missing.
>
> Fix: Updated the property change listener of Aqua LAF to update editor
> text orientation.
>
> Regards,
>
> Rajeev Chamyal
>

-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Dec 23 19:43:53 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 23 Dec 2015 11:43:53 -0800
Subject:  [9] Review Request for 8081722: Provide public API
 for file hierarchy provided by sun.awt.shell.ShellFolder
In-Reply-To: <56543585.60401@oracle.com>
References: <562E2FD1.1070301@oracle.com> <563265D5.8010205@oracle.com>
	<5637C2DD.6060801@oracle.com> <56543585.60401@oracle.com>
Message-ID: <567AF979.1090903@oracle.com>

I think this version looks OK. Don't forget it needs a CCC ..

-phil.

On 11/24/2015 02:01 AM, Semyon Sadetsky wrote:
>
>
> On 11/2/2015 11:09 PM, Sergey Bylokhov wrote:
>> On 29.10.15 21:30, Phil Race wrote:
>>> We should specify what happens if you pass in to get(String)
>>> a) null
>>> b) an unrecognised name.
>>>
>>> Would it make sense to define string constants on FileSystemView
>>> as otherwise people have to spell these exactly right without compiler
>>> help ?
>>>
>>> Also I expect (hope!) that we do not assert any privileges here so 
>>> there
>>> will be a SecurityException if the caller does not have the necessary
>>> permissions.
>>> That should be documented.
>>>
>>> I find it odd that isLink(File) catches FNFE and just returns "false"
>>> like this
>>> was a normal file. Why is that ? In fact I find it particularly odd 
>>> since
>>> getLinkLocation() *does* throw FNFE if it does not exist.
>>
>>     I guess the new code should follow the rules which are used by 
>> other methods in the same class, most of them catch FNFE and return 
>> some default value. Also most of them returns default value if the 
>> passed File is null. Anyway I think that NPE is better than IAE. At 
>> least we should discuss this.
> Could you explain why NPE is better? I supposed in case of an 
> incorrect method usage IAE is more precise than generic NPE.
> The FNFE is used in some methods of the class. I think that is 
> justified if the linked file is not found. In other cases it is caught.
>>
>> I am not sure why this methods are static unlike old/others methods().
> I agree, we should be following the class "style", so I have removed 
> static modifiers.
> The updated webrev: 
> http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.02/
>>
>> public static Object get(String key) {}
>>     Probably this method too flexible? What kind of use case for this 
>> method inside the users application? How the user will know which 
>> parameters to use in a cross-platform manner?
>>
>> For example "fileChooserDefaultFolder" property already covered by 
>> FileSystemView.getDefaultDirectory(), the "roots" is covered by 
>> getRoots().
> I don't think that we should elaborate a new Shell API in this fix, 
> because we initially aimed to make the minimal change we can to 
> support NetBeans ShellFolder extension.  We did a poll on the public 
> alias which showed nobody else need this API to be opened.
>>
>>
>>>
>>> Also the docs casually say
>>> "a shell interpreted link" and "platform shell" without explaining
>>> what they mean by a shell. Should this term be used at all or
>>> should the docs describe this in some other words ?
>>>
>>> getLinkLocation says
>>>
>>> "Returns a file linked to the specified file if the specified file"
>>>
>>> What that reads like to me is that you get back a link if
>>> you pass in a regular file, whereas (I believe) you mean
>>> the opposite.
>>>
>>> I think you mean :
>>> "Returns the regular file referenced by the specified link file"
>>>
>>> I also note that one of the uses we located was of
>>> ShellFolder.getShellFolder(File)
>>> That internal API returns a ShellFolder but it we expose that it would
>>> have to
>>> be the java.io.File superclass I expect.
>>>
>>> -phil.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -phil.
>>>
>>>
>>> On 10/26/2015 06:51 AM, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8081722
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.00
>>>>
>>>> As the solution it is suggested to have 3 new static methods in the
>>>> javax.swing.filechooser.FileSystemView class. Those methods proxy
>>>> sun.awt.shell.ShellFolder calls and it is enough to cover NetBeans
>>>> request. getShellFolder() method is not added because it returns the
>>>> ShellFolder instance which is not for public use under the proposed
>>>> approach.
>>>> The CCC request will be rework when the fix is approved.
>>>>
>>>> --Semyon
>>>
>>
>>
>

From rajeev.chamyal at oracle.com  Thu Dec 24 05:18:45 2015
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Wed, 23 Dec 2015 21:18:45 -0800 (PST)
Subject:  Review request for JDK-8078489 JSpinner using
 SpinnerNumberModel doesn't honor orientation flag
In-Reply-To: <567ABFC5.2040807@oracle.com>
References: <572f1e83-752d-41a9-be86-95084234bc35@default>
	<567ABFC5.2040807@oracle.com>
Message-ID: <41248751-f4be-4f59-824d-045986161b3c@default>

Hello Sergey,

Thanks for the review.
The issues is reproducible with mac Aqua LAF only with other LAF/platforms issue is not reproducible.
I have updated webrev as per review comments.

http://cr.openjdk.java.net/~rchamyal/8078489/webrev.01/

Regards,
Rajeev Chamyal

-----Original Message-----
From: Sergey Bylokhov 
Sent: 23 December 2015 21:08
To: Rajeev Chamyal; Alexander Scherbatiy; Prasanta Sadhukhan; swing-dev at openjdk.java.net
Subject: Re: Review request for JDK-8078489 JSpinner using SpinnerNumberModel doesn't honor orientation flag

Hi, Rajeev.
A few notes:
  - the cast in the "if (o != (ComponentOrientation) e.getOldValue())" 
is not necessary.
  - Is it possible to cover all look and feels in the test?
  - Why the test is for osx only?

On 22/12/15 12:54, Rajeev Chamyal wrote:
> Hello All,
>
> Please review the following fix for Jdk9:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8078489
>
> Webrev:http://cr.openjdk.java.net/~rchamyal/8078489/webrev.00/
>
> Issue: Jspinner text in Aqua LAF is not following Right to left 
> component orientation.
>
> Cause: Code for JSpinner Component orientation is missing.
>
> Fix: Updated the property change listener of Aqua LAF to update editor 
> text orientation.
>
> Regards,
>
> Rajeev Chamyal
>

--
Best regards, Sergey.

From rajeev.chamyal at oracle.com  Thu Dec 24 07:19:56 2015
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Wed, 23 Dec 2015 23:19:56 -0800 (PST)
Subject:  Review request for JDK-4769772
 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong
 state
In-Reply-To: <567AA83C.9080308@oracle.com>
References: <34136115-bd25-43f6-bbdd-c98bc1dbfe17@default>
	<567AA5A5.3090901@oracle.com> <567AA83C.9080308@oracle.com>
Message-ID: 

Hello Alexey,

Thanks for the review.
I have updated webrev as per review comments.

http://cr.openjdk.java.net/~rchamyal/4769772/webrev.01/

Regards,
Rajeev Chamyal

-----Original Message-----
From: Alexey Ivanov 
Sent: 23 December 2015 19:27
To: swing-dev at openjdk.java.net
Subject: Re:  Review request for JDK-4769772 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong state

Hi Rajeev,

One more comment:
You should call dispose() in finally block in main so that the frame is closed automatically if the test fails.

Regards,
Alexey

On 23.12.2015 16:46, Alexey Ivanov wrote:
> Hi Rajeev,
>
> There's a potential NullPointerException in this line of
> BasicInternalFrameUI.java:
>     if(value.equals(Boolean.FALSE))
>
> I suggest eliminating it using this construct:
>     if (Boolean.FALSE.equals(value))
>
> This way the code is safer.
>
>
> Can the test be simplified? Is it really required to create menu and 
> use robot to invoke commands?
> Wouldn't it be enough to programmatically add minimized internal frame 
> and then check its properties?
>
> JFrame in test should also be instantiated on EDT, in createUI() method.
>
>
> And a general recommendation to follow Java Coding Style [1] and in 
> particular to add a space [2] after 'if',  after comma in argument 
> lists, and after cast operator.
>
> Regards,
> Alexey
>
> [1] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
> [2]
> http://www.oracle.com/technetwork/java/javase/documentation/codeconven
> tions-141388.html#682
>
> On 18.12.2015 11:44, Rajeev Chamyal wrote:
>> Hello All,
>>
>> Please review the following fix for Jdk9:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-4769772
>>
>> Webrev:http://cr.openjdk.java.net/~rchamyal/4769772/webrev.00/
>> 
>>
>> Issue: Iconifying a frame before adding it to desktop pane is not 
>> working.
>>
>> Cause: Setting setIcon property of a JInternalFrame before addition 
>> to desktop pane fails to find the desktop as a result its always in 
>> maximized state.
>> Fix: Added method to check if frame is already iconified before 
>> addition.
>> Verified the fix on windows,Ubuntu and Mac with all layouts.
>> Also, removed unused imports from JDesktopPane.java as part of fix.
>> Regards,
>> Rajeev Chamyal
>>
>

From matthijs at stdin.nl  Thu Dec 10 09:24:15 2015
From: matthijs at stdin.nl (Matthijs Kooijman)
Date: Thu, 10 Dec 2015 10:24:15 +0100
Subject:  Incorrect / unexpected handling of keybindings using
 non-standard keyboard layouts
Message-ID: <20151210092415.GD2078@login.tika.stderr.nl>

(Please keep my CC'd, I'm not subscribed to the list)

Hi folks,

while going over the Java keybinding code (trying to solve a different
problem), I found some strangeness in how KeyboardManager and JComponent
handle keystrokes. In particular, they try to match any registered
keybindings to both the normal keycode, as well as the extended keycode
from the KeyEvent.

According to the documentation, the normal keycode relates to the
physical position of the key on the keyboard and is not influenced by
the keyboard layout. The extended keycode relates to the key pressed,
according to the current keyboard layout. When a US QWERTY layout is
used, both keycodes will be identical.

Matching the extended keycode makes sense, if a keybinding is CTRL-Q,
then you want it to work whenever you press the key labeled "Q" on the
keyboard. Matching the normal keycode makes less sense to me - why would
the "key-that-is-Q-on-a-QWERTY-keyboard" trigger a Ctrl-Q binding? I
presume this is a sort of backward compatibility feature, but I wonder
if the application should be in control of this? In any case, in the
current implementation, this approach causes a problem, which I will
describe below.

Handling of keybindings happens by letting each JComponent track a
number of "input maps", mapping keystrokes to actions. There is a map
for when the component is focused, when it is the ancestor of a focused
component, and when the component is in a focused window. The first two
mappings are resolved by traversing the component hierarchy and letting
each component check its maps, the latter map is resolved by
KeyboardManager, which keeps one big map of bindings for each window.

In summary, resolving keypress works like this:

 1. SwingUtilities.processKeyBindings() / JComponent.processKeyBindings():
    Starting with the focused component, going upwards, each component
    checks its keybindings for the current keyEvent. Each component first
    checks against the extended keycode, then the normal keycode.

 2. KeyboardManager.fireKeyboardAction(), via JComponent.processKeyBindingsForAllComponents():
    In the map of WHEN_IN_FOCUSED_WINDOW bindings kept by
    KeyboardManager for the current window, the key event is looked up
    and, if found, forwarded to the right JComponent. Again, this checks
    the extended keycode first, then the normal keycode.

 3. KeyboardManager.fireKeyboardAction() / JMenuBar.processKeyBinding():
    For each JMenuBar in the current window (tracked in a separate map
    by KeyboardManager), JMenuBar.processKeyBinding() is called, which
    recurses through the menu hierarchy to check the
    WHEN_IN_FOCUSED_WINDOW keybindings of each menu item. I assume this
    is needed because children of JMenus are not added to the hierarchy
    directly, but through a (detached) JPopupMenu instance.

Note that in step 1, it actually seems like the component hierarchy is
traversed in both SwingUtilities.processKeyBindings() as well as in
JComponent.processKeyBindings(), which seems like it is doing double
work (and applies the WHEN_FOCUSED maps even to ancestors of the focused
component). However, this doesn't seem relevant to the subject of this
mail, so I'll not investigate this further here.

In my examples below, I will be using the Belgian AZERTY layout. For
these examples, the only relevant changes are that the Q is swapped with
the A, and the W is swapped with the Z.

This resolution process has, AFAICS, two problems:

 1. A given shortcut can be triggered by two keys. For example, when
    using the Belgian AZERTY layout, a Ctrl-Q shortcut will be triggered
    by both CTRL-Q (matching the extended keycode) as well as by CTRL-A
    (the key in the same place as the Q on a QWERTY keyboard, by
    matching the normal keycode).

    I guess this is really intended as a feature, but it might be
    confusing. One unintended side effect seems to be that, on OSX, some
    keyboard shortcuts (such as Ctrl-, to open preferences) are handled
    by the windowing system and passed to the application using a
    seperate notification (e.g. "Open your preferences"), in *addition*
    to passing the original keystroke to the application. This was
    reported in https://bugs.openjdk.java.net/browse/JDK-8019498 where
    a keybinding for Ctrl-M was triggered by pressing Ctrl-, in
    *addition* to opening the preferences. Note that the preferences
    event handling uses some OSX specific code, e.g.
    http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c021b855f51e/src/java.desktop/macosx/classes/com/apple/eawt/_AppEventHandler.java#l192

 2. The second problem is that a component that is checked earlier in
    the resolution order can "hijack" keystrokes from later components.
    Normally, this is intentional - WHEN_FOCUSED and
    WHEN_ANCESTOR_OF_FOCUSED_COMPONENTS favor the focused component, or
    components close to them, and for WHEN_IN_FOCUSED_WINDOW bindings,
    no duplicate bindings should exist.

    However, because each step in the resolution matches both the
    extended and normal keycode, a component can hijack the even using
    the "backward compatible" normal keycode matching, even when a later
    component would have succesfully matched against the extended
    keycode.

    For example, when using a Belgian AZERTY layout, a button in the
    window binds Ctrl-Z, and a menu item binds Ctrl-W, you would expect
    both keypresses to trigger the corresponding action. However, in
    practice the button will match the Ctrl-W keypress too (by matching
    the normal keycode), preventing the menu bar (which comes later in
    the resolution procedure) from matching the keypress, so both
    Ctrl-W and Ctrl-Z trigger the button.

The latter problem is of course the bigger one. The obvious solution is
to run through the entire resolution twice, once matching the extended
keycode, then once more matching the normal keycode. To fix the first
problem too, the last step could perhaps be made optional, or perhaps
KeyStroke can be modified to match the normal keycode, extended keycode,
or both. Not sure if this can be done in a compatible way, though, since
some of the methods involved are public or protected.

To confirm my analisis, I wrote a small testcase (inline below, and at
https://gist.github.com/matthijskooijman/4d016e7a9e3fb07d0699). It shows
both of the problems outlined above. It contains a menu item bound to
Ctrl-Q, which triggers on both Ctrl-Q and Ctrl-A when using the Belgian
AZERTY layout.  It also contains a button binding to Ctrl-Z, which
prevents a menu item bound to Ctrl-W from working when using the Belgian
AZERTY layout. I have tested this on Linux, by selecting a different
keyboard layout ("Input source") in the Gnome keyboard settings (without
actually switching the keyboard).

There seem to be a few related bug reports already. I suspect that most
or all of these are caused by this problem, though not all of them have
enough details to be sure.

https://bugs.openjdk.java.net/browse/JDK-8087915
https://bugs.openjdk.java.net/browse/JDK-8022079
https://bugs.openjdk.java.net/browse/JDK-8019498
https://bugs.openjdk.java.net/browse/JDK-8141096

Interestingly, all of these reports are about OSX, but I'm pretty sure
the problem I'm describing will occur on all platforms, being caused by
platform-independent code. There might be additional OSX-specific
problems, of course, but I do not have access to OSX to test.

Gr.

Matthijs

import javax.swing.*;
import java.awt.event.*;
import java.awt.*;

class Item extends JMenuItem {
    public void addNotify() {
        System.out.println("Add\n");
    }
    public Item(String s) { super(s); }
}

public class Test {
    public static void main(String[] args) {
        SwingUtilities.invokeLater(() -> {
            JFrame frame = new JFrame();
            JMenuBar bar = new JMenuBar();
            JButton button = new JButton("Button Ctrl-Z");
            JTextArea text = new JTextArea("");
            JMenu menu = new JMenu("Menu");
            JMenuItem item1 = new Item( "Item 1" );
            JMenuItem item2 = new JMenuItem( "Item 2" );

            item1.addActionListener((ActionEvent e) -> text.append("Menuitem 1\n"));
            item2.addActionListener((ActionEvent e) -> text.append("Menuitem 2\n"));
            button.addActionListener((ActionEvent e) -> text.append("Button click\n"));

            item1.setAccelerator(KeyStroke.getKeyStroke('Q', KeyEvent.CTRL_MASK));
            item2.setAccelerator(KeyStroke.getKeyStroke('W', KeyEvent.CTRL_MASK));
            KeyStroke keyStroke = KeyStroke.getKeyStroke('Z', KeyEvent.CTRL_MASK);
            ActionListener action = (ActionEvent) -> text.append("Button key\n");
            button.registerKeyboardAction(action, "action", keyStroke, JComponent.WHEN_IN_FOCUSED_WINDOW);

            menu.add(item1);
            menu.add(item2);
            bar.add(menu);

            text.setEnabled(false);
            frame.setLayout(new BorderLayout());
            frame.add(button, BorderLayout.SOUTH);
            frame.add(text, BorderLayout.CENTER);
            frame.setJMenuBar(bar);
            frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
            frame.setSize(200,200);
            frame.setVisible(true);
        });
    }
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 

From semyon.sadetsky at oracle.com  Thu Dec 24 11:54:31 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 24 Dec 2015 14:54:31 +0300
Subject:  Incorrect / unexpected handling of keybindings
 using non-standard keyboard layouts
In-Reply-To: <20151210092415.GD2078@login.tika.stderr.nl>
References: <20151210092415.GD2078@login.tika.stderr.nl>
Message-ID: <567BDCF7.30503@oracle.com>

Hi Matthijs,

Thank you for your e-mail and the analysis. We really appreciate your 
contribution.
I ran your test on Windows and Linux. In both cases with Belgian(Dutch) 
keyboard layout I got single key combinations only, just keys were 
swapped Q->A, W->Z,  Z->W. (I don't have the Belgium physical keyboard, 
I only switched the OS layout.) It looks like that this is really Mac 
specific problem.

--Semyon

On 12/10/2015 12:24 PM, Matthijs Kooijman wrote:
> (Please keep my CC'd, I'm not subscribed to the list)
>
> Hi folks,
>
> while going over the Java keybinding code (trying to solve a different
> problem), I found some strangeness in how KeyboardManager and JComponent
> handle keystrokes. In particular, they try to match any registered
> keybindings to both the normal keycode, as well as the extended keycode
> from the KeyEvent.
>
> According to the documentation, the normal keycode relates to the
> physical position of the key on the keyboard and is not influenced by
> the keyboard layout. The extended keycode relates to the key pressed,
> according to the current keyboard layout. When a US QWERTY layout is
> used, both keycodes will be identical.
>
> Matching the extended keycode makes sense, if a keybinding is CTRL-Q,
> then you want it to work whenever you press the key labeled "Q" on the
> keyboard. Matching the normal keycode makes less sense to me - why would
> the "key-that-is-Q-on-a-QWERTY-keyboard" trigger a Ctrl-Q binding? I
> presume this is a sort of backward compatibility feature, but I wonder
> if the application should be in control of this? In any case, in the
> current implementation, this approach causes a problem, which I will
> describe below.
>
> Handling of keybindings happens by letting each JComponent track a
> number of "input maps", mapping keystrokes to actions. There is a map
> for when the component is focused, when it is the ancestor of a focused
> component, and when the component is in a focused window. The first two
> mappings are resolved by traversing the component hierarchy and letting
> each component check its maps, the latter map is resolved by
> KeyboardManager, which keeps one big map of bindings for each window.
>
> In summary, resolving keypress works like this:
>
>   1. SwingUtilities.processKeyBindings() / JComponent.processKeyBindings():
>      Starting with the focused component, going upwards, each component
>      checks its keybindings for the current keyEvent. Each component first
>      checks against the extended keycode, then the normal keycode.
>
>   2. KeyboardManager.fireKeyboardAction(), via JComponent.processKeyBindingsForAllComponents():
>      In the map of WHEN_IN_FOCUSED_WINDOW bindings kept by
>      KeyboardManager for the current window, the key event is looked up
>      and, if found, forwarded to the right JComponent. Again, this checks
>      the extended keycode first, then the normal keycode.
>
>   3. KeyboardManager.fireKeyboardAction() / JMenuBar.processKeyBinding():
>      For each JMenuBar in the current window (tracked in a separate map
>      by KeyboardManager), JMenuBar.processKeyBinding() is called, which
>      recurses through the menu hierarchy to check the
>      WHEN_IN_FOCUSED_WINDOW keybindings of each menu item. I assume this
>      is needed because children of JMenus are not added to the hierarchy
>      directly, but through a (detached) JPopupMenu instance.
>
> Note that in step 1, it actually seems like the component hierarchy is
> traversed in both SwingUtilities.processKeyBindings() as well as in
> JComponent.processKeyBindings(), which seems like it is doing double
> work (and applies the WHEN_FOCUSED maps even to ancestors of the focused
> component). However, this doesn't seem relevant to the subject of this
> mail, so I'll not investigate this further here.
>
> In my examples below, I will be using the Belgian AZERTY layout. For
> these examples, the only relevant changes are that the Q is swapped with
> the A, and the W is swapped with the Z.
>
> This resolution process has, AFAICS, two problems:
>
>   1. A given shortcut can be triggered by two keys. For example, when
>      using the Belgian AZERTY layout, a Ctrl-Q shortcut will be triggered
>      by both CTRL-Q (matching the extended keycode) as well as by CTRL-A
>      (the key in the same place as the Q on a QWERTY keyboard, by
>      matching the normal keycode).
>
>      I guess this is really intended as a feature, but it might be
>      confusing. One unintended side effect seems to be that, on OSX, some
>      keyboard shortcuts (such as Ctrl-, to open preferences) are handled
>      by the windowing system and passed to the application using a
>      seperate notification (e.g. "Open your preferences"), in *addition*
>      to passing the original keystroke to the application. This was
>      reported in https://bugs.openjdk.java.net/browse/JDK-8019498 where
>      a keybinding for Ctrl-M was triggered by pressing Ctrl-, in
>      *addition* to opening the preferences. Note that the preferences
>      event handling uses some OSX specific code, e.g.
>      http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c021b855f51e/src/java.desktop/macosx/classes/com/apple/eawt/_AppEventHandler.java#l192
>
>   2. The second problem is that a component that is checked earlier in
>      the resolution order can "hijack" keystrokes from later components.
>      Normally, this is intentional - WHEN_FOCUSED and
>      WHEN_ANCESTOR_OF_FOCUSED_COMPONENTS favor the focused component, or
>      components close to them, and for WHEN_IN_FOCUSED_WINDOW bindings,
>      no duplicate bindings should exist.
>
>      However, because each step in the resolution matches both the
>      extended and normal keycode, a component can hijack the even using
>      the "backward compatible" normal keycode matching, even when a later
>      component would have succesfully matched against the extended
>      keycode.
>
>      For example, when using a Belgian AZERTY layout, a button in the
>      window binds Ctrl-Z, and a menu item binds Ctrl-W, you would expect
>      both keypresses to trigger the corresponding action. However, in
>      practice the button will match the Ctrl-W keypress too (by matching
>      the normal keycode), preventing the menu bar (which comes later in
>      the resolution procedure) from matching the keypress, so both
>      Ctrl-W and Ctrl-Z trigger the button.
>
> The latter problem is of course the bigger one. The obvious solution is
> to run through the entire resolution twice, once matching the extended
> keycode, then once more matching the normal keycode. To fix the first
> problem too, the last step could perhaps be made optional, or perhaps
> KeyStroke can be modified to match the normal keycode, extended keycode,
> or both. Not sure if this can be done in a compatible way, though, since
> some of the methods involved are public or protected.
>
> To confirm my analisis, I wrote a small testcase (inline below, and at
> https://gist.github.com/matthijskooijman/4d016e7a9e3fb07d0699). It shows
> both of the problems outlined above. It contains a menu item bound to
> Ctrl-Q, which triggers on both Ctrl-Q and Ctrl-A when using the Belgian
> AZERTY layout.  It also contains a button binding to Ctrl-Z, which
> prevents a menu item bound to Ctrl-W from working when using the Belgian
> AZERTY layout. I have tested this on Linux, by selecting a different
> keyboard layout ("Input source") in the Gnome keyboard settings (without
> actually switching the keyboard).
>
> There seem to be a few related bug reports already. I suspect that most
> or all of these are caused by this problem, though not all of them have
> enough details to be sure.
>
> https://bugs.openjdk.java.net/browse/JDK-8087915
> https://bugs.openjdk.java.net/browse/JDK-8022079
> https://bugs.openjdk.java.net/browse/JDK-8019498
> https://bugs.openjdk.java.net/browse/JDK-8141096
>
> Interestingly, all of these reports are about OSX, but I'm pretty sure
> the problem I'm describing will occur on all platforms, being caused by
> platform-independent code. There might be additional OSX-specific
> problems, of course, but I do not have access to OSX to test.
>
> Gr.
>
> Matthijs
>
>
>
> import javax.swing.*;
> import java.awt.event.*;
> import java.awt.*;
>
> class Item extends JMenuItem {
>      public void addNotify() {
>          System.out.println("Add\n");
>      }
>      public Item(String s) { super(s); }
> }
>
> public class Test {
>      public static void main(String[] args) {
>          SwingUtilities.invokeLater(() -> {
>              JFrame frame = new JFrame();
>              JMenuBar bar = new JMenuBar();
>              JButton button = new JButton("Button Ctrl-Z");
>              JTextArea text = new JTextArea("");
>              JMenu menu = new JMenu("Menu");
>              JMenuItem item1 = new Item( "Item 1" );
>              JMenuItem item2 = new JMenuItem( "Item 2" );
>
>              item1.addActionListener((ActionEvent e) -> text.append("Menuitem 1\n"));
>              item2.addActionListener((ActionEvent e) -> text.append("Menuitem 2\n"));
>              button.addActionListener((ActionEvent e) -> text.append("Button click\n"));
>
>              item1.setAccelerator(KeyStroke.getKeyStroke('Q', KeyEvent.CTRL_MASK));
>              item2.setAccelerator(KeyStroke.getKeyStroke('W', KeyEvent.CTRL_MASK));
>              KeyStroke keyStroke = KeyStroke.getKeyStroke('Z', KeyEvent.CTRL_MASK);
>              ActionListener action = (ActionEvent) -> text.append("Button key\n");
>              button.registerKeyboardAction(action, "action", keyStroke, JComponent.WHEN_IN_FOCUSED_WINDOW);
>
>              menu.add(item1);
>              menu.add(item2);
>              bar.add(menu);
>
>              text.setEnabled(false);
>              frame.setLayout(new BorderLayout());
>              frame.add(button, BorderLayout.SOUTH);
>              frame.add(text, BorderLayout.CENTER);
>              frame.setJMenuBar(bar);
>              frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
>              frame.setSize(200,200);
>              frame.setVisible(true);
>          });
>      }
> }

From Sergey.Bylokhov at oracle.com  Thu Dec 24 16:08:56 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 24 Dec 2015 19:08:56 +0300
Subject:  Review request for JDK-8078489 JSpinner using
 SpinnerNumberModel doesn't honor orientation flag
In-Reply-To: <41248751-f4be-4f59-824d-045986161b3c@default>
References: <572f1e83-752d-41a9-be86-95084234bc35@default>
	<567ABFC5.2040807@oracle.com>
	<41248751-f4be-4f59-824d-045986161b3c@default>
Message-ID: <567C1898.7070702@oracle.com>

On 24/12/15 08:18, Rajeev Chamyal wrote:
> Hello Sergey,
>
> Thanks for the review.
> The issues is reproducible with mac Aqua LAF only with other LAF/platforms issue is not reproducible.

I am sure that this bug was reproduced on Aqua because we had not the 
test which cover this area for all supported look and feels. So when the 
new LaF was added the bug was not found. So I suggest to remove 
limitation on osx and to add the coverage for all supported LaFs, to 
prove that the same bug will not occur on some old/new LaF.

> I have updated webrev as per review comments.
>
> http://cr.openjdk.java.net/~rchamyal/8078489/webrev.01/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: 23 December 2015 21:08
> To: Rajeev Chamyal; Alexander Scherbatiy; Prasanta Sadhukhan; swing-dev at openjdk.java.net
> Subject: Re: Review request for JDK-8078489 JSpinner using SpinnerNumberModel doesn't honor orientation flag
>
> Hi, Rajeev.
> A few notes:
>    - the cast in the "if (o != (ComponentOrientation) e.getOldValue())"
> is not necessary.
>    - Is it possible to cover all look and feels in the test?
>    - Why the test is for osx only?
>
> On 22/12/15 12:54, Rajeev Chamyal wrote:
>> Hello All,
>>
>> Please review the following fix for Jdk9:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078489
>>
>> Webrev:http://cr.openjdk.java.net/~rchamyal/8078489/webrev.00/
>>
>> Issue: Jspinner text in Aqua LAF is not following Right to left
>> component orientation.
>>
>> Cause: Code for JSpinner Component orientation is missing.
>>
>> Fix: Updated the property change listener of Aqua LAF to update editor
>> text orientation.
>>
>> Regards,
>>
>> Rajeev Chamyal
>>
>
>
> --
> Best regards, Sergey.
>

-- 
Best regards, Sergey.

From matthijs at stdin.nl  Thu Dec 24 18:32:37 2015
From: matthijs at stdin.nl (Matthijs Kooijman)
Date: Thu, 24 Dec 2015 19:32:37 +0100
Subject:  Incorrect / unexpected handling of keybindings
 using non-standard keyboard layouts
In-Reply-To: <567BDCF7.30503@oracle.com>
References: <20151210092415.GD2078@login.tika.stderr.nl>
	<567BDCF7.30503@oracle.com>
Message-ID: <20151224183237.GD12507@login.tika.stderr.nl>

Hi Semyon,

> I ran your test on Windows and Linux. In both cases with Belgian(Dutch)
> keyboard layout I got single key combinations only, just keys were swapped
> Q->A, W->Z,  Z->W. (I don't have the Belgium physical keyboard, I only
> switched the OS layout.) It looks like that this is really Mac specific
> problem.
Hm, I tested on Linux, so it's certainly not mac-specific :-)

When you say "just keys were swapped", do you mean that changing the
layout didn't actually change any behaviour? e.g. ctrl+"the Q on the
keyboard, which is A in the layout" triggers the menu item, but
ctrl+"the A on the keyboard, which is Q in the layout" does *not*
trigger the menu item? Or do you mean that everything works as expected
with the shortcuts adapting to the new layout properly?

I posted my report two weeks ago but it was lost in the moderator queue,
so I subscribed and reposted it this afternoon. Since the first posting,
I have discovered that using keycodes for shortcuts actually suffers
from another shortcoming: Some layouts do not have just keys moved, but
the keys are different too. For example, (I think) the german layout
uses shift-7 to get / instead of / having its own key. So the ctrl-/
shortcut should really become ctrl-shift-7 on that layout, which is more
than just using the extended keycode instead of the normal keycode.

In other words, mapping keycodes for shortcuts can, AFAICS, never
reliably deal with alternative keyboard layouts. Using KEY_TYPED, which
has the actual character made, would then be better, except that
KeyStroke objects for KEY_TYPED events never include any modifiers,
making them again unsuitable.

I'm not really sure how this should be fixed (I'm not a very experienced
java coder, let along JDK hacker), but hopefully others can pick this up
from here :-)

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 

From alexey.ivanov at oracle.com  Fri Dec 25 12:43:42 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 25 Dec 2015 15:43:42 +0300
Subject:  Review request for JDK-4769772
 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong
 state
In-Reply-To: 
References: <34136115-bd25-43f6-bbdd-c98bc1dbfe17@default>
	<567AA5A5.3090901@oracle.com> <567AA83C.9080308@oracle.com>

Message-ID: <567D39FE.1080906@oracle.com>

Hi Rajeev,

Thank you for updating the code.

I have a couple more questions though.

1. SynthDesktopPaneUI
What is the purpose of this line?
     d.setBounds(r.x, r.y, r.width, r.height);

Since d is a JDesktopPane which contains the frame, you change the 
location and size of the desktop pane to those of the iconified frame. 
It doesn't seem right to me. Could you please clarify your intention?

2. dispose() method is never used in the test, so it could be removed.

3. Since testFailed field is accessed from different threads, it should 
be marked volatile.

4. robot.delay(1000) in executeTest() is unnecessary, isn't it?

5. You change the code for Synth and Aqua LaF but your test does not 
cover them. I suggest iterating over all installed LaFs and run the test 
case in all the LaFs.

6. Shouldn't test fail if PropertyVetoException is thrown for 
f.setIcon(true)? I believe it's not expected in this case.

7. Probably any exception thrown during test execution should also be 
considered as failure, otherwise catch in executeTest().Runnable{}.run() 
is redundant.

Regards,
Alexey

On 24.12.2015 10:19, Rajeev Chamyal wrote:
> Hello Alexey,
>
> Thanks for the review.
> I have updated webrev as per review comments.
>
> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.01/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Alexey Ivanov
> Sent: 23 December 2015 19:27
> To: swing-dev at openjdk.java.net
> Subject: Re:  Review request for JDK-4769772 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong state
>
> Hi Rajeev,
>
> One more comment:
> You should call dispose() in finally block in main so that the frame is closed automatically if the test fails.
>
> Regards,
> Alexey
>
> On 23.12.2015 16:46, Alexey Ivanov wrote:
>> Hi Rajeev,
>>
>> There's a potential NullPointerException in this line of
>> BasicInternalFrameUI.java:
>>      if(value.equals(Boolean.FALSE))
>>
>> I suggest eliminating it using this construct:
>>      if (Boolean.FALSE.equals(value))
>>
>> This way the code is safer.
>>
>>
>> Can the test be simplified? Is it really required to create menu and
>> use robot to invoke commands?
>> Wouldn't it be enough to programmatically add minimized internal frame
>> and then check its properties?
>>
>> JFrame in test should also be instantiated on EDT, in createUI() method.
>>
>>
>> And a general recommendation to follow Java Coding Style [1] and in
>> particular to add a space [2] after 'if',  after comma in argument
>> lists, and after cast operator.
>>
>> Regards,
>> Alexey
>>
>> [1] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
>> [2]
>> http://www.oracle.com/technetwork/java/javase/documentation/codeconven
>> tions-141388.html#682
>>
>> On 18.12.2015 11:44, Rajeev Chamyal wrote:
>>> Hello All,
>>>
>>> Please review the following fix for Jdk9:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4769772
>>>
>>> Webrev:http://cr.openjdk.java.net/~rchamyal/4769772/webrev.00/
>>> 
>>>
>>> Issue: Iconifying a frame before adding it to desktop pane is not
>>> working.
>>>
>>> Cause: Setting setIcon property of a JInternalFrame before addition
>>> to desktop pane fails to find the desktop as a result its always in
>>> maximized state.
>>> Fix: Added method to check if frame is already iconified before
>>> addition.
>>> Verified the fix on windows,Ubuntu and Mac with all layouts.
>>> Also, removed unused imports from JDesktopPane.java as part of fix.
>>> Regards,
>>> Rajeev Chamyal
>>>

From Sergey.Bylokhov at oracle.com  Fri Dec 25 15:53:14 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 25 Dec 2015 18:53:14 +0300
Subject:  Review request for JDK-8145060 Minimizing a
 JInternal frame not shifting focus to frame below it
In-Reply-To: <6e594a8b-fc5b-4d4d-abfa-ed54d5718323@default>
References: <6e594a8b-fc5b-4d4d-abfa-ed54d5718323@default>
Message-ID: <567D666A.9010008@oracle.com>

Hi, Rajeev.
I guess "d.setComponentOrderCheckingEnabled(false);" should be moved 
also for consistency.

On 14/12/15 08:32, Rajeev Chamyal wrote:
> Hello All,
>
> Please review the following fix for Jdk9:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145060
>
> Webrev:http://cr.openjdk.java.net/~rchamyal/8145060/webrev.00/
>
> Issue: On minimizing the successive internal frames the focus is not
> shifting to frame below it.
>
> Cause: During minimize internal frame is removed from container. Removal
> of internal frames from container also removes the internal frame entry
> from internal frame cache.
>
> During focus shift cache is checked for current internal frame entry and
> then focus is shifted to frame below it. As removal from container has
> already updated the cache so
>
> Current frame is not found in cache and focus shift fails.
>
> Fix: Internal frame removal from container is done after focus shift.
>
> Regards,
>
> Rajeev Chamyal
>

-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Dec 25 16:21:38 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 25 Dec 2015 19:21:38 +0300
Subject:  Review request for JDK-8075084
 JOptionPane.showMessageDialog causes JScrollBar to move
In-Reply-To: 
References: <556d6cec-a723-42a4-a96a-dc22b7d2f112@default>
	<565EAB0D.4070406@oracle.com>
	<745c79a4-6692-4b5c-9c81-ae10332c248d@default>
	<566961E8.1020806@oracle.com>
	<0101fe6a-0bfe-44e5-9bd4-4c470160024a@default>
	<56788E7A.4020601@oracle.com>

Message-ID: <567D6D12.70806@oracle.com>

Probably this bug can be fixed in a different way. Is it possible to 
check the state of the scroll bar in the timer? And if in some iteration 
the button became unpressed then stops itself(timer).

On 23/12/15 12:29, Rajeev Chamyal wrote:
> Hello Alexandr,
>
> The modal dialog can be application modal, document modal and toolkit modal.
>       1) Application-modal dialog box blocks all windows from the same application, except windows from its child hierarchy
>       2) Document-modal dialog box blocks all windows from the same document, except windows from its child hierarchy.
>       3) Toolkit-modal dialog box blocks all windows that run in the same toolkit, except windows from its child hierarchy
>
> The current issue is reproducible with all modal dialog types. I have updated the condition in code to check for modal dialogs.
>
> http://cr.openjdk.java.net/~rchamyal/8075084/webrev.02/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Alexander Scherbatiy
> Sent: 22 December 2015 05:13
> To: Rajeev Chamyal
> Cc: Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
> Subject: Re: Review request for JDK-8075084 JOptionPane.showMessageDialog causes JScrollBar to move
>
> On 21/12/15 12:21, Rajeev Chamyal wrote:
>> Hello Alexandr,
>>
>> I have updated the fix. Please review it.
>> http://cr.openjdk.java.net/~rchamyal/8075084/webrev.01/
>
>      When a modal dialog is shown does it block all windows or is it possible that a modal dialog blocks some windows and does not block others?
>
>    Thanks,
>    Alexandr.
>
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Alexander Scherbatiy
>> Sent: 10 December 2015 16:59
>> To: Rajeev Chamyal
>> Cc: Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
>> Subject: Re: Review request for JDK-8075084
>> JOptionPane.showMessageDialog causes JScrollBar to move
>>
>> On 12/3/2015 11:08 AM, Rajeev Chamyal wrote:
>>> Hello Alexandr,
>>>
>>> Thanks for the review.
>>>
>>> When we open a JOption dialog from AdjustmentListener the scroll bar
>>> arrow button is not receiving the mouse release event.
>>>
>>> As a result the JScrollBar: scrollTimer is not getting stopped and
>>> its becoming a recursive call.
>>>
>>       I tried to run the BuggyDialog sample form the issue description with the suggested fix.
>>       I noticed a strange behavior when I press scroll down and click not on the JOptionPane OK button but on the close button.
>>       The scroll bar continues scrolling in this case.
>>
>>       When a modal dialog is open it blocks others windows. Is it possible to check this event and stop the scroll timer in this case?
>>
>>      Thanks,
>>      Alexandr.
>>
>>> Regards,
>>>
>>> Rajeev Chamyal
>>>
>>> *From:*Alexandr Scherbatiy
>>> *Sent:* 02 December 2015 13:56
>>> *To:* Rajeev Chamyal; Sergey Bylokhov; Prasanta Sadhukhan;
>>> swing-dev at openjdk.java.net
>>> *Subject:* Re: Review request for JDK-8075084
>>> JOptionPane.showMessageDialog causes JScrollBar to move
>>>
>>> On 11/11/2015 7:47 AM, Rajeev Chamyal wrote:
>>>
>>>       Hello All,
>>>
>>>       Please review the following fix for Jdk9:
>>>
>>>
>>>
>>>       Bug:https://bugs.openjdk.java.net/browse/JDK-8075084
>>>
>>>       Webrev:http://cr.openjdk.java.net/~rchamyal/8075084/webrev.00/
>>>       
>>>
>>>       Issue: On running the sample program attached in bug JDK-8075084
>>>       user is expected to see a scrollbar and on clicking the scrollbar
>>>       tracker or scrollbar up/down arrow buttons a JOption dialog should
>>>       come once. The program works fine if scrollbar tracker is clicked
>>>       i.e. JOption dialog comes only once. But on clicking up/down arrow
>>>       buttons of scrollbar the JOption dialog keeps on coming repeatedly.
>>>
>>>       Cause: The mouse pressed event of scrollbar arrow buttons calls BasicScrollBarUI::scrollByUnit method which creates a property change event and calls scroll bar action listener which again calls BasicScrollBarUI::scrollByUnit. This is becoming a recursive call and causing the scrollbar slider to move repeatedly till it reaches the other end of scrollbar.
>>>
>>>      If I change the AdjustmentListener to not show the JOptionPane it
>>> is called only one time.
>>>      What is the reason that showing JOptionPane causes that the
>>> AdjustmentListener is called one more time?
>>>
>>>      Thanks,
>>>      Alexandr.
>>>
>>>
>>>
>>>
>>>       Fix: Added checks in the BasicScrollBarUI action listener to stop the recursion.
>>>
>>>
>>>
>>>       Regards,
>>>
>>>       Rajeev Chamyal
>>>
>

-- 
Best regards, Sergey.

From rajeev.chamyal at oracle.com  Sun Dec 27 15:02:25 2015
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Sun, 27 Dec 2015 07:02:25 -0800 (PST)
Subject:  Review request for JDK-8075084
 JOptionPane.showMessageDialog causes JScrollBar to move
In-Reply-To: <567D6D12.70806@oracle.com>
References: <556d6cec-a723-42a4-a96a-dc22b7d2f112@default>
	<565EAB0D.4070406@oracle.com>
	<745c79a4-6692-4b5c-9c81-ae10332c248d@default>
	<566961E8.1020806@oracle.com>
	<0101fe6a-0bfe-44e5-9bd4-4c470160024a@default>
	<56788E7A.4020601@oracle.com>

	<567D6D12.70806@oracle.com>
Message-ID: <6a9ba228-fbfb-41d8-bb59-01f98f449a0a@default>

Hello Sergey,

The first webrev version is implemented on similar lines as you suggested but it had issues as pointed my Alexandr in his review below. 
If the mouse pointer after clicking on modal dialog close lies outside the parent window then parent window is not getting any mouse events and BasicScrollBarUI::scrollByUnit method is again getting called recursively,
Because of which the scroll bar pointer keeps on moving till the end of scrollbar.
With this new implementation these issue are not seen.

Regards,
Rajeev Chamyal

-----Original Message-----
From: Sergey Bylokhov 
Sent: 25 December 2015 21:52
To: Rajeev Chamyal; Alexander Scherbatiy
Cc: Prasanta Sadhukhan; swing-dev at openjdk.java.net
Subject: Re: Review request for JDK-8075084 JOptionPane.showMessageDialog causes JScrollBar to move

Probably this bug can be fixed in a different way. Is it possible to check the state of the scroll bar in the timer? And if in some iteration the button became unpressed then stops itself(timer).

On 23/12/15 12:29, Rajeev Chamyal wrote:
> Hello Alexandr,
>
> The modal dialog can be application modal, document modal and toolkit modal.
>       1) Application-modal dialog box blocks all windows from the same application, except windows from its child hierarchy
>       2) Document-modal dialog box blocks all windows from the same document, except windows from its child hierarchy.
>       3) Toolkit-modal dialog box blocks all windows that run in the 
> same toolkit, except windows from its child hierarchy
>
> The current issue is reproducible with all modal dialog types. I have updated the condition in code to check for modal dialogs.
>
> http://cr.openjdk.java.net/~rchamyal/8075084/webrev.02/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Alexander Scherbatiy
> Sent: 22 December 2015 05:13
> To: Rajeev Chamyal
> Cc: Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
> Subject: Re: Review request for JDK-8075084 
> JOptionPane.showMessageDialog causes JScrollBar to move
>
> On 21/12/15 12:21, Rajeev Chamyal wrote:
>> Hello Alexandr,
>>
>> I have updated the fix. Please review it.
>> http://cr.openjdk.java.net/~rchamyal/8075084/webrev.01/
>
>      When a modal dialog is shown does it block all windows or is it possible that a modal dialog blocks some windows and does not block others?
>
>    Thanks,
>    Alexandr.
>
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Alexander Scherbatiy
>> Sent: 10 December 2015 16:59
>> To: Rajeev Chamyal
>> Cc: Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
>> Subject: Re: Review request for JDK-8075084 
>> JOptionPane.showMessageDialog causes JScrollBar to move
>>
>> On 12/3/2015 11:08 AM, Rajeev Chamyal wrote:
>>> Hello Alexandr,
>>>
>>> Thanks for the review.
>>>
>>> When we open a JOption dialog from AdjustmentListener the scroll bar 
>>> arrow button is not receiving the mouse release event.
>>>
>>> As a result the JScrollBar: scrollTimer is not getting stopped and 
>>> its becoming a recursive call.
>>>
>>       I tried to run the BuggyDialog sample form the issue description with the suggested fix.
>>       I noticed a strange behavior when I press scroll down and click not on the JOptionPane OK button but on the close button.
>>       The scroll bar continues scrolling in this case.
>>
>>       When a modal dialog is open it blocks others windows. Is it possible to check this event and stop the scroll timer in this case?
>>
>>      Thanks,
>>      Alexandr.
>>
>>> Regards,
>>>
>>> Rajeev Chamyal
>>>
>>> *From:*Alexandr Scherbatiy
>>> *Sent:* 02 December 2015 13:56
>>> *To:* Rajeev Chamyal; Sergey Bylokhov; Prasanta Sadhukhan; 
>>> swing-dev at openjdk.java.net
>>> *Subject:* Re: Review request for JDK-8075084 
>>> JOptionPane.showMessageDialog causes JScrollBar to move
>>>
>>> On 11/11/2015 7:47 AM, Rajeev Chamyal wrote:
>>>
>>>       Hello All,
>>>
>>>       Please review the following fix for Jdk9:
>>>
>>>
>>>
>>>       Bug:https://bugs.openjdk.java.net/browse/JDK-8075084
>>>
>>>       Webrev:http://cr.openjdk.java.net/~rchamyal/8075084/webrev.00/
>>>       
>>>
>>>       Issue: On running the sample program attached in bug JDK-8075084
>>>       user is expected to see a scrollbar and on clicking the scrollbar
>>>       tracker or scrollbar up/down arrow buttons a JOption dialog should
>>>       come once. The program works fine if scrollbar tracker is clicked
>>>       i.e. JOption dialog comes only once. But on clicking up/down arrow
>>>       buttons of scrollbar the JOption dialog keeps on coming repeatedly.
>>>
>>>       Cause: The mouse pressed event of scrollbar arrow buttons calls BasicScrollBarUI::scrollByUnit method which creates a property change event and calls scroll bar action listener which again calls BasicScrollBarUI::scrollByUnit. This is becoming a recursive call and causing the scrollbar slider to move repeatedly till it reaches the other end of scrollbar.
>>>
>>>      If I change the AdjustmentListener to not show the JOptionPane 
>>> it is called only one time.
>>>      What is the reason that showing JOptionPane causes that the 
>>> AdjustmentListener is called one more time?
>>>
>>>      Thanks,
>>>      Alexandr.
>>>
>>>
>>>
>>>
>>>       Fix: Added checks in the BasicScrollBarUI action listener to stop the recursion.
>>>
>>>
>>>
>>>       Regards,
>>>
>>>       Rajeev Chamyal
>>>
>

--
Best regards, Sergey.

From avik.niyogi at oracle.com  Mon Dec 28 04:53:32 2015
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 28 Dec 2015 10:23:32 +0530
Subject:  Review request for 8016665: [macosx] JComponent
	behaviour doesn't comply API documentation
	(setComponentOrientation method), Aqua LAF
In-Reply-To: <567AA990.5080806@oracle.com>
References: <830F92CE-33CC-42B5-BA07-8E1BB179D7E9@oracle.com>
	<567AA990.5080806@oracle.com>
Message-ID: 

Hi Alexandr,

Automated test may fail based on folder contents on individual systems irrespective of the fix directly not depending on the same. 
Also, to confirm this fix, it will need visual confirmation and hence, no automated test was provided.

With Regards,
Avik Niyogi
> On 23-Dec-2015, at 7:32 pm, Alexander Scherbatiy  wrote:
> 
> 
> 
>   The fix looks good to me.
> 
>   Is it possible to write an automated test for the fix?
> 
>   Thanks,
>   Alexandr.
> 
> On 12/21/2015 2:55 PM, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the bug fix for JDK 9.
>> 
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8016665 
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.00/ 
>> 
>> Issue:
>> The manual test: Swing_AllComponents/Manual/I18nSwingTests
>> in testsuite http://sqe-hg.us.oracle.com/hg/index.cgi/testbase/javase/functional/7/swing  fails.
>> 
>> Cause:
>> Due to not honouring of RIGHT_TO_LEFT parameter for setOrientation method applied for a JFileChooser for the AquaLookAndFeel only,
>> the fileChooser does not get displayed in RIGHT_TO_LEFT orientation. 
>> This issue was verified to exist only in AquaLookAndFeel for JFileChooser only due to wrong implementation in AquaFileSystemModel.
>> Also, as provided in comments: "The Aqua LAF must support the RTL orientation of JFileChooser."
>> 
>> Fix:
>> Added implementation for the check of RIGHT_TO_LEFT ComponentOrientation and verified with test suite.
>> 
>> 
>> With Regards,
>> Avik Niyogi
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rajeev.chamyal at oracle.com  Mon Dec 28 07:37:38 2015
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Sun, 27 Dec 2015 23:37:38 -0800 (PST)
Subject:  Review request for JDK-4769772
 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong
 state
In-Reply-To: <567D39FE.1080906@oracle.com>
References: <34136115-bd25-43f6-bbdd-c98bc1dbfe17@default>
	<567AA5A5.3090901@oracle.com> <567AA83C.9080308@oracle.com>

	<567D39FE.1080906@oracle.com>
Message-ID: 

Hello Alexey,

Thanks for the review. I have updated the code as suggested.
http://cr.openjdk.java.net/~rchamyal/4769772/webrev.02/
Please see response to questions inline.

Regards,
Rajeev Chamyal

-----Original Message-----
From: Alexey Ivanov 
Sent: 25 December 2015 18:14
To: Rajeev Chamyal; swing-dev at openjdk.java.net
Subject: Re:  Review request for JDK-4769772 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong state

Hi Rajeev,

Thank you for updating the code.

I have a couple more questions though.

1. SynthDesktopPaneUI
What is the purpose of this line?
     d.setBounds(r.x, r.y, r.width, r.height);

Since d is a JDesktopPane which contains the frame, you change the location and size of the desktop pane to those of the iconified frame. 
It doesn't seem right to me. Could you please clarify your intention?
[Rajeev Chamyal] It's a typo updated the code. We need to set bounds for desktopIcon instead of desktop pane.

2. dispose() method is never used in the test, so it could be removed.
[Rajeev Chamyal] Removed from test code.

3. Since testFailed field is accessed from different threads, it should be marked volatile.
[Rajeev Chamyal] Test updated to check all LAF. testFailed variable is not used now.

4. robot.delay(1000) in executeTest() is unnecessary, isn't it?
[Rajeev Chamyal]  As its UI test so added delay for user to check visually as well.

5. You change the code for Synth and Aqua LaF but your test does not cover them. I suggest iterating over all installed LaFs and run the test case in all the LaFs.
[Rajeev Chamyal]  Updated the test for all LAF's

6. Shouldn't test fail if PropertyVetoException is thrown for f.setIcon(true)? I believe it's not expected in this case.
[Rajeev Chamyal]  Updated code. But this exception is not expected.

7. Probably any exception thrown during test execution should also be considered as failure, otherwise catch in executeTest().Runnable{}.run() is redundant.
[Rajeev Chamyal] Test code is updated to handle all exceptions as failures.

Regards,
Alexey

On 24.12.2015 10:19, Rajeev Chamyal wrote:
> Hello Alexey,
>
> Thanks for the review.
> I have updated webrev as per review comments.
>
> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.01/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Alexey Ivanov
> Sent: 23 December 2015 19:27
> To: swing-dev at openjdk.java.net
> Subject: Re:  Review request for JDK-4769772 
> JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong 
> state
>
> Hi Rajeev,
>
> One more comment:
> You should call dispose() in finally block in main so that the frame is closed automatically if the test fails.
>
> Regards,
> Alexey
>
> On 23.12.2015 16:46, Alexey Ivanov wrote:
>> Hi Rajeev,
>>
>> There's a potential NullPointerException in this line of
>> BasicInternalFrameUI.java:
>>      if(value.equals(Boolean.FALSE))
>>
>> I suggest eliminating it using this construct:
>>      if (Boolean.FALSE.equals(value))
>>
>> This way the code is safer.
>>
>>
>> Can the test be simplified? Is it really required to create menu and 
>> use robot to invoke commands?
>> Wouldn't it be enough to programmatically add minimized internal 
>> frame and then check its properties?
>>
>> JFrame in test should also be instantiated on EDT, in createUI() method.
>>
>>
>> And a general recommendation to follow Java Coding Style [1] and in 
>> particular to add a space [2] after 'if',  after comma in argument 
>> lists, and after cast operator.
>>
>> Regards,
>> Alexey
>>
>> [1] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
>> [2]
>> http://www.oracle.com/technetwork/java/javase/documentation/codeconve
>> n
>> tions-141388.html#682
>>
>> On 18.12.2015 11:44, Rajeev Chamyal wrote:
>>> Hello All,
>>>
>>> Please review the following fix for Jdk9:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4769772
>>>
>>> Webrev:http://cr.openjdk.java.net/~rchamyal/4769772/webrev.00/
>>> 
>>>
>>> Issue: Iconifying a frame before adding it to desktop pane is not 
>>> working.
>>>
>>> Cause: Setting setIcon property of a JInternalFrame before addition 
>>> to desktop pane fails to find the desktop as a result its always in 
>>> maximized state.
>>> Fix: Added method to check if frame is already iconified before 
>>> addition.
>>> Verified the fix on windows,Ubuntu and Mac with all layouts.
>>> Also, removed unused imports from JDesktopPane.java as part of fix.
>>> Regards,
>>> Rajeev Chamyal
>>>

From rajeev.chamyal at oracle.com  Mon Dec 28 07:45:32 2015
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Sun, 27 Dec 2015 23:45:32 -0800 (PST)
Subject:  Review request for JDK-8145060 Minimizing a
 JInternal frame not shifting focus to frame below it
In-Reply-To: <567D666A.9010008@oracle.com>
References: <6e594a8b-fc5b-4d4d-abfa-ed54d5718323@default>
	<567D666A.9010008@oracle.com>
Message-ID: <7de3ac7e-b723-465e-b179-7bffa38b1eb6@default>

Hello Sergey,

Thanks for the review. I have updated the code.
http://cr.openjdk.java.net/~rchamyal/8145060/webrev.01/

Regards,
Rajeev Chamyal

-----Original Message-----
From: Sergey Bylokhov 
Sent: 25 December 2015 21:23
To: Rajeev Chamyal; Alexander Scherbatiy; Prasanta Sadhukhan; swing-dev at openjdk.java.net
Subject: Re: Review request for JDK-8145060 Minimizing a JInternal frame not shifting focus to frame below it

Hi, Rajeev.
I guess "d.setComponentOrderCheckingEnabled(false);" should be moved also for consistency.

On 14/12/15 08:32, Rajeev Chamyal wrote:
> Hello All,
>
> Please review the following fix for Jdk9:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145060
>
> Webrev:http://cr.openjdk.java.net/~rchamyal/8145060/webrev.00/
>
> Issue: On minimizing the successive internal frames the focus is not 
> shifting to frame below it.
>
> Cause: During minimize internal frame is removed from container. 
> Removal of internal frames from container also removes the internal 
> frame entry from internal frame cache.
>
> During focus shift cache is checked for current internal frame entry 
> and then focus is shifted to frame below it. As removal from container 
> has already updated the cache so
>
> Current frame is not found in cache and focus shift fails.
>
> Fix: Internal frame removal from container is done after focus shift.
>
> Regards,
>
> Rajeev Chamyal
>

--
Best regards, Sergey.

From alexey.ivanov at oracle.com  Mon Dec 28 11:22:37 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 28 Dec 2015 14:22:37 +0300
Subject:  Review request for JDK-4769772
 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong
 state
In-Reply-To: 
References: <34136115-bd25-43f6-bbdd-c98bc1dbfe17@default>
	<567AA5A5.3090901@oracle.com> <567AA83C.9080308@oracle.com>

	<567D39FE.1080906@oracle.com>

Message-ID: <56811B7D.7050700@oracle.com>

Hi Rajeev,

Thank you for updating the code and the test.

Please see my comments inline.

On 28.12.2015 10:37, Rajeev Chamyal wrote:
> Hello Alexey,
>
> Thanks for the review. I have updated the code as suggested.
> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.02/
> Please see response to questions inline.
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Alexey Ivanov
> Sent: 25 December 2015 18:14
> To: Rajeev Chamyal; swing-dev at openjdk.java.net
> Subject: Re:  Review request for JDK-4769772 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong state
>
> Hi Rajeev,
>
> Thank you for updating the code.
>
> I have a couple more questions though.
>
> 1. SynthDesktopPaneUI
> What is the purpose of this line?
>       d.setBounds(r.x, r.y, r.width, r.height);
>
> Since d is a JDesktopPane which contains the frame, you change the location and size of the desktop pane to those of the iconified frame.
> It doesn't seem right to me. Could you please clarify your intention?
> [Rajeev Chamyal] It's a typo updated the code. We need to set bounds for desktopIcon instead of desktop pane.
I suggest moving these lines:

             if (c == null || d == null) {
                  return;
              }

above calculations of desktopIcon position. Why shall we waste time 
calculating the position if we ignore the operation eventually?
>
> 2. dispose() method is never used in the test, so it could be removed.
> [Rajeev Chamyal] Removed from test code.
>
> 3. Since testFailed field is accessed from different threads, it should be marked volatile.
> [Rajeev Chamyal] Test updated to check all LAF. testFailed variable is not used now.
Yet your new errorMessage filed has the same issue. It should be marked 
volatile since it's accessed from different threads without 
synchronization. Actually I suggest storing the exception itself rather 
than the error message only. If exception is null, the test passed, if 
it's not, the test failed and you just print the exception and re-throw 
it to the test framework. What do you think?
>
> 4. robot.delay(1000) in executeTest() is unnecessary, isn't it?
> [Rajeev Chamyal]  As its UI test so added delay for user to check visually as well.
Think about it this way: you have, let's say, 20 automated UI tests 
which are similar to this one. There are five LaFs available on Windows, 
so the test takes at least 12 seconds. Thus you need at least 4 minutes 
to execute all 20 tests which is spent in delays. I don't think it's good.

So I propose to remove all delays. If the test fails, the user could add 
a delay to visually inspect the result of the test.

At the same time, to make test more stable, you should keep

robot.waitForIdle();

after createUI() which was in the test code in the previous webrevs.
>
> 5. You change the code for Synth and Aqua LaF but your test does not cover them. I suggest iterating over all installed LaFs and run the test case in all the LaFs.
> [Rajeev Chamyal]  Updated the test for all LAF's
Does it make it sense to print the current LaF at least for the failed 
test?
>
> 6. Shouldn't test fail if PropertyVetoException is thrown for f.setIcon(true)? I believe it's not expected in this case.
> [Rajeev Chamyal]  Updated code. But this exception is not expected.
Since this exception is not expected, it could be considered a test failure.

Regards,
Alexey
>
> 7. Probably any exception thrown during test execution should also be considered as failure, otherwise catch in executeTest().Runnable{}.run() is redundant.
> [Rajeev Chamyal] Test code is updated to handle all exceptions as failures.
>
> Regards,
> Alexey
>
> On 24.12.2015 10:19, Rajeev Chamyal wrote:
>> Hello Alexey,
>>
>> Thanks for the review.
>> I have updated webrev as per review comments.
>>
>> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.01/
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Alexey Ivanov
>> Sent: 23 December 2015 19:27
>> To: swing-dev at openjdk.java.net
>> Subject: Re:  Review request for JDK-4769772
>> JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong
>> state
>>
>> Hi Rajeev,
>>
>> One more comment:
>> You should call dispose() in finally block in main so that the frame is closed automatically if the test fails.
>>
>> Regards,
>> Alexey
>>
>> On 23.12.2015 16:46, Alexey Ivanov wrote:
>>> Hi Rajeev,
>>>
>>> There's a potential NullPointerException in this line of
>>> BasicInternalFrameUI.java:
>>>       if(value.equals(Boolean.FALSE))
>>>
>>> I suggest eliminating it using this construct:
>>>       if (Boolean.FALSE.equals(value))
>>>
>>> This way the code is safer.
>>>
>>>
>>> Can the test be simplified? Is it really required to create menu and
>>> use robot to invoke commands?
>>> Wouldn't it be enough to programmatically add minimized internal
>>> frame and then check its properties?
>>>
>>> JFrame in test should also be instantiated on EDT, in createUI() method.
>>>
>>>
>>> And a general recommendation to follow Java Coding Style [1] and in
>>> particular to add a space [2] after 'if',  after comma in argument
>>> lists, and after cast operator.
>>>
>>> Regards,
>>> Alexey
>>>
>>> [1] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
>>> [2]
>>> http://www.oracle.com/technetwork/java/javase/documentation/codeconve
>>> n
>>> tions-141388.html#682
>>>
>>> On 18.12.2015 11:44, Rajeev Chamyal wrote:
>>>> Hello All,
>>>>
>>>> Please review the following fix for Jdk9:
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4769772
>>>>
>>>> Webrev:http://cr.openjdk.java.net/~rchamyal/4769772/webrev.00/
>>>> 
>>>>
>>>> Issue: Iconifying a frame before adding it to desktop pane is not
>>>> working.
>>>>
>>>> Cause: Setting setIcon property of a JInternalFrame before addition
>>>> to desktop pane fails to find the desktop as a result its always in
>>>> maximized state.
>>>> Fix: Added method to check if frame is already iconified before
>>>> addition.
>>>> Verified the fix on windows,Ubuntu and Mac with all layouts.
>>>> Also, removed unused imports from JDesktopPane.java as part of fix.
>>>> Regards,
>>>> Rajeev Chamyal
>>>>

From rajeev.chamyal at oracle.com  Mon Dec 28 13:25:19 2015
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Mon, 28 Dec 2015 05:25:19 -0800 (PST)
Subject:  Review request for JDK-4769772
 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong
 state
In-Reply-To: <56811B7D.7050700@oracle.com>
References: <34136115-bd25-43f6-bbdd-c98bc1dbfe17@default>
	<567AA5A5.3090901@oracle.com> <567AA83C.9080308@oracle.com>

	<567D39FE.1080906@oracle.com>

	<56811B7D.7050700@oracle.com>
Message-ID: 

Hello Alexey,

Thanks for the review. I have updated the code.
http://cr.openjdk.java.net/~rchamyal/4769772/webrev.03/

1) I suggest moving these lines:

             if (c == null || d == null) {
                  return;
              }

above calculations of desktopIcon position. Why shall we waste time calculating the position if we ignore the operation eventually?
[Rajeev Chamyal] Updated the code as suggested.

2) Yet your new errorMessage filed has the same issue. It should be marked volatile since it's accessed from different threads without synchronization. Actually I suggest storing the exception itself rather than the error message only. If exception is null, the test passed, if it's not, the test failed and you just print the exception and re-throw it to the test framework. What do you think?
[Rajeev Chamyal] Test updated to make errorMessage volatile. errorMessage stores all exception messages which may occur in different LAFs and on test completion message is thrown with RunTimeException to mark test failure.

3) robot.delay(1000) in executeTest() is unnecessary, isn't it?
[Rajeev Chamyal] Removed the robot.delay and added robot.waitForIdle() call.

4) You change the code for Synth and Aqua LaF but your test does not cover them. I suggest iterating over all installed LaFs and run the test case in all the LaFs.
Does it make it sense to print the current LaF at least for the failed test?
 [Rajeev Chamyal]  Test prints all exception messages along with  failed LaF names on test completion.

5) Shouldn't test fail if PropertyVetoException is thrown for f.setIcon(true)? I believe it's not expected in this case.
 [Rajeev Chamyal]  PropertyVetoException exception is considered test failure.

Regards,
Rajeev Chamyal

-----Original Message-----
From: Alexey Ivanov 
Sent: 28 December 2015 16:53
To: Rajeev Chamyal; swing-dev at openjdk.java.net
Subject: Re:  Review request for JDK-4769772 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong state

Hi Rajeev,

Thank you for updating the code and the test.

Please see my comments inline.

On 28.12.2015 10:37, Rajeev Chamyal wrote:
> Hello Alexey,
>
> Thanks for the review. I have updated the code as suggested.
> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.02/
> Please see response to questions inline.
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Alexey Ivanov
> Sent: 25 December 2015 18:14
> To: Rajeev Chamyal; swing-dev at openjdk.java.net
> Subject: Re:  Review request for JDK-4769772 
> JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong 
> state
>
> Hi Rajeev,
>
> Thank you for updating the code.
>
> I have a couple more questions though.
>
> 1. SynthDesktopPaneUI
> What is the purpose of this line?
>       d.setBounds(r.x, r.y, r.width, r.height);
>
> Since d is a JDesktopPane which contains the frame, you change the location and size of the desktop pane to those of the iconified frame.
> It doesn't seem right to me. Could you please clarify your intention?
> [Rajeev Chamyal] It's a typo updated the code. We need to set bounds for desktopIcon instead of desktop pane.
I suggest moving these lines:

             if (c == null || d == null) {
                  return;
              }

above calculations of desktopIcon position. Why shall we waste time calculating the position if we ignore the operation eventually?
>
> 2. dispose() method is never used in the test, so it could be removed.
> [Rajeev Chamyal] Removed from test code.
>
> 3. Since testFailed field is accessed from different threads, it should be marked volatile.
> [Rajeev Chamyal] Test updated to check all LAF. testFailed variable is not used now.
Yet your new errorMessage filed has the same issue. It should be marked volatile since it's accessed from different threads without synchronization. Actually I suggest storing the exception itself rather than the error message only. If exception is null, the test passed, if it's not, the test failed and you just print the exception and re-throw it to the test framework. What do you think?
>
> 4. robot.delay(1000) in executeTest() is unnecessary, isn't it?
> [Rajeev Chamyal]  As its UI test so added delay for user to check visually as well.
Think about it this way: you have, let's say, 20 automated UI tests which are similar to this one. There are five LaFs available on Windows, so the test takes at least 12 seconds. Thus you need at least 4 minutes to execute all 20 tests which is spent in delays. I don't think it's good.

So I propose to remove all delays. If the test fails, the user could add a delay to visually inspect the result of the test.

At the same time, to make test more stable, you should keep

robot.waitForIdle();

after createUI() which was in the test code in the previous webrevs.
>
> 5. You change the code for Synth and Aqua LaF but your test does not cover them. I suggest iterating over all installed LaFs and run the test case in all the LaFs.
> [Rajeev Chamyal]  Updated the test for all LAF's
Does it make it sense to print the current LaF at least for the failed test?
>
> 6. Shouldn't test fail if PropertyVetoException is thrown for f.setIcon(true)? I believe it's not expected in this case.
> [Rajeev Chamyal]  Updated code. But this exception is not expected.
Since this exception is not expected, it could be considered a test failure.

Regards,
Alexey
>
> 7. Probably any exception thrown during test execution should also be considered as failure, otherwise catch in executeTest().Runnable{}.run() is redundant.
> [Rajeev Chamyal] Test code is updated to handle all exceptions as failures.
>
> Regards,
> Alexey
>
> On 24.12.2015 10:19, Rajeev Chamyal wrote:
>> Hello Alexey,
>>
>> Thanks for the review.
>> I have updated webrev as per review comments.
>>
>> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.01/
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Alexey Ivanov
>> Sent: 23 December 2015 19:27
>> To: swing-dev at openjdk.java.net
>> Subject: Re:  Review request for JDK-4769772
>> JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes 
>> wrong state
>>
>> Hi Rajeev,
>>
>> One more comment:
>> You should call dispose() in finally block in main so that the frame is closed automatically if the test fails.
>>
>> Regards,
>> Alexey
>>
>> On 23.12.2015 16:46, Alexey Ivanov wrote:
>>> Hi Rajeev,
>>>
>>> There's a potential NullPointerException in this line of
>>> BasicInternalFrameUI.java:
>>>       if(value.equals(Boolean.FALSE))
>>>
>>> I suggest eliminating it using this construct:
>>>       if (Boolean.FALSE.equals(value))
>>>
>>> This way the code is safer.
>>>
>>>
>>> Can the test be simplified? Is it really required to create menu and 
>>> use robot to invoke commands?
>>> Wouldn't it be enough to programmatically add minimized internal 
>>> frame and then check its properties?
>>>
>>> JFrame in test should also be instantiated on EDT, in createUI() method.
>>>
>>>
>>> And a general recommendation to follow Java Coding Style [1] and in 
>>> particular to add a space [2] after 'if',  after comma in argument 
>>> lists, and after cast operator.
>>>
>>> Regards,
>>> Alexey
>>>
>>> [1] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
>>> [2]
>>> http://www.oracle.com/technetwork/java/javase/documentation/codeconv
>>> e
>>> n
>>> tions-141388.html#682
>>>
>>> On 18.12.2015 11:44, Rajeev Chamyal wrote:
>>>> Hello All,
>>>>
>>>> Please review the following fix for Jdk9:
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4769772
>>>>
>>>> Webrev:http://cr.openjdk.java.net/~rchamyal/4769772/webrev.00/
>>>> 
>>>>
>>>> Issue: Iconifying a frame before adding it to desktop pane is not 
>>>> working.
>>>>
>>>> Cause: Setting setIcon property of a JInternalFrame before addition 
>>>> to desktop pane fails to find the desktop as a result its always in 
>>>> maximized state.
>>>> Fix: Added method to check if frame is already iconified before 
>>>> addition.
>>>> Verified the fix on windows,Ubuntu and Mac with all layouts.
>>>> Also, removed unused imports from JDesktopPane.java as part of fix.
>>>> Regards,
>>>> Rajeev Chamyal
>>>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 4390 bytes
Desc: not available
URL: 

From Sergey.Bylokhov at oracle.com  Mon Dec 28 13:35:48 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 28 Dec 2015 16:35:48 +0300
Subject:  Review request for 8041894: Test
 javax/swing/JSpinner/8008657/bug8008657.java failed on Mac
In-Reply-To: <3AF15B6F-06D6-4E4A-B8C8-EB68A4DF0379@oracle.com>
References: 
	<567493EC.6030304@oracle.com>
	<3AF15B6F-06D6-4E4A-B8C8-EB68A4DF0379@oracle.com>
Message-ID: <56813AB4.2070503@oracle.com>

Hi, Avik
On 21/12/15 07:17, Avik Niyogi wrote:
> Hi Sergey,
> I verified that the issue is only with Aqua Look and feel and not other
> look and feels.

It will be better to prove it in the test, so the bug will not occur 
again in some other/new L&F.

> The type cast for ComponentOrientation was done in the code just for two
> reasons:
> 1) User readability for the component within the event e.
> 2) The cast for which type it is specified. For example, it can be noted
> that in the older code,

This is unrelated to the code style. The cases which you selected are 
necessary because we pass these values to the replaceEditor(), note that 
parameters of replaceEditor are JComponent, so we must cast in these 
cases. Same for (ComponentOrientation) e.getNewValue() because we pass 
it to applyComponentOrientation(ComponentOrientation), but in case of 
getOldValue it is not necessary because we compare it to null only.

Also please do not remove the empty line before package com.apple.laf;

>
> if ("editor".equals(propertyName)) {
>                      final JComponent oldEditor = *(JComponent)*
> e.getOldValue();
>                      final JComponent newEditor = *(JComponent)*
> e.getNewValue();
>                      ui.replaceEditor(oldEditor, newEditor);
>                      ui.updateEnabledState();
>                  } else if ("componentOrientation".equals(propertyName)) {
>                      ComponentOrientation o
>                              = (ComponentOrientation) e.getNewValue();
>                      if (o != (ComponentOrientation) e.getOldValue()) {
>                          JComponent editor = spinner.getEditor();
>                          if (editor != null) {
>                              editor.applyComponentOrientation(o);
>                          }
>                          spinner.revalidate();
>                          spinner.repaint();
>                      }
> Casting of JComponent is done explicitly for the values there.
> Maintaining same standard
> and scoping out uncertainty seems correct in the context.
>
> With Regards,
> Avik Niyogi
>
>> On 19-Dec-2015, at 4:47 am, Sergey Bylokhov
>> > wrote:
>>
>> Hi, Avik.
>> Looks fine to me. It seems that the cast here is not necessary?
>> if (o != (ComponentOrientation) e.getOldValue())
>>
>> Can you confirm that this bug not affectes our other looks and feels?
>> It will be good to update the test to prove that.
>>
>> On 17/12/15 10:21, Avik Niyogi wrote:
>>>
>>>
>>> Hi All,
>>>
>>> Kindly review the fix for JDK9.
>>> *Bug*:https://bugs.openjdk.java.net/browse/JDK-8041894
>>>
>>> *Webrev*: http://cr.openjdk.java.net/~aniyogi/8041894/webrev.00/
>>>
>>> *Issue*: Test case throws an exception as subcomponents of were not
>>> getting orientation
>>>  property assignment.
>>>
>>> *Cause*: The case where property name as Component orientation not
>>> present to traverse
>>> the property to subcomponents of spinner for Aqua look and feel.
>>>
>>> *Fix*: The else if clause for this property name was added while
>>> checking for for editor to
>>> take charge of applying the component orientation to all subsequent
>>> subcomponents.
>>>
>>> With Regards,
>>> Avik Niyogi
>>
>>
>> --
>> Best regards, Sergey.
>

-- 
Best regards, Sergey.

From alexey.ivanov at oracle.com  Mon Dec 28 13:44:56 2015
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 28 Dec 2015 16:44:56 +0300
Subject:  Review request for JDK-4769772
 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong
 state
In-Reply-To: 
References: <34136115-bd25-43f6-bbdd-c98bc1dbfe17@default>
	<567AA5A5.3090901@oracle.com> <567AA83C.9080308@oracle.com>

	<567D39FE.1080906@oracle.com>

	<56811B7D.7050700@oracle.com>

Message-ID: <56813CD8.4040301@oracle.com>

Hi Rajeev,

The updated version looks good to me.

Regards,
Alexey

On 28.12.2015 16:25, Rajeev Chamyal wrote:
> Hello Alexey,
>
> Thanks for the review. I have updated the code.
> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.03/
>
> 1) I suggest moving these lines:
>
>               if (c == null || d == null) {
>                    return;
>                }
>
> above calculations of desktopIcon position. Why shall we waste time calculating the position if we ignore the operation eventually?
> [Rajeev Chamyal] Updated the code as suggested.
>
> 2) Yet your new errorMessage filed has the same issue. It should be marked volatile since it's accessed from different threads without synchronization. Actually I suggest storing the exception itself rather than the error message only. If exception is null, the test passed, if it's not, the test failed and you just print the exception and re-throw it to the test framework. What do you think?
> [Rajeev Chamyal] Test updated to make errorMessage volatile. errorMessage stores all exception messages which may occur in different LAFs and on test completion message is thrown with RunTimeException to mark test failure.

I got your idea: you iterate over all LaFs accumulating failed LaFs 
rather than fail the test at the first failure.

>
> 3) robot.delay(1000) in executeTest() is unnecessary, isn't it?
> [Rajeev Chamyal] Removed the robot.delay and added robot.waitForIdle() call.
>
>
> 4) You change the code for Synth and Aqua LaF but your test does not cover them. I suggest iterating over all installed LaFs and run the test case in all the LaFs.
> Does it make it sense to print the current LaF at least for the failed test?
>   [Rajeev Chamyal]  Test prints all exception messages along with  failed LaF names on test completion.
>
> 5) Shouldn't test fail if PropertyVetoException is thrown for f.setIcon(true)? I believe it's not expected in this case.
>   [Rajeev Chamyal]  PropertyVetoException exception is considered test failure.
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Alexey Ivanov
> Sent: 28 December 2015 16:53
> To: Rajeev Chamyal; swing-dev at openjdk.java.net
> Subject: Re:  Review request for JDK-4769772 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong state
>
> Hi Rajeev,
>
> Thank you for updating the code and the test.
>
> Please see my comments inline.
>
> On 28.12.2015 10:37, Rajeev Chamyal wrote:
>> Hello Alexey,
>>
>> Thanks for the review. I have updated the code as suggested.
>> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.02/
>> Please see response to questions inline.
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Alexey Ivanov
>> Sent: 25 December 2015 18:14
>> To: Rajeev Chamyal; swing-dev at openjdk.java.net
>> Subject: Re:  Review request for JDK-4769772
>> JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong
>> state
>>
>> Hi Rajeev,
>>
>> Thank you for updating the code.
>>
>> I have a couple more questions though.
>>
>> 1. SynthDesktopPaneUI
>> What is the purpose of this line?
>>        d.setBounds(r.x, r.y, r.width, r.height);
>>
>> Since d is a JDesktopPane which contains the frame, you change the location and size of the desktop pane to those of the iconified frame.
>> It doesn't seem right to me. Could you please clarify your intention?
>> [Rajeev Chamyal] It's a typo updated the code. We need to set bounds for desktopIcon instead of desktop pane.
> I suggest moving these lines:
>
>               if (c == null || d == null) {
>                    return;
>                }
>
> above calculations of desktopIcon position. Why shall we waste time calculating the position if we ignore the operation eventually?
>> 2. dispose() method is never used in the test, so it could be removed.
>> [Rajeev Chamyal] Removed from test code.
>>
>> 3. Since testFailed field is accessed from different threads, it should be marked volatile.
>> [Rajeev Chamyal] Test updated to check all LAF. testFailed variable is not used now.
> Yet your new errorMessage filed has the same issue. It should be marked volatile since it's accessed from different threads without synchronization. Actually I suggest storing the exception itself rather than the error message only. If exception is null, the test passed, if it's not, the test failed and you just print the exception and re-throw it to the test framework. What do you think?
>> 4. robot.delay(1000) in executeTest() is unnecessary, isn't it?
>> [Rajeev Chamyal]  As its UI test so added delay for user to check visually as well.
> Think about it this way: you have, let's say, 20 automated UI tests which are similar to this one. There are five LaFs available on Windows, so the test takes at least 12 seconds. Thus you need at least 4 minutes to execute all 20 tests which is spent in delays. I don't think it's good.
>
> So I propose to remove all delays. If the test fails, the user could add a delay to visually inspect the result of the test.
>
> At the same time, to make test more stable, you should keep
>
> robot.waitForIdle();
>
> after createUI() which was in the test code in the previous webrevs.
>> 5. You change the code for Synth and Aqua LaF but your test does not cover them. I suggest iterating over all installed LaFs and run the test case in all the LaFs.
>> [Rajeev Chamyal]  Updated the test for all LAF's
> Does it make it sense to print the current LaF at least for the failed test?
>> 6. Shouldn't test fail if PropertyVetoException is thrown for f.setIcon(true)? I believe it's not expected in this case.
>> [Rajeev Chamyal]  Updated code. But this exception is not expected.
> Since this exception is not expected, it could be considered a test failure.
>
> Regards,
> Alexey
>> 7. Probably any exception thrown during test execution should also be considered as failure, otherwise catch in executeTest().Runnable{}.run() is redundant.
>> [Rajeev Chamyal] Test code is updated to handle all exceptions as failures.
>>
>> Regards,
>> Alexey
>>
>> On 24.12.2015 10:19, Rajeev Chamyal wrote:
>>> Hello Alexey,
>>>
>>> Thanks for the review.
>>> I have updated webrev as per review comments.
>>>
>>> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.01/
>>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Alexey Ivanov
>>> Sent: 23 December 2015 19:27
>>> To: swing-dev at openjdk.java.net
>>> Subject: Re:  Review request for JDK-4769772
>>> JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes
>>> wrong state
>>>
>>> Hi Rajeev,
>>>
>>> One more comment:
>>> You should call dispose() in finally block in main so that the frame is closed automatically if the test fails.
>>>
>>> Regards,
>>> Alexey
>>>
>>> On 23.12.2015 16:46, Alexey Ivanov wrote:
>>>> Hi Rajeev,
>>>>
>>>> There's a potential NullPointerException in this line of
>>>> BasicInternalFrameUI.java:
>>>>        if(value.equals(Boolean.FALSE))
>>>>
>>>> I suggest eliminating it using this construct:
>>>>        if (Boolean.FALSE.equals(value))
>>>>
>>>> This way the code is safer.
>>>>
>>>>
>>>> Can the test be simplified? Is it really required to create menu and
>>>> use robot to invoke commands?
>>>> Wouldn't it be enough to programmatically add minimized internal
>>>> frame and then check its properties?
>>>>
>>>> JFrame in test should also be instantiated on EDT, in createUI() method.
>>>>
>>>>
>>>> And a general recommendation to follow Java Coding Style [1] and in
>>>> particular to add a space [2] after 'if',  after comma in argument
>>>> lists, and after cast operator.
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>> [1] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
>>>> [2]
>>>> http://www.oracle.com/technetwork/java/javase/documentation/codeconv
>>>> e
>>>> n
>>>> tions-141388.html#682
>>>>
>>>> On 18.12.2015 11:44, Rajeev Chamyal wrote:
>>>>> Hello All,
>>>>>
>>>>> Please review the following fix for Jdk9:
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4769772
>>>>>
>>>>> Webrev:http://cr.openjdk.java.net/~rchamyal/4769772/webrev.00/
>>>>> 
>>>>>
>>>>> Issue: Iconifying a frame before adding it to desktop pane is not
>>>>> working.
>>>>>
>>>>> Cause: Setting setIcon property of a JInternalFrame before addition
>>>>> to desktop pane fails to find the desktop as a result its always in
>>>>> maximized state.
>>>>> Fix: Added method to check if frame is already iconified before
>>>>> addition.
>>>>> Verified the fix on windows,Ubuntu and Mac with all layouts.
>>>>> Also, removed unused imports from JDesktopPane.java as part of fix.
>>>>> Regards,
>>>>> Rajeev Chamyal
>>>>>

From Sergey.Bylokhov at oracle.com  Tue Dec 29 14:17:53 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 29 Dec 2015 17:17:53 +0300
Subject:  Review request for JDK-8145060 Minimizing a
 JInternal frame not shifting focus to frame below it
In-Reply-To: <7de3ac7e-b723-465e-b179-7bffa38b1eb6@default>
References: <6e594a8b-fc5b-4d4d-abfa-ed54d5718323@default>
	<567D666A.9010008@oracle.com>
	<7de3ac7e-b723-465e-b179-7bffa38b1eb6@default>
Message-ID: <56829611.2030704@oracle.com>

On 28/12/15 10:45, Rajeev Chamyal wrote:
> Hello Sergey,
>
> Thanks for the review. I have updated the code.
> http://cr.openjdk.java.net/~rchamyal/8145060/webrev.01/

This patch has some additional changes.

>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: 25 December 2015 21:23
> To: Rajeev Chamyal; Alexander Scherbatiy; Prasanta Sadhukhan; swing-dev at openjdk.java.net
> Subject: Re: Review request for JDK-8145060 Minimizing a JInternal frame not shifting focus to frame below it
>
> Hi, Rajeev.
> I guess "d.setComponentOrderCheckingEnabled(false);" should be moved also for consistency.
>
> On 14/12/15 08:32, Rajeev Chamyal wrote:
>> Hello All,
>>
>> Please review the following fix for Jdk9:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145060
>>
>> Webrev:http://cr.openjdk.java.net/~rchamyal/8145060/webrev.00/
>>
>> Issue: On minimizing the successive internal frames the focus is not
>> shifting to frame below it.
>>
>> Cause: During minimize internal frame is removed from container.
>> Removal of internal frames from container also removes the internal
>> frame entry from internal frame cache.
>>
>> During focus shift cache is checked for current internal frame entry
>> and then focus is shifted to frame below it. As removal from container
>> has already updated the cache so
>>
>> Current frame is not found in cache and focus shift fails.
>>
>> Fix: Internal frame removal from container is done after focus shift.
>>
>> Regards,
>>
>> Rajeev Chamyal
>>
>
>
> --
> Best regards, Sergey.
>

-- 
Best regards, Sergey.

From rajeev.chamyal at oracle.com  Wed Dec 30 07:26:21 2015
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Tue, 29 Dec 2015 23:26:21 -0800 (PST)
Subject:  Review request for JDK-4769772
 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong
 state
In-Reply-To: <56813CD8.4040301@oracle.com>
References: <34136115-bd25-43f6-bbdd-c98bc1dbfe17@default>
	<567AA5A5.3090901@oracle.com> <567AA83C.9080308@oracle.com>

	<567D39FE.1080906@oracle.com>

	<56811B7D.7050700@oracle.com>

	<56813CD8.4040301@oracle.com>
Message-ID: <582d26a5-e3d9-4904-9d43-e8385fc8d928@default>

Hello All,

I need one more review for this webrev.
http://cr.openjdk.java.net/~rchamyal/4769772/webrev.03/

Regards,
Rajeev Chamyal

-----Original Message-----
From: Alexey Ivanov 
Sent: 28 December 2015 19:15
To: Rajeev Chamyal; swing-dev at openjdk.java.net
Subject: Re:  Review request for JDK-4769772 JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong state

Hi Rajeev,

The updated version looks good to me.

Regards,
Alexey

On 28.12.2015 16:25, Rajeev Chamyal wrote:
> Hello Alexey,
>
> Thanks for the review. I have updated the code.
> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.03/
>
> 1) I suggest moving these lines:
>
>               if (c == null || d == null) {
>                    return;
>                }
>
> above calculations of desktopIcon position. Why shall we waste time calculating the position if we ignore the operation eventually?
> [Rajeev Chamyal] Updated the code as suggested.
>
> 2) Yet your new errorMessage filed has the same issue. It should be marked volatile since it's accessed from different threads without synchronization. Actually I suggest storing the exception itself rather than the error message only. If exception is null, the test passed, if it's not, the test failed and you just print the exception and re-throw it to the test framework. What do you think?
> [Rajeev Chamyal] Test updated to make errorMessage volatile. errorMessage stores all exception messages which may occur in different LAFs and on test completion message is thrown with RunTimeException to mark test failure.

I got your idea: you iterate over all LaFs accumulating failed LaFs rather than fail the test at the first failure.

>
> 3) robot.delay(1000) in executeTest() is unnecessary, isn't it?
> [Rajeev Chamyal] Removed the robot.delay and added robot.waitForIdle() call.
>
>
> 4) You change the code for Synth and Aqua LaF but your test does not cover them. I suggest iterating over all installed LaFs and run the test case in all the LaFs.
> Does it make it sense to print the current LaF at least for the failed test?
>   [Rajeev Chamyal]  Test prints all exception messages along with  failed LaF names on test completion.
>
> 5) Shouldn't test fail if PropertyVetoException is thrown for f.setIcon(true)? I believe it's not expected in this case.
>   [Rajeev Chamyal]  PropertyVetoException exception is considered test failure.
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Alexey Ivanov
> Sent: 28 December 2015 16:53
> To: Rajeev Chamyal; swing-dev at openjdk.java.net
> Subject: Re:  Review request for JDK-4769772 
> JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes wrong 
> state
>
> Hi Rajeev,
>
> Thank you for updating the code and the test.
>
> Please see my comments inline.
>
> On 28.12.2015 10:37, Rajeev Chamyal wrote:
>> Hello Alexey,
>>
>> Thanks for the review. I have updated the code as suggested.
>> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.02/
>> Please see response to questions inline.
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Alexey Ivanov
>> Sent: 25 December 2015 18:14
>> To: Rajeev Chamyal; swing-dev at openjdk.java.net
>> Subject: Re:  Review request for JDK-4769772
>> JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes 
>> wrong state
>>
>> Hi Rajeev,
>>
>> Thank you for updating the code.
>>
>> I have a couple more questions though.
>>
>> 1. SynthDesktopPaneUI
>> What is the purpose of this line?
>>        d.setBounds(r.x, r.y, r.width, r.height);
>>
>> Since d is a JDesktopPane which contains the frame, you change the location and size of the desktop pane to those of the iconified frame.
>> It doesn't seem right to me. Could you please clarify your intention?
>> [Rajeev Chamyal] It's a typo updated the code. We need to set bounds for desktopIcon instead of desktop pane.
> I suggest moving these lines:
>
>               if (c == null || d == null) {
>                    return;
>                }
>
> above calculations of desktopIcon position. Why shall we waste time calculating the position if we ignore the operation eventually?
>> 2. dispose() method is never used in the test, so it could be removed.
>> [Rajeev Chamyal] Removed from test code.
>>
>> 3. Since testFailed field is accessed from different threads, it should be marked volatile.
>> [Rajeev Chamyal] Test updated to check all LAF. testFailed variable is not used now.
> Yet your new errorMessage filed has the same issue. It should be marked volatile since it's accessed from different threads without synchronization. Actually I suggest storing the exception itself rather than the error message only. If exception is null, the test passed, if it's not, the test failed and you just print the exception and re-throw it to the test framework. What do you think?
>> 4. robot.delay(1000) in executeTest() is unnecessary, isn't it?
>> [Rajeev Chamyal]  As its UI test so added delay for user to check visually as well.
> Think about it this way: you have, let's say, 20 automated UI tests which are similar to this one. There are five LaFs available on Windows, so the test takes at least 12 seconds. Thus you need at least 4 minutes to execute all 20 tests which is spent in delays. I don't think it's good.
>
> So I propose to remove all delays. If the test fails, the user could add a delay to visually inspect the result of the test.
>
> At the same time, to make test more stable, you should keep
>
> robot.waitForIdle();
>
> after createUI() which was in the test code in the previous webrevs.
>> 5. You change the code for Synth and Aqua LaF but your test does not cover them. I suggest iterating over all installed LaFs and run the test case in all the LaFs.
>> [Rajeev Chamyal]  Updated the test for all LAF's
> Does it make it sense to print the current LaF at least for the failed test?
>> 6. Shouldn't test fail if PropertyVetoException is thrown for f.setIcon(true)? I believe it's not expected in this case.
>> [Rajeev Chamyal]  Updated code. But this exception is not expected.
> Since this exception is not expected, it could be considered a test failure.
>
> Regards,
> Alexey
>> 7. Probably any exception thrown during test execution should also be considered as failure, otherwise catch in executeTest().Runnable{}.run() is redundant.
>> [Rajeev Chamyal] Test code is updated to handle all exceptions as failures.
>>
>> Regards,
>> Alexey
>>
>> On 24.12.2015 10:19, Rajeev Chamyal wrote:
>>> Hello Alexey,
>>>
>>> Thanks for the review.
>>> I have updated webrev as per review comments.
>>>
>>> http://cr.openjdk.java.net/~rchamyal/4769772/webrev.01/
>>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Alexey Ivanov
>>> Sent: 23 December 2015 19:27
>>> To: swing-dev at openjdk.java.net
>>> Subject: Re:  Review request for JDK-4769772
>>> JInternalFrame.setIcon(true) before JDesktopPane.add(JIF) causes 
>>> wrong state
>>>
>>> Hi Rajeev,
>>>
>>> One more comment:
>>> You should call dispose() in finally block in main so that the frame is closed automatically if the test fails.
>>>
>>> Regards,
>>> Alexey
>>>
>>> On 23.12.2015 16:46, Alexey Ivanov wrote:
>>>> Hi Rajeev,
>>>>
>>>> There's a potential NullPointerException in this line of
>>>> BasicInternalFrameUI.java:
>>>>        if(value.equals(Boolean.FALSE))
>>>>
>>>> I suggest eliminating it using this construct:
>>>>        if (Boolean.FALSE.equals(value))
>>>>
>>>> This way the code is safer.
>>>>
>>>>
>>>> Can the test be simplified? Is it really required to create menu 
>>>> and use robot to invoke commands?
>>>> Wouldn't it be enough to programmatically add minimized internal 
>>>> frame and then check its properties?
>>>>
>>>> JFrame in test should also be instantiated on EDT, in createUI() method.
>>>>
>>>>
>>>> And a general recommendation to follow Java Coding Style [1] and in 
>>>> particular to add a space [2] after 'if',  after comma in argument 
>>>> lists, and after cast operator.
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>> [1] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
>>>> [2]
>>>> http://www.oracle.com/technetwork/java/javase/documentation/codecon
>>>> v
>>>> e
>>>> n
>>>> tions-141388.html#682
>>>>
>>>> On 18.12.2015 11:44, Rajeev Chamyal wrote:
>>>>> Hello All,
>>>>>
>>>>> Please review the following fix for Jdk9:
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4769772
>>>>>
>>>>> Webrev:http://cr.openjdk.java.net/~rchamyal/4769772/webrev.00/
>>>>> 
>>>>>
>>>>> Issue: Iconifying a frame before adding it to desktop pane is not 
>>>>> working.
>>>>>
>>>>> Cause: Setting setIcon property of a JInternalFrame before 
>>>>> addition to desktop pane fails to find the desktop as a result its 
>>>>> always in maximized state.
>>>>> Fix: Added method to check if frame is already iconified before 
>>>>> addition.
>>>>> Verified the fix on windows,Ubuntu and Mac with all layouts.
>>>>> Also, removed unused imports from JDesktopPane.java as part of fix.
>>>>> Regards,
>>>>> Rajeev Chamyal
>>>>>

From rajeev.chamyal at oracle.com  Wed Dec 30 07:30:45 2015
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Tue, 29 Dec 2015 23:30:45 -0800 (PST)
Subject:  Review request for JDK-8145896 JInternalFrame
 setMaximum before adding to desktop throws null pointer exception
In-Reply-To: <567AAC2C.4060203@oracle.com>
References: 
	<567AAC2C.4060203@oracle.com>
Message-ID: <55a23711-f731-458d-a4f9-c88718db88d8@default>

Hello All,

I need one more review for this webrev.

HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8145896/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8145896/webrev.00/

Regards,

Rajeev Chamyal

From: Alexander Scherbatiy 
Sent: 23 December 2015 19:44
To: Rajeev Chamyal
Cc: Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
Subject: Re: Review request for JDK-8145896 JInternalFrame setMaximum before adding to desktop throws null pointer exception

  The fix looks good to me.

  Thanks,
  Alexandr.

On 12/21/2015 3:09 PM, Rajeev Chamyal wrote:

Hello All,

Please review the following fix for Jdk9:

Bug: https://bugs.openjdk.java.net/browse/JDK-8145896

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8145896/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8145896/webrev.00/

Issue: JInternalFrame setMaximum before adding to desktop throws null pointer exception

Cause: Null checks for parent and Desktop pane are missing

Fix: Added null checks for parent and desktop pane.

Verified the fix on windows,Ubuntu and Mac with all supported LAF.

Regards,
Rajeev Chamyal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rajeev.chamyal at oracle.com  Wed Dec 30 08:03:04 2015
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Wed, 30 Dec 2015 00:03:04 -0800 (PST)
Subject:  Review request for JDK-8145060 Minimizing a
 JInternal frame not shifting focus to frame below it
In-Reply-To: <56829611.2030704@oracle.com>
References: <6e594a8b-fc5b-4d4d-abfa-ed54d5718323@default>
	<567D666A.9010008@oracle.com>
	<7de3ac7e-b723-465e-b179-7bffa38b1eb6@default>
	<56829611.2030704@oracle.com>
Message-ID: 

Hello Sergey,

I have updated the webrev.
http://cr.openjdk.java.net/~rchamyal/8145060/webrev.01/

Regards,
Rajeev Chamyal

-----Original Message-----
From: Sergey Bylokhov 
Sent: 29 December 2015 19:48
To: Rajeev Chamyal; Alexander Scherbatiy; Prasanta Sadhukhan; swing-dev at openjdk.java.net
Subject: Re: Review request for JDK-8145060 Minimizing a JInternal frame not shifting focus to frame below it

On 28/12/15 10:45, Rajeev Chamyal wrote:
> Hello Sergey,
>
> Thanks for the review. I have updated the code.
> http://cr.openjdk.java.net/~rchamyal/8145060/webrev.01/

This patch has some additional changes.

>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: 25 December 2015 21:23
> To: Rajeev Chamyal; Alexander Scherbatiy; Prasanta Sadhukhan; 
> swing-dev at openjdk.java.net
> Subject: Re: Review request for JDK-8145060 Minimizing a JInternal 
> frame not shifting focus to frame below it
>
> Hi, Rajeev.
> I guess "d.setComponentOrderCheckingEnabled(false);" should be moved also for consistency.
>
> On 14/12/15 08:32, Rajeev Chamyal wrote:
>> Hello All,
>>
>> Please review the following fix for Jdk9:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145060
>>
>> Webrev:http://cr.openjdk.java.net/~rchamyal/8145060/webrev.00/
>>
>> Issue: On minimizing the successive internal frames the focus is not 
>> shifting to frame below it.
>>
>> Cause: During minimize internal frame is removed from container.
>> Removal of internal frames from container also removes the internal 
>> frame entry from internal frame cache.
>>
>> During focus shift cache is checked for current internal frame entry 
>> and then focus is shifted to frame below it. As removal from 
>> container has already updated the cache so
>>
>> Current frame is not found in cache and focus shift fails.
>>
>> Fix: Internal frame removal from container is done after focus shift.
>>
>> Regards,
>>
>> Rajeev Chamyal
>>
>
>
> --
> Best regards, Sergey.
>

--
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Dec 30 14:54:58 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 30 Dec 2015 17:54:58 +0300
Subject:  Review request for JDK-8145060 Minimizing a
 JInternal frame not shifting focus to frame below it
In-Reply-To: 
References: <6e594a8b-fc5b-4d4d-abfa-ed54d5718323@default>
	<567D666A.9010008@oracle.com>
	<7de3ac7e-b723-465e-b179-7bffa38b1eb6@default>
	<56829611.2030704@oracle.com>

Message-ID: <5683F042.2040804@oracle.com>

Looks fine.

On 30/12/15 11:03, Rajeev Chamyal wrote:
> Hello Sergey,
>
> I have updated the webrev.
> http://cr.openjdk.java.net/~rchamyal/8145060/webrev.01/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: 29 December 2015 19:48
> To: Rajeev Chamyal; Alexander Scherbatiy; Prasanta Sadhukhan; swing-dev at openjdk.java.net
> Subject: Re: Review request for JDK-8145060 Minimizing a JInternal frame not shifting focus to frame below it
>
> On 28/12/15 10:45, Rajeev Chamyal wrote:
>> Hello Sergey,
>>
>> Thanks for the review. I have updated the code.
>> http://cr.openjdk.java.net/~rchamyal/8145060/webrev.01/
>
> This patch has some additional changes.
>
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: 25 December 2015 21:23
>> To: Rajeev Chamyal; Alexander Scherbatiy; Prasanta Sadhukhan;
>> swing-dev at openjdk.java.net
>> Subject: Re: Review request for JDK-8145060 Minimizing a JInternal
>> frame not shifting focus to frame below it
>>
>> Hi, Rajeev.
>> I guess "d.setComponentOrderCheckingEnabled(false);" should be moved also for consistency.
>>
>> On 14/12/15 08:32, Rajeev Chamyal wrote:
>>> Hello All,
>>>
>>> Please review the following fix for Jdk9:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145060
>>>
>>> Webrev:http://cr.openjdk.java.net/~rchamyal/8145060/webrev.00/
>>>
>>> Issue: On minimizing the successive internal frames the focus is not
>>> shifting to frame below it.
>>>
>>> Cause: During minimize internal frame is removed from container.
>>> Removal of internal frames from container also removes the internal
>>> frame entry from internal frame cache.
>>>
>>> During focus shift cache is checked for current internal frame entry
>>> and then focus is shifted to frame below it. As removal from
>>> container has already updated the cache so
>>>
>>> Current frame is not found in cache and focus shift fails.
>>>
>>> Fix: Internal frame removal from container is done after focus shift.
>>>
>>> Regards,
>>>
>>> Rajeev Chamyal
>>>
>>
>>
>> --
>> Best regards, Sergey.
>>
>
>
> --
> Best regards, Sergey.
>

-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Dec 30 15:04:19 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 30 Dec 2015 18:04:19 +0300
Subject:  Review request for JDK-8145896 JInternalFrame
 setMaximum before adding to desktop throws null pointer exception
In-Reply-To: <55a23711-f731-458d-a4f9-c88718db88d8@default>
References: 
	<567AAC2C.4060203@oracle.com>
	<55a23711-f731-458d-a4f9-c88718db88d8@default>
Message-ID: <5683F273.2000808@oracle.com>

Hi, Rajeev.
A few notes:
- The "Rectangle desktopBounds = f.getParent().getBounds();" can reuse 
the new "c" variable.
- Is the "JDesktopPane d = f.getDesktopPane();" is necessary? It seems 
that it is not used after the null check.

On 30/12/15 10:30, Rajeev Chamyal wrote:
> Hello All,
>
> I need one more review for this webrev.
>
> http://cr.openjdk.java.net/~rchamyal/8145896/webrev.00/
> 
>
> Regards,
>
> Rajeev Chamyal
>
> *From:*Alexander Scherbatiy
> *Sent:* 23 December 2015 19:44
> *To:* Rajeev Chamyal
> *Cc:* Sergey Bylokhov; Prasanta Sadhukhan; swing-dev at openjdk.java.net
> *Subject:* Re: Review request for JDK-8145896 JInternalFrame setMaximum
> before adding to desktop throws null pointer exception
>
>
>    The fix looks good to me.
>
>    Thanks,
>    Alexandr.
>
> On 12/21/2015 3:09 PM, Rajeev Chamyal wrote:
>
>     Hello All,
>
>     Please review the following fix for Jdk9:
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8145896
>
>     Webrev:http://cr.openjdk.java.net/~rchamyal/8145896/webrev.00/
>     
>
>     Issue: JInternalFrame setMaximum before adding to desktop throws
>     null pointer exception
>
>     Cause: Null checks for parent and Desktop pane are missing
>
>     Fix: Added null checks for parent and desktop pane.
>
>     Verified the fix on windows,Ubuntu and Mac with all supported LAF.
>
>     Regards,
>
>     Rajeev Chamyal
>

-- 
Best regards, Sergey.