Re: swing-dev Digest, Vol 122, Issue 16

[Avik Niyogi]

Fix looks good to me.

> On 14-Jun-2017, at 5:30 pm, swing-dev-requ...@openjdk.java.net wrote:
> 
> Date: Wed, 14 Jun 2017 12:34:04 +0530
> From: Alexander Zvegintsev  >
> To: Prasanta Sadhukhan  >, Sergey
>   Bylokhov  >
> Cc: swing-dev@openjdk.java.net 
> Subject: Re:  [10] RFR: JDK-8043315: Nimbus: Setting
>   Nimbus.Overrides property affects custom keymap installation
> Message-ID: <67b025e2-2134-a1fb-8769-078ff1f14...@oracle.com 
> >
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Hi Prasanta,
> 
>> If app again calls setKeymap(null) then the static variable will be 
>> "true" and it will reset back to default keymap. 
> It doesn't seem to be relevant to this fix. setKeymap(): " Setting to 
> null effectively disables keyboard input." As it does with 
> you fix.
> 
> Otherwise the fix looks good to me.
> 
> Thanks,
> Alexander.
> 
> On 02/06/2017 13:59, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>> 
>> I have modified webrev to remove static keyword and made the test 
>> automated
>> http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.01/ 
>> 
>> Updated fix tests if app has fired a property change by calling 
>> setKeymap() then it will not uninstall custom keymap and let the 
>> custom keymap be honoured. If app again calls setKeymap(null) then the 
>> static variable will be "true" and it will reset back to default keymap.
>> 
>> Regards
>> Prasanta
>> On 6/2/2017 12:07 AM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Can you please clarify the fix a little bit.
>>> You have a static variable, which is set to "false" when the listener 
>>> for "keymap" is triggered, and it seems that you never set it back to 
>>> "true"? Is it intentional behavior?
>>> Note that if there are a few objects of "SynthEditorPaneUI" then they 
>>> will share this static field. Also it seems that the test can be 
>>> automated, because currently it is requires from the user to press 
>>> only one button("space").
>>> 
>>> - prasanta.sadhuk...@oracle.com  
>>> wrote:
>>> 
 Hi All,
 
 Please review a bug fix for Nimbus L where if app sets custom keymap
 
 and then sets Nimbus.Overrides property,
 then the custom keymap is not honoured.
 For example, if testapp sets a new action for "space" key press and
 sets
 sets Nimbus.Overrides property,
   it will not be honoured and default action ie. inserting a "space"
 character will be done.
 
 Issue was NimbusLookAndFeel#shouldUpdateStyleOnEvent() returns true
 for
 Nimbus.Override property which causes SynthEditorPaneUI#updateStyle()
 to
 be called which
 uninstall set keyboard actions and sets up default keyboard action.
 
 Proposed fix is to check if a keymap is already set (a propertyChange
 
 event will be fired for when app calls setKeyMap()) then do not reset
 to
 default keymap.
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8043315 
 
 webrev: http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.00/ 
 
 
 Regards
 Prasanta
>> 
> 

Re: [10] RFR: JDK-8181782:[TESTBUG] [Macosx] JTextAreaEmojiTest is not executed

[Avik Niyogi]

Fix looks good to me.

> On 13-Jun-2017, at 5:30 pm, swing-dev-requ...@openjdk.java.net wrote:
> 
> Date: Mon, 12 Jun 2017 07:21:13 -0700 (PDT)
> From: Sreeprakash Sreedharan  >
> To: Prasanta Sadhukhan  >,
>   swing-dev@openjdk.java.net 
> Subject: Re:  [10] RFR: JDK-8181782:[TESTBUG] [Macosx]
>   JTextAreaEmojiTest is not executed
> Message-ID: <9c1fbf5c-e872-414e-84c1-fa533a21e1aa@default>
> Content-Type: text/plain; charset=utf-8
> 
> Thanks for the inputs, Prasanta. 
> 
> I have incorporated the changes mentioned.
> 
> Updated Webrev :  http://cr.openjdk.java.net/~rpatil/8181782/webrev.01 
> 
> 
> Regards,
> Sreeprakash
> 
> -Original Message-
> From: Prasanta Sadhukhan 
> Sent: Monday, June 12, 2017 2:55 PM
> To: Sreeprakash Sreedharan  >; swing-dev@openjdk.java.net 
> 
> Subject: Re:  [10] RFR: JDK-8181782:[TESTBUG] [Macosx] 
> JTextAreaEmojiTest is not executed
> 
> It seems the test is waiting infinitely instead of having a timeout. I amnot 
> sure of jtreg timeout but it's better to rely on test's own timeout, so 
> await(timeout) is a better call .
> 
> Also, please add @key headful tag to the test.
> 
> Regards
> Prasanta
> On 6/9/2017 1:38 AM, Sreeprakash Sreedharan wrote:
>> Hi All,
>> 
>> Kindly review the fix for JDK10.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181782 
>> 
>> 
>> Webrev: http://cr.openjdk.java.net/~rpatil/8181782/webrev.00 
>> 
>> 
>> Issue: JTREG was not executing the manual test JTextAreaEmojiTest and was 
>> always giving a passed result.
>> 
>> Fix: Made sure that main function waits for pass/fail events using a 
>> countdown latch and also added manual to the run tag
>> 
>> Regards,
>> Sreeprakash
> 

Re: swing-dev Digest, Vol 121, Issue 19

[Avik Niyogi]

+1
 With Regards,
Avik Niyogi

> On 30-May-2017, at 10:30 pm, swing-dev-requ...@openjdk.java.net wrote:
> 
> Date: Mon, 29 May 2017 11:49:45 +0530
> From: Prasanta Sadhukhan <prasanta.sadhuk...@oracle.com 
> <mailto:prasanta.sadhuk...@oracle.com>>
> To: Sergey Bylokhov <sergey.bylok...@oracle.com 
> <mailto:sergey.bylok...@oracle.com>>
> Cc: swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net>
> Subject: Re:  [10] RFR: JDK-8075918:The regression-swing
>   case failed as the long Tab titles are not clipped with dots at the
>   end with NimbusLookAndFeel
> Message-ID: <e298e783-8cfe-df17-9223-bbecd4b73...@oracle.com 
> <mailto:e298e783-8cfe-df17-9223-bbecd4b73...@oracle.com>>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> I tried to incorporate your comments. Please find modified webrev
> 
> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/ 
> <http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/>
> 
> Regards
> Prasanta
> On 5/28/2017 8:01 AM, Sergey Bylokhov wrote:
>> Note that you shouldn't replace the clip, but should apply the new clip on 
>> top of the old. This is necessary if the old clip is smaller than new.
>> 
>> - sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com> wrote:
>> 
>>> Hi, Prasanta.
>>> 
>>> BasicTabbedPaneUI.paintIcon() as well as
>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>  - paintText() at line 681
>>>  - paintIcon() at line 634
>>> Both methods have a rectangle as a parameter, but it is ignored.
>>> 
>>> - prasanta.sadhuk...@oracle.com <mailto:prasanta.sadhuk...@oracle.com> 
>>> wrote:
>>> 
>>>> Hi Sergey,
>>>> 
>>>> I could get your concern for paintText() but could not find
>>>> paintIcon()
>>>> in SynthGraphicsUtils() so not sure how icon drawing contradicts
>>>> spec.
>>>> Modified webrev:
>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/ 
>>>> <http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/>
>>>> 
>>>> Also, if we are not calling SwingUtilities2.clipStringIfNecessary()
>>>> then
>>>> we are not going to get "..." at the end which this test expects.
>>> But
>>>> I
>>>> could not find anything in spec, that mandates ending with "..." for
>>>> long tab outside
>>>> tab bounds. If source change is ok, I guess we then need to modify
>>> the
>>>> html file modifying the expected result for NimbusL
>>>> 
>>>> Regards
>>>> Prasanta
>>>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>> Please take a look to my comments at:
>>>>> 
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html 
>>> <http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html>
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html 
>>> <http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html>
>>>>> The two methods paintText() and paintIcon() are contradict the
>>> spec
>>>> and draw the text and icons outside of the tab.
>>>>> - prasanta.sadhuk...@oracle.com 
>>>>> <mailto:prasanta.sadhuk...@oracle.com> wrote:
>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> Please review a fix for an issue where long Tab titiles are not
>>>>>> clipped
>>>>>> with dots at end for NimbusLookAndFeel L
>>>>>> Other L works ok.
>>>>>> 
>>>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
>>>> clipped
>>>>>> but
>>>>>> passed to paintText() as it is received.
>>>>>> Other L such as Metal, Motif, Windows which uses
>>>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
>>>>>> 
>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
>>>  
>>> <http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950>
>>>>>> before it is passed to paintText().
>>>>>> 
>>>>>> Proposed fix is to do the same for SynthTabbedPaneUI#paintTab().
>>>>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8075918>
>>>>>> webrev:
>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/ 
>>> <http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/>
>>>>>> Regards
>>>>>> Prasanta
> 

Re: [10] RFR JDK-6461834: Minimize WindowsLookAndFeel classes included with Unix JDKs

[Avik Niyogi]

+1

> On 24-May-2017, at 3:30 pm, swing-dev-requ...@openjdk.java.net wrote:
> 
> Date: Tue, 23 May 2017 14:29:16 +0530
> From: Prasanta Sadhukhan  >
> To: Phil Race >, 
> Magnus Ihse Bursie
>   >, 
> build-...@openjdk.java.net ,
>   "swing-dev@openjdk.java.net " 
> >
> Subject: Re:  [10] RFR JDK-6461834: Minimize
>   WindowsLookAndFeel classes included with Unix JDKs
> Message-ID: <2f126747-6659-813a-f006-a6d543391...@oracle.com 
> >
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> I got +1 from build. I need one more +1.
> 
> Any further comment/objection on this changeset? else Can I commit this?
> 
> Regards
> Prasanta
> On 5/18/2017 1:31 PM, Prasanta Sadhukhan wrote:
>> So far I have looked, it seems jdk.jconsole uses this classes for 
>> windows only. These classes are specified in
>> JConsole.java where it checks (for non-windows, it will come as 
>> GTKLookAndFeel)
>> 
>> String systemLaF = UIManager.getSystemLookAndFeelClassName();
>> if (systemLaF.equals("com.sun.java.swing.plaf.gtk.GTKLookAndFeel") ||
>> systemLaF.equals("com.sun.java.swing.plaf.windows.WindowsLookAndFeel")) {
>> 
>> try {
>> UIManager.setLookAndFeel(systemLaF); MaximizableInternalFrame.java 
>> where it checks for this classes in windows only if (JConsole.IS_WIN) {
>> try {
>> Class Part =
>> Class.forName("com.sun.java.swing.plaf.windows.TMSchema$Part"); and 
>> Utilities.java where it checks LookAndFeel laf = 
>> UIManager.getLookAndFeel();
>> boolean transparent = laf.getClass().getName().equals(windowsLaF);
>> 
>> Modified webrev
>> http://cr.openjdk.java.net/~psadhukhan/6461834/01/ 
>> 
>> 
>> Regards
>> Prasanta
>> 
>> On 5/18/2017 12:36 AM, Phil Race wrote:
>>> The way to do this is to create a file
>>> src/java.desktop/windows/classes/module-info.java.extra
>>> 
>>> and move the opens there.
>>> 
>>> See for example
>>> src/java.base/windows/classes/module-info.java.extra
>>> 
>>> But are you sure jdk.jconsole needs these only on Windows ?
>>> Better make sure of it.
>>> 
>>> -phil.
>>> 
>>> On 05/17/2017 03:49 AM, Prasanta Sadhukhan wrote:
 Yes, actually I am bit unsure of how to proceed with that. It is 
 meant to open internal java.desktop classes "only" to jdk.jconsole 
 but now afer this fix, these classes will only be available in 
 windows platform, so it should be a conditional "open" and I am not 
 sure if module-info.java allows conditional open.
 
 Regards
 Prasanta
 On 5/17/2017 4:16 PM, Magnus Ihse Bursie wrote:
> Build changes looks good. However in 
> src/java.desktop/share/classes/module-info.java you are trying to 
> check in commented-out code instead of removing it.
> 
> /Magnus
> 
> On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
>> Hi All,
>> 
>> Please review a fix for an issue whereby it is seen that 
>> WindowsLookAndFeel classes are built for non-windows platform,
>> where it is not needed.
>> Proposed fix is to remove building these classes for non-windows 
>> platform.
>> 
>> JPRT build is successful. Also, fixed the regression tests which 
>> expects this classes to be available in non-unix platform.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834 
>> 
>> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/ 
>> 
>> 
>> There are some closed regression test which will be taken care 
>> after this in a separate crucible review.
>> 
>> Regards
>> Prasanta
> 
 
>>> 
>> 
> 

Re: [10] RFR JDK-7042497: javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException

[Avik Niyogi]

Hi,
The fix looks good to me.
With Regards,
Avik Niyogi
> 
> Subject:  Re:  [10] RFR JDK-7042497: 
> javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
> Date: Mon, 15 May 2017 15:44:17 +0530
> From: Prasanta Sadhukhan <prasanta.sadhuk...@oracle.com> 
> <mailto:prasanta.sadhuk...@oracle.com>
> Organization: Oracle Corporation
> To:   Semyon Sadetsky <semyon.sadet...@oracle.com> 
> <mailto:semyon.sadet...@oracle.com>, swing-dev@openjdk.java.net 
> <mailto:swing-dev@openjdk.java.net> <swing-dev@openjdk.java.net> 
> <mailto:swing-dev@openjdk.java.net>
> 
> Updated webrev to use getRootFrame() via createDialog() to get the default 
> Frame when a frame is not provided.
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/ 
> <http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.01/>
> 
> Regards
> Prasanta
> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>> Also the spec says to use the default frame but the fix creates new frame 
>> each time. 
>> 
>> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>>> The fix covers the parentComponent=null case.
>>> What about the second case when non-null component is provided but it has 
>>> no frame?
>>> 
>>> --Semyon
>>> 
>>> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>> 
>>>> Please review a spec violation issue whereby if in 
>>>> JOptionPane.showInternalConfirmDialog(Component parentComponent, Object 
>>>> message)
>>>> "parentComponent" is null, we are getting RuntimeException 
>>>> "parentComponent does not have a valid parent"
>>>> 
>>>> but as per spec, 
>>>> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
>>>>  
>>>> <https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html>
>>>> it says "parentComponent - determines the Frame in which the dialog is 
>>>> displayed; if null, or if the parentComponent has no Frame, a default 
>>>> Frame is used"
>>>> 
>>>> This violation exists for all overridden showInternalConfirmDialog methods 
>>>> and showInternalOptionDialog.
>>>> 
>>>> The proposed fix creates a default JFrame and shows the confirm dialog in 
>>>> it, as stated in the spec.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497 
>>>> <https://bugs.openjdk.java.net/browse/JDK-7042497>
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/ 
>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.00/>
>>>> 
>>>> Regards
>>>> Prasanta
>>> 
>> 
> 

Re: 8172509: [TEST_BUG] [macosx] Failure of the new test java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java

[Avik Niyogi]

> On 17-Jan-2017, at 9:23 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> Hi, Avik.
>> 
>> In Nimbus and Aqua LAF, for focus traversal, keybindings do not existing 
>> only arrow keys would work within ungrouped radio buttons but not within 
>> grouped radio button groups. Also, verified Aqua LAF with native application 
>> on MacBook. So to test this focus traversal, it works only in LAF which do 
>> not use Aqua. I was informed last time a similar bug was fixed about this 
>> behaviour regarding Nimbus LAF as well and was confirmed by me by testing it.
> 
> Can you please clarify what bug was fixed in nimbus which was confirmed by 
> you.
HI Sergey,
It was not a bug fixed in Nimbus, it was a test case fixed to include Nimbus 
behaviour along with Aqua LAF as mentioned by you in the review for bug ID: 
8167160
 Please find the copied content of the mail chain for that bug ID below:


+1


On 11/23/2016 7:52 PM, Sergey Bylokhov wrote:
> On 22.11.16 8:49, Avik Niyogi wrote:
>> Hi All,
>> Please review the code changes made as suggested by reviewers for JDK9
>> as available for perusal in the link below:
>> http://cr.openjdk.java.net/~aniyogi/8167160/webrev.02/
>> Change note: Instead of rethrow of a RuntimeException, used
>> printStackTrace()
> 
> +1
> 
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 22-Nov-2016, at 4:01 am, Sergey Bylokhov
>>> <sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com>> wrote:
>>> 
>>> Hi, Avik.
>>> Is it necessary to use logging in the test?
>>> I guess that this code
>>> Logger.getLogger(bug8033699.class.getName()).log(Level.SEVERE, null, ex);
>>> can be replaced by rethrow a RuntimeException exception?
>>> 
>>> On 17.11.16 13:45, Avik Niyogi wrote:
>>>> Hi All,
>>>> Please review the code changes made as suggested by reviewers for JDK9
>>>> as available for perusal in the link below
>>>> http://cr.openjdk.java.net/~aniyogi/8167160/webrev.01/
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>> 
>>>>> On 14-Nov-2016, at 9:03 pm, Avik Niyogi <avik.niy...@oracle.com
>>>>> <mailto:avik.niy...@oracle.com>
>>>>> <mailto:avik.niy...@oracle.com>> wrote:
>>>>> 
>>>>> If I use UIManager.setLookAndFeel() to metalLookAndFeel then it works
>>>>> but for default settings on mac it is not working.
>>>>> 
>>>>>> On 14-Nov-2016, at 8:03 pm, Sergey Bylokhov
>>>>>> <sergey.bylok...@oracle.com
>>>>>> <mailto:sergey.bylok...@oracle.com> <mailto:sergey.bylok...@oracle.com>>
>>>>>> wrote:
>>>>>> 
>>>>>> On 14.11.16 17:18, Avik Niyogi wrote:
>>>>>>> I checked with MetalLAF as well. does not seem to work. also, tried
>>>>>>> with a native Mac app. Does not have any option for radio button
>>>>>>> focus traversal.
>>>>>> 
>>>>>> Can you please clarify how you set the L for this test? I also
>>>>>> checked it and the test passed on the current jdk9-client in case of
>>>>>> "-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel"
>>>>>> 
>>>>>>> 
>>>>>>>> On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov
>>>>>>>> <sergey.bylok...@oracle.com
>>>>>>>> <mailto:sergey.bylok...@oracle.com> 
>>>>>>>> <mailto:sergey.bylok...@oracle.com>>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> On 14.11.16 6:43, Avik Niyogi wrote:
>>>>>>>>> This is OS X Specific.
>>>>>>>> 
>>>>>>>> Are you sure? I guess the test will pass if will be run using
>>>>>>>> MetalLookAndFeel.
>>>>>>>> 
>>>>>>>>>> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov
>>>>>>>>>> <sergey.bylok...@oracle.com
>>>>>>>>>> <mailto:sergey.bylok...@oracle.com> 
>>>>>>>>>> <mailto:sergey.bylok...@oracle.com>>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> On 10.11.16 9:53, Avik Niyogi wrote:
>>>>>>>>>>> Arrow buttons for traversing a radio button

Re: 8172509: [TEST_BUG] [macosx] Failure of the new test java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java

[Avik Niyogi]

A gentle reminder, please review the code changes made.

With Regards,
Avik Niyogi

> On 12-Jan-2017, at 10:02 am, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> In Nimbus and Aqua LAF, for focus traversal, keybindings do not existing only 
> arrow keys would work within ungrouped radio buttons but not within grouped 
> radio button groups. Also, verified Aqua LAF with native application on 
> MacBook. So to test this focus traversal, it works only in LAF which do not 
> use Aqua. I was informed last time a similar bug was fixed about this 
> behaviour regarding Nimbus LAF as well and was confirmed by me by testing it.
> 
> With Regards,
> Avik Niyogi
>> On 11-Jan-2017, at 7:38 pm, Alexandr Scherbatiy 
>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>> wrote:
>> 
>> On 1/11/2017 2:01 PM, Avik Niyogi wrote:
>>> Hi All,
>>> I have addressed the inputs received in the following update. Please review 
>>> the same for JDK 9.
>>> http://cr.openjdk.java.net/~aniyogi/8172509/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.01/>
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 11-Jan-2017, at 4:22 pm, Prasanta Sadhukhan 
>>>> <prasanta.sadhuk...@oracle.com <mailto:prasanta.sadhuk...@oracle.com>> 
>>>> wrote:
>>>> 
>>>> I guess we need to throw the exception if changing LaF fails instead of 
>>>> silently consuming it!! 
>>>> Regards
>>>> Prasanta
>>>> On 1/11/2017 2:16 PM, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> 
>>>>> Kindly review the proposed fix for JDK9.
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172509 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8172509>
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.00/>
>>>>> 
>>>>> Issue: The focus traversal policy being tested was incorrect
>>>>> 
>>>>> Cause: For Aqua and Nimbus, the focus traversal policy used is different 
>>>>> and as this is tested on default LAF, it fails on Mac OS X
>>   Could you give more details what are the differences between using the 
>> focus traversal policy in Metal, Nimbus and Aqua L?
>> 
>>   Thanks,
>>   Alexandr.
>>>>> 
>>>>> Fix: Cross-platform (Metal) LAF is used in case the default LAF is either 
>>>>> Aqua or Nimbus and the focus traversal works in those cases.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>> 
>>> 
>> 
> 

Re: 8172509: [TEST_BUG] [macosx] Failure of the new test java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java

[Avik Niyogi]

In Nimbus and Aqua LAF, for focus traversal, keybindings do not existing only 
arrow keys would work within ungrouped radio buttons but not within grouped 
radio button groups. Also, verified Aqua LAF with native application on 
MacBook. So to test this focus traversal, it works only in LAF which do not use 
Aqua. I was informed last time a similar bug was fixed about this behaviour 
regarding Nimbus LAF as well and was confirmed by me by testing it.

With Regards,
Avik Niyogi
> On 11-Jan-2017, at 7:38 pm, Alexandr Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> On 1/11/2017 2:01 PM, Avik Niyogi wrote:
>> Hi All,
>> I have addressed the inputs received in the following update. Please review 
>> the same for JDK 9.
>> http://cr.openjdk.java.net/~aniyogi/8172509/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.01/>
>> 
>> With Regards,
>> Avik Niyogi
>>> On 11-Jan-2017, at 4:22 pm, Prasanta Sadhukhan 
>>> <prasanta.sadhuk...@oracle.com <mailto:prasanta.sadhuk...@oracle.com>> 
>>> wrote:
>>> 
>>> I guess we need to throw the exception if changing LaF fails instead of 
>>> silently consuming it!! 
>>> Regards
>>> Prasanta
>>> On 1/11/2017 2:16 PM, Avik Niyogi wrote:
>>>> Hi All,
>>>> 
>>>> Kindly review the proposed fix for JDK9.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172509 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8172509>
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.00/>
>>>> 
>>>> Issue: The focus traversal policy being tested was incorrect
>>>> 
>>>> Cause: For Aqua and Nimbus, the focus traversal policy used is different 
>>>> and as this is tested on default LAF, it fails on Mac OS X
>   Could you give more details what are the differences between using the 
> focus traversal policy in Metal, Nimbus and Aqua L?
> 
>   Thanks,
>   Alexandr.
>>>> 
>>>> Fix: Cross-platform (Metal) LAF is used in case the default LAF is either 
>>>> Aqua or Nimbus and the focus traversal works in those cases.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>> 
>> 
> 

Re: 8172509: [TEST_BUG] [macosx] Failure of the new test java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java

[Avik Niyogi]

Hi All,
I have addressed the inputs received in the following update. Please review the 
same for JDK 9.
http://cr.openjdk.java.net/~aniyogi/8172509/webrev.01/ 
<http://cr.openjdk.java.net/~aniyogi/8172509/webrev.01/>

With Regards,
Avik Niyogi
> On 11-Jan-2017, at 4:22 pm, Prasanta Sadhukhan 
> <prasanta.sadhuk...@oracle.com> wrote:
> 
> I guess we need to throw the exception if changing LaF fails instead of 
> silently consuming it!! 
> Regards
> Prasanta
> On 1/11/2017 2:16 PM, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the proposed fix for JDK9.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172509 
>> <https://bugs.openjdk.java.net/browse/JDK-8172509>
>> 
>> Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.00/>
>> 
>> Issue: The focus traversal policy being tested was incorrect
>> 
>> Cause: For Aqua and Nimbus, the focus traversal policy used is different and 
>> as this is tested on default LAF, it fails on Mac OS X
>> 
>> Fix: Cross-platform (Metal) LAF is used in case the default LAF is either 
>> Aqua or Nimbus and the focus traversal works in those cases.
>> 
>> With Regards,
>> Avik Niyogi
> 

Re: [9] Review request for 8165207: [macosx] Test javax/swing/Popup/TaskbarPositionTest.java fails on Mac 10.12

[Avik Niyogi]

Hi Alexander,
The following is my input for this webrev:

In case the LAF is Aqua, the check for combobox alignment is skipped. 
Instead, if default LAF is Aqua, the LAF should be changed to cross platform 
LAF to check if it works on other LAF or not.
Either run this in a loop with checks for all LAF versions available on OS, or 
check for default LAF at the beginning and change it to Cross-Platform LAF to 
check for alignment.
The current changes makes the test pass but does seem to give false positives 
by process of elimination for Aqua LAF.

Also, found the following minor issues which could be looked into if possible:
variables done and error are unused.
numData, dayData and mnDayData could be declared as final.
@override annotations are missing for methods used in ComboPopupCheckListener, 
PopupHandler.
panel is redeclared within scope instead of reusing available variable in 
method createContentPane().
wildcard * is used in import statements which according to guidelines should be 
replace to use only the classes required.

With Regards,
Avik Niyogi

8172509: [TEST_BUG] [macosx] Failure of the new test java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java

[Avik Niyogi]

Hi All,

Kindly review the proposed fix for JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8172509 
<https://bugs.openjdk.java.net/browse/JDK-8172509>

Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/>

Issue: The focus traversal policy being tested was incorrect

Cause: For Aqua and Nimbus, the focus traversal policy used is different and as 
this is tested on default LAF, it fails on Mac OS X

Fix: Cross-platform (Metal) LAF is used in case the default LAF is either Aqua 
or Nimbus and the focus traversal works in those cases.

With Regards,
Avik Niyogi

Re: [9] RFR: JDK-8170349: The printed content is beyond the borders.

[Avik Niyogi]

Fix looks good to me.
> 
> 
> 
> On 12/9/2016 8:18 PM, Alexandr Scherbatiy wrote:
>> On 12/6/2016 5:52 PM, Prasanta Sadhukhan wrote:
>>> On 12/6/2016 8:17 PM, Alexandr Scherbatiy wrote:
 On 12/1/2016 9:16 AM, Prasanta Sadhukhan wrote:
> On 11/30/2016 2:53 PM, Prasanta Sadhukhan wrote:
>> 
>> Hi All,
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170349 
>> 
>> 
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170349/webrev.00/ 
>> 
>> 
>> Please review a fix for a continuation/regression of JDK-8081491 
>> > > in which we 
>> made sure that we print only the JTable rows/columns that is 
>> visible on console.
>> 
>> This bug manifests itself as, despite marking JTable PrintMode to 
>> FIT_WIDTH, we are printing only those columns that are visible on 
>> console.
>> 
>> However, if JTable PrintMode is FIT_WIDTH, then as per spec
>> https://docs.oracle.com/javase/8/docs/api/javax/swing/JTable.PrintMode.html#FIT_WIDTH
>>  
>> 
>> we should print all columns on each page (apparently irrespective 
>> of what is visible)
>> 
>> The fix takes care of that by making sure the table bounds is 
>> adjusted to clipwidth [which is already adjusted to total column 
>> width here 
>> >  
>> >]
>> so that all columns are printed and also rectangle border is 
>> drawn encompassing all columns.
>> 
> The reason of adjusting the table bounds was because table.print() 
> calls BasicTableUI.paint() where we compute visibleBounds
> http://hg.openjdk.java.net/jdk9/client/jdk/file/a5e270f2c97d/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java#l1817
>  
> 
> therefore we need to adjust the visibleBounds to entire columns 
> instead of just the visible columns.
  Did the test Swing_JTable/Manual/PrintManualTest_FitWidthMultiple 
 pass before the fix for the JDK-8081491?
>>Which logic in the fix JDK-8081491 causes that the printing a 
>> table with FIT_WIDTH mode stopped to properly work?
> We calculate visibleBounds in BasicTableUI for 8081491 so even for 
> FIT_WIDTH, it was printing the visible portion of table. Since, in 
> BasicTableUI we cannot access TablePrintable.PrintMode value(since it 
> is private), we need to make sure the table bounds set to full column 
> width so that visibleBounds calculated in BasicTableUI is tricked to 
> believe, that we are printing whole columns.
> 
> Regards
> Prasanta
>> 
>>  Thanks,
>>  Alexandr.
>>> Yes, it did.
>>> 
>>> Regards
>>> Prasanta
  It looks like the table bounds never have been changed in the 
 TablePrintable.
 
  Thanks,
  Alexandr.
> 
> Regards
> Prasanta
>> The 8081491 testcases passed with this fix as well.
>> 
>> Regards
>> Prasanta
> 
 
>>> 
>> 
> 

Re: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java

[Avik Niyogi]

Hi All,
Please review the code changes made as suggested by reviewers for JDK9
as available for perusal in the link below:
http://cr.openjdk.java.net/~aniyogi/8167160/webrev.02/ 
<http://cr.openjdk.java.net/~aniyogi/8167160/webrev.02/>
Change note: Instead of rethrow of a RuntimeException, used printStackTrace()

With Regards,
Avik Niyogi

> On 22-Nov-2016, at 4:01 am, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> Hi, Avik.
> Is it necessary to use logging in the test?
> I guess that this code
> Logger.getLogger(bug8033699.class.getName()).log(Level.SEVERE, null, ex);
> can be replaced by rethrow a RuntimeException exception?
> 
> On 17.11.16 13:45, Avik Niyogi wrote:
>> Hi All,
>> Please review the code changes made as suggested by reviewers for JDK9
>> as available for perusal in the link below
>> http://cr.openjdk.java.net/~aniyogi/8167160/webrev.01/ 
>> <http://cr.openjdk.java.net/~aniyogi/8167160/webrev.01/>
>> With Regards,
>> Avik Niyogi
>> 
>> 
>>> On 14-Nov-2016, at 9:03 pm, Avik Niyogi <avik.niy...@oracle.com 
>>> <mailto:avik.niy...@oracle.com>
>>> <mailto:avik.niy...@oracle.com <mailto:avik.niy...@oracle.com>>> wrote:
>>> 
>>> If I use UIManager.setLookAndFeel() to metalLookAndFeel then it works
>>> but for default settings on mac it is not working.
>>> 
>>>> On 14-Nov-2016, at 8:03 pm, Sergey Bylokhov
>>>> <sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com> 
>>>> <mailto:sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com>>> 
>>>> wrote:
>>>> 
>>>> On 14.11.16 17:18, Avik Niyogi wrote:
>>>>> I checked with MetalLAF as well. does not seem to work. also, tried
>>>>> with a native Mac app. Does not have any option for radio button
>>>>> focus traversal.
>>>> 
>>>> Can you please clarify how you set the L for this test? I also
>>>> checked it and the test passed on the current jdk9-client in case of
>>>> "-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel"
>>>> 
>>>>> 
>>>>>> On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov
>>>>>> <sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com> 
>>>>>> <mailto:sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com>>> 
>>>>>> wrote:
>>>>>> 
>>>>>> On 14.11.16 6:43, Avik Niyogi wrote:
>>>>>>> This is OS X Specific.
>>>>>> 
>>>>>> Are you sure? I guess the test will pass if will be run using
>>>>>> MetalLookAndFeel.
>>>>>> 
>>>>>>>> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov
>>>>>>>> <sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com> 
>>>>>>>> <mailto:sergey.bylok...@oracle.com 
>>>>>>>> <mailto:sergey.bylok...@oracle.com>>>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> On 10.11.16 9:53, Avik Niyogi wrote:
>>>>>>>>> Arrow buttons for traversing a radio button group is not the
>>>>>>>>> expected OS X behaviour.
>>>>>>>> 
>>>>>>>> This behavior is OSX specific or it is related to the Aqua L
>>>>>>>> which is default on OSX?
>>>>>>>> 
>>>>>>>>> In OS X in default OS X apps, for radio button focus traversing
>>>>>>>>> to work, custom actions must be set using System Preferences.
>>>>>>>>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov
>>>>>>>>>> <sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com>
>>>>>>>>>> <mailto:sergey.bylok...@oracle.com 
>>>>>>>>>> <mailto:sergey.bylok...@oracle.com>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> On 09.11.16 11:06, Avik Niyogi wrote:
>>>>>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160*
>>>>>>>>>>> 
>>>>>>>>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/*
>>>>>>>>>>> 
>>>>>>>>>>> *Issue: *The test case :
>>>>>>>>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X
>>>>>>>>>>> 
>>>>>>>>>>> *Cause: * The test case does not apply for OS X and should
>>>>>>>>>>> work for
>>>>>>>>>>> windows and Linux
>>>>>>>>>> 
>>>>>>>>>> What is the reason why the test does not work on OSX?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Best regards, Sergey.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Best regards, Sergey.
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Best regards, Sergey.
>>> 
>> 
> 
> 
> -- 
> Best regards, Sergey.

Re: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java

[Avik Niyogi]

A gentle reminder, please review the code changes done as per the inputs 
received from reviewers.
Thanks in advance.
With Regards,
Avik Niyogi

> On 17-Nov-2016, at 4:15 pm, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> Hi All,
> Please review the code changes made as suggested by reviewers for JDK9 as 
> available for perusal in the link below
> http://cr.openjdk.java.net/~aniyogi/8167160/webrev.01/ 
> <http://cr.openjdk.java.net/~aniyogi/8167160/webrev.01/>
> With Regards,
> Avik Niyogi
> 
> 
>> On 14-Nov-2016, at 9:03 pm, Avik Niyogi <avik.niy...@oracle.com 
>> <mailto:avik.niy...@oracle.com>> wrote:
>> 
>> If I use UIManager.setLookAndFeel() to metalLookAndFeel then it works but 
>> for default settings on mac it is not working.
>> 
>>> On 14-Nov-2016, at 8:03 pm, Sergey Bylokhov <sergey.bylok...@oracle.com 
>>> <mailto:sergey.bylok...@oracle.com>> wrote:
>>> 
>>> On 14.11.16 17:18, Avik Niyogi wrote:
>>>> I checked with MetalLAF as well. does not seem to work. also, tried with a 
>>>> native Mac app. Does not have any option for radio button focus traversal.
>>> 
>>> Can you please clarify how you set the L for this test? I also checked it 
>>> and the test passed on the current jdk9-client in case of 
>>> "-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel"
>>> 
>>>> 
>>>>> On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov <sergey.bylok...@oracle.com 
>>>>> <mailto:sergey.bylok...@oracle.com>> wrote:
>>>>> 
>>>>> On 14.11.16 6:43, Avik Niyogi wrote:
>>>>>> This is OS X Specific.
>>>>> 
>>>>> Are you sure? I guess the test will pass if will be run using 
>>>>> MetalLookAndFeel.
>>>>> 
>>>>>>> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov <sergey.bylok...@oracle.com 
>>>>>>> <mailto:sergey.bylok...@oracle.com>> wrote:
>>>>>>> 
>>>>>>> On 10.11.16 9:53, Avik Niyogi wrote:
>>>>>>>> Arrow buttons for traversing a radio button group is not the expected 
>>>>>>>> OS X behaviour.
>>>>>>> 
>>>>>>> This behavior is OSX specific or it is related to the Aqua L which is 
>>>>>>> default on OSX?
>>>>>>> 
>>>>>>>> In OS X in default OS X apps, for radio button focus traversing to 
>>>>>>>> work, custom actions must be set using System Preferences.
>>>>>>>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov 
>>>>>>>>> <sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com>> 
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> On 09.11.16 11:06, Avik Niyogi wrote:
>>>>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* 
>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8167160*>
>>>>>>>>>> 
>>>>>>>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* 
>>>>>>>>>> <http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/*>
>>>>>>>>>> 
>>>>>>>>>> *Issue: *The test case :
>>>>>>>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X
>>>>>>>>>> 
>>>>>>>>>> *Cause: * The test case does not apply for OS X and should work for
>>>>>>>>>> windows and Linux
>>>>>>>>> 
>>>>>>>>> What is the reason why the test does not work on OSX?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Best regards, Sergey.
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Best regards, Sergey.
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Best regards, Sergey.
>>>> 
>>> 
>>> 
>>> -- 
>>> Best regards, Sergey.
>> 
> 

Re: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java

[Avik Niyogi]

Hi All,
Please review the code changes made as suggested by reviewers for JDK9 as 
available for perusal in the link below
http://cr.openjdk.java.net/~aniyogi/8167160/webrev.01/ 
<http://cr.openjdk.java.net/~aniyogi/8167160/webrev.01/>
With Regards,
Avik Niyogi


> On 14-Nov-2016, at 9:03 pm, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> If I use UIManager.setLookAndFeel() to metalLookAndFeel then it works but for 
> default settings on mac it is not working.
> 
>> On 14-Nov-2016, at 8:03 pm, Sergey Bylokhov <sergey.bylok...@oracle.com 
>> <mailto:sergey.bylok...@oracle.com>> wrote:
>> 
>> On 14.11.16 17:18, Avik Niyogi wrote:
>>> I checked with MetalLAF as well. does not seem to work. also, tried with a 
>>> native Mac app. Does not have any option for radio button focus traversal.
>> 
>> Can you please clarify how you set the L for this test? I also checked it 
>> and the test passed on the current jdk9-client in case of 
>> "-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel"
>> 
>>> 
>>>> On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov <sergey.bylok...@oracle.com 
>>>> <mailto:sergey.bylok...@oracle.com>> wrote:
>>>> 
>>>> On 14.11.16 6:43, Avik Niyogi wrote:
>>>>> This is OS X Specific.
>>>> 
>>>> Are you sure? I guess the test will pass if will be run using 
>>>> MetalLookAndFeel.
>>>> 
>>>>>> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov <sergey.bylok...@oracle.com 
>>>>>> <mailto:sergey.bylok...@oracle.com>> wrote:
>>>>>> 
>>>>>> On 10.11.16 9:53, Avik Niyogi wrote:
>>>>>>> Arrow buttons for traversing a radio button group is not the expected 
>>>>>>> OS X behaviour.
>>>>>> 
>>>>>> This behavior is OSX specific or it is related to the Aqua L which is 
>>>>>> default on OSX?
>>>>>> 
>>>>>>> In OS X in default OS X apps, for radio button focus traversing to 
>>>>>>> work, custom actions must be set using System Preferences.
>>>>>>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov 
>>>>>>>> <sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com>> wrote:
>>>>>>>> 
>>>>>>>> On 09.11.16 11:06, Avik Niyogi wrote:
>>>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* 
>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8167160*>
>>>>>>>>> 
>>>>>>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* 
>>>>>>>>> <http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/*>
>>>>>>>>> 
>>>>>>>>> *Issue: *The test case :
>>>>>>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X
>>>>>>>>> 
>>>>>>>>> *Cause: * The test case does not apply for OS X and should work for
>>>>>>>>> windows and Linux
>>>>>>>> 
>>>>>>>> What is the reason why the test does not work on OSX?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Best regards, Sergey.
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Best regards, Sergey.
>>> 
>> 
>> 
>> -- 
>> Best regards, Sergey.
> 

Re: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java

[Avik Niyogi]

If I use UIManager.setLookAndFeel() to metalLookAndFeel then it works but for 
default settings on mac it is not working.

> On 14-Nov-2016, at 8:03 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> On 14.11.16 17:18, Avik Niyogi wrote:
>> I checked with MetalLAF as well. does not seem to work. also, tried with a 
>> native Mac app. Does not have any option for radio button focus traversal.
> 
> Can you please clarify how you set the L for this test? I also checked it 
> and the test passed on the current jdk9-client in case of 
> "-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel"
> 
>> 
>>> On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
>>> wrote:
>>> 
>>> On 14.11.16 6:43, Avik Niyogi wrote:
>>>> This is OS X Specific.
>>> 
>>> Are you sure? I guess the test will pass if will be run using 
>>> MetalLookAndFeel.
>>> 
>>>>> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov <sergey.bylok...@oracle.com> 
>>>>> wrote:
>>>>> 
>>>>> On 10.11.16 9:53, Avik Niyogi wrote:
>>>>>> Arrow buttons for traversing a radio button group is not the expected OS 
>>>>>> X behaviour.
>>>>> 
>>>>> This behavior is OSX specific or it is related to the Aqua L which is 
>>>>> default on OSX?
>>>>> 
>>>>>> In OS X in default OS X apps, for radio button focus traversing to work, 
>>>>>> custom actions must be set using System Preferences.
>>>>>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov 
>>>>>>> <sergey.bylok...@oracle.com> wrote:
>>>>>>> 
>>>>>>> On 09.11.16 11:06, Avik Niyogi wrote:
>>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160*
>>>>>>>> 
>>>>>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/*
>>>>>>>> 
>>>>>>>> *Issue: *The test case :
>>>>>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X
>>>>>>>> 
>>>>>>>> *Cause: * The test case does not apply for OS X and should work for
>>>>>>>> windows and Linux
>>>>>>> 
>>>>>>> What is the reason why the test does not work on OSX?
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Best regards, Sergey.
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Best regards, Sergey.
>>>> 
>>> 
>>> 
>>> --
>>> Best regards, Sergey.
>> 
> 
> 
> -- 
> Best regards, Sergey.

Re: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java

[Avik Niyogi]

I checked with MetalLAF as well. does not seem to work. also, tried with a 
native Mac app. Does not have any option for radio button focus traversal.

> On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> On 14.11.16 6:43, Avik Niyogi wrote:
>> This is OS X Specific.
> 
> Are you sure? I guess the test will pass if will be run using 
> MetalLookAndFeel.
> 
>>> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov <sergey.bylok...@oracle.com> 
>>> wrote:
>>> 
>>> On 10.11.16 9:53, Avik Niyogi wrote:
>>>> Arrow buttons for traversing a radio button group is not the expected OS X 
>>>> behaviour.
>>> 
>>> This behavior is OSX specific or it is related to the Aqua L which is 
>>> default on OSX?
>>> 
>>>> In OS X in default OS X apps, for radio button focus traversing to work, 
>>>> custom actions must be set using System Preferences.
>>>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
>>>>> wrote:
>>>>> 
>>>>> On 09.11.16 11:06, Avik Niyogi wrote:
>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160*
>>>>>> 
>>>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/*
>>>>>> 
>>>>>> *Issue: *The test case :
>>>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X
>>>>>> 
>>>>>> *Cause: * The test case does not apply for OS X and should work for
>>>>>> windows and Linux
>>>>> 
>>>>> What is the reason why the test does not work on OSX?
>>>>> 
>>>>> 
>>>>> --
>>>>> Best regards, Sergey.
>>>> 
>>> 
>>> 
>>> --
>>> Best regards, Sergey.
>> 
> 
> 
> -- 
> Best regards, Sergey.

Re: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java

[Avik Niyogi]

This is OS X Specific.
> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> On 10.11.16 9:53, Avik Niyogi wrote:
>> Arrow buttons for traversing a radio button group is not the expected OS X 
>> behaviour.
> 
> This behavior is OSX specific or it is related to the Aqua L which is 
> default on OSX?
> 
>> In OS X in default OS X apps, for radio button focus traversing to work, 
>> custom actions must be set using System Preferences.
>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
>>> wrote:
>>> 
>>> On 09.11.16 11:06, Avik Niyogi wrote:
>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160*
>>>> 
>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/*
>>>> 
>>>> *Issue: *The test case :
>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X
>>>> 
>>>> *Cause: * The test case does not apply for OS X and should work for
>>>> windows and Linux
>>> 
>>> What is the reason why the test does not work on OSX?
>>> 
>>> 
>>> --
>>> Best regards, Sergey.
>> 
> 
> 
> -- 
> Best regards, Sergey.

8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java

[Avik Niyogi]

Hi All,

Kindly review the proposed webrev for JDK9. 

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


Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/ 


Issue: The test case : javax/swing/JRadioButton/8033699/bug8033699.java fails 
on OS X

Cause:  The test case does not apply for OS X and should work for windows and 
Linux

Fix: Appropriatechanges in test case parameters were added.

With Regards,

Re: 8168540: [TEST_BUG] On Unity, need a delay before screenshot taking to avoid animation

[Avik Niyogi]

It did not fail on my system but it probably failed for slow systems in testing 
environment.
Similar cases raised by Yuri had happened for several other cases which was 
confirmed to be fixed by the delay by him.

With Regards,
Avik Niyogi
> On 27-Oct-2016, at 1:55 pm, Prasanta Sadhukhan 
> <prasanta.sadhuk...@oracle.com> wrote:
> 
> Hi Avik,
> Did the test fail for you? I ran with the launcher auto-hidden in ubuntu14.04 
> but it passed for me with the original testcode.
> 
> Regards
> Prasanta
> On 10/26/2016 12:39 PM, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the proposed fix for JDK9.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168540 
>> <https://bugs.openjdk.java.net/browse/JDK-8168540>
>> 
>> Webrev: http://cr.openjdk.java.net/~aniyogi/8168540/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8168540/webrev.00/>
>> 
>> Issue: Animation before screen capture causes mismatch.
>> 
>> Cause: Delay before screen capture albeit provided is not enough
>> 
>> Fix: Delay provided to test case
>> 
>> With Regards,
>> Avik Niyogi
> 

Re: 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements

[Avik Niyogi]

Hi All,

Please review the proposed specification for JDK9 including inputs from 
reviewer reviews.
http://cr.openjdk.java.net/~aniyogi/8138771/webrev.04/ 
<http://cr.openjdk.java.net/~aniyogi/8138771/webrev.04/>
Thank you in advance.

With Regards,
Avik Niyogi

> On 27-Oct-2016, at 2:33 am, Jim Graham <james.gra...@oracle.com> wrote:
> 
> The "@return" tags should not start with "returns" in the text.
> 
> Also, in the @return for getProperty(), insert a word "the" as "the property 
> of the base image"...
> 
>   ...jim
> 
> On 10/26/16 12:36 AM, Avik Niyogi wrote:
>> Hi All,
>> 
>> Please review the proposed specification for JDK9 including inputs from 
>> reviver reviews.
>> 
>> *cr.openjdk.java.net/~aniyogi/8138771/webrev.03/* 
>> <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.03/>
>> 
>> 
>> Thank you in advance.
>> 
>> With Regards,
>> Avik Niyogi

8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements

[Avik Niyogi]

Hi All,

Please review the proposed specification for JDK9 including inputs from reviver 
reviews.

cr.openjdk.java.net/~aniyogi/8138771/webrev.03/ 
<http://cr.openjdk.java.net/~aniyogi/8138771/webrev.03/>


Thank you in advance.

With Regards,
Avik Niyogi

8168540: [TEST_BUG] On Unity, need a delay before screenshot taking to avoid animation

[Avik Niyogi]

Hi All,

Kindly review the proposed fix for JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8168540 
<https://bugs.openjdk.java.net/browse/JDK-8168540>

Webrev: http://cr.openjdk.java.net/~aniyogi/8168540/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8168540/webrev.00/>

Issue: Animation before screen capture causes mismatch.

Cause: Delay before screen capture albeit provided is not enough

Fix: Delay provided to test case

With Regards,
Avik Niyogi

Re: 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java

[Avik Niyogi]

A gentle reminder, please review code changes as indicated in new webrev.

With Regards,
Avik Niyogi

> On 07-Sep-2016, at 9:50 pm, Alexandr Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> The fix looks good to me.
> 
> Thanks,
> Alexandr.
> 
> On 9/7/2016 9:02 AM, Avik Niyogi wrote:
>> Hi All,
>> Kindly review the updated fix for JDK9 with new inputs incorporated.
>> Webrev: http://cr.openjdk.java.net/~aniyogi/8163274/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8163274/webrev.01/>
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 07-Sep-2016, at 11:03 am, Rajeev Chamyal <rajeev.cham...@oracle.com 
>>> <mailto:rajeev.cham...@oracle.com>> wrote:
>>> 
>>> Looks good to me.
>>>  
>>> Regards,
>>> Rajeev Chamyal
>>>  
>>> From: Alexandr Scherbatiy 
>>> Sent: 06 September 2016 16:16
>>> To: Avik Niyogi; Rajeev Chamyal; swing-dev@openjdk.java.net 
>>> <mailto:swing-dev@openjdk.java.net>
>>> Subject: Re:  8163274: [TEST_BUG][macosx] apparent regression: 
>>> javax/swing/JColorChooser/Test7194184.java
>>>  
>>> The fix looks good to me.
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 9/6/2016 9:12 AM, Avik Niyogi wrote:
>>> Hi All,
>>>  
>>> Kindly review the fix for JDK9.  
>>>  
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163274 
>>> <https://bugs.openjdk.java.net/browse/JDK-8163274>
>>>  
>>> Webrev: http://cr.openjdk.java.net/~aniyogi/8163274/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8163274/webrev.00/>
>>>  
>>> Issue: This test javax/swing/JColorChooser/Test7194184.java throws 
>>> exception due to event delay.
>>>  
>>> Cause:  Delay for event idling was not added.
>>>  
>>> Fix: Appropriate changes for autoWaitForIdle() were added.
>>>  
>>> With Regards,
>>> Avik Niyogi
>>>  
>> 
> 

8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java

[Avik Niyogi]

Hi All,

Kindly review the fix for JDK9. 

Bug: https://bugs.openjdk.java.net/browse/JDK-8163274 
<https://bugs.openjdk.java.net/browse/JDK-8163274>

Webrev: http://cr.openjdk.java.net/~aniyogi/8163274/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8163274/webrev.00/>

Issue: This test javax/swing/JColorChooser/Test7194184.java throws exception 
due to event delay.

Cause:  Delay for event idling was not added.

Fix: Appropriate changes for autoWaitForIdle() were added.

With Regards,
Avik Niyogi

Re: 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements

[Avik Niyogi]

Hi All,
Please review the proposed specification for JDK9 including inputs from 
reviewer reviews.

http://cr.openjdk.java.net/~aniyogi/8138771/webrev.02/ 
<http://cr.openjdk.java.net/~aniyogi/8138771/webrev.02/>

Thank you in advance.

With Regards,
Avik Niyogi

> On 29-Aug-2016, at 5:55 pm, Alexandr Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> On 8/29/2016 9:52 AM, Avik Niyogi wrote:
>> Hi All,
>> 
>> Please review the proposed specification for JDK9 including inputs from 
>> reviver reviews.
>> 
>> http://cr.openjdk.java.net/~aniyogi/8138771/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8138771/webrev.01/>
>> 
>   There is the {@inheritDoc} which allows to use a javadoc from the parent 
> method.
>   Javadoc for 
> AbstractMultiResolutionImage.getWidth()/getHeight()/getSource()/getProperty() 
> could be like:
> 
> /**
>  * This method simply delegates to the {@code getBaseImage()}.
>  * It is equivalent to: {@code getBaseImage().getWidth(observer)).
>  *
>  * @see #getBaseImage
>  * 
>  * @since 9
>  */
> 
>   Thanks,
>   Alexandr.
>   
>> Thank you in advance.
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 23-Aug-2016, at 2:58 pm, Alexander Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> On 22/08/16 11:06, Avik Niyogi wrote:
>>>> + awt-dev
>>>> 
>>>> 
>>>>> On 22-Aug-2016, at 12:28 pm, Avik Niyogi <avik.niy...@oracle.com 
>>>>> <mailto:avik.niy...@oracle.com>> wrote:
>>>>> 
>>>>> Hi All,
>>>>> 
>>>>> Kindly review the proposed specifications for JDK9. 
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138771 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8138771>
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~aniyogi/8138771/webrev.00/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8138771/webrev.00/>
>>>>> 
>>>>> Issue: The customised specifications necessitated for getGraphics method 
>>>>> did not exist.
>>>>>  So test cases created according to derived specifications would lead to 
>>>>> test cases failures.
>>>>> 
>>>>> Cause:  No congruous specifications could elicit failure in circumstances 
>>>>> not encompassed 
>>>>> in test cases generated without the knowledge of the same.
>>>>> 
>>>>> Fix: Appropriate comprehensive specifications required were added.
>>> -  I am not a native speaker. May be something like this would be better:
>>> --
>>> /**
>>>  * This method is not supported by {@code AbstractMultiResolutionImage}
>>>  * and always throws {@code UnsupportedOperationException}
>>>  *
>>>  * @return {@code UnsupportedOperationException} is thrown
>>>  * @throws UnsupportedOperationException this method is not supported
>>> --
>>> 
>>> - others overridden method should have a documentation that they delegate 
>>> call to the base image (see #getBaseImage)
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>> 
>>> 
>> 
> 

Re: 8163161: [PIT][TEST_BUG] increase timeout in javax/swing/plaf/nimbus/8057791/bug8057791.java

[Avik Niyogi]

Hi All,
A gentle reminder, please review my code change.

With Regards,
Avik Niyogi
> On 23-Aug-2016, at 2:28 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> The fix looks good to me.
> 
> Thanks,
> Alexandr.
> 
> On 23/08/16 10:38, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the fix for JDK9. 
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163161 
>> <https://bugs.openjdk.java.net/browse/JDK-8163161>
>> 
>> Webrev: http://cr.openjdk.java.net/~aniyogi/8163161/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8163161/webrev.00/>
>> 
>> Issue: This test javax/swing/plaf/nimbus/8057791/bug8057791.java times out
>> 
>> Cause:  No timeout delay was provided so it would fail on other systems.
>> 
>> Fix: Appropriate changes for timeout were added.
>> 
>> With Regards,
>> Avik Niyogi
> 

8163161: [PIT][TEST_BUG] increase timeout in javax/swing/plaf/nimbus/8057791/bug8057791.java

[Avik Niyogi]

Hi All,

Kindly review the fix for JDK9. 

Bug: https://bugs.openjdk.java.net/browse/JDK-8163161 
<https://bugs.openjdk.java.net/browse/JDK-8163161>

Webrev: http://cr.openjdk.java.net/~aniyogi/8163161/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8163161/webrev.00/>

Issue: This test javax/swing/plaf/nimbus/8057791/bug8057791.java times out

Cause:  No timeout delay was provided so it would fail on other systems.

Fix: Appropriate changes for timeout were added.

With Regards,
Avik Niyogi

8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements

[Avik Niyogi]

+ awt-dev


> On 22-Aug-2016, at 12:28 pm, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> Hi All,
> 
> Kindly review the proposed specifications for JDK9. 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8138771 
> <https://bugs.openjdk.java.net/browse/JDK-8138771>
> 
> Webrev: http://cr.openjdk.java.net/~aniyogi/8138771/webrev.00/ 
> <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.00/>
> 
> Issue: The customised specifications necessitated for getGraphics method did 
> not exist.
>  So test cases created according to derived specifications would lead to test 
> cases failures.
> 
> Cause:  No congruous specifications could elicit failure in circumstances not 
> encompassed 
> in test cases generated without the knowledge of the same.
> 
> Fix: Appropriate comprehensive specifications required were added.
> 
> With Regards,
> Avik Niyogi

8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements

[Avik Niyogi]

Hi All,

Kindly review the proposed specifications for JDK9. 

Bug: https://bugs.openjdk.java.net/browse/JDK-8138771 
<https://bugs.openjdk.java.net/browse/JDK-8138771>

Webrev: http://cr.openjdk.java.net/~aniyogi/8138771/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8138771/webrev.00/>

Issue: The customised specifications necessitated for getGraphics method did 
not exist.
 So test cases created according to derived specifications would lead to test 
cases failures.

Cause:  No congruous specifications could elicit failure in circumstances not 
encompassed 
in test cases generated without the knowledge of the same.

Fix: Appropriate comprehensive specifications required were added.

With Regards,
Avik Niyogi

8163169: [PIT][TEST_BUG] fix to JDK-8161470 doesn't work

[Avik Niyogi]

Hi All,

Kindly review the fix for JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8163169 
<https://bugs.openjdk.java.net/browse/JDK-8163169>

Webrev: http://cr.openjdk.java.net/~aniyogi/8163169/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8163169/webrev.00/>

Issue: The test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java 
fails on OS X
 for PIT machines even though it works fine for local machine.

Cause:  As pointed out, this is an issue with the robot autoDelay.

Fix: Appropriate Robot methods were used to fix this with enough delays added 
to work on PIT machines.

With Regards,
Avik Niyogi

Re: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java

[Avik Niyogi]

Hi Rajeev,
Updated on same webrev due to single line change.

> On 20-Jul-2016, at 11:41 am, Rajeev Chamyal <rajeev.cham...@oracle.com> wrote:
> 
> Hello Avik,
>  
> Line 67 can be removed from test.
>  
> Regards,
> Rajeev Chamyal
> From: Avik Niyogi 
> Sent: 20 July 2016 11:30
> To: Rajeev Chamyal
> Cc: Praveen Srivastava; Alexandr Scherbatiy; swing-dev@openjdk.java.net
> Subject: Re:  8161470: [TEST_BUG] Failure 
> javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java
>  
> A gentle reminder, please review my code changes.
>  
> With Regards,
> Avik Niyogi
> On 19-Jul-2016, at 1:31 pm, Alexandr Scherbatiy 
> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
> wrote:
>  
> 
> The fix looks good to me.
> 
> Thanks,
> Alexandr.
> 
> On 7/19/2016 9:45 AM, Avik Niyogi wrote:
> Hi All, 
>  
> Kindly review the fix for JDK9. 
>  
> Bug: https://bugs.openjdk.java.net/browse/JDK-8161470 
> <https://bugs.openjdk.java.net/browse/JDK-8161470>
>  
> Webrev: http://cr.openjdk.java.net/~aniyogi/8161470/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8161470/webrev.00/>
>  
> Issue: This test consistently (12/12) fails on OS X 10.10 and also fails on 
> Ubuntu 14.04.
>  
> Cause:  Due to quirk in robot.delay the UI was not getting appropriate 
> behaviour response.
>  
> Fix: Appropriate Robot methods were used to fix this.
>  
> With Regards,
> Avik Niyogi

Re: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java

[Avik Niyogi]

Updated on the same webrev due to one line change.
With Regards,
Avik Niyogi

> On 20-Jul-2016, at 11:41 am, Rajeev Chamyal <rajeev.cham...@oracle.com> wrote:
> 
> Hello Avik,
>  
> Line 67 can be removed from test.
>  
> Regards,
> Rajeev Chamyal
> From: Avik Niyogi 
> Sent: 20 July 2016 11:30
> To: Rajeev Chamyal
> Cc: Praveen Srivastava; Alexandr Scherbatiy; swing-dev@openjdk.java.net
> Subject: Re:  8161470: [TEST_BUG] Failure 
> javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java
>  
> A gentle reminder, please review my code changes.
>  
> With Regards,
> Avik Niyogi
> On 19-Jul-2016, at 1:31 pm, Alexandr Scherbatiy 
> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
> wrote:
>  
> 
> The fix looks good to me.
> 
> Thanks,
> Alexandr.
> 
> On 7/19/2016 9:45 AM, Avik Niyogi wrote:
> Hi All, 
>  
> Kindly review the fix for JDK9. 
>  
> Bug: https://bugs.openjdk.java.net/browse/JDK-8161470 
> <https://bugs.openjdk.java.net/browse/JDK-8161470>
>  
> Webrev: http://cr.openjdk.java.net/~aniyogi/8161470/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8161470/webrev.00/>
>  
> Issue: This test consistently (12/12) fails on OS X 10.10 and also fails on 
> Ubuntu 14.04.
>  
> Cause:  Due to quirk in robot.delay the UI was not getting appropriate 
> behaviour response.
>  
> Fix: Appropriate Robot methods were used to fix this.
>  
> With Regards,
> Avik Niyogi

Re: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java

[Avik Niyogi]

A gentle reminder, please review my code changes.

With Regards,
Avik Niyogi
> On 19-Jul-2016, at 1:31 pm, Alexandr Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> 
> The fix looks good to me.
> 
> Thanks,
> Alexandr.
> 
> On 7/19/2016 9:45 AM, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the fix for JDK9.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161470 
>> <https://bugs.openjdk.java.net/browse/JDK-8161470>
>> 
>> Webrev: http://cr.openjdk.java.net/~aniyogi/8161470/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8161470/webrev.00/>
>> 
>> Issue: This test consistently (12/12) fails on OS X 10.10 and also fails on 
>> Ubuntu 14.04.
>> 
>> Cause:  Due to quirk in robot.delay the UI was not getting appropriate 
>> behaviour response.
>> 
>> Fix: Appropriate Robot methods were used to fix this.
>> 
>> With Regards,
>> Avik Niyogi
> 

8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java

[Avik Niyogi]

Hi All,

Kindly review the fix for JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8161470 
<https://bugs.openjdk.java.net/browse/JDK-8161470>

Webrev: http://cr.openjdk.java.net/~aniyogi/8161470/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8161470/webrev.00/>

Issue: This test consistently (12/12) fails on OS X 10.10 and also fails on 
Ubuntu 14.04.

Cause:  Due to quirk in robot.delay the UI was not getting appropriate 
behaviour response.

Fix: Appropriate Robot methods were used to fix this.

With Regards,
Avik Niyogi

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

[Avik Niyogi]

Hi All,
Another gentle reminder. Please review the changes made.
> On 15-Jul-2016, at 2:50 pm, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> A gentle reminder, please review the changes
> 
>> On 14-Jul-2016, at 8:46 pm, Alexandr Scherbatiy 
>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>> wrote:
>> 
>> 
>> The fix looks good to me.
>> 
>> Thanks,
>> Alexandr.
>> 
>> On 7/14/2016 9:53 AM, Avik Niyogi wrote:
>>> Hi All,
>>> Please find my webrev below for review which includes changes as perceived 
>>> from inputs provided.
>>> 
>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.02/ 
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8160438/webrev.02/>
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 12-Jul-2016, at 7:12 pm, Alexandr Scherbatiy 
>>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>>> wrote:
>>>> 
>>>> On 7/12/2016 8:24 AM, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> A gentle reminder, please review my code changes.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>> 
>>>>>> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko <yuri.nestere...@oracle.com 
>>>>>> <mailto:yuri.nestere...@oracle.com>> wrote:
>>>>>> 
>>>>>> It pass for me if I provide some time to process native events
>>>>>> after the user activity simulation. For instance,
>>>>>> setAutoDelay(50) for robot does that plus waitForIdle()
>>>>>> after every mouseMove(). In this case, the part with that additional
>>>>>> check and a (misleading, I think) comment about the color profiles
>>>>>> may be removed. The test would take much more time though, and
>>>>>>   @run main/timeout=600 bug8057791
>>>>>> line would be necessary.
>>>>Some more comments to the previous ones:
>>>>  - runColorTestCase() uses JList and should be run on EDT
>>>>  - "if (tryNimbusLookAndFeel()) {" It is supposed that the Nimbus L is 
>>>> supported on all platforms. May be it is better to fail the test if the 
>>>> Nimbus L is not set.
>>>>  - "if (osName.contains("Mac")) { isMac = true; }" can be simplified to 
>>>> "return osName.contains("Mac")"
>>>>  - " if (!"".equals(errorString)) {" can be simplified to 
>>>> !errorString.isEmpty()
>>>> 
>>>>  Thanks,
>>>>  Alexandr.
>>>>>> 
>>>>>> Thanks,
>>>>>> -yan
>>>>>> 
>>>>>> On 07/08/2016 04:28 AM, Avik Niyogi wrote:
>>>>>>> The test does not pass if mac specific check is not done for
>>>>>>> backgroundcolor.
>>>>>>> The check is required to get the same values from BufferedImage as they
>>>>>>> are the same as found with Digital Color Meter.
>>>>>>> This test case fixes that.
>>>>>>> Please provide inputs if this fix will get a +1 or if not any positive
>>>>>>> inputs to modify the test case will be welcome.
>>>>>>> 
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>>>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky
>>>>>>>> <semyon.sadet...@oracle.com <mailto:semyon.sadet...@oracle.com> 
>>>>>>>> <mailto:semyon.sadet...@oracle.com 
>>>>>>>> <mailto:semyon.sadet...@oracle.com>>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote:
>>>>>>>>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote:
>>>>>>>>>> 
>>>>>>>>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote:
>>>>>>>>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote:
>>>>>>>>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote:
>>>>>>>>>>>>>> Hi Semyon,
>>>>>>>>>

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

[Avik Niyogi]

A gentle reminder, please review the changes

> On 14-Jul-2016, at 8:46 pm, Alexandr Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> 
> The fix looks good to me.
> 
> Thanks,
> Alexandr.
> 
> On 7/14/2016 9:53 AM, Avik Niyogi wrote:
>> Hi All,
>> Please find my webrev below for review which includes changes as perceived 
>> from inputs provided.
>> 
>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.02/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8160438/webrev.02/>
>> 
>> With Regards,
>> Avik Niyogi
>>> On 12-Jul-2016, at 7:12 pm, Alexandr Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> On 7/12/2016 8:24 AM, Avik Niyogi wrote:
>>>> Hi All,
>>>> A gentle reminder, please review my code changes.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko <yuri.nestere...@oracle.com 
>>>>> <mailto:yuri.nestere...@oracle.com>> wrote:
>>>>> 
>>>>> It pass for me if I provide some time to process native events
>>>>> after the user activity simulation. For instance,
>>>>> setAutoDelay(50) for robot does that plus waitForIdle()
>>>>> after every mouseMove(). In this case, the part with that additional
>>>>> check and a (misleading, I think) comment about the color profiles
>>>>> may be removed. The test would take much more time though, and
>>>>>   @run main/timeout=600 bug8057791
>>>>> line would be necessary.
>>>Some more comments to the previous ones:
>>>  - runColorTestCase() uses JList and should be run on EDT
>>>  - "if (tryNimbusLookAndFeel()) {" It is supposed that the Nimbus L is 
>>> supported on all platforms. May be it is better to fail the test if the 
>>> Nimbus L is not set.
>>>  - "if (osName.contains("Mac")) { isMac = true; }" can be simplified to 
>>> "return osName.contains("Mac")"
>>>  - " if (!"".equals(errorString)) {" can be simplified to 
>>> !errorString.isEmpty()
>>> 
>>>  Thanks,
>>>  Alexandr.
>>>>> 
>>>>> Thanks,
>>>>> -yan
>>>>> 
>>>>> On 07/08/2016 04:28 AM, Avik Niyogi wrote:
>>>>>> The test does not pass if mac specific check is not done for
>>>>>> backgroundcolor.
>>>>>> The check is required to get the same values from BufferedImage as they
>>>>>> are the same as found with Digital Color Meter.
>>>>>> This test case fixes that.
>>>>>> Please provide inputs if this fix will get a +1 or if not any positive
>>>>>> inputs to modify the test case will be welcome.
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky
>>>>>>> <semyon.sadet...@oracle.com <mailto:semyon.sadet...@oracle.com> 
>>>>>>> <mailto:semyon.sadet...@oracle.com 
>>>>>>> <mailto:semyon.sadet...@oracle.com>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote:
>>>>>>>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote:
>>>>>>>>> 
>>>>>>>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote:
>>>>>>>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote:
>>>>>>>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote:
>>>>>>>>>>>>> Hi Semyon,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thank you for the review comment.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display
>>>>>>>>>>>>> Profile*  section, the default value is *Color LCD*.
>>>>>>>>>>>>> This causes a failure in some test cases which uses robot.The 
>>>>>>>>>>>

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

[Avik Niyogi]

Hi Prasanta,
Kindly request you to review the webrev raised with inputs taken from reviewers 
in the mail trail. Thank you in advance.

With Regards,
Avik Niyogi
> On 15-Jul-2016, at 11:37 am, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> I will ask Prasanta to review since it is not a native code change.
> 
>> On 15-Jul-2016, at 11:35 am, Praveen Srivastava 
>> <praveen.s.srivast...@oracle.com <mailto:praveen.s.srivast...@oracle.com>> 
>> wrote:
>> 
>> Rajeev is on sick leave, can someone else like Prasanta or Manajit review ?
>> See if you can push it today..
>>  
>> Thanks
>> Praveen
>>  
>>  
>> From: Avik Niyogi 
>> Sent: Friday, July 15, 2016 11:35 AM
>> To: Rajeev Chamyal
>> Cc: Praveen Srivastava; swing-dev@openjdk.java.net 
>> <mailto:swing-dev@openjdk.java.net>
>> Subject: Re:  8160438: [PIT][macosx] [TEST_BUG] 
>> javax/swing/plaf/nimbus/8057791/bug8057791.java fails
>>  
>> Another gentle reminder, please review my code changes. Thank you in advance.
>> With Regards,
>> Avik Niyogi
>> On 14-Jul-2016, at 8:46 pm, Alexandr Scherbatiy 
>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>> wrote:
>>  
>> 
>> The fix looks good to me.
>> 
>> Thanks,
>> Alexandr.
>> 
>> On 7/14/2016 9:53 AM, Avik Niyogi wrote:
>> Hi All, 
>> Please find my webrev below for review which includes changes as perceived 
>> from inputs provided.
>>  
>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.02/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8160438/webrev.02/>
>>  
>> With Regards,
>> Avik Niyogi
>> On 12-Jul-2016, at 7:12 pm, Alexandr Scherbatiy 
>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>> wrote:
>>  
>> On 7/12/2016 8:24 AM, Avik Niyogi wrote:
>> 
>> Hi All,
>> A gentle reminder, please review my code changes.
>> 
>> With Regards,
>> Avik Niyogi
>> 
>> 
>> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko <yuri.nestere...@oracle.com 
>> <mailto:yuri.nestere...@oracle.com>> wrote:
>> 
>> It pass for me if I provide some time to process native events
>> after the user activity simulation. For instance,
>> setAutoDelay(50) for robot does that plus waitForIdle()
>> after every mouseMove(). In this case, the part with that additional
>> check and a (misleading, I think) comment about the color profiles
>> may be removed. The test would take much more time though, and
>>   @run main/timeout=600 bug8057791
>> line would be necessary.
>>Some more comments to the previous ones:
>>  - runColorTestCase() uses JList and should be run on EDT
>>  - "if (tryNimbusLookAndFeel()) {" It is supposed that the Nimbus L is 
>> supported on all platforms. May be it is better to fail the test if the 
>> Nimbus L is not set.
>>  - "if (osName.contains("Mac")) { isMac = true; }" can be simplified to 
>> "return osName.contains("Mac")"
>>  - " if (!"".equals(errorString)) {" can be simplified to 
>> !errorString.isEmpty()
>> 
>>  Thanks,
>>  Alexandr.
>> 
>> 
>> Thanks,
>> -yan
>> 
>> On 07/08/2016 04:28 AM, Avik Niyogi wrote:
>> 
>> The test does not pass if mac specific check is not done for
>> backgroundcolor.
>> The check is required to get the same values from BufferedImage as they
>> are the same as found with Digital Color Meter.
>> This test case fixes that.
>> Please provide inputs if this fix will get a +1 or if not any positive
>> inputs to modify the test case will be welcome.
>> 
>> With Regards,
>> Avik Niyogi
>> 
>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky
>> <semyon.sadet...@oracle.com <mailto:semyon.sadet...@oracle.com> 
>> <mailto:semyon.sadet...@oracle.com <mailto:semyon.sadet...@oracle.com>>> 
>> wrote:
>> 
>> 
>> 
>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote:
>> 
>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote:
>> 
>> 
>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote:
>> 
>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote:
>> 
>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:
>> 
>> 
>> On 07.07.2016 16:35, Avik Niyogi wrote:
>> 
>> Hi Semyon,
>> 
>> Thank you for the review comment.
>> 
>> In Mac OS X, *System Preferences > Displays > Colors > Display
>&g

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

[Avik Niyogi]

Another gentle reminder, please review my code changes. Thank you in advance.
With Regards,
Avik Niyogi
> On 14-Jul-2016, at 8:46 pm, Alexandr Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> 
> The fix looks good to me.
> 
> Thanks,
> Alexandr.
> 
> On 7/14/2016 9:53 AM, Avik Niyogi wrote:
>> Hi All,
>> Please find my webrev below for review which includes changes as perceived 
>> from inputs provided.
>> 
>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.02/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8160438/webrev.02/>
>> 
>> With Regards,
>> Avik Niyogi
>>> On 12-Jul-2016, at 7:12 pm, Alexandr Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> On 7/12/2016 8:24 AM, Avik Niyogi wrote:
>>>> Hi All,
>>>> A gentle reminder, please review my code changes.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko <yuri.nestere...@oracle.com 
>>>>> <mailto:yuri.nestere...@oracle.com>> wrote:
>>>>> 
>>>>> It pass for me if I provide some time to process native events
>>>>> after the user activity simulation. For instance,
>>>>> setAutoDelay(50) for robot does that plus waitForIdle()
>>>>> after every mouseMove(). In this case, the part with that additional
>>>>> check and a (misleading, I think) comment about the color profiles
>>>>> may be removed. The test would take much more time though, and
>>>>>   @run main/timeout=600 bug8057791
>>>>> line would be necessary.
>>>Some more comments to the previous ones:
>>>  - runColorTestCase() uses JList and should be run on EDT
>>>  - "if (tryNimbusLookAndFeel()) {" It is supposed that the Nimbus L is 
>>> supported on all platforms. May be it is better to fail the test if the 
>>> Nimbus L is not set.
>>>  - "if (osName.contains("Mac")) { isMac = true; }" can be simplified to 
>>> "return osName.contains("Mac")"
>>>  - " if (!"".equals(errorString)) {" can be simplified to 
>>> !errorString.isEmpty()
>>> 
>>>  Thanks,
>>>  Alexandr.
>>>>> 
>>>>> Thanks,
>>>>> -yan
>>>>> 
>>>>> On 07/08/2016 04:28 AM, Avik Niyogi wrote:
>>>>>> The test does not pass if mac specific check is not done for
>>>>>> backgroundcolor.
>>>>>> The check is required to get the same values from BufferedImage as they
>>>>>> are the same as found with Digital Color Meter.
>>>>>> This test case fixes that.
>>>>>> Please provide inputs if this fix will get a +1 or if not any positive
>>>>>> inputs to modify the test case will be welcome.
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky
>>>>>>> <semyon.sadet...@oracle.com <mailto:semyon.sadet...@oracle.com> 
>>>>>>> <mailto:semyon.sadet...@oracle.com 
>>>>>>> <mailto:semyon.sadet...@oracle.com>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote:
>>>>>>>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote:
>>>>>>>>> 
>>>>>>>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote:
>>>>>>>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote:
>>>>>>>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote:
>>>>>>>>>>>>> Hi Semyon,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thank you for the review comment.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display
>>>>>>>>>>>>> Profile*  section, the default value is *Color LCD*.
>>>>>>>>>>>>> This causes a failure in some test cases whic

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

[Avik Niyogi]

Hi All,
Please find my webrev below for review which includes changes as perceived from 
inputs provided.

http://cr.openjdk.java.net/~aniyogi/8160438/webrev.02/ 
<http://cr.openjdk.java.net/~aniyogi/8160438/webrev.02/>

With Regards,
Avik Niyogi
> On 12-Jul-2016, at 7:12 pm, Alexandr Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> On 7/12/2016 8:24 AM, Avik Niyogi wrote:
>> Hi All,
>> A gentle reminder, please review my code changes.
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko <yuri.nestere...@oracle.com> 
>>> wrote:
>>> 
>>> It pass for me if I provide some time to process native events
>>> after the user activity simulation. For instance,
>>> setAutoDelay(50) for robot does that plus waitForIdle()
>>> after every mouseMove(). In this case, the part with that additional
>>> check and a (misleading, I think) comment about the color profiles
>>> may be removed. The test would take much more time though, and
>>>   @run main/timeout=600 bug8057791
>>> line would be necessary.
>Some more comments to the previous ones:
>  - runColorTestCase() uses JList and should be run on EDT
>  - "if (tryNimbusLookAndFeel()) {" It is supposed that the Nimbus L is 
> supported on all platforms. May be it is better to fail the test if the 
> Nimbus L is not set.
>  - "if (osName.contains("Mac")) { isMac = true; }" can be simplified to 
> "return osName.contains("Mac")"
>  - " if (!"".equals(errorString)) {" can be simplified to 
> !errorString.isEmpty()
> 
>  Thanks,
>  Alexandr.
>>> 
>>> Thanks,
>>> -yan
>>> 
>>> On 07/08/2016 04:28 AM, Avik Niyogi wrote:
>>>> The test does not pass if mac specific check is not done for
>>>> backgroundcolor.
>>>> The check is required to get the same values from BufferedImage as they
>>>> are the same as found with Digital Color Meter.
>>>> This test case fixes that.
>>>> Please provide inputs if this fix will get a +1 or if not any positive
>>>> inputs to modify the test case will be welcome.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky
>>>>> <semyon.sadet...@oracle.com <mailto:semyon.sadet...@oracle.com>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote:
>>>>>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote:
>>>>>>> 
>>>>>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote:
>>>>>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote:
>>>>>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:
>>>>>>>>>> 
>>>>>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote:
>>>>>>>>>>> Hi Semyon,
>>>>>>>>>>> 
>>>>>>>>>>> Thank you for the review comment.
>>>>>>>>>>> 
>>>>>>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display
>>>>>>>>>>> Profile*  section, the default value is *Color LCD*.
>>>>>>>>>>> This causes a failure in some test cases which uses robot.The colour
>>>>>>>>>>> configuration it expects to use is the *Generic RGB Profile*.
>>>>>>>>>>> That is what “Non-generic display settings” means.
>>>>>>>>>> AFAIK there are instruction that tests should be executed using color
>>>>>>>>>> profile with no color corrections on OS X. I guess there are many
>>>>>>>>>> other
>>>>>>>>>> tests that fail with color correction.
>>>>>>>>>> If this is a root cause than the bug doesn't need to be fixed.
>>>>>>>>> Well, I filed this bug and I used Generic RGB on all my
>>>>>>>>> test machines. There may be additional precautions in the tests
>>>>>>>>> about that but misconfiguration is not the root case here.
>>>>>>>>> That said, I feel vary about attempts to guess Apple colors
>>>>>>>>   wary I mean
>>>>>>>>> in non-generic profiles.
>>>>>>&g

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

[Avik Niyogi]

Hi All,
A gentle reminder, please review my code changes.

With Regards,
Avik Niyogi

> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko <yuri.nestere...@oracle.com> 
> wrote:
> 
> It pass for me if I provide some time to process native events
> after the user activity simulation. For instance,
> setAutoDelay(50) for robot does that plus waitForIdle()
> after every mouseMove(). In this case, the part with that additional
> check and a (misleading, I think) comment about the color profiles
> may be removed. The test would take much more time though, and
>   @run main/timeout=600 bug8057791
> line would be necessary.
> 
> Thanks,
> -yan
> 
> On 07/08/2016 04:28 AM, Avik Niyogi wrote:
>> The test does not pass if mac specific check is not done for
>> backgroundcolor.
>> The check is required to get the same values from BufferedImage as they
>> are the same as found with Digital Color Meter.
>> This test case fixes that.
>> Please provide inputs if this fix will get a +1 or if not any positive
>> inputs to modify the test case will be welcome.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky
>>> <semyon.sadet...@oracle.com <mailto:semyon.sadet...@oracle.com>> wrote:
>>> 
>>> 
>>> 
>>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote:
>>>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote:
>>>>> 
>>>>> 
>>>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote:
>>>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote:
>>>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote:
>>>>>>>>> Hi Semyon,
>>>>>>>>> 
>>>>>>>>> Thank you for the review comment.
>>>>>>>>> 
>>>>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display
>>>>>>>>> Profile*  section, the default value is *Color LCD*.
>>>>>>>>> This causes a failure in some test cases which uses robot.The colour
>>>>>>>>> configuration it expects to use is the *Generic RGB Profile*.
>>>>>>>>> That is what “Non-generic display settings” means.
>>>>>>>> AFAIK there are instruction that tests should be executed using color
>>>>>>>> profile with no color corrections on OS X. I guess there are many
>>>>>>>> other
>>>>>>>> tests that fail with color correction.
>>>>>>>> If this is a root cause than the bug doesn't need to be fixed.
>>>>>>> 
>>>>>>> Well, I filed this bug and I used Generic RGB on all my
>>>>>>> test machines. There may be additional precautions in the tests
>>>>>>> about that but misconfiguration is not the root case here.
>>>>>>> That said, I feel vary about attempts to guess Apple colors
>>>>>>   wary I mean
>>>>>>> in non-generic profiles.
>>>>> Yuri. Do you mean that the non-generic is not a root case?
>>>> No: I had Generic RGB everywhere, and it failed for me.
>>>> I should say that the new version of the test properly
>>>> fails with b120 and pass with current PIT. And colors
>>>> are visibly different in the two builds: so the test works OK now.
>>> That contradicts with the description of the fix.
>>> Probably the test does unnecessary care about the non-Generic profiles.
>>> 
>>> 159 if (!foundMatch && isMac()) {
>>> 160 //One more chance for Mac due to non-Generic
>>> display setting
>>> 161 detectedColor = new Color(img.getRGB(x, y), true);
>>> 162 if (detectedColor.equals(colorCheck)) {
>>> 163 foundMatch = true;
>>> 164 break checkLoops;
>>> 165 }
>>> 166 }
>>> 
>>> Does it mean that the code above, which is necessary to serve
>>> non-Generic profiles on OS X, may be removed and the test still passes?
>>> 
>>> --Semyon
>>>> 
>>>> -yan
>>>> 
>>>>> 
>>>>> --Semyon
>>>>>>> 
>>>>>>> -yan
>>>>>&g

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

[Avik Niyogi]

The test does not pass if mac specific check is not done for backgroundcolor.
The check is required to get the same values from BufferedImage as they are the 
same as found with Digital Color Meter.
This test case fixes that.
Please provide inputs if this fix will get a +1 or if not any positive inputs 
to modify the test case will be welcome.

With Regards,
Avik Niyogi
> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky <semyon.sadet...@oracle.com> 
> wrote:
> 
> 
> 
> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote:
>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote:
>>> 
>>> 
>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote:
>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote:
>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:
>>>>>> 
>>>>>> 
>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote:
>>>>>>> Hi Semyon,
>>>>>>> 
>>>>>>> Thank you for the review comment.
>>>>>>> 
>>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display
>>>>>>> Profile*  section, the default value is *Color LCD*.
>>>>>>> This causes a failure in some test cases which uses robot.The colour
>>>>>>> configuration it expects to use is the *Generic RGB Profile*.
>>>>>>> That is what “Non-generic display settings” means.
>>>>>> AFAIK there are instruction that tests should be executed using color
>>>>>> profile with no color corrections on OS X. I guess there are many other
>>>>>> tests that fail with color correction.
>>>>>> If this is a root cause than the bug doesn't need to be fixed.
>>>>> 
>>>>> Well, I filed this bug and I used Generic RGB on all my
>>>>> test machines. There may be additional precautions in the tests
>>>>> about that but misconfiguration is not the root case here.
>>>>> That said, I feel vary about attempts to guess Apple colors
>>>>wary I mean
>>>>> in non-generic profiles.
>>> Yuri. Do you mean that the non-generic is not a root case?
>> No: I had Generic RGB everywhere, and it failed for me.
>> I should say that the new version of the test properly
>> fails with b120 and pass with current PIT. And colors
>> are visibly different in the two builds: so the test works OK now.
> That contradicts with the description of the fix.
> Probably the test does unnecessary care about the non-Generic profiles.
> 
> 159 if (!foundMatch && isMac()) {
> 160 //One more chance for Mac due to non-Generic display 
> setting
> 161 detectedColor = new Color(img.getRGB(x, y), true);
> 162 if (detectedColor.equals(colorCheck)) {
> 163 foundMatch = true;
> 164 break checkLoops;
> 165 }
> 166 }
> 
> Does it mean that the code above, which is necessary to serve non-Generic 
> profiles on OS X, may be removed and the test still passes?
> 
> --Semyon
>> 
>> -yan
>> 
>>> 
>>> --Semyon
>>>>> 
>>>>> -yan
>>>>> 
>>>>> 
>>>>>> 
>>>>>> --Semyon
>>>>>>> 
>>>>>>> Regarding “Negative scenarios”, these include cases where colours are
>>>>>>> different from the expected background or foreground colors
>>>>>>> is checked with the robot and BufferedImage respectively to *eliminate
>>>>>>> false positives due to coincidentally finding a match* by using robot
>>>>>>> or BufferedImage.
>>>>>>> 
>>>>>>> Please find my changes appropriating the inputs provided.
>>>>>>> I removed the variable foundMatch as I found that it is not required
>>>>>>> at all and incorporated the suggestion to use return instead of a
>>>>>>> labelled break.
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8160438/webrev.01/>
>>>>>>> 
>>>>>>> 
>>>>>>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky
>>>>>>>> <semyon.sadet...@oracle.com <mailto:semyon.sadet...@oracle.com>>
>>>>>>>> wrote:
>>>&

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

[Avik Niyogi]

Hi Semyon,

Thank you for the review comment.

In Mac OS X, System Preferences > Displays > Colors > Display Profile  section, 
the default value is Color LCD.
This causes a failure in some test cases which uses robot.The colour 
configuration it expects to use is the Generic RGB Profile.
That is what “Non-generic display settings” means.

Regarding “Negative scenarios”, these include cases where colours are different 
from the expected background or foreground colors 
is checked with the robot and BufferedImage respectively to eliminate false 
positives due to coincidentally finding a match by using robot or BufferedImage.

Please find my changes appropriating the inputs provided.
I removed the variable foundMatch as I found that it is not required at all and 
incorporated the suggestion to use return instead of a labelled break.

http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ 
<http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/>


> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky <semyon.sadet...@oracle.com> 
> wrote:
> 
> Hi Avik,
> 
> could you clarify what is "Non-generic display settings"? Is it known bug on 
> OS X?
> And also please be more specific on "negative scenarios" why they are 
> necessary ?
> 
> Also could you replace labeled break with "return foundMatch; "
> 
> --Semyon 
> 
> 
> On 07.07.2016 15:11, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the fix for JDK9.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8160438 
>> <https://bugs.openjdk.java.net/browse/JDK-8160438>
>> 
>> Webrev: http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8160438/webrev.00/>
>> 
>> Issue: test javax/swing/plaf/nimbus/8057791/bug8057791.java consistently 
>> fails on OS X 10.10
>> 
>> Cause:  Due to bug in detecting color for Non-generic display settings for 
>> Mac hardware, test case failed
>> 
>> Fix: Positive and negative scenarios was added to check the colour for the 
>> Nimbus LAF foreground and background colours.
>> 
>> With Regards,
>> Avik Niyogi
>> 
>> 
>> 
> 

[9] Review request for JDK-[TEST_BUG] test/javax/swing/JPopupMenu/8147521/PopupMenuTest.java: compilation failed

[Avik Niyogi]

The bug fix looks good to me.

With Regards,
Avik Niyogi
> On 03-Jun-2016, at 11:31 am, Rajeev Chamyal <rajeev.cham...@oracle.com> wrote:
> 
>  
>  
> From: Alexandr Scherbatiy 
> Sent: 02 June 2016 12:00
> To: Rajeev Chamyal; Sergey Bylokhov; swing-dev@openjdk.java.net 
> <mailto:swing-dev@openjdk.java.net>
> Subject: Re:  [9] Review request for JDK-[TEST_BUG] 
> test/javax/swing/JPopupMenu/8147521/PopupMenuTest.java: compilation failed
>  
> 
> The fix looks good to me.
> 
> Thanks,
> Alexandr.
> 
> On 6/2/2016 8:13 AM, Rajeev Chamyal wrote:
> Hello Alexandr,
>  
> Please review the updated webrev.
> http://cr.openjdk.java.net/~rchamyal/8158358/webrev.01/ 
> <http://cr.openjdk.java.net/~rchamyal/8158358/webrev.01/>
>  
> Regards,
> Rajeev Chamyal
>  
> From: Alexandr Scherbatiy 
> Sent: 02 June 2016 01:20
> To: Rajeev Chamyal; Sergey Bylokhov; swing-dev@openjdk.java.net 
> <mailto:swing-dev@openjdk.java.net>
> Subject: Re:  [9] Review request for JDK-[TEST_BUG] 
> test/javax/swing/JPopupMenu/8147521/PopupMenuTest.java: compilation failed
>  
> On 6/1/2016 10:35 PM, Rajeev Chamyal wrote:
> 
> 
> Hello All,
>  
> Please review the following webrev
>  
> Webrev : http://cr.openjdk.java.net/~rchamyal/8158358/webrev.00/ 
> <http://cr.openjdk.java.net/%7Erchamyal/8158358/webrev.00/>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8158358 
> <https://bugs.openjdk.java.net/browse/JDK-8158358>
>  
> Fix : Fixed the compilation error.
>The initial summary of the test should be preserved.
> 
>   Thanks,
>   Alexandr.
> 
> 
>  
> Regards,
> Rajeev Chamyal
>  
>  
>  

Re: 8158230: [macosx] ActionEvent is not fired for menu item with option apple.laf.useScreenMenuBar

[Avik Niyogi]

Hi Sergey,
I ran the relevant test cases:
ActionListenerCalledTwiceTest
ScreenMenuBarInputTwice
with different keyboard preferences and locales.
Also tried different LAFs but found that only default (aqua) LAF is relevant 
for this case.

With Regards,
Avik Niyogi

> On 31-May-2016, at 7:05 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> Hi, Avik.
> Please confirm that you run all tests for the previous regressions which were 
> fixed in this code recently. (use different system locales).
> 
> On 31.05.16 16:28, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the fix for JDK9.
>> *Bug: *https://bugs.openjdk.java.net/browse/JDK-8158230
>> 
>> *Webrev:* http://cr.openjdk.java.net/~aniyogi/8158230/webrev.00/
>> 
>> *Issue*: ActionEvent is not fired for menu item with option
>> apple.laf.useScreenMenuBar
>> 
>> *Cause*: The case for event that is not a Keydown has to be handled
>> 
>> *Fix*: With fixing the if - else loop, the correct behaviour was confirmed.
>> 
>> With Regards,
>> Avik Niyogi
> 
> 
> -- 
> Best regards, Sergey.

8158230: [macosx] ActionEvent is not fired for menu item with option apple.laf.useScreenMenuBar

[Avik Niyogi]

Hi All,

Kindly review the fix for JDK9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8158230 
<https://bugs.openjdk.java.net/browse/JDK-8158230>

Webrev: http://cr.openjdk.java.net/~aniyogi/8158230/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8158230/webrev.00/>

Issue: ActionEvent is not fired for menu item with option 
apple.laf.useScreenMenuBar

Cause: The case for event that is not a Keydown has to be handled

Fix: With fixing the if - else loop, the correct behaviour was confirmed.

With Regards,
Avik Niyogi

Review request for 8132771: [TEST_BUG][macosx] Test javax/swing/JTree/DnD/LastNodeLowerHalfDrop.java fails for MacOSX

[Avik Niyogi]

Hi All,

Kindly review the fix for JDK9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8132771 
<https://bugs.openjdk.java.net/browse/JDK-8132771>

Webrev: http://cr.openjdk.java.net/~aniyogi/8132771/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8132771/webrev.00/>

Issue: LastNodeLowerHalfDrop Test case throws an exception when the behaviour 
is as expected.

Cause: The robot does not have enough delay to run appropriately.

Fix: The test case was fixed to have enough delay for the test case.

With Regards,
Avik Niyogi

Re: Review request for 8144161: [TESTBUG] [macosx] Test javax/swing/plaf/basic/BasicComboPopup/7072653/bug7072653.java fails for mac

[Avik Niyogi]

A gentle reminder. Please review the bug fix:
http://cr.openjdk.java.net/~aniyogi/8144161/webrev.01/ 
<http://cr.openjdk.java.net/~aniyogi/8144161/webrev.01/>

With Regards,
Avik Niyogi

> On 25-May-2016, at 2:30 pm, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> Changes updated to same webrev.01
>> http://cr.openjdk.java.net/~aniyogi/8144161/webrev.01 
>> <http://cr.openjdk.java.net/~aniyogi/8144161/webrev.01>
> With regards,
> Avik Niyogi
> 
>> On 25-May-2016, at 2:21 pm, Rajeev Chamyal <rajeev.cham...@oracle.com 
>> <mailto:rajeev.cham...@oracle.com>> wrote:
>> 
>> Looks ok to me.
>> Can you please add specific class imports instead of *.
>>  
>> Regards,
>> Rajeev Chamyal
>>  
>> From: Avik Niyogi 
>> Sent: 25 May 2016 12:53
>> To: Alexander Scherbatiy
>> Cc: Rajeev Chamyal; swing-dev@openjdk.java.net 
>> <mailto:swing-dev@openjdk.java.net>
>> Subject: Re:  Review request for 8144161: [TESTBUG] [macosx] Test 
>> javax/swing/plaf/basic/BasicComboPopup/7072653/bug7072653.java fails for mac
>>  
>> Hi All,
>>  
>> Please find updated changes as per inputs received:
>>  Bug: https://bugs.openjdk.java.net/browse/JDK-8144161 
>> <https://bugs.openjdk.java.net/browse/JDK-8144161>
>>  
>> Webrev: http://cr.openjdk.java.net/~aniyogi/8144161/webrev.01/ 
>> <http://cr.openjdk.java.net/~aniyogi/8144161/webrev.01/>
>>  
>> With Regards,
>> Avik Niyogi
>>  
>> On 24-May-2016, at 5:58 pm, Alexander Scherbatiy 
>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>> wrote:
>>  
>> On 24/05/16 15:22, Avik Niyogi wrote:
>> Hi All, 
>>  
>> Kindly review the fix for JDK9.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144161 
>> <https://bugs.openjdk.java.net/browse/JDK-7124218>
>>  
>> Webrev:http:// cr.openjdk.java.net/~aniyogi/8144161/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8144161/webrev.00/>
>>  
>> Issue: Test case throws an exception when the behaviour is as expected.
>>  
>> Cause: The expected behaviour for comboBox was not accounted for Aqua look 
>> and feel in test case.
>>  
>> Fix: The test case was fixed to account for the Aqua LAF behaviour for 
>> comboBox dropdown menu which extends beyond the screen Insets (the dock 
>> height) for Mac.
>>  
>>   - the bug link points to the bug 7124218 instead of 8144161
>>   - The exception should be re-thrown on the line 63
>>   - Some code formatting change is not clear (see for example line 24 or 133)
>> 
>>   Thanks,
>>   Alexandr.
>> 
>> With Regards,
>> Avik Niyogi 
> 

Re: Review request for 8144161: [TESTBUG] [macosx] Test javax/swing/plaf/basic/BasicComboPopup/7072653/bug7072653.java fails for mac

[Avik Niyogi]

Changes updated to same webrev.01
> http://cr.openjdk.java.net/~aniyogi/8144161/webrev.01 
> <http://cr.openjdk.java.net/~aniyogi/8144161/webrev.01>
With regards,
Avik Niyogi

> On 25-May-2016, at 2:21 pm, Rajeev Chamyal <rajeev.cham...@oracle.com> wrote:
> 
> Looks ok to me.
> Can you please add specific class imports instead of *.
>  
> Regards,
> Rajeev Chamyal
>  
> From: Avik Niyogi 
> Sent: 25 May 2016 12:53
> To: Alexander Scherbatiy
> Cc: Rajeev Chamyal; swing-dev@openjdk.java.net
> Subject: Re:  Review request for 8144161: [TESTBUG] [macosx] Test 
> javax/swing/plaf/basic/BasicComboPopup/7072653/bug7072653.java fails for mac
>  
> Hi All,
>  
> Please find updated changes as per inputs received:
>  Bug: https://bugs.openjdk.java.net/browse/JDK-8144161 
> <https://bugs.openjdk.java.net/browse/JDK-8144161>
>  
> Webrev: http://cr.openjdk.java.net/~aniyogi/8144161/webrev.01/ 
> <http://cr.openjdk.java.net/~aniyogi/8144161/webrev.01/>
>  
> With Regards,
> Avik Niyogi
>  
> On 24-May-2016, at 5:58 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
> wrote:
>  
> On 24/05/16 15:22, Avik Niyogi wrote:
> Hi All, 
>  
> Kindly review the fix for JDK9.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144161 
> <https://bugs.openjdk.java.net/browse/JDK-7124218>
>  
> Webrev:http:// cr.openjdk.java.net/~aniyogi/8144161/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8144161/webrev.00/>
>  
> Issue: Test case throws an exception when the behaviour is as expected.
>  
> Cause: The expected behaviour for comboBox was not accounted for Aqua look 
> and feel in test case.
>  
> Fix: The test case was fixed to account for the Aqua LAF behaviour for 
> comboBox dropdown menu which extends beyond the screen Insets (the dock 
> height) for Mac.
>  
>   - the bug link points to the bug 7124218 instead of 8144161
>   - The exception should be re-thrown on the line 63
>   - Some code formatting change is not clear (see for example line 24 or 133)
> 
>   Thanks,
>   Alexandr.
> 
> With Regards,
> Avik Niyogi 

Re: Review request for 8144161: [TESTBUG] [macosx] Test javax/swing/plaf/basic/BasicComboPopup/7072653/bug7072653.java fails for mac

[Avik Niyogi]

Hi All,

Please find updated changes as per inputs received:
 Bug: https://bugs.openjdk.java.net/browse/JDK-8144161 
<https://bugs.openjdk.java.net/browse/JDK-8144161>

Webrev: http://cr.openjdk.java.net/~aniyogi/8144161/webrev.01/ 
<http://cr.openjdk.java.net/~aniyogi/8144161/webrev.01/>

With Regards,
Avik Niyogi

> On 24-May-2016, at 5:58 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> On 24/05/16 15:22, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the fix for JDK9.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144161 
>> <https://bugs.openjdk.java.net/browse/JDK-7124218>
>> 
>> Webrev:http:// cr.openjdk.java.net/~aniyogi/8144161/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8144161/webrev.00/>
>> 
>> Issue: Test case throws an exception when the behaviour is as expected.
>> 
>> Cause: The expected behaviour for comboBox was not accounted for Aqua look 
>> and feel in test case.
>> 
>> Fix: The test case was fixed to account for the Aqua LAF behaviour for 
>> comboBox dropdown menu which extends beyond the screen Insets (the dock 
>> height) for Mac.
>> 
>   - the bug link points to the bug 7124218 instead of 8144161
>   - The exception should be re-thrown on the line 63
>   - Some code formatting change is not clear (see for example line 24 or 133)
> 
>   Thanks,
>   Alexandr.
>> With Regards,
>> Avik Niyogi
> 

Review request for 8144161: [TESTBUG] [macosx] Test javax/swing/plaf/basic/BasicComboPopup/7072653/bug7072653.java fails for mac

[Avik Niyogi]

Hi All,

Kindly review the fix for JDK9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8144161 
<https://bugs.openjdk.java.net/browse/JDK-7124218>

Webrev:http://cr.openjdk.java.net/~aniyogi/8144161/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8144161/webrev.00/>

Issue: Test case throws an exception when the behaviour is as expected.

Cause: The expected behaviour for comboBox was not accounted for Aqua look and 
feel in test case.

Fix: The test case was fixed to account for the Aqua LAF behaviour for comboBox 
dropdown menu which extends beyond the screen Insets (the dock height) for Mac.

With Regards,
Avik Niyogi

Re: [9] Review request for JDK-8153282 [TEST_BUG] some new JInternalFrame tests fail

[Avik Niyogi]

Looks fine.

> On 03-May-2016, at 12:48 am, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> Thanks.
> On 02.05.16 18:20, Rajeev Chamyal wrote:
>> Hello Sergey,
>> 
>> Checked the tests with 1.9.0-ea-b86 build.
>> All tests failed.
>> 
>> Regards,
>> Rajeev Chamyal
>> 
>> -Original Message-
>> From: Sergey Bylokhov
>> Sent: 02 May 2016 19:05
>> To: Rajeev Chamyal; swing-dev@openjdk.java.net; Avik Niyogi
>> Subject: Re:  [9] Review request for JDK-8153282 [TEST_BUG] some 
>> new JInternalFrame tests fail
>> 
>> Looks fine, please confirm that the tests still fails before corresponding 
>> bugs were fixed.
>> 
>> On 02.05.16 13:19, Rajeev Chamyal wrote:
>>> Hello All,
>>> 
>>> 
>>> 
>>> Please review the following fix.
>>> 
>>> 
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153282
>>> 
>>> Webrev: http://cr.openjdk.java.net/~rchamyal/8153282/webrev.00/
>>> 
>>> 
>>> 
>>> Fix: Added delay for test TestJInternalFrameMaximize.java and
>>> TestJInternalFrameMinimize.java
>>> 
>>> Increased the time value for TestJInternalFrameDispose.java
>>> 
>>> 
>>> 
>>> Test are running fine on Mac,Windows and linux after the fix.
>>> 
>>> 
>>> 
>>> Regards,
>>> 
>>> Rajeev Chamyal
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Best regards, Sergey.
>> 
> 
> 
> -- 
> Best regards, Sergey.

Re: Review Request of 8152492: [macosx swing] double key event actions when using Mac menubar

[Avik Niyogi]

Hi All,
I have added some comments and made some minor tweaks as per the inputs 
received.
Please review my code changes as available at this link below:

http://cr.openjdk.java.net/~aniyogi/8152492/webrev.02/ 
<http://cr.openjdk.java.net/~aniyogi/8152492/webrev.02/>

With Regards,
Avik Niyogi

> On 19-Apr-2016, at 6:08 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> On 19.04.16 11:46, Avik Niyogi wrote:
>> Hi All,
>> Please review my code changes with inputs received:
> 
> Can you please add some description of your changes, it seems you removed all 
> code which was added by you previously.
> 
>> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.01/ 
>> <http://cr.openjdk.java.net/~aniyogi/8152492/webrev.01/>
>> 
>> With Regards,
>> Avik Niyogi
>>> On 19-Apr-2016, at 11:47 am, Avik Niyogi <avik.niy...@oracle.com 
>>> <mailto:avik.niy...@oracle.com>
>>> <mailto:avik.niy...@oracle.com <mailto:avik.niy...@oracle.com>>> wrote:
>>> 
>>> Hi Sergey,
>>> I have tried all these Input sources:
>>> 
>>> I am unable to reproduce the test failure as mentioned by you with
>>> these inputs. Please provide some screenshots and/or details of the
>>> procedure used for this test failure.
>>> Thank you in advance.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 08-Apr-2016, at 8:15 pm, Sergey Bylokhov
>>>> <sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com> 
>>>> <mailto:sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com>>> 
>>>> wrote:
>>>> 
>>>> Hi, Avik.
>>>> It seems there is one more bug in this "if".
>>>> Change the input source to "Hindi Dev.."/"Russian.." then this test
>>>> fails anyway(it will produce the double action).
>>>> Moreover if I change the source input to Hindi Transliteration, the
>>>> test sometimes crashed.
>>>> Please double check.
>>>> 
>>>> On 06.04.16 13:42, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> 
>>>>> Kindly review the bug fix for JDK 9.
>>>>> 
>>>>> *Bug:*
>>>>> https://bugs.openjdk.java.net/browse/JDK-8152492
>>>>> 
>>>>> *Webrev:*
>>>>> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.00/
>>>>> 
>>>>> *Issue:*
>>>>> For OSX, having there is provision of non-integrated menubar. for this
>>>>> case, triggering the menu action by key press triggered double action in
>>>>> some cases
>>>>> 
>>>>> *Cause:*
>>>>> Due to the use of Shift modifier being a soft modifier in case of mac.
>>>>> For example “Shift + m” is actually “M” and “Shift + ,” is “<“ .
>>>>> So such cases can not be used as shortcuts. This needs to be
>>>>> accounted for.
>>>>> Also, cases where “Cmd + Shift + c” is used as a shortcut, it should not
>>>>> morph that to a “Cmd + C” command and should detect c itself.
>>>>> Also, “Shift + ↑” has no equivalent soft modification and can be taken
>>>>> as a shortcut. This has to be accounted for.
>>>>> 
>>>>> *Fix:*
>>>>> All required edge case scenarios for the soft modification of Shift and
>>>>> cases of valid modifiers were taken into account.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>> 
>>>> 
>>>> --
>>>> Best regards, Sergey.
>>> 
>> 
> 
> 
> -- 
> Best regards, Sergey.

Re: Review Request of 8152492: [macosx swing] double key event actions when using Mac menubar

[Avik Niyogi]

Hi Sergey,
I have tried all these Input sources:

I am unable to reproduce the test failure as mentioned by you with these 
inputs. Please provide some screenshots and/or details of the procedure used 
for this test failure.
Thank you in advance.

With Regards,
Avik Niyogi

> On 08-Apr-2016, at 8:15 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> Hi, Avik.
> It seems there is one more bug in this "if".
> Change the input source to "Hindi Dev.."/"Russian.." then this test fails 
> anyway(it will produce the double action).
> Moreover if I change the source input to Hindi Transliteration, the test 
> sometimes crashed.
> Please double check.
> 
> On 06.04.16 13:42, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the bug fix for JDK 9.
>> 
>> *Bug:*
>> https://bugs.openjdk.java.net/browse/JDK-8152492
>> 
>> *Webrev:*
>> http://cr.openjdk.java.net/~aniyogi/8152492/webrev.00/
>> 
>> *Issue:*
>> For OSX, having there is provision of non-integrated menubar. for this
>> case, triggering the menu action by key press triggered double action in
>> some cases
>> 
>> *Cause:*
>> Due to the use of Shift modifier being a soft modifier in case of mac.
>> For example “Shift + m” is actually “M” and “Shift + ,” is “<“ .
>> So such cases can not be used as shortcuts. This needs to be accounted for.
>> Also, cases where “Cmd + Shift + c” is used as a shortcut, it should not
>> morph that to a “Cmd + C” command and should detect c itself.
>> Also, “Shift + ↑” has no equivalent soft modification and can be taken
>> as a shortcut. This has to be accounted for.
>> 
>> *Fix:*
>> All required edge case scenarios for the soft modification of Shift and
>> cases of valid modifiers were taken into account.
>> 
>> With Regards,
>> Avik Niyogi
> 
> 
> -- 
> Best regards, Sergey.

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

[Avik Niyogi]

Hi Sergey and Alexander,

Please review the code changes done.

With Regards,
Avik Niyogi
> On 28-Mar-2016, at 1:45 pm, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> A gentle reminder, Please review the code changes as presented below.
> 
> With Regards,
> Avik Niyogi
>> On 24-Mar-2016, at 3:01 pm, Rajeev Chamyal <rajeev.cham...@oracle.com 
>> <mailto:rajeev.cham...@oracle.com>> wrote:
>> 
>> Looks good to me.
>>  
>> Regards,
>> Rajeev Chamyal
>>  
>> From: Avik Niyogi 
>> Sent: 24 March 2016 12:54
>> To: Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov; 
>> swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net>
>> Subject: Re:  Review Request of 8137169 : [macosx] Incorrect 
>> minimal heigh of JTabbedPane with more tabs
>>  
>> Hi All,
>> Please review code changes as per inputs received. 
>>  
>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.03 
>> <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.03>
>>  
>> As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation 
>> within the derived AquaTruncatedTabbedPaneLayout, extending of 
>> TabbedPaneScrollLayout is not needed and management of row and column height 
>> is done within it itself. Hence preferredTabAreaWidth and 
>> preferredTabAreaHeight need not manage the number of columns and rows 
>> respectively and will remain 1 as tabs can be brought forth to the UI by the 
>> arrow buttons AQUA provides instead of placing them in another row or 
>> column. This is also the expected behaviour for AquaLAF as per javadoc.
>>  
>> With Regards,
>> Avik Niyogi
>>  
>> On 24-Mar-2016, at 12:34 pm, Rajeev Chamyal <rajeev.cham...@oracle.com 
>> <mailto:rajeev.cham...@oracle.com>> wrote:
>>  
>> Hello Avik,
>>  
>> x variable on line 2195 is not used anywhere. Do we need for loop also?
>>  
>> Regards,
>> Rajeev Chamyal
>>  
>> From: Avik Niyogi 
>> Sent: 24 March 2016 12:19
>> To: Alexander Scherbatiy
>> Cc: Sergey Bylokhov; Rajeev Chamyal; swing-dev@openjdk.java.net 
>> <mailto:swing-dev@openjdk.java.net>
>> Subject: Re:  Review Request of 8137169 : [macosx] Incorrect 
>> minimal heigh of JTabbedPane with more tabs
>>  
>> Hi All,
>>  
>> Please review my code changes below as per the inputs received.
>>  
>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/ 
>> <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/>
>>  
>> As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation 
>> within the derived AquaTruncatedTabbedPaneLayout, extending of 
>> TabbedPaneScrollLayout is not needed and management of row and column height 
>> is done within it itself. Hence preferredTabAreaWidth and 
>> preferredTabAreaHeight need not manage the number of columns and rows 
>> respectively and will remain 1 as tabs can be brought forth to the UI by the 
>> arrow buttons AQUA provides instead of placing them in another row or 
>> column. This is also the expected behaviour for AquaLAF as per javadoc.
>>  
>> With Regards,
>> Avik Niyogi
>>  
>>  
>> On 23-Mar-2016, at 4:14 pm, Alexander Scherbatiy 
>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>> wrote:
>>  
>> On 23/03/16 14:07, Avik Niyogi wrote:
>> 
>> 
>>  
>> On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy 
>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>> wrote:
>>  
>> On 21/03/16 09:19, Avik Niyogi wrote:
>> 
>> 
>> Hi Alexander, 
>> I agree with what you said regarding the look and feel looking different. 
>> But this bug arrises due to setting of TabbedPaneScrollLayout only. If 
>> Scroll Layout is not meant for Aqua look and feel should not the setting of 
>> this parameter instead throw a helpful error saying this parameter is not 
>> accepted
>>   According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) 
>> javadoc:  
>>   "Some look and feels might only support a subset of the possible layout 
>> policies, in which case the value of this property may be ignored."
>>   
>>   Aqua L ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and always 
>> use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.
>>  
>> Actually, it is doing the other way around for Aqua L It is defaulting 
>> WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still setting 

Re: [9] Review request for JDK-8150225 api/javax_swing/text/AbstractWriter/index_indent failed

[Avik Niyogi]

Hi Rajeev,

The fix looks fine to me.

With Regards,
Avik Niyogi

-Original Message-
From: Rajeev Chamyal 
Sent: 23 March 2016 14:45
To: Sergey Bylokhov; Alexander Scherbatiy; swing-dev@openjdk.java.net 
<mailto:swing-dev@openjdk.java.net>
Subject: RE:  [9] Review request for JDK-8150225 
api/javax_swing/text/AbstractWriter/index_indent failed

Hello Sergey,

I had found below link about pre tag which states A P tag is strictly not 
permitted inside PRE, but if a browser encounters one, it should treat it as 
two newlines.
http://www.htmlhelp.com/reference/wilbur/block/pre.html 
<http://www.htmlhelp.com/reference/wilbur/block/pre.html> 

Regards,
Rajeev Chamyal

-Original Message-
From: Sergey Bylokhov
Sent: 22 March 2016 21:58
To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev@openjdk.java.net 
<mailto:swing-dev@openjdk.java.net>
Subject: Re:  [9] Review request for JDK-8150225 
api/javax_swing/text/AbstractWriter/index_indent failed

Looks fine to me. But I am not an expert here. And I wonder why the  tag is 
so specific, can we get the similar issue if some other tags will be used 
instead?

On 22.03.16 11:35, Rajeev Chamyal wrote:
> Hello All,
> 
> Gentle reminder.
> Please review the fix.
> 
> Bug : https://bugs.openjdk.java.net/browse/JDK-8150225 
> <https://bugs.openjdk.java.net/browse/JDK-8150225>
> Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/ 
> <http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/>
> 
> Regards,
> Rajeev Chamyal
> 
> -Original Message-
> From: Rajeev Chamyal
> Sent: 09 March 2016 15:58
> To: Sergey Bylokhov; Alexander Scherbatiy; swing-dev@openjdk.java.net 
> <mailto:swing-dev@openjdk.java.net>
> Subject: Re:  [9] Review request for JDK-8150225 
> api/javax_swing/text/AbstractWriter/index_indent failed
> 
> Hello Sergey,
> 
> I have run JCK tests for HTMLWriter and AbstractWriter with this fix and all 
> passed.
> 
> Regards,
> Rajeev Chamyal
> 
> -Original Message-
> From: Sergey Bylokhov
> Sent: 09 March 2016 15:54
> To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev@openjdk.java.net 
> <mailto:swing-dev@openjdk.java.net>
> Subject: Re:  [9] Review request for JDK-8150225 
> api/javax_swing/text/AbstractWriter/index_indent failed
> 
> Hi, Rajeev.
> Please confirm that there are no new issues in the jck after this fix.
> 
> On 09.03.16 12:18, Rajeev Chamyal wrote:
>> Hello All,
>> 
>> Please review the following fix for Jdk9:
>> 
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8150225 
>> <https://bugs.openjdk.java.net/browse/JDK-8150225>
>> 
>> Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/ 
>> <http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/>
>> <http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/ 
>> <http://cr.openjdk.java.net/~rchamyal/8146276/webrev.00/>>
>> 
>> Issue : JCK conformance test failed due to fix for bug JDK-7104635
>> 
>> Fix: Reverted the fix for JDK-7104635 and added a new method in 
>> HTMLWriter.java to check if P tag is within Pre tag.
>> 
>> Decrement indentation is skipped if P tag is with a Pre tag.
>> 
>> Regards,
>> 
>> Rajeev Chamyal
>> 
> 
> 
> --
> Best regards, Sergey.
> 


--
Best regards, Sergey.

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

[Avik Niyogi]

Hi All,
Please review code changes as per inputs received. 

http://cr.openjdk.java.net/~aniyogi/8137169/webrev.03 
<http://cr.openjdk.java.net/~aniyogi/8137169/webrev.03>

As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation 
within the derived AquaTruncatedTabbedPaneLayout, extending of 
TabbedPaneScrollLayout is not needed and management of row and column height is 
done within it itself. Hence preferredTabAreaWidth and preferredTabAreaHeight 
need not manage the number of columns and rows respectively and will remain 1 
as tabs can be brought forth to the UI by the arrow buttons AQUA provides 
instead of placing them in another row or column. This is also the expected 
behaviour for AquaLAF as per javadoc.

With Regards,
Avik Niyogi

> On 24-Mar-2016, at 12:34 pm, Rajeev Chamyal <rajeev.cham...@oracle.com> wrote:
> 
> Hello Avik,
>  
> x variable on line 2195 is not used anywhere. Do we need for loop also?
>  
> Regards,
> Rajeev Chamyal
>  
> From: Avik Niyogi 
> Sent: 24 March 2016 12:19
> To: Alexander Scherbatiy
> Cc: Sergey Bylokhov; Rajeev Chamyal; swing-dev@openjdk.java.net
> Subject: Re:  Review Request of 8137169 : [macosx] Incorrect 
> minimal heigh of JTabbedPane with more tabs
>  
> Hi All,
>  
> Please review my code changes below as per the inputs received.
>  
> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/ 
> <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/>
>  
> As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation 
> within the derived AquaTruncatedTabbedPaneLayout, extending of 
> TabbedPaneScrollLayout is not needed and management of row and column height 
> is done within it itself. Hence preferredTabAreaWidth and 
> preferredTabAreaHeight need not manage the number of columns and rows 
> respectively and will remain 1 as tabs can be brought forth to the UI by the 
> arrow buttons AQUA provides instead of placing them in another row or column. 
> This is also the expected behaviour for AquaLAF as per javadoc.
>  
> With Regards,
> Avik Niyogi
>  
>  
> On 23-Mar-2016, at 4:14 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
> wrote:
>  
> On 23/03/16 14:07, Avik Niyogi wrote:
> 
>  
> On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
> wrote:
>  
> On 21/03/16 09:19, Avik Niyogi wrote:
> 
> Hi Alexander, 
> I agree with what you said regarding the look and feel looking different. But 
> this bug arrises due to setting of TabbedPaneScrollLayout only. If Scroll 
> Layout is not meant for Aqua look and feel should not the setting of this 
> parameter instead throw a helpful error saying this parameter is not accepted
>   According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) 
> javadoc:  
>   "Some look and feels might only support a subset of the possible layout 
> policies, in which case the value of this property may be ignored."
>   
>   Aqua L ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and always 
> use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.
>  
> Actually, it is doing the other way around for Aqua L It is defaulting 
> WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still setting a subclass of 
> TabbedPaneLayout and not TabbedPaneScrollLayout.
>According to the JTabbedPane javadoc:
>   SCROLL_TAB_LAYOUT: Tab layout policy for providing a subset of available 
> tabs when all the tabs will not fit within a single run.
>   WRAP_TAB_LAYOUT The tab layout policy for wrapping tabs in multiple runs 
> when all tabs will not fit within a single run.
>  
>The Aqua L uses only AquaTabbedPaneUI and AquaTabbedPaneContrastUI for 
> tabbed pane UI and they both returns AquaTruncatingTabbedPaneLayout which has 
> been designed for to place tabs according to the SCROLL_TAB_LAYOUT.
> 
>   Thanks,
>   Alexandr.
> 
> 
> 
>   Thanks,
>   Alexandr.
> 
> 
> instead of absorbing this parameter and letting it render itself into a dummy 
> node which does not proceed further with this parameter? Maybe we need to 
> discuss what the expected behaviour may be. Also, thank you for the inputs 
> regarding how to proceed with removing duplicate code.
>  
> With Regards,
> Avik Niyogi
> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
> wrote:
>  
> 
> I would think about something like:
> -
> public class TabbedPaneLayout implements LayoutManager {
> 
> protected int basePreferredTabAre

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

[Avik Niyogi]

Hi All,

Please review my code changes below as per the inputs received.

http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/ 
<http://cr.openjdk.java.net/~aniyogi/8137169/webrev.02/>

As SCROLL_TAB_LAYOUT is the default layout for Aqua LAF, with implementation 
within the derived AquaTruncatedTabbedPaneLayout, extending of 
TabbedPaneScrollLayout is not needed and management of row and column height is 
done within it itself. Hence preferredTabAreaWidth and preferredTabAreaHeight 
need not manage the number of columns and rows respectively and will remain 1 
as tabs can be brought forth to the UI by the arrow buttons AQUA provides 
instead of placing them in another row or column. This is also the expected 
behaviour for AquaLAF as per javadoc.

With Regards,
Avik Niyogi


> On 23-Mar-2016, at 4:14 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> On 23/03/16 14:07, Avik Niyogi wrote:
>> 
>>> On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> On 21/03/16 09:19, Avik Niyogi wrote:
>>>> Hi Alexander,
>>>> I agree with what you said regarding the look and feel looking different. 
>>>> But this bug arrises due to setting of TabbedPaneScrollLayout only. If 
>>>> Scroll Layout is not meant for Aqua look and feel should not the setting 
>>>> of this parameter instead throw a helpful error saying this parameter is 
>>>> not accepted
>>>   According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) 
>>> javadoc:  
>>>   "Some look and feels might only support a subset of the possible layout 
>>> policies, in which case the value of this property may be ignored."
>>>   
>>>   Aqua L ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and 
>>> always use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.
>> 
>> Actually, it is doing the other way around for Aqua L It is defaulting 
>> WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still setting a subclass of 
>> TabbedPaneLayout and not TabbedPaneScrollLayout.
>According to the JTabbedPane javadoc:
>   SCROLL_TAB_LAYOUT: Tab layout policy for providing a subset of available 
> tabs when all the tabs will not fit within a single run.
>   WRAP_TAB_LAYOUT The tab layout policy for wrapping tabs in multiple runs 
> when all tabs will not fit within a single run.
>  
>The Aqua L uses only AquaTabbedPaneUI and AquaTabbedPaneContrastUI for 
> tabbed pane UI and they both returns AquaTruncatingTabbedPaneLayout which has 
> been designed for to place tabs according to the SCROLL_TAB_LAYOUT.
> 
>   Thanks,
>   Alexandr.
>> 
>>>   Thanks,
>>>   Alexandr.
>>> 
>>>> instead of absorbing this parameter and letting it render itself into a 
>>>> dummy node which does not proceed further with this parameter? Maybe we 
>>>> need to discuss what the expected behaviour may be. Also, thank you for 
>>>> the inputs regarding how to proceed with removing duplicate code.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy < 
>>>>> <mailto:alexandr.scherba...@oracle.com>alexandr.scherba...@oracle.com 
>>>>> <mailto:alexandr.scherba...@oracle.com>> wrote:
>>>>> 
>>>>> 
>>>>> I would think about something like:
>>>>> -
>>>>> public class TabbedPaneLayout implements LayoutManager {
>>>>> 
>>>>> protected int basePreferredTabAreaWidth(final int tabPlacement, 
>>>>> final int height) {
>>>>> // TabbedPaneLayout preferredTabAreaWidth implementation
>>>>> }
>>>>> 
>>>>> protected int truncatingPreferredTabAreaWidth(final int 
>>>>> tabPlacement, final int height) {
>>>>> if (tabPlacement == SwingConstants.LEFT || tabPlacement == 
>>>>> SwingConstants.RIGHT) {
>>>>> return basePreferredTabAreaWidth(tabPlacement, height);
>>>>> }
>>>>> 
>>>>> return basePreferredTabAreaWidth(tabPlacement, height);
>>>>> }
>>>>> 
>>>>> protected int preferredTabAreaWidth(final int tabPlacement, final 
>>>>> int height) {
>>>>> ret

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

[Avik Niyogi]

> On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> On 21/03/16 09:19, Avik Niyogi wrote:
>> Hi Alexander,
>> I agree with what you said regarding the look and feel looking different. 
>> But this bug arrises due to setting of TabbedPaneScrollLayout only. If 
>> Scroll Layout is not meant for Aqua look and feel should not the setting of 
>> this parameter instead throw a helpful error saying this parameter is not 
>> accepted
>   According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) 
> javadoc:  
>   "Some look and feels might only support a subset of the possible layout 
> policies, in which case the value of this property may be ignored."
>   
>   Aqua L ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and always 
> use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.

Actually, it is doing the other way around for Aqua L It is defaulting 
WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still setting a subclass of 
TabbedPaneLayout and not TabbedPaneScrollLayout.

>   Thanks,
>   Alexandr.
> 
>> instead of absorbing this parameter and letting it render itself into a 
>> dummy node which does not proceed further with this parameter? Maybe we need 
>> to discuss what the expected behaviour may be. Also, thank you for the 
>> inputs regarding how to proceed with removing duplicate code.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> 
>>> I would think about something like:
>>> -
>>> public class TabbedPaneLayout implements LayoutManager {
>>> 
>>> protected int basePreferredTabAreaWidth(final int tabPlacement, 
>>> final int height) {
>>> // TabbedPaneLayout preferredTabAreaWidth implementation
>>> }
>>> 
>>> protected int truncatingPreferredTabAreaWidth(final int 
>>> tabPlacement, final int height) {
>>> if (tabPlacement == SwingConstants.LEFT || tabPlacement == 
>>> SwingConstants.RIGHT) {
>>> return basePreferredTabAreaWidth(tabPlacement, height);
>>> }
>>> 
>>> return basePreferredTabAreaWidth(tabPlacement, height);
>>> }
>>> 
>>> protected int preferredTabAreaWidth(final int tabPlacement, final 
>>> int height) {
>>> return basePreferredTabAreaWidth(tabPlacement, height);
>>> }
>>> 
>>> }
>>> 
>>> class TabbedPaneScrollLayout extends TabbedPaneLayout {
>>> @Override
>>> protected int basePreferredTabAreaWidth(int tabPlacement, int 
>>> height) {
>>> // TabbedPaneScrollLayout preferredTabAreaWidth implementation
>>> }
>>> }
>>> 
>>> protected class AquaTruncatingTabbedPaneLayout extends 
>>> AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
>>> 
>>> @Override
>>> protected int preferredTabAreaWidth(final int tabPlacement, final 
>>> int height) {
>>> return truncatingPreferredTabAreaWidth(tabPlacement, height);
>>> }
>>> }
>>> 
>>> protected class AquaTruncatingTabbedScrollPaneLayout extends 
>>> AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
>>> 
>>> @Override
>>> protected int preferredTabAreaWidth(final int tabPlacement, final 
>>> int height) {
>>> return truncatingPreferredTabAreaWidth(tabPlacement, height);
>>> }
>>> }
>>> -
>>> 
>>> I just have one more question. The TabbedPaneScrollLayout is only created 
>>> in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI 
>>> or AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 
>>> 
>>> Are there any real cases when the TabbedPaneScrollLayout is created?
>>> 
>>> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the 
>>> AquaTabbedPaneUI the JTabbedPane L with SCROLL_TAB_LAYOUT does not look 
>>> similar to Aqua L:
>>>   http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png 
>>> <http://cr.openjdk.java.net/%7Ealexsch/8137169/aqua-scrolled-tabbed-pane.png>
>>> 
>>> The Aqu

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

[Avik Niyogi]

Hi Alexander,
With inputs (code) provided, it is not possible to accommodate the right 
methods for tabPlacement parameter.
Also, since AquaTabbedPane is copied from BasicUI.java, this implementation if 
moved to TabbedPaneLayout, does not accommodate Awua related changes and hence, 
the redundant code is in effect.
Also, regarding the query about the below:
> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs 
> navigation.
> May be the fix should update the AquaTruncatingTabbedPaneLayout only?

The defect due to the bug is injected only if Scrolling is in effect. The 
non-scrolling values populated for tabbedPaneLayout tried to add another row 
and hence would result in defects.
This was due to the fact that TabbedPaneScrollLayout was not even getting set 
even when the user was trying to set it.
Ideally, it would have been easier to call the super class to manage just the 
layout part but as per inputs received, it will not be accepted even though it 
have no splash impact and would not lead to regressions. 
Due to those reasons, this is the solution seeming fit for this.
I have tried the way suggested in your input code, but it broke the UI and 
different elements not required to be visible were being rendered because it is 
copying those elements from BasicUI.
If a better solution is available without breaking some code apart from fix 
provided, please let me know. Thank you in advance.

With Regards,
Avik Niyogi

> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> 
> I would think about something like:
> -
> public class TabbedPaneLayout implements LayoutManager {
> 
> protected int basePreferredTabAreaWidth(final int tabPlacement, final 
> int height) {
> // TabbedPaneLayout preferredTabAreaWidth implementation
> }
> 
> protected int truncatingPreferredTabAreaWidth(final int tabPlacement, 
> final int height) {
> if (tabPlacement == SwingConstants.LEFT || tabPlacement == 
> SwingConstants.RIGHT) {
> return basePreferredTabAreaWidth(tabPlacement, height);
> }
> 
> return basePreferredTabAreaWidth(tabPlacement, height);
> }
> 
> protected int preferredTabAreaWidth(final int tabPlacement, final int 
> height) {
> return basePreferredTabAreaWidth(tabPlacement, height);
> }
> 
> }
> 
> class TabbedPaneScrollLayout extends TabbedPaneLayout {
> @Override
> protected int basePreferredTabAreaWidth(int tabPlacement, int height) 
> {
> // TabbedPaneScrollLayout preferredTabAreaWidth implementation
> }
> }
> 
> protected class AquaTruncatingTabbedPaneLayout extends 
> AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
> 
> @Override
> protected int preferredTabAreaWidth(final int tabPlacement, final int 
> height) {
> return truncatingPreferredTabAreaWidth(tabPlacement, height);
> }
> }
> 
> protected class AquaTruncatingTabbedScrollPaneLayout extends 
> AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
> 
> @Override
> protected int preferredTabAreaWidth(final int tabPlacement, final int 
> height) {
> return truncatingPreferredTabAreaWidth(tabPlacement, height);
> }
> }
> -
> 
> I just have one more question. The TabbedPaneScrollLayout is only created in 
> AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI or 
> AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 
> 
> Are there any real cases when the TabbedPaneScrollLayout is created?
> 
> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the 
> AquaTabbedPaneUI the JTabbedPane L with SCROLL_TAB_LAYOUT does not look 
> similar to Aqua L:
>   http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png 
> <http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png>
> 
> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs 
> navigation.
> May be the fix should update the AquaTruncatingTabbedPaneLayout only?
> 
> Thanks,
> Alexandr.
> 
> On 18/03/16 14:21, Avik Niyogi wrote:
>> Hi Alexander,
>> Thank you for the inputs. I agree with you and did feel the need for 
>> removing duplicate code as well. But as per an earlier review input, changes 
>> to the super call lay outing is not accepted. This was the only other 
>> feasible solution. Created redundant code in this process, but would be 
>> maintaining with requirements with code impact to superclasses.
>> Please provide any insight to a probable compens

Re: Review Request of 8151282: [TEST_BUG] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails with GTK LnF

[Avik Niyogi]

Hi All,
Please find webrev with new code fix:
http://cr.openjdk.java.net/~aniyogi/8151282/webrev.02/ 
<http://cr.openjdk.java.net/~aniyogi/8151282/webrev.02/>

With Regards,
Avik Niyogi

> On 21-Mar-2016, at 8:07 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> Hi, Avik.
> How this test can fail? I do not see any raised exceptions.
> 
> On 21.03.16 9:46, Avik Niyogi wrote:
>> Hi Sergey,
>> Please review the following code change.
>> With Regards,
>> Avik Niyogi
>>> On 19-Mar-2016, at 2:15 am, Alexander Scherbatiy
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>
>>> <mailto:alexandr.scherba...@oracle.com 
>>> <mailto:alexandr.scherba...@oracle.com>>> wrote:
>>> 
>>> The fix looks good to me.
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 14/03/16 16:25, Avik Niyogi wrote:
>>>> Hi All,
>>>> Please review code changes made as per inputs provided.
>>>> 
>>>> http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/ 
>>>> <http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/>
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8151282/webrev.01/ 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8151282/webrev.01/>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 14-Mar-2016, at 10:53 am, Avik Niyogi
>>>>> <<mailto:avik.niy...@oracle.com 
>>>>> <mailto:avik.niy...@oracle.com>>avik.niy...@oracle.com 
>>>>> <mailto:avik.niy...@oracle.com>> wrote:
>>>>> 
>>>>> Hi Sergey,
>>>>> Seems like it is a delay issue. Will submit test case with a
>>>>> waitForIdle() fix.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>> On 10-Mar-2016, at 7:22 pm, Sergey Bylokhov
>>>>>> <sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com> 
>>>>>> <mailto:sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com>>> 
>>>>>> wrote:
>>>>>> 
>>>>>> Hi, Avik.
>>>>>> A few questions.
>>>>>> - Why webrev contains the new file?
>>>>>> - You marked the test as a mac specific but it is iterates over a
>>>>>> bunch of l It seems it should not be OS specific, but should
>>>>>> check some specific l (which support such icons): Metal, Nimbus,
>>>>>> Aqua, Windows(???). So gtk/motif should be skipped.
>>>>>> 
>>>>>> On 08.03.16 8:10, Avik Niyogi wrote:
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>> 
>>>>>>> *Bug:*
>>>>>>> 
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151282
>>>>>>> 
>>>>>>> *Webrev:*
>>>>>>> 
>>>>>>> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_
>>>>>>> _
>>>>>>> _
>>>>>>> *Issue:*
>>>>>>> The test case failed for GTK LAF.
>>>>>>> 
>>>>>>> *Cause:*
>>>>>>> The test case was meant to be Mac specific and was missing a jtreg
>>>>>>> parameter
>>>>>>> 
>>>>>>> *Fix:*
>>>>>>> Minor change to test case with @requires tag added to set the fix.
>>>>>>> 
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>> 
>>>> 
>>> 
>> 
> 
> 
> -- 
> Best regards, Sergey.

Re: Review Request of 8148555: [macosx] An uncaught exception was raised entering Emoji into JTextArea

[Avik Niyogi]

Hi All,
Please review the below code changes as per the inputs received.
http://cr.openjdk.java.net/~aniyogi/8148555/webrev.01/ 
<http://cr.openjdk.java.net/~aniyogi/8148555/webrev.01/>


With Regards,
Avik Niyogi
> On 21-Mar-2016, at 12:45 pm, Rajeev Chamyal <rajeev.cham...@oracle.com> wrote:
> 
> Hello Avik,
>  
> I can’t comment on objective C code.
> As far as test is concerned below are my comments.
>  
> 1)  UI should be created in Swing thread.
> 2)  Switch case in  actionPerformed should be refactored.
>  
> Regards,
> Rajeev Chamyal
>  
> From: Avik Niyogi 
> Sent: 21 March 2016 12:20
> To: Sergey Bylokhov
> Cc: swing-dev@openjdk.java.net; Alexander Scherbatiy; Rajeev Chamyal
> Subject: Re:  Review Request of 8148555: [macosx] An uncaught 
> exception was raised entering Emoji into JTextArea
>  
> Hi Rajeev,
> Please review the following code changes.
>  
> With Regards,
> Avik Niyogi
> On 21-Mar-2016, at 12:17 pm, Avik Niyogi <avik.niy...@oracle.com 
> <mailto:avik.niy...@oracle.com>> wrote:
>  
> Hi Sergey,
>  
> Please review the following code changes.
> With Regards,
> Avik Niyogi
> On 17-Mar-2016, at 7:03 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
> wrote:
>  
> 
> The fix looks good to me.
> 
> Just a small note: it is better to remove comment "527 //" since it 
> does not have a description.
> 
> Thanks,
> Alexandr.
> 
> On 17/03/16 17:21, Avik Niyogi wrote:
> It can be made into a class method, but herein this case it is needed for 
> that instance only and hence the need for instance method and referred with 
> “self”. 
>  
> With Regards,
> Avik Niyogi
> On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
> wrote:
>  
> 
> Could the -(NSMutableString *) parseString: method be declared as class 
> method instead of instance?
> 
> Thanks,
> Alexandr.
> 
> On 14/03/16 17:18, Sergey Bylokhov wrote:
> Hi, Avik. 
> Can you please take a look to these two tests before fixing this bug: 
> 
> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java 
> ------ 
> TEST: 
> javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
> 
> I remember they passed on jdk8, but it seems we have a regression in jdk9 and 
> both of them fail. 
> 
> On 14.03.16 8:05, Avik Niyogi wrote: 
> 
> Hi All, 
> A gentle reminder, please review my code changes. 
> 
> With Regards, 
> Avik Niyogi 
> 
> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niy...@oracle.com 
> <mailto:avik.niy...@oracle.com> 
> <mailto:avik.niy...@oracle.com> <mailto:avik.niy...@oracle.com>> wrote: 
> 
> Hi All, 
> 
> Kindly review the bug fix for JDK 9. 
> 
> *Bug:* 
> 
> _https://bugs.openjdk.java.net/browse/JDK-8148555_ 
> <https://bugs.openjdk.java.net/browse/JDK-8148555_> 
> _ 
> _ 
> *Webrev:* 
> 
> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8148555/webrev.00/_> 
> 
> *Issue:* 
> Emoji selection in Character Viewer was causing exception in JNI 
> 
> *Cause:* 
> Emojis are considered to be of different class type (namely, 
> NSConcreteMutableAttributedString) from NSString which other 
> characters are because of a surrogate pair for them. 
> 
> *Fix:* 
> Major changes done for condition of emojis in JNI. Albeit rendering is 
> not yet supported, they will appear as blank “Missing font” notation. 
> Also, added debug point in case of issue with glyph arrises. 
> 
> With Regards, 
> Avik Niyogi 

Re: Review Request of 8148555: [macosx] An uncaught exception was raised entering Emoji into JTextArea

[Avik Niyogi]

Hi Manajit,
Please review the following code changes.

With Regards,
Avik Niyogi
> On 21-Mar-2016, at 12:20 pm, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> Hi Rajeev,
> Please review the following code changes.
> 
> With Regards,
> Avik Niyogi
>> On 21-Mar-2016, at 12:17 pm, Avik Niyogi <avik.niy...@oracle.com 
>> <mailto:avik.niy...@oracle.com>> wrote:
>> 
>> Hi Sergey,
>> 
>> Please review the following code changes.
>> With Regards,
>> Avik Niyogi
>>> On 17-Mar-2016, at 7:03 pm, Alexander Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> 
>>> The fix looks good to me.
>>> 
>>> Just a small note: it is better to remove comment "527 //" since it 
>>> does not have a description.
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 17/03/16 17:21, Avik Niyogi wrote:
>>>> It can be made into a class method, but herein this case it is needed for 
>>>> that instance only and hence the need for instance method and referred 
>>>> with “self”.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy 
>>>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> Could the -(NSMutableString *) parseString: method be declared as class 
>>>>> method instead of instance?
>>>>> 
>>>>> Thanks,
>>>>> Alexandr.
>>>>> 
>>>>> On 14/03/16 17:18, Sergey Bylokhov wrote:
>>>>>> Hi, Avik. 
>>>>>> Can you please take a look to these two tests before fixing this bug: 
>>>>>> 
>>>>>> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java 
>>>>>> -- 
>>>>>> TEST: 
>>>>>> javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
>>>>>> 
>>>>>> I remember they passed on jdk8, but it seems we have a regression in 
>>>>>> jdk9 and both of them fail. 
>>>>>> 
>>>>>> On 14.03.16 8:05, Avik Niyogi wrote: 
>>>>>>> Hi All, 
>>>>>>> A gentle reminder, please review my code changes. 
>>>>>>> 
>>>>>>> With Regards, 
>>>>>>> Avik Niyogi 
>>>>>>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niy...@oracle.com 
>>>>>>>> <mailto:avik.niy...@oracle.com> 
>>>>>>>> <mailto:avik.niy...@oracle.com> <mailto:avik.niy...@oracle.com>> 
>>>>>>>> wrote: 
>>>>>>>> 
>>>>>>>> Hi All, 
>>>>>>>> 
>>>>>>>> Kindly review the bug fix for JDK 9. 
>>>>>>>> 
>>>>>>>> *Bug:* 
>>>>>>>> 
>>>>>>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_ 
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8148555_> 
>>>>>>>> _ 
>>>>>>>> _ 
>>>>>>>> *Webrev:* 
>>>>>>>> 
>>>>>>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_ 
>>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8148555/webrev.00/_> 
>>>>>>>> 
>>>>>>>> *Issue:* 
>>>>>>>> Emoji selection in Character Viewer was causing exception in JNI 
>>>>>>>> 
>>>>>>>> *Cause:* 
>>>>>>>> Emojis are considered to be of different class type (namely, 
>>>>>>>> NSConcreteMutableAttributedString) from NSString which other 
>>>>>>>> characters are because of a surrogate pair for them. 
>>>>>>>> 
>>>>>>>> *Fix:* 
>>>>>>>> Major changes done for condition of emojis in JNI. Albeit rendering is 
>>>>>>>> not yet supported, they will appear as blank “Missing font” notation. 
>>>>>>>> Also, added debug point in case of issue with glyph arrises. 
>>>>>>>> 
>>>>>>>> With Regards, 
>>>>>>>> Avik Niyogi 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: Review Request of 8148555: [macosx] An uncaught exception was raised entering Emoji into JTextArea

[Avik Niyogi]

Hi Rajeev,
Please review the following code changes.

With Regards,
Avik Niyogi
> On 21-Mar-2016, at 12:17 pm, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> Hi Sergey,
> 
> Please review the following code changes.
> With Regards,
> Avik Niyogi
>> On 17-Mar-2016, at 7:03 pm, Alexander Scherbatiy 
>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>> wrote:
>> 
>> 
>> The fix looks good to me.
>> 
>> Just a small note: it is better to remove comment "527 //" since it 
>> does not have a description.
>> 
>> Thanks,
>> Alexandr.
>> 
>> On 17/03/16 17:21, Avik Niyogi wrote:
>>> It can be made into a class method, but herein this case it is needed for 
>>> that instance only and hence the need for instance method and referred with 
>>> “self”.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy 
>>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>>> wrote:
>>>> 
>>>> 
>>>> Could the -(NSMutableString *) parseString: method be declared as class 
>>>> method instead of instance?
>>>> 
>>>> Thanks,
>>>> Alexandr.
>>>> 
>>>> On 14/03/16 17:18, Sergey Bylokhov wrote:
>>>>> Hi, Avik. 
>>>>> Can you please take a look to these two tests before fixing this bug: 
>>>>> 
>>>>> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java 
>>>>> ------ 
>>>>> TEST: 
>>>>> javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
>>>>> 
>>>>> I remember they passed on jdk8, but it seems we have a regression in jdk9 
>>>>> and both of them fail. 
>>>>> 
>>>>> On 14.03.16 8:05, Avik Niyogi wrote: 
>>>>>> Hi All, 
>>>>>> A gentle reminder, please review my code changes. 
>>>>>> 
>>>>>> With Regards, 
>>>>>> Avik Niyogi 
>>>>>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niy...@oracle.com 
>>>>>>> <mailto:avik.niy...@oracle.com> 
>>>>>>> <mailto:avik.niy...@oracle.com> <mailto:avik.niy...@oracle.com>> wrote: 
>>>>>>> 
>>>>>>> Hi All, 
>>>>>>> 
>>>>>>> Kindly review the bug fix for JDK 9. 
>>>>>>> 
>>>>>>> *Bug:* 
>>>>>>> 
>>>>>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_ 
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8148555_> 
>>>>>>> _ 
>>>>>>> _ 
>>>>>>> *Webrev:* 
>>>>>>> 
>>>>>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_ 
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8148555/webrev.00/_> 
>>>>>>> 
>>>>>>> *Issue:* 
>>>>>>> Emoji selection in Character Viewer was causing exception in JNI 
>>>>>>> 
>>>>>>> *Cause:* 
>>>>>>> Emojis are considered to be of different class type (namely, 
>>>>>>> NSConcreteMutableAttributedString) from NSString which other 
>>>>>>> characters are because of a surrogate pair for them. 
>>>>>>> 
>>>>>>> *Fix:* 
>>>>>>> Major changes done for condition of emojis in JNI. Albeit rendering is 
>>>>>>> not yet supported, they will appear as blank “Missing font” notation. 
>>>>>>> Also, added debug point in case of issue with glyph arrises. 
>>>>>>> 
>>>>>>> With Regards, 
>>>>>>> Avik Niyogi 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: Review Request of 8148555: [macosx] An uncaught exception was raised entering Emoji into JTextArea

[Avik Niyogi]

Hi Sergey,

Please review the following code changes.
With Regards,
Avik Niyogi
> On 17-Mar-2016, at 7:03 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> 
> The fix looks good to me.
> 
> Just a small note: it is better to remove comment "527 //" since it 
> does not have a description.
> 
> Thanks,
> Alexandr.
> 
> On 17/03/16 17:21, Avik Niyogi wrote:
>> It can be made into a class method, but herein this case it is needed for 
>> that instance only and hence the need for instance method and referred with 
>> “self”.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> 
>>> Could the -(NSMutableString *) parseString: method be declared as class 
>>> method instead of instance?
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 14/03/16 17:18, Sergey Bylokhov wrote:
>>>> Hi, Avik. 
>>>> Can you please take a look to these two tests before fixing this bug: 
>>>> 
>>>> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java 
>>>> ------ 
>>>> TEST: 
>>>> javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
>>>> 
>>>> I remember they passed on jdk8, but it seems we have a regression in jdk9 
>>>> and both of them fail. 
>>>> 
>>>> On 14.03.16 8:05, Avik Niyogi wrote: 
>>>>> Hi All, 
>>>>> A gentle reminder, please review my code changes. 
>>>>> 
>>>>> With Regards, 
>>>>> Avik Niyogi 
>>>>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niy...@oracle.com 
>>>>>> <mailto:avik.niy...@oracle.com> 
>>>>>> <mailto:avik.niy...@oracle.com> <mailto:avik.niy...@oracle.com>> wrote: 
>>>>>> 
>>>>>> Hi All, 
>>>>>> 
>>>>>> Kindly review the bug fix for JDK 9. 
>>>>>> 
>>>>>> *Bug:* 
>>>>>> 
>>>>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_ 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8148555_> 
>>>>>> _ 
>>>>>> _ 
>>>>>> *Webrev:* 
>>>>>> 
>>>>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_ 
>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8148555/webrev.00/_> 
>>>>>> 
>>>>>> *Issue:* 
>>>>>> Emoji selection in Character Viewer was causing exception in JNI 
>>>>>> 
>>>>>> *Cause:* 
>>>>>> Emojis are considered to be of different class type (namely, 
>>>>>> NSConcreteMutableAttributedString) from NSString which other 
>>>>>> characters are because of a surrogate pair for them. 
>>>>>> 
>>>>>> *Fix:* 
>>>>>> Major changes done for condition of emojis in JNI. Albeit rendering is 
>>>>>> not yet supported, they will appear as blank “Missing font” notation. 
>>>>>> Also, added debug point in case of issue with glyph arrises. 
>>>>>> 
>>>>>> With Regards, 
>>>>>> Avik Niyogi 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
> 

Re: Review Request of 8151282: [TEST_BUG] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails with GTK LnF

[Avik Niyogi]

Hi Sergey,
Please review the following code change.
With Regards,
Avik Niyogi
> On 19-Mar-2016, at 2:15 am, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> The fix looks good to me.
> 
> Thanks,
> Alexandr.
> 
> On 14/03/16 16:25, Avik Niyogi wrote:
>> Hi All,
>> Please review code changes made as per inputs provided.
>> 
>> http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8151282/webrev.01/>
>> With Regards,
>> Avik Niyogi
>>> On 14-Mar-2016, at 10:53 am, Avik Niyogi < 
>>> <mailto:avik.niy...@oracle.com>avik.niy...@oracle.com 
>>> <mailto:avik.niy...@oracle.com>> wrote:
>>> 
>>> Hi Sergey,
>>> Seems like it is a delay issue. Will submit test case with a waitForIdle() 
>>> fix.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 10-Mar-2016, at 7:22 pm, Sergey Bylokhov <sergey.bylok...@oracle.com 
>>>> <mailto:sergey.bylok...@oracle.com>> wrote:
>>>> 
>>>> Hi, Avik.
>>>> A few questions.
>>>> - Why webrev contains the new file?
>>>> - You marked the test as a mac specific but it is iterates over a bunch of 
>>>> l It seems it should not be OS specific, but should check some 
>>>> specific l (which support such icons): Metal, Nimbus, Aqua, 
>>>> Windows(???). So gtk/motif should be skipped.
>>>> 
>>>> On 08.03.16 8:10, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> 
>>>>> Kindly review the bug fix for JDK 9.
>>>>> 
>>>>> *Bug:*
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8151282 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8151282>
>>>>> 
>>>>> *Webrev:*
>>>>> 
>>>>> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_ 
>>>>> <http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_>
>>>>> _
>>>>> _
>>>>> *Issue:*
>>>>> The test case failed for GTK LAF.
>>>>> 
>>>>> *Cause:*
>>>>> The test case was meant to be Mac specific and was missing a jtreg 
>>>>> parameter
>>>>> 
>>>>> *Fix:*
>>>>> Minor change to test case with @requires tag added to set the fix.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>> 
>>>> 
>>>> -- 
>>>> Best regards, Sergey.
>>> 
>> 
> 

Re: Review request for 8015748: JProgressbar with Aqua LaF ignores JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) call

[Avik Niyogi]

Hi Sergey,
This bug fix has been committed and resolved. Does not require a review.

With Regards,
Avik Niyogi
> On 21-Mar-2016, at 10:42 am, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> Hi Sergey,
> https://bugs.openjdk.java.net/browse/JDK-8151282 
> <https://bugs.openjdk.java.net/browse/JDK-8151282> is open and in progress.
> With Regards,
> Avik Niyogi
> 
>> On 19-Mar-2016, at 4:52 pm, Sergey Bylokhov <sergey.bylok...@oracle.com 
>> <mailto:sergey.bylok...@oracle.com>> wrote:
>> 
>> I guess you need a separate CR for this, because JDK-8015748 was closed 
>> already.
>> 
>> On 21.01.16 6:49, Avik Niyogi wrote:
>>> Hi All,
>>> Please review my code change with inputs received:
>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.08/ 
>>> <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.08/>
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 21-Jan-2016, at 8:30 am, Avik Niyogi <avik.niy...@oracle.com 
>>>> <mailto:avik.niy...@oracle.com>
>>>> <mailto:avik.niy...@oracle.com <mailto:avik.niy...@oracle.com>>> wrote:
>>>> 
>>>> Hi Sergey,
>>>> The JTreg will pass, but the errors are posted to the log and not as
>>>> an interrupt as it would prematurely terminate execution of entire
>>>> test case for other look and feels if done so.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 21-Jan-2016, at 8:26 am, Avik Niyogi <avik.niy...@oracle.com 
>>>>> <mailto:avik.niy...@oracle.com>
>>>>> <mailto:avik.niy...@oracle.com <mailto:avik.niy...@oracle.com>>> wrote:
>>>>> 
>>>>> Hi Sergey,
>>>>> This is the *log* of the test *JProgressBarOrientationRobotTest.java*
>>>>> after doing a *make java.desktop* after commenting out my code
>>>>> changes in *AquaProgressBarUI.java* :
>>>>> 
>>>>> run:
>>>>> [Metal]: LTR orientation test passed
>>>>> [Metal]: RTL orientation test passed
>>>>> [Nimbus]: LTR orientation test passed
>>>>> [Nimbus]: RTL orientation test passed
>>>>> [CDE/Motif]: LTR orientation test passed
>>>>> [CDE/Motif]: RTL orientation test passed
>>>>> [Mac OS X]: LTR orientation test passed
>>>>> [Mac OS X]: [Error]: LTR orientation test failed
>>>>> [Mac OS X]: [Error]: LTR orientation test failed
>>>>> BUILD SUCCESSFUL (total time: 31 seconds)
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>> 
>>>>>> On 20-Jan-2016, at 4:30 pm, Alexander Scherbatiy
>>>>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>
>>>>>> <mailto:alexandr.scherba...@oracle.com 
>>>>>> <mailto:alexandr.scherba...@oracle.com>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> The fix looks good to me.
>>>>>> 
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>> 
>>>>>> On 1/20/2016 12:47 PM, Rajeev Chamyal wrote:
>>>>>>> 
>>>>>>> Looks good to me.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Rajeev Chamyal
>>>>>>> 
>>>>>>> *From:*Avik Niyogi
>>>>>>> *Sent:* 20 January 2016 12:23
>>>>>>> *To:* Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov
>>>>>>> *Cc:* swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net> 
>>>>>>> <mailto:swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net>>
>>>>>>> *Subject:* Re:  Review request for 8015748: JProgressbar
>>>>>>> with Aqua LaF ignores
>>>>>>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>>>>>> call
>>>>>>> 
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> Please review the code changes made as with inputs for the webrev:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/ 
>>>>>>> <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/>
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/ 

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

[Avik Niyogi]

Hi Alexander,
I agree with what you said regarding the look and feel looking different. But 
this bug arrises due to setting of TabbedPaneScrollLayout only. If Scroll 
Layout is not meant for Aqua look and feel should not the setting of this 
parameter instead throw a helpful error saying this parameter is not accepted 
instead of absorbing this parameter and letting it render itself into a dummy 
node which does not proceed further with this parameter? Maybe we need to 
discuss what the expected behaviour may be. Also, thank you for the inputs 
regarding how to proceed with removing duplicate code.

With Regards,
Avik Niyogi
> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> 
> I would think about something like:
> -
> public class TabbedPaneLayout implements LayoutManager {
> 
> protected int basePreferredTabAreaWidth(final int tabPlacement, final 
> int height) {
> // TabbedPaneLayout preferredTabAreaWidth implementation
> }
> 
> protected int truncatingPreferredTabAreaWidth(final int tabPlacement, 
> final int height) {
> if (tabPlacement == SwingConstants.LEFT || tabPlacement == 
> SwingConstants.RIGHT) {
> return basePreferredTabAreaWidth(tabPlacement, height);
> }
> 
> return basePreferredTabAreaWidth(tabPlacement, height);
> }
> 
> protected int preferredTabAreaWidth(final int tabPlacement, final int 
> height) {
> return basePreferredTabAreaWidth(tabPlacement, height);
> }
> 
> }
> 
> class TabbedPaneScrollLayout extends TabbedPaneLayout {
> @Override
> protected int basePreferredTabAreaWidth(int tabPlacement, int height) 
> {
> // TabbedPaneScrollLayout preferredTabAreaWidth implementation
> }
> }
> 
> protected class AquaTruncatingTabbedPaneLayout extends 
> AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
> 
> @Override
> protected int preferredTabAreaWidth(final int tabPlacement, final int 
> height) {
> return truncatingPreferredTabAreaWidth(tabPlacement, height);
> }
> }
> 
> protected class AquaTruncatingTabbedScrollPaneLayout extends 
> AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
> 
> @Override
> protected int preferredTabAreaWidth(final int tabPlacement, final int 
> height) {
> return truncatingPreferredTabAreaWidth(tabPlacement, height);
> }
> }
> -
> 
> I just have one more question. The TabbedPaneScrollLayout is only created in 
> AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI or 
> AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 
> 
> Are there any real cases when the TabbedPaneScrollLayout is created?
> 
> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the 
> AquaTabbedPaneUI the JTabbedPane L with SCROLL_TAB_LAYOUT does not look 
> similar to Aqua L:
>   http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png 
> <http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png>
> 
> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs 
> navigation.
> May be the fix should update the AquaTruncatingTabbedPaneLayout only?
> 
> Thanks,
> Alexandr.
> 
> On 18/03/16 14:21, Avik Niyogi wrote:
>> Hi Alexander,
>> Thank you for the inputs. I agree with you and did feel the need for 
>> removing duplicate code as well. But as per an earlier review input, changes 
>> to the super call lay outing is not accepted. This was the only other 
>> feasible solution. Created redundant code in this process, but would be 
>> maintaining with requirements with code impact to superclasses.
>> Please provide any insight to a probable compensate to mitigate this 
>> dichotomy of code expectation. Thank you in advance.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> 
>>> It is not usually a good idea to have a duplicated code which should be 
>>> updated every time in several places.
>>> 
>>> Is it possible to move the  methods used both in 
>>> AquaTruncatingTabbedPaneLayout and AquaTruncatingTabbedScrollPaneLayout  to 
>>> TabbedPaneLayout with different names and then reused?
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 17/03/16 17:17, Avik Niyogi wrote:
&g

Re: Review request for 8015748: JProgressbar with Aqua LaF ignores JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) call

[Avik Niyogi]

Hi Sergey,
https://bugs.openjdk.java.net/browse/JDK-8151282 
<https://bugs.openjdk.java.net/browse/JDK-8151282> is open and in progress.
With Regards,
Avik Niyogi

> On 19-Mar-2016, at 4:52 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> I guess you need a separate CR for this, because JDK-8015748 was closed 
> already.
> 
> On 21.01.16 6:49, Avik Niyogi wrote:
>> Hi All,
>> Please review my code change with inputs received:
>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.08/ 
>> <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.08/>
>> With Regards,
>> Avik Niyogi
>> 
>>> On 21-Jan-2016, at 8:30 am, Avik Niyogi <avik.niy...@oracle.com 
>>> <mailto:avik.niy...@oracle.com>
>>> <mailto:avik.niy...@oracle.com <mailto:avik.niy...@oracle.com>>> wrote:
>>> 
>>> Hi Sergey,
>>> The JTreg will pass, but the errors are posted to the log and not as
>>> an interrupt as it would prematurely terminate execution of entire
>>> test case for other look and feels if done so.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 21-Jan-2016, at 8:26 am, Avik Niyogi <avik.niy...@oracle.com 
>>>> <mailto:avik.niy...@oracle.com>
>>>> <mailto:avik.niy...@oracle.com <mailto:avik.niy...@oracle.com>>> wrote:
>>>> 
>>>> Hi Sergey,
>>>> This is the *log* of the test *JProgressBarOrientationRobotTest.java*
>>>> after doing a *make java.desktop* after commenting out my code
>>>> changes in *AquaProgressBarUI.java* :
>>>> 
>>>> run:
>>>> [Metal]: LTR orientation test passed
>>>> [Metal]: RTL orientation test passed
>>>> [Nimbus]: LTR orientation test passed
>>>> [Nimbus]: RTL orientation test passed
>>>> [CDE/Motif]: LTR orientation test passed
>>>> [CDE/Motif]: RTL orientation test passed
>>>> [Mac OS X]: LTR orientation test passed
>>>> [Mac OS X]: [Error]: LTR orientation test failed
>>>> [Mac OS X]: [Error]: LTR orientation test failed
>>>> BUILD SUCCESSFUL (total time: 31 seconds)
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 20-Jan-2016, at 4:30 pm, Alexander Scherbatiy
>>>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>
>>>>> <mailto:alexandr.scherba...@oracle.com 
>>>>> <mailto:alexandr.scherba...@oracle.com>>> wrote:
>>>>> 
>>>>> 
>>>>> The fix looks good to me.
>>>>> 
>>>>> Thanks,
>>>>> Alexandr.
>>>>> 
>>>>> On 1/20/2016 12:47 PM, Rajeev Chamyal wrote:
>>>>>> 
>>>>>> Looks good to me.
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Rajeev Chamyal
>>>>>> 
>>>>>> *From:*Avik Niyogi
>>>>>> *Sent:* 20 January 2016 12:23
>>>>>> *To:* Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov
>>>>>> *Cc:* swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net> 
>>>>>> <mailto:swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net>>
>>>>>> *Subject:* Re:  Review request for 8015748: JProgressbar
>>>>>> with Aqua LaF ignores
>>>>>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>>>>> call
>>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> Please review the code changes made as with inputs for the webrev:
>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/ 
>>>>>> <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/>
>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/ 
>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/>>
>>>>>> 
>>>>>> With Regards,
>>>>>> 
>>>>>> Avik Niyogi
>>>>>> 
>>>>>>   On 20-Jan-2016, at 10:40 am, Rajeev Chamyal
>>>>>>   <rajeev.cham...@oracle.com <mailto:rajeev.cham...@oracle.com> 
>>>>>> <mailto:rajeev.cham...@oracle.com <mailto:rajeev.cham...@oracle.com>>
>>>>>> <mailto:rajeev.cham...@oracle.com <mailto:rajeev.cham...

Re: Review Request of 8148555: [macosx] An uncaught exception was raised entering Emoji into JTextArea

[Avik Niyogi]

Hi Sergey,
I have tested the test cases as mentioned.
1) They are not related to the current fix
2) ScreenMenuBarInputTwice.java issue is not reproducible.
3) There is a test bug in ActionListenerCalledTwiceTest.java, hence a new test 
case called ScreenMenuBarInputTwice.java 
was created to encompass actual expectations from Java on OS X as per native 
behaviour.

Please review my current fix as available in the mail trail. Thank you in 
advance.

With Regards,
Avik Niyogi


> On 14-Mar-2016, at 6:48 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> Hi, Avik.
> Can you please take a look to these two tests before fixing this bug:
> 
> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java
> --
> TEST: 
> javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
> 
> I remember they passed on jdk8, but it seems we have a regression in jdk9 and 
> both of them fail.
> 
> On 14.03.16 8:05, Avik Niyogi wrote:
>> Hi All,
>> A gentle reminder, please review my code changes.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niy...@oracle.com 
>>> <mailto:avik.niy...@oracle.com>
>>> <mailto:avik.niy...@oracle.com <mailto:avik.niy...@oracle.com>>> wrote:
>>> 
>>> Hi All,
>>> 
>>> Kindly review the bug fix for JDK 9.
>>> 
>>> *Bug:*
>>> 
>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_ 
>>> <https://bugs.openjdk.java.net/browse/JDK-8148555_>
>>> _
>>> _
>>> *Webrev:*
>>> 
>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_
>>> 
>>> *Issue:*
>>> Emoji selection in Character Viewer was causing exception in JNI
>>> 
>>> *Cause:*
>>> Emojis are considered to be of different class type (namely,
>>> NSConcreteMutableAttributedString) from NSString which other
>>> characters are because of a surrogate pair for them.
>>> 
>>> *Fix:*
>>> Major changes done for condition of emojis in JNI. Albeit rendering is
>>> not yet supported, they will appear as blank “Missing font” notation.
>>> Also, added debug point in case of issue with glyph arrises.
>>> 
>>> With Regards,
>>> Avik Niyogi
>> 
> 
> 
> -- 
> Best regards, Sergey.

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

[Avik Niyogi]

Hi Alexander,
The issue only applies for ScrollingTabbedPane and hence this fix.

With Regards,
Avik Niyogi

> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> 
> Does the same issue affects the AquaTabbedPaneContrastUI?
> 
> Thanks,
> Alexandr.
> 
> On 14/03/16 09:04, Avik Niyogi wrote:
>> Hi All,
>> A gentle reminder, please review code changes.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi < 
>>> <mailto:avik.niy...@oracle.com>avik.niy...@oracle.com 
>>> <mailto:avik.niy...@oracle.com>> wrote:
>>> 
>>> Hi All,
>>> 
>>> Please review code changes done as with inputs provided.
>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.01/>
>>> 
>>> Also, albeit the title of issue mentioned is as above, the injection of 
>>> issue occurs because  
>>> pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.
>>> In the new fix as provided, references to base class layout manager is 
>>> removed in current solution.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin < 
>>>> <mailto:alexander.potoch...@oracle.com>alexander.potoch...@oracle.com 
>>>> <mailto:alexander.potoch...@oracle.com>> wrote:
>>>> 
>>>> Hello Avik
>>>> 
>>>> Let me make it clear I don't approve the proposed fix
>>>> and ask you to do additional evaluation.
>>>> 
>>>> Every LookAndFeel is different and it doesn't make much sense
>>>> to compare Metal LaF with AquaLaf.
>>>> 
>>>> The AquaLaf mimics the native MacOS controls and therefore look quite 
>>>> different from any other Lafs.
>>>> 
>>>> The bug you are fixing has the following subject 
>>>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>>>> 
>>>> Could you please fix exactly the problem with the minimal heights,
>>>> without changing the UI delegate class.
>>>> 
>>>> Thanks
>>>> alexp
>>>> 
>>>>> Gentle reminder. Please review this fix.
>>>>> 
>>>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi < 
>>>>>> <mailto:avik.niy...@oracle.com>avik.niy...@oracle.com 
>>>>>> <mailto:avik.niy...@oracle.com>> wrote:
>>>>>> 
>>>>>> The issue is with setting of TabbedPaneScrollLayout() for the option 
>>>>>> JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>>>>>  and not TabbedPaneLayout() as which is the default.
>>>>>> 
>>>>>> The minimum size fixes itself because the ScrollLayout check fails in 
>>>>>> setTabLayoutPolicy() for the pane. So the issue is with the call to set 
>>>>>> layout manager.
>>>>>> There are only two configurations that the JTabbedPane can exist in of 
>>>>>> which SCROLL_TAB_LAYOUT is one of them.
>>>>>> 
>>>>>> Fixing the minimum size in AquaTabbedPaneUI will fix it for 
>>>>>> TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
>>>>>> 
>>>>>> Also, I have checked other implementations such as for Metal and Motif 
>>>>>> and they have similar code for doing this process.
>>>>>> Hence, with in-depth analysis, this fix has no other impact apart from 
>>>>>> this fix.
>>>>>> 
>>>>>> In case the impact caused by this change has caused some definitive 
>>>>>> regressions, please mention them so they can be addressed. Thank you.
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>> 
>>>>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin < 
>>>>>>> <mailto:alexander.potoch...@oracle.com>alexander.potoch...@oracle.com 
>>>>>>> <mailto:alexander.potoch...@oracle.com>> wrote:
>>>>>>> 
>>>>>>> Hello Avik
>>>>>>> 
>>>>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for 
>>>>>>> the AquaTabbedPaneUI.
>>>>>>> I don't think setting the layout manager from the base class is the 
>>>>>>> right solution here.
>>>>>>> 
>>>>>>> If there is a problem with minimum size it should be fixed inside the 
>>>>>>> AquaTabbedPaneUI
>>>>>>> 
>>>>>>> Thanks
>>>>>>> alexp
>>>>>>> 
>>>>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>> 
>>>>>>>> Bug:
>>>>>>>>  
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8137169>https://bugs.openjdk.java.net/browse/JDK-8137169
>>>>>>>>  <https://bugs.openjdk.java.net/browse/JDK-8137169>
>>>>>>>> 
>>>>>>>> Webrev:
>>>>>>>> 
>>>>>>>>  
>>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/
>>>>>>>>  <http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/>
>>>>>>>> 
>>>>>>>> Issue:
>>>>>>>> For Aqua Look, multiple calls to pane.getMinimumSize().height 
>>>>>>>> causes incremental return of values.
>>>>>>>> 
>>>>>>>> Cause:
>>>>>>>> The impact was caused by a major broken code within 
>>>>>>>> AquaTabbedPaneUI.java for createLayoutManager()
>>>>>>>> 
>>>>>>>> Fix:
>>>>>>>> Major linking calls to super class fix done within 
>>>>>>>> createLayoutManager().
>>>>>>>> 
>>>>>>>> With Regards,
>>>>>>>> Avik Niyogi
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: Review Request of 8148555: [macosx] An uncaught exception was raised entering Emoji into JTextArea

[Avik Niyogi]

It can be made into a class method, but herein this case it is needed for that 
instance only and hence the need for instance method and referred with “self”.

With Regards,
Avik Niyogi
> On 16-Mar-2016, at 11:55 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> 
> Could the -(NSMutableString *) parseString: method be declared as class 
> method instead of instance?
> 
> Thanks,
> Alexandr.
> 
> On 14/03/16 17:18, Sergey Bylokhov wrote:
>> Hi, Avik. 
>> Can you please take a look to these two tests before fixing this bug: 
>> 
>> TEST: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java 
>> -- 
>> TEST: 
>> javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
>> 
>> I remember they passed on jdk8, but it seems we have a regression in jdk9 
>> and both of them fail. 
>> 
>> On 14.03.16 8:05, Avik Niyogi wrote: 
>>> Hi All, 
>>> A gentle reminder, please review my code changes. 
>>> 
>>> With Regards, 
>>> Avik Niyogi 
>>>> On 08-Mar-2016, at 9:39 pm, Avik Niyogi <avik.niy...@oracle.com 
>>>> <mailto:avik.niy...@oracle.com> 
>>>> <mailto:avik.niy...@oracle.com> <mailto:avik.niy...@oracle.com>> wrote: 
>>>> 
>>>> Hi All, 
>>>> 
>>>> Kindly review the bug fix for JDK 9. 
>>>> 
>>>> *Bug:* 
>>>> 
>>>> _https://bugs.openjdk.java.net/browse/JDK-8148555_ 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8148555_> 
>>>> _ 
>>>> _ 
>>>> *Webrev:* 
>>>> 
>>>> _http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_ 
>>>> <http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/_> 
>>>> 
>>>> *Issue:* 
>>>> Emoji selection in Character Viewer was causing exception in JNI 
>>>> 
>>>> *Cause:* 
>>>> Emojis are considered to be of different class type (namely, 
>>>> NSConcreteMutableAttributedString) from NSString which other 
>>>> characters are because of a surrogate pair for them. 
>>>> 
>>>> *Fix:* 
>>>> Major changes done for condition of emojis in JNI. Albeit rendering is 
>>>> not yet supported, they will appear as blank “Missing font” notation. 
>>>> Also, added debug point in case of issue with glyph arrises. 
>>>> 
>>>> With Regards, 
>>>> Avik Niyogi 
>>> 
>> 
>> 
> 

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

[Avik Niyogi]

Hi Alexander,
Thank you for the inputs. I agree with you and did feel the need for removing 
duplicate code as well. But as per an earlier review input, changes to the 
super call lay outing is not accepted. This was the only other feasible 
solution. Created redundant code in this process, but would be maintaining with 
requirements with code impact to superclasses.
Please provide any insight to a probable compensate to mitigate this dichotomy 
of code expectation. Thank you in advance.

With Regards,
Avik Niyogi
> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> 
> It is not usually a good idea to have a duplicated code which should be 
> updated every time in several places.
> 
> Is it possible to move the  methods used both in 
> AquaTruncatingTabbedPaneLayout and AquaTruncatingTabbedScrollPaneLayout  to 
> TabbedPaneLayout with different names and then reused?
> 
> Thanks,
> Alexandr.
> 
> On 17/03/16 17:17, Avik Niyogi wrote:
>> Hi Alexander,
>> The issue only applies for ScrollingTabbedPane and hence this fix.
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> 
>>> Does the same issue affects the AquaTabbedPaneContrastUI?
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 14/03/16 09:04, Avik Niyogi wrote:
>>>> Hi All,
>>>> A gentle reminder, please review code changes.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 08-Mar-2016, at 9:51 pm, Avik Niyogi <avik.niy...@oracle.com 
>>>>> <mailto:avik.niy...@oracle.com>> wrote:
>>>>> 
>>>>> Hi All,
>>>>> 
>>>>> Please review code changes done as with inputs provided.
>>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.01/>
>>>>> 
>>>>> Also, albeit the title of issue mentioned is as above, the injection of 
>>>>> issue occurs because  
>>>>> pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not honoured.
>>>>> In the new fix as provided, references to base class layout manager is 
>>>>> removed in current solution.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>> 
>>>>>> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin < 
>>>>>> <mailto:alexander.potoch...@oracle.com>alexander.potoch...@oracle.com 
>>>>>> <mailto:alexander.potoch...@oracle.com>> wrote:
>>>>>> 
>>>>>> Hello Avik
>>>>>> 
>>>>>> Let me make it clear I don't approve the proposed fix
>>>>>> and ask you to do additional evaluation.
>>>>>> 
>>>>>> Every LookAndFeel is different and it doesn't make much sense
>>>>>> to compare Metal LaF with AquaLaf.
>>>>>> 
>>>>>> The AquaLaf mimics the native MacOS controls and therefore look quite 
>>>>>> different from any other Lafs.
>>>>>> 
>>>>>> The bug you are fixing has the following subject 
>>>>>> "Incorrect minimal heigh of JTabbedPane with more tabs"
>>>>>> 
>>>>>> Could you please fix exactly the problem with the minimal heights,
>>>>>> without changing the UI delegate class.
>>>>>> 
>>>>>> Thanks
>>>>>> alexp
>>>>>> 
>>>>>>> Gentle reminder. Please review this fix.
>>>>>>> 
>>>>>>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi < 
>>>>>>>> <mailto:avik.niy...@oracle.com>avik.niy...@oracle.com 
>>>>>>>> <mailto:avik.niy...@oracle.com>> wrote:
>>>>>>>> 
>>>>>>>> The issue is with setting of TabbedPaneScrollLayout() for the option 
>>>>>>>> JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>>>>>>>  and not TabbedPaneLayout() as which is the default.
>>>>>>>> 
>>>>>>>> The minimum size fixes itself because the ScrollLayout check fails in 
>>>>>>>> setTabLayoutPolicy() for the pane. So the issue is with 

Re: Review Request of 8151282: [TEST_BUG] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails with GTK LnF

[Avik Niyogi]

Hi All,
Please review code changes made as per inputs provided.

http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/ 
<http://cr.openjdk.java.net/~aniyogi/8151282/webrev.01/>
With Regards,
Avik Niyogi
> On 14-Mar-2016, at 10:53 am, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> Hi Sergey,
> Seems like it is a delay issue. Will submit test case with a waitForIdle() 
> fix.
> 
> With Regards,
> Avik Niyogi
>> On 10-Mar-2016, at 7:22 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
>> wrote:
>> 
>> Hi, Avik.
>> A few questions.
>> - Why webrev contains the new file?
>> - You marked the test as a mac specific but it is iterates over a bunch of 
>> l It seems it should not be OS specific, but should check some specific 
>> l (which support such icons): Metal, Nimbus, Aqua, Windows(???). So 
>> gtk/motif should be skipped.
>> 
>> On 08.03.16 8:10, Avik Niyogi wrote:
>>> Hi All,
>>> 
>>> Kindly review the bug fix for JDK 9.
>>> 
>>> *Bug:*
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8151282
>>> 
>>> *Webrev:*
>>> 
>>> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_
>>> _
>>> _
>>> *Issue:*
>>> The test case failed for GTK LAF.
>>> 
>>> *Cause:*
>>> The test case was meant to be Mac specific and was missing a jtreg parameter
>>> 
>>> *Fix:*
>>> Minor change to test case with @requires tag added to set the fix.
>>> 
>>> With Regards,
>>> Avik Niyogi
>> 
>> 
>> -- 
>> Best regards, Sergey.
> 

Re: Review Request of 8151282: [TEST_BUG] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails with GTK LnF

[Avik Niyogi]

Hi Sergey,
Seems like it is a delay issue. Will submit test case with a waitForIdle() fix.

With Regards,
Avik Niyogi
> On 10-Mar-2016, at 7:22 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> Hi, Avik.
> A few questions.
> - Why webrev contains the new file?
> - You marked the test as a mac specific but it is iterates over a bunch of 
> l It seems it should not be OS specific, but should check some specific 
> l (which support such icons): Metal, Nimbus, Aqua, Windows(???). So 
> gtk/motif should be skipped.
> 
> On 08.03.16 8:10, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the bug fix for JDK 9.
>> 
>> *Bug:*
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8151282
>> 
>> *Webrev:*
>> 
>> _http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/_
>> _
>> _
>> *Issue:*
>> The test case failed for GTK LAF.
>> 
>> *Cause:*
>> The test case was meant to be Mac specific and was missing a jtreg parameter
>> 
>> *Fix:*
>> Minor change to test case with @requires tag added to set the fix.
>> 
>> With Regards,
>> Avik Niyogi
> 
> 
> -- 
> Best regards, Sergey.

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

[Avik Niyogi]

Hi All,

Please review code changes done as with inputs provided.
http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/ 
<http://cr.openjdk.java.net/~aniyogi/8137169/webrev.01/>

Also, albeit the title of issue mentioned is as above, the injection of issue 
occurs because  pane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT); is not 
honoured.
In the new fix as provided, references to base class layout manager is removed 
in current solution.

With Regards,
Avik Niyogi

> On 02-Mar-2016, at 7:50 pm, Alexander Potochkin 
> <alexander.potoch...@oracle.com> wrote:
> 
> Hello Avik
> 
> Let me make it clear I don't approve the proposed fix
> and ask you to do additional evaluation.
> 
> Every LookAndFeel is different and it doesn't make much sense
> to compare Metal LaF with AquaLaf.
> 
> The AquaLaf mimics the native MacOS controls and therefore look quite 
> different from any other Lafs.
> 
> The bug you are fixing has the following subject 
> "Incorrect minimal heigh of JTabbedPane with more tabs"
> 
> Could you please fix exactly the problem with the minimal heights,
> without changing the UI delegate class.
> 
> Thanks
> alexp
> 
>> Gentle reminder. Please review this fix.
>> 
>>> On 26-Feb-2016, at 10:39 am, Avik Niyogi < 
>>> <mailto:avik.niy...@oracle.com>avik.niy...@oracle.com 
>>> <mailto:avik.niy...@oracle.com>> wrote:
>>> 
>>> The issue is with setting of TabbedPaneScrollLayout() for the option 
>>> JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>>>  and not TabbedPaneLayout() as which is the default.
>>> 
>>> The minimum size fixes itself because the ScrollLayout check fails in 
>>> setTabLayoutPolicy() for the pane. So the issue is with the call to set 
>>> layout manager.
>>> There are only two configurations that the JTabbedPane can exist in of 
>>> which SCROLL_TAB_LAYOUT is one of them.
>>> 
>>> Fixing the minimum size in AquaTabbedPaneUI will fix it for 
>>> TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
>>> 
>>> Also, I have checked other implementations such as for Metal and Motif and 
>>> they have similar code for doing this process.
>>> Hence, with in-depth analysis, this fix has no other impact apart from this 
>>> fix.
>>> 
>>> In case the impact caused by this change has caused some definitive 
>>> regressions, please mention them so they can be addressed. Thank you.
>>> 
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin < 
>>>> <mailto:alexander.potoch...@oracle.com>alexander.potoch...@oracle.com 
>>>> <mailto:alexander.potoch...@oracle.com>> wrote:
>>>> 
>>>> Hello Avik
>>>> 
>>>> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the 
>>>> AquaTabbedPaneUI.
>>>> I don't think setting the layout manager from the base class is the right 
>>>> solution here.
>>>> 
>>>> If there is a problem with minimum size it should be fixed inside the 
>>>> AquaTabbedPaneUI
>>>> 
>>>> Thanks
>>>> alexp
>>>> 
>>>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> 
>>>>> Kindly review the bug fix for JDK 9.
>>>>> 
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8137169 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8137169>
>>>>> 
>>>>> Webrev:
>>>>> 
>>>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>
>>>>> 
>>>>> Issue:
>>>>> For Aqua Look, multiple calls to pane.getMinimumSize().height causes 
>>>>> incremental return of values.
>>>>> 
>>>>> Cause:
>>>>> The impact was caused by a major broken code within AquaTabbedPaneUI.java 
>>>>> for createLayoutManager()
>>>>> 
>>>>> Fix:
>>>>> Major linking calls to super class fix done within createLayoutManager().
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>> 
>>> 
>> 
> 

Review Request of 8148555: [macosx] An uncaught exception was raised entering Emoji into JTextArea

[Avik Niyogi]

Hi All,

Kindly review the bug fix for JDK 9.

Bug:

https://bugs.openjdk.java.net/browse/JDK-8148555 
<https://bugs.openjdk.java.net/browse/JDK-8148555>

Webrev:

http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8148555/webrev.00/>

Issue:
Emoji selection in Character Viewer was causing exception in JNI

Cause:
Emojis are considered to be of different class type (namely, 
NSConcreteMutableAttributedString) from NSString which other characters are 
because of a surrogate pair for them.

Fix:
Major changes done for condition of emojis in JNI. Albeit rendering is not yet 
supported, they will appear as blank “Missing font” notation.
Also, added debug point in case of issue with glyph arrises.

With Regards,
Avik Niyogi

Review Request of 8151282: [TEST_BUG] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails with GTK LnF

[Avik Niyogi]

Hi All,

Kindly review the bug fix for JDK 9.

Bug:

https://bugs.openjdk.java.net/browse/JDK-8151282 
<https://bugs.openjdk.java.net/browse/JDK-8151282>

Webrev:

http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8151282/webrev.00/>

Issue:
The test case failed for GTK LAF.

Cause:
The test case was meant to be Mac specific and was missing a jtreg parameter

Fix:
Minor change to test case with @requires tag added to set the fix.

With Regards,
Avik Niyogi

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

[Avik Niyogi]

Gentle reminder. Please review this fix.

> On 26-Feb-2016, at 10:39 am, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> The issue is with setting of TabbedPaneScrollLayout() for the option 
> JTabbedPane.SCROLL_TAB_LAYOUT as is enabled in the test code
>  and not TabbedPaneLayout() as which is the default.
> 
> The minimum size fixes itself because the ScrollLayout check fails in 
> setTabLayoutPolicy() for the pane. So the issue is with the call to set 
> layout manager.
> There are only two configurations that the JTabbedPane can exist in of which 
> SCROLL_TAB_LAYOUT is one of them.
> 
> Fixing the minimum size in AquaTabbedPaneUI will fix it for 
> TabbedPaneLayout() only which is the WRAP_TAB_LAYOUT.
> 
> Also, I have checked other implementations such as for Metal and Motif and 
> they have similar code for doing this process.
> Hence, with in-depth analysis, this fix has no other impact apart from this 
> fix.
> 
> In case the impact caused by this change has caused some definitive 
> regressions, please mention them so they can be addressed. Thank you.
> 
> With Regards,
> Avik Niyogi
> 
>> On 25-Feb-2016, at 6:45 pm, Alexander Potochkin 
>> <alexander.potoch...@oracle.com <mailto:alexander.potoch...@oracle.com>> 
>> wrote:
>> 
>> Hello Avik
>> 
>> AquaTruncatingTabbedPaneLayout has a lot of code which is specific for the 
>> AquaTabbedPaneUI.
>> I don't think setting the layout manager from the base class is the right 
>> solution here.
>> 
>> If there is a problem with minimum size it should be fixed inside the 
>> AquaTabbedPaneUI
>> 
>> Thanks
>> alexp
>> 
>> On 2/24/2016 12:07, Avik Niyogi wrote:
>>> Hi All,
>>> 
>>> Kindly review the bug fix for JDK 9.
>>> 
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8137169 
>>> <https://bugs.openjdk.java.net/browse/JDK-8137169>
>>> 
>>> Webrev:
>>> 
>>> http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8137169/webrev.00/>
>>> 
>>> Issue:
>>> For Aqua Look, multiple calls to pane.getMinimumSize().height causes 
>>> incremental return of values.
>>> 
>>> Cause:
>>> The impact was caused by a major broken code within AquaTabbedPaneUI.java 
>>> for createLayoutManager()
>>> 
>>> Fix:
>>> Major linking calls to super class fix done within createLayoutManager().
>>> 
>>> With Regards,
>>> Avik Niyogi
>> 
> 

Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

[Avik Niyogi]

Hi All,

Kindly review the bug fix for JDK 9.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8137169 
<https://bugs.openjdk.java.net/browse/JDK-8137169>

Webrev:

http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/>

Issue:
For Aqua Look, multiple calls to pane.getMinimumSize().height causes 
incremental return of values.

Cause:
The impact was caused by a major broken code within AquaTabbedPaneUI.java for 
createLayoutManager()

Fix:
Major linking calls to super class fix done within createLayoutManager().

With Regards,
Avik Niyogi

Review Request of 8137169 :

[Avik Niyogi]

Hi All,

Kindly review the bug fix for JDK 9.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8137169 
<https://bugs.openjdk.java.net/browse/JDK-8137169>

Webrev:

http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8137169/webrev.00/>

Issue:
For Aqua Look, multiple calls to pane.getMinimumSize().height causes 
incremental return of values.

Cause:
The impact was caused by a major broken code within AquaTabbedPaneUI.java for 
createLayoutManager()

Fix:
Major linking calls to super class fix done within createLayoutManager().

With Regards,
Avik Niyogi

Re: Review Request of 8146321: [macosx] JInternalFrame frame icon in wrong position on Mac L if icon is not ImageIcon

[Avik Niyogi]

A gentle reminder. Please review webrev with changes as per the inputs provided:
cr.openjdk.java.net/~aniyogi/8146321/webrev.06/ 
<http://cr.openjdk.java.net/~aniyogi/8146321/webrev.06/>

With Regards,
Avik Niyogi
> On 08-Feb-2016, at 12:42 pm, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> Hi Sergey,
> Please review webrev with changes as per the inputs provided:
> cr.openjdk.java.net/~aniyogi/8146321/webrev.06/ 
> <http://cr.openjdk.java.net/~aniyogi/8146321/webrev.06/>
> 
> With Regards,
> Avik Niyogi
> 
>> On 08-Feb-2016, at 2:29 am, Sergey Bylokhov <sergey.bylok...@oracle.com 
>> <mailto:sergey.bylok...@oracle.com>> wrote:
>> 
>> Both updated methods have a typo, 0 will be returned if 
>> frame.getFrameIcon()==null:
>> 
>>protected int getIconWidth(final JInternalFrame frame) {
>>int width = 0;
>> 
>>Icon icon = frame.getFrameIcon();
>>if (icon == null) {
>>icon = UIManager.getIcon("InternalFrame.icon");
>>}
>>else {
>>width = Math.min(icon.getIconWidth(), sMaxIconWidth);
>>}
>> 
>>return width;
>>}
>> 
>>protected int getIconHeight(final JInternalFrame frame) {
>>int height = 0;
>> 
>>Icon icon = frame.getFrameIcon();
>>if (icon == null) {
>>icon = UIManager.getIcon("InternalFrame.icon");
>>}
>>else{
>>height = Math.min(icon.getIconHeight(), sMaxIconHeight);
>>}
>> 
>>return height;
>>}
>> 
>> Note that getIconWidth/getIconHeight should return width/height of the icon, 
>> but this is not true anymore, because paintTitleIcon() now use the aspect 
>> ratio, which can produce the different Width/Height for the same icon.
>> 
>> 
>> On 04.02.16 12:26, Alexandr Scherbatiy wrote:
>>> 
>>>   The fix looks good to me.
>>> 
>>>   Thanks,
>>>   Alexandr.
>>> 
>>> On 2/3/2016 8:51 PM, Avik Niyogi wrote:
>>>> Hi All,
>>>> Please review the code changes made as per the inputs provided:
>>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.05/ 
>>>> <http://cr.openjdk.java.net/~aniyogi/8146321/webrev.05/>
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.05/ 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.05/>>
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 03-Feb-2016, at 7:38 pm, Alexandr Scherbatiy
>>>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>
>>>>> <mailto:alexandr.scherba...@oracle.com 
>>>>> <mailto:alexandr.scherba...@oracle.com>>> wrote:
>>>>> 
>>>>> On 2/3/2016 12:47 AM, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>> Please review the code changes made as per the inputs provided:
>>>>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.04 
>>>>>> <http://cr.openjdk.java.net/~aniyogi/8146321/webrev.04>
>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.04 
>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.04>>
>>>>>  326 g2.translate(0, 0);
>>>>>  The translation to the zero vector leaves the coordinate system the
>>>>> same.
>>>>> 
>>>>>  327 float xScaleFactor = (float) sMaxIconWidth /
>>>>> icon.getIconWidth();
>>>>>  It is better to use double values because the graphics transform
>>>>> methods use them.
>>>>> 
>>>>>  332 g2.scale(scaleFactorAspectRatio,
>>>>> scaleFactorAspectRatio);
>>>>>  333 g2.translate(x / scaleFactorAspectRatio, y /
>>>>> scaleFactorAspectRatio);
>>>>>  Is it possible to use the translation first and the scale the
>>>>> second? I this case where no need to re-scale translation coordinates.
>>>>> 
>>>>>  Thanks,
>>>>>  Alexandr.
>>>>> 
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>>> On 02-Feb-2016, at 5:55 pm, Alexandr Scherbatiy
>>>>>>> <<mailto:alexandr.scherba...@oracle.com 
>>>>>>> <mailto:alexandr.scherba...@oracl

Re: Review Request of 8146321: [macosx] JInternalFrame frame icon in wrong position on Mac L if icon is not ImageIcon

[Avik Niyogi]

Hi Sergey,
Please review webrev with changes as per the inputs provided:
cr.openjdk.java.net/~aniyogi/8146321/webrev.06/ 
<http://cr.openjdk.java.net/~aniyogi/8146321/webrev.06/>

With Regards,
Avik Niyogi

> On 08-Feb-2016, at 2:29 am, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> Both updated methods have a typo, 0 will be returned if 
> frame.getFrameIcon()==null:
> 
>protected int getIconWidth(final JInternalFrame frame) {
>int width = 0;
> 
>Icon icon = frame.getFrameIcon();
>if (icon == null) {
>icon = UIManager.getIcon("InternalFrame.icon");
>}
>else {
>width = Math.min(icon.getIconWidth(), sMaxIconWidth);
>}
> 
>return width;
>}
> 
>protected int getIconHeight(final JInternalFrame frame) {
>int height = 0;
> 
>Icon icon = frame.getFrameIcon();
>if (icon == null) {
>icon = UIManager.getIcon("InternalFrame.icon");
>}
>else{
>height = Math.min(icon.getIconHeight(), sMaxIconHeight);
>}
> 
>return height;
>}
> 
> Note that getIconWidth/getIconHeight should return width/height of the icon, 
> but this is not true anymore, because paintTitleIcon() now use the aspect 
> ratio, which can produce the different Width/Height for the same icon.
> 
> 
> On 04.02.16 12:26, Alexandr Scherbatiy wrote:
>> 
>>   The fix looks good to me.
>> 
>>   Thanks,
>>   Alexandr.
>> 
>> On 2/3/2016 8:51 PM, Avik Niyogi wrote:
>>> Hi All,
>>> Please review the code changes made as per the inputs provided:
>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.05/ 
>>> <http://cr.openjdk.java.net/~aniyogi/8146321/webrev.05/>
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.05/ 
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.05/>>
>>> 
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 03-Feb-2016, at 7:38 pm, Alexandr Scherbatiy
>>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>
>>>> <mailto:alexandr.scherba...@oracle.com 
>>>> <mailto:alexandr.scherba...@oracle.com>>> wrote:
>>>> 
>>>> On 2/3/2016 12:47 AM, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> Please review the code changes made as per the inputs provided:
>>>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.04 
>>>>> <http://cr.openjdk.java.net/~aniyogi/8146321/webrev.04>
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.04 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.04>>
>>>>  326 g2.translate(0, 0);
>>>>  The translation to the zero vector leaves the coordinate system the
>>>> same.
>>>> 
>>>>  327 float xScaleFactor = (float) sMaxIconWidth /
>>>> icon.getIconWidth();
>>>>  It is better to use double values because the graphics transform
>>>> methods use them.
>>>> 
>>>>  332 g2.scale(scaleFactorAspectRatio,
>>>> scaleFactorAspectRatio);
>>>>  333 g2.translate(x / scaleFactorAspectRatio, y /
>>>> scaleFactorAspectRatio);
>>>>  Is it possible to use the translation first and the scale the
>>>> second? I this case where no need to re-scale translation coordinates.
>>>> 
>>>>  Thanks,
>>>>  Alexandr.
>>>> 
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>> On 02-Feb-2016, at 5:55 pm, Alexandr Scherbatiy
>>>>>> <<mailto:alexandr.scherba...@oracle.com 
>>>>>> <mailto:alexandr.scherba...@oracle.com>>alexandr.scherba...@oracle.com 
>>>>>> <mailto:alexandr.scherba...@oracle.com>>
>>>>>> wrote:
>>>>>> 
>>>>>> On 2/2/2016 3:41 AM, Avik Niyogi wrote:
>>>>>>> Hi Alexander,
>>>>>>> 
>>>>>>>> On 02-Feb-2016, at 3:44 pm, Alexandr Scherbatiy
>>>>>>>> <alexandr.scherba...@oracle.com 
>>>>>>>> <mailto:alexandr.scherba...@oracle.com>> wrote:
>>>>>>>> 
>>>>>>>> On 2/2/2016 1:50 AM, Avik Niyogi wrote:
>>>>>>>>> Hi All,
>>>>>>>>> Please r

Re: Review Request of 8146321: [macosx] JInternalFrame frame icon in wrong position on Mac L if icon is not ImageIcon

[Avik Niyogi]

Hi All,
Please review the code changes made as per the inputs provided:
http://cr.openjdk.java.net/~aniyogi/8146321/webrev.04 
<http://cr.openjdk.java.net/~aniyogi/8146321/webrev.04>

With Regards,
Avik Niyogi
> On 02-Feb-2016, at 5:55 pm, Alexandr Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> On 2/2/2016 3:41 AM, Avik Niyogi wrote:
>> Hi Alexander,
>> 
>>> On 02-Feb-2016, at 3:44 pm, Alexandr Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> On 2/2/2016 1:50 AM, Avik Niyogi wrote:
>>>> Hi All,
>>>> Please review the code changes made as per the inputs provided:
>>>> cr.openjdk.java.net/~aniyogi/8146321/webrev.03 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.03>
>>>  -  Will it work with custom implementation of the Icon interface which 
>>> just draws an image?
>>>   For example:
>>>  --
>>>  public class DukeIcon implements Icon {
>>> 
>>> private BufferedImage dukeImage;
>>> 
>>> public DukeIcon() throws IOException {
>>> dukeImage = ImageIO.read(new File(""));
>>> }
>>> 
>>> @Override
>>> public void paintIcon(Component c, Graphics g, int x, int y) {
>>> g.drawImage(dukeImage, x, y, c);
>>> }
>>> 
>>> @Override
>>> public int getIconWidth() {
>>> return dukeImage.getWidth();
>>> }
>>> 
>>> @Override
>>> public int getIconHeight() {
>>> return dukeImage.getHeight();
>>> }
>>> }
>> 
>> This is a limitation for custom Icons because they will need to use toe 
>> drawImage with appropriate implementation.
>> To fix that will be a major change and may need change in the implementation 
>> of drawImage method.
> 
>   It looks like the code below from the fix doesn't work for the ImageIcon 
> because x and y are now scaled. Is it possible to apply some other 
> transformations (may be some translations) to the graphics to draw the image 
> at the right position?
> ---
>  334 g2.scale((float) sMaxIconWidth / icon.getIconWidth(),
>  335 (float) sMaxIconWidth / icon.getIconHeight());
>  336 icon.paintIcon(frame, g2, x, y);
> ---
>>> --
>>> 
>>> - "(icon != null && (icon instanceof Icon))"
>>>   Could the check to null also be omitted here?
>>>   In other words, are the "(icon != null && (icon instanceof Icon))" and 
>>> "(icon instanceof Icon)" checks return the same result?
>>> 
>> If we remove the check, the cases where custom ImageIcon have no images will 
>> fail.
> 
> The provided example  should work with the check: "(icon instanceof 
> Icon)" in the same way as with the check "(icon != null && (icon instanceof 
> Icon))" because the used icon is not null and it implements Icon interface, 
> should not it?
> 
>  Thanks,
>  Alexandr.
> 
>> Example:
>> 
>> 
>> import java.awt.*;
>> import javax.swing.*;
>> 
>> public class JInternalFrameBug {
>> 
>>public static void main(String[] args) {
>>   SwingUtilities.invokeLater(
>> new Runnable() {
>>public void run() {
>>   try {
>>  
>> UIManager.setLookAndFeel("com.apple.laf.AquaLookAndFeel"); }
>>   catch(Exception e) {
>>  System.out.println("This is not a Mac.");
>>  return;
>>   }
>>   JFrame f = new JFrame();
>>   f.setSize(500, 500);
>>   JDesktopPane dtp = new JDesktopPane();
>>   JInternalFrame jif = new JInternalFrame();
>>   jif.setTitle("Test");
>>   jif.setFrameIcon(
>> new ImageIcon() {
>>public int getIconWidth() {
>>   return 16;
>>}
>>    public int getIconHeight() {
>>   return 16;
>>}
>>public void paintIcon(Component c, Graphics g, 
>> int x, int y) {
>&

Re: Review Request of 8146321: [macosx] JInternalFrame frame icon in wrong position on Mac L if icon is not ImageIcon

[Avik Niyogi]

Hi All,
Please review the code changes made as per the inputs provided:
http://cr.openjdk.java.net/~aniyogi/8146321/webrev.05/ 
<http://cr.openjdk.java.net/~aniyogi/8146321/webrev.05/>

With Regards,
Avik Niyogi

> On 03-Feb-2016, at 7:38 pm, Alexandr Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> On 2/3/2016 12:47 AM, Avik Niyogi wrote:
>> Hi All,
>> Please review the code changes made as per the inputs provided:
>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.04 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.04>  326 
>> g2.translate(0, 0);
>   The translation to the zero vector leaves the coordinate system the same.
> 
>   327 float xScaleFactor = (float) sMaxIconWidth / 
> icon.getIconWidth();
>   It is better to use double values because the graphics transform methods 
> use them.
> 
>   332 g2.scale(scaleFactorAspectRatio, scaleFactorAspectRatio);
>   333 g2.translate(x / scaleFactorAspectRatio, y / 
> scaleFactorAspectRatio);
>   Is it possible to use the translation first and the scale the second? I 
> this case where no need to re-scale translation coordinates.
> 
>   Thanks,
>   Alexandr.
> 
>> 
>> With Regards,
>> Avik Niyogi
>>> On 02-Feb-2016, at 5:55 pm, Alexandr Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> On 2/2/2016 3:41 AM, Avik Niyogi wrote:
>>>> Hi Alexander,
>>>> 
>>>>> On 02-Feb-2016, at 3:44 pm, Alexandr Scherbatiy < 
>>>>> <mailto:alexandr.scherba...@oracle.com>alexandr.scherba...@oracle.com 
>>>>> <mailto:alexandr.scherba...@oracle.com>> wrote:
>>>>> 
>>>>> On 2/2/2016 1:50 AM, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>> Please review the code changes made as per the inputs provided:
>>>>>> cr.openjdk.java.net/~aniyogi/8146321/webrev.03 
>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.03>
>>>>>  -  Will it work with custom implementation of the Icon interface which 
>>>>> just draws an image?
>>>>>   For example:
>>>>>  --
>>>>>  public class DukeIcon implements Icon {
>>>>> 
>>>>> private BufferedImage dukeImage;
>>>>> 
>>>>> public DukeIcon() throws IOException {
>>>>> dukeImage = ImageIO.read(new File(""));
>>>>> }
>>>>> 
>>>>> @Override
>>>>> public void paintIcon(Component c, Graphics g, int x, int y) {
>>>>> g.drawImage(dukeImage, x, y, c);
>>>>> }
>>>>> 
>>>>> @Override
>>>>> public int getIconWidth() {
>>>>> return dukeImage.getWidth();
>>>>> }
>>>>> 
>>>>> @Override
>>>>> public int getIconHeight() {
>>>>> return dukeImage.getHeight();
>>>>> }
>>>>> }
>>>> 
>>>> This is a limitation for custom Icons because they will need to use toe 
>>>> drawImage with appropriate implementation.
>>>> To fix that will be a major change and may need change in the 
>>>> implementation of drawImage method.
>>> 
>>>   It looks like the code below from the fix doesn't work for the ImageIcon 
>>> because x and y are now scaled. Is it possible to apply some other 
>>> transformations (may be some translations) to the graphics to draw the 
>>> image at the right position?
>>> ---
>>>  334 g2.scale((float) sMaxIconWidth / icon.getIconWidth(),
>>>  335 (float) sMaxIconWidth / icon.getIconHeight());
>>>  336 icon.paintIcon(frame, g2, x, y);
>>> ---
>>>>> --
>>>>> 
>>>>> - "(icon != null && (icon instanceof Icon))"
>>>>>   Could the check to null also be omitted here?
>>>>>   In other words, are the "(icon != null && (icon instanceof Icon))" and 
>>>>> "(icon instanceof Icon)" checks return the same result?
>>>>> 
>>>> If we remove the check, the cases where custom ImageIcon have no images 
>>>> will fail.
>>> 
>>>

Re: Review Request of 8146321: [macosx] JInternalFrame frame icon in wrong position on Mac L if icon is not ImageIcon

[Avik Niyogi]

Hi Alexander,

> On 02-Feb-2016, at 3:44 pm, Alexandr Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> On 2/2/2016 1:50 AM, Avik Niyogi wrote:
>> Hi All,
>> Please review the code changes made as per the inputs provided:
>> cr.openjdk.java.net/~aniyogi/8146321/webrev.03 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.03>
>  -  Will it work with custom implementation of the Icon interface which just 
> draws an image?
>   For example:
>  --
>  public class DukeIcon implements Icon {
> 
> private BufferedImage dukeImage;
> 
> public DukeIcon() throws IOException {
> dukeImage = ImageIO.read(new File(""));
> }
> 
> @Override
> public void paintIcon(Component c, Graphics g, int x, int y) {
> g.drawImage(dukeImage, x, y, c);
> }
> 
> @Override
> public int getIconWidth() {
> return dukeImage.getWidth();
> }
> 
> @Override
> public int getIconHeight() {
> return dukeImage.getHeight();
> }
> }

This is a limitation for custom Icons because they will need to use toe 
drawImage with appropriate implementation.
To fix that will be a major change and may need change in the implementation of 
drawImage method.
> --
> 
> - "(icon != null && (icon instanceof Icon))"
>   Could the check to null also be omitted here?
>   In other words, are the "(icon != null && (icon instanceof Icon))" and 
> "(icon instanceof Icon)" checks return the same result?
> 
If we remove the check, the cases where custom ImageIcon have no images will 
fail.
Example:


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

public class JInternalFrameBug {

   public static void main(String[] args) {
  SwingUtilities.invokeLater(
new Runnable() {
   public void run() {
  try {
 UIManager.setLookAndFeel("com.apple.laf.AquaLookAndFeel"); 
}
  catch(Exception e) {
 System.out.println("This is not a Mac.");
 return;
  }
  JFrame f = new JFrame();
  f.setSize(500, 500);
  JDesktopPane dtp = new JDesktopPane();
  JInternalFrame jif = new JInternalFrame();
  jif.setTitle("Test");
  jif.setFrameIcon(
new ImageIcon() {
   public int getIconWidth() {
  return 16;
   }
   public int getIconHeight() {
  return 16;
   }
   public void paintIcon(Component c, Graphics g, int 
x, int y) {
  g.setColor(java.awt.Color.green);
  g.fillRect(x, y, 16, 16);
   }
});
  jif.setSize(400, 400);
  jif.setVisible(true);
  dtp.add(jif);

  f.getContentPane().setLayout(new BorderLayout());
  f.getContentPane().add(dtp, "Center");
  f.setVisible(true);
   }
});
   }
}

>   Thanks,
>   Alexandr.
> 
>> 
>> With Regards,
>> Avik Niyogi
>>> On 02-Feb-2016, at 3:02 pm, Alexandr Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> On 2/1/2016 11:25 PM, Avik Niyogi wrote:
>>>> Hi All,
>>>> Please review the code changes made as per inputs provided:
>>>> cr.openjdk.java.net/~aniyogi/8146321/webrev.02 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.02>
>>>    - is it possible to skip the ImageIcon parsing and handle it as others 
>>> icons (may be applying some translation to the graphics)?
>>>-   "(icon instanceof ImageIcon || icon instanceof Icon):
>>>  ImageIcons is also Icon so the whole condition should be the same as 
>>> just (icon instanceof Icon)
>>> 
>>>   Thanks,
>>>   Alexandr.
>>> 
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 20-Jan-2016, at 10:35 pm, Sergey Bylokhov <sergey.bylok...@oracle.com 
>>>>> <mailto:sergey.bylok...@oracle.com>> wrote:
>>>>> 
>>>>> On 20/01/16 18:43, Avik Niyogi wrote:
>>>>>> if ((icon.getIconWidth() > sMaxIconWidth
>>>>>> || icon.getIconHeight() > sMaxIconHeight

Re: Review Request of 8146321: [macosx] JInternalFrame frame icon in wrong position on Mac L if icon is not ImageIcon

[Avik Niyogi]

Hi All,
Please review the code changes made as per inputs provided:
cr.openjdk.java.net/~aniyogi/8146321/webrev.02 
<http://cr.openjdk.java.net/~aniyogi/8146321/webrev.02>

With Regards,
Avik Niyogi
> On 20-Jan-2016, at 10:35 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> On 20/01/16 18:43, Avik Niyogi wrote:
>> if ((icon.getIconWidth() > sMaxIconWidth
>> || icon.getIconHeight() > sMaxIconHeight)) {
>> final Graphics2D g2 = (Graphics2D) g;
>> final AffineTransform savedAT = g2.getTransform();
>> g2.scale((float)sMaxIconWidth/icon.getIconWidth(),
>> (float)sMaxIconWidth/icon.getIconHeight());
>> icon.paintIcon(frame, g2, x, y);
>> g2.setTransform(savedAT);
>> }
> 
> This code does not take into account that x,y whcih are passed to the 
> paintIcon should be adjusted, because after the scale they contain incorrect 
> starting points.
> 
>> 
>> then for a test code with the following:
>> 
>> import java.awt.*;
>> import javax.swing.*;
>> 
>> public class JInternalFrameBug {
>> 
>>public static void main(String[] args) {
>>   SwingUtilities.invokeLater(
>> new Runnable() {
>>public void run() {
>>   try {
>> 
>>  UIManager.setLookAndFeel("com.apple.laf.AquaLookAndFeel"); }
>>   catch(Exception e) {
>>  System.out.println("This is not a Mac.");
>>  return;
>>   }
>>   JFrame f = new JFrame();
>>   f.setSize(400, 400);
>>   JDesktopPane dtp = new JDesktopPane();
>>   JInternalFrame jif = new JInternalFrame();
>>   jif.setTitle("Test");
>>   jif.setFrameIcon(new
>> ImageIcon("/Users/avniyogi/Downloads/FeedbinNotifier-master/FeedbinNotifier/Images.xcassets/AppIcon.appiconset/icon_128x...@2x.png"));
>>   jif.setSize(200, 200);
>>   jif.setVisible(true);
>>   dtp.add(jif);
>> 
>>   f.getContentPane().setLayout(new BorderLayout());
>>   f.getContentPane().add(dtp, "Center");
>>   f.setVisible(true);
>>}
>> });
>>}
>> }
>> 
>> results in this:
>> 
>> 
>> 
>>> On 20-Jan-2016, at 4:42 pm, Alexander Scherbatiy
>>> <alexandr.scherba...@oracle.com
>>> <mailto:alexandr.scherba...@oracle.com>> wrote:
>>> 
>>> On 1/20/2016 7:59 AM, Avik Niyogi wrote:
>>>> Hi All,
>>>> A gentle reminder, please review my code changes as in the webrev
>>>> below in the mail trail.
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 18-Jan-2016, at 3:01 pm, Avik Niyogi <avik.niy...@oracle.com
>>>>> <mailto:avik.niy...@oracle.com> <mailto:avik.niy...@oracle.com>> wrote:
>>>>> 
>>>>> Hi Sergey,
>>>>> 
>>>>> Please review the webrev taking inputs as per the discussion before:
>>>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.01/
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8146321/webrev.01/>
>>> 
>>>   The idea was to scale the graphics that the drawn icon fits to the
>>> target sizes.
>>>   Something like:
>>>  
>>>  g2d.scale(targetIconWidth/icon.getWidth(),
>>> targetIconHeight/icon.getHeight());
>>>  icon.paintIcon(frame, g2d, x, y);
>>> -
>>> 
>>>  This should work not only for ImageIcon but for any type of icons.
>>> 
>>>  Thanks,
>>>  Alexandr.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>> 
>>>>>> On 14-Jan-2016, at 12:55 pm, Avik Niyogi <avik.niy...@oracle.com
>>>>>> <mailto:avik.niy...@oracle.com> <mailto:avik.niy...@oracle.com>> wrote:
>>>>>> 
>>>>>> Hi Sergey,
>>>>>> I have verified it with the test case as well. If a test case
>>>>>> overrides these methods to imply a change with icons larger than
>>>>>> 16x16 it will show that for ImageIcon and Icon as before. The
>>>>>> resize of ImageIcon is only in case it has an image file that it
>>&

Re: Review request for 8015748: JProgressbar with Aqua LaF ignores JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) call

[Avik Niyogi]

Hi All,
Please review my code change with inputs received: 
http://cr.openjdk.java.net/~aniyogi/8015748/webrev.08/ 
<http://cr.openjdk.java.net/~aniyogi/8015748/webrev.08/>
With Regards,
Avik Niyogi

> On 21-Jan-2016, at 8:30 am, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> Hi Sergey,
> The JTreg will pass, but the errors are posted to the log and not as an 
> interrupt as it would prematurely terminate execution of entire test case for 
> other look and feels if done so.
> 
> With Regards,
> Avik Niyogi
> 
>> On 21-Jan-2016, at 8:26 am, Avik Niyogi <avik.niy...@oracle.com 
>> <mailto:avik.niy...@oracle.com>> wrote:
>> 
>> Hi Sergey,
>> This is the log of the test JProgressBarOrientationRobotTest.java after 
>> doing a make java.desktop after commenting out my code changes in 
>> AquaProgressBarUI.java :
>> 
>> run:
>> [Metal]: LTR orientation test passed
>> [Metal]: RTL orientation test passed
>> [Nimbus]: LTR orientation test passed
>> [Nimbus]: RTL orientation test passed
>> [CDE/Motif]: LTR orientation test passed
>> [CDE/Motif]: RTL orientation test passed
>> [Mac OS X]: LTR orientation test passed
>> [Mac OS X]: [Error]: LTR orientation test failed
>> [Mac OS X]: [Error]: LTR orientation test failed
>> BUILD SUCCESSFUL (total time: 31 seconds)
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 20-Jan-2016, at 4:30 pm, Alexander Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> 
>>>  The fix looks good to me.
>>> 
>>>  Thanks,
>>>  Alexandr.
>>> 
>>> On 1/20/2016 12:47 PM, Rajeev Chamyal wrote:
>>>> 
>>>> Looks good to me.
>>>> 
>>>> Regards,
>>>> 
>>>> Rajeev Chamyal
>>>> 
>>>> *From:*Avik Niyogi
>>>> *Sent:* 20 January 2016 12:23
>>>> *To:* Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov
>>>> *Cc:* swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net>
>>>> *Subject:* Re:  Review request for 8015748: JProgressbar with 
>>>> Aqua LaF ignores 
>>>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) 
>>>> call
>>>> 
>>>> Hi All,
>>>> 
>>>> Please review the code changes made as with inputs for the webrev: 
>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/ 
>>>> <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/> 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/ 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/>>
>>>> 
>>>> With Regards,
>>>> 
>>>> Avik Niyogi
>>>> 
>>>>On 20-Jan-2016, at 10:40 am, Rajeev Chamyal
>>>><rajeev.cham...@oracle.com <mailto:rajeev.cham...@oracle.com> 
>>>> <mailto:rajeev.cham...@oracle.com <mailto:rajeev.cham...@oracle.com>>> 
>>>> wrote:
>>>> 
>>>>Hello Avik,
>>>> 
>>>>All exception caught during test should mark the test as failed.
>>>>For example not able to set any LAF should also be considered as
>>>>test failure.
>>>> 
>>>>Regards,
>>>> 
>>>>    Rajeev Chamyal
>>>> 
>>>>*From:*Avik Niyogi
>>>>*Sent:*20 January 2016 10:20
>>>>*To:*Rajeev Chamyal
>>>>*Cc:*Alexander Scherbatiy; Sergey Bylokhov
>>>>*Subject:*Re:  Review request for 8015748: JProgressbar
>>>>with Aqua LaF ignores
>>>>
>>>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>>>call
>>>> 
>>>>Hi Rajeev and Sergey,
>>>> 
>>>>A gentle reminder. Kindly request to complete the pending review
>>>>of my code changes in the webrev:
>>>>    http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/ 
>>>> <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/>
>>>><http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/ 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>>
>>>> 
>>>>Thank you in advance.
>>>> 
>>>>With Regards,
>>>> 
>>>>Avik Niyogi
>>>> 
>>>> 

Re: Review request for 8015748: JProgressbar with Aqua LaF ignores JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) call

[Avik Niyogi]

Hi Sergey,
This is the log of the test JProgressBarOrientationRobotTest.java after doing a 
make java.desktop after commenting out my code changes in 
AquaProgressBarUI.java :

run:
[Metal]: LTR orientation test passed
[Metal]: RTL orientation test passed
[Nimbus]: LTR orientation test passed
[Nimbus]: RTL orientation test passed
[CDE/Motif]: LTR orientation test passed
[CDE/Motif]: RTL orientation test passed
[Mac OS X]: LTR orientation test passed
[Mac OS X]: [Error]: LTR orientation test failed
[Mac OS X]: [Error]: LTR orientation test failed
BUILD SUCCESSFUL (total time: 31 seconds)

With Regards,
Avik Niyogi

> On 20-Jan-2016, at 4:30 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> 
>  The fix looks good to me.
> 
>  Thanks,
>  Alexandr.
> 
> On 1/20/2016 12:47 PM, Rajeev Chamyal wrote:
>> 
>> Looks good to me.
>> 
>> Regards,
>> 
>> Rajeev Chamyal
>> 
>> *From:*Avik Niyogi
>> *Sent:* 20 January 2016 12:23
>> *To:* Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov
>> *Cc:* swing-dev@openjdk.java.net
>> *Subject:* Re:  Review request for 8015748: JProgressbar with 
>> Aqua LaF ignores 
>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) 
>> call
>> 
>> Hi All,
>> 
>> Please review the code changes made as with inputs for the webrev: 
>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/>
>> 
>> With Regards,
>> 
>> Avik Niyogi
>> 
>>On 20-Jan-2016, at 10:40 am, Rajeev Chamyal
>><rajeev.cham...@oracle.com <mailto:rajeev.cham...@oracle.com>> wrote:
>> 
>>Hello Avik,
>> 
>>All exception caught during test should mark the test as failed.
>>For example not able to set any LAF should also be considered as
>>test failure.
>> 
>>Regards,
>> 
>>Rajeev Chamyal
>> 
>>*From:*Avik Niyogi
>>*Sent:*20 January 2016 10:20
>>*To:*Rajeev Chamyal
>>*Cc:*Alexander Scherbatiy; Sergey Bylokhov
>>*Subject:*Re:  Review request for 8015748: JProgressbar
>>with Aqua LaF ignores
>>JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>call
>> 
>>Hi Rajeev and Sergey,
>> 
>>A gentle reminder. Kindly request to complete the pending review
>>of my code changes in the webrev:
>>http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/
>><http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>
>> 
>>Thank you in advance.
>> 
>>With Regards,
>> 
>>Avik Niyogi
>> 
>>On 19-Jan-2016, at 9:01 pm, Alexander Scherbatiy
>><alexandr.scherba...@oracle.com
>>    <mailto:alexandr.scherba...@oracle.com>> wrote:
>> 
>> 
>> The fix looks good to me.
>> 
>> Thanks,
>> Alexandr.
>> 
>> 
>>On 19/01/16 15:27, Avik Niyogi wrote:
>> 
>>Hi All,
>> 
>>A gentle reminder. Please review my code changes as
>>mentioned in the webrev below as available in the link in
>>the mail trail.
>> 
>>With Regards,
>> 
>>Avik Niyogi
>> 
>>On 18-Jan-2016, at 11:34 am, Avik Niyogi
>><avik.niy...@oracle.com
>><mailto:avik.niy...@oracle.com>> wrote:
>> 
>>Hi All, Please find the changes as provided with
>>incorporation of inputs:
>> 
>>http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/
>><http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>
>> 
>>With Regards,
>> 
>>Avik Niyogi
>> 
>>On 14-Jan-2016, at 10:57 pm, Sergey Bylokhov
>><sergey.bylok...@oracle.com
>><mailto:sergey.bylok...@oracle.com>> wrote:
>> 
>>Probably I missed something but why we need two
>>tests? Note that the manual test is not marked as
>>manual, which means that it will be run during the
>>regular run?(even if -a option is provided to
>>jtreg). Please check your other review requests
>>        for this issue.
>> 
>>moreover on my s

Re: Review request for 8015748: JProgressbar with Aqua LaF ignores JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) call

[Avik Niyogi]

Hi Sergey,
The JTreg will pass, but the errors are posted to the log and not as an 
interrupt as it would prematurely terminate execution of entire test case for 
other look and feels if done so.

With Regards,
Avik Niyogi

> On 21-Jan-2016, at 8:26 am, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> Hi Sergey,
> This is the log of the test JProgressBarOrientationRobotTest.java after doing 
> a make java.desktop after commenting out my code changes in 
> AquaProgressBarUI.java :
> 
> run:
> [Metal]: LTR orientation test passed
> [Metal]: RTL orientation test passed
> [Nimbus]: LTR orientation test passed
> [Nimbus]: RTL orientation test passed
> [CDE/Motif]: LTR orientation test passed
> [CDE/Motif]: RTL orientation test passed
> [Mac OS X]: LTR orientation test passed
> [Mac OS X]: [Error]: LTR orientation test failed
> [Mac OS X]: [Error]: LTR orientation test failed
> BUILD SUCCESSFUL (total time: 31 seconds)
> 
> With Regards,
> Avik Niyogi
> 
>> On 20-Jan-2016, at 4:30 pm, Alexander Scherbatiy 
>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>> wrote:
>> 
>> 
>>  The fix looks good to me.
>> 
>>  Thanks,
>>  Alexandr.
>> 
>> On 1/20/2016 12:47 PM, Rajeev Chamyal wrote:
>>> 
>>> Looks good to me.
>>> 
>>> Regards,
>>> 
>>> Rajeev Chamyal
>>> 
>>> *From:*Avik Niyogi
>>> *Sent:* 20 January 2016 12:23
>>> *To:* Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov
>>> *Cc:* swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net>
>>> *Subject:* Re:  Review request for 8015748: JProgressbar with 
>>> Aqua LaF ignores 
>>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) 
>>> call
>>> 
>>> Hi All,
>>> 
>>> Please review the code changes made as with inputs for the webrev: 
>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/ 
>>> <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/> 
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/ 
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/>>
>>> 
>>> With Regards,
>>> 
>>> Avik Niyogi
>>> 
>>>On 20-Jan-2016, at 10:40 am, Rajeev Chamyal
>>><rajeev.cham...@oracle.com <mailto:rajeev.cham...@oracle.com> 
>>> <mailto:rajeev.cham...@oracle.com <mailto:rajeev.cham...@oracle.com>>> 
>>> wrote:
>>> 
>>>Hello Avik,
>>> 
>>>All exception caught during test should mark the test as failed.
>>>For example not able to set any LAF should also be considered as
>>>test failure.
>>> 
>>>Regards,
>>> 
>>>Rajeev Chamyal
>>> 
>>>*From:*Avik Niyogi
>>>*Sent:*20 January 2016 10:20
>>>*To:*Rajeev Chamyal
>>>*Cc:*Alexander Scherbatiy; Sergey Bylokhov
>>>*Subject:*Re:  Review request for 8015748: JProgressbar
>>>with Aqua LaF ignores
>>>
>>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>>call
>>> 
>>>Hi Rajeev and Sergey,
>>> 
>>>A gentle reminder. Kindly request to complete the pending review
>>>of my code changes in the webrev:
>>>http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/ 
>>> <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/>
>>><http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/ 
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>>
>>> 
>>>Thank you in advance.
>>> 
>>>With Regards,
>>> 
>>>Avik Niyogi
>>> 
>>>On 19-Jan-2016, at 9:01 pm, Alexander Scherbatiy
>>><alexandr.scherba...@oracle.com 
>>> <mailto:alexandr.scherba...@oracle.com>
>>><mailto:alexandr.scherba...@oracle.com 
>>> <mailto:alexandr.scherba...@oracle.com>>> wrote:
>>> 
>>> 
>>> The fix looks good to me.
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> 
>>>On 19/01/16 15:27, Avik Niyogi wrote:
>>> 
>>>Hi All,
>>> 
>>>A gentle reminder. Please review my code changes as
>>>mentioned in the webrev below as available in the link in
>>>the mail trail.
>>> 
&

Re: Review request for 8015748: JProgressbar with Aqua LaF ignores JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) call

[Avik Niyogi]

The fix is for Aqua Look and Feel. It works after the fix on JDK9

> On 20-Jan-2016, at 6:02 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> Hi, Avik.
> The test still pass before the fix, but it should fail.
> 
> On 20/01/16 14:00, Alexander Scherbatiy wrote:
>> 
>>   The fix looks good to me.
>> 
>>   Thanks,
>>   Alexandr.
>> 
>> On 1/20/2016 12:47 PM, Rajeev Chamyal wrote:
>>> 
>>> Looks good to me.
>>> 
>>> Regards,
>>> 
>>> Rajeev Chamyal
>>> 
>>> *From:*Avik Niyogi
>>> *Sent:* 20 January 2016 12:23
>>> *To:* Rajeev Chamyal; Alexander Scherbatiy; Sergey Bylokhov
>>> *Cc:* swing-dev@openjdk.java.net
>>> *Subject:* Re:  Review request for 8015748: JProgressbar
>>> with Aqua LaF ignores
>>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>> call
>>> 
>>> Hi All,
>>> 
>>> Please review the code changes made as with inputs for the webrev:
>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.07/>
>>> 
>>> With Regards,
>>> 
>>> Avik Niyogi
>>> 
>>>On 20-Jan-2016, at 10:40 am, Rajeev Chamyal
>>><rajeev.cham...@oracle.com <mailto:rajeev.cham...@oracle.com>> wrote:
>>> 
>>>Hello Avik,
>>> 
>>>All exception caught during test should mark the test as failed.
>>>For example not able to set any LAF should also be considered as
>>>test failure.
>>> 
>>>Regards,
>>> 
>>>Rajeev Chamyal
>>> 
>>>*From:*Avik Niyogi
>>>*Sent:*20 January 2016 10:20
>>>*To:*Rajeev Chamyal
>>>*Cc:*Alexander Scherbatiy; Sergey Bylokhov
>>>*Subject:*Re:  Review request for 8015748: JProgressbar
>>>with Aqua LaF ignores
>>> 
>>> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT)
>>> 
>>>call
>>> 
>>>Hi Rajeev and Sergey,
>>> 
>>>A gentle reminder. Kindly request to complete the pending review
>>>of my code changes in the webrev:
>>>http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/
>>><http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>
>>> 
>>>Thank you in advance.
>>> 
>>>With Regards,
>>> 
>>>Avik Niyogi
>>> 
>>>On 19-Jan-2016, at 9:01 pm, Alexander Scherbatiy
>>><alexandr.scherba...@oracle.com
>>><mailto:alexandr.scherba...@oracle.com>> wrote:
>>> 
>>> 
>>> The fix looks good to me.
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> 
>>>On 19/01/16 15:27, Avik Niyogi wrote:
>>> 
>>>Hi All,
>>> 
>>>A gentle reminder. Please review my code changes as
>>>mentioned in the webrev below as available in the link in
>>>the mail trail.
>>> 
>>>With Regards,
>>> 
>>>Avik Niyogi
>>> 
>>>On 18-Jan-2016, at 11:34 am, Avik Niyogi
>>><avik.niy...@oracle.com
>>><mailto:avik.niy...@oracle.com>> wrote:
>>> 
>>>Hi All, Please find the changes as provided with
>>>incorporation of inputs:
>>> 
>>>http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/
>>> 
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>
>>> 
>>>With Regards,
>>> 
>>>Avik Niyogi
>>> 
>>>On 14-Jan-2016, at 10:57 pm, Sergey Bylokhov
>>><sergey.bylok...@oracle.com
>>><mailto:sergey.bylok...@oracle.com>> wrote:
>>> 
>>>        Probably I missed something but why we need two
>>>tests? Note that the manual test is not marked as
>>>manual, which means that it will be run during the
>>>regular run?(even if -a option is provided to
>>>jtreg). Please check your other review requests
>>>for this issue.
>>>

Re: Review request for 8015748: JProgressbar with Aqua LaF ignores JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) call

[Avik Niyogi]

Hi All,
A gentle reminder. Please review my code changes as mentioned in the webrev 
below as available in the link in the mail trail.

With Regards,
Avik Niyogi

> On 18-Jan-2016, at 11:34 am, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> Hi All, Please find the changes as provided with incorporation of inputs:
> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/ 
> <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/>
> 
> With Regards,
> Avik Niyogi
> 
>> On 14-Jan-2016, at 10:57 pm, Sergey Bylokhov <sergey.bylok...@oracle.com 
>> <mailto:sergey.bylok...@oracle.com>> wrote:
>> 
>> Probably I missed something but why we need two tests? Note that the manual 
>> test is not marked as manual, which means that it will be run during the 
>> regular run?(even if -a option is provided to jtreg). Please check your 
>> other review requests for this issue.
>> 
>> moreover on my system JProgressBarOrientationManualTest.java simply passed, 
>> and JProgressBarOrientationRobotTest.java failed even after the fix. Please 
>> recheck.
>> 
>> On 14/01/16 13:11, Avik Niyogi wrote:
>>> Hi All,
>>> Please find the changes as provided with incorporation of inputs:
>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.05/ 
>>> <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.05/>
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 14-Jan-2016, at 3:18 pm, Alexander Scherbatiy
>>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>
>>>> <mailto:alexandr.scherba...@oracle.com 
>>>> <mailto:alexandr.scherba...@oracle.com>>> wrote:
>>>> 
>>>> On 1/14/2016 8:18 AM, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> Please find changes as provided with incorporation of inputs:
>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.04/ 
>>>>> <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.04/>
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/ 
>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>>
>>>> 
>>>>  It is better to restore the graphics transform after the progress
>>>> bar is painted and before the paintString call because the a method
>>>> that calls AquaProgressBarUI.paint(Graphics) can rely that the
>>>> graphics transform is unchanged.
>>>> In your fix the graphics transform is not restored if
>>>> progressBar.isStringPainted() returns false.
>>>> 
>>>> Thanks,
>>>> Alexandr.
>>>> 
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>> On 13-Jan-2016, at 7:02 pm, Alexander Scherbatiy
>>>>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>
>>>>>> <mailto:alexandr.scherba...@oracle.com 
>>>>>> <mailto:alexandr.scherba...@oracle.com>>
>>>>>> <mailto:alexandr.scherba...@oracle.com 
>>>>>> <mailto:alexandr.scherba...@oracle.com>>> wrote:
>>>>>> 
>>>>>> On 1/13/2016 9:28 AM, Avik Niyogi wrote:
>>>>>>> Hi All,
>>>>>>> Please find changes as provided with incorporation of inputs:
>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.03/ 
>>>>>>> <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.03/>
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/ 
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>>
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/ 
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>>
>>>>>>> 
>>>>>> 
>>>>>> It looks like a string on a vertical progress bar with the right to
>>>>>> left orientation will be mirrored.
>>>>>> Did you try just restore the scale/translate transform after the
>>>>>> painter.paint() call? Will it help in such case?
>>>>>> 
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>> 
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>>>> On 12-Jan-2016, at 11:49 pm, Alexander Scherbatiy
>>>>>>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@

Re: Review Request of 8146321: [macosx] JInternalFrame frame icon in wrong position on Mac L if icon is not ImageIcon

[Avik Niyogi]

Hi All,
A gentle reminder, please review my code changes as in the webrev below in the 
mail trail.
With Regards,
Avik Niyogi
> On 18-Jan-2016, at 3:01 pm, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> Hi Sergey,
> 
> Please review the webrev taking inputs as per the discussion before:
> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.01/ 
> <http://cr.openjdk.java.net/~aniyogi/8146321/webrev.01/>
> 
> With Regards,
> Avik Niyogi
> 
>> On 14-Jan-2016, at 12:55 pm, Avik Niyogi <avik.niy...@oracle.com 
>> <mailto:avik.niy...@oracle.com>> wrote:
>> 
>> Hi Sergey,
>> I have verified it with the test case as well. If a test case overrides 
>> these methods to imply a change with icons larger than 16x16 it will show 
>> that for ImageIcon and Icon as before. The resize of ImageIcon is only in 
>> case it has an image file that it will try to fit. I had a similar query 
>> myself and have found out that getImage() exists for ImageIcon class only 
>> and not Icon class.
>> Example:
>> private static void createImageIconUI(final String lookAndFeelString)
>> throws Exception {
>> SwingUtilities.invokeAndWait(new Runnable() {
>> @Override
>> public void run() {
>> desktopPane = new JDesktopPane();
>> internalFrame = new JInternalFrame();
>> frame = new JFrame();
>> internalFrame.setTitle(lookAndFeelString);
>> titleImageIcon = new ImageIcon() {
>> @Override
>> public int getIconWidth() {
>> return 16;
>> }
>> 
>> @Override
>> public int getIconHeight() {
>> return 16;
>> }
>> 
>> @Override
>> public void paintIcon(
>> Component c, Graphics g, int x, int y) {
>> g.setColor(java.awt.Color.black);
>> g.fillRect(x, y, 50, 50);
>> }
>> };
>> internalFrame.setFrameIcon(titleImageIcon);
>> internalFrame.setSize(500, 200);
>> internalFrame.setVisible(true);
>> desktopPane.add(internalFrame);
>> 
>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>> frame.getContentPane().setLayout(new BorderLayout());
>> frame.getContentPane().add(desktopPane, "Center");
>> frame.setSize(500, 500);
>> frame.setLocationRelativeTo(null);
>> frame.setVisible(true);
>> frame.toFront();
>> }
>> });
>> }
>> In this case the ImageIcon will NOT be resized to 16 x 16 even before my fix 
>> was implemented. That resize as shown in code is only for Image files to fit 
>> in default ImageIcon size as returned from the getIconHeight() and 
>> getIconWidth() methods. If user changes the ImageIcon size as in the 
>> example, that is upto to user to choose to do so and no control exists to 
>> prevent that. So, with or without my fix, this behaviour will be same for 
>> ImageIcon and Icon custom instances.
>> Hope this clarifies the query. 
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 14-Jan-2016, at 11:36 am, Sergey Bylokhov <sergey.bylok...@oracle.com 
>>> <mailto:sergey.bylok...@oracle.com>> wrote:
>>> 
>>> Hi, Avik.
>>> In the fix you update getIconWidth() and getIconHeight, so now we take the 
>>> Icon into account. but it seems if the Icon is bigger that the maximum size 
>>> it will not be resided to 16x16, right?
>>> 
>>> On 14/01/16 07:49, Avik Niyogi wrote:
>>>> Hi All,
>>>> 
>>>> Kindly review the bug fix for JDK 9.
>>>> 
>>>> *Bug:*
>>>> https://bugs.openjdk.java.net/browse/JDK-8146321 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8146321>
>>>> 
>>>> *Webrev:*
>>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/ 
>>>> <http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/>
>>>> 
>>>> *Issue:*
>>>> Under the Mac Look, if an icon type other than an ImageIcon is used
>>>> in JInternalFrame.setFrameIcon(),
>>>> the icon will show up in the wrong position.
>>>> 
>>>> *Cause:*
>>>> the "instanceof Icon" was not checked for. Also, customs ImageIcon with
>>>> color fill (and no image URL) which would
>>>> have resulted in null value for resized ImageIcon image was not well
>>>> handled.
>>>> 
>>>> *Fix:*
>>>> All places in Aqua LAF where "instanceof Icon” (and not just ImageIcon
>>>> class) is required,
>>>> inputs were added after significant analyses.
>>>> Check for null for getImage was done to remove a Null Pointer Exception.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>> 
>>> 
>>> -- 
>>> Best regards, Sergey.
>> 
> 

Re: Review request for 8015748: JProgressbar with Aqua LaF ignores JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) call

[Avik Niyogi]

Hi All,

Please review the code changes made as with inputs for the webrev: 
http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/ 
<http://cr.openjdk.java.net/~aniyogi/8015748/webrev.07/>

With Regards,
Avik Niyogi
> On 20-Jan-2016, at 10:40 am, Rajeev Chamyal <rajeev.cham...@oracle.com> wrote:
> 
> Hello Avik,
>  
> All exception caught during test should mark the test as failed. For example 
> not able to set any LAF should also be considered as test failure.
>  
> Regards,
> Rajeev Chamyal
>  
> From: Avik Niyogi 
> Sent: 20 January 2016 10:20
> To: Rajeev Chamyal
> Cc: Alexander Scherbatiy; Sergey Bylokhov
> Subject: Re:  Review request for 8015748: JProgressbar with Aqua 
> LaF ignores 
> JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) 
> call
>  
> Hi Rajeev and Sergey,
>  
> A gentle reminder. Kindly request to complete the pending review of my code 
> changes in the webrev: http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/ 
> <http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/>
> Thank you in advance.
>  
> With Regards,
> Avik Niyogi
>  
> On 19-Jan-2016, at 9:01 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
> wrote:
>  
> 
>  The fix looks good to me.
> 
>  Thanks,
>  Alexandr.
> 
> 
> On 19/01/16 15:27, Avik Niyogi wrote:
> Hi All, 
> A gentle reminder. Please review my code changes as mentioned in the webrev 
> below as available in the link in the mail trail.
>  
> With Regards,
> Avik Niyogi
>  
> On 18-Jan-2016, at 11:34 am, Avik Niyogi <avik.niy...@oracle.com 
> <mailto:avik.niy...@oracle.com>> wrote:
>  
> Hi All, Please find the changes as provided with incorporation of inputs: 
> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.06/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.06/>
>  
> With Regards,
> Avik Niyogi
>  
> On 14-Jan-2016, at 10:57 pm, Sergey Bylokhov <sergey.bylok...@oracle.com 
> <mailto:sergey.bylok...@oracle.com>> wrote:
>  
> Probably I missed something but why we need two tests? Note that the manual 
> test is not marked as manual, which means that it will be run during the 
> regular run?(even if -a option is provided to jtreg). Please check your other 
> review requests for this issue.
> 
> moreover on my system JProgressBarOrientationManualTest.java simply passed, 
> and JProgressBarOrientationRobotTest.java failed even after the fix. Please 
> recheck.
> 
> On 14/01/16 13:11, Avik Niyogi wrote:
> 
> Hi All,
> Please find the changes as provided with incorporation of inputs:
> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.05/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.05/>
> 
> With Regards,
> Avik Niyogi
> 
> On 14-Jan-2016, at 3:18 pm, Alexander Scherbatiy
> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>
> <mailto:alexandr.scherba...@oracle.com 
> <mailto:alexandr.scherba...@oracle.com>>> wrote:
> 
> On 1/14/2016 8:18 AM, Avik Niyogi wrote:
> 
> Hi All,
> Please find changes as provided with incorporation of inputs:
> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.04/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>
> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>>
> 
>  It is better to restore the graphics transform after the progress
> bar is painted and before the paintString call because the a method
> that calls AquaProgressBarUI.paint(Graphics) can rely that the
> graphics transform is unchanged.
> In your fix the graphics transform is not restored if
> progressBar.isStringPainted() returns false.
> 
> Thanks,
> Alexandr.
> 
> 
> 
> With Regards,
> Avik Niyogi
> 
> On 13-Jan-2016, at 7:02 pm, Alexander Scherbatiy
> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>
> <mailto:alexandr.scherba...@oracle.com 
> <mailto:alexandr.scherba...@oracle.com>>
> <mailto:alexandr.scherba...@oracle.com 
> <mailto:alexandr.scherba...@oracle.com>>> wrote:
> 
> On 1/13/2016 9:28 AM, Avik Niyogi wrote:
> 
> Hi All,
> Please find changes as provided with incorporation of inputs:
> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.03/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>>
> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/ 
> <ht

Re: Review Request of 8146321: [macosx] JInternalFrame frame icon in wrong position on Mac L if icon is not ImageIcon

[Avik Niyogi]

Hi Sergey,

Please review the webrev taking inputs as per the discussion before:
http://cr.openjdk.java.net/~aniyogi/8146321/webrev.01/ 
<http://cr.openjdk.java.net/~aniyogi/8146321/webrev.01/>

With Regards,
Avik Niyogi

> On 14-Jan-2016, at 12:55 pm, Avik Niyogi <avik.niy...@oracle.com> wrote:
> 
> Hi Sergey,
> I have verified it with the test case as well. If a test case overrides these 
> methods to imply a change with icons larger than 16x16 it will show that for 
> ImageIcon and Icon as before. The resize of ImageIcon is only in case it has 
> an image file that it will try to fit. I had a similar query myself and have 
> found out that getImage() exists for ImageIcon class only and not Icon class.
> Example:
> private static void createImageIconUI(final String lookAndFeelString)
> throws Exception {
> SwingUtilities.invokeAndWait(new Runnable() {
> @Override
> public void run() {
> desktopPane = new JDesktopPane();
> internalFrame = new JInternalFrame();
> frame = new JFrame();
> internalFrame.setTitle(lookAndFeelString);
> titleImageIcon = new ImageIcon() {
> @Override
> public int getIconWidth() {
> return 16;
> }
> 
> @Override
> public int getIconHeight() {
> return 16;
> }
> 
> @Override
> public void paintIcon(
> Component c, Graphics g, int x, int y) {
> g.setColor(java.awt.Color.black);
> g.fillRect(x, y, 50, 50);
> }
> };
> internalFrame.setFrameIcon(titleImageIcon);
> internalFrame.setSize(500, 200);
> internalFrame.setVisible(true);
> desktopPane.add(internalFrame);
> 
> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> frame.getContentPane().setLayout(new BorderLayout());
> frame.getContentPane().add(desktopPane, "Center");
> frame.setSize(500, 500);
> frame.setLocationRelativeTo(null);
> frame.setVisible(true);
> frame.toFront();
> }
> });
> }
> In this case the ImageIcon will NOT be resized to 16 x 16 even before my fix 
> was implemented. That resize as shown in code is only for Image files to fit 
> in default ImageIcon size as returned from the getIconHeight() and 
> getIconWidth() methods. If user changes the ImageIcon size as in the example, 
> that is upto to user to choose to do so and no control exists to prevent 
> that. So, with or without my fix, this behaviour will be same for ImageIcon 
> and Icon custom instances.
> Hope this clarifies the query. 
> 
> With Regards,
> Avik Niyogi
> 
>> On 14-Jan-2016, at 11:36 am, Sergey Bylokhov <sergey.bylok...@oracle.com 
>> <mailto:sergey.bylok...@oracle.com>> wrote:
>> 
>> Hi, Avik.
>> In the fix you update getIconWidth() and getIconHeight, so now we take the 
>> Icon into account. but it seems if the Icon is bigger that the maximum size 
>> it will not be resided to 16x16, right?
>> 
>> On 14/01/16 07:49, Avik Niyogi wrote:
>>> Hi All,
>>> 
>>> Kindly review the bug fix for JDK 9.
>>> 
>>> *Bug:*
>>> https://bugs.openjdk.java.net/browse/JDK-8146321 
>>> <https://bugs.openjdk.java.net/browse/JDK-8146321>
>>> 
>>> *Webrev:*
>>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/
>>> 
>>> *Issue:*
>>> Under the Mac Look, if an icon type other than an ImageIcon is used
>>> in JInternalFrame.setFrameIcon(),
>>> the icon will show up in the wrong position.
>>> 
>>> *Cause:*
>>> the "instanceof Icon" was not checked for. Also, customs ImageIcon with
>>> color fill (and no image URL) which would
>>> have resulted in null value for resized ImageIcon image was not well
>>> handled.
>>> 
>>> *Fix:*
>>> All places in Aqua LAF where "instanceof Icon” (and not just ImageIcon
>>> class) is required,
>>> inputs were added after significant analyses.
>>> Check for null for getImage was done to remove a Null Pointer Exception.
>>> 
>>> With Regards,
>>> Avik Niyogi
>> 
>> 
>> -- 
>> Best regards, Sergey.
> 

Re: Review request for 8015748: JProgressbar with Aqua LaF ignores JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) call

[Avik Niyogi]

Hi All,
Please find the changes as provided with incorporation of inputs:
http://cr.openjdk.java.net/~aniyogi/8015748/webrev.05/ 
<http://cr.openjdk.java.net/~aniyogi/8015748/webrev.05/>

With Regards,
Avik Niyogi
> On 14-Jan-2016, at 3:18 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> On 1/14/2016 8:18 AM, Avik Niyogi wrote:
>> Hi All,
>> Please find changes as provided with incorporation of inputs:
>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.04/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.04/>
> 
>   It is better to restore the graphics transform after the progress bar is 
> painted and before the paintString call because the a method that calls 
> AquaProgressBarUI.paint(Graphics) can rely that the graphics transform is 
> unchanged.
>  In your fix the graphics transform is not restored if 
> progressBar.isStringPainted() returns false.
> 
>  Thanks,
>  Alexandr.
> 
>> 
>> With Regards,
>> Avik Niyogi
>>> On 13-Jan-2016, at 7:02 pm, Alexander Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> On 1/13/2016 9:28 AM, Avik Niyogi wrote:
>>>> Hi All,
>>>> Please find changes as provided with incorporation of inputs:
>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.03/ 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/> 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>>>> 
>>> 
>>> It looks like a string on a vertical progress bar with the right to left 
>>> orientation will be mirrored.
>>> Did you try just restore the scale/translate transform after the 
>>> painter.paint() call? Will it help in such case?
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 12-Jan-2016, at 11:49 pm, Alexander Scherbatiy 
>>>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com> 
>>>>> <mailto:alexandr.scherba...@oracle.com>> wrote:
>>>>> 
>>>>> 
>>>>> - there was the comment below that it is better to revert the transform 
>>>>> back after the painter.paint() call
>>>>> - according to the comment from the 
>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-January/005262.html
>>>>> 
>>>>> It is true that a filled progress bar has different colors because of 
>>>>> animation under Aqua L
>>>>> However, it is possible to compare colors before a progress bar was 
>>>>> filled and after that to check that the progress bar is filled from the 
>>>>> correct side.
>>>>> For example let's set a progress bar value to 0 and get its color from 
>>>>> 5/6 of the progress bar width
>>>>>progress bar: [_o__]  // get a color at point o
>>>>> Now set the progress bar value to 30 and get a color at the same point.
>>>>> If colors are the same then  the progress bar is filled from left to the 
>>>>> right [_o__].
>>>>> If colors are different then the progress bar is filled from the right to 
>>>>> the left [|o||] .
>>>>> 
>>>>> Thanks,
>>>>> Alexandr.
>>>>> 
>>>>> 
>>>>> On 12/01/16 13:34, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> Please find the code changes in fix as with the inputs received for the 
>>>>>> same.
>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.02/ 
>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/> 
>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>> 
>>>>>>> On 11-Jan-2016, at 3:55 pm, Semyon Sadetsky <semyon.sadet...@oracle.com 
>>>>>>> <mailto:semyon.sadet...@oracle.com> 
>>>>>>> <mailto:semyon.sadet...@oracle.com>> wrote:
>>>>>>> 
>>>>>>> Hi Avik,
>>>>>>> 
>>>>>>> Shouldn't the graphics transformation be restored before the 
>>>>>>> paintString() call?
>>>>>>> 
>>>>>&g

Re: Review request for 8015748: JProgressbar with Aqua LaF ignores JProgressbar#applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) call

[Avik Niyogi]

Hi All,
Please find changes as provided with incorporation of inputs:
http://cr.openjdk.java.net/~aniyogi/8015748/webrev.04/ 
<http://cr.openjdk.java.net/~aniyogi/8015748/webrev.04/>

With Regards,
Avik Niyogi
> On 13-Jan-2016, at 7:02 pm, Alexander Scherbatiy 
> <alexandr.scherba...@oracle.com> wrote:
> 
> On 1/13/2016 9:28 AM, Avik Niyogi wrote:
>> Hi All,
>> Please find changes as provided with incorporation of inputs:
>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.03/ 
>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.03/>
>> 
> 
>  It looks like a string on a vertical progress bar with the right to left 
> orientation will be mirrored.
>  Did you try just restore the scale/translate transform after the 
> painter.paint() call? Will it help in such case?
> 
>  Thanks,
>  Alexandr.
> 
>> With Regards,
>> Avik Niyogi
>>> On 12-Jan-2016, at 11:49 pm, Alexander Scherbatiy 
>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>> 
>>> wrote:
>>> 
>>> 
>>> - there was the comment below that it is better to revert the transform 
>>> back after the painter.paint() call
>>> - according to the comment from the 
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-January/005262.html
>>> 
>>> It is true that a filled progress bar has different colors because of 
>>> animation under Aqua L
>>> However, it is possible to compare colors before a progress bar was filled 
>>> and after that to check that the progress bar is filled from the correct 
>>> side.
>>> For example let's set a progress bar value to 0 and get its color from 5/6 
>>> of the progress bar width
>>> progress bar: [_o__]  // get a color at point o
>>> Now set the progress bar value to 30 and get a color at the same point.
>>> If colors are the same then  the progress bar is filled from left to the 
>>> right [_o__].
>>> If colors are different then the progress bar is filled from the right to 
>>> the left [|o||] .
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> 
>>> On 12/01/16 13:34, Avik Niyogi wrote:
>>>> Hi All,
>>>> 
>>>> Please find the code changes in fix as with the inputs received for the 
>>>> same.
>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.02/ 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.02/>
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 11-Jan-2016, at 3:55 pm, Semyon Sadetsky <semyon.sadet...@oracle.com 
>>>>> <mailto:semyon.sadet...@oracle.com>> wrote:
>>>>> 
>>>>> Hi Avik,
>>>>> 
>>>>> Shouldn't the graphics transformation be restored before the 
>>>>> paintString() call?
>>>>> 
>>>>> It seems to me that left/right insets need to be swapped for 
>>>>> right-to-left painting with mirroring graphics transformation.
>>>>> 
>>>>> --Semyon
>>>>> 
>>>>> On 1/5/2016 1:22 PM, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>> Please find webrev with inputs as provided: 
>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.01/
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>> 
>>>>>>> On 23-Dec-2015, at 7:29 pm, Alexander Scherbatiy 
>>>>>>> <alexandr.scherba...@oracle.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>  - please check that the progress bar string 
>>>>>>> (progressBar.setString()/setStringPainted()) is painted correctly.
>>>>>>>  - is it possible to write an automated test for the fix?
>>>>>>> 
>>>>>>>  Thanks,
>>>>>>>  Alexandr.
>>>>>>> 
>>>>>>> On 12/21/2015 11:47 AM, Avik Niyogi wrote:
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> Kindly review the bug fix for JDK 9.
>>>>>>>> 
>>>>>>>> *Bug:*
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8015748
>>>>>>>> 
>>>>>>>> *Webrev:*
>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8015748/webrev.00/ 
>>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8015748/webrev.00/>
>>>>>>>> 
>>>>>>>> *Issue:*
>>>>>>>> The manual test: 
>>>>>>>> Swing_JProgressbar/Manual/ProgressBarLAFTests/ProgressBarLAFTest1
>>>>>>>> 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 JProgressBar for the AquaLookAndFeel only,
>>>>>>>> the progressBar does not have the ability to grow from right to left. 
>>>>>>>> This issue was verified to exist only in AquaLookAndFeel for 
>>>>>>>> JProgressBar.
>>>>>>>> 
>>>>>>>> *Fix:*
>>>>>>>> Added implementation for the check of RIGHT_TO_LEFT 
>>>>>>>> ComponentOrientation and verified with other combination orientation 
>>>>>>>> with available
>>>>>>>> Horizontal and Vertical orientations as provided from before.
>>>>>>>> 
>>>>>>>> With Regards,
>>>>>>>> Avik Niyogi
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: Review Request of 8146321: [macosx] JInternalFrame frame icon in wrong position on Mac L if icon is not ImageIcon

[Avik Niyogi]

Hi Sergey,
I have verified it with the test case as well. If a test case overrides these 
methods to imply a change with icons larger than 16x16 it will show that for 
ImageIcon and Icon as before. The resize of ImageIcon is only in case it has an 
image file that it will try to fit. I had a similar query myself and have found 
out that getImage() exists for ImageIcon class only and not Icon class.
Example:
private static void createImageIconUI(final String lookAndFeelString)
throws Exception {
SwingUtilities.invokeAndWait(new Runnable() {
@Override
public void run() {
desktopPane = new JDesktopPane();
internalFrame = new JInternalFrame();
frame = new JFrame();
internalFrame.setTitle(lookAndFeelString);
titleImageIcon = new ImageIcon() {
@Override
public int getIconWidth() {
return 16;
}

@Override
public int getIconHeight() {
return 16;
}

@Override
public void paintIcon(
Component c, Graphics g, int x, int y) {
g.setColor(java.awt.Color.black);
g.fillRect(x, y, 50, 50);
}
};
internalFrame.setFrameIcon(titleImageIcon);
internalFrame.setSize(500, 200);
internalFrame.setVisible(true);
desktopPane.add(internalFrame);

frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.getContentPane().setLayout(new BorderLayout());
frame.getContentPane().add(desktopPane, "Center");
frame.setSize(500, 500);
frame.setLocationRelativeTo(null);
frame.setVisible(true);
frame.toFront();
}
});
}
In this case the ImageIcon will NOT be resized to 16 x 16 even before my fix 
was implemented. That resize as shown in code is only for Image files to fit in 
default ImageIcon size as returned from the getIconHeight() and getIconWidth() 
methods. If user changes the ImageIcon size as in the example, that is upto to 
user to choose to do so and no control exists to prevent that. So, with or 
without my fix, this behaviour will be same for ImageIcon and Icon custom 
instances.
Hope this clarifies the query. 

With Regards,
Avik Niyogi

> On 14-Jan-2016, at 11:36 am, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> Hi, Avik.
> In the fix you update getIconWidth() and getIconHeight, so now we take the 
> Icon into account. but it seems if the Icon is bigger that the maximum size 
> it will not be resided to 16x16, right?
> 
> On 14/01/16 07:49, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the bug fix for JDK 9.
>> 
>> *Bug:*
>> https://bugs.openjdk.java.net/browse/JDK-8146321
>> 
>> *Webrev:*
>> http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/
>> 
>> *Issue:*
>> Under the Mac Look, if an icon type other than an ImageIcon is used
>> in JInternalFrame.setFrameIcon(),
>> the icon will show up in the wrong position.
>> 
>> *Cause:*
>> the "instanceof Icon" was not checked for. Also, customs ImageIcon with
>> color fill (and no image URL) which would
>> have resulted in null value for resized ImageIcon image was not well
>> handled.
>> 
>> *Fix:*
>> All places in Aqua LAF where "instanceof Icon” (and not just ImageIcon
>> class) is required,
>> inputs were added after significant analyses.
>> Check for null for getImage was done to remove a Null Pointer Exception.
>> 
>> With Regards,
>> Avik Niyogi
> 
> 
> -- 
> Best regards, Sergey.

Review Request of 8146321: [macosx] JInternalFrame frame icon in wrong position on Mac L if icon is not ImageIcon

[Avik Niyogi]

Hi All,

Kindly review the bug fix for JDK 9.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8146321 
<https://bugs.openjdk.java.net/browse/JDK-8146321>

Webrev:
http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/ 
<http://cr.openjdk.java.net/~aniyogi/8146321/webrev.00/>

Issue:
Under the Mac Look, if an icon type other than an ImageIcon is used in 
JInternalFrame.setFrameIcon(),
the icon will show up in the wrong position. 

Cause:
the "instanceof Icon" was not checked for. Also, customs ImageIcon with color 
fill (and no image URL) which would 
have resulted in null value for resized ImageIcon image was not well handled.

Fix:
All places in Aqua LAF where "instanceof Icon” (and not just ImageIcon class) 
is required, 
inputs were added after significant analyses.
Check for null for getImage was done to remove a Null Pointer Exception.

With Regards,
Avik Niyogi

Re: Review request for 8016665: [macosx] JComponent behaviour doesn't comply API documentation (setComponentOrientation method), Aqua LAF

[Avik Niyogi]

Hi All,

Please find code changes incorporating changes as suggested by inputs provided:

http://cr.openjdk.java.net/~aniyogi/8016665/webrev.02/ 
<http://cr.openjdk.java.net/~aniyogi/8016665/webrev.02/>

With Regards,
Avik Niyogi

> On 13-Jan-2016, at 11:38 pm, Sergey Bylokhov <sergey.bylok...@oracle.com> 
> wrote:
> 
> On 13/01/16 09:27, Avik Niyogi wrote:
>> Hi Sergey,
>> If fFileList refers to a soft linked empty folder, we will  will not
>> need to apply orientation to it’s sub-components.
> I didn't understand what "soft linked empty folder" means here =((
> 
> Just to clarify. In the fix you have this code:
>  95 if (fFileList != null) {
>  96 fFileList.setComponentOrientation(o);
> ...
>  98 }
> 
> Which means that fFileList can be null, but it is a final field in the 
> AquaFileSystemModel and it is initialized in the 
> AquaFileChooserUI.createList() to a non null value:
> 
>fFileList = new JTableExtension();
> .
>model = new AquaFileSystemModel(fc, fFileList, fColumnNames);
> 
> Or am I missing something?
> 
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 12-Jan-2016, at 7:19 pm, Sergey Bylokhov
>>> <sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com>> wrote:
>>> 
>>> Hi, Avik.
>>> Is it possible that fFileList can be null? I see that in other places
>>> we do not check it to null?
>>> 
>>> On 04/01/16 11:52, Avik Niyogi wrote:
>>>> Hi All,
>>>> 
>>>> Please review the webrev.01 :
>>>> http://cr.openjdk.java.net/~aniyogi/8016665/webrev.01/
>>>> incorporated with the inputs received.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>>> On 28-Dec-2015, at 10:23 am, Avik Niyogi <avik.niy...@oracle.com
>>>>> <mailto:avik.niy...@oracle.com>
>>>>> <mailto:avik.niy...@oracle.com>> wrote:
>>>>> 
>>>>> 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
>>>>>> <alexandr.scherba...@oracle.com <mailto:alexandr.scherba...@oracle.com>
>>>>>> <mailto:alexandr.scherba...@oracle.com>> 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/
>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8016665/webrev.00/>
>>>>>>> 
>>>>>>> *Issue:*
>>>>>>> The manual test: Swing_AllComponents/Manual/I18nSwingTests
>>>>>>> in testsuite 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
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Best regards, Sergey.
>> 
> 
> 
> -- 
> Best regards, Sergey.