From tim.bell at oracle.com Tue Apr 1 02:43:31 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 01 Apr 2014 02:43:31 +0000 Subject: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris In-Reply-To: References: <5332ACC3.6080109@oracle.com> <5332B687.40402@oracle.com> <5332BAB3.6020505@oracle.com> <5332BBB9.1040302@oracle.com> <53340FCF.3080305@oracle.com> Message-ID: <533A27D3.207@oracle.com> Hi Erik Looks good to me as well. Tim > Looks good to me. > > /Magnus > >> On 27 mar 2014, at 12:47, Erik Joelsson wrote: >> >> Further testing revealed some more issues. New webrev: >> >> http://cr.openjdk.java.net/~erikj/8038340/webrev.root.03/ >> >> I had to break out the devkit/sysroot parts from from BASIC_SETUP_PATHS so that it happened after the early custom hook. >> >> /Erik >> >>> On 2014-03-26 12:36, Magnus Ihse Bursie wrote: >>> >>>> On 2014-03-26 12:32, Erik Joelsson wrote: >>>> Thanks, here is a new webrev: >>>> >>>> http://cr.openjdk.java.net/~erikj/8038340/webrev.root.02/ >>> Looks good to me. >>> >>> /Magnus From dmitriy.ermashov at oracle.com Tue Apr 1 09:06:50 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Tue, 01 Apr 2014 13:06:50 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <5339727F.5000109@oracle.com> References: <53392A07.8060702@oracle.com> <53393F56.50501@oracle.com> <7C52E68B-B5B9-440E-9C4A-8C2F7E8B6BC0@oracle.com> <533956D9.4020306@oracle.com> <5339727F.5000109@oracle.com> Message-ID: <533A81AA.6050200@oracle.com> Hi, Sergey On 31.03.2014 17:49, Sergey Bylokhov wrote: > Hi, Dmitriy. > Do I understand correctly that these methods will be added to the > Robot class in jdk9? Yes, it is a current plan. > A few notes: > - Different javadoc formatting for different methods. > - There is no information about exceptions. At least waitForIdle will > throw an exception if will be called on edt. 2All: please, review the latest version of changeset: http://cr.openjdk.java.net/~yan/8038631/webrev.02/ > > On 31.03.2014 15:51, Dmitriy Ermashov wrote: >> Hi, >> >> Please, review the latest version of changeset for: >> https://bugs.openjdk.java.net/browse/JDK-8038631 >> >> Webrev is here: >> http://cr.openjdk.java.net/~yan/8038631/webrev.01/ >> >> >> On 31.03.2014 14:15, Petr Pchelko wrote: >>>>> 4. The default value for realSync additional delay doesn't seem >>>>> enough. We normally use 500 ms as the frame creation and first >>>>> draw could take more time. >>>> We have to use small delay between mousePress and mouseRelease >>>> events to emulate real mouse click event. And larger delay can be >>>> put after mouseRelease call, for ex. 500 ms, as you wrote. >>>> Don't you mind of this solution? >>> And couldn't you reuse DEFAULT_SPEED for sleeping in mouseClick? The >>> comment states it's used there but it's not.. >>> >>>>> 5. The click method could be more consistent with others if called >>>>> "mouseClick". No strong opinion on this. >>>> For now we have several hundreds of functional tests, most of them >>>> use method named click(). It seems more reasonable to create method >>>> click() and use it than search the usage of it in all tests and fix >>>> to mouseClick() call. >>> Ok, no problem. I'm fine either way. >>> >>> With best regards. Petr. >>> >>> On 31.03.2014, at 14:11, Dmitriy Ermashov >>> wrote: >>> >>>> On 31.03.2014 13:12, Petr Pchelko wrote: >>>>> Hello, Dmitry. >>>>> >>>>> Some comments: >>>>> >>>>> 1. The name RobotWrapper does not fit in my opinion. The "Wrapper" >>>>> is more useful for delegation not extension and it feels like you >>>>> should pass the normal Robot to the wrapper constructor.. I think >>>>> something like "ExtendedRobot" would feel better. This is my >>>>> personal preference so it's arguable. >>>> No objections. Will rename it to ExtendedRobot. >>>>> 2. I'm not sure I understand why is this location of the util >>>>> works? in JavaDoc you state that it should be included from >>>>> regtesthelpers but you put it to the test lib. Is it some feature >>>>> of jtreg I'm not aware of? >>>> Will fix in next version of webrev. >>>>> 3. Could you please use @code instead of >>>> Will fix in next version of webrev. >>>>> 4. The default value for realSync additional delay doesn't seem >>>>> enough. We normally use 500 ms as the frame creation and first >>>>> draw could take more time. >>>> We have to use small delay between mousePress and mouseRelease >>>> events to emulate real mouse click event. And larger delay can be >>>> put after mouseRelease call, for ex. 500 ms, as you wrote. >>>> Don't you mind of this solution? >>>>> 5. The click method could be more consistent with others if called >>>>> "mouseClick". No strong opinion on this. >>>> For now we have several hundreds of functional tests, most of them >>>> use method named click(). It seems more reasonable to create method >>>> click() and use it than search the usage of it in all tests and fix >>>> to mouseClick() call. >>>>> 6. "Clicks mouse button 1 with the default pause between Press and >>>>> Release." this statement does not seem clear. How to override the >>>>> default value? Why does this method click with the default pause >>>>> and the previous one does not? or does it? It's not clear from the >>>>> JavaDoc >>>> I believe, javadoc should be fixed. >>>> Will fix in next version of webrev. >>>>> 7. Could you please add @Override annotations where appropriate >>>>> (waitForIdle for example) >>>> Will fix in next version of webrev. >>>>> 8. "public void type" may be keyType would be better? For >>>>> consistency with other methods. >>>> Same as 5. >>>>> 9. Could the method you are using for converting KeyChar to >>>>> KeyCode be replaces with KeyEvent.getExtendedKeyCodeForChar? Or >>>>> KeyStroke API? This switch is ugly and it would be awesome to >>>>> replace it. >>>> Will fix in next version of webrev. >>>>> Thank you. >>>>> With best regards. Petr. >>>>> >>>>> On 31.03.2014, at 12:40, Dmitriy Ermashov >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> Please, review the changeset for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8038631 >>>>>> >>>>>> Webrev is here: >>>>>> http://cr.openjdk.java.net/~yan/8038631/webrev.00 >>>>>> >>>>>> Presently for testing of JDK client we use test suites of two >>>>>> kinds, historically called regression and functional (internal). >>>>>> In JDK9 we plan an attempt to unify them and ultimately get rid >>>>>> of the functional suites. >>>>>> >>>>>> One of the first technical problems in this refactoring attempt >>>>>> is a multitude of the java.awt.Robot wrappers. There are some >>>>>> really elaborate libraries enhansing Robot which all we cannot >>>>>> and should not port to jtreg. >>>>>> >>>>>> Fortunately, test writers almost never use complex features of >>>>>> these wrappers. So here's our plan: >>>>>> (1) describe the real practice of the robot use in the functional >>>>>> tests (please don't worry, that's out of scope of this request); >>>>>> (2) write a minimal useful RobotWrapper extending java.awt.Robot; >>>>>> (3) start functional tests refactoring; >>>>>> (4) cautiously move enhancements to the java.awt.Robot trying not >>>>>> to break backward compatibility of thousands existing tests. For >>>>>> instance, waitForIdle should use realSync() but there definitely >>>>>> are plenty of tests using it on EDT: or maybe not -- we should >>>>>> spent some time for background research in parallel with (3). >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Dima >>>>>> >>>> -- >>>> Thanks, >>>> Dima >>>> >> > > -- Thanks, Dima From dmitry.markov at oracle.com Tue Apr 1 11:02:18 2014 From: dmitry.markov at oracle.com (dmitry markov) Date: Tue, 01 Apr 2014 15:02:18 +0400 Subject: [9] Review Request: JDK-8036112: JColorChooser throws a NPE when applet with static reference is reloaded Message-ID: <533A9CBA.2090107@oracle.com> Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8036112 webrev: http://cr.openjdk.java.net/~dmarkov/8036112/jdk9/webrev.00/ Problem description: the EventQueue object stored in AppContext for static fields of an applet becomes null after the refresh of the web page. This may cause a NPE in swing/awt code. Fix: The method SunToolkit.getSystEmeventQueueImplPP(AppContext appContext) should be modified. If the EventQueue from the passed AppContext is null, the method will retrieve the EventQueue from the default AppContext. Thanks, Dmitry From Sergey.Bylokhov at oracle.com Tue Apr 1 11:17:17 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 01 Apr 2014 15:17:17 +0400 Subject: [9] Review Request: JDK-8036112: JColorChooser throws a NPE when applet with static reference is reloaded In-Reply-To: <533A9CBA.2090107@oracle.com> References: <533A9CBA.2090107@oracle.com> Message-ID: <533AA03D.1040509@oracle.com> Hi, Dmitry. This means that the wrong EDT will be used for some components. The situation is strange. We have appcontext and probably some components, which belongs to it, but there is no appropriate EDT. Why? Should we recreate it? And i think appContext.getAppContext() can be null too. On 4/1/14 3:02 PM, dmitry markov wrote: > Hello, > > Could you review the fix for jdk9, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8036112 > webrev: http://cr.openjdk.java.net/~dmarkov/8036112/jdk9/webrev.00/ > > Problem description: the EventQueue object stored in AppContext for > static fields of an applet becomes null after the refresh of the web > page. This may cause a NPE in swing/awt code. > > Fix: The method SunToolkit.getSystEmeventQueueImplPP(AppContext > appContext) should be modified. If the EventQueue from the passed > AppContext is null, the method will retrieve the EventQueue from the > default AppContext. > > Thanks, > Dmitry > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Wed Apr 2 06:36:22 2014 From: dmitry.markov at oracle.com (dmitry markov) Date: Wed, 02 Apr 2014 10:36:22 +0400 Subject: [9] Review Request: JDK-8036112: JColorChooser throws a NPE when applet with static reference is reloaded In-Reply-To: <533AA03D.1040509@oracle.com> References: <533A9CBA.2090107@oracle.com> <533AA03D.1040509@oracle.com> Message-ID: <533BAFE6.8080006@oracle.com> Hi, Sergey, Please find my answer inline. Thanks, Dmitry On 01/04/2014 15:17, Sergey Bylokhov wrote: > Hi, Dmitry. > This means that the wrong EDT will be used for some components. > The situation is strange. We have appcontext and probably some > components, which belongs to it, but there is no appropriate EDT. Why? > Should we recreate it? This situation is typical for the applets which have some AWT or Swing components as a static fields (see simple example in https://bugs.openjdk.java.net/browse/JDK-8036112 ). The static field is created only once when the applet's code is loaded. All works well for the first execution. However, if the web page is refreshed, (i.e. F5 is pressed), the Java Plugin destroys the applet and starts it again. The static fields stay untouched since they should be the same for all instances of the applet's class. So the static AWT/Swing component has AppContext which points to not existed EventQueue object, since it has gone during applet's relaunch. Of course we can try to re-create AppContext during applet's relaunch, but I do not think that's a good idea. In this case we have to go through all static fields and find out the components whose AppContext should be changed. But it may take a lot of time and significantly increase the applet's relaunch time, since the structure of static field may be quite complex. > And i think appContext.getAppContext() can be null too. > > > On 4/1/14 3:02 PM, dmitry markov wrote: >> Hello, >> >> Could you review the fix for jdk9, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8036112 >> webrev: http://cr.openjdk.java.net/~dmarkov/8036112/jdk9/webrev.00/ >> >> Problem description: the EventQueue object stored in AppContext for >> static fields of an applet becomes null after the refresh of the web >> page. This may cause a NPE in swing/awt code. >> >> Fix: The method SunToolkit.getSystEmeventQueueImplPP(AppContext >> appContext) should be modified. If the EventQueue from the passed >> AppContext is null, the method will retrieve the EventQueue from the >> default AppContext. >> >> Thanks, >> Dmitry >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.pchelko at oracle.com Wed Apr 2 09:16:08 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 2 Apr 2014 13:16:08 +0400 Subject: [9] Review Request: JDK-8037560 [macosx] Cleaup CClipboard.m In-Reply-To: References: <53281239.4080304@oracle.com> <2DEC7D1A-3634-4BCC-8729-FA1FF4F98056@oracle.com> <53288F05.5000906@oracle.com> Message-ID: <34F58511-FF2F-4026-8B10-F82779F49DCC@oracle.com> Hello, This is a reminder.. With best regards. Petr. On 21.03.2014, at 16:22, Petr Pchelko wrote: > Hello, > > Is anybody willing to make a second review? > > With best regards. Petr. > > On 18.03.2014, at 22:23, Anthony Petrov wrote: > >> Sounds good. +1. >> >> -- >> best regards, >> Anthony >> >> On 3/18/2014 1:39 PM, Petr Pchelko wrote: >>> Hello, Anthony. >>> >>>> I didn't make a line-to-line comparison, but overall the new code looks good to me. Note that I'd leave the comment at old lines 176-179 as is for clarity. >>> Ok, I'll return it back before the push. >>> >>>> PS. I assume all clipboard tests pass after this fix. >>> Most of the tests fail on Mac OS X even before the fix because of the bug I've originally tried to fix, but this change does not add any new failures. >>> >>> With best regards. Petr. >>> >>> On 18.03.2014, at 13:30, Anthony Petrov wrote: >>> >>>> Hi Petr, >>>> >>>> I didn't make a line-to-line comparison, but overall the new code looks good to me. Note that I'd leave the comment at old lines 176-179 as is for clarity. >>>> >>>> PS. I assume all clipboard tests pass after this fix. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 3/18/2014 12:17 PM, Petr Pchelko wrote: >>>>> Hello, AWT Team. >>>>> >>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8037560 >>>>> The fix: http://cr.openjdk.java.net/~pchelko/9/8037560/webrev/ >>>>> >>>>> Recently I've tried to fix our clipboard tests and make a proper implementation of the ClipboardOwner notifications on Mac OS X. >>>>> However this appeared to be impossible without any over-complex solution due to Cocoa restrictions. By the way I've done a big >>>>> clean-up of the Clipboard native code which would be a pity to throw away. So could you please review this clean-up fix. >>>>> >>>>> What I'm doing is replacing the selector-based invocations with block-based, so the source shrinks quite a lot. >>>>> >>>>> With best regards. Petr. >>>>> >>>>> >>> > From petr.pchelko at oracle.com Wed Apr 2 09:19:20 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 2 Apr 2014 13:19:20 +0400 Subject: [9] Review Request: 8038999 In Java 8 java.awt.datatransfer.DataFlavor.equals is no longer symmetric Message-ID: Hello, AWT Team. The bug: https://bugs.openjdk.java.net/browse/JDK-8038999 The fix: http://cr.openjdk.java.net/~pchelko/9/8038999/webrev/ After adding HTML data flavors the equals is not symmetric any more. I've also updated the hashCode, to avoid unnecessary hash collisions. Also I've fixed an annoying broken javadoc link.. With best regards. Petr. From petr.pchelko at oracle.com Wed Apr 2 10:28:28 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 2 Apr 2014 14:28:28 +0400 Subject: [9] Review Request: 8038999 In Java 8 java.awt.datatransfer.DataFlavor.equals is no longer symmetric In-Reply-To: References: Message-ID: Hello, I quick follow-up. Please review a new version here: http://cr.openjdk.java.net/~pchelko/9/8038999/webrev.01/ I've used Objects.equals as it looks better. With best regards. Petr. On 02.04.2014, at 13:19, Petr Pchelko wrote: > Hello, AWT Team. > > The bug: https://bugs.openjdk.java.net/browse/JDK-8038999 > The fix: http://cr.openjdk.java.net/~pchelko/9/8038999/webrev/ > > After adding HTML data flavors the equals is not symmetric any more. I've also updated the hashCode, to avoid unnecessary hash collisions. > Also I've fixed an annoying broken javadoc link.. > > With best regards. Petr. From andrew.brygin at oracle.com Wed Apr 2 10:45:00 2014 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Wed, 02 Apr 2014 14:45:00 +0400 Subject: [9] Request for review: 8019990: IM candidate window appears on the South-East corner of the display. Message-ID: <533BEA2C.7090005@oracle.com> Hello, could you please review a fix for 8019990? bug: https://bugs.openjdk.java.net/browse/JDK-8019990 webrev: http://cr.openjdk.java.net/~bae/8019990/9/webrev.00/ The problem was triggered by the fix for 7024749, which moved IME messages handling from awt_Component to awt_Frame. Due to this change, the WM_IME_SETCONTEXT never reaches the applet's component, and candidate window position is never adjusted. Suggested fix reverts a part of the fix for 7024749: messages WM_IME_SETCONTEXT and WM_IME_NOTIFY are handled in awt_Component again. To prevent the crash described in 7024749, I suggest to check whether the proxy is enabled before routing messages to it (see awt_Component.cpp, line 4090). I have verified that the suggested change does not trigger any automatic regression test related to IM. Unfortunately, there is no new regression test related to the candidate window position because this problem can be reproduced in a browser, but does not appear in applet-based regression tests. Please take a look. Thanks, Andrew From Sergey.Bylokhov at oracle.com Wed Apr 2 10:46:29 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 02 Apr 2014 14:46:29 +0400 Subject: [9] Review Request: JDK-8037560 [macosx] Cleaup CClipboard.m In-Reply-To: <34F58511-FF2F-4026-8B10-F82779F49DCC@oracle.com> References: <53281239.4080304@oracle.com> <2DEC7D1A-3634-4BCC-8729-FA1FF4F98056@oracle.com> <53288F05.5000906@oracle.com> <34F58511-FF2F-4026-8B10-F82779F49DCC@oracle.com> Message-ID: <533BEA85.2080606@oracle.com> Hi, Petr. The fix looks good. On 4/2/14 1:16 PM, Petr Pchelko wrote: > Hello, > > This is a reminder.. > > With best regards. Petr. > > On 21.03.2014, at 16:22, Petr Pchelko wrote: > >> Hello, >> >> Is anybody willing to make a second review? >> >> With best regards. Petr. >> >> On 18.03.2014, at 22:23, Anthony Petrov wrote: >> >>> Sounds good. +1. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 3/18/2014 1:39 PM, Petr Pchelko wrote: >>>> Hello, Anthony. >>>> >>>>> I didn't make a line-to-line comparison, but overall the new code looks good to me. Note that I'd leave the comment at old lines 176-179 as is for clarity. >>>> Ok, I'll return it back before the push. >>>> >>>>> PS. I assume all clipboard tests pass after this fix. >>>> Most of the tests fail on Mac OS X even before the fix because of the bug I've originally tried to fix, but this change does not add any new failures. >>>> >>>> With best regards. Petr. >>>> >>>> On 18.03.2014, at 13:30, Anthony Petrov wrote: >>>> >>>>> Hi Petr, >>>>> >>>>> I didn't make a line-to-line comparison, but overall the new code looks good to me. Note that I'd leave the comment at old lines 176-179 as is for clarity. >>>>> >>>>> PS. I assume all clipboard tests pass after this fix. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 3/18/2014 12:17 PM, Petr Pchelko wrote: >>>>>> Hello, AWT Team. >>>>>> >>>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8037560 >>>>>> The fix: http://cr.openjdk.java.net/~pchelko/9/8037560/webrev/ >>>>>> >>>>>> Recently I've tried to fix our clipboard tests and make a proper implementation of the ClipboardOwner notifications on Mac OS X. >>>>>> However this appeared to be impossible without any over-complex solution due to Cocoa restrictions. By the way I've done a big >>>>>> clean-up of the Clipboard native code which would be a pity to throw away. So could you please review this clean-up fix. >>>>>> >>>>>> What I'm doing is replacing the selector-based invocations with block-based, so the source shrinks quite a lot. >>>>>> >>>>>> With best regards. Petr. >>>>>> >>>>>> -- Best regards, Sergey. From petr.pchelko at oracle.com Wed Apr 2 11:18:26 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 2 Apr 2014 15:18:26 +0400 Subject: [9] Review Request: JDK-8036112: JColorChooser throws a NPE when applet with static reference is reloaded In-Reply-To: <533BAFE6.8080006@oracle.com> References: <533A9CBA.2090107@oracle.com> <533AA03D.1040509@oracle.com> <533BAFE6.8080006@oracle.com> Message-ID: <6A650FF6-D662-4B35-BAC8-82E0DD82AE77@oracle.com> Hello, Dmitry. You are changing the contract of the getSystemEventQueueImplPP method in such a way that it could mask real bugs and security issues. Now we are relying on such NPEs to spot existent problems in our code, but with your fix the problems could be unnoticed, just the code would be run on a wrong thread which is VERY hard to find. I understand that this looks like an only solution, but I think it's better to live with the JColorChooser bug than to hide AppContext problems. I suggest closing this bug as Not an Issue, because the client code is buggy - the static initializer is called not on the EDT, so the swing component in created off EDT. This violates the swing threading contract. I've added David DeHaven to this review as he could provide us some expertise in the deploy side of the issue. David, could you please clarify why the applet class is not reloaded by the VM when the applet page is restarted? Isn't it a bug? Shouldn't the refreshed applet be run from scratch, like a whole different application? With best regards. Petr. On 02.04.2014, at 10:36, dmitry markov wrote: > Hi, Sergey, > > Please find my answer inline. > > Thanks, > Dmitry > On 01/04/2014 15:17, Sergey Bylokhov wrote: >> Hi, Dmitry. >> This means that the wrong EDT will be used for some components. >> The situation is strange. We have appcontext and probably some components, which belongs to it, but there is no appropriate EDT. Why? Should we recreate it? > This situation is typical for the applets which have some AWT or Swing components as a static fields (see simple example in https://bugs.openjdk.java.net/browse/JDK-8036112 ). The static field is created only once when the applet's code is loaded. All works well for the first execution. However, if the web page is refreshed, (i.e. F5 is pressed), the Java Plugin destroys the applet and starts it again. The static fields stay untouched since they should be the same for all instances of the applet's class. So the static AWT/Swing component has AppContext which points to not existed EventQueue object, since it has gone during applet's relaunch. > Of course we can try to re-create AppContext during applet's relaunch, but I do not think that's a good idea. In this case we have to go through all static fields and find out the components whose AppContext should be changed. But it may take a lot of time and significantly increase the applet's relaunch time, since the structure of static field may be quite complex. >> And i think appContext.getAppContext() can be null too. >> >> >> On 4/1/14 3:02 PM, dmitry markov wrote: >>> Hello, >>> >>> Could you review the fix for jdk9, please? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8036112 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8036112/jdk9/webrev.00/ >>> >>> Problem description: the EventQueue object stored in AppContext for static fields of an applet becomes null after the refresh of the web page. This may cause a NPE in swing/awt code. >>> >>> Fix: The method SunToolkit.getSystEmeventQueueImplPP(AppContext appContext) should be modified. If the EventQueue from the passed AppContext is null, the method will retrieve the EventQueue from the default AppContext. >>> >>> Thanks, >>> Dmitry >>> >> >> >> -- >> Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.pchelko at oracle.com Wed Apr 2 11:20:51 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 2 Apr 2014 15:20:51 +0400 Subject: [9] Review Request: JDK-8036112: JColorChooser throws a NPE when applet with static reference is reloaded In-Reply-To: <6A650FF6-D662-4B35-BAC8-82E0DD82AE77@oracle.com> References: <533A9CBA.2090107@oracle.com> <533AA03D.1040509@oracle.com> <533BAFE6.8080006@oracle.com> <6A650FF6-D662-4B35-BAC8-82E0DD82AE77@oracle.com> Message-ID: <3BF5D0F0-ADA6-4176-BD9F-21A99BFBD272@oracle.com> [Added David] Sorry, I forgot to actually add David last time. With best regards. Petr. On 02.04.2014, at 15:18, Petr Pchelko wrote: > Hello, Dmitry. > > You are changing the contract of the getSystemEventQueueImplPP method in such a way that it could mask real bugs and security issues. > Now we are relying on such NPEs to spot existent problems in our code, but with your fix the problems could be unnoticed, just the code > would be run on a wrong thread which is VERY hard to find. I understand that this looks like an only solution, but I think it's better to live with > the JColorChooser bug than to hide AppContext problems. > > I suggest closing this bug as Not an Issue, because the client code is buggy - the static initializer is called not on the EDT, so the swing > component in created off EDT. This violates the swing threading contract. > > I've added David DeHaven to this review as he could provide us some expertise in the deploy side of the issue. > David, could you please clarify why the applet class is not reloaded by the VM when the applet page is restarted? > Isn't it a bug? Shouldn't the refreshed applet be run from scratch, like a whole different application? > > With best regards. Petr. > > On 02.04.2014, at 10:36, dmitry markov wrote: > >> Hi, Sergey, >> >> Please find my answer inline. >> >> Thanks, >> Dmitry >> On 01/04/2014 15:17, Sergey Bylokhov wrote: >>> Hi, Dmitry. >>> This means that the wrong EDT will be used for some components. >>> The situation is strange. We have appcontext and probably some components, which belongs to it, but there is no appropriate EDT. Why? Should we recreate it? >> This situation is typical for the applets which have some AWT or Swing components as a static fields (see simple example in https://bugs.openjdk.java.net/browse/JDK-8036112 ). The static field is created only once when the applet's code is loaded. All works well for the first execution. However, if the web page is refreshed, (i.e. F5 is pressed), the Java Plugin destroys the applet and starts it again. The static fields stay untouched since they should be the same for all instances of the applet's class. So the static AWT/Swing component has AppContext which points to not existed EventQueue object, since it has gone during applet's relaunch. >> Of course we can try to re-create AppContext during applet's relaunch, but I do not think that's a good idea. In this case we have to go through all static fields and find out the components whose AppContext should be changed. But it may take a lot of time and significantly increase the applet's relaunch time, since the structure of static field may be quite complex. >>> And i think appContext.getAppContext() can be null too. >>> >>> >>> On 4/1/14 3:02 PM, dmitry markov wrote: >>>> Hello, >>>> >>>> Could you review the fix for jdk9, please? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8036112 >>>> webrev: http://cr.openjdk.java.net/~dmarkov/8036112/jdk9/webrev.00/ >>>> >>>> Problem description: the EventQueue object stored in AppContext for static fields of an applet becomes null after the refresh of the web page. This may cause a NPE in swing/awt code. >>>> >>>> Fix: The method SunToolkit.getSystEmeventQueueImplPP(AppContext appContext) should be modified. If the EventQueue from the passed AppContext is null, the method will retrieve the EventQueue from the default AppContext. >>>> >>>> Thanks, >>>> Dmitry >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.pekhovskiy at oracle.com Wed Apr 2 11:39:39 2014 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Wed, 02 Apr 2014 15:39:39 +0400 Subject: [9] Request for review: 8019990: IM candidate window appears on the South-East corner of the display. In-Reply-To: <533BEA2C.7090005@oracle.com> References: <533BEA2C.7090005@oracle.com> Message-ID: <533BF6FB.7060909@oracle.com> Hi Andrew, the fix looks good. Regards, Oleg On 02.04.2014 14:45, Andrew Brygin wrote: > Hello, > > could you please review a fix for 8019990? > > bug: https://bugs.openjdk.java.net/browse/JDK-8019990 > webrev: http://cr.openjdk.java.net/~bae/8019990/9/webrev.00/ > > The problem was triggered by the fix for 7024749, which moved > IME messages handling from awt_Component to awt_Frame. Due > to this change, the WM_IME_SETCONTEXT never reaches the applet's > component, and candidate window position is never adjusted. > > Suggested fix reverts a part of the fix for 7024749: messages > WM_IME_SETCONTEXT and WM_IME_NOTIFY are handled in > awt_Component again. > > To prevent the crash described in 7024749, I suggest to check > whether the proxy is enabled before routing messages to it > (see awt_Component.cpp, line 4090). > > I have verified that the suggested change does not trigger any > automatic regression test related to IM. > > Unfortunately, there is no new regression test related to the candidate > window position because this problem can be reproduced in a browser, > but does not appear in applet-based regression tests. > > Please take a look. > > Thanks, > Andrew > > > From alexandr.scherbatiy at oracle.com Wed Apr 2 12:20:02 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 02 Apr 2014 16:20:02 +0400 Subject: [9] Review request for 8038113 [macosx] JTree icon is not rendered in high resolution on Retina In-Reply-To: <5332E0FE.5090807@oracle.com> References: <5332E0FE.5090807@oracle.com> Message-ID: <533C0072.1020306@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8038113/webrev.01/ The CachableJRSUIIcon creates an image twice: in createImage() and in the AquaPainter.paint() methods. The fix paints the icon directly from the AquaPainter.paint() method which uses the properly scaled image. Thanks, Alexandr. On 3/26/2014 6:15 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8038113 > webrev: http://cr.openjdk.java.net/~alexsch/8038113/webrev.00 > > MultiResolution image is used to create resolution variants for the > JTree icons. > > The fix assumes that AquaPainter uses the graphics transform for the > image size calculation > an so depends on the fix for issue 8032667 [macosx] Components > cannot be rendered in > http://mail.openjdk.java.net/pipermail/awt-dev/2014-March/007370.html > > Thanks, > Alexandr. > From Sergey.Bylokhov at oracle.com Wed Apr 2 12:25:33 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 02 Apr 2014 16:25:33 +0400 Subject: [9] Review Request: 8038999 In Java 8 java.awt.datatransfer.DataFlavor.equals is no longer symmetric In-Reply-To: References: Message-ID: <533C01BD.7030706@oracle.com> Hi, Petr. The fix looks good. Can you split 'initialize' line before the push, please. Thanks! On 4/2/14 2:28 PM, Petr Pchelko wrote: > Hello, > > I quick follow-up. Please review a new version here: http://cr.openjdk.java.net/~pchelko/9/8038999/webrev.01/ > > I've used Objects.equals as it looks better. > > With best regards. Petr. > > On 02.04.2014, at 13:19, Petr Pchelko wrote: > >> Hello, AWT Team. >> >> The bug: https://bugs.openjdk.java.net/browse/JDK-8038999 >> The fix: http://cr.openjdk.java.net/~pchelko/9/8038999/webrev/ >> >> After adding HTML data flavors the equals is not symmetric any more. I've also updated the hashCode, to avoid unnecessary hash collisions. >> Also I've fixed an annoying broken javadoc link.. >> >> With best regards. Petr. -- Best regards, Sergey. From petr.pchelko at oracle.com Wed Apr 2 12:37:19 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 2 Apr 2014 16:37:19 +0400 Subject: [9] Review request for 8038113 [macosx] JTree icon is not rendered in high resolution on Retina In-Reply-To: <533C0072.1020306@oracle.com> References: <5332E0FE.5090807@oracle.com> <533C0072.1020306@oracle.com> Message-ID: Hello, Alexander. Could you please add the @Override to the paintIcon method. Also I suggest to reuse the paintIcon in the createIcon. With best regards. Petr. On 02.04.2014, at 16:20, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8038113/webrev.01/ > > The CachableJRSUIIcon creates an image twice: in createImage() and in the AquaPainter.paint() methods. > > The fix paints the icon directly from the AquaPainter.paint() method which uses the properly scaled image. > > Thanks, > Alexandr. > > On 3/26/2014 6:15 PM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8038113 >> webrev: http://cr.openjdk.java.net/~alexsch/8038113/webrev.00 >> >> MultiResolution image is used to create resolution variants for the JTree icons. >> >> The fix assumes that AquaPainter uses the graphics transform for the image size calculation >> an so depends on the fix for issue 8032667 [macosx] Components cannot be rendered in >> http://mail.openjdk.java.net/pipermail/awt-dev/2014-March/007370.html >> >> Thanks, >> Alexandr. >> > From Sergey.Bylokhov at oracle.com Wed Apr 2 13:08:15 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 02 Apr 2014 17:08:15 +0400 Subject: [9] Review Request: JDK-6463901 Either generify or deprecate sun.awt.EventListenerAggregate In-Reply-To: <1996BC12-9D64-4B9B-A863-AEFADB2CD34C@oracle.com> References: <8C33BAAC-1313-4901-B6B8-AFA892FEF215@oracle.com> <532860E2.2040305@oracle.com> <0B77BE6C-CF63-4CCB-9052-A049667E506A@oracle.com> <53286A7A.1090902@oracle.com> <53289971.1090109@oracle.com> <1996BC12-9D64-4B9B-A863-AEFADB2CD34C@oracle.com> Message-ID: <533C0BBF.9050101@oracle.com> Hi, Petr. The fix looks good. On 3/19/14 12:44 PM, Petr Pchelko wrote: > Hello, Anthony, Sergey. > > Thank you for the review. > >> Now that the flavorListeners is never null, I believe that the condition should check the value of currentDataFlavors, rather than rely on emptiness of the listeners collection: note that there's removeListener method, so the collection may become empty again, and we don't want to reinitialize the currentDataFlavors for the second time. > I'm now initializing it in the constructor, the same time as the list is initialized. > >> As for the Set vs. List issue, note that Set implementations generally do not guarantee a particular iteration order - it may change after adding/removing listeners. This is particularly true for hash-based collections. So if we use a HashSet, listeners added by other code could be executed in different order at different times which could confuse some applications (maybe?). Since we don't expect a large number of listeners to be added to the collection, I don't think that removing a listener would be a bottle-neck (and this is the only operation that actually benefits from using HashSet in this code). So personally, I'd choose a List instead. But I don't have a strong opinion on this. > I don't think the iteration order would have any effect on the applications. The only reason I'm choosing a Set is to avoid duplicated notifications in case 2 identical listeners were accidentally added. It's actually would be a bug in the client code, so I'm OK to replace the Set with the List if you think it would be better. > > With best regards. Petr. > > On 18.03.2014, at 23:07, Anthony Petrov wrote: > >> Hi Petr, >> >>> 259 if (flavorListeners.isEmpty()) { >>> 260 currentDataFlavors = getAvailableDataFlavorSet(); >>> >>> 261 } >>> 262 flavorListeners.add(listener); >> Now that the flavorListeners is never null, I believe that the condition should check the value of currentDataFlavors, rather than rely on emptiness of the listeners collection: note that there's removeListener method, so the collection may become empty again, and we don't want to reinitialize the currentDataFlavors for the second time. >> >> As for the Set vs. List issue, note that Set implementations generally do not guarantee a particular iteration order - it may change after adding/removing listeners. This is particularly true for hash-based collections. So if we use a HashSet, listeners added by other code could be executed in different order at different times which could confuse some applications (maybe?). Since we don't expect a large number of listeners to be added to the collection, I don't think that removing a listener would be a bottle-neck (and this is the only operation that actually benefits from using HashSet in this code). So personally, I'd choose a List instead. But I don't have a strong opinion on this. >> >> -- >> best regards, >> Anthony >> >> On 3/18/2014 7:47 PM, Sergey Bylokhov wrote: >>> On 3/18/14 7:44 PM, Petr Pchelko wrote: >>>> Hello, Sergey. >>>> >>>> Thank you for the review. >>>> The updated version is located here: >>>> http://cr.openjdk.java.net/~pchelko/9/6463901/webrev.01/ >>>> >>>> It addresses both of your comments. >>> I am curious why Set and not a List(ArrayList)? >>>> With best regards. Petr. >>>> >>>> On 18.03.2014, at 19:06, Sergey Bylokhov >>>> wrote: >>>> >>>>> Hi, Petr. >>>>> >>>>> A few notes: >>>>> >>>>> 314 if (prevDataFlavors != null && currentDataFlavors != null >>>>> 315 && prevDataFlavors.equals(currentDataFlavors)) { >>>>> 316 return; >>>>> 317 } >>>>> >>>>> I suppose we should return in case both of them will be null? >>>>> Objects.equals should be a little bit more readable here. >>>>> >>>>> >>>>> 440 flavorListeners.stream() >>>>> 441 .filter(Objects::nonNull) >>>>> 442 .forEach(listener -> >>>>> SunToolkit.postEvent(appContext, >>>>> 443 new PeerEvent(this, >>>>> 444 () -> >>>>> listener.flavorsChanged(new FlavorEvent(SunClipboard.this)), >>>>> 445 PeerEvent.PRIORITY_EVENT))); >>>>> >>>>> here is a place where we can reformat it to be more readable. >>>>> >>>>> On 18.03.2014 18:34, Petr Pchelko wrote: >>>>>> Hello, AWT Team. >>>>>> >>>>>> Please review the fix for the issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-6463901 >>>>>> The fix is available at: >>>>>> http://cr.openjdk.java.net/~pchelko/9/6463901/webrev/ >>>>>> >>>>>> The bug states that we should deprecate or generify the >>>>>> EventListenerAggregate class. >>>>>> However it's an internal class in sun.awt package so we could remove >>>>>> it. >>>>>> >>>>>> I've used grep on JDK source to verify that this class is not used >>>>>> any more. >>>>>> Clipboard regression, functional and JCK tests run fine. >>>>>> >>>>>> With best regards. Petr. >>>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Apr 2 15:01:14 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 02 Apr 2014 19:01:14 +0400 Subject: [9] Request for review: 8019990: IM candidate window appears on the South-East corner of the display. In-Reply-To: <533BEA2C.7090005@oracle.com> References: <533BEA2C.7090005@oracle.com> Message-ID: <533C263A.9080105@oracle.com> Hi, Andrew. The fix looks good. On 4/2/14 2:45 PM, Andrew Brygin wrote: > Hello, > > could you please review a fix for 8019990? > > bug: https://bugs.openjdk.java.net/browse/JDK-8019990 > webrev: http://cr.openjdk.java.net/~bae/8019990/9/webrev.00/ > > The problem was triggered by the fix for 7024749, which moved > IME messages handling from awt_Component to awt_Frame. Due > to this change, the WM_IME_SETCONTEXT never reaches the applet's > component, and candidate window position is never adjusted. > > Suggested fix reverts a part of the fix for 7024749: messages > WM_IME_SETCONTEXT and WM_IME_NOTIFY are handled in > awt_Component again. > > To prevent the crash described in 7024749, I suggest to check > whether the proxy is enabled before routing messages to it > (see awt_Component.cpp, line 4090). > > I have verified that the suggested change does not trigger any > automatic regression test related to IM. > > Unfortunately, there is no new regression test related to the candidate > window position because this problem can be reproduced in a browser, > but does not appear in applet-based regression tests. > > Please take a look. > > Thanks, > Andrew > > > -- Best regards, Sergey. From petr.pchelko at oracle.com Wed Apr 2 15:02:11 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 2 Apr 2014 19:02:11 +0400 Subject: [9] Review Request: 7124250 [macosx] JOptionPane dialogs show wrong icons Message-ID: Hello, AWT team. Please review a step 1 fix for the issue: https://bugs.openjdk.java.net/browse/JDK-7124250 The fix is here: http://cr.openjdk.java.net/~pchelko/9/7124250/webrev/ In case Java is not installed we've requested an icon that Finder would've used for the folder where the java executable is located. I have no idea why this was done, I've tested this fix with 10.8 and 10.9, Oracle JDK and OpenJDK, with simple apps, applets, JavaWS and bundled apps. I've run Netbeans and Idea on top of the JDK with the fix and could not find any regressions, so I propose to remove the suspicious code. After this is fixed I'll file a new bug against the test, because it is wrong - it does not take into account that the OpenJDK and OracleJDK icons are different, also golden images should be updated. With best regards. Petr. From Sergey.Bylokhov at oracle.com Wed Apr 2 15:07:08 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 02 Apr 2014 19:07:08 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <533A81AA.6050200@oracle.com> References: <53392A07.8060702@oracle.com> <53393F56.50501@oracle.com> <7C52E68B-B5B9-440E-9C4A-8C2F7E8B6BC0@oracle.com> <533956D9.4020306@oracle.com> <5339727F.5000109@oracle.com> <533A81AA.6050200@oracle.com> Message-ID: <533C279C.8020007@oracle.com> On 4/1/14 1:06 PM, Dmitriy Ermashov wrote: > Hi, Sergey > > On 31.03.2014 17:49, Sergey Bylokhov wrote: >> Hi, Dmitriy. >> Do I understand correctly that these methods will be added to the >> Robot class in jdk9? > Yes, it is a current plan. Then why you did not apply these changes to the Robot class itself? >> A few notes: >> - Different javadoc formatting for different methods. >> - There is no information about exceptions. At least waitForIdle >> will throw an exception if will be called on edt. > 2All: please, review the latest version of changeset: > http://cr.openjdk.java.net/~yan/8038631/webrev.02/ - javadoc formatting still different. - you cannot use non public realSync method name in the public documentation. - Probably it will make sense to set syncDelay via system property and get rid setters? In this case delay can be controlled outside of the test itself. - It would be good to make some research in internet, what methods can be implemented as well.(like drag, etc). >> >> On 31.03.2014 15:51, Dmitriy Ermashov wrote: >>> Hi, >>> >>> Please, review the latest version of changeset for: >>> https://bugs.openjdk.java.net/browse/JDK-8038631 >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~yan/8038631/webrev.01/ >>> >>> >>> On 31.03.2014 14:15, Petr Pchelko wrote: >>>>>> 4. The default value for realSync additional delay doesn't seem >>>>>> enough. We normally use 500 ms as the frame creation and first >>>>>> draw could take more time. >>>>> We have to use small delay between mousePress and mouseRelease >>>>> events to emulate real mouse click event. And larger delay can be >>>>> put after mouseRelease call, for ex. 500 ms, as you wrote. >>>>> Don't you mind of this solution? >>>> And couldn't you reuse DEFAULT_SPEED for sleeping in mouseClick? >>>> The comment states it's used there but it's not.. >>>> >>>>>> 5. The click method could be more consistent with others if >>>>>> called "mouseClick". No strong opinion on this. >>>>> For now we have several hundreds of functional tests, most of them >>>>> use method named click(). It seems more reasonable to create >>>>> method click() and use it than search the usage of it in all tests >>>>> and fix to mouseClick() call. >>>> Ok, no problem. I'm fine either way. >>>> >>>> With best regards. Petr. >>>> >>>> On 31.03.2014, at 14:11, Dmitriy Ermashov >>>> wrote: >>>> >>>>> On 31.03.2014 13:12, Petr Pchelko wrote: >>>>>> Hello, Dmitry. >>>>>> >>>>>> Some comments: >>>>>> >>>>>> 1. The name RobotWrapper does not fit in my opinion. The >>>>>> "Wrapper" is more useful for delegation not extension and it >>>>>> feels like you should pass the normal Robot to the wrapper >>>>>> constructor.. I think something like "ExtendedRobot" would feel >>>>>> better. This is my personal preference so it's arguable. >>>>> No objections. Will rename it to ExtendedRobot. >>>>>> 2. I'm not sure I understand why is this location of the util >>>>>> works? in JavaDoc you state that it should be included from >>>>>> regtesthelpers but you put it to the test lib. Is it some feature >>>>>> of jtreg I'm not aware of? >>>>> Will fix in next version of webrev. >>>>>> 3. Could you please use @code instead of >>>>> Will fix in next version of webrev. >>>>>> 4. The default value for realSync additional delay doesn't seem >>>>>> enough. We normally use 500 ms as the frame creation and first >>>>>> draw could take more time. >>>>> We have to use small delay between mousePress and mouseRelease >>>>> events to emulate real mouse click event. And larger delay can be >>>>> put after mouseRelease call, for ex. 500 ms, as you wrote. >>>>> Don't you mind of this solution? >>>>>> 5. The click method could be more consistent with others if >>>>>> called "mouseClick". No strong opinion on this. >>>>> For now we have several hundreds of functional tests, most of them >>>>> use method named click(). It seems more reasonable to create >>>>> method click() and use it than search the usage of it in all tests >>>>> and fix to mouseClick() call. >>>>>> 6. "Clicks mouse button 1 with the default pause between Press >>>>>> and Release." this statement does not seem clear. How to override >>>>>> the default value? Why does this method click with the default >>>>>> pause and the previous one does not? or does it? It's not clear >>>>>> from the JavaDoc >>>>> I believe, javadoc should be fixed. >>>>> Will fix in next version of webrev. >>>>>> 7. Could you please add @Override annotations where appropriate >>>>>> (waitForIdle for example) >>>>> Will fix in next version of webrev. >>>>>> 8. "public void type" may be keyType would be better? For >>>>>> consistency with other methods. >>>>> Same as 5. >>>>>> 9. Could the method you are using for converting KeyChar to >>>>>> KeyCode be replaces with KeyEvent.getExtendedKeyCodeForChar? Or >>>>>> KeyStroke API? This switch is ugly and it would be awesome to >>>>>> replace it. >>>>> Will fix in next version of webrev. >>>>>> Thank you. >>>>>> With best regards. Petr. >>>>>> >>>>>> On 31.03.2014, at 12:40, Dmitriy Ermashov >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> Please, review the changeset for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8038631 >>>>>>> >>>>>>> Webrev is here: >>>>>>> http://cr.openjdk.java.net/~yan/8038631/webrev.00 >>>>>>> >>>>>>> Presently for testing of JDK client we use test suites of two >>>>>>> kinds, historically called regression and functional (internal). >>>>>>> In JDK9 we plan an attempt to unify them and ultimately get rid >>>>>>> of the functional suites. >>>>>>> >>>>>>> One of the first technical problems in this refactoring attempt >>>>>>> is a multitude of the java.awt.Robot wrappers. There are some >>>>>>> really elaborate libraries enhansing Robot which all we cannot >>>>>>> and should not port to jtreg. >>>>>>> >>>>>>> Fortunately, test writers almost never use complex features of >>>>>>> these wrappers. So here's our plan: >>>>>>> (1) describe the real practice of the robot use in the >>>>>>> functional tests (please don't worry, that's out of scope of >>>>>>> this request); >>>>>>> (2) write a minimal useful RobotWrapper extending java.awt.Robot; >>>>>>> (3) start functional tests refactoring; >>>>>>> (4) cautiously move enhancements to the java.awt.Robot trying >>>>>>> not to break backward compatibility of thousands existing tests. >>>>>>> For instance, waitForIdle should use realSync() but there >>>>>>> definitely >>>>>>> are plenty of tests using it on EDT: or maybe not -- we should >>>>>>> spent some time for background research in parallel with (3). >>>>>>> >>>>>>> -- >>>>>>> Thanks, >>>>>>> Dima >>>>>>> >>>>> -- >>>>> Thanks, >>>>> Dima >>>>> >>> >> >> > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.petrov at oracle.com Wed Apr 2 19:13:55 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 Apr 2014 23:13:55 +0400 Subject: [9] Review Request: 8038999 In Java 8 java.awt.datatransfer.DataFlavor.equals is no longer symmetric In-Reply-To: References: Message-ID: <533C6173.7080702@oracle.com> Looks good to me. -- best regards, Anthony On 4/2/2014 2:28 PM, Petr Pchelko wrote: > Hello, > > I quick follow-up. Please review a new version here: http://cr.openjdk.java.net/~pchelko/9/8038999/webrev.01/ > > I've used Objects.equals as it looks better. > > With best regards. Petr. > > On 02.04.2014, at 13:19, Petr Pchelko wrote: > >> Hello, AWT Team. >> >> The bug: https://bugs.openjdk.java.net/browse/JDK-8038999 >> The fix: http://cr.openjdk.java.net/~pchelko/9/8038999/webrev/ >> >> After adding HTML data flavors the equals is not symmetric any more. I've also updated the hashCode, to avoid unnecessary hash collisions. >> Also I've fixed an annoying broken javadoc link.. >> >> With best regards. Petr. > From james.graham at oracle.com Wed Apr 2 22:23:23 2014 From: james.graham at oracle.com (Jim Graham) Date: Wed, 02 Apr 2014 15:23:23 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: <53343914.6090004@oracle.com> References: <52D51764.8020103@oracle.com> <52DF2F98.3030503@oracle.com> <52F4BCEB.9040702@oracle.com> <52F5782A.9060300@oracle.com> <52FB7E3E.6050000@oracle.com> <52FC14EC.9080503@oracle.com> <53037D3D.80709@oracle.com> <5307E71E.50607@oracle.com> <530F3592.40600@oracle.com> <532B00AD.1000704@oracle.com> <532B7EC5.9000206@oracle.com> <532C4DD7.1080804@oracle.com> <532CD202.5070508@oracle.com> <53302A8E.6090107@oracle.com> <53343914.6090004@oracle.com> Message-ID: <533C8DDB.5000406@oracle.com> Hi Alexandr, The back and forth is getting confusing here, so I thought I'd try to summarize and start fresh(ish): 1. We need to support @2x internally for MacOS compatibility (done). 2. We will need to support _DPI images for Win-DPI compatibility (TBD). 3. Customers may have their own collection of images to bundle together into an MR image (working on that here). What is the push for this? Is this simply parity with Mac interfaces? 4. Customers may want to synthetically generate images at arbitrary resolutions (a variation that is impacting this solution). What is the push for this? 5. I'm guessing that customers might want to override the logic to choose from among multiple resolutions. That came from me based on seeing Mac and Win using different selection logic and our history of developers split between those wanting cross-platform consistency and those wanting consistency with native apps on each platform. Also, the needs of an animator may differ from the needs of a resolution-settable-document editor as to how dynamically the images shift between resolution variants. Is that a fair summary of all of the considerations so far, or did I miss something? ...jim On 3/27/14 7:43 AM, Alexander Scherbatiy wrote: > > Below are some thoughts about TK.createMRImage(...) method > > On 3/24/2014 4:52 PM, Alexander Scherbatiy wrote: >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8029339/webrev.03/ >> >> - baseImageWidth/Height arguments are added to the >> getResolutionVariant(...) method >> - dest image sizes are reverted to included DPI scale >> - AbstractMultiResolutionImage is added. It needs only to implement >> only 3 methods from the AbstractMultiResolutionImage class >> to create a custom multi-resolution image. For example: >> >> On 3/22/2014 3:57 AM, Jim Graham wrote: >>> >>> Your code example below can be expressed as an implementation of the >>> single-method, lambda-compatible interface that expresses just the >>> getRV() method. They could easily do: >>> >>> final Image baseImage = ...; >>> TK.createMRImage(new RVInterface() { >>> public Image getRV(...) { >>> // calculate rvWidth and rvHeight >>> // look up rvWidth/rvHeight in a database of images >>> // possibly contruct a new image >>> return rvImage; >>> } >>> }, baseImage); >>> > The RVInterface mixes the logic that construct an image and > chooses the necessary resolution variant. > It is ok if a developer always implements this interface. If it > needs to have DPI/Transform/Platform aware RVInterface the image > construction logic should be separated. > > Does TK.createMRImage() method implies that Platform aware logic > should be used for a resolution-variant choosing? > If so, may be general createMRImage() can be placed in the > ImageResolutionHelper. >>> The main issue I see is if you might want the newly constructed >>> variants to appear in the List returned from the getVariants() >>> method. I'm not sure what value that would have beyond simply >>> returning the base media that the object uses from which to construct >>> its variants...? > > It can be solved by using something like array of image sizes or > other seeds and a mapper that can create an image from the given seed. > > It can look like: > ------------------------- > public class ImageResolutionHelper { > public interface RVChooser { > > public Image getRV( > float logicalDPIX, float logicalDPIY, > float baseImageWidth, float baseImageHeight, > float destImageWidth, float destImageHeight, > final Image... resolutionVariants); > } > > public static final RVChooser DPI_AWARE = ...; > public static final RVChooser TRANSFORM_AWARE = ...; > > // resolutionVariants is an array of sorted by width/height images > static Image createMRImage(final RVChooser rvChooser, > final int baseImageIndex, final Image... > resolutionVariants) { ... } > > // sorted by width/height images should be generated from seeds > static Image createMRImage(final RVChooser rvChooser, > final Type baseImageSeed, final Function > mapper, final Type... rvSeeds) {...} > } > > public abstract class Toolkit { > public abstract Image createMRImage(int baseImageIndex, Image... > resolutionVariants); // Platform aware rv chooser is used > public abstract RVChooser getPlatformRVChooser() ; > } > -------------------------- > Thanks, > Alexandr. > >>> >>>> I think it is better to provide both the MultiResolutionImage and >>>> its implementation based on the given resolution variants array. >>> >>> It occurs to me that even if we don't go with a lambda-factory-based >>> approach like what I'm describing, it might make sense to provide a >>> baseMR implementation that they can subclass to keep them from trying >>> to subclass off of BufferedImage instead. I really would like to >>> avoid "custom MR images are subclasses of BufImg" if we can as I >>> think the mix of concepts is a little jarring... >>> >>> ...jim >>> >>>> The implementation could look like: >>>> --------------------------------- >>>> public class CustomMultiResolutionImage extends Image implements >>>> MultiResolutionImage { >>>> >>>> int baseImageIndex; >>>> Image[] resolutionVariants; >>>> >>>> public CustomMultiResolutionImage(int baseImageIndex, >>>> Image... resolutionVariants) { >>>> this.baseImageIndex = baseImageIndex; >>>> this.resolutionVariants = resolutionVariants; >>>> } >>>> >>>> @Override >>>> public int getWidth(ImageObserver observer) { >>>> return getBaseImage().getWidth(null); >>>> } >>>> >>>> @Override >>>> public int getHeight(ImageObserver observer) { >>>> return getBaseImage().getHeight(null); >>>> } >>>> >>>> @Override >>>> public ImageProducer getSource() { >>>> return getBaseImage().getSource(); >>>> } >>>> >>>> @Override >>>> public Graphics getGraphics() { >>>> return getBaseImage().getGraphics(); >>>> } >>>> >>>> @Override >>>> public Object getProperty(String name, ImageObserver observer) { >>>> return getBaseImage().getProperty(name, observer); >>>> } >>>> >>>> @Override >>>> public Image getResolutionVariant(float logicalDPIX, float >>>> logicalDPIY, >>>> float destinationImageWidth, float >>>> destinationImageHeight) { >>>> // calculate resolution variant width/height >>>> return getResolutionVariant(rvWidth, rvHeight); >>>> } >>>> >>>> @Override >>>> public List getResolutionVariants() { >>>> return Arrays.asList(resolutionVariants); >>>> } >>>> >>>> private Image getResolutionVariant(float rvWidth, float >>>> rvHeight) { >>>> // return a resolution variant based on the given width and >>>> height >>>> } >>>> >>>> private Image getBaseImage() { >>>> return resolutionVariants[baseImageIndex]; >>>> } >>>> } >>>> --------------------------------- >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> Then we provide one of these from TK.get/createImage() when the >>>>> platform detects @2x, or Win8-style variants. >>>>> >>>>> For custom images we provide TK.createMRImage(lambda getRV, Image >>>>> variants...) and TK.createMRImage(Image variants...); >>>>> >>>>> Since the get method is just bookkeeping, I don't see them >>>>> needing to override it, so the getRV() method is really the only thing >>>>> they might want to override, and we can tie into the new Lambda >>>>> capabilities by making a single-method interface for it that they >>>>> supply in a factory method. >>>>> >>>>> I realize that the interface you created is more fundamentally OO, but >>>>> the Image class has always been special in this regard in the AWT >>>>> ecosystem (in so far as we do not support someone implementing their >>>>> own Image subclass even though it is technically possible). Because of >>>>> this special nature of Image, we end up with the situation that if >>>>> someone were given a need to create a subclass of Image, then they >>>>> would turn to BufImg as their superclass even though BufImg is >>>>> essentially an implementation-specific leaf node on the Image class >>>>> hierarchy. This approach with a factory method to create an internal >>>>> subclass of the new MRI class mirrors the existing cases of Image >>>>> objects that come from factories as well. >>>>> >>>>> Thoughts? >>>>> >>>>> ...jim >>>>> >>>>> >>>>> On 3/20/14 7:52 AM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the updated version of the fix: >>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.01/ >>>>>> >>>>>> - The "getResolutionVariant(int width, int height)" method from >>>>>> MultiResolutionImage class is changed to >>>>>> Image getResolutionVariant(float logicalDPIX, float logicalDPIY, >>>>>> float width, float height, AffineTransform transform); >>>>>> >>>>>> - sun.awt.image.ImageResolutionHelper class is added. The >>>>>> sun.awt.image.MultiResolutionToolkitImage and >>>>>> sun.awt.image.MultiResolutionBufferedImage classes are used >>>>>> PLATFORM ImageResolutionHelper. >>>>>> >>>>>> The MultiResolutionImage interface implementation could look like: >>>>>> ------------------------------ >>>>>> public class CustomMultiResolutionImage extends BufferedImage >>>>>> implements >>>>>> MultiResolutionImage { >>>>>> >>>>>> private final Image[] resolutionVariants; >>>>>> >>>>>> public CustomMultiResolutionImage(int baseIndex, Image... >>>>>> images) { >>>>>> super(images[baseIndex].getWidth(null), >>>>>> images[baseIndex].getHeight(null), >>>>>> BufferedImage.TYPE_INT_RGB); >>>>>> this.resolutionVariants = images; >>>>>> Graphics g = getGraphics(); >>>>>> g.drawImage(images[baseIndex], 0, 0, null); >>>>>> g.dispose(); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>>> logicalDPIY, >>>>>> float width, float height, AffineTransform transform) { >>>>>> return getResolutionVariant(logicalDPIX * width, >>>>>> logicalDPIY * >>>>>> height); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public List getResolutionVariants() { >>>>>> return Arrays.asList(resolutionVariants); >>>>>> } >>>>>> >>>>>> public Image getResolutionVariant(double width, double height) { >>>>>> for (Image image : resolutionVariants) { >>>>>> if (width <= image.getWidth(null) && height <= >>>>>> image.getHeight(null)) { >>>>>> return image; >>>>>> } >>>>>> } >>>>>> return this; >>>>>> } >>>>>> } >>>>>> ------------------------------ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 2/27/2014 4:54 PM, Alexander Scherbatiy wrote: >>>>>>> On 2/22/2014 3:54 AM, Jim Graham wrote: >>>>>>>> Hi Alexandr, >>>>>>>> >>>>>>>> On 2/18/14 7:33 AM, Alexander Scherbatiy wrote: >>>>>>>>> Hi Jim, >>>>>>>>> >>>>>>>>> Let's divide the discussion into two part. >>>>>>>>> >>>>>>>>> 1. Where it is better to hold resolution variants? >>>>>>>>> Putting resolution variants in Image class brings some >>>>>>>>> questions like: >>>>>>>>> - Some type of images do not need to have resolution variants >>>>>>>>> - Should resolution variants have the same type as the base >>>>>>>>> image? >>>>>>>>> - getResolutionVariants() method can return copy of the >>>>>>>>> original >>>>>>>>> list >>>>>>>>> so add/removeRV methods should be also added. >>>>>>>>> >>>>>>>>> There are pros and cons for placing resolution variants to >>>>>>>>> Image >>>>>>>>> class or to a separate intreface. >>>>>>>> >>>>>>>> I agree that this could be a separate interface. In my examples >>>>>>>> below I was just sticking them inside an "Image{}" to show where >>>>>>>> they >>>>>>>> lived in the set of involved objects, not a specific recommendation >>>>>>>> that they actually be new methods on the base class itself. I >>>>>>>> probably should have put a comment there about that. >>>>>>>> >>>>>>>> With respect to add/remove - that is assuming a need for manual >>>>>>>> construction of an image set, right? Forgive me if I'm forgetting >>>>>>>> something, but I seem to recall that manual Multi-Res images was >>>>>>>> proposed as a way for developers to introduce @2x support >>>>>>>> themselves, >>>>>>>> but if we are internally managing @2x and -DPI variants for them, >>>>>>>> then I'm not sure if there is actual developer need to manually >>>>>>>> construct their own. Am I forgetting something? >>>>>>> The NSImage has addRepresentation/removeRepresentation methods to >>>>>>> work with image representations on Mac OS X. >>>>>>> The java.awt.Image class should provide similar functionality to >>>>>>> have the possibilities as Cocoa on HiDPI displays. >>>>>>> >>>>>>>> >>>>>>>>> 2. Using scale factor/image sizes/scaled image sizes to >>>>>>>>> retreive a >>>>>>>>> resolution variant. >>>>>>>>> >>>>>>>>> May be it is better to have a structure that provide all >>>>>>>>> necessary >>>>>>>>> information to query the resolution variant: scale factor, >>>>>>>>> draw area >>>>>>>>> width/height, transformed area width/height? >>>>>>>>> >>>>>>>>> For example: >>>>>>>>> --------------------- >>>>>>>>> public interface MultiResolutionImage { >>>>>>>>> >>>>>>>>> interface DrawAreaInfo { >>>>>>>>> >>>>>>>>> float getScaleFactor(); >>>>>>>>> float getAreaWidth(); >>>>>>>>> float getAreaHeight(); >>>>>>>>> float getTransformedAreaWidth(); >>>>>>>>> float getTransformedAreaHeight(); >>>>>>>>> } >>>>>>>>> >>>>>>>>> public Image getResolutionVariant(DrawAreaInfo >>>>>>>>> drawAreaInfo) ; >>>>>>>>> public List getResolutionVariants(); >>>>>>>>> } >>>>>>>>> --------------------- >>>>>>>> >>>>>>>> The problem with a constructor is that this is something that is >>>>>>>> (potentially) done on every drawImage() call, which means we are >>>>>>>> inviting GC into the equation. If we can come up with a simple >>>>>>>> "just >>>>>>>> a couple/3/4 numbers" way to embed that data into a method call >>>>>>>> argument list then we can make this lighter weight. >>>>>>>> >>>>>>>> What about simply having floating point (double) dimensions on the >>>>>>>> rendered size >>>>>>> There should be a way to choose a resolution variant based on >>>>>>> requested drawing size or transformed drawing size. >>>>>>> At least a current transformation should be included too. >>>>>>>> plus a single floating point "logical DPI" for the screen? >>>>>>> There is the ID2D1Factory::GetDesktopDpi method which returns >>>>>>> dpiX and dpiY. >>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316 >>>>>>> >>>>>>> That means that logicalDPIX/Y can have different values. >>>>>>> At least it is described in the >>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/ff684173 >>>>>>> "To get the DPI setting, call the ID2D1Factory::GetDesktopDpi >>>>>>> method. The DPI is returned as two floating-point values, one for >>>>>>> the >>>>>>> x-axis and one for the y-axis. In theory, these values can differ. >>>>>>> Calculate a separate scaling factor for each axis." >>>>>>> >>>>>>> The getResolutionVariant method could look like: >>>>>>> -------------------------------------- >>>>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>>>> logicalDPIY, >>>>>>> float widthX, float widthY, AffineTransform transform); >>>>>>> -------------------------------------- >>>>>>> >>>>>>>> If the image is known (either passed as an argument or the >>>>>>>> method is >>>>>>>> called on the image), then it can provide the original WH. >>>>>>>> >>>>>>>>> The MultiResolutionImage default implementation could allow >>>>>>>>> to use >>>>>>>>> different strategies like scale factor/transfom/OS based >>>>>>>>> to query a resolution variant. The OS based strategy can be >>>>>>>>> used by >>>>>>>>> default. >>>>>>>> >>>>>>>> For Mac policy, all we need is the transformed dimensions, which >>>>>>>> can >>>>>>>> be passed in as FP for generality. For Windows policy, all we need >>>>>>>> is logical DPI for the screen. What other information would we >>>>>>>> need, or would an algorithm like to use, that can't be computed >>>>>>>> from >>>>>>>> those 2 pieces? >>>>>>> The aim is to provide a base class that can be used to create a >>>>>>> MultiResolutionImage like: >>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/diff/ae53ebce5fa3/src/share/classes/sun/awt/image/MultiResolutionBufferedImage.java >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> A developer should be able to implement a custom algorithm to >>>>>>> query a resolution variant. >>>>>>> >>>>>>> It can be done by overriding the getResolutionVariant image: >>>>>>> ----------------------- >>>>>>> Image mrImage = new MultiResolutionBufferedImage(){ >>>>>>> @Override >>>>>>> public Image getResolutionVariant(...) { >>>>>>> // Custom logic here >>>>>>> } >>>>>>> }; >>>>>>> ----------------------- >>>>>>> >>>>>>> Or it can be done by using resolution variant choosers so a >>>>>>> developer can implement custom resolution variant query: >>>>>>> ----------------------- >>>>>>> public class MultiResolutionBufferedImage implements >>>>>>> MultiResolutionImage{ >>>>>>> >>>>>>> interface ResolutionVariantChooser{ >>>>>>> Image getResolutionVariant(dpi, size,..., List >>>>>>> resolutionVariants); >>>>>>> } >>>>>>> ResolutionVariantChooser TRANSFORM_BASED = null; >>>>>>> ResolutionVariantChooser DPI_BASED = null; >>>>>>> >>>>>>> ResolutionVariantChooser rvChooser; >>>>>>> >>>>>>> @Override >>>>>>> public Image getResolutionVariant(dpi, size,...,) { >>>>>>> return rvChooser.getResolutionVariant(dpi, size,..., >>>>>>> getResolutionVariants()); >>>>>>> } >>>>>>> } >>>>>>> ----------------------- >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/13/2014 4:42 AM, Jim Graham wrote: >>>>>>>>>> On 2/12/14 5:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>>> On 2/8/2014 4:19 AM, Jim Graham wrote: >>>>>>>>>>>> The primary thing that I was concerned about was the >>>>>>>>>>>> presence of >>>>>>>>>>>> integers in the API when Windows uses non-integer multiples >>>>>>>>>>> It would make sense to pass real numbers to the >>>>>>>>>>> getResolutionVariant() method if the difference between >>>>>>>>>>> resolution >>>>>>>>>>> variants sizes is 1. >>>>>>>>>>> It seems that it is not a common case. >>>>>>>>>> >>>>>>>>>> I was thinking of other API that is related to this, such as >>>>>>>>>> the API >>>>>>>>>> that queries the scaling factor from a SurfaceManager. I seem to >>>>>>>>>> remember some integer return values in that, but Windows might >>>>>>>>>> have >>>>>>>>>> the answer 1.4 or 1.8, depending on the screen scaling factor >>>>>>>>>> that was >>>>>>>>>> determined from the UI. >>>>>>>>>> >>>>>>>>>> In terms of the getResolutionVariant() method here, those >>>>>>>>>> non-integer >>>>>>>>>> screen scaling factors don't directly impact this API. But, we >>>>>>>>>> have >>>>>>>>>> some issues with the use of integers there from other sources: >>>>>>>>>> >>>>>>>>>> - That API assumes that the caller will determine the pixel size >>>>>>>>>> needed, but the actual media choice is determined with different >>>>>>>>>> techniques on Mac and Windows so this means that the caller will >>>>>>>>>> have >>>>>>>>>> to worry about platform conventions. Is that the right tradeoff? >>>>>>>>>> >>>>>>>>>> - The technique recommended for Mac involves computing the >>>>>>>>>> precise >>>>>>>>>> size desired using the current transform, which may be a floating >>>>>>>>>> point value, so the integer values used in this API are already >>>>>>>>>> approximations and there is no documentation on how to >>>>>>>>>> generate the >>>>>>>>>> proper integer. In particular, the current code in SG2D naively >>>>>>>>>> uses >>>>>>>>>> a cast to integer to determine the values to supply which means a >>>>>>>>>> transformed size of W+0.5 will be truncated to W and the lower >>>>>>>>>> resolution image will be used. Does that conform to Mac >>>>>>>>>> guidelines? Do >>>>>>>>>> they require the truncated size to reach W+1 before the next >>>>>>>>>> size is >>>>>>>>>> used? Passing in float or double values would sidestep all of >>>>>>>>>> that >>>>>>>>>> since then the comparisons would be done with full precision, >>>>>>>>>> but as >>>>>>>>>> long as we can determine a "best practices compatible with all >>>>>>>>>> platforms" rule on how to round to integers, then integers are OK >>>>>>>>>> there. >>>>>>>>>> >>>>>>>>>> - The Windows document you cite below suggests that the >>>>>>>>>> determination >>>>>>>>>> should be made by looking at the Screen DPI and choosing the next >>>>>>>>>> higher media variant based on that screen DPI. They do not >>>>>>>>>> specify >>>>>>>>>> choosing media based on the current transform as is done for >>>>>>>>>> Mac. If >>>>>>>>>> we stick with supplying values that are used to determine which >>>>>>>>>> media >>>>>>>>>> to use, then on Windows we should not take the transform into >>>>>>>>>> account, >>>>>>>>>> but instead query the SurfaceManager for the scale factor and >>>>>>>>>> only >>>>>>>>>> transform by those values (even if the current transform was >>>>>>>>>> manually >>>>>>>>>> overridden to identity). >>>>>>>>>> >>>>>>>>>> There are pros and cons to both approaches. >>>>>>>>>> >>>>>>>>>> Mac ensures that you are always using the best media for any >>>>>>>>>> given >>>>>>>>>> render operation. >>>>>>>>>> >>>>>>>>>> But, Windows ensure more consistency in the face of other >>>>>>>>>> scaling. >>>>>>>>>> >>>>>>>>>> The thing to consider is that if you have a 500x500 image with a >>>>>>>>>> 1000x1000 variant and you rendering it at 500x500 and then >>>>>>>>>> 501x501, >>>>>>>>>> that first jump will be fairly jarring as the scaled version >>>>>>>>>> of the >>>>>>>>>> 1000x1000 will not look precisely like the original 500x500 did. >>>>>>>>>> With >>>>>>>>>> @2x images only, this effect is minimized so the advantage of >>>>>>>>>> always >>>>>>>>>> using "the best media for a given render operation" may >>>>>>>>>> outweigh the >>>>>>>>>> inconsistency issue. But, on Windows where the media are 1.4x or >>>>>>>>>> 1.8x >>>>>>>>>> in size, a downscaled image will start to show more interpolation >>>>>>>>>> noise and so the balance of the two choices may shift more >>>>>>>>>> towards not >>>>>>>>>> wanting a jarring shift. >>>>>>>>>> >>>>>>>>>> We might want one or more of the following: >>>>>>>>>> >>>>>>>>>> - Developer chooses policy (TX_AWARE, DPI_AWARE, ALWAYS_LARGEST, >>>>>>>>>> NONE, >>>>>>>>>> PLATFORM) where the last policy would use TX_AWARE on Mac and >>>>>>>>>> DPI_AWARE on Windows >>>>>>>>>> >>>>>>>>>> - We create our own policy and always use it (TX_AWARE? or >>>>>>>>>> DPI_AWARE?) >>>>>>>>>> >>>>>>>>>> - We create our own policy that dynamically chooses one of the >>>>>>>>>> above >>>>>>>>>> strategies depending on platform or available media or ??? >>>>>>>>>> >>>>>>>>>> - We could create an optional interface for them to install their >>>>>>>>>> own >>>>>>>>>> algorithm as well. I think it would work best as a delegate >>>>>>>>>> interface >>>>>>>>>> that one installs into Image so that it can be used with any >>>>>>>>>> image >>>>>>>>>> without having to subclass (it wouldn't really have much to do >>>>>>>>>> for >>>>>>>>>> BufferedImages or VolatileImages, though): >>>>>>>>>> >>>>>>>>>> class Image { >>>>>>>>>> void setResolutionHelper(ImageResolutionHelper foo); >>>>>>>>>> List getResolutionVariants(); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> or: >>>>>>>>>> >>>>>>>>>> class Graphics { >>>>>>>>>> void setResolutionHelper(ImageResolutionHelper foo); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> or - anywhere else it could be installed more centrally (per App >>>>>>>>>> context)? >>>>>>>>>> >>>>>>>>>> and the interface would be something like one of these variants: >>>>>>>>>> >>>>>>>>>> interface ImageResolutionHelper { >>>>>>>>>> // This version would prevent substituting a random image: >>>>>>>>>> // They have to return an index into the List for that >>>>>>>>>> image... >>>>>>>>>> public int chooseVariant(Image img, double dpi, number w, >>>>>>>>>> number h); >>>>>>>>>> >>>>>>>>>> or: >>>>>>>>>> >>>>>>>>>> // This version would allow substituting an arbitrary image: >>>>>>>>>> public Image getVariant(Image img, double dpi, number w, >>>>>>>>>> number >>>>>>>>>> h); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Since they would be in full control of the policy, though, we >>>>>>>>>> would >>>>>>>>>> unfortunately always have to call this, there would be no more >>>>>>>>>> testing >>>>>>>>>> in SG2D to see "if" we need to deal with DPI, though perhaps we >>>>>>>>>> could >>>>>>>>>> document some internal conditions in which we do not call it for >>>>>>>>>> common cases (but that would have to be well agreed not to get in >>>>>>>>>> the >>>>>>>>>> way of reasonable uses of the API and well documented)? >>>>>>>>>> >>>>>>>>>> Note that we would have to do a security audit to make sure that >>>>>>>>>> random image substitution couldn't allow any sort of "screen >>>>>>>>>> phishing" >>>>>>>>>> exploit. >>>>>>>>>> >>>>>>>>>> ...jim >>>>>>>>>> >>>>>>>>>>>> and also what policy they use for choosing scaled images. >>>>>>>>>>>> >>>>>>>>>>>> I don't see a mention of taking the current transform into >>>>>>>>>>>> account, >>>>>>>>>>>> just physical issues like screen DPI and form factor. They talk >>>>>>>>>>>> about >>>>>>>>>>>> resolution plateaus and in their recommendations section they >>>>>>>>>>>> tell the >>>>>>>>>>>> developer to use a particular property that tells them the >>>>>>>>>>>> screen >>>>>>>>>>>> resolution to figure out which image to load if they are >>>>>>>>>>>> loading >>>>>>>>>>>> manually. There is no discussion about dynamically loading >>>>>>>>>>>> multiple >>>>>>>>>>>> versions of the image based on a dynamic program-applied >>>>>>>>>>>> transform >>>>>>>>>>>> factor as is done on MacOS. >>>>>>>>>>>> >>>>>>>>>>>> Also, they tell developers to draw images to a specific size >>>>>>>>>>>> rather >>>>>>>>>>>> than using auto-sizing. That begs the question as to how they >>>>>>>>>>>> interpret a call to draw an image just using a location in the >>>>>>>>>>>> presence of various DPI factors. >>>>>>>>>>> There is an interesting doc that describes how to write >>>>>>>>>>> DPI-aware >>>>>>>>>>> Win32 applications: >>>>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464646%28v=vs.85%29.aspx >>>>>>>>>>> >>>>>>>>>>> It is suggested to handle WM_DPICHANGED message, load the >>>>>>>>>>> graphic >>>>>>>>>>> that has slightly greater resolution to the current DPI and use >>>>>>>>>>> StretchBlt >>>>>>>>>>> to scale down the image. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ...jim >>>>>>>>>>>> >>>>>>>>>>>> On 2/7/14 3:00 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>> On 1/22/2014 6:40 AM, Jim Graham wrote: >>>>>>>>>>>>>> Hi Alexander, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Before we get too far down the road on this API, I think we >>>>>>>>>>>>>> understand >>>>>>>>>>>>>> the way in which MacOS processes multi-resolution images for >>>>>>>>>>>>>> HiDPI >>>>>>>>>>>>>> screens, but have we investigated the processes that Windows >>>>>>>>>>>>>> uses >>>>>>>>>>>>>> under Windows 8? My impression is that Windows 8 has >>>>>>>>>>>>>> included a >>>>>>>>>>>>>> number of new techniques for dealing with the high resolution >>>>>>>>>>>>>> displays >>>>>>>>>>>>>> that it will run on in the Windows tablet and mobile >>>>>>>>>>>>>> industries >>>>>>>>>>>>>> and >>>>>>>>>>>>>> that these will also come into play as 4K displays (already >>>>>>>>>>>>>> available) >>>>>>>>>>>>>> become more common on the desktop. We should make sure that >>>>>>>>>>>>>> what we >>>>>>>>>>>>>> come up with here can provide native compatibility with >>>>>>>>>>>>>> either >>>>>>>>>>>>>> platform's policies and standard practices. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you've investigated the MS policies I'd like to see a >>>>>>>>>>>>>> summary so >>>>>>>>>>>>>> that we can consider them as we review this API... >>>>>>>>>>>>> There is the Windows Guidelines for scaling to pixel >>>>>>>>>>>>> density: >>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> which says that Windows has automatic resource loading >>>>>>>>>>>>> that >>>>>>>>>>>>> supports >>>>>>>>>>>>> three version of images scaling (100%, 140%, and 180%) >>>>>>>>>>>>> -------------------------------- >>>>>>>>>>>>> Without scaling, as the pixel density of a display device >>>>>>>>>>>>> increases, the >>>>>>>>>>>>> physical sizes of objects on screen get smaller. >>>>>>>>>>>>> When UI would otherwise be too small to touch and when text >>>>>>>>>>>>> gets >>>>>>>>>>>>> too >>>>>>>>>>>>> small to read, >>>>>>>>>>>>> Windows scales the system and app UI to one of the following >>>>>>>>>>>>> scaling >>>>>>>>>>>>> plateaus: >>>>>>>>>>>>> >>>>>>>>>>>>> 1.0 (100%, no scaling is applied) >>>>>>>>>>>>> 1.4 (140% scaling) >>>>>>>>>>>>> 1.8 (180% scaling) >>>>>>>>>>>>> >>>>>>>>>>>>> Windows determines which scaling plateau to use based on the >>>>>>>>>>>>> physical >>>>>>>>>>>>> screen size, the screen resolution, the DPI of the screen, and >>>>>>>>>>>>> form >>>>>>>>>>>>> factor. >>>>>>>>>>>>> >>>>>>>>>>>>> Use resource loading for bitmap images in the app package For >>>>>>>>>>>>> bitmap >>>>>>>>>>>>> images stored >>>>>>>>>>>>> in the app package, provide a separate image for each scaling >>>>>>>>>>>>> factor(100%, 140%, and 180%), >>>>>>>>>>>>> and name your image files using the "scale" naming convention >>>>>>>>>>>>> described >>>>>>>>>>>>> below. >>>>>>>>>>>>> Windows loads the right image for the current scale >>>>>>>>>>>>> automatically. >>>>>>>>>>>>> -------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> The image name convention for the various scales is: >>>>>>>>>>>>> images/logo.scale-100.png >>>>>>>>>>>>> images/logo.scale-140.png >>>>>>>>>>>>> images/logo.scale-180.png >>>>>>>>>>>>> >>>>>>>>>>>>> The 'ms-appx:///images/logo.png' uri is used to load the >>>>>>>>>>>>> image >>>>>>>>>>>>> in an >>>>>>>>>>>>> application. >>>>>>>>>>>>> >>>>>>>>>>>>> If we want to support this in the same way as it is done >>>>>>>>>>>>> for Mac >>>>>>>>>>>>> OS X >>>>>>>>>>>>> the WToolkit should return MultiResolution image in case if >>>>>>>>>>>>> the >>>>>>>>>>>>> loaded image has .scale-* qualifiers. >>>>>>>>>>>>> The Graphics class can request an image with necessary >>>>>>>>>>>>> resolution >>>>>>>>>>>>> from the MultiResolution image. >>>>>>>>>>>>> >>>>>>>>>>>>> It seems that nothing should be changed in the >>>>>>>>>>>>> MultiResolution >>>>>>>>>>>>> interface in this case. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 1/14/14 2:54 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8029339 >>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is a proposal to introduce an API that allows to >>>>>>>>>>>>>>> create a >>>>>>>>>>>>>>> custom >>>>>>>>>>>>>>> multi resolution image. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I. It seems reasonable that the API should provide two basic >>>>>>>>>>>>>>> operations: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. Get the resolution variant based on the requested image >>>>>>>>>>>>>>> width and >>>>>>>>>>>>>>> height: >>>>>>>>>>>>>>> - Image getResolutionVariant(int width, int height) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Usually the system provides the scale factor which >>>>>>>>>>>>>>> represents >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> number of pixels corresponding to each linear unit on the >>>>>>>>>>>>>>> display. >>>>>>>>>>>>>>> However, it has sense to combine the scale factor and >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> current >>>>>>>>>>>>>>> transformations to get the actual image size to be >>>>>>>>>>>>>>> displayed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. Get all provided resolution variants: >>>>>>>>>>>>>>> - List getResolutionVariants() >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There are several uses cases: >>>>>>>>>>>>>>> - Create a new multi-resolution image based on the given >>>>>>>>>>>>>>> multi-resolution image. >>>>>>>>>>>>>>> - Pass to the native system the multi-resolution >>>>>>>>>>>>>>> image. For >>>>>>>>>>>>>>> example, >>>>>>>>>>>>>>> a use can set to the system the custom multi-resolution >>>>>>>>>>>>>>> cursor. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> II. There are some possible ways where the new API can be >>>>>>>>>>>>>>> added >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. java.awt.Image. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The 2 new methods can be added to the Image class. A user >>>>>>>>>>>>>>> can >>>>>>>>>>>>>>> override >>>>>>>>>>>>>>> the getResolutionVariant() and getResolutionVariants() >>>>>>>>>>>>>>> methods to >>>>>>>>>>>>>>> provide the resolution variants >>>>>>>>>>>>>>> or there can be default implementations of these methods >>>>>>>>>>>>>>> if a >>>>>>>>>>>>>>> user >>>>>>>>>>>>>>> puts resolution variants >>>>>>>>>>>>>>> to the list in the sorted order. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To check that the image has resolution variants the >>>>>>>>>>>>>>> following >>>>>>>>>>>>>>> statement can be used: image.getResolutionVariants().size() >>>>>>>>>>>>>>> != 1 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The disadvantage is that there is an overhead that the >>>>>>>>>>>>>>> Image >>>>>>>>>>>>>>> class >>>>>>>>>>>>>>> should contain the List object and not all >>>>>>>>>>>>>>> images can have resolution variants. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. Introduce new MultiResolutionImage interface. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A user should extend Image class and implement the >>>>>>>>>>>>>>> MultiResolutionImage interface. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For example: >>>>>>>>>>>>>>> --------------------- >>>>>>>>>>>>>>> public class CustomMultiResolutionImage extends >>>>>>>>>>>>>>> BufferedImage >>>>>>>>>>>>>>> implements MultiResolutionImage { >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Image highResolutionImage; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> public CustomMultiResolutionImage(BufferedImage >>>>>>>>>>>>>>> baseImage, >>>>>>>>>>>>>>> BufferedImage highResolutionImage) { >>>>>>>>>>>>>>> super(baseImage.getWidth(), >>>>>>>>>>>>>>> baseImage.getHeight(), >>>>>>>>>>>>>>> baseImage.getType()); >>>>>>>>>>>>>>> this.highResolutionImage = highResolutionImage; >>>>>>>>>>>>>>> Graphics g = getGraphics(); >>>>>>>>>>>>>>> g.drawImage(baseImage, 0, 0, null); >>>>>>>>>>>>>>> g.dispose(); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>> public Image getResolutionVariant(int width, int >>>>>>>>>>>>>>> height) { >>>>>>>>>>>>>>> return ((width <= getWidth() && height <= >>>>>>>>>>>>>>> getHeight())) >>>>>>>>>>>>>>> ? this : highResolutionImage; >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>> public List getResolutionVariants() { >>>>>>>>>>>>>>> return Arrays.asList(this, >>>>>>>>>>>>>>> highResolutionImage); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> --------------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The current fix adds the MultiResolutionImage interface >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> public >>>>>>>>>>>>>>> resolution variant rendering hints. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >> > From yuri.nesterenko at oracle.com Thu Apr 3 07:01:39 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 03 Apr 2014 11:01:39 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <533C279C.8020007@oracle.com> References: <53392A07.8060702@oracle.com> <53393F56.50501@oracle.com> <7C52E68B-B5B9-440E-9C4A-8C2F7E8B6BC0@oracle.com> <533956D9.4020306@oracle.com> <5339727F.5000109@oracle.com> <533A81AA.6050200@oracle.com> <533C279C.8020007@oracle.com> Message-ID: <533D0753.9070306@oracle.com> On 04/02/2014 07:07 PM, Sergey Bylokhov wrote: > On 4/1/14 1:06 PM, Dmitriy Ermashov wrote: >> Hi, Sergey >> >> On 31.03.2014 17:49, Sergey Bylokhov wrote: >>> Hi, Dmitriy. >>> Do I understand correctly that these methods will be added to the >>> Robot class in jdk9? >> Yes, it is a current plan. > Then why you did not apply these changes to the Robot class itself? There's some sort of a logistics issue here. The existing corpus of the client tests is huge, and making a drastic change like introducing realSync would inevitably break some of them. Nobody knows how many. The operational plan is to give an important change some time in limbo before adding it to JDK/src -- but at the same time to do our porting job. That would require some (a lot of) test run analysis with internal JDK builds -- but in background. Thanks, -yan >>> A few notes: >>> - Different javadoc formatting for different methods. >>> - There is no information about exceptions. At least waitForIdle >>> will throw an exception if will be called on edt. >> 2All: please, review the latest version of changeset: >> http://cr.openjdk.java.net/~yan/8038631/webrev.02/ > - javadoc formatting still different. > - you cannot use non public realSync method name in the public > documentation. > - Probably it will make sense to set syncDelay via system property and > get rid setters? In this case delay can be controlled outside of the > test itself. > - It would be good to make some research in internet, what methods can > be implemented as well.(like drag, etc). >>> >>> On 31.03.2014 15:51, Dmitriy Ermashov wrote: >>>> Hi, >>>> >>>> Please, review the latest version of changeset for: >>>> https://bugs.openjdk.java.net/browse/JDK-8038631 >>>> >>>> Webrev is here: >>>> http://cr.openjdk.java.net/~yan/8038631/webrev.01/ >>>> >>>> >>>> On 31.03.2014 14:15, Petr Pchelko wrote: >>>>>>> 4. The default value for realSync additional delay doesn't seem >>>>>>> enough. We normally use 500 ms as the frame creation and first >>>>>>> draw could take more time. >>>>>> We have to use small delay between mousePress and mouseRelease >>>>>> events to emulate real mouse click event. And larger delay can be >>>>>> put after mouseRelease call, for ex. 500 ms, as you wrote. >>>>>> Don't you mind of this solution? >>>>> And couldn't you reuse DEFAULT_SPEED for sleeping in mouseClick? >>>>> The comment states it's used there but it's not.. >>>>> >>>>>>> 5. The click method could be more consistent with others if >>>>>>> called "mouseClick". No strong opinion on this. >>>>>> For now we have several hundreds of functional tests, most of them >>>>>> use method named click(). It seems more reasonable to create >>>>>> method click() and use it than search the usage of it in all tests >>>>>> and fix to mouseClick() call. >>>>> Ok, no problem. I'm fine either way. >>>>> >>>>> With best regards. Petr. >>>>> >>>>> On 31.03.2014, at 14:11, Dmitriy Ermashov >>>>> wrote: >>>>> >>>>>> On 31.03.2014 13:12, Petr Pchelko wrote: >>>>>>> Hello, Dmitry. >>>>>>> >>>>>>> Some comments: >>>>>>> >>>>>>> 1. The name RobotWrapper does not fit in my opinion. The >>>>>>> "Wrapper" is more useful for delegation not extension and it >>>>>>> feels like you should pass the normal Robot to the wrapper >>>>>>> constructor.. I think something like "ExtendedRobot" would feel >>>>>>> better. This is my personal preference so it's arguable. >>>>>> No objections. Will rename it to ExtendedRobot. >>>>>>> 2. I'm not sure I understand why is this location of the util >>>>>>> works? in JavaDoc you state that it should be included from >>>>>>> regtesthelpers but you put it to the test lib. Is it some feature >>>>>>> of jtreg I'm not aware of? >>>>>> Will fix in next version of webrev. >>>>>>> 3. Could you please use @code instead of >>>>>> Will fix in next version of webrev. >>>>>>> 4. The default value for realSync additional delay doesn't seem >>>>>>> enough. We normally use 500 ms as the frame creation and first >>>>>>> draw could take more time. >>>>>> We have to use small delay between mousePress and mouseRelease >>>>>> events to emulate real mouse click event. And larger delay can be >>>>>> put after mouseRelease call, for ex. 500 ms, as you wrote. >>>>>> Don't you mind of this solution? >>>>>>> 5. The click method could be more consistent with others if >>>>>>> called "mouseClick". No strong opinion on this. >>>>>> For now we have several hundreds of functional tests, most of them >>>>>> use method named click(). It seems more reasonable to create >>>>>> method click() and use it than search the usage of it in all tests >>>>>> and fix to mouseClick() call. >>>>>>> 6. "Clicks mouse button 1 with the default pause between Press >>>>>>> and Release." this statement does not seem clear. How to override >>>>>>> the default value? Why does this method click with the default >>>>>>> pause and the previous one does not? or does it? It's not clear >>>>>>> from the JavaDoc >>>>>> I believe, javadoc should be fixed. >>>>>> Will fix in next version of webrev. >>>>>>> 7. Could you please add @Override annotations where appropriate >>>>>>> (waitForIdle for example) >>>>>> Will fix in next version of webrev. >>>>>>> 8. "public void type" may be keyType would be better? For >>>>>>> consistency with other methods. >>>>>> Same as 5. >>>>>>> 9. Could the method you are using for converting KeyChar to >>>>>>> KeyCode be replaces with KeyEvent.getExtendedKeyCodeForChar? Or >>>>>>> KeyStroke API? This switch is ugly and it would be awesome to >>>>>>> replace it. >>>>>> Will fix in next version of webrev. >>>>>>> Thank you. >>>>>>> With best regards. Petr. >>>>>>> >>>>>>> On 31.03.2014, at 12:40, Dmitriy Ermashov >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> Please, review the changeset for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8038631 >>>>>>>> >>>>>>>> Webrev is here: >>>>>>>> http://cr.openjdk.java.net/~yan/8038631/webrev.00 >>>>>>>> >>>>>>>> Presently for testing of JDK client we use test suites of two >>>>>>>> kinds, historically called regression and functional (internal). >>>>>>>> In JDK9 we plan an attempt to unify them and ultimately get rid >>>>>>>> of the functional suites. >>>>>>>> >>>>>>>> One of the first technical problems in this refactoring attempt >>>>>>>> is a multitude of the java.awt.Robot wrappers. There are some >>>>>>>> really elaborate libraries enhansing Robot which all we cannot >>>>>>>> and should not port to jtreg. >>>>>>>> >>>>>>>> Fortunately, test writers almost never use complex features of >>>>>>>> these wrappers. So here's our plan: >>>>>>>> (1) describe the real practice of the robot use in the >>>>>>>> functional tests (please don't worry, that's out of scope of >>>>>>>> this request); >>>>>>>> (2) write a minimal useful RobotWrapper extending java.awt.Robot; >>>>>>>> (3) start functional tests refactoring; >>>>>>>> (4) cautiously move enhancements to the java.awt.Robot trying >>>>>>>> not to break backward compatibility of thousands existing tests. >>>>>>>> For instance, waitForIdle should use realSync() but there >>>>>>>> definitely >>>>>>>> are plenty of tests using it on EDT: or maybe not -- we should >>>>>>>> spent some time for background research in parallel with (3). >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks, >>>>>>>> Dima >>>>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Dima >>>>>> >>>> >>> >>> >> > > > -- > Best regards, Sergey. > From dmitriy.ermashov at oracle.com Thu Apr 3 07:44:14 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Thu, 03 Apr 2014 11:44:14 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <533D0753.9070306@oracle.com> References: <53392A07.8060702@oracle.com> <53393F56.50501@oracle.com> <7C52E68B-B5B9-440E-9C4A-8C2F7E8B6BC0@oracle.com> <533956D9.4020306@oracle.com> <5339727F.5000109@oracle.com> <533A81AA.6050200@oracle.com> <533C279C.8020007@oracle.com> <533D0753.9070306@oracle.com> Message-ID: <533D114E.3060609@oracle.com> Hi, Sergey >> - javadoc formatting still different. Sergey, could you give some additional info about different javadoc formatting? What methods have different formatting and how you think it should look like? >> - It would be good to make some research in internet, what methods can be implemented as well.(like drag, etc). We hove a batch of functional tests that uses some other methods (like Drag&Drop and some others) of several robot wrappers, but the number of these tests is too little. So there is no real need to add some other methods. Anyway, we can add more methods in future if it would be reasonable. -- Thanks, Dima On 03.04.2014 11:01, Yuri Nesterenko wrote: > On 04/02/2014 07:07 PM, Sergey Bylokhov wrote: >> On 4/1/14 1:06 PM, Dmitriy Ermashov wrote: >>> Hi, Sergey >>> >>> On 31.03.2014 17:49, Sergey Bylokhov wrote: >>>> Hi, Dmitriy. >>>> Do I understand correctly that these methods will be added to the >>>> Robot class in jdk9? >>> Yes, it is a current plan. >> Then why you did not apply these changes to the Robot class itself? > > There's some sort of a logistics issue here. The existing corpus of > the client tests is huge, and making a drastic change like introducing > realSync would inevitably break some of them. Nobody knows > how many. > The operational plan is to give an important change some time > in limbo before adding it > to JDK/src -- but at the same time to do our porting job. > That would require some (a lot of) test run analysis with > internal JDK builds -- but in background. > > Thanks, > -yan > > >>>> A few notes: >>>> - Different javadoc formatting for different methods. >>>> - There is no information about exceptions. At least waitForIdle >>>> will throw an exception if will be called on edt. >>> 2All: please, review the latest version of changeset: >>> http://cr.openjdk.java.net/~yan/8038631/webrev.02/ >> - javadoc formatting still different. >> - you cannot use non public realSync method name in the public >> documentation. >> - Probably it will make sense to set syncDelay via system property and >> get rid setters? In this case delay can be controlled outside of the >> test itself. >> - It would be good to make some research in internet, what methods can >> be implemented as well.(like drag, etc). >>>> >>>> On 31.03.2014 15:51, Dmitriy Ermashov wrote: >>>>> Hi, >>>>> >>>>> Please, review the latest version of changeset for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8038631 >>>>> >>>>> Webrev is here: >>>>> http://cr.openjdk.java.net/~yan/8038631/webrev.01/ >>>>> >>>>> >>>>> On 31.03.2014 14:15, Petr Pchelko wrote: >>>>>>>> 4. The default value for realSync additional delay doesn't seem >>>>>>>> enough. We normally use 500 ms as the frame creation and first >>>>>>>> draw could take more time. >>>>>>> We have to use small delay between mousePress and mouseRelease >>>>>>> events to emulate real mouse click event. And larger delay can be >>>>>>> put after mouseRelease call, for ex. 500 ms, as you wrote. >>>>>>> Don't you mind of this solution? >>>>>> And couldn't you reuse DEFAULT_SPEED for sleeping in mouseClick? >>>>>> The comment states it's used there but it's not.. >>>>>> >>>>>>>> 5. The click method could be more consistent with others if >>>>>>>> called "mouseClick". No strong opinion on this. >>>>>>> For now we have several hundreds of functional tests, most of them >>>>>>> use method named click(). It seems more reasonable to create >>>>>>> method click() and use it than search the usage of it in all tests >>>>>>> and fix to mouseClick() call. >>>>>> Ok, no problem. I'm fine either way. >>>>>> >>>>>> With best regards. Petr. >>>>>> >>>>>> On 31.03.2014, at 14:11, Dmitriy Ermashov >>>>>> wrote: >>>>>> >>>>>>> On 31.03.2014 13:12, Petr Pchelko wrote: >>>>>>>> Hello, Dmitry. >>>>>>>> >>>>>>>> Some comments: >>>>>>>> >>>>>>>> 1. The name RobotWrapper does not fit in my opinion. The >>>>>>>> "Wrapper" is more useful for delegation not extension and it >>>>>>>> feels like you should pass the normal Robot to the wrapper >>>>>>>> constructor.. I think something like "ExtendedRobot" would feel >>>>>>>> better. This is my personal preference so it's arguable. >>>>>>> No objections. Will rename it to ExtendedRobot. >>>>>>>> 2. I'm not sure I understand why is this location of the util >>>>>>>> works? in JavaDoc you state that it should be included from >>>>>>>> regtesthelpers but you put it to the test lib. Is it some feature >>>>>>>> of jtreg I'm not aware of? >>>>>>> Will fix in next version of webrev. >>>>>>>> 3. Could you please use @code instead of >>>>>>> Will fix in next version of webrev. >>>>>>>> 4. The default value for realSync additional delay doesn't seem >>>>>>>> enough. We normally use 500 ms as the frame creation and first >>>>>>>> draw could take more time. >>>>>>> We have to use small delay between mousePress and mouseRelease >>>>>>> events to emulate real mouse click event. And larger delay can be >>>>>>> put after mouseRelease call, for ex. 500 ms, as you wrote. >>>>>>> Don't you mind of this solution? >>>>>>>> 5. The click method could be more consistent with others if >>>>>>>> called "mouseClick". No strong opinion on this. >>>>>>> For now we have several hundreds of functional tests, most of them >>>>>>> use method named click(). It seems more reasonable to create >>>>>>> method click() and use it than search the usage of it in all tests >>>>>>> and fix to mouseClick() call. >>>>>>>> 6. "Clicks mouse button 1 with the default pause between Press >>>>>>>> and Release." this statement does not seem clear. How to override >>>>>>>> the default value? Why does this method click with the default >>>>>>>> pause and the previous one does not? or does it? It's not clear >>>>>>>> from the JavaDoc >>>>>>> I believe, javadoc should be fixed. >>>>>>> Will fix in next version of webrev. >>>>>>>> 7. Could you please add @Override annotations where appropriate >>>>>>>> (waitForIdle for example) >>>>>>> Will fix in next version of webrev. >>>>>>>> 8. "public void type" may be keyType would be better? For >>>>>>>> consistency with other methods. >>>>>>> Same as 5. >>>>>>>> 9. Could the method you are using for converting KeyChar to >>>>>>>> KeyCode be replaces with KeyEvent.getExtendedKeyCodeForChar? Or >>>>>>>> KeyStroke API? This switch is ugly and it would be awesome to >>>>>>>> replace it. >>>>>>> Will fix in next version of webrev. >>>>>>>> Thank you. >>>>>>>> With best regards. Petr. >>>>>>>> >>>>>>>> On 31.03.2014, at 12:40, Dmitriy Ermashov >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> Please, review the changeset for: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8038631 >>>>>>>>> >>>>>>>>> Webrev is here: >>>>>>>>> http://cr.openjdk.java.net/~yan/8038631/webrev.00 >>>>>>>>> >>>>>>>>> Presently for testing of JDK client we use test suites of two >>>>>>>>> kinds, historically called regression and functional (internal). >>>>>>>>> In JDK9 we plan an attempt to unify them and ultimately get rid >>>>>>>>> of the functional suites. >>>>>>>>> >>>>>>>>> One of the first technical problems in this refactoring attempt >>>>>>>>> is a multitude of the java.awt.Robot wrappers. There are some >>>>>>>>> really elaborate libraries enhansing Robot which all we cannot >>>>>>>>> and should not port to jtreg. >>>>>>>>> >>>>>>>>> Fortunately, test writers almost never use complex features of >>>>>>>>> these wrappers. So here's our plan: >>>>>>>>> (1) describe the real practice of the robot use in the >>>>>>>>> functional tests (please don't worry, that's out of scope of >>>>>>>>> this request); >>>>>>>>> (2) write a minimal useful RobotWrapper extending java.awt.Robot; >>>>>>>>> (3) start functional tests refactoring; >>>>>>>>> (4) cautiously move enhancements to the java.awt.Robot trying >>>>>>>>> not to break backward compatibility of thousands existing tests. >>>>>>>>> For instance, waitForIdle should use realSync() but there >>>>>>>>> definitely >>>>>>>>> are plenty of tests using it on EDT: or maybe not -- we should >>>>>>>>> spent some time for background research in parallel with (3). >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Thanks, >>>>>>>>> Dima >>>>>>>>> >>>>>>> -- >>>>>>> Thanks, >>>>>>> Dima >>>>>>> >>>>> >>>> >>>> >>> >> >> >> -- >> Best regards, Sergey. >> > From petr.pchelko at oracle.com Thu Apr 3 11:23:49 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 3 Apr 2014 15:23:49 +0400 Subject: [9] Review Request: 8039083 REGRESSION: closed/java/awt/dnd/DragSourceListenerSerializationTest/DragSourceListenerSerializationTest.html fails with NPE since 8u20 b07 on Linux Message-ID: <5E3F3E5C-2390-4E2B-A139-F893C848EE44@oracle.com> Hello, Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8039083 The fix is available at: http://cr.openjdk.java.net/~pchelko/9/8039083/webrev/ When I?ve been making the validation on DnD classes deserialization I?ve over validated a little bit - the DragGestureRecognizer source actions are relying on a transient field, so we not to check the sourceActions from the DragSourceContext field instead. I?m also open-sourcing and cleaning up the test. With best regards. Petr. From Sergey.Bylokhov at oracle.com Thu Apr 3 11:27:37 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 03 Apr 2014 15:27:37 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <533D0753.9070306@oracle.com> References: <53392A07.8060702@oracle.com> <53393F56.50501@oracle.com> <7C52E68B-B5B9-440E-9C4A-8C2F7E8B6BC0@oracle.com> <533956D9.4020306@oracle.com> <5339727F.5000109@oracle.com> <533A81AA.6050200@oracle.com> <533C279C.8020007@oracle.com> <533D0753.9070306@oracle.com> Message-ID: <533D45A9.6070202@oracle.com> On 03.04.2014 11:01, Yuri Nesterenko wrote: > On 04/02/2014 07:07 PM, Sergey Bylokhov wrote: > > There's some sort of a logistics issue here. The existing corpus of > the client tests is huge, and making a drastic change like introducing > realSync would inevitably break some of them. Nobody knows > how many. > The operational plan is to give an important change some time > in limbo before adding it > to JDK/src -- but at the same time to do our porting job. > That would require some (a lot of) test run analysis with > internal JDK builds -- but in background. I think it will be simple to add a few methods to the robot class. No? Otherwise you have to change tests again? We can start from the simple glade and type. It will be integrated early and bugs will be found early as well. But thats up to you. > > Thanks, > -yan > > >>>> A few notes: >>>> - Different javadoc formatting for different methods. >>>> - There is no information about exceptions. At least waitForIdle >>>> will throw an exception if will be called on edt. >>> 2All: please, review the latest version of changeset: >>> http://cr.openjdk.java.net/~yan/8038631/webrev.02/ >> - javadoc formatting still different. >> - you cannot use non public realSync method name in the public >> documentation. >> - Probably it will make sense to set syncDelay via system property and >> get rid setters? In this case delay can be controlled outside of the >> test itself. >> - It would be good to make some research in internet, what methods can >> be implemented as well.(like drag, etc). >>>> >>>> On 31.03.2014 15:51, Dmitriy Ermashov wrote: >>>>> Hi, >>>>> >>>>> Please, review the latest version of changeset for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8038631 >>>>> >>>>> Webrev is here: >>>>> http://cr.openjdk.java.net/~yan/8038631/webrev.01/ >>>>> >>>>> >>>>> On 31.03.2014 14:15, Petr Pchelko wrote: >>>>>>>> 4. The default value for realSync additional delay doesn't seem >>>>>>>> enough. We normally use 500 ms as the frame creation and first >>>>>>>> draw could take more time. >>>>>>> We have to use small delay between mousePress and mouseRelease >>>>>>> events to emulate real mouse click event. And larger delay can be >>>>>>> put after mouseRelease call, for ex. 500 ms, as you wrote. >>>>>>> Don't you mind of this solution? >>>>>> And couldn't you reuse DEFAULT_SPEED for sleeping in mouseClick? >>>>>> The comment states it's used there but it's not.. >>>>>> >>>>>>>> 5. The click method could be more consistent with others if >>>>>>>> called "mouseClick". No strong opinion on this. >>>>>>> For now we have several hundreds of functional tests, most of them >>>>>>> use method named click(). It seems more reasonable to create >>>>>>> method click() and use it than search the usage of it in all tests >>>>>>> and fix to mouseClick() call. >>>>>> Ok, no problem. I'm fine either way. >>>>>> >>>>>> With best regards. Petr. >>>>>> >>>>>> On 31.03.2014, at 14:11, Dmitriy Ermashov >>>>>> wrote: >>>>>> >>>>>>> On 31.03.2014 13:12, Petr Pchelko wrote: >>>>>>>> Hello, Dmitry. >>>>>>>> >>>>>>>> Some comments: >>>>>>>> >>>>>>>> 1. The name RobotWrapper does not fit in my opinion. The >>>>>>>> "Wrapper" is more useful for delegation not extension and it >>>>>>>> feels like you should pass the normal Robot to the wrapper >>>>>>>> constructor.. I think something like "ExtendedRobot" would feel >>>>>>>> better. This is my personal preference so it's arguable. >>>>>>> No objections. Will rename it to ExtendedRobot. >>>>>>>> 2. I'm not sure I understand why is this location of the util >>>>>>>> works? in JavaDoc you state that it should be included from >>>>>>>> regtesthelpers but you put it to the test lib. Is it some feature >>>>>>>> of jtreg I'm not aware of? >>>>>>> Will fix in next version of webrev. >>>>>>>> 3. Could you please use @code instead of >>>>>>> Will fix in next version of webrev. >>>>>>>> 4. The default value for realSync additional delay doesn't seem >>>>>>>> enough. We normally use 500 ms as the frame creation and first >>>>>>>> draw could take more time. >>>>>>> We have to use small delay between mousePress and mouseRelease >>>>>>> events to emulate real mouse click event. And larger delay can be >>>>>>> put after mouseRelease call, for ex. 500 ms, as you wrote. >>>>>>> Don't you mind of this solution? >>>>>>>> 5. The click method could be more consistent with others if >>>>>>>> called "mouseClick". No strong opinion on this. >>>>>>> For now we have several hundreds of functional tests, most of them >>>>>>> use method named click(). It seems more reasonable to create >>>>>>> method click() and use it than search the usage of it in all tests >>>>>>> and fix to mouseClick() call. >>>>>>>> 6. "Clicks mouse button 1 with the default pause between Press >>>>>>>> and Release." this statement does not seem clear. How to override >>>>>>>> the default value? Why does this method click with the default >>>>>>>> pause and the previous one does not? or does it? It's not clear >>>>>>>> from the JavaDoc >>>>>>> I believe, javadoc should be fixed. >>>>>>> Will fix in next version of webrev. >>>>>>>> 7. Could you please add @Override annotations where appropriate >>>>>>>> (waitForIdle for example) >>>>>>> Will fix in next version of webrev. >>>>>>>> 8. "public void type" may be keyType would be better? For >>>>>>>> consistency with other methods. >>>>>>> Same as 5. >>>>>>>> 9. Could the method you are using for converting KeyChar to >>>>>>>> KeyCode be replaces with KeyEvent.getExtendedKeyCodeForChar? Or >>>>>>>> KeyStroke API? This switch is ugly and it would be awesome to >>>>>>>> replace it. >>>>>>> Will fix in next version of webrev. >>>>>>>> Thank you. >>>>>>>> With best regards. Petr. >>>>>>>> >>>>>>>> On 31.03.2014, at 12:40, Dmitriy Ermashov >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> Please, review the changeset for: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8038631 >>>>>>>>> >>>>>>>>> Webrev is here: >>>>>>>>> http://cr.openjdk.java.net/~yan/8038631/webrev.00 >>>>>>>>> >>>>>>>>> Presently for testing of JDK client we use test suites of two >>>>>>>>> kinds, historically called regression and functional (internal). >>>>>>>>> In JDK9 we plan an attempt to unify them and ultimately get rid >>>>>>>>> of the functional suites. >>>>>>>>> >>>>>>>>> One of the first technical problems in this refactoring attempt >>>>>>>>> is a multitude of the java.awt.Robot wrappers. There are some >>>>>>>>> really elaborate libraries enhansing Robot which all we cannot >>>>>>>>> and should not port to jtreg. >>>>>>>>> >>>>>>>>> Fortunately, test writers almost never use complex features of >>>>>>>>> these wrappers. So here's our plan: >>>>>>>>> (1) describe the real practice of the robot use in the >>>>>>>>> functional tests (please don't worry, that's out of scope of >>>>>>>>> this request); >>>>>>>>> (2) write a minimal useful RobotWrapper extending java.awt.Robot; >>>>>>>>> (3) start functional tests refactoring; >>>>>>>>> (4) cautiously move enhancements to the java.awt.Robot trying >>>>>>>>> not to break backward compatibility of thousands existing tests. >>>>>>>>> For instance, waitForIdle should use realSync() but there >>>>>>>>> definitely >>>>>>>>> are plenty of tests using it on EDT: or maybe not -- we should >>>>>>>>> spent some time for background research in parallel with (3). >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Thanks, >>>>>>>>> Dima >>>>>>>>> >>>>>>> -- >>>>>>> Thanks, >>>>>>> Dima >>>>>>> >>>>> >>>> >>>> >>> >> >> >> -- >> Best regards, Sergey. >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Apr 3 11:31:22 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 03 Apr 2014 15:31:22 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <533D114E.3060609@oracle.com> References: <53392A07.8060702@oracle.com> <53393F56.50501@oracle.com> <7C52E68B-B5B9-440E-9C4A-8C2F7E8B6BC0@oracle.com> <533956D9.4020306@oracle.com> <5339727F.5000109@oracle.com> <533A81AA.6050200@oracle.com> <533C279C.8020007@oracle.com> <533D0753.9070306@oracle.com> <533D114E.3060609@oracle.com> Message-ID: <533D468A.6080605@oracle.com> On 03.04.2014 11:44, Dmitriy Ermashov wrote: > Hi, Sergey > > >> - javadoc formatting still different. > Sergey, could you give some additional info about different javadoc > formatting? Different alignment for example in the public void type(char c) { and public void glide(Point src, Point dest) { and public void glide(int fromX, int fromY, int toX, int toY) { etc... > > What methods have different formatting and how you think it should > look like? > > >> - It would be good to make some research in internet, what methods > can be implemented as well.(like drag, etc). > We hove a batch of functional tests that uses some other methods (like > Drag&Drop and some others) of several robot wrappers, but the number > of these tests is too little. So there is no real need to add some > other methods. > Anyway, we can add more methods in future if it would be reasonable. > -- Best regards, Sergey. From yuri.nesterenko at oracle.com Thu Apr 3 11:56:43 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 03 Apr 2014 15:56:43 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <533D45A9.6070202@oracle.com> References: <53392A07.8060702@oracle.com> <53393F56.50501@oracle.com> <7C52E68B-B5B9-440E-9C4A-8C2F7E8B6BC0@oracle.com> <533956D9.4020306@oracle.com> <5339727F.5000109@oracle.com> <533A81AA.6050200@oracle.com> <533C279C.8020007@oracle.com> <533D0753.9070306@oracle.com> <533D45A9.6070202@oracle.com> Message-ID: <533D4C7B.7000309@oracle.com> On 04/03/2014 03:27 PM, Sergey Bylokhov wrote: > On 03.04.2014 11:01, Yuri Nesterenko wrote: >> On 04/02/2014 07:07 PM, Sergey Bylokhov wrote: >> >> There's some sort of a logistics issue here. The existing corpus of >> the client tests is huge, and making a drastic change like introducing >> realSync would inevitably break some of them. Nobody knows >> how many. >> The operational plan is to give an important change some time >> in limbo before adding it >> to JDK/src -- but at the same time to do our porting job. >> That would require some (a lot of) test run analysis with >> internal JDK builds -- but in background. > I think it will be simple to add a few methods to the robot class. No? > Otherwise you have to change tests again? We can start from the simple > glade and type. > It will be integrated early and bugs will be found early as well. But > thats up to you. Well yes, that part would be simple. But to move methods to the parent also will be simple, and we will do it for some methods anyway. For tests it is completely transparent from where some method come, so they will not change. Thanks, -yan From alexander.zvegintsev at oracle.com Thu Apr 3 13:20:37 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 03 Apr 2014 17:20:37 +0400 Subject: [9] Review Request: 8039083 REGRESSION: closed/java/awt/dnd/DragSourceListenerSerializationTest/DragSourceListenerSerializationTest.html fails with NPE since 8u20 b07 on Linux In-Reply-To: <5E3F3E5C-2390-4E2B-A139-F893C848EE44@oracle.com> References: <5E3F3E5C-2390-4E2B-A139-F893C848EE44@oracle.com> Message-ID: <533D6025.1050303@oracle.com> Hello Petr, the fix looks good to me. -- Thanks, Alexander. On 04/03/2014 03:23 PM, Petr Pchelko wrote: > Hello, > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8039083 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8039083/webrev/ > > When I?ve been making the validation on DnD classes deserialization I?ve over validated a little bit - the DragGestureRecognizer source actions are relying on a transient field, so we not to check the sourceActions from the DragSourceContext field instead. I?m also open-sourcing and cleaning up the test. > > With best regards. Petr. From dmitriy.ermashov at oracle.com Thu Apr 3 13:40:12 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Thu, 03 Apr 2014 17:40:12 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality Message-ID: <533D64BC.8080202@oracle.com> Hi, Please, review the changeset for: https://bugs.openjdk.java.net/browse/JDK-8038631 Webrev is here: http://cr.openjdk.java.net/~yan/8038631/webrev.03/ Last changes consist of: 1. Year updated to 2014 in copyright note. 2. Improve javadoc formatting. 3. Removed non-public method "realSync()" mentions from javadoc. 4. Method setSyncDelay replaced with automatic set on object creation according to vm property. -- Thanks, Dima From petr.pchelko at oracle.com Thu Apr 3 14:18:57 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 3 Apr 2014 18:18:57 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <533D64BC.8080202@oracle.com> References: <533D64BC.8080202@oracle.com> Message-ID: Hello, Dmitry. 1. Do we need to print the delay? I don?t think it?s necessary. 2. The robot could be used in the tests with a SecurityManager, so you should wrap the getProperty in a privileged block. 3. The property should be advertised in the JavaDoc. 4. Robot should probably be thread-safe, so it?s better to make syncDelay final as you are not allowing to change it and set it upon construction. With best regards. Petr. 03 ???. 2014 ?., ? 5:40 ????? ???????, Dmitriy Ermashov ???????(?): > Hi, > Please, review the changeset for: > https://bugs.openjdk.java.net/browse/JDK-8038631 > > Webrev is here: > http://cr.openjdk.java.net/~yan/8038631/webrev.03/ > > Last changes consist of: > 1. Year updated to 2014 in copyright note. > 2. Improve javadoc formatting. > 3. Removed non-public method "realSync()" mentions from javadoc. > 4. Method setSyncDelay replaced with automatic set on object creation according to vm property. > > -- > Thanks, > Dima > From alexandr.scherbatiy at oracle.com Fri Apr 4 11:53:38 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 04 Apr 2014 15:53:38 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: <533C8DDB.5000406@oracle.com> References: <52D51764.8020103@oracle.com> <52DF2F98.3030503@oracle.com> <52F4BCEB.9040702@oracle.com> <52F5782A.9060300@oracle.com> <52FB7E3E.6050000@oracle.com> <52FC14EC.9080503@oracle.com> <53037D3D.80709@oracle.com> <5307E71E.50607@oracle.com> <530F3592.40600@oracle.com> <532B00AD.1000704@oracle.com> <532B7EC5.9000206@oracle.com> <532C4DD7.1080804@oracle.com> <532CD202.5070508@oracle.com> <53302A8E.6090107@oracle.com> <53343914.6090004@oracle.com> <533C8DDB.5000406@oracle.com> Message-ID: <533E9D42.10409@oracle.com> On 4/3/2014 2:23 AM, Jim Graham wrote: > Hi Alexandr, > > The back and forth is getting confusing here, so I thought I'd try to > summarize and start fresh(ish): > > 1. We need to support @2x internally for MacOS compatibility (done). > > 2. We will need to support _DPI images for Win-DPI compatibility (TBD). > > 3. Customers may have their own collection of images to bundle > together into an MR image (working on that here). What is the push > for this? Is this simply parity with Mac interfaces? ---------- Image[] resolutionVariants = // get sorted by sizes array of resolution variants; Image mrImage = Toolkit.getDefaultToolkit().createMRImage(baseImageIndex, resolutionVariants); ---------- Here is the proposed patch: http://cr.openjdk.java.net/~alexsch/8029339/webrev.04/ > 4. Customers may want to synthetically generate images at arbitrary > resolutions (a variation that is impacting this solution). What is > the push for this? ---------- Image mrImage = Toolkit.getDefaultToolkit().createMRImage(baseImageWidth, baseImageHeight, new float[][]{{100, 100}, {150, 150}, {200, 200}}, // resolution variants sizes (rvWidth, rvHeight) -> { /* generate a resolution variant */ }); ---------- > > 5. I'm guessing that customers might want to override the logic to > choose from among multiple resolutions. That came from me based on > seeing Mac and Win using different selection logic and our history of > developers split between those wanting cross-platform consistency and > those wanting consistency with native apps on each platform. Also, > the needs of an animator may differ from the needs of a > resolution-settable-document editor as to how dynamically the images > shift between resolution variants. ---------- Image[] resolutionVariants = // get sorted by sizes array of resolution variants; Image mrImage = ImageResolutionHelper.createMRImage( (rvWidth, rvHeight, resolutionVariants) -> { /*use a custom logic to choose a resolution variant from an array of images*/}, (logicalDPI, baseImageSize, destImageSize) -> destImageSize, // calculate the custom aware resolution variant size baseImageIndex, resolutionVariants); ---------- or just extend the CustomMultiResolutionImage which has Image as the parent class: -------------------- public class CustomMultiResolutionImage extends AbstractMultiResolutionImage { @Override public Image getResolutionVariant(float logicalDPIX, float logicalDPIY, float baseImageWidth, float baseImageHeight, float destImageWidth, float destImageHeight) { // return a resolution variant based on the given logical DPI, // base image size, or destination image size } @Override public List getResolutionVariants() { // return a list of resolution variants } @Override protected Image getBaseImage() { // return the base image } } -------------------- > > Is that a fair summary of all of the considerations so far, or did I > miss something? I think it should cover the main needs. Thanks, Alexandr. > > ...jim > > On 3/27/14 7:43 AM, Alexander Scherbatiy wrote: >> >> Below are some thoughts about TK.createMRImage(...) method >> >> On 3/24/2014 4:52 PM, Alexander Scherbatiy wrote: >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.03/ >>> >>> - baseImageWidth/Height arguments are added to the >>> getResolutionVariant(...) method >>> - dest image sizes are reverted to included DPI scale >>> - AbstractMultiResolutionImage is added. It needs only to implement >>> only 3 methods from the AbstractMultiResolutionImage class >>> to create a custom multi-resolution image. For example: >>> >>> On 3/22/2014 3:57 AM, Jim Graham wrote: >>>> >>>> Your code example below can be expressed as an implementation of the >>>> single-method, lambda-compatible interface that expresses just the >>>> getRV() method. They could easily do: >>>> >>>> final Image baseImage = ...; >>>> TK.createMRImage(new RVInterface() { >>>> public Image getRV(...) { >>>> // calculate rvWidth and rvHeight >>>> // look up rvWidth/rvHeight in a database of images >>>> // possibly contruct a new image >>>> return rvImage; >>>> } >>>> }, baseImage); >>>> >> The RVInterface mixes the logic that construct an image and >> chooses the necessary resolution variant. >> It is ok if a developer always implements this interface. If it >> needs to have DPI/Transform/Platform aware RVInterface the image >> construction logic should be separated. >> >> Does TK.createMRImage() method implies that Platform aware logic >> should be used for a resolution-variant choosing? >> If so, may be general createMRImage() can be placed in the >> ImageResolutionHelper. >>>> The main issue I see is if you might want the newly constructed >>>> variants to appear in the List returned from the getVariants() >>>> method. I'm not sure what value that would have beyond simply >>>> returning the base media that the object uses from which to construct >>>> its variants...? >> >> It can be solved by using something like array of image sizes or >> other seeds and a mapper that can create an image from the given seed. >> >> It can look like: >> ------------------------- >> public class ImageResolutionHelper { >> public interface RVChooser { >> >> public Image getRV( >> float logicalDPIX, float logicalDPIY, >> float baseImageWidth, float baseImageHeight, >> float destImageWidth, float destImageHeight, >> final Image... resolutionVariants); >> } >> >> public static final RVChooser DPI_AWARE = ...; >> public static final RVChooser TRANSFORM_AWARE = ...; >> >> // resolutionVariants is an array of sorted by width/height images >> static Image createMRImage(final RVChooser rvChooser, >> final int baseImageIndex, final Image... >> resolutionVariants) { ... } >> >> // sorted by width/height images should be generated from seeds >> static Image createMRImage(final RVChooser rvChooser, >> final Type baseImageSeed, final Function >> mapper, final Type... rvSeeds) {...} >> } >> >> public abstract class Toolkit { >> public abstract Image createMRImage(int baseImageIndex, Image... >> resolutionVariants); // Platform aware rv chooser is used >> public abstract RVChooser getPlatformRVChooser() ; >> } >> -------------------------- >> Thanks, >> Alexandr. >> >>>> >>>>> I think it is better to provide both the MultiResolutionImage >>>>> and >>>>> its implementation based on the given resolution variants array. >>>> >>>> It occurs to me that even if we don't go with a lambda-factory-based >>>> approach like what I'm describing, it might make sense to provide a >>>> baseMR implementation that they can subclass to keep them from trying >>>> to subclass off of BufferedImage instead. I really would like to >>>> avoid "custom MR images are subclasses of BufImg" if we can as I >>>> think the mix of concepts is a little jarring... >>>> >>>> ...jim >>>> >>>>> The implementation could look like: >>>>> --------------------------------- >>>>> public class CustomMultiResolutionImage extends Image implements >>>>> MultiResolutionImage { >>>>> >>>>> int baseImageIndex; >>>>> Image[] resolutionVariants; >>>>> >>>>> public CustomMultiResolutionImage(int baseImageIndex, >>>>> Image... resolutionVariants) { >>>>> this.baseImageIndex = baseImageIndex; >>>>> this.resolutionVariants = resolutionVariants; >>>>> } >>>>> >>>>> @Override >>>>> public int getWidth(ImageObserver observer) { >>>>> return getBaseImage().getWidth(null); >>>>> } >>>>> >>>>> @Override >>>>> public int getHeight(ImageObserver observer) { >>>>> return getBaseImage().getHeight(null); >>>>> } >>>>> >>>>> @Override >>>>> public ImageProducer getSource() { >>>>> return getBaseImage().getSource(); >>>>> } >>>>> >>>>> @Override >>>>> public Graphics getGraphics() { >>>>> return getBaseImage().getGraphics(); >>>>> } >>>>> >>>>> @Override >>>>> public Object getProperty(String name, ImageObserver observer) { >>>>> return getBaseImage().getProperty(name, observer); >>>>> } >>>>> >>>>> @Override >>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>> logicalDPIY, >>>>> float destinationImageWidth, float >>>>> destinationImageHeight) { >>>>> // calculate resolution variant width/height >>>>> return getResolutionVariant(rvWidth, rvHeight); >>>>> } >>>>> >>>>> @Override >>>>> public List getResolutionVariants() { >>>>> return Arrays.asList(resolutionVariants); >>>>> } >>>>> >>>>> private Image getResolutionVariant(float rvWidth, float >>>>> rvHeight) { >>>>> // return a resolution variant based on the given width and >>>>> height >>>>> } >>>>> >>>>> private Image getBaseImage() { >>>>> return resolutionVariants[baseImageIndex]; >>>>> } >>>>> } >>>>> --------------------------------- >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> >>>>>> Then we provide one of these from TK.get/createImage() when the >>>>>> platform detects @2x, or Win8-style variants. >>>>>> >>>>>> For custom images we provide TK.createMRImage(lambda getRV, Image >>>>>> variants...) and TK.createMRImage(Image variants...); >>>>>> >>>>>> Since the get method is just bookkeeping, I don't see them >>>>>> needing to override it, so the getRV() method is really the only >>>>>> thing >>>>>> they might want to override, and we can tie into the new Lambda >>>>>> capabilities by making a single-method interface for it that they >>>>>> supply in a factory method. >>>>>> >>>>>> I realize that the interface you created is more fundamentally >>>>>> OO, but >>>>>> the Image class has always been special in this regard in the AWT >>>>>> ecosystem (in so far as we do not support someone implementing their >>>>>> own Image subclass even though it is technically possible). >>>>>> Because of >>>>>> this special nature of Image, we end up with the situation that if >>>>>> someone were given a need to create a subclass of Image, then they >>>>>> would turn to BufImg as their superclass even though BufImg is >>>>>> essentially an implementation-specific leaf node on the Image class >>>>>> hierarchy. This approach with a factory method to create an >>>>>> internal >>>>>> subclass of the new MRI class mirrors the existing cases of Image >>>>>> objects that come from factories as well. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> ...jim >>>>>> >>>>>> >>>>>> On 3/20/14 7:52 AM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the updated version of the fix: >>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.01/ >>>>>>> >>>>>>> - The "getResolutionVariant(int width, int height)" method from >>>>>>> MultiResolutionImage class is changed to >>>>>>> Image getResolutionVariant(float logicalDPIX, float >>>>>>> logicalDPIY, >>>>>>> float width, float height, AffineTransform transform); >>>>>>> >>>>>>> - sun.awt.image.ImageResolutionHelper class is added. The >>>>>>> sun.awt.image.MultiResolutionToolkitImage and >>>>>>> sun.awt.image.MultiResolutionBufferedImage classes are used >>>>>>> PLATFORM ImageResolutionHelper. >>>>>>> >>>>>>> The MultiResolutionImage interface implementation could look >>>>>>> like: >>>>>>> ------------------------------ >>>>>>> public class CustomMultiResolutionImage extends BufferedImage >>>>>>> implements >>>>>>> MultiResolutionImage { >>>>>>> >>>>>>> private final Image[] resolutionVariants; >>>>>>> >>>>>>> public CustomMultiResolutionImage(int baseIndex, Image... >>>>>>> images) { >>>>>>> super(images[baseIndex].getWidth(null), >>>>>>> images[baseIndex].getHeight(null), >>>>>>> BufferedImage.TYPE_INT_RGB); >>>>>>> this.resolutionVariants = images; >>>>>>> Graphics g = getGraphics(); >>>>>>> g.drawImage(images[baseIndex], 0, 0, null); >>>>>>> g.dispose(); >>>>>>> } >>>>>>> >>>>>>> @Override >>>>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>>>> logicalDPIY, >>>>>>> float width, float height, AffineTransform >>>>>>> transform) { >>>>>>> return getResolutionVariant(logicalDPIX * width, >>>>>>> logicalDPIY * >>>>>>> height); >>>>>>> } >>>>>>> >>>>>>> @Override >>>>>>> public List getResolutionVariants() { >>>>>>> return Arrays.asList(resolutionVariants); >>>>>>> } >>>>>>> >>>>>>> public Image getResolutionVariant(double width, double >>>>>>> height) { >>>>>>> for (Image image : resolutionVariants) { >>>>>>> if (width <= image.getWidth(null) && height <= >>>>>>> image.getHeight(null)) { >>>>>>> return image; >>>>>>> } >>>>>>> } >>>>>>> return this; >>>>>>> } >>>>>>> } >>>>>>> ------------------------------ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 2/27/2014 4:54 PM, Alexander Scherbatiy wrote: >>>>>>>> On 2/22/2014 3:54 AM, Jim Graham wrote: >>>>>>>>> Hi Alexandr, >>>>>>>>> >>>>>>>>> On 2/18/14 7:33 AM, Alexander Scherbatiy wrote: >>>>>>>>>> Hi Jim, >>>>>>>>>> >>>>>>>>>> Let's divide the discussion into two part. >>>>>>>>>> >>>>>>>>>> 1. Where it is better to hold resolution variants? >>>>>>>>>> Putting resolution variants in Image class brings some >>>>>>>>>> questions like: >>>>>>>>>> - Some type of images do not need to have resolution variants >>>>>>>>>> - Should resolution variants have the same type as the base >>>>>>>>>> image? >>>>>>>>>> - getResolutionVariants() method can return copy of the >>>>>>>>>> original >>>>>>>>>> list >>>>>>>>>> so add/removeRV methods should be also added. >>>>>>>>>> >>>>>>>>>> There are pros and cons for placing resolution variants to >>>>>>>>>> Image >>>>>>>>>> class or to a separate intreface. >>>>>>>>> >>>>>>>>> I agree that this could be a separate interface. In my examples >>>>>>>>> below I was just sticking them inside an "Image{}" to show where >>>>>>>>> they >>>>>>>>> lived in the set of involved objects, not a specific >>>>>>>>> recommendation >>>>>>>>> that they actually be new methods on the base class itself. I >>>>>>>>> probably should have put a comment there about that. >>>>>>>>> >>>>>>>>> With respect to add/remove - that is assuming a need for manual >>>>>>>>> construction of an image set, right? Forgive me if I'm >>>>>>>>> forgetting >>>>>>>>> something, but I seem to recall that manual Multi-Res images was >>>>>>>>> proposed as a way for developers to introduce @2x support >>>>>>>>> themselves, >>>>>>>>> but if we are internally managing @2x and -DPI variants for them, >>>>>>>>> then I'm not sure if there is actual developer need to manually >>>>>>>>> construct their own. Am I forgetting something? >>>>>>>> The NSImage has addRepresentation/removeRepresentation >>>>>>>> methods to >>>>>>>> work with image representations on Mac OS X. >>>>>>>> The java.awt.Image class should provide similar >>>>>>>> functionality to >>>>>>>> have the possibilities as Cocoa on HiDPI displays. >>>>>>>> >>>>>>>>> >>>>>>>>>> 2. Using scale factor/image sizes/scaled image sizes to >>>>>>>>>> retreive a >>>>>>>>>> resolution variant. >>>>>>>>>> >>>>>>>>>> May be it is better to have a structure that provide all >>>>>>>>>> necessary >>>>>>>>>> information to query the resolution variant: scale factor, >>>>>>>>>> draw area >>>>>>>>>> width/height, transformed area width/height? >>>>>>>>>> >>>>>>>>>> For example: >>>>>>>>>> --------------------- >>>>>>>>>> public interface MultiResolutionImage { >>>>>>>>>> >>>>>>>>>> interface DrawAreaInfo { >>>>>>>>>> >>>>>>>>>> float getScaleFactor(); >>>>>>>>>> float getAreaWidth(); >>>>>>>>>> float getAreaHeight(); >>>>>>>>>> float getTransformedAreaWidth(); >>>>>>>>>> float getTransformedAreaHeight(); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> public Image getResolutionVariant(DrawAreaInfo >>>>>>>>>> drawAreaInfo) ; >>>>>>>>>> public List getResolutionVariants(); >>>>>>>>>> } >>>>>>>>>> --------------------- >>>>>>>>> >>>>>>>>> The problem with a constructor is that this is something that is >>>>>>>>> (potentially) done on every drawImage() call, which means we are >>>>>>>>> inviting GC into the equation. If we can come up with a simple >>>>>>>>> "just >>>>>>>>> a couple/3/4 numbers" way to embed that data into a method call >>>>>>>>> argument list then we can make this lighter weight. >>>>>>>>> >>>>>>>>> What about simply having floating point (double) dimensions on >>>>>>>>> the >>>>>>>>> rendered size >>>>>>>> There should be a way to choose a resolution variant >>>>>>>> based on >>>>>>>> requested drawing size or transformed drawing size. >>>>>>>> At least a current transformation should be included too. >>>>>>>>> plus a single floating point "logical DPI" for the screen? >>>>>>>> There is the ID2D1Factory::GetDesktopDpi method which returns >>>>>>>> dpiX and dpiY. >>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316 >>>>>>>> >>>>>>>> That means that logicalDPIX/Y can have different values. >>>>>>>> At least it is described in the >>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/ff684173 >>>>>>>> "To get the DPI setting, call the ID2D1Factory::GetDesktopDpi >>>>>>>> method. The DPI is returned as two floating-point values, one for >>>>>>>> the >>>>>>>> x-axis and one for the y-axis. In theory, these values can differ. >>>>>>>> Calculate a separate scaling factor for each axis." >>>>>>>> >>>>>>>> The getResolutionVariant method could look like: >>>>>>>> -------------------------------------- >>>>>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>>>>> logicalDPIY, >>>>>>>> float widthX, float widthY, AffineTransform >>>>>>>> transform); >>>>>>>> -------------------------------------- >>>>>>>> >>>>>>>>> If the image is known (either passed as an argument or the >>>>>>>>> method is >>>>>>>>> called on the image), then it can provide the original WH. >>>>>>>>> >>>>>>>>>> The MultiResolutionImage default implementation could allow >>>>>>>>>> to use >>>>>>>>>> different strategies like scale factor/transfom/OS based >>>>>>>>>> to query a resolution variant. The OS based strategy can be >>>>>>>>>> used by >>>>>>>>>> default. >>>>>>>>> >>>>>>>>> For Mac policy, all we need is the transformed dimensions, which >>>>>>>>> can >>>>>>>>> be passed in as FP for generality. For Windows policy, all we >>>>>>>>> need >>>>>>>>> is logical DPI for the screen. What other information would we >>>>>>>>> need, or would an algorithm like to use, that can't be computed >>>>>>>>> from >>>>>>>>> those 2 pieces? >>>>>>>> The aim is to provide a base class that can be used to >>>>>>>> create a >>>>>>>> MultiResolutionImage like: >>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/diff/ae53ebce5fa3/src/share/classes/sun/awt/image/MultiResolutionBufferedImage.java >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A developer should be able to implement a custom algorithm to >>>>>>>> query a resolution variant. >>>>>>>> >>>>>>>> It can be done by overriding the getResolutionVariant image: >>>>>>>> ----------------------- >>>>>>>> Image mrImage = new MultiResolutionBufferedImage(){ >>>>>>>> @Override >>>>>>>> public Image getResolutionVariant(...) { >>>>>>>> // Custom logic here >>>>>>>> } >>>>>>>> }; >>>>>>>> ----------------------- >>>>>>>> >>>>>>>> Or it can be done by using resolution variant choosers so a >>>>>>>> developer can implement custom resolution variant query: >>>>>>>> ----------------------- >>>>>>>> public class MultiResolutionBufferedImage implements >>>>>>>> MultiResolutionImage{ >>>>>>>> >>>>>>>> interface ResolutionVariantChooser{ >>>>>>>> Image getResolutionVariant(dpi, size,..., List >>>>>>>> resolutionVariants); >>>>>>>> } >>>>>>>> ResolutionVariantChooser TRANSFORM_BASED = null; >>>>>>>> ResolutionVariantChooser DPI_BASED = null; >>>>>>>> >>>>>>>> ResolutionVariantChooser rvChooser; >>>>>>>> >>>>>>>> @Override >>>>>>>> public Image getResolutionVariant(dpi, size,...,) { >>>>>>>> return rvChooser.getResolutionVariant(dpi, size,..., >>>>>>>> getResolutionVariants()); >>>>>>>> } >>>>>>>> } >>>>>>>> ----------------------- >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>> >>>>>>>>> ...jim >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/13/2014 4:42 AM, Jim Graham wrote: >>>>>>>>>>> On 2/12/14 5:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>> On 2/8/2014 4:19 AM, Jim Graham wrote: >>>>>>>>>>>>> The primary thing that I was concerned about was the >>>>>>>>>>>>> presence of >>>>>>>>>>>>> integers in the API when Windows uses non-integer multiples >>>>>>>>>>>> It would make sense to pass real numbers to the >>>>>>>>>>>> getResolutionVariant() method if the difference between >>>>>>>>>>>> resolution >>>>>>>>>>>> variants sizes is 1. >>>>>>>>>>>> It seems that it is not a common case. >>>>>>>>>>> >>>>>>>>>>> I was thinking of other API that is related to this, such as >>>>>>>>>>> the API >>>>>>>>>>> that queries the scaling factor from a SurfaceManager. I >>>>>>>>>>> seem to >>>>>>>>>>> remember some integer return values in that, but Windows might >>>>>>>>>>> have >>>>>>>>>>> the answer 1.4 or 1.8, depending on the screen scaling factor >>>>>>>>>>> that was >>>>>>>>>>> determined from the UI. >>>>>>>>>>> >>>>>>>>>>> In terms of the getResolutionVariant() method here, those >>>>>>>>>>> non-integer >>>>>>>>>>> screen scaling factors don't directly impact this API. But, we >>>>>>>>>>> have >>>>>>>>>>> some issues with the use of integers there from other sources: >>>>>>>>>>> >>>>>>>>>>> - That API assumes that the caller will determine the pixel >>>>>>>>>>> size >>>>>>>>>>> needed, but the actual media choice is determined with >>>>>>>>>>> different >>>>>>>>>>> techniques on Mac and Windows so this means that the caller >>>>>>>>>>> will >>>>>>>>>>> have >>>>>>>>>>> to worry about platform conventions. Is that the right >>>>>>>>>>> tradeoff? >>>>>>>>>>> >>>>>>>>>>> - The technique recommended for Mac involves computing the >>>>>>>>>>> precise >>>>>>>>>>> size desired using the current transform, which may be a >>>>>>>>>>> floating >>>>>>>>>>> point value, so the integer values used in this API are already >>>>>>>>>>> approximations and there is no documentation on how to >>>>>>>>>>> generate the >>>>>>>>>>> proper integer. In particular, the current code in SG2D >>>>>>>>>>> naively >>>>>>>>>>> uses >>>>>>>>>>> a cast to integer to determine the values to supply which >>>>>>>>>>> means a >>>>>>>>>>> transformed size of W+0.5 will be truncated to W and the lower >>>>>>>>>>> resolution image will be used. Does that conform to Mac >>>>>>>>>>> guidelines? Do >>>>>>>>>>> they require the truncated size to reach W+1 before the next >>>>>>>>>>> size is >>>>>>>>>>> used? Passing in float or double values would sidestep all of >>>>>>>>>>> that >>>>>>>>>>> since then the comparisons would be done with full precision, >>>>>>>>>>> but as >>>>>>>>>>> long as we can determine a "best practices compatible with all >>>>>>>>>>> platforms" rule on how to round to integers, then integers >>>>>>>>>>> are OK >>>>>>>>>>> there. >>>>>>>>>>> >>>>>>>>>>> - The Windows document you cite below suggests that the >>>>>>>>>>> determination >>>>>>>>>>> should be made by looking at the Screen DPI and choosing the >>>>>>>>>>> next >>>>>>>>>>> higher media variant based on that screen DPI. They do not >>>>>>>>>>> specify >>>>>>>>>>> choosing media based on the current transform as is done for >>>>>>>>>>> Mac. If >>>>>>>>>>> we stick with supplying values that are used to determine which >>>>>>>>>>> media >>>>>>>>>>> to use, then on Windows we should not take the transform into >>>>>>>>>>> account, >>>>>>>>>>> but instead query the SurfaceManager for the scale factor and >>>>>>>>>>> only >>>>>>>>>>> transform by those values (even if the current transform was >>>>>>>>>>> manually >>>>>>>>>>> overridden to identity). >>>>>>>>>>> >>>>>>>>>>> There are pros and cons to both approaches. >>>>>>>>>>> >>>>>>>>>>> Mac ensures that you are always using the best media for any >>>>>>>>>>> given >>>>>>>>>>> render operation. >>>>>>>>>>> >>>>>>>>>>> But, Windows ensure more consistency in the face of other >>>>>>>>>>> scaling. >>>>>>>>>>> >>>>>>>>>>> The thing to consider is that if you have a 500x500 image >>>>>>>>>>> with a >>>>>>>>>>> 1000x1000 variant and you rendering it at 500x500 and then >>>>>>>>>>> 501x501, >>>>>>>>>>> that first jump will be fairly jarring as the scaled version >>>>>>>>>>> of the >>>>>>>>>>> 1000x1000 will not look precisely like the original 500x500 >>>>>>>>>>> did. >>>>>>>>>>> With >>>>>>>>>>> @2x images only, this effect is minimized so the advantage of >>>>>>>>>>> always >>>>>>>>>>> using "the best media for a given render operation" may >>>>>>>>>>> outweigh the >>>>>>>>>>> inconsistency issue. But, on Windows where the media are >>>>>>>>>>> 1.4x or >>>>>>>>>>> 1.8x >>>>>>>>>>> in size, a downscaled image will start to show more >>>>>>>>>>> interpolation >>>>>>>>>>> noise and so the balance of the two choices may shift more >>>>>>>>>>> towards not >>>>>>>>>>> wanting a jarring shift. >>>>>>>>>>> >>>>>>>>>>> We might want one or more of the following: >>>>>>>>>>> >>>>>>>>>>> - Developer chooses policy (TX_AWARE, DPI_AWARE, >>>>>>>>>>> ALWAYS_LARGEST, >>>>>>>>>>> NONE, >>>>>>>>>>> PLATFORM) where the last policy would use TX_AWARE on Mac and >>>>>>>>>>> DPI_AWARE on Windows >>>>>>>>>>> >>>>>>>>>>> - We create our own policy and always use it (TX_AWARE? or >>>>>>>>>>> DPI_AWARE?) >>>>>>>>>>> >>>>>>>>>>> - We create our own policy that dynamically chooses one of the >>>>>>>>>>> above >>>>>>>>>>> strategies depending on platform or available media or ??? >>>>>>>>>>> >>>>>>>>>>> - We could create an optional interface for them to install >>>>>>>>>>> their >>>>>>>>>>> own >>>>>>>>>>> algorithm as well. I think it would work best as a delegate >>>>>>>>>>> interface >>>>>>>>>>> that one installs into Image so that it can be used with any >>>>>>>>>>> image >>>>>>>>>>> without having to subclass (it wouldn't really have much to do >>>>>>>>>>> for >>>>>>>>>>> BufferedImages or VolatileImages, though): >>>>>>>>>>> >>>>>>>>>>> class Image { >>>>>>>>>>> void setResolutionHelper(ImageResolutionHelper foo); >>>>>>>>>>> List getResolutionVariants(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> or: >>>>>>>>>>> >>>>>>>>>>> class Graphics { >>>>>>>>>>> void setResolutionHelper(ImageResolutionHelper foo); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> or - anywhere else it could be installed more centrally (per >>>>>>>>>>> App >>>>>>>>>>> context)? >>>>>>>>>>> >>>>>>>>>>> and the interface would be something like one of these >>>>>>>>>>> variants: >>>>>>>>>>> >>>>>>>>>>> interface ImageResolutionHelper { >>>>>>>>>>> // This version would prevent substituting a random image: >>>>>>>>>>> // They have to return an index into the List for >>>>>>>>>>> that >>>>>>>>>>> image... >>>>>>>>>>> public int chooseVariant(Image img, double dpi, number w, >>>>>>>>>>> number h); >>>>>>>>>>> >>>>>>>>>>> or: >>>>>>>>>>> >>>>>>>>>>> // This version would allow substituting an arbitrary >>>>>>>>>>> image: >>>>>>>>>>> public Image getVariant(Image img, double dpi, number w, >>>>>>>>>>> number >>>>>>>>>>> h); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Since they would be in full control of the policy, though, we >>>>>>>>>>> would >>>>>>>>>>> unfortunately always have to call this, there would be no more >>>>>>>>>>> testing >>>>>>>>>>> in SG2D to see "if" we need to deal with DPI, though perhaps we >>>>>>>>>>> could >>>>>>>>>>> document some internal conditions in which we do not call it >>>>>>>>>>> for >>>>>>>>>>> common cases (but that would have to be well agreed not to >>>>>>>>>>> get in >>>>>>>>>>> the >>>>>>>>>>> way of reasonable uses of the API and well documented)? >>>>>>>>>>> >>>>>>>>>>> Note that we would have to do a security audit to make sure >>>>>>>>>>> that >>>>>>>>>>> random image substitution couldn't allow any sort of "screen >>>>>>>>>>> phishing" >>>>>>>>>>> exploit. >>>>>>>>>>> >>>>>>>>>>> ...jim >>>>>>>>>>> >>>>>>>>>>>>> and also what policy they use for choosing scaled images. >>>>>>>>>>>>> >>>>>>>>>>>>> I don't see a mention of taking the current transform into >>>>>>>>>>>>> account, >>>>>>>>>>>>> just physical issues like screen DPI and form factor. They >>>>>>>>>>>>> talk >>>>>>>>>>>>> about >>>>>>>>>>>>> resolution plateaus and in their recommendations section they >>>>>>>>>>>>> tell the >>>>>>>>>>>>> developer to use a particular property that tells them the >>>>>>>>>>>>> screen >>>>>>>>>>>>> resolution to figure out which image to load if they are >>>>>>>>>>>>> loading >>>>>>>>>>>>> manually. There is no discussion about dynamically loading >>>>>>>>>>>>> multiple >>>>>>>>>>>>> versions of the image based on a dynamic program-applied >>>>>>>>>>>>> transform >>>>>>>>>>>>> factor as is done on MacOS. >>>>>>>>>>>>> >>>>>>>>>>>>> Also, they tell developers to draw images to a specific size >>>>>>>>>>>>> rather >>>>>>>>>>>>> than using auto-sizing. That begs the question as to how >>>>>>>>>>>>> they >>>>>>>>>>>>> interpret a call to draw an image just using a location in >>>>>>>>>>>>> the >>>>>>>>>>>>> presence of various DPI factors. >>>>>>>>>>>> There is an interesting doc that describes how to write >>>>>>>>>>>> DPI-aware >>>>>>>>>>>> Win32 applications: >>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464646%28v=vs.85%29.aspx >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It is suggested to handle WM_DPICHANGED message, load >>>>>>>>>>>> the >>>>>>>>>>>> graphic >>>>>>>>>>>> that has slightly greater resolution to the current DPI and >>>>>>>>>>>> use >>>>>>>>>>>> StretchBlt >>>>>>>>>>>> to scale down the image. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ...jim >>>>>>>>>>>>> >>>>>>>>>>>>> On 2/7/14 3:00 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> On 1/22/2014 6:40 AM, Jim Graham wrote: >>>>>>>>>>>>>>> Hi Alexander, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Before we get too far down the road on this API, I think we >>>>>>>>>>>>>>> understand >>>>>>>>>>>>>>> the way in which MacOS processes multi-resolution images >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> HiDPI >>>>>>>>>>>>>>> screens, but have we investigated the processes that >>>>>>>>>>>>>>> Windows >>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>> under Windows 8? My impression is that Windows 8 has >>>>>>>>>>>>>>> included a >>>>>>>>>>>>>>> number of new techniques for dealing with the high >>>>>>>>>>>>>>> resolution >>>>>>>>>>>>>>> displays >>>>>>>>>>>>>>> that it will run on in the Windows tablet and mobile >>>>>>>>>>>>>>> industries >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> that these will also come into play as 4K displays (already >>>>>>>>>>>>>>> available) >>>>>>>>>>>>>>> become more common on the desktop. We should make sure >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> what we >>>>>>>>>>>>>>> come up with here can provide native compatibility with >>>>>>>>>>>>>>> either >>>>>>>>>>>>>>> platform's policies and standard practices. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If you've investigated the MS policies I'd like to see a >>>>>>>>>>>>>>> summary so >>>>>>>>>>>>>>> that we can consider them as we review this API... >>>>>>>>>>>>>> There is the Windows Guidelines for scaling to pixel >>>>>>>>>>>>>> density: >>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> which says that Windows has automatic resource loading >>>>>>>>>>>>>> that >>>>>>>>>>>>>> supports >>>>>>>>>>>>>> three version of images scaling (100%, 140%, and 180%) >>>>>>>>>>>>>> -------------------------------- >>>>>>>>>>>>>> Without scaling, as the pixel density of a display device >>>>>>>>>>>>>> increases, the >>>>>>>>>>>>>> physical sizes of objects on screen get smaller. >>>>>>>>>>>>>> When UI would otherwise be too small to touch and when text >>>>>>>>>>>>>> gets >>>>>>>>>>>>>> too >>>>>>>>>>>>>> small to read, >>>>>>>>>>>>>> Windows scales the system and app UI to one of the following >>>>>>>>>>>>>> scaling >>>>>>>>>>>>>> plateaus: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1.0 (100%, no scaling is applied) >>>>>>>>>>>>>> 1.4 (140% scaling) >>>>>>>>>>>>>> 1.8 (180% scaling) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Windows determines which scaling plateau to use based on the >>>>>>>>>>>>>> physical >>>>>>>>>>>>>> screen size, the screen resolution, the DPI of the >>>>>>>>>>>>>> screen, and >>>>>>>>>>>>>> form >>>>>>>>>>>>>> factor. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Use resource loading for bitmap images in the app package >>>>>>>>>>>>>> For >>>>>>>>>>>>>> bitmap >>>>>>>>>>>>>> images stored >>>>>>>>>>>>>> in the app package, provide a separate image for each >>>>>>>>>>>>>> scaling >>>>>>>>>>>>>> factor(100%, 140%, and 180%), >>>>>>>>>>>>>> and name your image files using the "scale" naming >>>>>>>>>>>>>> convention >>>>>>>>>>>>>> described >>>>>>>>>>>>>> below. >>>>>>>>>>>>>> Windows loads the right image for the current scale >>>>>>>>>>>>>> automatically. >>>>>>>>>>>>>> -------------------------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> The image name convention for the various scales is: >>>>>>>>>>>>>> images/logo.scale-100.png >>>>>>>>>>>>>> images/logo.scale-140.png >>>>>>>>>>>>>> images/logo.scale-180.png >>>>>>>>>>>>>> >>>>>>>>>>>>>> The 'ms-appx:///images/logo.png' uri is used to load the >>>>>>>>>>>>>> image >>>>>>>>>>>>>> in an >>>>>>>>>>>>>> application. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If we want to support this in the same way as it is done >>>>>>>>>>>>>> for Mac >>>>>>>>>>>>>> OS X >>>>>>>>>>>>>> the WToolkit should return MultiResolution image in >>>>>>>>>>>>>> case if >>>>>>>>>>>>>> the >>>>>>>>>>>>>> loaded image has .scale-* qualifiers. >>>>>>>>>>>>>> The Graphics class can request an image with necessary >>>>>>>>>>>>>> resolution >>>>>>>>>>>>>> from the MultiResolution image. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It seems that nothing should be changed in the >>>>>>>>>>>>>> MultiResolution >>>>>>>>>>>>>> interface in this case. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 1/14/14 2:54 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8029339 >>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.00 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is a proposal to introduce an API that allows to >>>>>>>>>>>>>>>> create a >>>>>>>>>>>>>>>> custom >>>>>>>>>>>>>>>> multi resolution image. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I. It seems reasonable that the API should provide two >>>>>>>>>>>>>>>> basic >>>>>>>>>>>>>>>> operations: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1. Get the resolution variant based on the requested >>>>>>>>>>>>>>>> image >>>>>>>>>>>>>>>> width and >>>>>>>>>>>>>>>> height: >>>>>>>>>>>>>>>> - Image getResolutionVariant(int width, int height) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Usually the system provides the scale factor which >>>>>>>>>>>>>>>> represents >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> number of pixels corresponding to each linear unit on the >>>>>>>>>>>>>>>> display. >>>>>>>>>>>>>>>> However, it has sense to combine the scale factor and >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>> transformations to get the actual image size to be >>>>>>>>>>>>>>>> displayed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2. Get all provided resolution variants: >>>>>>>>>>>>>>>> - List getResolutionVariants() >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There are several uses cases: >>>>>>>>>>>>>>>> - Create a new multi-resolution image based on the >>>>>>>>>>>>>>>> given >>>>>>>>>>>>>>>> multi-resolution image. >>>>>>>>>>>>>>>> - Pass to the native system the multi-resolution >>>>>>>>>>>>>>>> image. For >>>>>>>>>>>>>>>> example, >>>>>>>>>>>>>>>> a use can set to the system the custom multi-resolution >>>>>>>>>>>>>>>> cursor. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> II. There are some possible ways where the new API can be >>>>>>>>>>>>>>>> added >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1. java.awt.Image. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The 2 new methods can be added to the Image class. A >>>>>>>>>>>>>>>> user >>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>> override >>>>>>>>>>>>>>>> the getResolutionVariant() and getResolutionVariants() >>>>>>>>>>>>>>>> methods to >>>>>>>>>>>>>>>> provide the resolution variants >>>>>>>>>>>>>>>> or there can be default implementations of these >>>>>>>>>>>>>>>> methods >>>>>>>>>>>>>>>> if a >>>>>>>>>>>>>>>> user >>>>>>>>>>>>>>>> puts resolution variants >>>>>>>>>>>>>>>> to the list in the sorted order. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To check that the image has resolution variants the >>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>> statement can be used: >>>>>>>>>>>>>>>> image.getResolutionVariants().size() >>>>>>>>>>>>>>>> != 1 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The disadvantage is that there is an overhead that the >>>>>>>>>>>>>>>> Image >>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>> should contain the List object and not all >>>>>>>>>>>>>>>> images can have resolution variants. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2. Introduce new MultiResolutionImage interface. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A user should extend Image class and implement the >>>>>>>>>>>>>>>> MultiResolutionImage interface. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For example: >>>>>>>>>>>>>>>> --------------------- >>>>>>>>>>>>>>>> public class CustomMultiResolutionImage extends >>>>>>>>>>>>>>>> BufferedImage >>>>>>>>>>>>>>>> implements MultiResolutionImage { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Image highResolutionImage; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> public CustomMultiResolutionImage(BufferedImage >>>>>>>>>>>>>>>> baseImage, >>>>>>>>>>>>>>>> BufferedImage highResolutionImage) { >>>>>>>>>>>>>>>> super(baseImage.getWidth(), >>>>>>>>>>>>>>>> baseImage.getHeight(), >>>>>>>>>>>>>>>> baseImage.getType()); >>>>>>>>>>>>>>>> this.highResolutionImage = highResolutionImage; >>>>>>>>>>>>>>>> Graphics g = getGraphics(); >>>>>>>>>>>>>>>> g.drawImage(baseImage, 0, 0, null); >>>>>>>>>>>>>>>> g.dispose(); >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>>> public Image getResolutionVariant(int width, int >>>>>>>>>>>>>>>> height) { >>>>>>>>>>>>>>>> return ((width <= getWidth() && height <= >>>>>>>>>>>>>>>> getHeight())) >>>>>>>>>>>>>>>> ? this : highResolutionImage; >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>>> public List getResolutionVariants() { >>>>>>>>>>>>>>>> return Arrays.asList(this, >>>>>>>>>>>>>>>> highResolutionImage); >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> --------------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The current fix adds the MultiResolutionImage interface >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> public >>>>>>>>>>>>>>>> resolution variant rendering hints. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >> From alexander.v.stepanov at oracle.com Fri Apr 4 12:55:00 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Fri, 04 Apr 2014 16:55:00 +0400 Subject: [9] Review request for 8039259: Tidy warnings cleanup for java.awt Message-ID: <533EABA4.4050801@oracle.com> Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8039259 Webrev corresponding: http://cr.openjdk.java.net/~yan/8039259/webrev.00/ Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. Thanks. Regards, Alexander From petr.pchelko at oracle.com Fri Apr 4 12:55:25 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 4 Apr 2014 16:55:25 +0400 Subject: [9] Review Request: 8039267 Test closed/java/awt/Choice/ChoiceLocationTest/ChoiceLocationTest.html should be removed Message-ID: <9BAE379B-E35F-498C-A67E-910D8835719A@oracle.com> Hello, AWT Team. Please review a simple fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8039267 The fix is available here: http://cr.openjdk.java.net/~pchelko/9/8039267/webrev/ As a part of JDK-7159566 this test was converted to automatic and moved to the open. But the original was not removed. Thank you. With best regards. Petr. From alexander.zvegintsev at oracle.com Fri Apr 4 12:59:55 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 04 Apr 2014 16:59:55 +0400 Subject: [9] Review Request: 8039267 Test closed/java/awt/Choice/ChoiceLocationTest/ChoiceLocationTest.html should be removed In-Reply-To: <9BAE379B-E35F-498C-A67E-910D8835719A@oracle.com> References: <9BAE379B-E35F-498C-A67E-910D8835719A@oracle.com> Message-ID: <533EACCB.3010709@oracle.com> Hello Petr, the fix looks good to me. Thanks, Alexander. On 04/04/2014 04:55 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review a simple fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8039267 > The fix is available here: > http://cr.openjdk.java.net/~pchelko/9/8039267/webrev/ > > As a part of JDK-7159566 this test was converted to automatic and moved to the open. But the original was not removed. > > Thank you. > With best regards. Petr. From Sergey.Bylokhov at oracle.com Fri Apr 4 13:39:15 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 04 Apr 2014 17:39:15 +0400 Subject: [9] Review request for 8039259: Tidy warnings cleanup for java.awt In-Reply-To: <533EABA4.4050801@oracle.com> References: <533EABA4.4050801@oracle.com> Message-ID: <533EB603.5090701@oracle.com> Looks fine. Thanks! On 4/4/14 4:55 PM, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8039259 > > Webrev corresponding: > http://cr.openjdk.java.net/~yan/8039259/webrev.00/ > > Just a minor cleanup of javadoc to avoid tidy warnings; no other code > affected. > > Thanks. > > Regards, > Alexander -- Best regards, Sergey. From petr.pchelko at oracle.com Fri Apr 4 13:42:17 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 4 Apr 2014 17:42:17 +0400 Subject: [9] Review request for 8039259: Tidy warnings cleanup for java.awt In-Reply-To: <533EB603.5090701@oracle.com> References: <533EABA4.4050801@oracle.com> <533EB603.5090701@oracle.com> Message-ID: <4E0C4C67-B33E-42B8-9781-4C9890A6AB0B@oracle.com> Hello, Alexander. Looks good to me too. With best regards. Petr. On 04.04.2014, at 17:39, Sergey Bylokhov wrote: > Looks fine. > Thanks! > > On 4/4/14 4:55 PM, alexander stepanov wrote: >> Hello, >> >> Could you please review the fix for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8039259 >> >> Webrev corresponding: >> http://cr.openjdk.java.net/~yan/8039259/webrev.00/ >> >> Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. >> >> Thanks. >> >> Regards, >> Alexander > > > -- > Best regards, Sergey. > From dmitriy.ermashov at oracle.com Fri Apr 4 13:49:33 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Fri, 04 Apr 2014 17:49:33 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: References: <533D64BC.8080202@oracle.com> Message-ID: <533EB86D.8080309@oracle.com> Hi, Please, review the changeset for: https://bugs.openjdk.java.net/browse/JDK-8038631 Webrev is here: http://cr.openjdk.java.net/~yan/8038631/webrev.04/ Last changes consist of: 1. Removed unnecessary System.out calls. 2. System.getProperty wrapped in doPrivileged block. 3. Javadoc improvement, added info about system property "java.awt.robotdelay" 4. Added modifier final for property syncDelay. -- Thanks, Dima From petr.pchelko at oracle.com Fri Apr 4 14:17:29 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 4 Apr 2014 18:17:29 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <533EB86D.8080309@oracle.com> References: <533D64BC.8080202@oracle.com> <533EB86D.8080309@oracle.com> Message-ID: Hello, Dmitry. > ExtendedRobot is a wrapper around java.awt.Robot that provides some convenience methods. > It contains methods that are ought to be moved to {@link java.awt.Robot} class This is not true. The ExtendedRobot is not a wrapper but a subclass. Also the first mention of "java.awt.Robot" lacks the @link. > ... and sets delay value depends on property value. If property was not set default value of 500 ms is used. This is not an English phrase to my ear... May be something like: "... and sets the delay value equal to the property value. If the property was not set 500 milliseconds default value is used."? But I'm also not a native speaker and I may be wrong here) Also just a suggestion: The glide implementation is not optimal - when int parameters are passed you are creating Point objects and then converting them back to int. It's better to make int-base method main and reuse it in the Point-based. With best regards. Petr. On 04.04.2014, at 17:49, Dmitriy Ermashov wrote: > Hi, > Please, review the changeset for: > https://bugs.openjdk.java.net/browse/JDK-8038631 > > Webrev is here: > http://cr.openjdk.java.net/~yan/8038631/webrev.04/ > > Last changes consist of: > 1. Removed unnecessary System.out calls. > 2. System.getProperty wrapped in doPrivileged block. > 3. Javadoc improvement, added info about system property "java.awt.robotdelay" > 4. Added modifier final for property syncDelay. > > -- > Thanks, > Dima > From alexander.zvegintsev at oracle.com Fri Apr 4 14:30:56 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 04 Apr 2014 18:30:56 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: References: <533D64BC.8080202@oracle.com> <533EB86D.8080309@oracle.com> Message-ID: <533EC220.7020204@oracle.com> Hello Dmitry, there is no need to use string array with doPrivileged: String tempDelay = AccessController.doPrivileged(new PrivilegedAction() { public Void run() { return System.getProperty("java.awt.robotdelay"); } }); Moreover, there is a helper class which can be used here: sun.security.action.GetIntegerAction . Thanks, Alexander. On 04/04/2014 06:17 PM, Petr Pchelko wrote: > Hello, Dmitry. > >> ExtendedRobot is a wrapper around java.awt.Robot that provides some convenience methods. >> It contains methods that are ought to be moved to {@link java.awt.Robot} class > This is not true. The ExtendedRobot is not a wrapper but a subclass. Also the first mention of "java.awt.Robot" lacks the @link. > >> ... and sets delay value depends on property value. If property was not set default value of 500 ms is used. > This is not an English phrase to my ear... May be something like: "... and sets the delay value equal to the property value. > If the property was not set 500 milliseconds default value is used."? But I'm also not a native speaker and I may be wrong here) > > Also just a suggestion: > The glide implementation is not optimal - when int parameters are passed you are creating Point objects and then converting > them back to int. It's better to make int-base method main and reuse it in the Point-based. > > With best regards. Petr. > > On 04.04.2014, at 17:49, Dmitriy Ermashov wrote: > >> Hi, >> Please, review the changeset for: >> https://bugs.openjdk.java.net/browse/JDK-8038631 >> >> Webrev is here: >> http://cr.openjdk.java.net/~yan/8038631/webrev.04/ >> >> Last changes consist of: >> 1. Removed unnecessary System.out calls. >> 2. System.getProperty wrapped in doPrivileged block. >> 3. Javadoc improvement, added info about system property "java.awt.robotdelay" >> 4. Added modifier final for property syncDelay. >> >> -- >> Thanks, >> Dima >> From alexander.zvegintsev at oracle.com Fri Apr 4 14:40:48 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 04 Apr 2014 18:40:48 +0400 Subject: [9] Review request : 6788138 leak in Java_sun_awt_X11_XlibWrapper_getStringBytes? In-Reply-To: <5331A9A5.40500@oracle.com> References: <532C1420.9020109@oracle.com> <532C19BF.4020107@oracle.com> <532C1E26.3090809@oracle.com> <5331A9A5.40500@oracle.com> Message-ID: <533EC470.3060608@oracle.com> Hello AWT team, Could I get a second review? Thanks, Alexander. On 03/25/2014 08:07 PM, Sergey Bylokhov wrote: > On 3/21/14 3:10 PM, Alexander Zvegintsev wrote: >> Hi Sergey, >> >> Updated: >> http://cr.openjdk.java.net/~azvegint/jdk/9/6788138/01/ >> >>> - This two line was added by the dm, in the fix for "Fixed size >>> problem in getStringBytes" in 2003. Note that the storage has >>> "length +1" size. Why? >> >> May be there was an attempt to use a NULL-terminated string(why?), >> but since we passing to SetByteArrayRegion length( not length + 1) it >> makes no sense. >> We passing result of getStringBytes to a String constructor, so we >> don't need a trailing \0. > Thanks. The fix looks fine to me. >> >> Thanks, >> >> Alexander. >> >> On 03/21/2014 02:51 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> A few notes. >>> - documentation of this method is wrong.(copypaste from XFree) >>> - This two line was added by the dm, in the fix for "Fixed size >>> problem in getStringBytes" in 2003. Note that the storage has >>> "length +1" size. Why? >>> >>> On 3/21/14 2:27 PM, Alexander Zvegintsev wrote: >>>> Hello AWT team, >>>> >>>> please review the fix >>>> http://cr.openjdk.java.net/~azvegint/jdk/9/6788138/00/ >>>> for the issue >>>> https://bugs.openjdk.java.net/browse/JDK-6788138 >>>> >>>> >>>> Currently we use this function to get Window Manager name from >>>> native only. >>>> It happens only once at startup, hence this leak is not noticeable. >>>> >>> >>> >> > > From petr.pchelko at oracle.com Fri Apr 4 14:43:15 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 4 Apr 2014 18:43:15 +0400 Subject: [9] Review request : 6788138 leak in Java_sun_awt_X11_XlibWrapper_getStringBytes? In-Reply-To: <533EC470.3060608@oracle.com> References: <532C1420.9020109@oracle.com> <532C19BF.4020107@oracle.com> <532C1E26.3090809@oracle.com> <5331A9A5.40500@oracle.com> <533EC470.3060608@oracle.com> Message-ID: <3C3E9BF0-ADD8-46D1-8F64-1608A479C421@oracle.com> Hello, Alexander. Looks good. With best regards. Petr. On 04.04.2014, at 18:40, Alexander Zvegintsev wrote: > Hello AWT team, > > Could I get a second review? > > Thanks, > > Alexander. > > On 03/25/2014 08:07 PM, Sergey Bylokhov wrote: >> On 3/21/14 3:10 PM, Alexander Zvegintsev wrote: >>> Hi Sergey, >>> >>> Updated: >>> http://cr.openjdk.java.net/~azvegint/jdk/9/6788138/01/ >>> >>>> - This two line was added by the dm, in the fix for "Fixed size problem in getStringBytes" in 2003. Note that the storage has "length +1" size. Why? >>> >>> May be there was an attempt to use a NULL-terminated string(why?), but since we passing to SetByteArrayRegion length( not length + 1) it makes no sense. >>> We passing result of getStringBytes to a String constructor, so we don't need a trailing \0. >> Thanks. The fix looks fine to me. >>> >>> Thanks, >>> >>> Alexander. >>> >>> On 03/21/2014 02:51 PM, Sergey Bylokhov wrote: >>>> Hi, Alexander. >>>> A few notes. >>>> - documentation of this method is wrong.(copypaste from XFree) >>>> - This two line was added by the dm, in the fix for "Fixed size problem in getStringBytes" in 2003. Note that the storage has "length +1" size. Why? >>>> >>>> On 3/21/14 2:27 PM, Alexander Zvegintsev wrote: >>>>> Hello AWT team, >>>>> >>>>> please review the fix >>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/6788138/00/ >>>>> for the issue >>>>> https://bugs.openjdk.java.net/browse/JDK-6788138 >>>>> >>>>> >>>>> Currently we use this function to get Window Manager name from native only. >>>>> It happens only once at startup, hence this leak is not noticeable. >>>>> >>>> >>>> >>> >> >> > From dmitriy.ermashov at oracle.com Fri Apr 4 15:02:34 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Fri, 04 Apr 2014 19:02:34 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <533EB86D.8080309@oracle.com> References: <533D64BC.8080202@oracle.com> <533EB86D.8080309@oracle.com> Message-ID: <533EC98A.7090906@oracle.com> Hi, Please, review the changeset for: https://bugs.openjdk.java.net/browse/JDK-8038631 Webrev is here: http://cr.openjdk.java.net/~yan/8038631/webrev.05/ Last changes consist of: 1. Modified property read process, added sun.security.action.GetIntegerAction usage. 2. Javadoc improvements, added @link, rephrased some sentences. 3. Refactored overloaded glide() methods. -- Thanks, Dima From Sergey.Bylokhov at oracle.com Fri Apr 4 15:06:26 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 04 Apr 2014 19:06:26 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <533EC98A.7090906@oracle.com> References: <533D64BC.8080202@oracle.com> <533EB86D.8080309@oracle.com> <533EC98A.7090906@oracle.com> Message-ID: <533ECA72.7070000@oracle.com> On 4/4/14 7:02 PM, Dmitriy Ermashov wrote: > Hi, > Please, review the changeset for: > https://bugs.openjdk.java.net/browse/JDK-8038631 > > Webrev is here: > http://cr.openjdk.java.net/~yan/8038631/webrev.05/ > > Last changes consist of: > 1. Modified property read process, added > sun.security.action.GetIntegerAction usage. > 2. Javadoc improvements, added @link, rephrased some sentences. > 3. Refactored overloaded glide() methods. Nice refactoring "GetIntegerAction1". -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitriy.ermashov at oracle.com Fri Apr 4 15:09:52 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Fri, 4 Apr 2014 19:09:52 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <533ECA72.7070000@oracle.com> References: <533D64BC.8080202@oracle.com> <533EB86D.8080309@oracle.com> <533EC98A.7090906@oracle.com> <533ECA72.7070000@oracle.com> Message-ID: Oops, small typo! Will fix without webrev, ok? With regards, Dmitriy Ermashov > 04 ???. 2014 ?., ? 19:06, Sergey Bylokhov ???????(?): > >> On 4/4/14 7:02 PM, Dmitriy Ermashov wrote: >> Hi, >> Please, review the changeset for: >> https://bugs.openjdk.java.net/browse/JDK-8038631 >> >> Webrev is here: >> http://cr.openjdk.java.net/~yan/8038631/webrev.05/ >> >> Last changes consist of: >> 1. Modified property read process, added sun.security.action.GetIntegerAction usage. >> 2. Javadoc improvements, added @link, rephrased some sentences. >> 3. Refactored overloaded glide() methods. > Nice refactoring "GetIntegerAction1". > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.pchelko at oracle.com Fri Apr 4 15:11:02 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 4 Apr 2014 19:11:02 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: References: <533D64BC.8080202@oracle.com> <533EB86D.8080309@oracle.com> <533EC98A.7090906@oracle.com> <533ECA72.7070000@oracle.com> Message-ID: <57A280DA-D71E-476F-A3EE-E3C1D4E19FE0@oracle.com> And it would be good to use the GetIntegerAction with the default and get rid of the if clause. With best regards. Petr. On 04.04.2014, at 19:09, Dmitriy Ermashov wrote: > Oops, small typo! > Will fix without webrev, ok? > > With regards, > Dmitriy Ermashov > > 04 ???. 2014 ?., ? 19:06, Sergey Bylokhov ???????(?): > >> On 4/4/14 7:02 PM, Dmitriy Ermashov wrote: >>> Hi, >>> Please, review the changeset for: >>> https://bugs.openjdk.java.net/browse/JDK-8038631 >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~yan/8038631/webrev.05/ >>> >>> Last changes consist of: >>> 1. Modified property read process, added sun.security.action.GetIntegerAction usage. >>> 2. Javadoc improvements, added @link, rephrased some sentences. >>> 3. Refactored overloaded glide() methods. >> Nice refactoring "GetIntegerAction1". >> >> >> -- >> Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitriy.ermashov at oracle.com Fri Apr 4 16:16:39 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Fri, 04 Apr 2014 20:16:39 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <533EC98A.7090906@oracle.com> References: <533D64BC.8080202@oracle.com> <533EB86D.8080309@oracle.com> <533EC98A.7090906@oracle.com> Message-ID: Hi, Please, review the changeset for: https://bugs.openjdk.java.net/browse/JDK-8038631 Webrev is here: http://cr.openjdk.java.net/~yan/8038631/webrev.06/ Last changes consist of: 1. Removed if clause from class initialization section ? Thanks, Dima From petr.pchelko at oracle.com Fri Apr 4 19:32:00 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 4 Apr 2014 23:32:00 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: References: <533D64BC.8080202@oracle.com> <533EB86D.8080309@oracle.com> <533EC98A.7090906@oracle.com> Message-ID: <2CBCC54C-85DC-48D9-A613-32699134DF0A@oracle.com> Hello, Dmitry. This version looks great. With best regards. Petr. 04 ???. 2014 ?., ? 8:16 ????? ???????, Dmitriy Ermashov ???????(?): > Hi, > Please, review the changeset for: > https://bugs.openjdk.java.net/browse/JDK-8038631 > > Webrev is here: > http://cr.openjdk.java.net/~yan/8038631/webrev.06/ > > Last changes consist of: > 1. Removed if clause from class initialization section > > ? > > Thanks, > Dima > > From alexander.zvegintsev at oracle.com Mon Apr 7 08:32:39 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 07 Apr 2014 12:32:39 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <2CBCC54C-85DC-48D9-A613-32699134DF0A@oracle.com> References: <533D64BC.8080202@oracle.com> <533EB86D.8080309@oracle.com> <533EC98A.7090906@oracle.com> <2CBCC54C-85DC-48D9-A613-32699134DF0A@oracle.com> Message-ID: <534262A7.1040300@oracle.com> Hello Dmitriy, this version looks good to me. Thanks, Alexander. On 04/04/2014 11:32 PM, Petr Pchelko wrote: > Hello, Dmitry. > > This version looks great. > > With best regards. Petr. > > 04 ???. 2014 ?., ? 8:16 ????? ???????, Dmitriy Ermashov ???????(?): > >> Hi, >> Please, review the changeset for: >> https://bugs.openjdk.java.net/browse/JDK-8038631 >> >> Webrev is here: >> http://cr.openjdk.java.net/~yan/8038631/webrev.06/ >> >> Last changes consist of: >> 1. Removed if clause from class initialization section >> >> ? >> >> Thanks, >> Dima >> >> From dmitriy.ermashov at oracle.com Mon Apr 7 11:56:04 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Mon, 07 Apr 2014 15:56:04 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <534262A7.1040300@oracle.com> References: <533D64BC.8080202@oracle.com> <533EB86D.8080309@oracle.com> <533EC98A.7090906@oracle.com> <2CBCC54C-85DC-48D9-A613-32699134DF0A@oracle.com> <534262A7.1040300@oracle.com> Message-ID: <53429254.3070501@oracle.com> Hi, Sergey Do you have any additions? http://cr.openjdk.java.net/~yan/8038631/webrev.06/ -- Thanks, Dima On 04/07/2014 12:32 PM, Alexander Zvegintsev wrote: > Hello Dmitriy, > > this version looks good to me. > > Thanks, > > Alexander. > > On 04/04/2014 11:32 PM, Petr Pchelko wrote: >> Hello, Dmitry. >> >> This version looks great. >> >> With best regards. Petr. >> >> 04 ???. 2014 ?., ? 8:16 ????? ???????, Dmitriy Ermashov >> ???????(?): >> >>> Hi, >>> Please, review the changeset for: >>> https://bugs.openjdk.java.net/browse/JDK-8038631 >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~yan/8038631/webrev.06/ >>> >>> Last changes consist of: >>> 1. Removed if clause from class initialization section >>> >>> ? >>> >>> Thanks, >>> Dima >>> >>> > From petr.pchelko at oracle.com Mon Apr 7 13:13:33 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 7 Apr 2014 17:13:33 +0400 Subject: [9] Review Request: JDK-6690000 Typo's in DataFlavor Javadoc Message-ID: <815C6789-6058-41D4-AABA-8830BAD360DB@oracle.com> Hello, AWT Team. Please review the fix for the javadoc typos: https://bugs.openjdk.java.net/browse/JDK-6690000 The fix is here: http://cr.openjdk.java.net/~pchelko/9/6690000/webrev.00/ With best regards. Petr. From petr.pchelko at oracle.com Mon Apr 7 13:16:33 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 7 Apr 2014 17:16:33 +0400 Subject: [9] Review Request: JDK-8039377 Clipboard should post notifications without using the EventQueue.invokeLater Message-ID: <920C4A77-4730-4459-97BD-2C8CB5DF2378@oracle.com> Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8039377 The fix is here: http://cr.openjdk.java.net/~pchelko/9/8039377/webrev.00/ The problem: Clipboard depend on the EventQueue. The solution - remove the invokeLater. The Clipboard object is used only as a Swing sandbox clipboard which is used from the EDT. The user can't use in as the System clipboard, so there's no worries about the callback being executed on some privileged thread. So we can simply remove the invokeLater here. With best regards. Petr. From alexander.zvegintsev at oracle.com Mon Apr 7 13:20:21 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 07 Apr 2014 17:20:21 +0400 Subject: [9] Review Request: JDK-6690000 Typo's in DataFlavor Javadoc In-Reply-To: <815C6789-6058-41D4-AABA-8830BAD360DB@oracle.com> References: <815C6789-6058-41D4-AABA-8830BAD360DB@oracle.com> Message-ID: <5342A615.5090802@oracle.com> Hello Petr, the fix looks good to me. Thanks, Alexander. On 04/07/2014 05:13 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the javadoc typos: > https://bugs.openjdk.java.net/browse/JDK-6690000 > The fix is here: > http://cr.openjdk.java.net/~pchelko/9/6690000/webrev.00/ > > With best regards. Petr. From anthony.petrov at oracle.com Mon Apr 7 13:42:53 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 07 Apr 2014 17:42:53 +0400 Subject: [9] Review Request: JDK-8039377 Clipboard should post notifications without using the EventQueue.invokeLater In-Reply-To: <920C4A77-4730-4459-97BD-2C8CB5DF2378@oracle.com> References: <920C4A77-4730-4459-97BD-2C8CB5DF2378@oracle.com> Message-ID: <5342AB5D.8030305@oracle.com> Hi Petr, Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. -- best regards, Anthony On 4/7/2014 5:16 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8039377 > The fix is here: > http://cr.openjdk.java.net/~pchelko/9/8039377/webrev.00/ > > The problem: Clipboard depend on the EventQueue. The solution - remove the invokeLater. The Clipboard object is used only as a Swing sandbox clipboard which is used from the EDT. > The user can't use in as the System clipboard, so there's no worries about the callback being executed on some privileged thread. So we can simply remove the invokeLater here. > > With best regards. Petr. > From petr.pchelko at oracle.com Mon Apr 7 13:52:03 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 7 Apr 2014 17:52:03 +0400 Subject: [9] Review Request: JDK-8039377 Clipboard should post notifications without using the EventQueue.invokeLater In-Reply-To: <5342AB5D.8030305@oracle.com> References: <920C4A77-4730-4459-97BD-2C8CB5DF2378@oracle.com> <5342AB5D.8030305@oracle.com> Message-ID: <7C5A515A-1ECD-44F8-9985-40BEFB8D3B8F@oracle.com> > Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on > any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. The FlavorListener and ClipboardOwner interfaces do not state that the callbacks would be called on EDT, so at least we are not breaking the spec. The problem here is that Clipboard would be a part of a different module and must be independent from AWT or the desktop module. Even reflectively independent. This means we have 2 options here: option 1 is implemented in the fix. Option 2 is to declare some "DelayedNotificationService", make the Clipboard look for this service using a ServiceLoader and make AWT implement the service using the invokeLater. So if the Clipboard would be used in absence of desktop module it would deliver the notifications in place, and with the desktop module it will use the invokeLater. Personally I think that the second option is way more fragile and unnecessary complicated. The only place where the Clipboard is used directly is in swing's sandbox clipboard, but it's used internally and only on EDT. And it does not leak to the user. So if we just remove the invokeLater we would likely not break anything. With the second option I would not be so sure. With best regards. Petr. On 07.04.2014, at 17:42, Anthony Petrov wrote: > Hi Petr, > > Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. > > -- > best regards, > Anthony > > On 4/7/2014 5:16 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8039377 >> The fix is here: >> http://cr.openjdk.java.net/~pchelko/9/8039377/webrev.00/ >> >> The problem: Clipboard depend on the EventQueue. The solution - remove the invokeLater. The Clipboard object is used only as a Swing sandbox clipboard which is used from the EDT. >> The user can't use in as the System clipboard, so there's no worries about the callback being executed on some privileged thread. So we can simply remove the invokeLater here. >> >> With best regards. Petr. >> From anthony.petrov at oracle.com Mon Apr 7 14:00:51 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 07 Apr 2014 18:00:51 +0400 Subject: [9] Review Request: JDK-8039377 Clipboard should post notifications without using the EventQueue.invokeLater In-Reply-To: <7C5A515A-1ECD-44F8-9985-40BEFB8D3B8F@oracle.com> References: <920C4A77-4730-4459-97BD-2C8CB5DF2378@oracle.com> <5342AB5D.8030305@oracle.com> <7C5A515A-1ECD-44F8-9985-40BEFB8D3B8F@oracle.com> Message-ID: <5342AF93.7000309@oracle.com> I'm aware of the reasons behind this issue. However, I'm still unsure whether this is a safe enough solution. A user could obtain an instance of a Clipboard object by using its public constructor. They could also get it using Clipboard.getSystemClipboard(), and the latter could call the methods that you're changing from a non-EDT thread (directly or indirectly). In any case, the fix that you're proposing changes the threading contract for these methods considerably. And I don't think that this change is safe. -- best regards, Anthony On 4/7/2014 5:52 PM, Petr Pchelko wrote: >> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on >> any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. > The FlavorListener and ClipboardOwner interfaces do not state that the callbacks would be called on EDT, so at least we are not breaking the spec. > The problem here is that Clipboard would be a part of a different module and must be independent from AWT or the desktop module. Even reflectively independent. > This means we have 2 options here: option 1 is implemented in the fix. > > Option 2 is to declare some "DelayedNotificationService", make the Clipboard look for this service using a ServiceLoader and make AWT implement the service > using the invokeLater. So if the Clipboard would be used in absence of desktop module it would deliver the notifications in place, and with the desktop module it will > use the invokeLater. Personally I think that the second option is way more fragile and unnecessary complicated. > > The only place where the Clipboard is used directly is in swing's sandbox clipboard, but it's used internally and only on EDT. And it does not leak to the user. > So if we just remove the invokeLater we would likely not break anything. With the second option I would not be so sure. > > With best regards. Petr. > > On 07.04.2014, at 17:42, Anthony Petrov wrote: > >> Hi Petr, >> >> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. >> >> -- >> best regards, >> Anthony >> >> On 4/7/2014 5:16 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8039377 >>> The fix is here: >>> http://cr.openjdk.java.net/~pchelko/9/8039377/webrev.00/ >>> >>> The problem: Clipboard depend on the EventQueue. The solution - remove the invokeLater. The Clipboard object is used only as a Swing sandbox clipboard which is used from the EDT. >>> The user can't use in as the System clipboard, so there's no worries about the callback being executed on some privileged thread. So we can simply remove the invokeLater here. >>> >>> With best regards. Petr. >>> > From petr.pchelko at oracle.com Mon Apr 7 14:17:00 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 7 Apr 2014 18:17:00 +0400 Subject: [9] Review Request: JDK-8039377 Clipboard should post notifications without using the EventQueue.invokeLater In-Reply-To: <5342AF93.7000309@oracle.com> References: <920C4A77-4730-4459-97BD-2C8CB5DF2378@oracle.com> <5342AB5D.8030305@oracle.com> <7C5A515A-1ECD-44F8-9985-40BEFB8D3B8F@oracle.com> <5342AF93.7000309@oracle.com> Message-ID: > They could also get it using Clipboard.getSystemClipboard(), and the latter could call > the methods that you're changing from a non-EDT thread (directly or indirectly). This is not an issue since the system clipboard is always an instance of a SunClipboard which overrides these methods and uses SunToolkit.postEvent. And there's no API to change the class of the returned system clipboard. > A user could obtain an instance of a Clipboard object by using its public constructor. This is more interesting. If the user creates a Clipboard instance he has almost nothing to do with it. The only place where the custom Clipboard could be passed is TransferHandler.exportToClipboard. Indeed, after the change the Clipboard notifications will be called on the same thread where the exportToClipboard is called, but as TransferHandler is the swing API is must be called on EDT, so effectively nothing's changed. It might be an issue that the notifications become synchronous, but I didn't find any problems with it. > In any case, the fix that you're proposing changes the threading contract for these methods considerably. > And I don't think that this change is safe. Option 2 is not safe as well, but it's way more complicated... Do you have any suggestions about some other options? Thank you. With best regards. Petr. On 07.04.2014, at 18:00, Anthony Petrov wrote: > I'm aware of the reasons behind this issue. However, I'm still unsure whether this is a safe enough solution. A user could obtain an instance of a Clipboard object by using its public constructor. They could also get it using Clipboard.getSystemClipboard(), and the latter could call the methods that you're changing from a non-EDT thread (directly or indirectly). In any case, the fix that you're proposing changes the threading contract for these methods considerably. And I don't think that this change is safe. > > -- > best regards, > Anthony > > On 4/7/2014 5:52 PM, Petr Pchelko wrote: >>> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on >>> any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. >> The FlavorListener and ClipboardOwner interfaces do not state that the callbacks would be called on EDT, so at least we are not breaking the spec. >> The problem here is that Clipboard would be a part of a different module and must be independent from AWT or the desktop module. Even reflectively independent. >> This means we have 2 options here: option 1 is implemented in the fix. >> >> Option 2 is to declare some "DelayedNotificationService", make the Clipboard look for this service using a ServiceLoader and make AWT implement the service >> using the invokeLater. So if the Clipboard would be used in absence of desktop module it would deliver the notifications in place, and with the desktop module it will >> use the invokeLater. Personally I think that the second option is way more fragile and unnecessary complicated. >> >> The only place where the Clipboard is used directly is in swing's sandbox clipboard, but it's used internally and only on EDT. And it does not leak to the user. >> So if we just remove the invokeLater we would likely not break anything. With the second option I would not be so sure. >> >> With best regards. Petr. >> >> On 07.04.2014, at 17:42, Anthony Petrov wrote: >> >>> Hi Petr, >>> >>> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/7/2014 5:16 PM, Petr Pchelko wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8039377 >>>> The fix is here: >>>> http://cr.openjdk.java.net/~pchelko/9/8039377/webrev.00/ >>>> >>>> The problem: Clipboard depend on the EventQueue. The solution - remove the invokeLater. The Clipboard object is used only as a Swing sandbox clipboard which is used from the EDT. >>>> The user can't use in as the System clipboard, so there's no worries about the callback being executed on some privileged thread. So we can simply remove the invokeLater here. >>>> >>>> With best regards. Petr. >>>> >> From alexandr.scherbatiy at oracle.com Mon Apr 7 15:30:38 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 07 Apr 2014 19:30:38 +0400 Subject: [9] Review request for 8038113 [macosx] JTree icon is not rendered in high resolution on Retina In-Reply-To: References: <5332E0FE.5090807@oracle.com> <533C0072.1020306@oracle.com> Message-ID: <5342C49E.8080504@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8038113/webrev.02 - CachableJRSUIIcon explicitly implements Icon interface now - getOptimizedImage() method is removed from the CachingScalingIcon because NSImage always scales an image to the requested size - @Override annotation is added. Thanks, Alexandr. On 4/2/2014 4:37 PM, Petr Pchelko wrote: > Hello, Alexander. > > Could you please add the @Override to the paintIcon method. > > Also I suggest to reuse the paintIcon in the createIcon. > > With best regards. Petr. > > On 02.04.2014, at 16:20, Alexander Scherbatiy wrote: > >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8038113/webrev.01/ >> >> The CachableJRSUIIcon creates an image twice: in createImage() and in the AquaPainter.paint() methods. >> >> The fix paints the icon directly from the AquaPainter.paint() method which uses the properly scaled image. >> >> Thanks, >> Alexandr. >> >> On 3/26/2014 6:15 PM, Alexander Scherbatiy wrote: >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8038113 >>> webrev: http://cr.openjdk.java.net/~alexsch/8038113/webrev.00 >>> >>> MultiResolution image is used to create resolution variants for the JTree icons. >>> >>> The fix assumes that AquaPainter uses the graphics transform for the image size calculation >>> an so depends on the fix for issue 8032667 [macosx] Components cannot be rendered in >>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-March/007370.html >>> >>> Thanks, >>> Alexandr. >>> From Sergey.Bylokhov at oracle.com Mon Apr 7 15:39:01 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 07 Apr 2014 19:39:01 +0400 Subject: [9] Review Request: JDK-6690000 Typo's in DataFlavor Javadoc In-Reply-To: <815C6789-6058-41D4-AABA-8830BAD360DB@oracle.com> References: <815C6789-6058-41D4-AABA-8830BAD360DB@oracle.com> Message-ID: <5342C695.6030005@oracle.com> Hi, Petr. The fix looks good On 07.04.2014 17:13, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the javadoc typos: > https://bugs.openjdk.java.net/browse/JDK-6690000 > The fix is here: > http://cr.openjdk.java.net/~pchelko/9/6690000/webrev.00/ > > With best regards. Petr. -- Best regards, Sergey. From anthony.petrov at oracle.com Mon Apr 7 17:06:02 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 07 Apr 2014 21:06:02 +0400 Subject: [9] Review Request: JDK-8039377 Clipboard should post notifications without using the EventQueue.invokeLater In-Reply-To: References: <920C4A77-4730-4459-97BD-2C8CB5DF2378@oracle.com> <5342AB5D.8030305@oracle.com> <7C5A515A-1ECD-44F8-9985-40BEFB8D3B8F@oracle.com> <5342AF93.7000309@oracle.com> Message-ID: <5342DAFA.1080501@oracle.com> The synchronous vs. asynchronous calling of handlers is a big issue, IMO. Some applications may not be ready for that. I wouldn't change that part unless there's a bug in that functionality. And AFAIK, there's none. As for other options, could you please provide more details on what exactly is required by the modularization project? Do they need to use the Clipboard class, or they actually only need a few other classes from the java.awt.datatransfer classes? In other words, can we keep the Clipboard class in the AWT module, and only move those other classes needed by RMI and friends to a separate module? If that is not an option, then I'd go with a "service" for delayed execution approach. By default the service would provide synchronous dispatching of runnables, but AWT could override it with an implementation that calls invokeLater() under the hood. -- best regards, Anthony On 4/7/2014 6:17 PM, Petr Pchelko wrote: >> They could also get it using Clipboard.getSystemClipboard(), and the latter could call >> the methods that you're changing from a non-EDT thread (directly or indirectly). > This is not an issue since the system clipboard is always an instance of a SunClipboard > which overrides these methods and uses SunToolkit.postEvent. And there's no API to > change the class of the returned system clipboard. > >> A user could obtain an instance of a Clipboard object by using its public constructor. > This is more interesting. If the user creates a Clipboard instance he has almost nothing to do with it. > The only place where the custom Clipboard could be passed is TransferHandler.exportToClipboard. > Indeed, after the change the Clipboard notifications will be called on the same thread where the > exportToClipboard is called, but as TransferHandler is the swing API is must be called on EDT, > so effectively nothing's changed. It might be an issue that the notifications become synchronous, > but I didn't find any problems with it. > >> In any case, the fix that you're proposing changes the threading contract for these methods considerably. >> And I don't think that this change is safe. > > Option 2 is not safe as well, but it's way more complicated... Do you have any suggestions about some other > options? > > Thank you. > With best regards. Petr. > > On 07.04.2014, at 18:00, Anthony Petrov wrote: > >> I'm aware of the reasons behind this issue. However, I'm still unsure whether this is a safe enough solution. A user could obtain an instance of a Clipboard object by using its public constructor. They could also get it using Clipboard.getSystemClipboard(), and the latter could call the methods that you're changing from a non-EDT thread (directly or indirectly). In any case, the fix that you're proposing changes the threading contract for these methods considerably. And I don't think that this change is safe. >> >> -- >> best regards, >> Anthony >> >> On 4/7/2014 5:52 PM, Petr Pchelko wrote: >>>> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on >>>> any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. >>> The FlavorListener and ClipboardOwner interfaces do not state that the callbacks would be called on EDT, so at least we are not breaking the spec. >>> The problem here is that Clipboard would be a part of a different module and must be independent from AWT or the desktop module. Even reflectively independent. >>> This means we have 2 options here: option 1 is implemented in the fix. >>> >>> Option 2 is to declare some "DelayedNotificationService", make the Clipboard look for this service using a ServiceLoader and make AWT implement the service >>> using the invokeLater. So if the Clipboard would be used in absence of desktop module it would deliver the notifications in place, and with the desktop module it will >>> use the invokeLater. Personally I think that the second option is way more fragile and unnecessary complicated. >>> >>> The only place where the Clipboard is used directly is in swing's sandbox clipboard, but it's used internally and only on EDT. And it does not leak to the user. >>> So if we just remove the invokeLater we would likely not break anything. With the second option I would not be so sure. >>> >>> With best regards. Petr. >>> >>> On 07.04.2014, at 17:42, Anthony Petrov wrote: >>> >>>> Hi Petr, >>>> >>>> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 4/7/2014 5:16 PM, Petr Pchelko wrote: >>>>> Hello, AWT Team. >>>>> >>>>> Please review the fix for the issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8039377 >>>>> The fix is here: >>>>> http://cr.openjdk.java.net/~pchelko/9/8039377/webrev.00/ >>>>> >>>>> The problem: Clipboard depend on the EventQueue. The solution - remove the invokeLater. The Clipboard object is used only as a Swing sandbox clipboard which is used from the EDT. >>>>> The user can't use in as the System clipboard, so there's no worries about the callback being executed on some privileged thread. So we can simply remove the invokeLater here. >>>>> >>>>> With best regards. Petr. >>>>> >>> > From petr.pchelko at oracle.com Mon Apr 7 17:13:12 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 7 Apr 2014 21:13:12 +0400 Subject: [9] Review Request: JDK-8039377 Clipboard should post notifications without using the EventQueue.invokeLater In-Reply-To: <5342DAFA.1080501@oracle.com> References: <920C4A77-4730-4459-97BD-2C8CB5DF2378@oracle.com> <5342AB5D.8030305@oracle.com> <7C5A515A-1ECD-44F8-9985-40BEFB8D3B8F@oracle.com> <5342AF93.7000309@oracle.com> <5342DAFA.1080501@oracle.com> Message-ID: <1466BF89-A89F-410D-AFA7-933F20FD335F@oracle.com> > As for other options, could you please provide more details on what exactly is required by the modularization project? Do they need to use the Clipboard class, or they actually only need a few other classes from the java.awt.datatransfer classes? In other words, can we keep the Clipboard class in the AWT module, and only move those other classes needed by RMI and friends to a separate module? Unfortunately that?s not an option. They do not allow us to split the public API packages, so the Clipboard must go into the data transfer module.. > If that is not an option, then I'd go with a "service" for delayed execution approach. By default the service would provide synchronous dispatching of runnables, but AWT could override it with an implementation that calls invokeLater() under the hood. I need some time to investigate this approach.. I?m not sure yet how would this work. The issue with this approach is that we are creating a very fragile API.. If the desktop module is present the callbacks would go asynchronously on EDT, if it?s not - synchronously. So imagine some third-patry component developed not for the desktop, but using the datatransfer module and a Clipboard as a simple holder for transferable. Then someone would reuse that component in the application which also uses AWT. And the notifications would suddenly and unpredictable transform to asynchronous. Nobody will ever understand what?s happening.. With best regards. Petr. 07 ???. 2014 ?., ? 9:06 ????? ???????, Anthony Petrov ???????(?): > The synchronous vs. asynchronous calling of handlers is a big issue, IMO. Some applications may not be ready for that. I wouldn't change that part unless there's a bug in that functionality. And AFAIK, there's none. > > As for other options, could you please provide more details on what exactly is required by the modularization project? Do they need to use the Clipboard class, or they actually only need a few other classes from the java.awt.datatransfer classes? In other words, can we keep the Clipboard class in the AWT module, and only move those other classes needed by RMI and friends to a separate module? > > If that is not an option, then I'd go with a "service" for delayed execution approach. By default the service would provide synchronous dispatching of runnables, but AWT could override it with an implementation that calls invokeLater() under the hood. > > -- > best regards, > Anthony > > On 4/7/2014 6:17 PM, Petr Pchelko wrote: >>> They could also get it using Clipboard.getSystemClipboard(), and the latter could call >>> the methods that you're changing from a non-EDT thread (directly or indirectly). >> This is not an issue since the system clipboard is always an instance of a SunClipboard >> which overrides these methods and uses SunToolkit.postEvent. And there's no API to >> change the class of the returned system clipboard. >> >>> A user could obtain an instance of a Clipboard object by using its public constructor. >> This is more interesting. If the user creates a Clipboard instance he has almost nothing to do with it. >> The only place where the custom Clipboard could be passed is TransferHandler.exportToClipboard. >> Indeed, after the change the Clipboard notifications will be called on the same thread where the >> exportToClipboard is called, but as TransferHandler is the swing API is must be called on EDT, >> so effectively nothing's changed. It might be an issue that the notifications become synchronous, >> but I didn't find any problems with it. >> >>> In any case, the fix that you're proposing changes the threading contract for these methods considerably. >>> And I don't think that this change is safe. >> >> Option 2 is not safe as well, but it's way more complicated... Do you have any suggestions about some other >> options? >> >> Thank you. >> With best regards. Petr. >> >> On 07.04.2014, at 18:00, Anthony Petrov wrote: >> >>> I'm aware of the reasons behind this issue. However, I'm still unsure whether this is a safe enough solution. A user could obtain an instance of a Clipboard object by using its public constructor. They could also get it using Clipboard.getSystemClipboard(), and the latter could call the methods that you're changing from a non-EDT thread (directly or indirectly). In any case, the fix that you're proposing changes the threading contract for these methods considerably. And I don't think that this change is safe. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/7/2014 5:52 PM, Petr Pchelko wrote: >>>>> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on >>>>> any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. >>>> The FlavorListener and ClipboardOwner interfaces do not state that the callbacks would be called on EDT, so at least we are not breaking the spec. >>>> The problem here is that Clipboard would be a part of a different module and must be independent from AWT or the desktop module. Even reflectively independent. >>>> This means we have 2 options here: option 1 is implemented in the fix. >>>> >>>> Option 2 is to declare some "DelayedNotificationService", make the Clipboard look for this service using a ServiceLoader and make AWT implement the service >>>> using the invokeLater. So if the Clipboard would be used in absence of desktop module it would deliver the notifications in place, and with the desktop module it will >>>> use the invokeLater. Personally I think that the second option is way more fragile and unnecessary complicated. >>>> >>>> The only place where the Clipboard is used directly is in swing's sandbox clipboard, but it's used internally and only on EDT. And it does not leak to the user. >>>> So if we just remove the invokeLater we would likely not break anything. With the second option I would not be so sure. >>>> >>>> With best regards. Petr. >>>> >>>> On 07.04.2014, at 17:42, Anthony Petrov wrote: >>>> >>>>> Hi Petr, >>>>> >>>>> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 4/7/2014 5:16 PM, Petr Pchelko wrote: >>>>>> Hello, AWT Team. >>>>>> >>>>>> Please review the fix for the issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8039377 >>>>>> The fix is here: >>>>>> http://cr.openjdk.java.net/~pchelko/9/8039377/webrev.00/ >>>>>> >>>>>> The problem: Clipboard depend on the EventQueue. The solution - remove the invokeLater. The Clipboard object is used only as a Swing sandbox clipboard which is used from the EDT. >>>>>> The user can't use in as the System clipboard, so there's no worries about the callback being executed on some privileged thread. So we can simply remove the invokeLater here. >>>>>> >>>>>> With best regards. Petr. >>>>>> >>>> >> From anthony.petrov at oracle.com Mon Apr 7 17:36:46 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 07 Apr 2014 21:36:46 +0400 Subject: [9] Review Request: JDK-8039377 Clipboard should post notifications without using the EventQueue.invokeLater In-Reply-To: <1466BF89-A89F-410D-AFA7-933F20FD335F@oracle.com> References: <920C4A77-4730-4459-97BD-2C8CB5DF2378@oracle.com> <5342AB5D.8030305@oracle.com> <7C5A515A-1ECD-44F8-9985-40BEFB8D3B8F@oracle.com> <5342AF93.7000309@oracle.com> <5342DAFA.1080501@oracle.com> <1466BF89-A89F-410D-AFA7-933F20FD335F@oracle.com> Message-ID: <5342E22E.5010103@oracle.com> So we both see that replacing asynchronous behavior with a synchronous one (or vice versa) could cause problems for existing or future apps. This indicates that the issue is serious. Note that the default implementation of the service could still dispatch runnables asynchronously on a worker thread, thus minimizing the differences from the case when AWT is present. -- best regards, Anthony On 4/7/2014 9:13 PM, Petr Pchelko wrote: >> As for other options, could you please provide more details on what exactly is required by the modularization project? Do they need to use the Clipboard class, or they actually only need a few other classes from the java.awt.datatransfer classes? In other words, can we keep the Clipboard class in the AWT module, and only move those other classes needed by RMI and friends to a separate module? > Unfortunately that?s not an option. They do not allow us to split the public API packages, so the Clipboard must go into the data transfer module.. > >> If that is not an option, then I'd go with a "service" for delayed execution approach. By default the service would provide synchronous dispatching of runnables, but AWT could override it with an implementation that calls invokeLater() under the hood. > I need some time to investigate this approach.. I?m not sure yet how would this work. The issue with this approach is that we are creating a very fragile API.. If the desktop module is present the callbacks would go asynchronously on EDT, if it?s not - synchronously. So imagine some third-patry component developed not for the desktop, but using the datatransfer module and a Clipboard as a simple holder for transferable. Then someone would reuse that component in the application which also uses AWT. And the notifications would suddenly and unpredictable transform to asynchronous. Nobody will ever understand what?s happening.. > > With best regards. Petr. > > 07 ???. 2014 ?., ? 9:06 ????? ???????, Anthony Petrov ???????(?): > >> The synchronous vs. asynchronous calling of handlers is a big issue, IMO. Some applications may not be ready for that. I wouldn't change that part unless there's a bug in that functionality. And AFAIK, there's none. >> >> As for other options, could you please provide more details on what exactly is required by the modularization project? Do they need to use the Clipboard class, or they actually only need a few other classes from the java.awt.datatransfer classes? In other words, can we keep the Clipboard class in the AWT module, and only move those other classes needed by RMI and friends to a separate module? >> >> If that is not an option, then I'd go with a "service" for delayed execution approach. By default the service would provide synchronous dispatching of runnables, but AWT could override it with an implementation that calls invokeLater() under the hood. >> >> -- >> best regards, >> Anthony >> >> On 4/7/2014 6:17 PM, Petr Pchelko wrote: >>>> They could also get it using Clipboard.getSystemClipboard(), and the latter could call >>>> the methods that you're changing from a non-EDT thread (directly or indirectly). >>> This is not an issue since the system clipboard is always an instance of a SunClipboard >>> which overrides these methods and uses SunToolkit.postEvent. And there's no API to >>> change the class of the returned system clipboard. >>> >>>> A user could obtain an instance of a Clipboard object by using its public constructor. >>> This is more interesting. If the user creates a Clipboard instance he has almost nothing to do with it. >>> The only place where the custom Clipboard could be passed is TransferHandler.exportToClipboard. >>> Indeed, after the change the Clipboard notifications will be called on the same thread where the >>> exportToClipboard is called, but as TransferHandler is the swing API is must be called on EDT, >>> so effectively nothing's changed. It might be an issue that the notifications become synchronous, >>> but I didn't find any problems with it. >>> >>>> In any case, the fix that you're proposing changes the threading contract for these methods considerably. >>>> And I don't think that this change is safe. >>> >>> Option 2 is not safe as well, but it's way more complicated... Do you have any suggestions about some other >>> options? >>> >>> Thank you. >>> With best regards. Petr. >>> >>> On 07.04.2014, at 18:00, Anthony Petrov wrote: >>> >>>> I'm aware of the reasons behind this issue. However, I'm still unsure whether this is a safe enough solution. A user could obtain an instance of a Clipboard object by using its public constructor. They could also get it using Clipboard.getSystemClipboard(), and the latter could call the methods that you're changing from a non-EDT thread (directly or indirectly). In any case, the fix that you're proposing changes the threading contract for these methods considerably. And I don't think that this change is safe. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 4/7/2014 5:52 PM, Petr Pchelko wrote: >>>>>> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on >>>>>> any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. >>>>> The FlavorListener and ClipboardOwner interfaces do not state that the callbacks would be called on EDT, so at least we are not breaking the spec. >>>>> The problem here is that Clipboard would be a part of a different module and must be independent from AWT or the desktop module. Even reflectively independent. >>>>> This means we have 2 options here: option 1 is implemented in the fix. >>>>> >>>>> Option 2 is to declare some "DelayedNotificationService", make the Clipboard look for this service using a ServiceLoader and make AWT implement the service >>>>> using the invokeLater. So if the Clipboard would be used in absence of desktop module it would deliver the notifications in place, and with the desktop module it will >>>>> use the invokeLater. Personally I think that the second option is way more fragile and unnecessary complicated. >>>>> >>>>> The only place where the Clipboard is used directly is in swing's sandbox clipboard, but it's used internally and only on EDT. And it does not leak to the user. >>>>> So if we just remove the invokeLater we would likely not break anything. With the second option I would not be so sure. >>>>> >>>>> With best regards. Petr. >>>>> >>>>> On 07.04.2014, at 17:42, Anthony Petrov wrote: >>>>> >>>>>> Hi Petr, >>>>>> >>>>>> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 4/7/2014 5:16 PM, Petr Pchelko wrote: >>>>>>> Hello, AWT Team. >>>>>>> >>>>>>> Please review the fix for the issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039377 >>>>>>> The fix is here: >>>>>>> http://cr.openjdk.java.net/~pchelko/9/8039377/webrev.00/ >>>>>>> >>>>>>> The problem: Clipboard depend on the EventQueue. The solution - remove the invokeLater. The Clipboard object is used only as a Swing sandbox clipboard which is used from the EDT. >>>>>>> The user can't use in as the System clipboard, so there's no worries about the callback being executed on some privileged thread. So we can simply remove the invokeLater here. >>>>>>> >>>>>>> With best regards. Petr. >>>>>>> >>>>> >>> > From Sergey.Bylokhov at oracle.com Mon Apr 7 17:57:49 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 07 Apr 2014 21:57:49 +0400 Subject: [9] Review Request: JDK-8039377 Clipboard should post notifications without using the EventQueue.invokeLater In-Reply-To: <1466BF89-A89F-410D-AFA7-933F20FD335F@oracle.com> References: <920C4A77-4730-4459-97BD-2C8CB5DF2378@oracle.com> <5342AB5D.8030305@oracle.com> <7C5A515A-1ECD-44F8-9985-40BEFB8D3B8F@oracle.com> <5342AF93.7000309@oracle.com> <5342DAFA.1080501@oracle.com> <1466BF89-A89F-410D-AFA7-933F20FD335F@oracle.com> Message-ID: <5342E71D.1020500@oracle.com> Note that this InvokeLater was added in 2003 by the omXXXXX as a fix for JDK-4259272. It have some useful information. On 07.04.2014 21:13, Petr Pchelko wrote: >> As for other options, could you please provide more details on what exactly is required by the modularization project? Do they need to use the Clipboard class, or they actually only need a few other classes from the java.awt.datatransfer classes? In other words, can we keep the Clipboard class in the AWT module, and only move those other classes needed by RMI and friends to a separate module? > Unfortunately that?s not an option. They do not allow us to split the public API packages, so the Clipboard must go into the data transfer module.. > >> If that is not an option, then I'd go with a "service" for delayed execution approach. By default the service would provide synchronous dispatching of runnables, but AWT could override it with an implementation that calls invokeLater() under the hood. > I need some time to investigate this approach.. I?m not sure yet how would this work. The issue with this approach is that we are creating a very fragile API.. If the desktop module is present the callbacks would go asynchronously on EDT, if it?s not - synchronously. So imagine some third-patry component developed not for the desktop, but using the datatransfer module and a Clipboard as a simple holder for transferable. Then someone would reuse that component in the application which also uses AWT. And the notifications would suddenly and unpredictable transform to asynchronous. Nobody will ever understand what?s happening.. > > With best regards. Petr. > > 07 ???. 2014 ?., ? 9:06 ????? ???????, Anthony Petrov ???????(?): > >> The synchronous vs. asynchronous calling of handlers is a big issue, IMO. Some applications may not be ready for that. I wouldn't change that part unless there's a bug in that functionality. And AFAIK, there's none. >> >> As for other options, could you please provide more details on what exactly is required by the modularization project? Do they need to use the Clipboard class, or they actually only need a few other classes from the java.awt.datatransfer classes? In other words, can we keep the Clipboard class in the AWT module, and only move those other classes needed by RMI and friends to a separate module? >> >> If that is not an option, then I'd go with a "service" for delayed execution approach. By default the service would provide synchronous dispatching of runnables, but AWT could override it with an implementation that calls invokeLater() under the hood. >> >> -- >> best regards, >> Anthony >> >> On 4/7/2014 6:17 PM, Petr Pchelko wrote: >>>> They could also get it using Clipboard.getSystemClipboard(), and the latter could call >>>> the methods that you're changing from a non-EDT thread (directly or indirectly). >>> This is not an issue since the system clipboard is always an instance of a SunClipboard >>> which overrides these methods and uses SunToolkit.postEvent. And there's no API to >>> change the class of the returned system clipboard. >>> >>>> A user could obtain an instance of a Clipboard object by using its public constructor. >>> This is more interesting. If the user creates a Clipboard instance he has almost nothing to do with it. >>> The only place where the custom Clipboard could be passed is TransferHandler.exportToClipboard. >>> Indeed, after the change the Clipboard notifications will be called on the same thread where the >>> exportToClipboard is called, but as TransferHandler is the swing API is must be called on EDT, >>> so effectively nothing's changed. It might be an issue that the notifications become synchronous, >>> but I didn't find any problems with it. >>> >>>> In any case, the fix that you're proposing changes the threading contract for these methods considerably. >>>> And I don't think that this change is safe. >>> Option 2 is not safe as well, but it's way more complicated... Do you have any suggestions about some other >>> options? >>> >>> Thank you. >>> With best regards. Petr. >>> >>> On 07.04.2014, at 18:00, Anthony Petrov wrote: >>> >>>> I'm aware of the reasons behind this issue. However, I'm still unsure whether this is a safe enough solution. A user could obtain an instance of a Clipboard object by using its public constructor. They could also get it using Clipboard.getSystemClipboard(), and the latter could call the methods that you're changing from a non-EDT thread (directly or indirectly). In any case, the fix that you're proposing changes the threading contract for these methods considerably. And I don't think that this change is safe. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 4/7/2014 5:52 PM, Petr Pchelko wrote: >>>>>> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on >>>>>> any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. >>>>> The FlavorListener and ClipboardOwner interfaces do not state that the callbacks would be called on EDT, so at least we are not breaking the spec. >>>>> The problem here is that Clipboard would be a part of a different module and must be independent from AWT or the desktop module. Even reflectively independent. >>>>> This means we have 2 options here: option 1 is implemented in the fix. >>>>> >>>>> Option 2 is to declare some "DelayedNotificationService", make the Clipboard look for this service using a ServiceLoader and make AWT implement the service >>>>> using the invokeLater. So if the Clipboard would be used in absence of desktop module it would deliver the notifications in place, and with the desktop module it will >>>>> use the invokeLater. Personally I think that the second option is way more fragile and unnecessary complicated. >>>>> >>>>> The only place where the Clipboard is used directly is in swing's sandbox clipboard, but it's used internally and only on EDT. And it does not leak to the user. >>>>> So if we just remove the invokeLater we would likely not break anything. With the second option I would not be so sure. >>>>> >>>>> With best regards. Petr. >>>>> >>>>> On 07.04.2014, at 17:42, Anthony Petrov wrote: >>>>> >>>>>> Hi Petr, >>>>>> >>>>>> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 4/7/2014 5:16 PM, Petr Pchelko wrote: >>>>>>> Hello, AWT Team. >>>>>>> >>>>>>> Please review the fix for the issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039377 >>>>>>> The fix is here: >>>>>>> http://cr.openjdk.java.net/~pchelko/9/8039377/webrev.00/ >>>>>>> >>>>>>> The problem: Clipboard depend on the EventQueue. The solution - remove the invokeLater. The Clipboard object is used only as a Swing sandbox clipboard which is used from the EDT. >>>>>>> The user can't use in as the System clipboard, so there's no worries about the callback being executed on some privileged thread. So we can simply remove the invokeLater here. >>>>>>> >>>>>>> With best regards. Petr. >>>>>>> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Apr 7 19:23:06 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 07 Apr 2014 23:23:06 +0400 Subject: [9] Review Request: 8038765 [macosx] Toolkit.sync should be implemented Message-ID: <5342FB1A.2060107@oracle.com> Hello. Please review the fix for jdk 9. In the fix Toolkit.sync() is implemented in the same way as on other platforms. Note that on OSX we need additional step to flush the native selectors queue, because all our rendering was done to offscreen texture. Bug: https://bugs.openjdk.java.net/browse/JDK-8038765 Webrev can be found at: http://cr.openjdk.java.net/~serb/8038765/webrev.00 -- Best regards, Sergey. From henry.jen at oracle.com Tue Apr 8 00:55:03 2014 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 07 Apr 2014 17:55:03 -0700 Subject: JDK9: RFR: 8039342: Fix raw and unchecked warnings in sun.awt.* In-Reply-To: <5343312E.4060207@oracle.com> References: <53430EAB.3090504@oracle.com> <5343312E.4060207@oracle.com> Message-ID: <534348E7.6010207@oracle.com> Thanks Joe for pointing out the request should go to awt-dev. Cheers, Henry On 04/07/2014 04:13 PM, Joe Darcy wrote: > Hi Henry, > > Thanks for looking into this. FWIW, while I was working on > > JDK-8039109: Fix unchecked and raw lint warnings in java.awt > > I started looking at some sun.awt.* type too and I noticed the same > problem in AreaOp.pruneEdges(). The comment I added to my in-progress > webrev is: > > 203 /* > 204 * The implementation of this method consistently treats its > 205 * return type either as a Vector or a Vector. > 206 */ > > so there does seem to be some internal inconsistency in what the Vector > is meant to hold. > > In any case, your changes look good to me. (I'll adapt my changes for > 8039109 based on your changes in this bug.) > > Cheers, > > -Joe > > On 04/07/2014 01:46 PM, Henry Jen wrote: >> Hi, >> >> Please review the webrev cleans up raw and unchecked warnings in sun.awt, >> >> http://cr.openjdk.java.net/~henryjen/jdk9/8039342/0/webrev/ >> >> The following changes in AreaOp::pruneEdges() is particular worth >> attention, when numedges < 2, two different type are mixed up in the >> past with use of rawtypes; However, I think it could only work if the >> Vector is empty? >> >> Cheers, >> Henry >> >> >>> @@ -193,16 +193,20 @@ >>> } >>> return 1; >>> } >>> }; >>> >>> - private Vector pruneEdges(Vector edges) { >>> + private Vector pruneEdges(Vector edges) { >>> int numedges = edges.size(); >>> if (numedges < 2) { >>> - return edges; >>> + Vector rt = new Vector<>(); >>> + for (Edge edge: edges) { >>> + rt.add(edge.getCurve()); >>> } >>> - Edge[] edgelist = (Edge[]) edges.toArray(new Edge[numedges]); >>> + return rt; >>> + } >>> + Edge[] edgelist = edges.toArray(new Edge[numedges]); >>> Arrays.sort(edgelist, YXTopComparator); >>> if (false) { >>> System.out.println("pruning: "); >>> for (int i = 0; i < numedges; i++) { >>> System.out.println("edgelist["+i+"] = "+edgelist[i]); >> > From petr.pchelko at oracle.com Tue Apr 8 08:49:17 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 8 Apr 2014 12:49:17 +0400 Subject: [9] Review Request: 8038765 [macosx] Toolkit.sync should be implemented In-Reply-To: <5342FB1A.2060107@oracle.com> References: <5342FB1A.2060107@oracle.com> Message-ID: <738F8540-9525-4F56-BB9B-C0E25E9B2521@oracle.com> Hello, Sergey. Why don't you add a boolean parameter to syncNativeQueue to avoid adding a new native method? With best regards. Petr. On 07.04.2014, at 23:23, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > In the fix Toolkit.sync() is implemented in the same way as on other platforms. Note that on OSX we need additional step to flush the native selectors queue, because all our rendering was done to offscreen texture. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8038765 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8038765/webrev.00 > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Tue Apr 8 09:53:16 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 08 Apr 2014 13:53:16 +0400 Subject: [9] Review Request: 8038765 [macosx] Toolkit.sync should be implemented In-Reply-To: <738F8540-9525-4F56-BB9B-C0E25E9B2521@oracle.com> References: <5342FB1A.2060107@oracle.com> <738F8540-9525-4F56-BB9B-C0E25E9B2521@oracle.com> Message-ID: <5343C70C.9010507@oracle.com> On 4/8/14 12:49 PM, Petr Pchelko wrote: > Hello, Sergey. > > Why don't you add a boolean parameter to syncNativeQueue to avoid adding a new native method? Two reasons: - syncNativeQueue will be reworked in the future, since it does not work correctly in all cases now. - If syncNativeQueue() will be reused, when I'll have to ignore its timeout parameter, this can be misleading > > With best regards. Petr. > > On 07.04.2014, at 23:23, Sergey Bylokhov wrote: > >> Hello. >> Please review the fix for jdk 9. >> In the fix Toolkit.sync() is implemented in the same way as on other platforms. Note that on OSX we need additional step to flush the native selectors queue, because all our rendering was done to offscreen texture. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8038765 >> Webrev can be found at: http://cr.openjdk.java.net/~serb/8038765/webrev.00 >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From petr.pchelko at oracle.com Tue Apr 8 10:12:06 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 8 Apr 2014 14:12:06 +0400 Subject: [9] Review Request: 8038765 [macosx] Toolkit.sync should be implemented In-Reply-To: <5343C70C.9010507@oracle.com> References: <5342FB1A.2060107@oracle.com> <738F8540-9525-4F56-BB9B-C0E25E9B2521@oracle.com> <5343C70C.9010507@oracle.com> Message-ID: Hello, Sergey. Thank you for the clarification. The fix looks good to me. With best regards. Petr. On 08.04.2014, at 13:53, Sergey Bylokhov wrote: > On 4/8/14 12:49 PM, Petr Pchelko wrote: >> Hello, Sergey. >> >> Why don't you add a boolean parameter to syncNativeQueue to avoid adding a new native method? > Two reasons: > - syncNativeQueue will be reworked in the future, since it does not work correctly in all cases now. > - If syncNativeQueue() will be reused, when I'll have to ignore its timeout parameter, this can be misleading >> >> With best regards. Petr. >> >> On 07.04.2014, at 23:23, Sergey Bylokhov wrote: >> >>> Hello. >>> Please review the fix for jdk 9. >>> In the fix Toolkit.sync() is implemented in the same way as on other platforms. Note that on OSX we need additional step to flush the native selectors queue, because all our rendering was done to offscreen texture. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038765 >>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8038765/webrev.00 >>> >>> -- >>> Best regards, Sergey. >>> > > > -- > Best regards, Sergey. > From petr.pchelko at oracle.com Tue Apr 8 10:47:36 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 8 Apr 2014 14:47:36 +0400 Subject: [9] Review Request: 8039267 Test closed/java/awt/Choice/ChoiceLocationTest/ChoiceLocationTest.html should be removed In-Reply-To: <533EACCB.3010709@oracle.com> References: <9BAE379B-E35F-498C-A67E-910D8835719A@oracle.com> <533EACCB.3010709@oracle.com> Message-ID: Hello, Could I get a second review on this trivial change? Thank you. With best regards. Petr. On 04.04.2014, at 16:59, Alexander Zvegintsev wrote: > Hello Petr, > > the fix looks good to me. > > Thanks, > > Alexander. > > On 04/04/2014 04:55 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review a simple fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8039267 >> The fix is available here: >> http://cr.openjdk.java.net/~pchelko/9/8039267/webrev/ >> >> As a part of JDK-7159566 this test was converted to automatic and moved to the open. But the original was not removed. >> >> Thank you. >> With best regards. Petr. > From alexandr.scherbatiy at oracle.com Tue Apr 8 11:12:25 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 08 Apr 2014 15:12:25 +0400 Subject: [9] Review Request: 8039267 Test closed/java/awt/Choice/ChoiceLocationTest/ChoiceLocationTest.html should be removed In-Reply-To: References: <9BAE379B-E35F-498C-A67E-910D8835719A@oracle.com> <533EACCB.3010709@oracle.com> Message-ID: <5343D999.7030803@oracle.com> The fix looks good for me. Thanks, Alexandr. On 4/8/2014 2:47 PM, Petr Pchelko wrote: > Hello, > > Could I get a second review on this trivial change? > > Thank you. > With best regards. Petr. > > On 04.04.2014, at 16:59, Alexander Zvegintsev wrote: > >> Hello Petr, >> >> the fix looks good to me. >> >> Thanks, >> >> Alexander. >> >> On 04/04/2014 04:55 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review a simple fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8039267 >>> The fix is available here: >>> http://cr.openjdk.java.net/~pchelko/9/8039267/webrev/ >>> >>> As a part of JDK-7159566 this test was converted to automatic and moved to the open. But the original was not removed. >>> >>> Thank you. >>> With best regards. Petr. From anthony.petrov at oracle.com Tue Apr 8 11:54:09 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 08 Apr 2014 15:54:09 +0400 Subject: [9] Review Request: 8038765 [macosx] Toolkit.sync should be implemented In-Reply-To: References: <5342FB1A.2060107@oracle.com> <738F8540-9525-4F56-BB9B-C0E25E9B2521@oracle.com> <5343C70C.9010507@oracle.com> Message-ID: <5343E361.9050802@oracle.com> +1 -- best regards, Anthony On 4/8/2014 2:12 PM, Petr Pchelko wrote: > Hello, Sergey. > > Thank you for the clarification. > > The fix looks good to me. > > With best regards. Petr. > > On 08.04.2014, at 13:53, Sergey Bylokhov wrote: > >> On 4/8/14 12:49 PM, Petr Pchelko wrote: >>> Hello, Sergey. >>> >>> Why don't you add a boolean parameter to syncNativeQueue to avoid adding a new native method? >> Two reasons: >> - syncNativeQueue will be reworked in the future, since it does not work correctly in all cases now. >> - If syncNativeQueue() will be reused, when I'll have to ignore its timeout parameter, this can be misleading >>> >>> With best regards. Petr. >>> >>> On 07.04.2014, at 23:23, Sergey Bylokhov wrote: >>> >>>> Hello. >>>> Please review the fix for jdk 9. >>>> In the fix Toolkit.sync() is implemented in the same way as on other platforms. Note that on OSX we need additional step to flush the native selectors queue, because all our rendering was done to offscreen texture. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038765 >>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8038765/webrev.00 >>>> >>>> -- >>>> Best regards, Sergey. >>>> >> >> >> -- >> Best regards, Sergey. >> > From dmitriy.ermashov at oracle.com Tue Apr 8 12:09:46 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Tue, 08 Apr 2014 16:09:46 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository Message-ID: <5343E70A.1070501@oracle.com> Hi, Please, review the changeset for: https://bugs.openjdk.java.net/browse/JDK-8039279 Webrev is here: http://cr.openjdk.java.net/~yan/8039279/webrev/ This is the first batch of functional AWT tests, that are prepared for migration to OpenJDK repository. Testlist: AWT_ZoomFrame/Automated/Frame/SetBoundsTest AWT_Robot/Automated/ModifierRobotKey AWT_Toolkit/Manual/LockingKeyStateTest AWT_LayoutTest/Automated/GridLayout/Layout AWT_LayoutTest/Automated/GridLayout/ChangeGrids Tests were switched on using jtreg, tested on the following platforms and seems stable: Windows 7 x64, Intel graphical card Ubuntu Linux 12.04 x64, Intel graphical card OS X 10.8.5 x64, NVIDIA GeForce 9400 Ubuntu 10.04 ARMv7 -- Thanks, Dima From mikhail.cherkasov at oracle.com Tue Apr 8 14:03:59 2014 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Tue, 08 Apr 2014 18:03:59 +0400 Subject: review request: focus disappears with shift+tab on dialogue having a focus component In-Reply-To: <52CE56C7.7050707@oracle.com> References: <52C2B1A1.8060803@oracle.com> <52CE56C7.7050707@oracle.com> Message-ID: <534401CF.6060007@oracle.com> Hi again, A regression test was added: http://cr.openjdk.java.net/~mcherkas/8031075/webrev.01/ Could you please review second version of webrev? Thanks, Mikhail. On 1/9/2014 11:59 AM, Sergey Bylokhov wrote: > Hi, Mikhail. > The fix looks good. But since this regression was not found by our > tests it would be good to add new one. > > On 31.12.2013 15:59, mikhail cherkasov wrote: >> Hello all, >> >> Could you please review the following fix: >> https://bugs.openjdk.java.net/browse/JDK-8031075 >> review request: focus disappears with shift+tab on dialogue having a >> focus component >> http://cr.openjdk.java.net/~mcherkas/8031075/webrev.00/ >> >> >> Jdk8 already has it, also it was in jdk7 too, but was mistakenly >> reverted by other fix, so >> I'm just returning it back. >> >> >> Thanks, >> Mikhail. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Apr 8 15:27:35 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 08 Apr 2014 19:27:35 +0400 Subject: [9] Review request for 8039001 [macosx] Textfields in dialogs are disabled after using F3 on Mac OS X to select a window Message-ID: <53441567.9070207@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8039001 webrev: http://cr.openjdk.java.net/~alexsch/8039001/webrev.00 NSRunningApplication active property is false when windowDidBecomeKey notification is received after switching from the Mission Control on Mac OS X to the modal dialog. The fix adds the isAppActive propery to the ApplicationDelegate and change it after the applicationWillBecomeActive/applicationWillResignActive notifications to track the application active state. It is difficult to write an automated test because it is hard to find the application coordinates in the Mission Control. Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Tue Apr 8 21:08:55 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 09 Apr 2014 01:08:55 +0400 Subject: [9] Review Request: 8039267 Test closed/java/awt/Choice/ChoiceLocationTest/ChoiceLocationTest.html should be removed In-Reply-To: References: <9BAE379B-E35F-498C-A67E-910D8835719A@oracle.com> <533EACCB.3010709@oracle.com> Message-ID: <53446567.4050301@oracle.com> On 4/8/14 2:47 PM, Petr Pchelko wrote: > Hello, > > Could I get a second review on this trivial change? webrev link is broken: 404 - Not Found > > Thank you. > With best regards. Petr. > > On 04.04.2014, at 16:59, Alexander Zvegintsev wrote: > >> Hello Petr, >> >> the fix looks good to me. >> >> Thanks, >> >> Alexander. >> >> On 04/04/2014 04:55 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review a simple fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8039267 >>> The fix is available here: >>> http://cr.openjdk.java.net/~pchelko/9/8039267/webrev/ >>> >>> As a part of JDK-7159566 this test was converted to automatic and moved to the open. But the original was not removed. >>> >>> Thank you. >>> With best regards. Petr. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.pchelko at oracle.com Wed Apr 9 06:31:48 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 9 Apr 2014 10:31:48 +0400 Subject: [9] Review request for 8038113 [macosx] JTree icon is not rendered in high resolution on Retina In-Reply-To: <5342C49E.8080504@oracle.com> References: <5332E0FE.5090807@oracle.com> <533C0072.1020306@oracle.com> <5342C49E.8080504@oracle.com> Message-ID: Hello, Alexander. The new version looks good to me. With best regards. Petr. On 07.04.2014, at 19:30, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8038113/webrev.02 > > - CachableJRSUIIcon explicitly implements Icon interface now > - getOptimizedImage() method is removed from the CachingScalingIcon because NSImage always scales an image to the requested size > - @Override annotation is added. > > Thanks, > Alexandr. > > On 4/2/2014 4:37 PM, Petr Pchelko wrote: >> Hello, Alexander. >> >> Could you please add the @Override to the paintIcon method. >> >> Also I suggest to reuse the paintIcon in the createIcon. >> >> With best regards. Petr. >> >> On 02.04.2014, at 16:20, Alexander Scherbatiy wrote: >> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8038113/webrev.01/ >>> >>> The CachableJRSUIIcon creates an image twice: in createImage() and in the AquaPainter.paint() methods. >>> >>> The fix paints the icon directly from the AquaPainter.paint() method which uses the properly scaled image. >>> >>> Thanks, >>> Alexandr. >>> >>> On 3/26/2014 6:15 PM, Alexander Scherbatiy wrote: >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038113 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8038113/webrev.00 >>>> >>>> MultiResolution image is used to create resolution variants for the JTree icons. >>>> >>>> The fix assumes that AquaPainter uses the graphics transform for the image size calculation >>>> an so depends on the fix for issue 8032667 [macosx] Components cannot be rendered in >>>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-March/007370.html >>>> >>>> Thanks, >>>> Alexandr. >>>> > From petr.pchelko at oracle.com Wed Apr 9 09:35:38 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 9 Apr 2014 13:35:38 +0400 Subject: [9] Review Request: 8039083 REGRESSION: closed/java/awt/dnd/DragSourceListenerSerializationTest/DragSourceListenerSerializationTest.html fails with NPE since 8u20 b07 on Linux In-Reply-To: <533D6025.1050303@oracle.com> References: <5E3F3E5C-2390-4E2B-A139-F893C848EE44@oracle.com> <533D6025.1050303@oracle.com> Message-ID: Hello, Is anybody willing to make the second review? Thank you. With best regards. Petr. On 03.04.2014, at 17:20, Alexander Zvegintsev wrote: > Hello Petr, > > the fix looks good to me. > > -- > Thanks, > Alexander. > > On 04/03/2014 03:23 PM, Petr Pchelko wrote: >> Hello, >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8039083 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/8039083/webrev/ >> >> When I?ve been making the validation on DnD classes deserialization I?ve over validated a little bit - the DragGestureRecognizer source actions are relying on a transient field, so we not to check the sourceActions from the DragSourceContext field instead. I?m also open-sourcing and cleaning up the test. >> >> With best regards. Petr. > From alexandr.scherbatiy at oracle.com Wed Apr 9 10:20:35 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 09 Apr 2014 14:20:35 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <53429254.3070501@oracle.com> References: <533D64BC.8080202@oracle.com> <533EB86D.8080309@oracle.com> <533EC98A.7090906@oracle.com> <2CBCC54C-85DC-48D9-A613-32699134DF0A@oracle.com> <534262A7.1040300@oracle.com> <53429254.3070501@oracle.com> Message-ID: <53451EF3.9040204@oracle.com> On 4/7/2014 3:56 PM, Dmitriy Ermashov wrote: > Hi, Sergey > > Do you have any additions? > http://cr.openjdk.java.net/~yan/8038631/webrev.06/ > Will the AccessController.doPrivileged() block work under the Security manager if the ExtendedRobot package is not listed in the "package.access" list? Thanks, Alexandr. > -- > Thanks, > Dima > > > On 04/07/2014 12:32 PM, Alexander Zvegintsev wrote: >> Hello Dmitriy, >> >> this version looks good to me. >> >> Thanks, >> >> Alexander. >> >> On 04/04/2014 11:32 PM, Petr Pchelko wrote: >>> Hello, Dmitry. >>> >>> This version looks great. >>> >>> With best regards. Petr. >>> >>> 04 ???. 2014 ?., ? 8:16 ????? ???????, Dmitriy Ermashov >>> ???????(?): >>> >>>> Hi, >>>> Please, review the changeset for: >>>> https://bugs.openjdk.java.net/browse/JDK-8038631 >>>> >>>> Webrev is here: >>>> http://cr.openjdk.java.net/~yan/8038631/webrev.06/ >>>> >>>> Last changes consist of: >>>> 1. Removed if clause from class initialization section >>>> >>>> ? >>>> >>>> Thanks, >>>> Dima >>>> >>>> >> > From petr.pchelko at oracle.com Wed Apr 9 10:24:36 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 9 Apr 2014 14:24:36 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <5343E70A.1070501@oracle.com> References: <5343E70A.1070501@oracle.com> Message-ID: <34E9C300-111A-4E7B-A31D-6F25D544888C@oracle.com> Hello, Dmitriy. 1. Could you please not use the applet pattern in automatic tests? We normally get rid of this in all the tests we touch/write, because it's useless and slows down the test execution. So please rewrite SetBoundsTest to use main. 2. ../../../../lib/testlibrary could be replaces to just /lib/testlibrary. 3. I see that you are using printStackTrace + System.exit to fail the test. We normally just throw the RuntimeException or state that main throws Exception, do not add catch blocks and let exceptions propagate out of main. jtreg would catch them, report error nicely and fail the test. I'm not sure which pattern is better, so it worths discussing.. 4. ModifierRobotKey : System.getProperty("os.name").trim().substring(0, 3).toUpperCase().equals("SUN") you can replace this to use the OSInfo class. It's way mode reliable. 5. ModifierRobotKey: Toolkit.getDefaultToolkit().getSystemEventQueue().invokeAndWait - Why no use SwingUtilities? 6. General comment: since this is going to 9 you could use lambdas wherever possible. 7. ModifierRobotTest: 131 canvas.addFocusListener(new FocusListener() - could be replaced with an Adapter. 8. Another general comment: the lib/testlibrary has an Asserts class - it could be used where possible. The assertTrue(focusGained, "Canvas focus gained"); looks much cleaner than if (!focusGained) { System.err.println("FAIL: Canvas failed to gain focus!"); System.exit(1); } Of coarse it could be used only if we switch to "throw exception and not catch" pattern instead of the "System.exit" pattern. 9. LockingKeyStateTest - I don't like the pattern with the "result" variable. First of all - why it's an int if it's really should be a boolean? Secondly, why are we continuing the test execution after we've found an error? Who cares that all the rest of assertions are true or not, the test is already failed anyway. I'd rather just throw an Exception in place and stop the execution. The most of my comments are a bit controversial, I just want to run the discussion of these points, because this is the first portion of tests added and we are setting up the patterns now... With best regards. Petr On 08.04.2014, at 16:09, Dmitriy Ermashov wrote: > Hi, > Please, review the changeset for: > https://bugs.openjdk.java.net/browse/JDK-8039279 > > Webrev is here: > http://cr.openjdk.java.net/~yan/8039279/webrev/ > > This is the first batch of functional AWT tests, that are prepared for migration to OpenJDK repository. > Testlist: > AWT_ZoomFrame/Automated/Frame/SetBoundsTest > AWT_Robot/Automated/ModifierRobotKey > AWT_Toolkit/Manual/LockingKeyStateTest > AWT_LayoutTest/Automated/GridLayout/Layout > AWT_LayoutTest/Automated/GridLayout/ChangeGrids > > Tests were switched on using jtreg, tested on the following platforms and seems stable: > Windows 7 x64, Intel graphical card > Ubuntu Linux 12.04 x64, Intel graphical card > OS X 10.8.5 x64, NVIDIA GeForce 9400 > Ubuntu 10.04 ARMv7 > > -- > Thanks, > Dima > From Sergey.Bylokhov at oracle.com Wed Apr 9 10:49:32 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 09 Apr 2014 14:49:32 +0400 Subject: [9] Review Request: 8039083 REGRESSION: closed/java/awt/dnd/DragSourceListenerSerializationTest/DragSourceListenerSerializationTest.html fails with NPE since 8u20 b07 on Linux In-Reply-To: References: <5E3F3E5C-2390-4E2B-A139-F893C848EE44@oracle.com> <533D6025.1050303@oracle.com> Message-ID: <534525BC.8050006@oracle.com> On 4/9/14 1:35 PM, Petr Pchelko wrote: > Hello, > > Is anybody willing to make the second review? Looks fine. > > Thank you. > With best regards. Petr. > > On 03.04.2014, at 17:20, Alexander Zvegintsev wrote: > >> Hello Petr, >> >> the fix looks good to me. >> >> -- >> Thanks, >> Alexander. >> >> On 04/03/2014 03:23 PM, Petr Pchelko wrote: >>> Hello, >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8039083 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/9/8039083/webrev/ >>> >>> When I?ve been making the validation on DnD classes deserialization I?ve over validated a little bit - the DragGestureRecognizer source actions are relying on a transient field, so we not to check the sourceActions from the DragSourceContext field instead. I?m also open-sourcing and cleaning up the test. >>> >>> With best regards. Petr. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Apr 9 10:54:06 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 09 Apr 2014 14:54:06 +0400 Subject: [9] Review request for 8038113 [macosx] JTree icon is not rendered in high resolution on Retina In-Reply-To: <5342C49E.8080504@oracle.com> References: <5332E0FE.5090807@oracle.com> <533C0072.1020306@oracle.com> <5342C49E.8080504@oracle.com> Message-ID: <534526CE.9020602@oracle.com> Hi, Alexander. The fix looks good. But can you remove the text " in Quartz" from the comments before the push. Thanks. On 4/7/14 7:30 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8038113/webrev.02 > > - CachableJRSUIIcon explicitly implements Icon interface now > - getOptimizedImage() method is removed from the CachingScalingIcon > because NSImage always scales an image to the requested size > - @Override annotation is added. > > Thanks, > Alexandr. > > On 4/2/2014 4:37 PM, Petr Pchelko wrote: >> Hello, Alexander. >> >> Could you please add the @Override to the paintIcon method. >> >> Also I suggest to reuse the paintIcon in the createIcon. >> >> With best regards. Petr. >> >> On 02.04.2014, at 16:20, Alexander Scherbatiy >> wrote: >> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8038113/webrev.01/ >>> >>> The CachableJRSUIIcon creates an image twice: in createImage() and >>> in the AquaPainter.paint() methods. >>> >>> The fix paints the icon directly from the AquaPainter.paint() >>> method which uses the properly scaled image. >>> >>> Thanks, >>> Alexandr. >>> >>> On 3/26/2014 6:15 PM, Alexander Scherbatiy wrote: >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038113 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8038113/webrev.00 >>>> >>>> MultiResolution image is used to create resolution variants for >>>> the JTree icons. >>>> >>>> The fix assumes that AquaPainter uses the graphics transform for >>>> the image size calculation >>>> an so depends on the fix for issue 8032667 [macosx] Components >>>> cannot be rendered in >>>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-March/007370.html >>>> >>>> Thanks, >>>> Alexandr. >>>> > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.cherkasov at oracle.com Wed Apr 9 11:02:07 2014 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Wed, 09 Apr 2014 15:02:07 +0400 Subject: Review request for JDK-8032961: A JTextField of an applet loses the abillity to receive the focus under certain circumstances. Message-ID: <534528AF.1030702@oracle.com> Hi all, please review the fix: http://cr.openjdk.java.net/~mcherkas/8032961/jdk9/webrev.00/ for the following bug: https://bugs.openjdk.java.net/browse/JDK-8032961 The problem is that when we create modal dialog we can't set the whole browser as its parent window, due some limitation of browser API. So that means we have to emulate modal dialog behavior. When modal dialog is opened applet reject focus events - so the applet in browser can not become active while modal dialog is opened. As result we can get in situation when modal dialog is closed, but applet is inactive and doesn't recognize any user input. The fix tracks closing modal dialogs and if browser active it activates applet too. Thanks, Mikhail. From petr.pchelko at oracle.com Wed Apr 9 11:06:18 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 9 Apr 2014 15:06:18 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <34E9C300-111A-4E7B-A31D-6F25D544888C@oracle.com> References: <5343E70A.1070501@oracle.com> <34E9C300-111A-4E7B-A31D-6F25D544888C@oracle.com> Message-ID: <60C65812-9BBF-4963-9F8C-84BF629454E8@oracle.com> Hello, Dmitry. > 2. ../../../../lib/testlibrary could be replaces to just /lib/testlibrary. Actually this is incorrect, sorry. With best regards. Petr. On 09.04.2014, at 14:24, Petr Pchelko wrote: > Hello, Dmitriy. > > 1. Could you please not use the applet pattern in automatic tests? > We normally get rid of this in all the tests we touch/write, because it's useless and slows down the test execution. > So please rewrite SetBoundsTest to use main. > > 2. ../../../../lib/testlibrary could be replaces to just /lib/testlibrary. > > 3. I see that you are using printStackTrace + System.exit to fail the test. We normally just throw the RuntimeException > or state that main throws Exception, do not add catch blocks and let exceptions propagate out of main. jtreg would catch them, > report error nicely and fail the test. > I'm not sure which pattern is better, so it worths discussing.. > > 4. ModifierRobotKey : System.getProperty("os.name").trim().substring(0, 3).toUpperCase().equals("SUN") you can replace this > to use the OSInfo class. It's way mode reliable. > > 5. ModifierRobotKey: Toolkit.getDefaultToolkit().getSystemEventQueue().invokeAndWait - Why no use SwingUtilities? > > 6. General comment: since this is going to 9 you could use lambdas wherever possible. > > 7. ModifierRobotTest: 131 canvas.addFocusListener(new FocusListener() - could be replaced with an Adapter. > > 8. Another general comment: the lib/testlibrary has an Asserts class - it could be used where possible. The > > assertTrue(focusGained, "Canvas focus gained"); > > looks much cleaner than > > if (!focusGained) { > System.err.println("FAIL: Canvas failed to gain focus!"); > System.exit(1); > } > > Of coarse it could be used only if we switch to "throw exception and not catch" pattern instead of the "System.exit" pattern. > > 9. LockingKeyStateTest - I don't like the pattern with the "result" variable. First of all - why it's an int if it's really should be a boolean? > Secondly, why are we continuing the test execution after we've found an error? Who cares that all the rest of assertions are true or not, > the test is already failed anyway. I'd rather just throw an Exception in place and stop the execution. > > The most of my comments are a bit controversial, I just want to run the discussion of these points, because this is the first portion of tests > added and we are setting up the patterns now... > > With best regards. Petr > > On 08.04.2014, at 16:09, Dmitriy Ermashov wrote: > >> Hi, >> Please, review the changeset for: >> https://bugs.openjdk.java.net/browse/JDK-8039279 >> >> Webrev is here: >> http://cr.openjdk.java.net/~yan/8039279/webrev/ >> >> This is the first batch of functional AWT tests, that are prepared for migration to OpenJDK repository. >> Testlist: >> AWT_ZoomFrame/Automated/Frame/SetBoundsTest >> AWT_Robot/Automated/ModifierRobotKey >> AWT_Toolkit/Manual/LockingKeyStateTest >> AWT_LayoutTest/Automated/GridLayout/Layout >> AWT_LayoutTest/Automated/GridLayout/ChangeGrids >> >> Tests were switched on using jtreg, tested on the following platforms and seems stable: >> Windows 7 x64, Intel graphical card >> Ubuntu Linux 12.04 x64, Intel graphical card >> OS X 10.8.5 x64, NVIDIA GeForce 9400 >> Ubuntu 10.04 ARMv7 >> >> -- >> Thanks, >> Dima >> > From anthony.petrov at oracle.com Wed Apr 9 11:08:30 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 09 Apr 2014 15:08:30 +0400 Subject: Review request for JDK-8032961: A JTextField of an applet loses the abillity to receive the focus under certain circumstances. In-Reply-To: <534528AF.1030702@oracle.com> References: <534528AF.1030702@oracle.com> Message-ID: <53452A2E.2070607@oracle.com> Hi Michail, Instead of handling the WINDOW_CLOSED event in the CEmbeddedFrame class, can we make the Dialog peer do something upon closing? From Java perspective, the Dialog knows about its parent, so at the peer's level the dialog peer could simply call a method in the CEmbeddedFrame when the dialog is closing. -- best regards, Anthony On 4/9/2014 3:02 PM, mikhail cherkasov wrote: > Hi all, > > please review the fix: > http://cr.openjdk.java.net/~mcherkas/8032961/jdk9/webrev.00/ > for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8032961 > > The problem is that when we create modal dialog we can't set the > whole browser as its parent window, due some limitation of browser API. > So that means we have to emulate modal dialog behavior. > When modal dialog is opened applet reject focus events - so the applet in > browser can not become active while modal dialog is opened. > As result we can get in situation when modal dialog is closed, but > applet is inactive > and doesn't recognize any user input. > The fix tracks closing modal dialogs and if browser active it activates > applet too. > > Thanks, > Mikhail. > From dmitriy.ermashov at oracle.com Wed Apr 9 12:50:26 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Wed, 09 Apr 2014 16:50:26 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality Message-ID: <53454212.5060408@oracle.com> Hi, Please, review the changeset for: https://bugs.openjdk.java.net/browse/JDK-8038631 Webrev is here: http://cr.openjdk.java.net/~yan/8038631/webrev.06/ Last changes consist of: 1. Commented block with "java.awt.robotdelay" property read Also the bug JDK-8039749 was created to track the removing all java.awt.Robot heirs from OpnJDK repository. -- Thanks, Dima From petr.pchelko at oracle.com Wed Apr 9 12:53:06 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 9 Apr 2014 16:53:06 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <53454212.5060408@oracle.com> References: <53454212.5060408@oracle.com> Message-ID: <7C71A831-5BC3-4917-AFD0-0881BC8BDBD2@oracle.com> Hello, Dmitriy. I assume the correct link is http://cr.openjdk.java.net/~yan/8038631/webrev.07 Looks good. With best regards. Petr. On 09.04.2014, at 16:50, Dmitriy Ermashov wrote: > Hi, > Please, review the changeset for: > https://bugs.openjdk.java.net/browse/JDK-8038631 > > Webrev is here: > http://cr.openjdk.java.net/~yan/8038631/webrev.06/ > > Last changes consist of: > 1. Commented block with "java.awt.robotdelay" property read > > Also the bug JDK-8039749 was created to track the removing all java.awt.Robot heirs from OpnJDK repository. > > -- > Thanks, > Dima > From dmitriy.ermashov at oracle.com Wed Apr 9 12:54:26 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Wed, 09 Apr 2014 16:54:26 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <7C71A831-5BC3-4917-AFD0-0881BC8BDBD2@oracle.com> References: <53454212.5060408@oracle.com> <7C71A831-5BC3-4917-AFD0-0881BC8BDBD2@oracle.com> Message-ID: <53454302.3030209@oracle.com> Sure, the correct URL is your one. Thanks! On 04/09/2014 04:53 PM, Petr Pchelko wrote: > Hello, Dmitriy. > > I assume the correct link is http://cr.openjdk.java.net/~yan/8038631/webrev.07 > > Looks good. > > With best regards. Petr. > > On 09.04.2014, at 16:50, Dmitriy Ermashov wrote: > >> Hi, >> Please, review the changeset for: >> https://bugs.openjdk.java.net/browse/JDK-8038631 >> >> Webrev is here: >> http://cr.openjdk.java.net/~yan/8038631/webrev.06/ >> >> Last changes consist of: >> 1. Commented block with "java.awt.robotdelay" property read >> >> Also the bug JDK-8039749 was created to track the removing all java.awt.Robot heirs from OpnJDK repository. >> >> -- >> Thanks, >> Dima >> -- Thanks, Dima From mikhail.cherkasov at oracle.com Wed Apr 9 12:57:45 2014 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Wed, 09 Apr 2014 16:57:45 +0400 Subject: Review request for JDK-8032961: A JTextField of an applet loses the abillity to receive the focus under certain circumstances. In-Reply-To: <53452A2E.2070607@oracle.com> References: <534528AF.1030702@oracle.com> <53452A2E.2070607@oracle.com> Message-ID: <534543C9.6050208@oracle.com> Hi Anthony, this problem is specific only for applets and doesn't touch usual application, now I think the best place for this code is PluginEmbeddedFrame. I'll check this... Thanks, Mikhail. On 4/9/2014 3:08 PM, Anthony Petrov wrote: > Hi Michail, > > Instead of handling the WINDOW_CLOSED event in the CEmbeddedFrame > class, can we make the Dialog peer do something upon closing? From > Java perspective, the Dialog knows about its parent, so at the peer's > level the dialog peer could simply call a method in the CEmbeddedFrame > when the dialog is closing. > > -- > best regards, > Anthony > > On 4/9/2014 3:02 PM, mikhail cherkasov wrote: >> Hi all, >> >> please review the fix: >> http://cr.openjdk.java.net/~mcherkas/8032961/jdk9/webrev.00/ >> for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8032961 >> >> The problem is that when we create modal dialog we can't set the >> whole browser as its parent window, due some limitation of browser >> API. >> So that means we have to emulate modal dialog behavior. >> When modal dialog is opened applet reject focus events - so the >> applet in >> browser can not become active while modal dialog is opened. >> As result we can get in situation when modal dialog is closed, but >> applet is inactive >> and doesn't recognize any user input. >> The fix tracks closing modal dialogs and if browser active it activates >> applet too. >> >> Thanks, >> Mikhail. >> From alexandr.scherbatiy at oracle.com Wed Apr 9 13:19:33 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 09 Apr 2014 17:19:33 +0400 Subject: Review request for JDK-8038631: Create wrapper for awt.Robot with additional functionality In-Reply-To: <53454302.3030209@oracle.com> References: <53454212.5060408@oracle.com> <7C71A831-5BC3-4917-AFD0-0881BC8BDBD2@oracle.com> <53454302.3030209@oracle.com> Message-ID: <534548E5.4040609@oracle.com> The fix looks good for me. Thanks, Alexandr. On 4/9/2014 4:54 PM, Dmitriy Ermashov wrote: > Sure, the correct URL is your one. Thanks! > > On 04/09/2014 04:53 PM, Petr Pchelko wrote: >> Hello, Dmitriy. >> >> I assume the correct link is >> http://cr.openjdk.java.net/~yan/8038631/webrev.07 >> >> Looks good. >> >> With best regards. Petr. >> >> On 09.04.2014, at 16:50, Dmitriy Ermashov >> wrote: >> >>> Hi, >>> Please, review the changeset for: >>> https://bugs.openjdk.java.net/browse/JDK-8038631 >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~yan/8038631/webrev.06/ >>> >>> Last changes consist of: >>> 1. Commented block with "java.awt.robotdelay" property read >>> >>> Also the bug JDK-8039749 was created to track the removing all >>> java.awt.Robot heirs from OpnJDK repository. >>> >>> -- >>> Thanks, >>> Dima >>> > From petr.pchelko at oracle.com Wed Apr 9 13:43:05 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 9 Apr 2014 17:43:05 +0400 Subject: [9] Review Request: 8039752 Regression: Clipboard couldn't be used on linux Message-ID: <3188B43B-AF9B-4C67-B274-1341F0A9E229@oracle.com> Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8039752 The fix is available at: http://cr.openjdk.java.net/~pchelko/9/8039752/webrev/ I've recently made this regression( The currentDataFlavors was moved to the Clipboard constructor, but it could possibly call overridable methods which could use the system clipboard. And it's not constructed at this time which causes an NPE on Linux. In this fix I'm moving back to lazy initialization of the flavorListeners and currentDataFlavors. FYI: here's the fix that caused this regression: http://cr.openjdk.java.net/~pchelko/9/6463901/webrev.02/ With best regards. Petr. From anthony.petrov at oracle.com Wed Apr 9 13:48:15 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 09 Apr 2014 17:48:15 +0400 Subject: [9] Review Request: 8039752 Regression: Clipboard couldn't be used on linux In-Reply-To: <3188B43B-AF9B-4C67-B274-1341F0A9E229@oracle.com> References: <3188B43B-AF9B-4C67-B274-1341F0A9E229@oracle.com> Message-ID: <53454F9F.1010306@oracle.com> Hi Petr, The fix looks fine to me. -- best regards, Anthony On 4/9/2014 5:43 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8039752 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8039752/webrev/ > > I've recently made this regression( The currentDataFlavors was moved to the Clipboard constructor, > but it could possibly call overridable methods which could use the system clipboard. And it's not > constructed at this time which causes an NPE on Linux. > > In this fix I'm moving back to lazy initialization of the flavorListeners and currentDataFlavors. > > FYI: here's the fix that caused this regression: http://cr.openjdk.java.net/~pchelko/9/6463901/webrev.02/ > > With best regards. Petr. > From Sergey.Bylokhov at oracle.com Wed Apr 9 13:58:52 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 09 Apr 2014 17:58:52 +0400 Subject: [9] Review Request: 8039752 Regression: Clipboard couldn't be used on linux In-Reply-To: <3188B43B-AF9B-4C67-B274-1341F0A9E229@oracle.com> References: <3188B43B-AF9B-4C67-B274-1341F0A9E229@oracle.com> Message-ID: <5345521C.7080104@oracle.com> Looks fine. On 4/9/14 5:43 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8039752 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8039752/webrev/ > > I've recently made this regression( The currentDataFlavors was moved to the Clipboard constructor, > but it could possibly call overridable methods which could use the system clipboard. And it's not > constructed at this time which causes an NPE on Linux. > > In this fix I'm moving back to lazy initialization of the flavorListeners and currentDataFlavors. > > FYI: here's the fix that caused this regression: http://cr.openjdk.java.net/~pchelko/9/6463901/webrev.02/ > > With best regards. Petr. -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Wed Apr 9 14:03:36 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 09 Apr 2014 18:03:36 +0400 Subject: [9] Review Request: 8039752 Regression: Clipboard couldn't be used on linux In-Reply-To: <3188B43B-AF9B-4C67-B274-1341F0A9E229@oracle.com> References: <3188B43B-AF9B-4C67-B274-1341F0A9E229@oracle.com> Message-ID: <53455338.1060606@oracle.com> Hi Petr, the fix looks fine to me too. Thanks, Alexander. On 04/09/2014 05:43 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8039752 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8039752/webrev/ > > I've recently made this regression( The currentDataFlavors was moved to the Clipboard constructor, > but it could possibly call overridable methods which could use the system clipboard. And it's not > constructed at this time which causes an NPE on Linux. > > In this fix I'm moving back to lazy initialization of the flavorListeners and currentDataFlavors. > > FYI: here's the fix that caused this regression: http://cr.openjdk.java.net/~pchelko/9/6463901/webrev.02/ > > With best regards. Petr. From petr.pchelko at oracle.com Wed Apr 9 14:27:15 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 9 Apr 2014 18:27:15 +0400 Subject: [9] Review Request: 8039567 Duplicated code in DataTransferer Message-ID: <06D2CA5B-B72A-46D4-A611-08AD640828B2@oracle.com> Hello AWT team. Please review a simple cleanup fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8039567 The fix is available here: http://cr.openjdk.java.net/~pchelko/9/8039567/webrev/ 1. The getBestCharsetForTextFormat is duplicated 3 times in the code. 2. Caching of the default Charset in DataTransferer does not make sense as it's already cached in the Charset class itself. Adding more references to the nio.Charset is not a problem since it's used in this class anyway and we cannot break this dependency. With best regards. Petr. From alexander.zvegintsev at oracle.com Wed Apr 9 14:57:59 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 09 Apr 2014 18:57:59 +0400 Subject: [9] Review Request: 8039567 Duplicated code in DataTransferer In-Reply-To: <06D2CA5B-B72A-46D4-A611-08AD640828B2@oracle.com> References: <06D2CA5B-B72A-46D4-A611-08AD640828B2@oracle.com> Message-ID: <53455FF7.7070901@oracle.com> Hi Petr, the fix looks good to me. Thanks, Alexander. On 04/09/2014 06:27 PM, Petr Pchelko wrote: > Hello AWT team. > > Please review a simple cleanup fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8039567 > The fix is available here: > http://cr.openjdk.java.net/~pchelko/9/8039567/webrev/ > > 1. The getBestCharsetForTextFormat is duplicated 3 times in the code. > 2. Caching of the default Charset in DataTransferer does not make sense as it's already cached in the Charset class itself. > Adding more references to the nio.Charset is not a problem since it's used in this class anyway and we cannot break this > dependency. > > With best regards. Petr. From philip.race at oracle.com Wed Apr 9 21:35:40 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 09 Apr 2014 14:35:40 -0700 Subject: JDK9: RFR: 8039342: Fix raw and unchecked warnings in sun.awt.* In-Reply-To: <534348E7.6010207@oracle.com> References: <53430EAB.3090504@oracle.com> <5343312E.4060207@oracle.com> <534348E7.6010207@oracle.com> Message-ID: <5345BD2C.2020104@oracle.com> Yes it looks to be about 70% AWT and about 30% 2d .. Remember there's a magic decoder ring at http://openjdk.java.net/groups/2d/2dawtfiles.html It may not have 100% coverage but it should help. I looked over the 2D ones as below .. src/share/classes/sun/awt/FontConfiguration.java src/share/classes/sun/awt/PlatformFont.java src/share/classes/sun/awt/geom/AreaOp.java src/share/classes/sun/awt/geom/Crossings.java src/share/classes/sun/awt/geom/Curve.java src/share/classes/sun/awt/geom/Order2.java src/share/classes/sun/awt/geom/Order3.java src/share/classes/sun/awt/image/BufImgSurfaceData.java src/share/classes/sun/awt/image/GifImageDecoder.java src/share/classes/sun/awt/image/ImageDecoder.java src/share/classes/sun/awt/image/ImageFetcher.java src/share/classes/sun/awt/image/ImageRepresentation.java src/share/classes/sun/awt/image/ImagingLib.java src/share/classes/sun/awt/image/JPEGImageDecoder.java src/share/classes/sun/awt/image/OffScreenImageSource.java src/share/classes/sun/awt/image/PNGImageDecoder.java src/share/classes/sun/awt/image/ToolkitImage.java src/solaris/classes/sun/awt/X11FontManager.java src/solaris/classes/sun/awt/X11GraphicsDevice.java src/solaris/classes/sun/awt/X11GraphicsEnvironment.java src/solaris/classes/sun/awt/motif/MFontConfiguration.java It seems fine except that 1. How are you testing all these changes ? 2. The changes in sun/awt/geom need closer examination and I would really like Jim to weigh in on those .. -phil. On 4/7/2014 5:55 PM, Henry Jen wrote: > Thanks Joe for pointing out the request should go to awt-dev. > > Cheers, > Henry > > > On 04/07/2014 04:13 PM, Joe Darcy wrote: >> Hi Henry, >> >> Thanks for looking into this. FWIW, while I was working on >> >> JDK-8039109: Fix unchecked and raw lint warnings in java.awt >> >> I started looking at some sun.awt.* type too and I noticed the same >> problem in AreaOp.pruneEdges(). The comment I added to my in-progress >> webrev is: >> >> 203 /* >> 204 * The implementation of this method consistently >> treats its >> 205 * return type either as a Vector or a >> Vector. >> 206 */ >> >> so there does seem to be some internal inconsistency in what the Vector >> is meant to hold. >> >> In any case, your changes look good to me. (I'll adapt my changes for >> 8039109 based on your changes in this bug.) >> >> Cheers, >> >> -Joe >> >> On 04/07/2014 01:46 PM, Henry Jen wrote: >>> Hi, >>> >>> Please review the webrev cleans up raw and unchecked warnings in >>> sun.awt, >>> >>> http://cr.openjdk.java.net/~henryjen/jdk9/8039342/0/webrev/ >>> >>> The following changes in AreaOp::pruneEdges() is particular worth >>> attention, when numedges < 2, two different type are mixed up in the >>> past with use of rawtypes; However, I think it could only work if the >>> Vector is empty? >>> >>> Cheers, >>> Henry >>> >>> >>>> @@ -193,16 +193,20 @@ >>>> } >>>> return 1; >>>> } >>>> }; >>>> >>>> - private Vector pruneEdges(Vector edges) { >>>> + private Vector pruneEdges(Vector edges) { >>>> int numedges = edges.size(); >>>> if (numedges < 2) { >>>> - return edges; >>>> + Vector rt = new Vector<>(); >>>> + for (Edge edge: edges) { >>>> + rt.add(edge.getCurve()); >>>> } >>>> - Edge[] edgelist = (Edge[]) edges.toArray(new Edge[numedges]); >>>> + return rt; >>>> + } >>>> + Edge[] edgelist = edges.toArray(new Edge[numedges]); >>>> Arrays.sort(edgelist, YXTopComparator); >>>> if (false) { >>>> System.out.println("pruning: "); >>>> for (int i = 0; i < numedges; i++) { >>>> System.out.println("edgelist["+i+"] = "+edgelist[i]); >>> >> From henry.jen at oracle.com Wed Apr 9 22:31:25 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 09 Apr 2014 15:31:25 -0700 Subject: JDK9: RFR: 8039342: Fix raw and unchecked warnings in sun.awt.* In-Reply-To: <5345BD2C.2020104@oracle.com> References: <53430EAB.3090504@oracle.com> <5343312E.4060207@oracle.com> <534348E7.6010207@oracle.com> <5345BD2C.2020104@oracle.com> Message-ID: <5345CA3D.5000008@oracle.com> On 04/09/2014 02:35 PM, Phil Race wrote: > Yes it looks to be about 70% AWT and about 30% 2d .. > > Remember there's a magic decoder ring at > http://openjdk.java.net/groups/2d/2dawtfiles.html > It may not have 100% coverage but it should help. > > I looked over the 2D ones as below .. > > src/share/classes/sun/awt/FontConfiguration.java > src/share/classes/sun/awt/PlatformFont.java > src/share/classes/sun/awt/geom/AreaOp.java > src/share/classes/sun/awt/geom/Crossings.java > src/share/classes/sun/awt/geom/Curve.java > src/share/classes/sun/awt/geom/Order2.java > src/share/classes/sun/awt/geom/Order3.java > src/share/classes/sun/awt/image/BufImgSurfaceData.java > src/share/classes/sun/awt/image/GifImageDecoder.java > src/share/classes/sun/awt/image/ImageDecoder.java > src/share/classes/sun/awt/image/ImageFetcher.java > src/share/classes/sun/awt/image/ImageRepresentation.java > src/share/classes/sun/awt/image/ImagingLib.java > src/share/classes/sun/awt/image/JPEGImageDecoder.java > src/share/classes/sun/awt/image/OffScreenImageSource.java > src/share/classes/sun/awt/image/PNGImageDecoder.java > src/share/classes/sun/awt/image/ToolkitImage.java > src/solaris/classes/sun/awt/X11FontManager.java > src/solaris/classes/sun/awt/X11GraphicsDevice.java > src/solaris/classes/sun/awt/X11GraphicsEnvironment.java > src/solaris/classes/sun/awt/motif/MFontConfiguration.java > > It seems fine except that > 1. How are you testing all these changes ? > I ran jtreg on test/sun/awt and test/java/awt(which contains quite a few manual test that I simply click pass without verifying based on instruction). Also jprt. > 2. The changes in sun/awt/geom need closer examination and I would really > like Jim to weigh in on those .. > Would certainly appreciate that. Cheers, Henry From joe.darcy at oracle.com Thu Apr 10 02:44:04 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Apr 2014 19:44:04 -0700 Subject: JDK 9 RFR of JDK-8039861: Fix fallthrough lint warnings in awt Message-ID: <53460574.2010704@oracle.com> Hello, Please review the changes for JDK-8039861: Fix fallthrough lint warnings in awt http://cr.openjdk.java.net/~darcy/8039861.0/ Thanks, -Joe --- old/src/share/classes/java/awt/dnd/DragSourceContext.java 2014-04-09 19:41:33.000000000 -0700 +++ new/src/share/classes/java/awt/dnd/DragSourceContext.java 2014-04-09 19:41:33.000000000 -0700 @@ -472,7 +472,7 @@ * ENTER, OVER, * CHANGED */ - + @SuppressWarnings("fallthrough") protected synchronized void updateCurrentCursor(int sourceAct, int targetAct, int status) { // if the cursor has been previously set then don't do any defaults --- old/src/share/classes/sun/awt/image/GifImageDecoder.java 2014-04-09 19:41:33.000000000 -0700 +++ new/src/share/classes/sun/awt/image/GifImageDecoder.java 2014-04-09 19:41:33.000000000 -0700 @@ -114,6 +114,7 @@ /** * produce an image from the stream. */ + @SuppressWarnings("fallthrough") public void produceImage() throws IOException, ImageFormatException { try { readHeader(); @@ -238,7 +239,7 @@ if (frameno == 0) { return; } - // NOBREAK + // Fall through case TERMINATOR: if (nloops == 0 || nloops-- >= 0) { --- old/src/share/classes/sun/awt/image/PixelConverter.java 2014-04-09 19:41:34.000000000 -0700 +++ new/src/share/classes/sun/awt/image/PixelConverter.java 2014-04-09 19:41:33.000000000 -0700 @@ -53,6 +53,7 @@ protected PixelConverter() {} + @SuppressWarnings("fallthrough") public int rgbToPixel(int rgb, ColorModel cm) { Object obj = cm.getDataElements(rgb, null); switch (cm.getTransferType()) { --- old/src/solaris/classes/sun/awt/X11/XWM.java 2014-04-09 19:41:34.000000000 -0700 +++ new/src/solaris/classes/sun/awt/X11/XWM.java 2014-04-09 19:41:34.000000000 -0700 @@ -1112,6 +1112,7 @@ * Therefore, a compound state is just ICONIFIED | anything else. * */ + @SuppressWarnings("fallthrough") boolean supportsExtendedState(int state) { switch (state) { case Frame.MAXIMIZED_VERT: @@ -1131,6 +1132,7 @@ return true; } } + /* FALLTROUGH */ default: return false; } From alexey.ivanov at oracle.com Thu Apr 10 08:18:07 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 10 Apr 2014 12:18:07 +0400 Subject: [9] Review Request for JDK-8024061: Exception thrown when drag and drop between two components is executed quickly Message-ID: <534653BF.8090104@oracle.com> Hello AWT team, Could you please review the fix for jdk9: bug: https://bugs.openjdk.java.net/browse/JDK-8024061 webrev: http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.00/ Problem description: Dragging and dropping an object from one panel to another very quickly causes an exception. Fix: The fix addresses only the thrown exception. The dragged object would not be moved. Thanks, Alexey. From petr.pchelko at oracle.com Thu Apr 10 08:52:41 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 10 Apr 2014 12:52:41 +0400 Subject: [9] Review Request for JDK-8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: <534653BF.8090104@oracle.com> References: <534653BF.8090104@oracle.com> Message-ID: Hello, Dmitry. Thank you for the detailed explanation of the issue. I?m OK with this workaround as this should be back ported to 8u and 7u, but I think we could try to provide a real fix in 9. Could you please add some comment which shortly explains why the if clause was added? And could you also file a new bug for 9 so that we try to replace the workaround with a real fix? Thank you. With best regards. Petr. 10 ???. 2014 ?., ? 12:18 ????? ???????, Alexey Ivanov ???????(?): > Hello AWT team, > > Could you please review the fix for jdk9: > bug: https://bugs.openjdk.java.net/browse/JDK-8024061 > webrev: http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.00/ > > Problem description: > Dragging and dropping an object from one panel to another very quickly causes an exception. > > Fix: > The fix addresses only the thrown exception. > The dragged object would not be moved. > > > Thanks, > Alexey. From dmitriy.ermashov at oracle.com Thu Apr 10 09:53:55 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Thu, 10 Apr 2014 13:53:55 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <34E9C300-111A-4E7B-A31D-6F25D544888C@oracle.com> References: <5343E70A.1070501@oracle.com> <34E9C300-111A-4E7B-A31D-6F25D544888C@oracle.com> Message-ID: <53466A33.5010602@oracle.com> Hi, Petr, General comment: Ugly parts of code (like 4, 5, 6, 7, 8) are just legacy of functional tests. We will be trying to get rid of them. See next version of webrev soon. On 04/09/2014 02:24 PM, Petr Pchelko wrote: > Hello, Dmitriy. > > 1. Could you please not use the applet pattern in automatic tests? > We normally get rid of this in all the tests we touch/write, because it's useless and slows down the test execution. > So please rewrite SetBoundsTest to use main. > > 2. ../../../../lib/testlibrary could be replaces to just /lib/testlibrary. > > 3. I see that you are using printStackTrace + System.exit to fail the test. We normally just throw the RuntimeException > or state that main throws Exception, do not add catch blocks and let exceptions propagate out of main. jtreg would catch them, > report error nicely and fail the test. > I'm not sure which pattern is better, so it worths discussing.. I tried to rewrite tests on using throw new RuntimeException, and it seems to make more sense. > 4. ModifierRobotKey : System.getProperty("os.name").trim().substring(0, 3).toUpperCase().equals("SUN") you can replace this > to use the OSInfo class. It's way mode reliable. > > 5. ModifierRobotKey: Toolkit.getDefaultToolkit().getSystemEventQueue().invokeAndWait - Why no use SwingUtilities? > > 6. General comment: since this is going to 9 you could use lambdas wherever possible. > > 7. ModifierRobotTest: 131 canvas.addFocusListener(new FocusListener() - could be replaced with an Adapter. > > 8. Another general comment: the lib/testlibrary has an Asserts class - it could be used where possible. The > > assertTrue(focusGained, "Canvas focus gained"); > > looks much cleaner than > > if (!focusGained) { > System.err.println("FAIL: Canvas failed to gain focus!"); > System.exit(1); > } > > Of coarse it could be used only if we switch to "throw exception and not catch" pattern instead of the "System.exit" pattern. > > 9. LockingKeyStateTest - I don't like the pattern with the "result" variable. First of all - why it's an int if it's really should be a boolean? > Secondly, why are we continuing the test execution after we've found an error? Who cares that all the rest of assertions are true or not, > the test is already failed anyway. I'd rather just throw an Exception in place and stop the execution. Actually there is no need in result variable at all in scope on using "throw new Exception". > The most of my comments are a bit controversial, I just want to run the discussion of these points, because this is the first portion of tests > added and we are setting up the patterns now... > > With best regards. Petr > > On 08.04.2014, at 16:09, Dmitriy Ermashov wrote: > >> Hi, >> Please, review the changeset for: >> https://bugs.openjdk.java.net/browse/JDK-8039279 >> >> Webrev is here: >> http://cr.openjdk.java.net/~yan/8039279/webrev/ >> >> This is the first batch of functional AWT tests, that are prepared for migration to OpenJDK repository. >> Testlist: >> AWT_ZoomFrame/Automated/Frame/SetBoundsTest >> AWT_Robot/Automated/ModifierRobotKey >> AWT_Toolkit/Manual/LockingKeyStateTest >> AWT_LayoutTest/Automated/GridLayout/Layout >> AWT_LayoutTest/Automated/GridLayout/ChangeGrids >> >> Tests were switched on using jtreg, tested on the following platforms and seems stable: >> Windows 7 x64, Intel graphical card >> Ubuntu Linux 12.04 x64, Intel graphical card >> OS X 10.8.5 x64, NVIDIA GeForce 9400 >> Ubuntu 10.04 ARMv7 >> >> -- >> Thanks, >> Dima >> -- Thanks, Dima From mikhail.cherkasov at oracle.com Thu Apr 10 10:44:42 2014 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 10 Apr 2014 14:44:42 +0400 Subject: review request: focus disappears with shift+tab on dialogue having a focus component In-Reply-To: <534401CF.6060007@oracle.com> References: <52C2B1A1.8060803@oracle.com> <52CE56C7.7050707@oracle.com> <534401CF.6060007@oracle.com> Message-ID: <5346761A.5090408@oracle.com> Hi there, this is friendly reminder about the review request. Thanks, Mikhail. On 4/8/2014 6:03 PM, mikhail cherkasov wrote: > Hi again, > > A regression test was added: > http://cr.openjdk.java.net/~mcherkas/8031075/webrev.01/ > > Could you please review second version of webrev? > > Thanks, > Mikhail. > > On 1/9/2014 11:59 AM, Sergey Bylokhov wrote: >> Hi, Mikhail. >> The fix looks good. But since this regression was not found by our >> tests it would be good to add new one. >> >> On 31.12.2013 15:59, mikhail cherkasov wrote: >>> Hello all, >>> >>> Could you please review the following fix: >>> https://bugs.openjdk.java.net/browse/JDK-8031075 >>> review request: focus disappears with shift+tab on dialogue having a >>> focus component >>> http://cr.openjdk.java.net/~mcherkas/8031075/webrev.00/ >>> >>> >>> Jdk8 already has it, also it was in jdk7 too, but was mistakenly >>> reverted by other fix, so >>> I'm just returning it back. >>> >>> >>> Thanks, >>> Mikhail. >> >> >> -- >> Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitriy.ermashov at oracle.com Thu Apr 10 11:03:47 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Thu, 10 Apr 2014 15:03:47 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository Message-ID: <53467A93.9030704@oracle.com> Hi, Please, review the changeset for: https://bugs.openjdk.java.net/browse/JDK-8039279 Webrev is here: http://cr.openjdk.java.net/~yan/8039279/webrev.01/ Changelist: 1. Got rid of using applet in SetBounds test 2. Tests switched on using pattern "throw RuntimeException on fail" 3. ModifierRobotKeyTest now uses SwingUtilities, OSInfo and FocusAdapter classes 4. Using jdk.testlibrary.Asserts methods from lib/testlibrary folder Test runs on the following platforms seems stable: Windows 7 x64, Intel graphical card Ubuntu Linux 12.04 x64, Intel graphical card OS X 10.8.5 x64, NVIDIA GeForce 9400 Ubuntu 10.04 ARMv7 -- Thanks, Dima From yuri.nesterenko at oracle.com Thu Apr 10 11:17:18 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 10 Apr 2014 15:17:18 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <53467A93.9030704@oracle.com> References: <53467A93.9030704@oracle.com> Message-ID: <53467DBE.40709@oracle.com> Not that I have something against this fix but I feel it may be not necessary in future to use SwingUtilities in all-AWT tests. -yan On 04/10/2014 03:03 PM, Dmitriy Ermashov wrote: > Hi, > Please, review the changeset for: > https://bugs.openjdk.java.net/browse/JDK-8039279 > > Webrev is here: > http://cr.openjdk.java.net/~yan/8039279/webrev.01/ > > Changelist: > 1. Got rid of using applet in SetBounds test > 2. Tests switched on using pattern "throw RuntimeException on fail" > 3. ModifierRobotKeyTest now uses SwingUtilities, OSInfo and FocusAdapter > classes > 4. Using jdk.testlibrary.Asserts methods from lib/testlibrary folder > > Test runs on the following platforms seems stable: > Windows 7 x64, Intel graphical card > Ubuntu Linux 12.04 x64, Intel graphical card > OS X 10.8.5 x64, NVIDIA GeForce 9400 > Ubuntu 10.04 ARMv7 > From alexey.ivanov at oracle.com Thu Apr 10 13:39:32 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 10 Apr 2014 17:39:32 +0400 Subject: [9] Review Request for JDK-8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: References: <534653BF.8090104@oracle.com> Message-ID: <53469F14.4000507@oracle.com> Hi Petr, If the requested data flavor is DataFlavor.javaJVMLocalObjectMimeType, then transferable is local to the JVM. It is stored to a static variable in SunDropTargetContextPeer.setCurrentJVMLocalSourceTransferable(). When processEnterMessage() is handled, its value is copied to instance variable "local". The instance variable is cleaned by processExitMessage(), the static variable is cleared by SunDragSourceContextPeer.cleanup(). If drag-and-drop operation is performed quickly, SunDragSourceContextPeer.cleanup() is called when mouse button is released and *before* processEnterMessage() is called. So when EDT finally handles MOUSE_ENTERED event and DropTargetListener.dragEnter() gets called, "local" transferable is already null. The listener tries to get the data from the transferable: DropTargetDragEvent.getTransferable(), and then Transferable.getTransferData(dataFlavor). The dataFlavor has MIME type of DataFlavor.javaJVMLocalObjectMimeType, and SunDropTargetContextPeer.currentJVMLocalSourceTransferable is already cleared. The representationClass field of the DataFlavor object is set to java.io.InputStream.class. So when SunDropTargetContextPeer.getNativeData() executes it tries to cast the data object to java.io.InputStream to deserialize the data but fails with the exception: java.lang.ClassCastException: DnD$DropObject cannot be cast to java.io.InputStream. This exception is caught internally, and IOException is thrown as it failed to get the data. At the same time, no IO should have occurred because a local source was dragged, so this exception is rather unexpected. What actually happens is that native drag-and-drop operation completed already whereas this drag-and-drop operation on EDT didn't even started yet. Does throwing InvalidDnDOperationException look more appropriate than returning null in this case? Sure, I'll submit a new bug for 9 to implement the proper fix. Regards, Alexey. On 10.04.2014 12:52, Petr Pchelko wrote: > Hello, Dmitry. > > Thank you for the detailed explanation of the issue. > > I?m OK with this workaround as this should be back ported to 8u and 7u, but I think we could try to provide a real fix in 9. > Could you please add some comment which shortly explains why the if clause was added? > And could you also file a new bug for 9 so that we try to replace the workaround with a real fix? > > Thank you. > With best regards. Petr. > > 10 ???. 2014 ?., ? 12:18 ????? ???????, Alexey Ivanov ???????(?): > >> Hello AWT team, >> >> Could you please review the fix for jdk9: >> bug: https://bugs.openjdk.java.net/browse/JDK-8024061 >> webrev: http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.00/ >> >> Problem description: >> Dragging and dropping an object from one panel to another very quickly causes an exception. >> >> Fix: >> The fix addresses only the thrown exception. >> The dragged object would not be moved. >> >> >> Thanks, >> Alexey. From petr.pchelko at oracle.com Thu Apr 10 14:31:45 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 10 Apr 2014 18:31:45 +0400 Subject: [9] Review Request for JDK-8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: <53469F14.4000507@oracle.com> References: <534653BF.8090104@oracle.com> <53469F14.4000507@oracle.com> Message-ID: Hello, Alexey. Thank you for the clarification. > What actually happens is that native drag-and-drop operation completed already whereas this drag-and-drop operation on EDT didn't even started yet. Does throwing InvalidDnDOperationException look more appropriate than returning null in this case? No, I think it?s not good. As a workaround it?s better to not return the data than to throw an exception. It would be really hard for the users to deal with such an exception. Please add some comment to the if clause to clarify what?s happening. Otherwise the fix looks good to me. With best regards. Petr. 10 ???. 2014 ?., ? 5:39 ????? ???????, Alexey Ivanov ???????(?): > Hi Petr, > > If the requested data flavor is DataFlavor.javaJVMLocalObjectMimeType, then transferable is local to the JVM. It is stored to a static variable in SunDropTargetContextPeer.setCurrentJVMLocalSourceTransferable(). When processEnterMessage() is handled, its value is copied to instance variable "local". The instance variable is cleaned by processExitMessage(), the static variable is cleared by SunDragSourceContextPeer.cleanup(). > > If drag-and-drop operation is performed quickly, SunDragSourceContextPeer.cleanup() is called when mouse button is released and *before* processEnterMessage() is called. So when EDT finally handles MOUSE_ENTERED event and DropTargetListener.dragEnter() gets called, "local" transferable is already null. The listener tries to get the data from the transferable: > DropTargetDragEvent.getTransferable(), and then > Transferable.getTransferData(dataFlavor). > > The dataFlavor has MIME type of DataFlavor.javaJVMLocalObjectMimeType, and SunDropTargetContextPeer.currentJVMLocalSourceTransferable is already cleared. The representationClass field of the DataFlavor object is set to java.io.InputStream.class. So when SunDropTargetContextPeer.getNativeData() executes it tries to cast the data object to java.io.InputStream to deserialize the data but fails with the exception: > java.lang.ClassCastException: DnD$DropObject cannot be cast to java.io.InputStream. > > This exception is caught internally, and IOException is thrown as it failed to get the data. At the same time, no IO should have occurred because a local source was dragged, so this exception is rather unexpected. > > > What actually happens is that native drag-and-drop operation completed already whereas this drag-and-drop operation on EDT didn't even started yet. Does throwing InvalidDnDOperationException look more appropriate than returning null in this case? > > > Sure, I'll submit a new bug for 9 to implement the proper fix. > > > Regards, > Alexey. > > On 10.04.2014 12:52, Petr Pchelko wrote: >> Hello, Dmitry. >> >> Thank you for the detailed explanation of the issue. >> >> I?m OK with this workaround as this should be back ported to 8u and 7u, but I think we could try to provide a real fix in 9. >> Could you please add some comment which shortly explains why the if clause was added? >> And could you also file a new bug for 9 so that we try to replace the workaround with a real fix? >> >> Thank you. >> With best regards. Petr. >> >> 10 ???. 2014 ?., ? 12:18 ????? ???????, Alexey Ivanov ???????(?): >> >>> Hello AWT team, >>> >>> Could you please review the fix for jdk9: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8024061 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.00/ >>> >>> Problem description: >>> Dragging and dropping an object from one panel to another very quickly causes an exception. >>> >>> Fix: >>> The fix addresses only the thrown exception. >>> The dragged object would not be moved. >>> >>> >>> Thanks, >>> Alexey. > From xiangli.sjtu at qq.com Thu Apr 10 01:54:52 2014 From: xiangli.sjtu at qq.com (=?ISO-8859-1?B?TGVl?=) Date: Thu, 10 Apr 2014 09:54:52 +0800 Subject: [OpenJDK 2D-Dev] JDK9: RFR: 8039342: Fix raw and uncheckedwarnings in sun.awt.* In-Reply-To: <5345CA3D.5000008@oracle.com> References: <53430EAB.3090504@oracle.com> <5343312E.4060207@oracle.com> <534348E7.6010207@oracle.com> <5345BD2C.2020104@oracle.com> <5345CA3D.5000008@oracle.com> Message-ID: pls tell me how to quit this group?thanks ------------------ Original ------------------ From: "Henry Jen";; Date: Thu, Apr 10, 2014 06:31 AM To: "Phil Race"; "Joe Darcy"; "2d-dev"<2d-dev at openjdk.java.net>; Cc: "awt-dev"; "Alan Bateman"; Subject: Re: [OpenJDK 2D-Dev] JDK9: RFR: 8039342: Fix raw and uncheckedwarnings in sun.awt.* On 04/09/2014 02:35 PM, Phil Race wrote: > Yes it looks to be about 70% AWT and about 30% 2d .. > > Remember there's a magic decoder ring at > http://openjdk.java.net/groups/2d/2dawtfiles.html > It may not have 100% coverage but it should help. > > I looked over the 2D ones as below .. > > src/share/classes/sun/awt/FontConfiguration.java > src/share/classes/sun/awt/PlatformFont.java > src/share/classes/sun/awt/geom/AreaOp.java > src/share/classes/sun/awt/geom/Crossings.java > src/share/classes/sun/awt/geom/Curve.java > src/share/classes/sun/awt/geom/Order2.java > src/share/classes/sun/awt/geom/Order3.java > src/share/classes/sun/awt/image/BufImgSurfaceData.java > src/share/classes/sun/awt/image/GifImageDecoder.java > src/share/classes/sun/awt/image/ImageDecoder.java > src/share/classes/sun/awt/image/ImageFetcher.java > src/share/classes/sun/awt/image/ImageRepresentation.java > src/share/classes/sun/awt/image/ImagingLib.java > src/share/classes/sun/awt/image/JPEGImageDecoder.java > src/share/classes/sun/awt/image/OffScreenImageSource.java > src/share/classes/sun/awt/image/PNGImageDecoder.java > src/share/classes/sun/awt/image/ToolkitImage.java > src/solaris/classes/sun/awt/X11FontManager.java > src/solaris/classes/sun/awt/X11GraphicsDevice.java > src/solaris/classes/sun/awt/X11GraphicsEnvironment.java > src/solaris/classes/sun/awt/motif/MFontConfiguration.java > > It seems fine except that > 1. How are you testing all these changes ? > I ran jtreg on test/sun/awt and test/java/awt(which contains quite a few manual test that I simply click pass without verifying based on instruction). Also jprt. > 2. The changes in sun/awt/geom need closer examination and I would really > like Jim to weigh in on those .. > Would certainly appreciate that. Cheers, Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.ananiev at oracle.com Thu Apr 10 14:45:16 2014 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 10 Apr 2014 18:45:16 +0400 Subject: review request: focus disappears with shift+tab on dialogue having a focus component In-Reply-To: <534401CF.6060007@oracle.com> References: <52C2B1A1.8060803@oracle.com> <52CE56C7.7050707@oracle.com> <534401CF.6060007@oracle.com> Message-ID: <5346AE7C.5030905@oracle.com> Hi, Mikhail, the fix looks fine. The test looks fine as well, except the "button" field, which should be volatile. Thanks, Artem On 4/8/2014 6:03 PM, mikhail cherkasov wrote: > Hi again, > > A regression test was added: > http://cr.openjdk.java.net/~mcherkas/8031075/webrev.01/ > > Could you please review second version of webrev? > > Thanks, > Mikhail. > > On 1/9/2014 11:59 AM, Sergey Bylokhov wrote: >> Hi, Mikhail. >> The fix looks good. But since this regression was not found by our >> tests it would be good to add new one. >> >> On 31.12.2013 15:59, mikhail cherkasov wrote: >>> Hello all, >>> >>> Could you please review the following fix: >>> https://bugs.openjdk.java.net/browse/JDK-8031075 >>> review request: focus disappears with shift+tab on dialogue having a >>> focus component >>> http://cr.openjdk.java.net/~mcherkas/8031075/webrev.00/ >>> >>> >>> Jdk8 already has it, also it was in jdk7 too, but was mistakenly >>> reverted by other fix, so >>> I'm just returning it back. >>> >>> >>> Thanks, >>> Mikhail. >> >> >> -- >> Best regards, Sergey. > From mikhail.cherkasov at oracle.com Thu Apr 10 14:49:12 2014 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 10 Apr 2014 18:49:12 +0400 Subject: review request: focus disappears with shift+tab on dialogue having a focus component In-Reply-To: <5346AE7C.5030905@oracle.com> References: <52C2B1A1.8060803@oracle.com> <52CE56C7.7050707@oracle.com> <534401CF.6060007@oracle.com> <5346AE7C.5030905@oracle.com> Message-ID: <5346AF68.9030808@oracle.com> Thank you! On 4/10/2014 6:45 PM, Artem Ananiev wrote: > Hi, Mikhail, > > the fix looks fine. ok, will fix before commit. > > The test looks fine as well, except the "button" field, which should > be volatile. > > Thanks, > > Artem > > On 4/8/2014 6:03 PM, mikhail cherkasov wrote: >> Hi again, >> >> A regression test was added: >> http://cr.openjdk.java.net/~mcherkas/8031075/webrev.01/ >> >> Could you please review second version of webrev? >> >> Thanks, >> Mikhail. >> >> On 1/9/2014 11:59 AM, Sergey Bylokhov wrote: >>> Hi, Mikhail. >>> The fix looks good. But since this regression was not found by our >>> tests it would be good to add new one. >>> >>> On 31.12.2013 15:59, mikhail cherkasov wrote: >>>> Hello all, >>>> >>>> Could you please review the following fix: >>>> https://bugs.openjdk.java.net/browse/JDK-8031075 >>>> review request: focus disappears with shift+tab on dialogue having a >>>> focus component >>>> http://cr.openjdk.java.net/~mcherkas/8031075/webrev.00/ >>>> >>>> >>>> Jdk8 already has it, also it was in jdk7 too, but was mistakenly >>>> reverted by other fix, so >>>> I'm just returning it back. >>>> >>>> >>>> Thanks, >>>> Mikhail. >>> >>> >>> -- >>> Best regards, Sergey. >> From Sergey.Bylokhov at oracle.com Thu Apr 10 16:13:26 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 10 Apr 2014 20:13:26 +0400 Subject: review request: focus disappears with shift+tab on dialogue having a focus component In-Reply-To: <5346AF68.9030808@oracle.com> References: <52C2B1A1.8060803@oracle.com> <52CE56C7.7050707@oracle.com> <534401CF.6060007@oracle.com> <5346AE7C.5030905@oracle.com> <5346AF68.9030808@oracle.com> Message-ID: <5346C326.30003@oracle.com> The fix looks good. I guess the test should be pushed to jdk 8,9 as well. On 10.04.2014 18:49, mikhail cherkasov wrote: > Thank you! > > On 4/10/2014 6:45 PM, Artem Ananiev wrote: >> Hi, Mikhail, >> >> the fix looks fine. > ok, will fix before commit. >> >> The test looks fine as well, except the "button" field, which should >> be volatile. >> >> Thanks, >> >> Artem >> >> On 4/8/2014 6:03 PM, mikhail cherkasov wrote: >>> Hi again, >>> >>> A regression test was added: >>> http://cr.openjdk.java.net/~mcherkas/8031075/webrev.01/ >>> >>> Could you please review second version of webrev? >>> >>> Thanks, >>> Mikhail. >>> >>> On 1/9/2014 11:59 AM, Sergey Bylokhov wrote: >>>> Hi, Mikhail. >>>> The fix looks good. But since this regression was not found by our >>>> tests it would be good to add new one. >>>> >>>> On 31.12.2013 15:59, mikhail cherkasov wrote: >>>>> Hello all, >>>>> >>>>> Could you please review the following fix: >>>>> https://bugs.openjdk.java.net/browse/JDK-8031075 >>>>> review request: focus disappears with shift+tab on dialogue having a >>>>> focus component >>>>> http://cr.openjdk.java.net/~mcherkas/8031075/webrev.00/ >>>>> >>>>> >>>>> Jdk8 already has it, also it was in jdk7 too, but was mistakenly >>>>> reverted by other fix, so >>>>> I'm just returning it back. >>>>> >>>>> >>>>> Thanks, >>>>> Mikhail. >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> > -- Best regards, Sergey. From mikhail.cherkasov at oracle.com Thu Apr 10 16:17:05 2014 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 10 Apr 2014 20:17:05 +0400 Subject: review request: focus disappears with shift+tab on dialogue having a focus component In-Reply-To: <5346C326.30003@oracle.com> References: <52C2B1A1.8060803@oracle.com> <52CE56C7.7050707@oracle.com> <534401CF.6060007@oracle.com> <5346AE7C.5030905@oracle.com> <5346AF68.9030808@oracle.com> <5346C326.30003@oracle.com> Message-ID: <5346C401.20108@oracle.com> thank you for review!. On 4/10/2014 8:13 PM, Sergey Bylokhov wrote: > The fix looks good. > > I guess the test should be pushed to jdk 8,9 as well. ok, Do I need to file a new bug or how it works for this case? > > On 10.04.2014 18:49, mikhail cherkasov wrote: >> Thank you! >> >> On 4/10/2014 6:45 PM, Artem Ananiev wrote: >>> Hi, Mikhail, >>> >>> the fix looks fine. >> ok, will fix before commit. >>> >>> The test looks fine as well, except the "button" field, which should >>> be volatile. >>> >>> Thanks, >>> >>> Artem >>> >>> On 4/8/2014 6:03 PM, mikhail cherkasov wrote: >>>> Hi again, >>>> >>>> A regression test was added: >>>> http://cr.openjdk.java.net/~mcherkas/8031075/webrev.01/ >>>> >>>> Could you please review second version of webrev? >>>> >>>> Thanks, >>>> Mikhail. >>>> >>>> On 1/9/2014 11:59 AM, Sergey Bylokhov wrote: >>>>> Hi, Mikhail. >>>>> The fix looks good. But since this regression was not found by our >>>>> tests it would be good to add new one. >>>>> >>>>> On 31.12.2013 15:59, mikhail cherkasov wrote: >>>>>> Hello all, >>>>>> >>>>>> Could you please review the following fix: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8031075 >>>>>> review request: focus disappears with shift+tab on dialogue having a >>>>>> focus component >>>>>> http://cr.openjdk.java.net/~mcherkas/8031075/webrev.00/ >>>>>> >>>>>> >>>>>> Jdk8 already has it, also it was in jdk7 too, but was mistakenly >>>>>> reverted by other fix, so >>>>>> I'm just returning it back. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Mikhail. >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >> > > From petr.pchelko at oracle.com Fri Apr 11 08:13:35 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 11 Apr 2014 12:13:35 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <53467DBE.40709@oracle.com> References: <53467A93.9030704@oracle.com> <53467DBE.40709@oracle.com> Message-ID: Hello, Dmitriy. Looks much better now. Less code, ore understandable) Just a couple of minor comments left and we are good to go) SetBounds: 90: you don't need to catch the exception, let it propagate also. The test would fail anyway if you could not create a robot. 155: Please have a look on the asserts sources. It doesn't print the message as is, but adds smth like "expected: true but was: false" So you'd better write messages like "Button triggered action when clicked". So just describe the action you are asserting. LockingKeyStateTest 56: Method reference would look nice here) Just a suggestion.. 103: some weird commented out code left Thank you. With best regards. Petr. On 10.04.2014, at 15:17, Yuri Nesterenko wrote: > Not that I have something against this fix but > I feel it may be not necessary in future to use > SwingUtilities in all-AWT tests. > > -yan > > On 04/10/2014 03:03 PM, Dmitriy Ermashov wrote: >> Hi, >> Please, review the changeset for: >> https://bugs.openjdk.java.net/browse/JDK-8039279 >> >> Webrev is here: >> http://cr.openjdk.java.net/~yan/8039279/webrev.01/ >> >> Changelist: >> 1. Got rid of using applet in SetBounds test >> 2. Tests switched on using pattern "throw RuntimeException on fail" >> 3. ModifierRobotKeyTest now uses SwingUtilities, OSInfo and FocusAdapter >> classes >> 4. Using jdk.testlibrary.Asserts methods from lib/testlibrary folder >> >> Test runs on the following platforms seems stable: >> Windows 7 x64, Intel graphical card >> Ubuntu Linux 12.04 x64, Intel graphical card >> OS X 10.8.5 x64, NVIDIA GeForce 9400 >> Ubuntu 10.04 ARMv7 >> > From Sergey.Bylokhov at oracle.com Fri Apr 11 11:02:29 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 Apr 2014 15:02:29 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <53467DBE.40709@oracle.com> References: <53467A93.9030704@oracle.com> <53467DBE.40709@oracle.com> Message-ID: <5347CBC5.8010309@oracle.com> On 10.04.2014 15:17, Yuri Nesterenko wrote: > Not that I have something against this fix but > I feel it may be not necessary in future to use > SwingUtilities in all-AWT tests. Yes, in awt tests it is better to use EventQueue.invokeLater/invokeAndWait. > > -yan > > On 04/10/2014 03:03 PM, Dmitriy Ermashov wrote: >> Hi, >> Please, review the changeset for: >> https://bugs.openjdk.java.net/browse/JDK-8039279 >> >> Webrev is here: >> http://cr.openjdk.java.net/~yan/8039279/webrev.01/ >> >> Changelist: >> 1. Got rid of using applet in SetBounds test >> 2. Tests switched on using pattern "throw RuntimeException on fail" >> 3. ModifierRobotKeyTest now uses SwingUtilities, OSInfo and FocusAdapter >> classes >> 4. Using jdk.testlibrary.Asserts methods from lib/testlibrary folder >> >> Test runs on the following platforms seems stable: >> Windows 7 x64, Intel graphical card >> Ubuntu Linux 12.04 x64, Intel graphical card >> OS X 10.8.5 x64, NVIDIA GeForce 9400 >> Ubuntu 10.04 ARMv7 >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Apr 11 11:05:10 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 Apr 2014 15:05:10 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <53467A93.9030704@oracle.com> References: <53467A93.9030704@oracle.com> Message-ID: <5347CC66.30609@oracle.com> On 10.04.2014 15:03, Dmitriy Ermashov wrote: > Changelist: > 1. Got rid of using applet in SetBounds test It seems this code is unnecessary too: "SetBounds extends Applet" > 2. Tests switched on using pattern "throw RuntimeException on fail" > 3. ModifierRobotKeyTest now uses SwingUtilities, OSInfo and > FocusAdapter classes > 4. Using jdk.testlibrary.Asserts methods from lib/testlibrary folder > > Test runs on the following platforms seems stable: > Windows 7 x64, Intel graphical card > Ubuntu Linux 12.04 x64, Intel graphical card > OS X 10.8.5 x64, NVIDIA GeForce 9400 > Ubuntu 10.04 ARMv7 > -- Best regards, Sergey. From petr.pchelko at oracle.com Fri Apr 11 11:14:15 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 11 Apr 2014 15:14:15 +0400 Subject: [9] Review Request: 8039926 -spash: can't be combined with -xStartOnFirstThread since JDK 7 Message-ID: Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8039926 The fix is available at: http://cr.openjdk.java.net/~pchelko/9/8039926/webrev.00/ When running SWT we should not start the main event loop for splashscreen because it breaks SWT. The only way understand that in splashscreen code is to check the system property launcher sets on the startup. We do the same in awt.m, but we cannot reuse the code because splash and awt are not statically linked. With best regards. Petr. From anthony.petrov at oracle.com Fri Apr 11 11:31:47 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 11 Apr 2014 15:31:47 +0400 Subject: [9] Review Request: 8039926 -spash: can't be combined with -xStartOnFirstThread since JDK 7 In-Reply-To: References: Message-ID: <5347D2A3.3020509@oracle.com> Hi Petr, The fix looks fine. I see that we're not checking the isSWTInWebStart() case (see awt.m), but I don't immediately see any way to check this actually, because the JVM isn't started yet when the splashscreen is initializing. So I think we're good with the current solution. Although it would be good to document somewhere (in a comment in the code?) that when running an SWT app in WebStart, the AWT splashscreen is unsupported. -- best regards, Anthony On 4/11/2014 3:14 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8039926 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8039926/webrev.00/ > > When running SWT we should not start the main event loop for splashscreen because it breaks SWT. > The only way understand that in splashscreen code is to check the system property launcher sets on > the startup. We do the same in awt.m, but we cannot reuse the code because splash and awt are not > statically linked. > > With best regards. Petr. > From petr.pchelko at oracle.com Fri Apr 11 11:39:29 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 11 Apr 2014 15:39:29 +0400 Subject: [9] Review Request: 8039926 -spash: can't be combined with -xStartOnFirstThread since JDK 7 In-Reply-To: <5347D2A3.3020509@oracle.com> References: <5347D2A3.3020509@oracle.com> Message-ID: <91E9EBD2-9887-49CE-B552-5E26AF83E4DA@oracle.com> Hello, Anthony. Thank you for the review. > Although it would be good to document somewhere (in a comment in the code?) that when running an SWT app in WebStart, the AWT splashscreen is unsupported. I'll add the comment before the push. Something like: "Can't check if running SWT in webstart, so splash screen in webstart SWT applications is not supported". With best regards. Petr. On 11.04.2014, at 15:31, Anthony Petrov wrote: > Hi Petr, > > The fix looks fine. I see that we're not checking the isSWTInWebStart() case (see awt.m), but I don't immediately see any way to check this actually, because the JVM isn't started yet when the splashscreen is initializing. So I think we're good with the current solution. Although it would be good to document somewhere (in a comment in the code?) that when running an SWT app in WebStart, the AWT splashscreen is unsupported. > > -- > best regards, > Anthony > > On 4/11/2014 3:14 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8039926 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/8039926/webrev.00/ >> >> When running SWT we should not start the main event loop for splashscreen because it breaks SWT. >> The only way understand that in splashscreen code is to check the system property launcher sets on >> the startup. We do the same in awt.m, but we cannot reuse the code because splash and awt are not >> statically linked. >> >> With best regards. Petr. >> From anthony.petrov at oracle.com Fri Apr 11 11:41:14 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 11 Apr 2014 15:41:14 +0400 Subject: [9] Review Request: 8039926 -spash: can't be combined with -xStartOnFirstThread since JDK 7 In-Reply-To: <91E9EBD2-9887-49CE-B552-5E26AF83E4DA@oracle.com> References: <5347D2A3.3020509@oracle.com> <91E9EBD2-9887-49CE-B552-5E26AF83E4DA@oracle.com> Message-ID: <5347D4DA.5050700@oracle.com> Sounds good. Thanks. -- best regards, Anthony On 4/11/2014 3:39 PM, Petr Pchelko wrote: > Hello, Anthony. > > Thank you for the review. > >> Although it would be good to document somewhere (in a comment in the code?) that when running an SWT app in WebStart, the AWT splashscreen is unsupported. > I'll add the comment before the push. > Something like: "Can't check if running SWT in webstart, so splash screen in webstart SWT applications is not supported". > > With best regards. Petr. > > On 11.04.2014, at 15:31, Anthony Petrov wrote: > >> Hi Petr, >> >> The fix looks fine. I see that we're not checking the isSWTInWebStart() case (see awt.m), but I don't immediately see any way to check this actually, because the JVM isn't started yet when the splashscreen is initializing. So I think we're good with the current solution. Although it would be good to document somewhere (in a comment in the code?) that when running an SWT app in WebStart, the AWT splashscreen is unsupported. >> >> -- >> best regards, >> Anthony >> >> On 4/11/2014 3:14 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8039926 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/9/8039926/webrev.00/ >>> >>> When running SWT we should not start the main event loop for splashscreen because it breaks SWT. >>> The only way understand that in splashscreen code is to check the system property launcher sets on >>> the startup. We do the same in awt.m, but we cannot reuse the code because splash and awt are not >>> statically linked. >>> >>> With best regards. Petr. >>> > From dmitriy.ermashov at oracle.com Mon Apr 14 10:17:46 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Mon, 14 Apr 2014 14:17:46 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository Message-ID: <534BB5CA.6020801@oracle.com> Hi, Please, review the changeset for: https://bugs.openjdk.java.net/browse/JDK-8039279 Webrev is here: http://cr.openjdk.java.net/~yan/8039279/webrev.02/ Changelist: 1. Test SetBounds was renamed to SetMaximizedBounds. All unnecessary code has been removed. 2. Thrown away all usages of javax.swing package. 3. Fixed info messages for Asserts functions. 4. Code cleanup in LockingKeyStateTest (removed commented lines of code, switched to method reference usage) Test runs on the following platforms seems stable: Windows 7 x64, Intel graphical card Ubuntu Linux 12.04 x64, Intel graphical card OS X 10.8.5 x64, NVIDIA GeForce 9400 Ubuntu 10.04 ARMv7 -- Thanks, Dima From alexander.v.stepanov at oracle.com Mon Apr 14 10:34:29 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Mon, 14 Apr 2014 14:34:29 +0400 Subject: [9] Review request for 8040081: Tidy warnings cleanup for java.applet Message-ID: <534BB9B5.3070208@oracle.com> Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8040081 Webrev corresponding: http://cr.openjdk.java.net/~yan/8040081/webrev.00/ Just a very minor cleanup of javadoc to avoid tidy warnings; no other code affected. Thanks. Regards, Alexander From petr.pchelko at oracle.com Mon Apr 14 11:41:46 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 14 Apr 2014 15:41:46 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <534BB5CA.6020801@oracle.com> References: <534BB5CA.6020801@oracle.com> Message-ID: <4A4F906C-BFBD-4D80-8F1B-2716AB7B1BD2@oracle.com> Looks fine to me. With best regards. Petr. On 14.04.2014, at 14:17, Dmitriy Ermashov wrote: > Hi, > Please, review the changeset for: > https://bugs.openjdk.java.net/browse/JDK-8039279 > > Webrev is here: > http://cr.openjdk.java.net/~yan/8039279/webrev.02/ > > Changelist: > 1. Test SetBounds was renamed to SetMaximizedBounds. All unnecessary code has been removed. > 2. Thrown away all usages of javax.swing package. > 3. Fixed info messages for Asserts functions. > 4. Code cleanup in LockingKeyStateTest (removed commented lines of code, switched to method reference usage) > > Test runs on the following platforms seems stable: > Windows 7 x64, Intel graphical card > Ubuntu Linux 12.04 x64, Intel graphical card > OS X 10.8.5 x64, NVIDIA GeForce 9400 > Ubuntu 10.04 ARMv7 > > -- > Thanks, > Dima > From alexey.ivanov at oracle.com Tue Apr 15 11:00:46 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 15 Apr 2014 15:00:46 +0400 Subject: [9] Review Request for JDK-8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: <534653BF.8090104@oracle.com> References: <534653BF.8090104@oracle.com> Message-ID: <534D115E.2020906@oracle.com> Hello AWT team, Could you please review the updated version of the webrev: http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.01/ I have added a comment explaining why another 'if' clause is added, as proposed by Petr Pchelko. Thanks, Alexey. On 10.04.2014 12:18, Alexey Ivanov wrote: > Hello AWT team, > > Could you please review the fix for jdk9: > bug: https://bugs.openjdk.java.net/browse/JDK-8024061 > webrev: http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.00/ > > Problem description: > Dragging and dropping an object from one panel to another very quickly > causes an exception. > > Fix: > The fix addresses only the thrown exception. > The dragged object would not be moved. > > > Thanks, > Alexey. From alexey.ivanov at oracle.com Tue Apr 15 11:02:29 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 15 Apr 2014 15:02:29 +0400 Subject: [9] Review Request for JDK-8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: References: <534653BF.8090104@oracle.com> <53469F14.4000507@oracle.com> Message-ID: <534D11C5.2090901@oracle.com> Hi Petr, Please look at the updated webrev with comment explaining why additional 'if' clause is added: http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.01/ I have submitted a new bug JDK-8040248: "Drag and drop between two components fails if performed quickly" https://bugs.openjdk.java.net/browse/JDK-8040248 Regards, Alexey. On 10.04.2014 18:31, Petr Pchelko wrote: > Hello, Alexey. > > Thank you for the clarification. > >> What actually happens is that native drag-and-drop operation completed already whereas this drag-and-drop operation on EDT didn't even started yet. Does throwing InvalidDnDOperationException look more appropriate than returning null in this case? > No, I think it?s not good. As a workaround it?s better to not return the data than to throw an exception. It would be really hard for the users to deal with such an exception. > > Please add some comment to the if clause to clarify what?s happening. > Otherwise the fix looks good to me. > > With best regards. Petr. > > 10 ???. 2014 ?., ? 5:39 ????? ???????, Alexey Ivanov ???????(?): > >> Hi Petr, >> >> If the requested data flavor is DataFlavor.javaJVMLocalObjectMimeType, then transferable is local to the JVM. It is stored to a static variable in SunDropTargetContextPeer.setCurrentJVMLocalSourceTransferable(). When processEnterMessage() is handled, its value is copied to instance variable "local". The instance variable is cleaned by processExitMessage(), the static variable is cleared by SunDragSourceContextPeer.cleanup(). >> >> If drag-and-drop operation is performed quickly, SunDragSourceContextPeer.cleanup() is called when mouse button is released and *before* processEnterMessage() is called. So when EDT finally handles MOUSE_ENTERED event and DropTargetListener.dragEnter() gets called, "local" transferable is already null. The listener tries to get the data from the transferable: >> DropTargetDragEvent.getTransferable(), and then >> Transferable.getTransferData(dataFlavor). >> >> The dataFlavor has MIME type of DataFlavor.javaJVMLocalObjectMimeType, and SunDropTargetContextPeer.currentJVMLocalSourceTransferable is already cleared. The representationClass field of the DataFlavor object is set to java.io.InputStream.class. So when SunDropTargetContextPeer.getNativeData() executes it tries to cast the data object to java.io.InputStream to deserialize the data but fails with the exception: >> java.lang.ClassCastException: DnD$DropObject cannot be cast to java.io.InputStream. >> >> This exception is caught internally, and IOException is thrown as it failed to get the data. At the same time, no IO should have occurred because a local source was dragged, so this exception is rather unexpected. >> >> >> What actually happens is that native drag-and-drop operation completed already whereas this drag-and-drop operation on EDT didn't even started yet. Does throwing InvalidDnDOperationException look more appropriate than returning null in this case? >> >> >> Sure, I'll submit a new bug for 9 to implement the proper fix. >> >> >> Regards, >> Alexey. >> >> On 10.04.2014 12:52, Petr Pchelko wrote: >>> Hello, Dmitry. >>> >>> Thank you for the detailed explanation of the issue. >>> >>> I?m OK with this workaround as this should be back ported to 8u and 7u, but I think we could try to provide a real fix in 9. >>> Could you please add some comment which shortly explains why the if clause was added? >>> And could you also file a new bug for 9 so that we try to replace the workaround with a real fix? >>> >>> Thank you. >>> With best regards. Petr. >>> >>> 10 ???. 2014 ?., ? 12:18 ????? ???????, Alexey Ivanov ???????(?): >>> >>>> Hello AWT team, >>>> >>>> Could you please review the fix for jdk9: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8024061 >>>> webrev: http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.00/ >>>> >>>> Problem description: >>>> Dragging and dropping an object from one panel to another very quickly causes an exception. >>>> >>>> Fix: >>>> The fix addresses only the thrown exception. >>>> The dragged object would not be moved. >>>> >>>> >>>> Thanks, >>>> Alexey. From petr.pchelko at oracle.com Tue Apr 15 11:13:59 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 15 Apr 2014 15:13:59 +0400 Subject: [9] Review Request for JDK-8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: <534D11C5.2090901@oracle.com> References: <534653BF.8090104@oracle.com> <53469F14.4000507@oracle.com> <534D11C5.2090901@oracle.com> Message-ID: <44CF8F6F-DA12-44C8-906A-8CBAC73979E9@oracle.com> Hello, Alexey. I?m fine with your fix. Thank you for filing a new bug for JDK 9. With best regards. Petr. 15 ???. 2014 ?., ? 3:02 ????? ???????, Alexey Ivanov ???????(?): > Hi Petr, > > Please look at the updated webrev with comment explaining why additional 'if' clause is added: > http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.01/ > > I have submitted a new bug JDK-8040248: > "Drag and drop between two components fails if performed quickly" > https://bugs.openjdk.java.net/browse/JDK-8040248 > > Regards, > Alexey. > > On 10.04.2014 18:31, Petr Pchelko wrote: >> Hello, Alexey. >> >> Thank you for the clarification. >> >>> What actually happens is that native drag-and-drop operation completed already whereas this drag-and-drop operation on EDT didn't even started yet. Does throwing InvalidDnDOperationException look more appropriate than returning null in this case? >> No, I think it?s not good. As a workaround it?s better to not return the data than to throw an exception. It would be really hard for the users to deal with such an exception. >> >> Please add some comment to the if clause to clarify what?s happening. >> Otherwise the fix looks good to me. >> >> With best regards. Petr. >> >> 10 ???. 2014 ?., ? 5:39 ????? ???????, Alexey Ivanov ???????(?): >> >>> Hi Petr, >>> >>> If the requested data flavor is DataFlavor.javaJVMLocalObjectMimeType, then transferable is local to the JVM. It is stored to a static variable in SunDropTargetContextPeer.setCurrentJVMLocalSourceTransferable(). When processEnterMessage() is handled, its value is copied to instance variable "local". The instance variable is cleaned by processExitMessage(), the static variable is cleared by SunDragSourceContextPeer.cleanup(). >>> >>> If drag-and-drop operation is performed quickly, SunDragSourceContextPeer.cleanup() is called when mouse button is released and *before* processEnterMessage() is called. So when EDT finally handles MOUSE_ENTERED event and DropTargetListener.dragEnter() gets called, "local" transferable is already null. The listener tries to get the data from the transferable: >>> DropTargetDragEvent.getTransferable(), and then >>> Transferable.getTransferData(dataFlavor). >>> >>> The dataFlavor has MIME type of DataFlavor.javaJVMLocalObjectMimeType, and SunDropTargetContextPeer.currentJVMLocalSourceTransferable is already cleared. The representationClass field of the DataFlavor object is set to java.io.InputStream.class. So when SunDropTargetContextPeer.getNativeData() executes it tries to cast the data object to java.io.InputStream to deserialize the data but fails with the exception: >>> java.lang.ClassCastException: DnD$DropObject cannot be cast to java.io.InputStream. >>> >>> This exception is caught internally, and IOException is thrown as it failed to get the data. At the same time, no IO should have occurred because a local source was dragged, so this exception is rather unexpected. >>> >>> >>> What actually happens is that native drag-and-drop operation completed already whereas this drag-and-drop operation on EDT didn't even started yet. Does throwing InvalidDnDOperationException look more appropriate than returning null in this case? >>> >>> >>> Sure, I'll submit a new bug for 9 to implement the proper fix. >>> >>> >>> Regards, >>> Alexey. >>> >>> On 10.04.2014 12:52, Petr Pchelko wrote: >>>> Hello, Dmitry. >>>> >>>> Thank you for the detailed explanation of the issue. >>>> >>>> I?m OK with this workaround as this should be back ported to 8u and 7u, but I think we could try to provide a real fix in 9. >>>> Could you please add some comment which shortly explains why the if clause was added? >>>> And could you also file a new bug for 9 so that we try to replace the workaround with a real fix? >>>> >>>> Thank you. >>>> With best regards. Petr. >>>> >>>> 10 ???. 2014 ?., ? 12:18 ????? ???????, Alexey Ivanov ???????(?): >>>> >>>>> Hello AWT team, >>>>> >>>>> Could you please review the fix for jdk9: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8024061 >>>>> webrev: http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.00/ >>>>> >>>>> Problem description: >>>>> Dragging and dropping an object from one panel to another very quickly causes an exception. >>>>> >>>>> Fix: >>>>> The fix addresses only the thrown exception. >>>>> The dragged object would not be moved. >>>>> >>>>> >>>>> Thanks, >>>>> Alexey. > From dmitriy.ermashov at oracle.com Tue Apr 15 11:33:50 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Tue, 15 Apr 2014 15:33:50 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <4A4F906C-BFBD-4D80-8F1B-2716AB7B1BD2@oracle.com> References: <534BB5CA.6020801@oracle.com> <4A4F906C-BFBD-4D80-8F1B-2716AB7B1BD2@oracle.com> Message-ID: <534D191E.8030507@oracle.com> Hi all. Petr, thanks for review! Guys, could you also review this tests? http://cr.openjdk.java.net/~yan/8039279/webrev.02/ -- Thanks, Dima On 04/14/2014 03:41 PM, Petr Pchelko wrote: > Looks fine to me. > > With best regards. Petr. > > On 14.04.2014, at 14:17, Dmitriy Ermashov wrote: > >> Hi, >> Please, review the changeset for: >> https://bugs.openjdk.java.net/browse/JDK-8039279 >> >> Webrev is here: >> http://cr.openjdk.java.net/~yan/8039279/webrev.02/ >> >> Changelist: >> 1. Test SetBounds was renamed to SetMaximizedBounds. All unnecessary code has been removed. >> 2. Thrown away all usages of javax.swing package. >> 3. Fixed info messages for Asserts functions. >> 4. Code cleanup in LockingKeyStateTest (removed commented lines of code, switched to method reference usage) >> >> Test runs on the following platforms seems stable: >> Windows 7 x64, Intel graphical card >> Ubuntu Linux 12.04 x64, Intel graphical card >> OS X 10.8.5 x64, NVIDIA GeForce 9400 >> Ubuntu 10.04 ARMv7 >> >> -- >> Thanks, >> Dima >> From petr.pchelko at oracle.com Tue Apr 15 12:33:39 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 15 Apr 2014 16:33:39 +0400 Subject: [9] Review Request: 7124365 [macosx] setMaximizedBounds() should be implemented Message-ID: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-7124365 The fix is available at: http://cr.openjdk.java.net/~pchelko/9/7124365/webrev/ The implementation is pretty straightforward. In native -1 indicates that this bound is not set. Using Integer.MAX_VALUE as in Frame?s javadoc isn?t convenient in native code. We do not need to worry about bounds that do not fit the screen - Cocoa handles it for us. But we need to handle the maximum/minimum sizes manually, because these are applied before the willUseStandardFrame callback is called. The regression test for this exists, it?s being moved from SQE right now. I?ll modify it to support Mac as soon as it?s pushed. Thank you. With best regards. Petr. From Sergey.Bylokhov at oracle.com Tue Apr 15 12:51:47 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 15 Apr 2014 16:51:47 +0400 Subject: [9] Review Request: 7124365 [macosx] setMaximizedBounds() should be implemented In-Reply-To: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> References: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> Message-ID: <534D2B63.9040005@oracle.com> Hi, Petr. Is it true that the native system does not constrain min/max height/width ourselves after the call to windowWillUseStandardFrame? I guess we can suggest to sqe to change the test now, since it is currently under review. On 4/15/14 4:33 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-7124365 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/7124365/webrev/ > > The implementation is pretty straightforward. > In native -1 indicates that this bound is not set. Using Integer.MAX_VALUE as in Frame?s javadoc isn?t convenient in native code. > We do not need to worry about bounds that do not fit the screen - Cocoa handles it for us. > But we need to handle the maximum/minimum sizes manually, because these are applied before the willUseStandardFrame callback is called. > The regression test for this exists, it?s being moved from SQE right now. I?ll modify it to support Mac as soon as it?s pushed. > > Thank you. > With best regards. Petr. -- Best regards, Sergey. From petr.pchelko at oracle.com Tue Apr 15 12:56:39 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 15 Apr 2014 16:56:39 +0400 Subject: [9] Review Request: 7124365 [macosx] setMaximizedBounds() should be implemented In-Reply-To: <534D2B63.9040005@oracle.com> References: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> <534D2B63.9040005@oracle.com> Message-ID: <69152040-6178-4A1A-90F1-AD19E30E0C9D@oracle.com> > Is it true that the native system does not constrain min/max height/width ourselves after the call to windowWillUseStandardFrame? I didn?t quite understand your question) If I set maximum size to 100x100 and return 200x200 from maximized size the frame will ignore the maximum size and appear 200x200. We could not modify that test, but write a new one to specifically check this possible bug.. With best regards. Petr. 15 ???. 2014 ?., ? 4:51 ????? ???????, Sergey Bylokhov ???????(?): > Hi, Petr. > Is it true that the native system does not constrain min/max height/width ourselves after the call to windowWillUseStandardFrame? > I guess we can suggest to sqe to change the test now, since it is currently under review. > > On 4/15/14 4:33 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-7124365 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/7124365/webrev/ >> >> The implementation is pretty straightforward. >> In native -1 indicates that this bound is not set. Using Integer.MAX_VALUE as in Frame?s javadoc isn?t convenient in native code. >> We do not need to worry about bounds that do not fit the screen - Cocoa handles it for us. >> But we need to handle the maximum/minimum sizes manually, because these are applied before the willUseStandardFrame callback is called. >> The regression test for this exists, it?s being moved from SQE right now. I?ll modify it to support Mac as soon as it?s pushed. >> >> Thank you. >> With best regards. Petr. > > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Tue Apr 15 13:14:40 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 15 Apr 2014 17:14:40 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <534D191E.8030507@oracle.com> References: <534BB5CA.6020801@oracle.com> <4A4F906C-BFBD-4D80-8F1B-2716AB7B1BD2@oracle.com> <534D191E.8030507@oracle.com> Message-ID: <534D30C0.3040806@oracle.com> Hi, Dmitriy. A few comments: SetMaximizedBounds.java: please add macosx to the test coverage. It does not work now but the fix is under review. ChangeGridSize.java/ ComponentPreferredSize.java: actionPerformed must be volatile, all other constant can be final. ModifierRobotKeyTest.java: tempPress must be volatile, access to modifierStatus[] and textStatus should be synchronized somehow. LockingKeyStateTest.java:I guess we have synchronization problem as well. Additionally, can you dispose all frames in the tests. On 4/15/14 3:33 PM, Dmitriy Ermashov wrote: > Hi all. > > Petr, thanks for review! > > Guys, could you also review this tests? > http://cr.openjdk.java.net/~yan/8039279/webrev.02/ > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Apr 15 13:16:42 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 15 Apr 2014 17:16:42 +0400 Subject: [9] Review Request: 7124365 [macosx] setMaximizedBounds() should be implemented In-Reply-To: <69152040-6178-4A1A-90F1-AD19E30E0C9D@oracle.com> References: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> <534D2B63.9040005@oracle.com> <69152040-6178-4A1A-90F1-AD19E30E0C9D@oracle.com> Message-ID: <534D313A.4090507@oracle.com> On 4/15/14 4:56 PM, Petr Pchelko wrote: >> Is it true that the native system does not constrain min/max height/width ourselves after the call to windowWillUseStandardFrame? > I didn?t quite understand your question) If I set maximum size to 100x100 and return 200x200 from maximized size the frame will ignore the maximum size and appear 200x200. ok. > We could not modify that test, but write a new one to specifically check this possible bug.. So we need a new additional test to check intersection of maximizedBounds/maxsize/minsize? > > With best regards. Petr. > > 15 ???. 2014 ?., ? 4:51 ????? ???????, Sergey Bylokhov ???????(?): > >> Hi, Petr. >> Is it true that the native system does not constrain min/max height/width ourselves after the call to windowWillUseStandardFrame? >> I guess we can suggest to sqe to change the test now, since it is currently under review. >> >> On 4/15/14 4:33 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-7124365 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/9/7124365/webrev/ >>> >>> The implementation is pretty straightforward. >>> In native -1 indicates that this bound is not set. Using Integer.MAX_VALUE as in Frame?s javadoc isn?t convenient in native code. >>> We do not need to worry about bounds that do not fit the screen - Cocoa handles it for us. >>> But we need to handle the maximum/minimum sizes manually, because these are applied before the willUseStandardFrame callback is called. >>> The regression test for this exists, it?s being moved from SQE right now. I?ll modify it to support Mac as soon as it?s pushed. >>> >>> Thank you. >>> With best regards. Petr. >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From petr.pchelko at oracle.com Tue Apr 15 13:52:14 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 15 Apr 2014 17:52:14 +0400 Subject: [9] Review Request: 7124365 [macosx] setMaximizedBounds() should be implemented In-Reply-To: <534D313A.4090507@oracle.com> References: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> <534D2B63.9040005@oracle.com> <69152040-6178-4A1A-90F1-AD19E30E0C9D@oracle.com> <534D313A.4090507@oracle.com> Message-ID: <4D22D813-EAA4-4F89-A6F5-88D8805E5392@oracle.com> I?ll prepare it and send a new request. 15 ???. 2014 ?., ? 5:16 ????? ???????, Sergey Bylokhov ???????(?): > On 4/15/14 4:56 PM, Petr Pchelko wrote: >>> Is it true that the native system does not constrain min/max height/width ourselves after the call to windowWillUseStandardFrame? >> I didn?t quite understand your question) If I set maximum size to 100x100 and return 200x200 from maximized size the frame will ignore the maximum size and appear 200x200. > ok. >> We could not modify that test, but write a new one to specifically check this possible bug.. > So we need a new additional test to check intersection of maximizedBounds/maxsize/minsize? >> >> With best regards. Petr. >> >> 15 ???. 2014 ?., ? 4:51 ????? ???????, Sergey Bylokhov ???????(?): >> >>> Hi, Petr. >>> Is it true that the native system does not constrain min/max height/width ourselves after the call to windowWillUseStandardFrame? >>> I guess we can suggest to sqe to change the test now, since it is currently under review. >>> >>> On 4/15/14 4:33 PM, Petr Pchelko wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-7124365 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/9/7124365/webrev/ >>>> >>>> The implementation is pretty straightforward. >>>> In native -1 indicates that this bound is not set. Using Integer.MAX_VALUE as in Frame?s javadoc isn?t convenient in native code. >>>> We do not need to worry about bounds that do not fit the screen - Cocoa handles it for us. >>>> But we need to handle the maximum/minimum sizes manually, because these are applied before the willUseStandardFrame callback is called. >>>> The regression test for this exists, it?s being moved from SQE right now. I?ll modify it to support Mac as soon as it?s pushed. >>>> >>>> Thank you. >>>> With best regards. Petr. >>> >>> -- >>> Best regards, Sergey. >>> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Tue Apr 15 14:01:41 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 15 Apr 2014 18:01:41 +0400 Subject: [9] Review Request: 7124365 [macosx] setMaximizedBounds() should be implemented In-Reply-To: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> References: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> Message-ID: <534D3BC5.8010804@oracle.com> Hello Petr, #1: I noticed that a window doesn't move on setExtendedState(Frame.MAXIMIZED_BOTH) if a window already have the same size as provided to setMaximizedBounds(). Another case: we successfully maximized a window, its window state is MAXIMIZED_BOTH, we moved a window, its window state is NORMAL we trying to maximize it once again, window state becomes MAXIMIZED_BOTH, but window keeps its location. I think, that a user would expect that the window will be moved to its MaximizedBounds location. #2: I suggest to place check against javaMaxSize above javaMinSize in AWTWindow.m. IIRC, on Windows, Linux and Mac OS X min size native hint is more powerful than max size. So after applying native hints like frame.setMinimumSize(new Dimension(300, 300)); frame.setMaximumSize(new Dimension(200, 200)); the size of a frame will be 300x300 (java currently supports maximum size on OS X only, but you can check it with any native program). And calling frame.setMaximizedBounds(new Rectangle(300, 300, 500, 500)); will lead to a window with size 200x200, but I expect here 300x300 (anyway I think that it is a ridiculous case). But just moving this checks isn't enough because of #1 (a window has size same to specified in setMaximizedBounds() and doesn't move). Thanks, Alexander. On 04/15/2014 04:33 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-7124365 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/7124365/webrev/ > > The implementation is pretty straightforward. > In native -1 indicates that this bound is not set. Using Integer.MAX_VALUE as in Frame?s javadoc isn?t convenient in native code. > We do not need to worry about bounds that do not fit the screen - Cocoa handles it for us. > But we need to handle the maximum/minimum sizes manually, because these are applied before the willUseStandardFrame callback is called. > The regression test for this exists, it?s being moved from SQE right now. I?ll modify it to support Mac as soon as it?s pushed. > > Thank you. > With best regards. Petr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.pchelko at oracle.com Tue Apr 15 14:33:53 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 15 Apr 2014 18:33:53 +0400 Subject: [9] Review Request: 7124365 [macosx] setMaximizedBounds() should be implemented In-Reply-To: <534D3BC5.8010804@oracle.com> References: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> <534D3BC5.8010804@oracle.com> Message-ID: Hello, Alexander. Thank you for testing! > I noticed that a window doesn't move on setExtendedState(Frame.MAXIMIZED_BOTH) if a window already have > the same size as provided to setMaximizedBounds(). Hmm.. didn?t notice that.. Looks like it?s because we are discarding zoom the size is not going to change. Looks like I should reimplement a fix with unrealizable windows. About #2 - thank you. I?ll update this. With best regards. Petr. 15 ???. 2014 ?., ? 6:01 ????? ???????, Alexander Zvegintsev ???????(?): > Hello Petr, > > > #1: > I noticed that a window doesn't move on setExtendedState(Frame.MAXIMIZED_BOTH) if a window already have > the same size as provided to setMaximizedBounds(). > > Another case: > we successfully maximized a window, its window state is MAXIMIZED_BOTH, > we moved a window, its window state is NORMAL > we trying to maximize it once again, window state becomes MAXIMIZED_BOTH, but window keeps its location. > > I think, that a user would expect that the window will be moved to its MaximizedBounds location. > > #2: > > I suggest to place check against javaMaxSize above javaMinSize in AWTWindow.m. > > IIRC, on Windows, Linux and Mac OS X min size native hint is more powerful than max size. So after applying native hints like > > frame.setMinimumSize(new Dimension(300, 300)); > frame.setMaximumSize(new Dimension(200, 200)); > > the size of a frame will be 300x300 (java currently supports maximum size on OS X only, but you can check it with any native program). > > And calling > > frame.setMaximizedBounds(new Rectangle(300, 300, 500, 500)); > > will lead to a window with size 200x200, but I expect here 300x300 (anyway I think that it is a ridiculous case). > > But just moving this checks isn't enough because of #1 (a window has size same to specified in setMaximizedBounds() and doesn't move). > > > Thanks, > > Alexander. > On 04/15/2014 04:33 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-7124365 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/7124365/webrev/ >> >> The implementation is pretty straightforward. >> In native -1 indicates that this bound is not set. Using Integer.MAX_VALUE as in Frame?s javadoc isn?t convenient in native code. >> We do not need to worry about bounds that do not fit the screen - Cocoa handles it for us. >> But we need to handle the maximum/minimum sizes manually, because these are applied before the willUseStandardFrame callback is called. >> The regression test for this exists, it?s being moved from SQE right now. I?ll modify it to support Mac as soon as it?s pushed. >> >> Thank you. >> With best regards. Petr. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Apr 15 14:36:00 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 15 Apr 2014 18:36:00 +0400 Subject: [9] Review request for 8040279 [macosx] Do not use the base image in the MultiResolutionBufferedImage constructor Message-ID: <534D43D0.2010808@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8040279 webrev: http://cr.openjdk.java.net/~alexsch/8040279/webrev.00 MultiResolutionBufferedImage extends BufferedImage. In this case it needs to use the base image to write it to the BufferedImage. The fix renames MultiResolutionBufferedImage to MultiResolutionCahcedImage and does not use the BufferedImage as the super class. The base image is created and cached by demand. CImage now always returns MultiResolutionCahcedImage. All requested resolution variants are scaled by NSImage. Thanks, Alexandr. From joe.darcy at oracle.com Tue Apr 15 17:32:41 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 15 Apr 2014 10:32:41 -0700 Subject: JDK 9 RFR of JDK-8039861: Fix fallthrough lint warnings in awt In-Reply-To: <53460574.2010704@oracle.com> References: <53460574.2010704@oracle.com> Message-ID: <534D6D39.8000106@oracle.com> *ping* On 04/09/2014 07:44 PM, Joe Darcy wrote: > Hello, > > Please review the changes for > > JDK-8039861: Fix fallthrough lint warnings in awt > http://cr.openjdk.java.net/~darcy/8039861.0/ > > Thanks, > > -Joe > > --- old/src/share/classes/java/awt/dnd/DragSourceContext.java > 2014-04-09 19:41:33.000000000 -0700 > +++ new/src/share/classes/java/awt/dnd/DragSourceContext.java > 2014-04-09 19:41:33.000000000 -0700 > @@ -472,7 +472,7 @@ > * ENTER, OVER, > * CHANGED > */ > - > + @SuppressWarnings("fallthrough") > protected synchronized void updateCurrentCursor(int sourceAct, > int targetAct, int status) { > > // if the cursor has been previously set then don't do any > defaults > --- old/src/share/classes/sun/awt/image/GifImageDecoder.java > 2014-04-09 19:41:33.000000000 -0700 > +++ new/src/share/classes/sun/awt/image/GifImageDecoder.java > 2014-04-09 19:41:33.000000000 -0700 > @@ -114,6 +114,7 @@ > /** > * produce an image from the stream. > */ > + @SuppressWarnings("fallthrough") > public void produceImage() throws IOException, > ImageFormatException { > try { > readHeader(); > @@ -238,7 +239,7 @@ > if (frameno == 0) { > return; > } > - // NOBREAK > + // Fall through > > case TERMINATOR: > if (nloops == 0 || nloops-- >= 0) { > --- old/src/share/classes/sun/awt/image/PixelConverter.java 2014-04-09 > 19:41:34.000000000 -0700 > +++ new/src/share/classes/sun/awt/image/PixelConverter.java 2014-04-09 > 19:41:33.000000000 -0700 > @@ -53,6 +53,7 @@ > > protected PixelConverter() {} > > + @SuppressWarnings("fallthrough") > public int rgbToPixel(int rgb, ColorModel cm) { > Object obj = cm.getDataElements(rgb, null); > switch (cm.getTransferType()) { > --- old/src/solaris/classes/sun/awt/X11/XWM.java 2014-04-09 > 19:41:34.000000000 -0700 > +++ new/src/solaris/classes/sun/awt/X11/XWM.java 2014-04-09 > 19:41:34.000000000 -0700 > @@ -1112,6 +1112,7 @@ > * Therefore, a compound state is just ICONIFIED | anything else. > * > */ > + @SuppressWarnings("fallthrough") > boolean supportsExtendedState(int state) { > switch (state) { > case Frame.MAXIMIZED_VERT: > @@ -1131,6 +1132,7 @@ > return true; > } > } > + /* FALLTROUGH */ > default: > return false; > } > From petr.pchelko at oracle.com Tue Apr 15 17:37:02 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 15 Apr 2014 21:37:02 +0400 Subject: JDK 9 RFR of JDK-8039861: Fix fallthrough lint warnings in awt In-Reply-To: <53460574.2010704@oracle.com> References: <53460574.2010704@oracle.com> Message-ID: <1781E9F2-5E0E-4DB0-8AE5-08DE1EFF39FC@oracle.com> Hello, Joe. The fix looks good to me. With best regards. Petr. 10 ???. 2014 ?., ? 6:44 ?? ???????, Joe Darcy ???????(?): > Hello, > > Please review the changes for > > JDK-8039861: Fix fallthrough lint warnings in awt > http://cr.openjdk.java.net/~darcy/8039861.0/ > > Thanks, > > -Joe > > --- old/src/share/classes/java/awt/dnd/DragSourceContext.java 2014-04-09 19:41:33.000000000 -0700 > +++ new/src/share/classes/java/awt/dnd/DragSourceContext.java 2014-04-09 19:41:33.000000000 -0700 > @@ -472,7 +472,7 @@ > * ENTER, OVER, > * CHANGED > */ > - > + @SuppressWarnings("fallthrough") > protected synchronized void updateCurrentCursor(int sourceAct, int targetAct, int status) { > > // if the cursor has been previously set then don't do any defaults > --- old/src/share/classes/sun/awt/image/GifImageDecoder.java 2014-04-09 19:41:33.000000000 -0700 > +++ new/src/share/classes/sun/awt/image/GifImageDecoder.java 2014-04-09 19:41:33.000000000 -0700 > @@ -114,6 +114,7 @@ > /** > * produce an image from the stream. > */ > + @SuppressWarnings("fallthrough") > public void produceImage() throws IOException, ImageFormatException { > try { > readHeader(); > @@ -238,7 +239,7 @@ > if (frameno == 0) { > return; > } > - // NOBREAK > + // Fall through > > case TERMINATOR: > if (nloops == 0 || nloops-- >= 0) { > --- old/src/share/classes/sun/awt/image/PixelConverter.java 2014-04-09 19:41:34.000000000 -0700 > +++ new/src/share/classes/sun/awt/image/PixelConverter.java 2014-04-09 19:41:33.000000000 -0700 > @@ -53,6 +53,7 @@ > > protected PixelConverter() {} > > + @SuppressWarnings("fallthrough") > public int rgbToPixel(int rgb, ColorModel cm) { > Object obj = cm.getDataElements(rgb, null); > switch (cm.getTransferType()) { > --- old/src/solaris/classes/sun/awt/X11/XWM.java 2014-04-09 19:41:34.000000000 -0700 > +++ new/src/solaris/classes/sun/awt/X11/XWM.java 2014-04-09 19:41:34.000000000 -0700 > @@ -1112,6 +1112,7 @@ > * Therefore, a compound state is just ICONIFIED | anything else. > * > */ > + @SuppressWarnings("fallthrough") > boolean supportsExtendedState(int state) { > switch (state) { > case Frame.MAXIMIZED_VERT: > @@ -1131,6 +1132,7 @@ > return true; > } > } > + /* FALLTROUGH */ > default: > return false; > } > From philip.race at oracle.com Tue Apr 15 18:26:04 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 15 Apr 2014 11:26:04 -0700 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <534D30C0.3040806@oracle.com> References: <534BB5CA.6020801@oracle.com> <4A4F906C-BFBD-4D80-8F1B-2716AB7B1BD2@oracle.com> <534D191E.8030507@oracle.com> <534D30C0.3040806@oracle.com> Message-ID: <534D79BC.1060005@oracle.com> http://cr.openjdk.java.net/~yan/8039279/webrev.02/test/java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java.html import static sun.awt.OSInfo.*; Why is this using sun.* API ? In module mode this will be invisible. And all its used for is this :- if (getOSType() == OSType.WINDOWS) You can do that with a getProperty() call. 36 * @build ExtendedRobot jdk.testlibrary.Asserts What is ExtendedRobot ? I can't find it. And do we really need a library dependency just to do equals for us ?? 73 assertEquals(bound, max, 74 "The bounds of the Frame equal to what" 75 + " is specified when the frame is in Frame.MAXIMIZED_BOTH state"); Could easily be replaced by if (!bounds.equals(max)) throw new RuntimeException(...); We should make the tests as easy to run standalone as possible and avoid internal APIs. -phil On 4/15/2014 6:14 AM, Sergey Bylokhov wrote: > Hi, Dmitriy. > A few comments: > SetMaximizedBounds.java: please add macosx to the test coverage. It > does not work now but the fix is under review. > ChangeGridSize.java/ ComponentPreferredSize.java: actionPerformed must > be volatile, all other constant can be final. > ModifierRobotKeyTest.java: tempPress must be volatile, access to > modifierStatus[] and textStatus should be synchronized somehow. > LockingKeyStateTest.java:I guess we have synchronization problem as well. > > Additionally, can you dispose all frames in the tests. > > On 4/15/14 3:33 PM, Dmitriy Ermashov wrote: >> Hi all. >> >> Petr, thanks for review! >> >> Guys, could you also review this tests? >> http://cr.openjdk.java.net/~yan/8039279/webrev.02/ >> > > > -- > Best regards, Sergey. From yuri.nesterenko at oracle.com Wed Apr 16 06:41:45 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 16 Apr 2014 10:41:45 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <534D79BC.1060005@oracle.com> References: <534BB5CA.6020801@oracle.com> <4A4F906C-BFBD-4D80-8F1B-2716AB7B1BD2@oracle.com> <534D191E.8030507@oracle.com> <534D30C0.3040806@oracle.com> <534D79BC.1060005@oracle.com> Message-ID: <534E2629.5060406@oracle.com> On 04/15/2014 10:26 PM, Phil Race wrote: > http://cr.openjdk.java.net/~yan/8039279/webrev.02/test/java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java.html > > > > import static sun.awt.OSInfo.*; > > Why is this using sun.* API ? > In module mode this will be invisible. > > And all its used for is this :- > if (getOSType() == OSType.WINDOWS) > > You can do that with a getProperty() call. Personally, I agree with that and try not to use OSInfo. However the author of the fix was forced to use it by previous reviewers. It is considered a standard routine by now. For jigsaw, we'll have to invent something to accommodate that. > > > 36 * @build ExtendedRobot jdk.testlibrary.Asserts > > What is ExtendedRobot ? I can't find it. > > > And do we really need a library dependency just to > do equals for us ?? Re: ExtendedRobot please see https://bugs.openjdk.java.net/browse/JDK-8038631 and explanations of our objectives there. It was discussed in this list and run through 7 cycles of review. In short, we have hundreds of existing tests depending on very complex Robot extensions. We have to move all of them to the regression suite. And exactly to get rid of (even) binary dependencies we proposed a minimal extension which is both useful and allows us not to rewrite the bulk of old code whenever possible. This portion of tests also is not written anew (which would be easier, it seems) but ported from functional suite. > > 73 assertEquals(bound, max, > 74 "The bounds of the Frame equal to what" > 75 + " is specified when the frame is in > Frame.MAXIMIZED_BOTH state"); > > Could easily be replaced by > if (!bounds.equals(max)) throw new RuntimeException(...); > > We should make the tests as easy to run standalone as possible > and avoid internal APIs. Hear, hear! Other colleagues here have different opinions though. -yan > > -phil > > On 4/15/2014 6:14 AM, Sergey Bylokhov wrote: >> Hi, Dmitriy. >> A few comments: >> SetMaximizedBounds.java: please add macosx to the test coverage. It >> does not work now but the fix is under review. >> ChangeGridSize.java/ ComponentPreferredSize.java: actionPerformed must >> be volatile, all other constant can be final. >> ModifierRobotKeyTest.java: tempPress must be volatile, access to >> modifierStatus[] and textStatus should be synchronized somehow. >> LockingKeyStateTest.java:I guess we have synchronization problem as well. >> >> Additionally, can you dispose all frames in the tests. >> >> On 4/15/14 3:33 PM, Dmitriy Ermashov wrote: >>> Hi all. >>> >>> Petr, thanks for review! >>> >>> Guys, could you also review this tests? >>> http://cr.openjdk.java.net/~yan/8039279/webrev.02/ >>> >> >> >> -- >> Best regards, Sergey. > From petr.pchelko at oracle.com Wed Apr 16 08:32:05 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 16 Apr 2014 12:32:05 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <534E2629.5060406@oracle.com> References: <534BB5CA.6020801@oracle.com> <4A4F906C-BFBD-4D80-8F1B-2716AB7B1BD2@oracle.com> <534D191E.8030507@oracle.com> <534D30C0.3040806@oracle.com> <534D79BC.1060005@oracle.com> <534E2629.5060406@oracle.com> Message-ID: Hello, >> import static sun.awt.OSInfo.*; >> >> Why is this using sun.* API ? >> In module mode this will be invisible. >> >> And all its used for is this :- >> if (getOSType() == OSType.WINDOWS) >> >> You can do that with a getProperty() call. > > Personally, I agree with that and try not to use OSInfo. > However the author of the fix was forced to use it by > previous reviewers. It is considered a standard routine > by now. Right now the tests are filled with this pattern... And with other private APIs. We have SunToolkit in almost every single test, but it's really better to not use private APIs in new tests. We didn't think about Jigsaw when making this comment, probably using the os.name property would be better. Sorry, Dmitriy, look like I've pushed you to the wrong path here. >> 36 * @build ExtendedRobot jdk.testlibrary.Asserts >> >> What is ExtendedRobot ? I can't find it. >> >> >> And do we really need a library dependency just to >> do equals for us ?? > Re: ExtendedRobot please see > https://bugs.openjdk.java.net/browse/JDK-8038631 > and explanations of our objectives there. > It was discussed in this list and run through 7 cycles > of review. > In short, we have hundreds of existing tests depending > on very complex Robot extensions. We have to move all > of them to the regression suite. And exactly to get rid of > (even) binary dependencies we proposed a minimal extension > which is both useful and allows us not to rewrite the bulk > of old code whenever possible. > This portion of tests also is not written anew > (which would be easier, it seems) but ported from functional > suite. Just to add, we expect that the ExtendedRobot features will be moved to the awt Robot and made public API when the process of test migration moves on and the features would be baked in the ExtendedRobot. Additionally we will try to import all of our other helpers into Robot at some point. >> 73 assertEquals(bound, max, >> 74 "The bounds of the Frame equal to what" >> 75 + " is specified when the frame is in >> Frame.MAXIMIZED_BOTH state"); >> >> Could easily be replaced by >> if (!bounds.equals(max)) throw new RuntimeException(...); >> >> We should make the tests as easy to run standalone as possible >> and avoid internal APIs. > > Hear, hear! > Other colleagues here have different opinions though. This was also my idea to use this. The code looks cleaner with it, but it's probably the matter of taste. Currently we use awt and swing regtesthelpers, process helpers and JRobot in almost every test, so I thought it wouldn't be harmful to use yet another library. No strong opinion here, so if Phil thinks this practice is bad I'd agree with him. With best regards. Petr. On 16.04.2014, at 10:41, Yuri Nesterenko wrote: > On 04/15/2014 10:26 PM, Phil Race wrote: >> http://cr.openjdk.java.net/~yan/8039279/webrev.02/test/java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java.html >> >> >> >> import static sun.awt.OSInfo.*; >> >> Why is this using sun.* API ? >> In module mode this will be invisible. >> >> And all its used for is this :- >> if (getOSType() == OSType.WINDOWS) >> >> You can do that with a getProperty() call. > > Personally, I agree with that and try not to use OSInfo. > However the author of the fix was forced to use it by > previous reviewers. It is considered a standard routine > by now. For jigsaw, we'll have to invent something > to accommodate that. > >> >> >> 36 * @build ExtendedRobot jdk.testlibrary.Asserts >> >> What is ExtendedRobot ? I can't find it. >> >> >> And do we really need a library dependency just to >> do equals for us ?? > Re: ExtendedRobot please see > https://bugs.openjdk.java.net/browse/JDK-8038631 > and explanations of our objectives there. > It was discussed in this list and run through 7 cycles > of review. > In short, we have hundreds of existing tests depending > on very complex Robot extensions. We have to move all > of them to the regression suite. And exactly to get rid of > (even) binary dependencies we proposed a minimal extension > which is both useful and allows us not to rewrite the bulk > of old code whenever possible. > This portion of tests also is not written anew > (which would be easier, it seems) but ported from functional > suite. > >> >> 73 assertEquals(bound, max, >> 74 "The bounds of the Frame equal to what" >> 75 + " is specified when the frame is in >> Frame.MAXIMIZED_BOTH state"); >> >> Could easily be replaced by >> if (!bounds.equals(max)) throw new RuntimeException(...); >> >> We should make the tests as easy to run standalone as possible >> and avoid internal APIs. > > Hear, hear! > Other colleagues here have different opinions though. > > -yan > >> >> -phil >> >> On 4/15/2014 6:14 AM, Sergey Bylokhov wrote: >>> Hi, Dmitriy. >>> A few comments: >>> SetMaximizedBounds.java: please add macosx to the test coverage. It >>> does not work now but the fix is under review. >>> ChangeGridSize.java/ ComponentPreferredSize.java: actionPerformed must >>> be volatile, all other constant can be final. >>> ModifierRobotKeyTest.java: tempPress must be volatile, access to >>> modifierStatus[] and textStatus should be synchronized somehow. >>> LockingKeyStateTest.java:I guess we have synchronization problem as well. >>> >>> Additionally, can you dispose all frames in the tests. >>> >>> On 4/15/14 3:33 PM, Dmitriy Ermashov wrote: >>>> Hi all. >>>> >>>> Petr, thanks for review! >>>> >>>> Guys, could you also review this tests? >>>> http://cr.openjdk.java.net/~yan/8039279/webrev.02/ >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > From dmitriy.ermashov at oracle.com Wed Apr 16 08:39:56 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Wed, 16 Apr 2014 12:39:56 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: References: <534BB5CA.6020801@oracle.com> <4A4F906C-BFBD-4D80-8F1B-2716AB7B1BD2@oracle.com> <534D191E.8030507@oracle.com> <534D30C0.3040806@oracle.com> <534D79BC.1060005@oracle.com> <534E2629.5060406@oracle.com> Message-ID: <534E41DC.8070203@oracle.com> On 04/16/2014 12:32 PM, Petr Pchelko wrote: > Hello, > >>> import static sun.awt.OSInfo.*; >>> >>> Why is this using sun.* API ? >>> In module mode this will be invisible. >>> >>> And all its used for is this :- >>> if (getOSType() == OSType.WINDOWS) >>> >>> You can do that with a getProperty() call. >> Personally, I agree with that and try not to use OSInfo. >> However the author of the fix was forced to use it by >> previous reviewers. It is considered a standard routine >> by now. > Right now the tests are filled with this pattern... And with other > private APIs. We have SunToolkit in almost every single test, but it's > really better to not use private APIs in new tests. > We didn't think about Jigsaw when making this comment, > probably using the os.name property would be better. > Sorry, Dmitriy, look like I've pushed you to the wrong path here. > >>> 36 * @build ExtendedRobot jdk.testlibrary.Asserts >>> >>> What is ExtendedRobot ? I can't find it. >>> >>> >>> And do we really need a library dependency just to >>> do equals for us ?? >> Re: ExtendedRobot please see >> https://bugs.openjdk.java.net/browse/JDK-8038631 >> and explanations of our objectives there. >> It was discussed in this list and run through 7 cycles >> of review. >> In short, we have hundreds of existing tests depending >> on very complex Robot extensions. We have to move all >> of them to the regression suite. And exactly to get rid of >> (even) binary dependencies we proposed a minimal extension >> which is both useful and allows us not to rewrite the bulk >> of old code whenever possible. >> This portion of tests also is not written anew >> (which would be easier, it seems) but ported from functional >> suite. > Just to add, we expect that the ExtendedRobot features will be > moved to the awt Robot and made public API when the process > of test migration moves on and the features would be baked in > the ExtendedRobot. Additionally we will try to import all of our > other helpers into Robot at some point. > >>> 73 assertEquals(bound, max, >>> 74 "The bounds of the Frame equal to what" >>> 75 + " is specified when the frame is in >>> Frame.MAXIMIZED_BOTH state"); >>> >>> Could easily be replaced by >>> if (!bounds.equals(max)) throw new RuntimeException(...); >>> >>> We should make the tests as easy to run standalone as possible >>> and avoid internal APIs. >> Hear, hear! >> Other colleagues here have different opinions though. > This was also my idea to use this. The code looks cleaner with it, > but it's probably the matter of taste. Currently we use awt and swing > regtesthelpers, process helpers and JRobot in almost every test, > so I thought it wouldn't be harmful to use yet another library. No strong > opinion here, so if Phil thinks this practice is bad I'd agree with him. I agree with Phil that we have no real need in usage Asserts library here. But I suppose that most of tests that uses this dependency can do without it. And it is not the reason to rewrite tests. Asserts usage looks more clear and that's why it makes sense. I believe that elegance and readability must be over independence. And this rule touches other functional tests. > With best regards. Petr. > > On 16.04.2014, at 10:41, Yuri Nesterenko wrote: > >> On 04/15/2014 10:26 PM, Phil Race wrote: >>> http://cr.openjdk.java.net/~yan/8039279/webrev.02/test/java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java.html >>> >>> >>> >>> import static sun.awt.OSInfo.*; >>> >>> Why is this using sun.* API ? >>> In module mode this will be invisible. >>> >>> And all its used for is this :- >>> if (getOSType() == OSType.WINDOWS) >>> >>> You can do that with a getProperty() call. >> Personally, I agree with that and try not to use OSInfo. >> However the author of the fix was forced to use it by >> previous reviewers. It is considered a standard routine >> by now. For jigsaw, we'll have to invent something >> to accommodate that. >> >>> >>> 36 * @build ExtendedRobot jdk.testlibrary.Asserts >>> >>> What is ExtendedRobot ? I can't find it. >>> >>> >>> And do we really need a library dependency just to >>> do equals for us ?? >> Re: ExtendedRobot please see >> https://bugs.openjdk.java.net/browse/JDK-8038631 >> and explanations of our objectives there. >> It was discussed in this list and run through 7 cycles >> of review. >> In short, we have hundreds of existing tests depending >> on very complex Robot extensions. We have to move all >> of them to the regression suite. And exactly to get rid of >> (even) binary dependencies we proposed a minimal extension >> which is both useful and allows us not to rewrite the bulk >> of old code whenever possible. >> This portion of tests also is not written anew >> (which would be easier, it seems) but ported from functional >> suite. >> >>> 73 assertEquals(bound, max, >>> 74 "The bounds of the Frame equal to what" >>> 75 + " is specified when the frame is in >>> Frame.MAXIMIZED_BOTH state"); >>> >>> Could easily be replaced by >>> if (!bounds.equals(max)) throw new RuntimeException(...); >>> >>> We should make the tests as easy to run standalone as possible >>> and avoid internal APIs. >> Hear, hear! >> Other colleagues here have different opinions though. >> >> -yan >> >>> -phil >>> >>> On 4/15/2014 6:14 AM, Sergey Bylokhov wrote: >>>> Hi, Dmitriy. >>>> A few comments: >>>> SetMaximizedBounds.java: please add macosx to the test coverage. It >>>> does not work now but the fix is under review. >>>> ChangeGridSize.java/ ComponentPreferredSize.java: actionPerformed must >>>> be volatile, all other constant can be final. >>>> ModifierRobotKeyTest.java: tempPress must be volatile, access to >>>> modifierStatus[] and textStatus should be synchronized somehow. >>>> LockingKeyStateTest.java:I guess we have synchronization problem as well. >>>> >>>> Additionally, can you dispose all frames in the tests. >>>> >>>> On 4/15/14 3:33 PM, Dmitriy Ermashov wrote: >>>>> Hi all. >>>>> >>>>> Petr, thanks for review! >>>>> >>>>> Guys, could you also review this tests? >>>>> http://cr.openjdk.java.net/~yan/8039279/webrev.02/ >>>>> >>>> >>>> -- >>>> Best regards, Sergey. -- Thanks, Dima From anthony.petrov at oracle.com Wed Apr 16 11:56:02 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 16 Apr 2014 15:56:02 +0400 Subject: [9] Review Request: 7124365 [macosx] setMaximizedBounds() should be implemented In-Reply-To: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> References: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> Message-ID: <534E6FD2.4070900@oracle.com> Hi Petr, src/macosx/native/sun/awt/AWTWindow.m > 125 @synthesize preFullScreenLevel; > 126 @synthesize javaMaximizedBounds = _javaMaximizedBounds; The style of instantiation of the javaMaximizedBounds property differs from a bunch of other properties. Is there any particular reason for that? Do we need to change other @synthesize directives above this one as well? > 255 self.javaMaximizedBounds = NSMakeRect(-1, -1, -1, -1); In a multi-screen environment, could -1 indicate a valid value for a coordinate that user code might actually want to use? > 1033 if (y >= 0) { The specification of Frame.setMaximizedBounds() allows a developer to provide some of the fixed parameters only (e.g. the width and the x coordinate), leaving others set to their default, system-provided values. So the condition you're checking here seems incorrect. -- best regards, Anthony On 4/15/2014 4:33 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-7124365 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/7124365/webrev/ > > The implementation is pretty straightforward. > In native -1 indicates that this bound is not set. Using Integer.MAX_VALUE as in Frame?s javadoc isn?t convenient in native code. > We do not need to worry about bounds that do not fit the screen - Cocoa handles it for us. > But we need to handle the maximum/minimum sizes manually, because these are applied before the willUseStandardFrame callback is called. > The regression test for this exists, it?s being moved from SQE right now. I?ll modify it to support Mac as soon as it?s pushed. > > Thank you. > With best regards. Petr. > From petr.pchelko at oracle.com Wed Apr 16 12:14:12 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 16 Apr 2014 16:14:12 +0400 Subject: [9] Review Request: 7124365 [macosx] setMaximizedBounds() should be implemented In-Reply-To: <534E6FD2.4070900@oracle.com> References: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> <534E6FD2.4070900@oracle.com> Message-ID: <666CFA57-EE7D-4D11-947A-DA819B15FBA0@oracle.com> >> 125 @synthesize preFullScreenLevel; >> 126 @synthesize javaMaximizedBounds = _javaMaximizedBounds; > > The style of instantiation of the javaMaximizedBounds property differs from a bunch of other properties. > Is there any particular reason for that? Do we need to change other @synthesize directives above this one as well? The new style is kind of better, because do not need to declare the instance cariable - it's created for you. With an old pattern you had to declare it in the .h file. I can replace this with and old style for consistency. >> 1033 if (y >= 0) { > > The specification of Frame.setMaximizedBounds() allows a developer to provide some of the fixed parameters only (e.g. the width and the x coordinate), > leaving others set to their default, system-provided values. So the condition you're checking here seems incorrect. According to the setMaximizedBounds docs the user needs to set Integer.MAX_VALUE to leave a particular coordinate default. In LWWindowPeer I replace the Integer.MAX_VALUE with -1, because the MAX_VALUE is not that reliable in native environment. Cocoa has NSUIntegerMax constant, but it is be different in 32bit/64bit, NSRect coords is stored in a float and using huge values there could lead to unpredictable bugs because of rounding. This condition is added because we do not want to flip the y coord if it's -1 (which means not set). >> 255 self.javaMaximizedBounds = NSMakeRect(-1, -1, -1, -1); > > In a multi-screen environment, could -1 indicate a valid value for a coordinate that user code might actually want to use? From Apple's documentation the return rectangle is clipped to fit the current screen of the window. So no, it can not. Even if the user will set negative values the will be clipped anyway and it will not work, so I think we need to explicitly threat all negatives as "Not Set". I'll update the fix. On 16.04.2014, at 15:56, Anthony Petrov wrote: > Hi Petr, > > src/macosx/native/sun/awt/AWTWindow.m >> 125 @synthesize preFullScreenLevel; >> 126 @synthesize javaMaximizedBounds = _javaMaximizedBounds; > > The style of instantiation of the javaMaximizedBounds property differs from a bunch of other properties. Is there any particular reason for that? Do we need to change other @synthesize directives above this one as well? > > >> 255 self.javaMaximizedBounds = NSMakeRect(-1, -1, -1, -1); > > In a multi-screen environment, could -1 indicate a valid value for a coordinate that user code might actually want to use? > > >> 1033 if (y >= 0) { > > The specification of Frame.setMaximizedBounds() allows a developer to provide some of the fixed parameters only (e.g. the width and the x coordinate), leaving others set to their default, system-provided values. So the condition you're checking here seems incorrect. > > -- > best regards, > Anthony > > On 4/15/2014 4:33 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-7124365 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/7124365/webrev/ >> >> The implementation is pretty straightforward. >> In native -1 indicates that this bound is not set. Using Integer.MAX_VALUE as in Frame?s javadoc isn?t convenient in native code. >> We do not need to worry about bounds that do not fit the screen - Cocoa handles it for us. >> But we need to handle the maximum/minimum sizes manually, because these are applied before the willUseStandardFrame callback is called. >> The regression test for this exists, it?s being moved from SQE right now. I?ll modify it to support Mac as soon as it?s pushed. >> >> Thank you. >> With best regards. Petr. >> From anthony.petrov at oracle.com Wed Apr 16 12:40:04 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 16 Apr 2014 16:40:04 +0400 Subject: [9] Review Request: 7124365 [macosx] setMaximizedBounds() should be implemented In-Reply-To: <666CFA57-EE7D-4D11-947A-DA819B15FBA0@oracle.com> References: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> <534E6FD2.4070900@oracle.com> <666CFA57-EE7D-4D11-947A-DA819B15FBA0@oracle.com> Message-ID: <534E7A24.5050802@oracle.com> On 4/16/2014 4:14 PM, Petr Pchelko wrote: >>> 125 @synthesize preFullScreenLevel; >>> 126 @synthesize javaMaximizedBounds = _javaMaximizedBounds; >> >> The style of instantiation of the javaMaximizedBounds property differs from a bunch of other properties. >> Is there any particular reason for that? Do we need to change other @synthesize directives above this one as well? > > The new style is kind of better, because do not need to declare the instance cariable - it's created for you. > With an old pattern you had to declare it in the .h file. I can replace this with and old style for consistency. I'm fine with either style as long as our code uses it everywhere consistently. >>> 1033 if (y >= 0) { >> >> The specification of Frame.setMaximizedBounds() allows a developer to provide some of the fixed parameters only (e.g. the width and the x coordinate), >> leaving others set to their default, system-provided values. So the condition you're checking here seems incorrect. > According to the setMaximizedBounds docs the user needs to set Integer.MAX_VALUE to leave a particular coordinate default. > In LWWindowPeer I replace the Integer.MAX_VALUE with -1, because the MAX_VALUE is not that reliable in native environment. > Cocoa has NSUIntegerMax constant, but it is be different in 32bit/64bit, NSRect coords is stored in a float and using huge values > there could lead to unpredictable bugs because of rounding. This condition is added because we do not want to flip the y coord > if it's -1 (which means not set). Right. Thanks for the clarification. >>> 255 self.javaMaximizedBounds = NSMakeRect(-1, -1, -1, -1); >> >> In a multi-screen environment, could -1 indicate a valid value for a coordinate that user code might actually want to use? > From Apple's documentation the return rectangle is clipped to fit the current screen of the window. So no, it can not. > Even if the user will set negative values the will be clipped anyway and it will not work, so I think we need to explicitly > threat all negatives as "Not Set". I'll update the fix. I don't believe so. Try configuring a secondary screen on the left from the main screen. The secondary screen will have negative coordinates then, and you could position you window at, say, (-200, 100), which is perfectly valid, no? The same is true for (-1, 100) then, too. -- best regards, Anthony > > > On 16.04.2014, at 15:56, Anthony Petrov wrote: > >> Hi Petr, >> >> src/macosx/native/sun/awt/AWTWindow.m >>> 125 @synthesize preFullScreenLevel; >>> 126 @synthesize javaMaximizedBounds = _javaMaximizedBounds; >> >> The style of instantiation of the javaMaximizedBounds property differs from a bunch of other properties. Is there any particular reason for that? Do we need to change other @synthesize directives above this one as well? >> >> >>> 255 self.javaMaximizedBounds = NSMakeRect(-1, -1, -1, -1); >> >> In a multi-screen environment, could -1 indicate a valid value for a coordinate that user code might actually want to use? >> >> >>> 1033 if (y >= 0) { >> >> The specification of Frame.setMaximizedBounds() allows a developer to provide some of the fixed parameters only (e.g. the width and the x coordinate), leaving others set to their default, system-provided values. So the condition you're checking here seems incorrect. >> >> -- >> best regards, >> Anthony >> >> On 4/15/2014 4:33 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-7124365 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/9/7124365/webrev/ >>> >>> The implementation is pretty straightforward. >>> In native -1 indicates that this bound is not set. Using Integer.MAX_VALUE as in Frame?s javadoc isn?t convenient in native code. >>> We do not need to worry about bounds that do not fit the screen - Cocoa handles it for us. >>> But we need to handle the maximum/minimum sizes manually, because these are applied before the willUseStandardFrame callback is called. >>> The regression test for this exists, it?s being moved from SQE right now. I?ll modify it to support Mac as soon as it?s pushed. >>> >>> Thank you. >>> With best regards. Petr. >>> > From petr.pchelko at oracle.com Wed Apr 16 12:55:37 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 16 Apr 2014 16:55:37 +0400 Subject: [9] Review Request: 7124365 [macosx] setMaximizedBounds() should be implemented In-Reply-To: <534E7A24.5050802@oracle.com> References: <8F04F23E-DD95-4BC0-AF48-48C819F4DCE8@oracle.com> <534E6FD2.4070900@oracle.com> <666CFA57-EE7D-4D11-947A-DA819B15FBA0@oracle.com> <534E7A24.5050802@oracle.com> Message-ID: <9313A04C-E42F-4972-A3CD-A8C924D12D1B@oracle.com> >>>> 255 self.javaMaximizedBounds = NSMakeRect(-1, -1, -1, -1); >>> >>> In a multi-screen environment, could -1 indicate a valid value for a coordinate that user code might actually want to use? >> From Apple's documentation the return rectangle is clipped to fit the current screen of the window. So no, it can not. >> Even if the user will set negative values the will be clipped anyway and it will not work, so I think we need to explicitly >> threat all negatives as "Not Set". I'll update the fix. > > I don't believe so. Try configuring a secondary screen on the left from the main screen. The secondary screen will have negative > coordinates then, and you could position you window at, say, (-200, 100), which is perfectly valid, no? The same is true for (-1, 100) then, too. On 10.8 this is exactly as you are saying. This line in the documentation tricked me: On return from this method, the zoom: method modifies the returned standard frame, if necessary, to fit on the current screen. I'll tests the multiscreen configuration also with 10.9 as it has quite different multiscreen behavior and write my findings. With best regards. Petr. On 16.04.2014, at 16:40, Anthony Petrov wrote: > On 4/16/2014 4:14 PM, Petr Pchelko wrote: >>>> 125 @synthesize preFullScreenLevel; >>>> 126 @synthesize javaMaximizedBounds = _javaMaximizedBounds; >>> >>> The style of instantiation of the javaMaximizedBounds property differs from a bunch of other properties. >>> Is there any particular reason for that? Do we need to change other @synthesize directives above this one as well? >> >> The new style is kind of better, because do not need to declare the instance cariable - it's created for you. >> With an old pattern you had to declare it in the .h file. I can replace this with and old style for consistency. > > I'm fine with either style as long as our code uses it everywhere consistently. > > >>>> 1033 if (y >= 0) { >>> >>> The specification of Frame.setMaximizedBounds() allows a developer to provide some of the fixed parameters only (e.g. the width and the x coordinate), >>> leaving others set to their default, system-provided values. So the condition you're checking here seems incorrect. >> According to the setMaximizedBounds docs the user needs to set Integer.MAX_VALUE to leave a particular coordinate default. >> In LWWindowPeer I replace the Integer.MAX_VALUE with -1, because the MAX_VALUE is not that reliable in native environment. >> Cocoa has NSUIntegerMax constant, but it is be different in 32bit/64bit, NSRect coords is stored in a float and using huge values >> there could lead to unpredictable bugs because of rounding. This condition is added because we do not want to flip the y coord >> if it's -1 (which means not set). > > Right. Thanks for the clarification. > > >>>> 255 self.javaMaximizedBounds = NSMakeRect(-1, -1, -1, -1); >>> >>> In a multi-screen environment, could -1 indicate a valid value for a coordinate that user code might actually want to use? >> From Apple's documentation the return rectangle is clipped to fit the current screen of the window. So no, it can not. >> Even if the user will set negative values the will be clipped anyway and it will not work, so I think we need to explicitly >> threat all negatives as "Not Set". I'll update the fix. > > I don't believe so. Try configuring a secondary screen on the left from the main screen. The secondary screen will have negative coordinates then, and you could position you window at, say, (-200, 100), which is perfectly valid, no? The same is true for (-1, 100) then, too. > > -- > best regards, > Anthony > >> >> >> On 16.04.2014, at 15:56, Anthony Petrov wrote: >> >>> Hi Petr, >>> >>> src/macosx/native/sun/awt/AWTWindow.m >>>> 125 @synthesize preFullScreenLevel; >>>> 126 @synthesize javaMaximizedBounds = _javaMaximizedBounds; >>> >>> The style of instantiation of the javaMaximizedBounds property differs from a bunch of other properties. Is there any particular reason for that? Do we need to change other @synthesize directives above this one as well? >>> >>> >>>> 255 self.javaMaximizedBounds = NSMakeRect(-1, -1, -1, -1); >>> >>> In a multi-screen environment, could -1 indicate a valid value for a coordinate that user code might actually want to use? >>> >>> >>>> 1033 if (y >= 0) { >>> >>> The specification of Frame.setMaximizedBounds() allows a developer to provide some of the fixed parameters only (e.g. the width and the x coordinate), leaving others set to their default, system-provided values. So the condition you're checking here seems incorrect. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/15/2014 4:33 PM, Petr Pchelko wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-7124365 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/9/7124365/webrev/ >>>> >>>> The implementation is pretty straightforward. >>>> In native -1 indicates that this bound is not set. Using Integer.MAX_VALUE as in Frame?s javadoc isn?t convenient in native code. >>>> We do not need to worry about bounds that do not fit the screen - Cocoa handles it for us. >>>> But we need to handle the maximum/minimum sizes manually, because these are applied before the willUseStandardFrame callback is called. >>>> The regression test for this exists, it?s being moved from SQE right now. I?ll modify it to support Mac as soon as it?s pushed. >>>> >>>> Thank you. >>>> With best regards. Petr. >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.pchelko at oracle.com Wed Apr 16 14:42:04 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 16 Apr 2014 18:42:04 +0400 Subject: [9] Review Request: 8035169 Move ThreadGroupUtils from the sun.misc package Message-ID: <8B3ABD87-268C-41FD-BA35-A81BC4BF1D10@oracle.com> Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8035169 The fix is available at: http://cr.openjdk.java.net/~pchelko/9/8035169/webrev/ The ThreadGroupUtils class was added to sun.misc, but it's a bad practice for modularization. We should move it somewhere to AWT. Here I've put it to sun.awt.util. Nothing.s changed except moving the class. With best regards. Petr. From petr.pchelko at oracle.com Thu Apr 17 08:38:19 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 17 Apr 2014 12:38:19 +0400 Subject: [9] Review Request: 8039926 -spash: can't be combined with -xStartOnFirstThread since JDK 7 In-Reply-To: <5347D4DA.5050700@oracle.com> References: <5347D2A3.3020509@oracle.com> <91E9EBD2-9887-49CE-B552-5E26AF83E4DA@oracle.com> <5347D4DA.5050700@oracle.com> Message-ID: <33558E9E-AFAA-4A7F-B955-527E0CC569B8@oracle.com> Hello, Could I get a second review on this. With best regards. Petr. On 11.04.2014, at 15:41, Anthony Petrov wrote: > Sounds good. Thanks. > > -- > best regards, > Anthony > > On 4/11/2014 3:39 PM, Petr Pchelko wrote: >> Hello, Anthony. >> >> Thank you for the review. >> >>> Although it would be good to document somewhere (in a comment in the code?) that when running an SWT app in WebStart, the AWT splashscreen is unsupported. >> I'll add the comment before the push. >> Something like: "Can't check if running SWT in webstart, so splash screen in webstart SWT applications is not supported". >> >> With best regards. Petr. >> >> On 11.04.2014, at 15:31, Anthony Petrov wrote: >> >>> Hi Petr, >>> >>> The fix looks fine. I see that we're not checking the isSWTInWebStart() case (see awt.m), but I don't immediately see any way to check this actually, because the JVM isn't started yet when the splashscreen is initializing. So I think we're good with the current solution. Although it would be good to document somewhere (in a comment in the code?) that when running an SWT app in WebStart, the AWT splashscreen is unsupported. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/11/2014 3:14 PM, Petr Pchelko wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8039926 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/9/8039926/webrev.00/ >>>> >>>> When running SWT we should not start the main event loop for splashscreen because it breaks SWT. >>>> The only way understand that in splashscreen code is to check the system property launcher sets on >>>> the startup. We do the same in awt.m, but we cannot reuse the code because splash and awt are not >>>> statically linked. >>>> >>>> With best regards. Petr. >>>> >> From petr.pchelko at oracle.com Thu Apr 17 09:00:15 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 17 Apr 2014 13:00:15 +0400 Subject: [9] Review Request: 8039567 Duplicated code in DataTransferer In-Reply-To: <53455FF7.7070901@oracle.com> References: <06D2CA5B-B72A-46D4-A611-08AD640828B2@oracle.com> <53455FF7.7070901@oracle.com> Message-ID: Hello, Could I get a second review on this. With best regards. Petr. On 09.04.2014, at 18:57, Alexander Zvegintsev wrote: > Hi Petr, > > the fix looks good to me. > > Thanks, > > Alexander. > > On 04/09/2014 06:27 PM, Petr Pchelko wrote: >> Hello AWT team. >> >> Please review a simple cleanup fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8039567 >> The fix is available here: >> http://cr.openjdk.java.net/~pchelko/9/8039567/webrev/ >> >> 1. The getBestCharsetForTextFormat is duplicated 3 times in the code. >> 2. Caching of the default Charset in DataTransferer does not make sense as it's already cached in the Charset class itself. >> Adding more references to the nio.Charset is not a problem since it's used in this class anyway and we cannot break this >> dependency. >> >> With best regards. Petr. > From alexander.zvegintsev at oracle.com Thu Apr 17 09:00:49 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 17 Apr 2014 13:00:49 +0400 Subject: [9] Review Request: 8039926 -spash: can't be combined with -xStartOnFirstThread since JDK 7 In-Reply-To: <33558E9E-AFAA-4A7F-B955-527E0CC569B8@oracle.com> References: <5347D2A3.3020509@oracle.com> <91E9EBD2-9887-49CE-B552-5E26AF83E4DA@oracle.com> <5347D4DA.5050700@oracle.com> <33558E9E-AFAA-4A7F-B955-527E0CC569B8@oracle.com> Message-ID: <534F9841.9090900@oracle.com> Hello Petr, the fix looks fine to me. -- Thanks, Alexander. On 04/17/2014 12:38 PM, Petr Pchelko wrote: > Hello, > > Could I get a second review on this. > > With best regards. Petr. > > On 11.04.2014, at 15:41, Anthony Petrov wrote: > >> Sounds good. Thanks. >> >> -- >> best regards, >> Anthony >> >> On 4/11/2014 3:39 PM, Petr Pchelko wrote: >>> Hello, Anthony. >>> >>> Thank you for the review. >>> >>>> Although it would be good to document somewhere (in a comment in the code?) that when running an SWT app in WebStart, the AWT splashscreen is unsupported. >>> I'll add the comment before the push. >>> Something like: "Can't check if running SWT in webstart, so splash screen in webstart SWT applications is not supported". >>> >>> With best regards. Petr. >>> >>> On 11.04.2014, at 15:31, Anthony Petrov wrote: >>> >>>> Hi Petr, >>>> >>>> The fix looks fine. I see that we're not checking the isSWTInWebStart() case (see awt.m), but I don't immediately see any way to check this actually, because the JVM isn't started yet when the splashscreen is initializing. So I think we're good with the current solution. Although it would be good to document somewhere (in a comment in the code?) that when running an SWT app in WebStart, the AWT splashscreen is unsupported. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 4/11/2014 3:14 PM, Petr Pchelko wrote: >>>>> Hello, AWT Team. >>>>> >>>>> Please review the fix for the issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8039926 >>>>> The fix is available at: >>>>> http://cr.openjdk.java.net/~pchelko/9/8039926/webrev.00/ >>>>> >>>>> When running SWT we should not start the main event loop for splashscreen because it breaks SWT. >>>>> The only way understand that in splashscreen code is to check the system property launcher sets on >>>>> the startup. We do the same in awt.m, but we cannot reuse the code because splash and awt are not >>>>> statically linked. >>>>> >>>>> With best regards. Petr. >>>>> From alexander.zvegintsev at oracle.com Thu Apr 17 09:07:50 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 17 Apr 2014 13:07:50 +0400 Subject: [9] Review Request: 8035169 Move ThreadGroupUtils from the sun.misc package In-Reply-To: <8B3ABD87-268C-41FD-BA35-A81BC4BF1D10@oracle.com> References: <8B3ABD87-268C-41FD-BA35-A81BC4BF1D10@oracle.com> Message-ID: <534F99E6.8080906@oracle.com> Hello Petr, the fix looks fine to me. -- Thanks, Alexander. On 04/16/2014 06:42 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8035169 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8035169/webrev/ > > The ThreadGroupUtils class was added to sun.misc, but it's a bad > practice for modularization. We should move it somewhere to AWT. > Here I've put it to sun.awt.util. Nothing.s changed except moving the > class. > > With best regards. Petr. From dmitriy.ermashov at oracle.com Thu Apr 17 09:22:25 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Thu, 17 Apr 2014 13:22:25 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <534BB5CA.6020801@oracle.com> References: <534BB5CA.6020801@oracle.com> Message-ID: <534F9D51.7030906@oracle.com> Hi, Please, review the changeset for: https://bugs.openjdk.java.net/browse/JDK-8039279 Webrev is here: http://cr.openjdk.java.net/~yan/8039279/webrev.03/ Changelist: 1. Removed internal API usage (sun.awt.*) 2. Removed Asserts library dependency from all tests except of ModifierRobotKeyTest (too much usage of asserts in it). 3. Improved thread synchronization in ComponentPreferredSize, ChangeGridSize, ModifierRobotKeyTest, LockingKeyStateTest 4. Added disposing frame at the end of each test. Test runs on the following platforms seems stable: Windows 7 x64, Intel graphical card Ubuntu Linux 12.04 x64, Intel graphical card OS X 10.8.5 x64, NVIDIA GeForce 9400 Ubuntu 10.04 ARMv7 --Dima From Sergey.Bylokhov at oracle.com Thu Apr 17 09:58:34 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 Apr 2014 13:58:34 +0400 Subject: [9] Review Request: 8035169 Move ThreadGroupUtils from the sun.misc package In-Reply-To: <8B3ABD87-268C-41FD-BA35-A81BC4BF1D10@oracle.com> References: <8B3ABD87-268C-41FD-BA35-A81BC4BF1D10@oracle.com> Message-ID: <534FA5CA.6050906@oracle.com> Hi, Petr. Typo from the previous review "could could". On 16.04.2014 18:42, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8035169 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8035169/webrev/ > > The ThreadGroupUtils class was added to sun.misc, but it's a bad > practice for modularization. We should move it somewhere to AWT. > Here I've put it to sun.awt.util. Nothing.s changed except moving the > class. > > With best regards. Petr. -- Best regards, Sergey. From petr.pchelko at oracle.com Thu Apr 17 11:34:18 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 17 Apr 2014 15:34:18 +0400 Subject: [9] Review Request: 8035169 Move ThreadGroupUtils from the sun.misc package In-Reply-To: <534FA5CA.6050906@oracle.com> References: <8B3ABD87-268C-41FD-BA35-A81BC4BF1D10@oracle.com> <534FA5CA.6050906@oracle.com> Message-ID: Hello, Sergey. Thank you for the review. Fixed: http://cr.openjdk.java.net/~pchelko/9/8035169/webrev.01/ With best regards. Petr. On 17.04.2014, at 13:58, Sergey Bylokhov wrote: > Hi, Petr. > Typo from the previous review "could could". > > On 16.04.2014 18:42, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8035169 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/8035169/webrev/ >> >> The ThreadGroupUtils class was added to sun.misc, but it's a bad >> practice for modularization. We should move it somewhere to AWT. >> Here I've put it to sun.awt.util. Nothing.s changed except moving the >> class. >> >> With best regards. Petr. > > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Thu Apr 17 15:22:26 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 Apr 2014 19:22:26 +0400 Subject: [9] Review Request for JDK-8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: <44CF8F6F-DA12-44C8-906A-8CBAC73979E9@oracle.com> References: <534653BF.8090104@oracle.com> <53469F14.4000507@oracle.com> <534D11C5.2090901@oracle.com> <44CF8F6F-DA12-44C8-906A-8CBAC73979E9@oracle.com> Message-ID: <534FF1B2.2080700@oracle.com> Hi, Alexey. The fix looks good. On 4/15/14 3:13 PM, Petr Pchelko wrote: > Hello, Alexey. > > I?m fine with your fix. > > Thank you for filing a new bug for JDK 9. > > With best regards. Petr. > > 15 ???. 2014 ?., ? 3:02 ????? ???????, Alexey Ivanov ???????(?): > >> Hi Petr, >> >> Please look at the updated webrev with comment explaining why additional 'if' clause is added: >> http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.01/ >> >> I have submitted a new bug JDK-8040248: >> "Drag and drop between two components fails if performed quickly" >> https://bugs.openjdk.java.net/browse/JDK-8040248 >> >> Regards, >> Alexey. >> >> On 10.04.2014 18:31, Petr Pchelko wrote: >>> Hello, Alexey. >>> >>> Thank you for the clarification. >>> >>>> What actually happens is that native drag-and-drop operation completed already whereas this drag-and-drop operation on EDT didn't even started yet. Does throwing InvalidDnDOperationException look more appropriate than returning null in this case? >>> No, I think it?s not good. As a workaround it?s better to not return the data than to throw an exception. It would be really hard for the users to deal with such an exception. >>> >>> Please add some comment to the if clause to clarify what?s happening. >>> Otherwise the fix looks good to me. >>> >>> With best regards. Petr. >>> >>> 10 ???. 2014 ?., ? 5:39 ????? ???????, Alexey Ivanov ???????(?): >>> >>>> Hi Petr, >>>> >>>> If the requested data flavor is DataFlavor.javaJVMLocalObjectMimeType, then transferable is local to the JVM. It is stored to a static variable in SunDropTargetContextPeer.setCurrentJVMLocalSourceTransferable(). When processEnterMessage() is handled, its value is copied to instance variable "local". The instance variable is cleaned by processExitMessage(), the static variable is cleared by SunDragSourceContextPeer.cleanup(). >>>> >>>> If drag-and-drop operation is performed quickly, SunDragSourceContextPeer.cleanup() is called when mouse button is released and *before* processEnterMessage() is called. So when EDT finally handles MOUSE_ENTERED event and DropTargetListener.dragEnter() gets called, "local" transferable is already null. The listener tries to get the data from the transferable: >>>> DropTargetDragEvent.getTransferable(), and then >>>> Transferable.getTransferData(dataFlavor). >>>> >>>> The dataFlavor has MIME type of DataFlavor.javaJVMLocalObjectMimeType, and SunDropTargetContextPeer.currentJVMLocalSourceTransferable is already cleared. The representationClass field of the DataFlavor object is set to java.io.InputStream.class. So when SunDropTargetContextPeer.getNativeData() executes it tries to cast the data object to java.io.InputStream to deserialize the data but fails with the exception: >>>> java.lang.ClassCastException: DnD$DropObject cannot be cast to java.io.InputStream. >>>> >>>> This exception is caught internally, and IOException is thrown as it failed to get the data. At the same time, no IO should have occurred because a local source was dragged, so this exception is rather unexpected. >>>> >>>> >>>> What actually happens is that native drag-and-drop operation completed already whereas this drag-and-drop operation on EDT didn't even started yet. Does throwing InvalidDnDOperationException look more appropriate than returning null in this case? >>>> >>>> >>>> Sure, I'll submit a new bug for 9 to implement the proper fix. >>>> >>>> >>>> Regards, >>>> Alexey. >>>> >>>> On 10.04.2014 12:52, Petr Pchelko wrote: >>>>> Hello, Dmitry. >>>>> >>>>> Thank you for the detailed explanation of the issue. >>>>> >>>>> I?m OK with this workaround as this should be back ported to 8u and 7u, but I think we could try to provide a real fix in 9. >>>>> Could you please add some comment which shortly explains why the if clause was added? >>>>> And could you also file a new bug for 9 so that we try to replace the workaround with a real fix? >>>>> >>>>> Thank you. >>>>> With best regards. Petr. >>>>> >>>>> 10 ???. 2014 ?., ? 12:18 ????? ???????, Alexey Ivanov ???????(?): >>>>> >>>>>> Hello AWT team, >>>>>> >>>>>> Could you please review the fix for jdk9: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8024061 >>>>>> webrev: http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.00/ >>>>>> >>>>>> Problem description: >>>>>> Dragging and dropping an object from one panel to another very quickly causes an exception. >>>>>> >>>>>> Fix: >>>>>> The fix addresses only the thrown exception. >>>>>> The dragged object would not be moved. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Alexey. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Apr 17 15:44:32 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 Apr 2014 19:44:32 +0400 Subject: [9] Review Request: 8039567 Duplicated code in DataTransferer In-Reply-To: References: <06D2CA5B-B72A-46D4-A611-08AD640828B2@oracle.com> <53455FF7.7070901@oracle.com> Message-ID: <534FF6E0.2070504@oracle.com> Hi, Petr. The fix looks good. But can you split the long lines in the DataTransferer.java, it seems it has right margin = 80. On 4/17/14 1:00 PM, Petr Pchelko wrote: > Hello, > > Could I get a second review on this. > > With best regards. Petr. > > On 09.04.2014, at 18:57, Alexander Zvegintsev wrote: > >> Hi Petr, >> >> the fix looks good to me. >> >> Thanks, >> >> Alexander. >> >> On 04/09/2014 06:27 PM, Petr Pchelko wrote: >>> Hello AWT team. >>> >>> Please review a simple cleanup fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8039567 >>> The fix is available here: >>> http://cr.openjdk.java.net/~pchelko/9/8039567/webrev/ >>> >>> 1. The getBestCharsetForTextFormat is duplicated 3 times in the code. >>> 2. Caching of the default Charset in DataTransferer does not make sense as it's already cached in the Charset class itself. >>> Adding more references to the nio.Charset is not a problem since it's used in this class anyway and we cannot break this >>> dependency. >>> >>> With best regards. Petr. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Apr 17 15:51:21 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 Apr 2014 19:51:21 +0400 Subject: [9] Review Request: 8035169 Move ThreadGroupUtils from the sun.misc package In-Reply-To: References: <8B3ABD87-268C-41FD-BA35-A81BC4BF1D10@oracle.com> <534FA5CA.6050906@oracle.com> Message-ID: <534FF879.5090804@oracle.com> Hi, Petr. The fix looks good. On 4/17/14 3:34 PM, Petr Pchelko wrote: > Hello, Sergey. > > Thank you for the review. > Fixed: http://cr.openjdk.java.net/~pchelko/9/8035169/webrev.01/ > > With best regards. Petr. > > On 17.04.2014, at 13:58, Sergey Bylokhov wrote: > >> Hi, Petr. >> Typo from the previous review "could could". >> >> On 16.04.2014 18:42, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8035169 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/9/8035169/webrev/ >>> >>> The ThreadGroupUtils class was added to sun.misc, but it's a bad >>> practice for modularization. We should move it somewhere to AWT. >>> Here I've put it to sun.awt.util. Nothing.s changed except moving the >>> class. >>> >>> With best regards. Petr. >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Thu Apr 17 16:29:11 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 17 Apr 2014 20:29:11 +0400 Subject: [9] Review Request: 8035169 Move ThreadGroupUtils from the sun.misc package In-Reply-To: <534FF879.5090804@oracle.com> References: <8B3ABD87-268C-41FD-BA35-A81BC4BF1D10@oracle.com> <534FA5CA.6050906@oracle.com> <534FF879.5090804@oracle.com> Message-ID: <53500157.70805@oracle.com> Still looks good to me. -- Thanks, Alexander. 17.04.2014 19:51, Sergey Bylokhov wrote: > Hi, Petr. > The fix looks good. > > On 4/17/14 3:34 PM, Petr Pchelko wrote: >> Hello, Sergey. >> >> Thank you for the review. >> Fixed: http://cr.openjdk.java.net/~pchelko/9/8035169/webrev.01/ >> >> With best regards. Petr. >> >> On 17.04.2014, at 13:58, Sergey Bylokhov >> wrote: >> >>> Hi, Petr. >>> Typo from the previous review "could could". >>> >>> On 16.04.2014 18:42, Petr Pchelko wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8035169 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/9/8035169/webrev/ >>>> >>>> The ThreadGroupUtils class was added to sun.misc, but it's a bad >>>> practice for modularization. We should move it somewhere to AWT. >>>> Here I've put it to sun.awt.util. Nothing.s changed except moving the >>>> class. >>>> >>>> With best regards. Petr. >>> >>> -- >>> Best regards, Sergey. >>> > > From joe.darcy at oracle.com Thu Apr 17 16:41:07 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 17 Apr 2014 09:41:07 -0700 Subject: JDK 9 RFR of JDK-8039861: Fix fallthrough lint warnings in awt In-Reply-To: <1781E9F2-5E0E-4DB0-8AE5-08DE1EFF39FC@oracle.com> References: <53460574.2010704@oracle.com> <1781E9F2-5E0E-4DB0-8AE5-08DE1EFF39FC@oracle.com> Message-ID: <53500423.7060807@oracle.com> Hi Petr, Thanks for the review. While preparing to push this, I noticed another instance of this situation in XComponentPeer.java: --- a/src/solaris/classes/sun/awt/X11/XComponentPeer.java Thu Apr 17 16:26:45 2014 +0400 +++ b/src/solaris/classes/sun/awt/X11/XComponentPeer.java Thu Apr 17 09:38:13 2014 -0700 @@ -548,6 +548,7 @@ } } + @SuppressWarnings("fallthrough") public void handleEvent(java.awt.AWTEvent e) { if ((e instanceof InputEvent) && !((InputEvent)e).isConsumed() && target.isEnabled()) { if (e instanceof MouseEvent) { The switch statement in question already has the fallthrough commented switch(id) { case PaintEvent.PAINT: // Got native painting paintPending = false; // Fallthrough to next statement case PaintEvent.UPDATE: // Skip all painting while layouting and all UPDATEs // while waiting for native paint if (!isLayouting && !paintPending) { paintArea.paint(target,false); } so I'll add the annotation at the time time. Thanks, -Joe On 04/15/2014 10:37 AM, Petr Pchelko wrote: > Hello, Joe. > > The fix looks good to me. > > With best regards. Petr. > > 10 ???. 2014 ?., ? 6:44 ?? ???????, Joe Darcy ???????(?): > >> Hello, >> >> Please review the changes for >> >> JDK-8039861: Fix fallthrough lint warnings in awt >> http://cr.openjdk.java.net/~darcy/8039861.0/ >> >> Thanks, >> >> -Joe >> >> --- old/src/share/classes/java/awt/dnd/DragSourceContext.java 2014-04-09 19:41:33.000000000 -0700 >> +++ new/src/share/classes/java/awt/dnd/DragSourceContext.java 2014-04-09 19:41:33.000000000 -0700 >> @@ -472,7 +472,7 @@ >> * ENTER, OVER, >> * CHANGED >> */ >> - >> + @SuppressWarnings("fallthrough") >> protected synchronized void updateCurrentCursor(int sourceAct, int targetAct, int status) { >> >> // if the cursor has been previously set then don't do any defaults >> --- old/src/share/classes/sun/awt/image/GifImageDecoder.java 2014-04-09 19:41:33.000000000 -0700 >> +++ new/src/share/classes/sun/awt/image/GifImageDecoder.java 2014-04-09 19:41:33.000000000 -0700 >> @@ -114,6 +114,7 @@ >> /** >> * produce an image from the stream. >> */ >> + @SuppressWarnings("fallthrough") >> public void produceImage() throws IOException, ImageFormatException { >> try { >> readHeader(); >> @@ -238,7 +239,7 @@ >> if (frameno == 0) { >> return; >> } >> - // NOBREAK >> + // Fall through >> >> case TERMINATOR: >> if (nloops == 0 || nloops-- >= 0) { >> --- old/src/share/classes/sun/awt/image/PixelConverter.java 2014-04-09 19:41:34.000000000 -0700 >> +++ new/src/share/classes/sun/awt/image/PixelConverter.java 2014-04-09 19:41:33.000000000 -0700 >> @@ -53,6 +53,7 @@ >> >> protected PixelConverter() {} >> >> + @SuppressWarnings("fallthrough") >> public int rgbToPixel(int rgb, ColorModel cm) { >> Object obj = cm.getDataElements(rgb, null); >> switch (cm.getTransferType()) { >> --- old/src/solaris/classes/sun/awt/X11/XWM.java 2014-04-09 19:41:34.000000000 -0700 >> +++ new/src/solaris/classes/sun/awt/X11/XWM.java 2014-04-09 19:41:34.000000000 -0700 >> @@ -1112,6 +1112,7 @@ >> * Therefore, a compound state is just ICONIFIED | anything else. >> * >> */ >> + @SuppressWarnings("fallthrough") >> boolean supportsExtendedState(int state) { >> switch (state) { >> case Frame.MAXIMIZED_VERT: >> @@ -1131,6 +1132,7 @@ >> return true; >> } >> } >> + /* FALLTROUGH */ >> default: >> return false; >> } >> From petr.pchelko at oracle.com Thu Apr 17 17:36:07 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 17 Apr 2014 21:36:07 +0400 Subject: JDK 9 RFR of JDK-8039861: Fix fallthrough lint warnings in awt In-Reply-To: <53500423.7060807@oracle.com> References: <53460574.2010704@oracle.com> <1781E9F2-5E0E-4DB0-8AE5-08DE1EFF39FC@oracle.com> <53500423.7060807@oracle.com> Message-ID: <98D7F140-38C1-4313-89B5-29CB8EE8BABC@oracle.com> Hello, Joe. The updated part also looks good. With best regards. Petr. On Apr 17, 2014, at 8:41 PM, Joe Darcy wrote: > Hi Petr, > > Thanks for the review. While preparing to push this, I noticed another instance of this situation in XComponentPeer.java: > > --- a/src/solaris/classes/sun/awt/X11/XComponentPeer.java Thu Apr 17 16:26:45 2014 +0400 > +++ b/src/solaris/classes/sun/awt/X11/XComponentPeer.java Thu Apr 17 09:38:13 2014 -0700 > @@ -548,6 +548,7 @@ > } > } > > + @SuppressWarnings("fallthrough") > public void handleEvent(java.awt.AWTEvent e) { > if ((e instanceof InputEvent) && !((InputEvent)e).isConsumed() && target.isEnabled()) { > if (e instanceof MouseEvent) { > > The switch statement in question already has the fallthrough commented > > switch(id) { > case PaintEvent.PAINT: > // Got native painting > paintPending = false; > // Fallthrough to next statement > case PaintEvent.UPDATE: > // Skip all painting while layouting and all UPDATEs > // while waiting for native paint > if (!isLayouting && !paintPending) { > paintArea.paint(target,false); > } > > so I'll add the annotation at the time time. > > Thanks, > > -Joe > > On 04/15/2014 10:37 AM, Petr Pchelko wrote: >> Hello, Joe. >> >> The fix looks good to me. >> >> With best regards. Petr. >> >> 10 ???. 2014 ?., ? 6:44 ?? ???????, Joe Darcy ???????(?): >> >>> Hello, >>> >>> Please review the changes for >>> >>> JDK-8039861: Fix fallthrough lint warnings in awt >>> http://cr.openjdk.java.net/~darcy/8039861.0/ >>> >>> Thanks, >>> >>> -Joe >>> >>> --- old/src/share/classes/java/awt/dnd/DragSourceContext.java 2014-04-09 19:41:33.000000000 -0700 >>> +++ new/src/share/classes/java/awt/dnd/DragSourceContext.java 2014-04-09 19:41:33.000000000 -0700 >>> @@ -472,7 +472,7 @@ >>> * ENTER, OVER, >>> * CHANGED >>> */ >>> - >>> + @SuppressWarnings("fallthrough") >>> protected synchronized void updateCurrentCursor(int sourceAct, int targetAct, int status) { >>> >>> // if the cursor has been previously set then don't do any defaults >>> --- old/src/share/classes/sun/awt/image/GifImageDecoder.java 2014-04-09 19:41:33.000000000 -0700 >>> +++ new/src/share/classes/sun/awt/image/GifImageDecoder.java 2014-04-09 19:41:33.000000000 -0700 >>> @@ -114,6 +114,7 @@ >>> /** >>> * produce an image from the stream. >>> */ >>> + @SuppressWarnings("fallthrough") >>> public void produceImage() throws IOException, ImageFormatException { >>> try { >>> readHeader(); >>> @@ -238,7 +239,7 @@ >>> if (frameno == 0) { >>> return; >>> } >>> - // NOBREAK >>> + // Fall through >>> >>> case TERMINATOR: >>> if (nloops == 0 || nloops-- >= 0) { >>> --- old/src/share/classes/sun/awt/image/PixelConverter.java 2014-04-09 19:41:34.000000000 -0700 >>> +++ new/src/share/classes/sun/awt/image/PixelConverter.java 2014-04-09 19:41:33.000000000 -0700 >>> @@ -53,6 +53,7 @@ >>> >>> protected PixelConverter() {} >>> >>> + @SuppressWarnings("fallthrough") >>> public int rgbToPixel(int rgb, ColorModel cm) { >>> Object obj = cm.getDataElements(rgb, null); >>> switch (cm.getTransferType()) { >>> --- old/src/solaris/classes/sun/awt/X11/XWM.java 2014-04-09 19:41:34.000000000 -0700 >>> +++ new/src/solaris/classes/sun/awt/X11/XWM.java 2014-04-09 19:41:34.000000000 -0700 >>> @@ -1112,6 +1112,7 @@ >>> * Therefore, a compound state is just ICONIFIED | anything else. >>> * >>> */ >>> + @SuppressWarnings("fallthrough") >>> boolean supportsExtendedState(int state) { >>> switch (state) { >>> case Frame.MAXIMIZED_VERT: >>> @@ -1131,6 +1132,7 @@ >>> return true; >>> } >>> } >>> + /* FALLTROUGH */ >>> default: >>> return false; >>> } >>> > From anthony.petrov at oracle.com Thu Apr 17 18:46:07 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 17 Apr 2014 22:46:07 +0400 Subject: [9] Review Request: 8035169 Move ThreadGroupUtils from the sun.misc package In-Reply-To: <53500157.70805@oracle.com> References: <8B3ABD87-268C-41FD-BA35-A81BC4BF1D10@oracle.com> <534FA5CA.6050906@oracle.com> <534FF879.5090804@oracle.com> <53500157.70805@oracle.com> Message-ID: <5350216F.8040009@oracle.com> The fix looks fine to me, too. -- best regards, Anthony On 4/17/2014 8:29 PM, Alexander Zvegintsev wrote: > Still looks good to me. > > -- > Thanks, > Alexander. > > 17.04.2014 19:51, Sergey Bylokhov wrote: >> Hi, Petr. >> The fix looks good. >> >> On 4/17/14 3:34 PM, Petr Pchelko wrote: >>> Hello, Sergey. >>> >>> Thank you for the review. >>> Fixed: http://cr.openjdk.java.net/~pchelko/9/8035169/webrev.01/ >>> >>> With best regards. Petr. >>> >>> On 17.04.2014, at 13:58, Sergey Bylokhov >>> wrote: >>> >>>> Hi, Petr. >>>> Typo from the previous review "could could". >>>> >>>> On 16.04.2014 18:42, Petr Pchelko wrote: >>>>> Hello, AWT Team. >>>>> >>>>> Please review the fix for the issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8035169 >>>>> The fix is available at: >>>>> http://cr.openjdk.java.net/~pchelko/9/8035169/webrev/ >>>>> >>>>> The ThreadGroupUtils class was added to sun.misc, but it's a bad >>>>> practice for modularization. We should move it somewhere to AWT. >>>>> Here I've put it to sun.awt.util. Nothing.s changed except moving the >>>>> class. >>>>> >>>>> With best regards. Petr. >>>> >>>> -- >>>> Best regards, Sergey. >>>> >> >> > From petr.pchelko at oracle.com Fri Apr 18 06:38:41 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 18 Apr 2014 10:38:41 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <534F9D51.7030906@oracle.com> References: <534BB5CA.6020801@oracle.com> <534F9D51.7030906@oracle.com> Message-ID: <7CF00C03-CF76-4067-9C5E-5DC4ED61E28D@oracle.com> Hello, Dmitriy. The fix looks good. With best regards. Petr. On Apr 17, 2014, at 1:22 PM, Dmitriy Ermashov wrote: > Hi, > Please, review the changeset for: > https://bugs.openjdk.java.net/browse/JDK-8039279 > > Webrev is here: > http://cr.openjdk.java.net/~yan/8039279/webrev.03/ > > Changelist: > 1. Removed internal API usage (sun.awt.*) > 2. Removed Asserts library dependency from all tests except of ModifierRobotKeyTest (too much usage of asserts in it). > 3. Improved thread synchronization in ComponentPreferredSize, ChangeGridSize, ModifierRobotKeyTest, LockingKeyStateTest > 4. Added disposing frame at the end of each test. > > Test runs on the following platforms seems stable: > Windows 7 x64, Intel graphical card > Ubuntu Linux 12.04 x64, Intel graphical card > OS X 10.8.5 x64, NVIDIA GeForce 9400 > Ubuntu 10.04 ARMv7 > > --Dima From petr.pchelko at oracle.com Fri Apr 18 07:04:02 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 18 Apr 2014 11:04:02 +0400 Subject: [9] Review Request: 8039567 Duplicated code in DataTransferer In-Reply-To: <534FF6E0.2070504@oracle.com> References: <06D2CA5B-B72A-46D4-A611-08AD640828B2@oracle.com> <53455FF7.7070901@oracle.com> <534FF6E0.2070504@oracle.com> Message-ID: Hello, Could you please review the updated version: http://cr.openjdk.java.net/~pchelko/9/8039567/webrev.01/ Splited the long line. Previously I didn?t add a couple of files into the webrev. Adding them now. With best regards. Petr. On Apr 17, 2014, at 7:44 PM, Sergey Bylokhov wrote: > Hi, Petr. > The fix looks good. But can you split the long lines in the DataTransferer.java, it seems it has right margin = 80. > On 4/17/14 1:00 PM, Petr Pchelko wrote: >> Hello, >> >> Could I get a second review on this. >> >> With best regards. Petr. >> >> On 09.04.2014, at 18:57, Alexander Zvegintsev wrote: >> >>> Hi Petr, >>> >>> the fix looks good to me. >>> >>> Thanks, >>> >>> Alexander. >>> >>> On 04/09/2014 06:27 PM, Petr Pchelko wrote: >>>> Hello AWT team. >>>> >>>> Please review a simple cleanup fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8039567 >>>> The fix is available here: >>>> http://cr.openjdk.java.net/~pchelko/9/8039567/webrev/ >>>> >>>> 1. The getBestCharsetForTextFormat is duplicated 3 times in the code. >>>> 2. Caching of the default Charset in DataTransferer does not make sense as it's already cached in the Charset class itself. >>>> Adding more references to the nio.Charset is not a problem since it's used in this class anyway and we cannot break this >>>> dependency. >>>> >>>> With best regards. Petr. > > > -- > Best regards, Sergey. > From alexey.ivanov at oracle.com Fri Apr 18 08:09:32 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 18 Apr 2014 12:09:32 +0400 Subject: [9] Review request for JDK-8039383: NPE when changing Windows Theme Message-ID: <5350DDBC.30603@oracle.com> Hello Swing and AWT teams, Could you please review the fix for jdk9: bug: https://bugs.openjdk.java.net/browse/JDK-8039383 webrev: http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.00/ Problem description: When changing Windows themes from a theme with visual styles (Windows Aero or Windows Basic) to a classic one, NullPointerException could be thrown from Swing code during component tree validation, or InternalError could be thrown during component painting. Root cause: Windows theme data are "cached" in XPStyle object. When the theme is switched to a classic one, HTHEME handle becomes unavailable and data cannot be accessed from the theme any more. The change in theme in posted to EDT via invokeLater. At the same time, the UI needs to repaint itself as soon as Windows changed the theme, and paint code is often called before the theme change is handled in Java. This leads to NPE and InternalError as the code tries to access the data that has become unavailable. The fix: Update "win.xpstyle.themeActive" desktop property and invalidate the cached XPStyle as soon as windowsSettingChange() is called from native code. Thus when Swing code needs to access theme data, it will see no theme is available and will fallback to classic painting. Note: Before the fix, PropertyChangeEvents for desktop properties in Windows were fired on the Event Dispatch Thread. With this change, property "win.xpstyle.themeActive" change is fired on the toolkit thread; all other properties are changed on the EDT as before. Regards, Alexey. From Sergey.Bylokhov at oracle.com Fri Apr 18 11:48:27 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 18 Apr 2014 15:48:27 +0400 Subject: [9] Review Request: 8026252 [macosx] Change AWT_DEBUG_BUG_REPORT_MESSAGE for macosx platform Message-ID: <5351110B.50806@oracle.com> Hello. Please review the fix for jdk 9. The link was changed from http://java.net/jira/browse/MACOSX_PORT to http://bugreport.java.com/bugreport Also additional "\t" was added to "Cocoa AWT:" to properly align it with all other messages. Bug: https://bugs.openjdk.java.net/browse/JDK-8026252 Webrev can be found at: http://cr.openjdk.java.net/~serb/8026252/webrev.00 -- Best regards, Sergey. From anthony.petrov at oracle.com Fri Apr 18 12:02:04 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 18 Apr 2014 16:02:04 +0400 Subject: [9] Review request for JDK-8039383: NPE when changing Windows Theme In-Reply-To: <5350DDBC.30603@oracle.com> References: <5350DDBC.30603@oracle.com> Message-ID: <5351143C.8010100@oracle.com> Hi Alexey, > With this change, property "win.xpstyle.themeActive" change is fired on the toolkit thread Is it possible to install a change listener for this property from user code, and hence eventually allow executing some user code on the toolkit thread with your fix? -- best regards, Anthony On 4/18/2014 12:09 PM, Alexey Ivanov wrote: > Hello Swing and AWT teams, > > Could you please review the fix for jdk9: > bug: https://bugs.openjdk.java.net/browse/JDK-8039383 > webrev: http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.00/ > > Problem description: > When changing Windows themes from a theme with visual styles (Windows > Aero or Windows Basic) to a classic one, NullPointerException could be > thrown from Swing code during component tree validation, or > InternalError could be thrown during component painting. > > Root cause: > Windows theme data are "cached" in XPStyle object. When the theme is > switched to a classic one, HTHEME handle becomes unavailable and data > cannot be accessed from the theme any more. The change in theme in > posted to EDT via invokeLater. At the same time, the UI needs to repaint > itself as soon as Windows changed the theme, and paint code is often > called before the theme change is handled in Java. This leads to NPE and > InternalError as the code tries to access the data that has become > unavailable. > > The fix: > Update "win.xpstyle.themeActive" desktop property and invalidate the > cached XPStyle as soon as windowsSettingChange() is called from native > code. Thus when Swing code needs to access theme data, it will see no > theme is available and will fallback to classic painting. > > Note: Before the fix, PropertyChangeEvents for desktop properties in > Windows were fired on the Event Dispatch Thread. With this change, > property "win.xpstyle.themeActive" change is fired on the toolkit > thread; all other properties are changed on the EDT as before. > > > Regards, > Alexey. From petr.pchelko at oracle.com Fri Apr 18 12:17:56 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 18 Apr 2014 16:17:56 +0400 Subject: [9] Review Request: 8026252 [macosx] Change AWT_DEBUG_BUG_REPORT_MESSAGE for macosx platform In-Reply-To: <5351110B.50806@oracle.com> References: <5351110B.50806@oracle.com> Message-ID: Hello, Sergey. The fix looks good. Could you split the long line with \ ?) No new webrev needed. Thank you. With best regards. Petr. On Apr 18, 2014, at 3:48 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > The link was changed from http://java.net/jira/browse/MACOSX_PORT to http://bugreport.java.com/bugreport > Also additional "\t" was added to "Cocoa AWT:" to properly align it with all other messages. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026252 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8026252/webrev.00 > > -- > Best regards, Sergey. > From alexander.zvegintsev at oracle.com Fri Apr 18 12:38:42 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 18 Apr 2014 16:38:42 +0400 Subject: [9] Review Request: 8039567 Duplicated code in DataTransferer In-Reply-To: References: <06D2CA5B-B72A-46D4-A611-08AD640828B2@oracle.com> <53455FF7.7070901@oracle.com> <534FF6E0.2070504@oracle.com> Message-ID: <53511CD2.8050808@oracle.com> Hello Petr, the fix looks good to me. -- Thanks, Alexander. On 04/18/2014 11:04 AM, Petr Pchelko wrote: > Hello, > > Could you please review the updated version: > http://cr.openjdk.java.net/~pchelko/9/8039567/webrev.01/ > > Splited the long line. > Previously I didn?t add a couple of files into the webrev. Adding them now. > > With best regards. Petr. > > On Apr 17, 2014, at 7:44 PM, Sergey Bylokhov wrote: > >> Hi, Petr. >> The fix looks good. But can you split the long lines in the DataTransferer.java, it seems it has right margin = 80. >> On 4/17/14 1:00 PM, Petr Pchelko wrote: >>> Hello, >>> >>> Could I get a second review on this. >>> >>> With best regards. Petr. >>> >>> On 09.04.2014, at 18:57, Alexander Zvegintsev wrote: >>> >>>> Hi Petr, >>>> >>>> the fix looks good to me. >>>> >>>> Thanks, >>>> >>>> Alexander. >>>> >>>> On 04/09/2014 06:27 PM, Petr Pchelko wrote: >>>>> Hello AWT team. >>>>> >>>>> Please review a simple cleanup fix for the issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8039567 >>>>> The fix is available here: >>>>> http://cr.openjdk.java.net/~pchelko/9/8039567/webrev/ >>>>> >>>>> 1. The getBestCharsetForTextFormat is duplicated 3 times in the code. >>>>> 2. Caching of the default Charset in DataTransferer does not make sense as it's already cached in the Charset class itself. >>>>> Adding more references to the nio.Charset is not a problem since it's used in this class anyway and we cannot break this >>>>> dependency. >>>>> >>>>> With best regards. Petr. >> >> -- >> Best regards, Sergey. >> From alexander.zvegintsev at oracle.com Fri Apr 18 12:40:58 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 18 Apr 2014 16:40:58 +0400 Subject: [9] Review Request: 8026252 [macosx] Change AWT_DEBUG_BUG_REPORT_MESSAGE for macosx platform In-Reply-To: <5351110B.50806@oracle.com> References: <5351110B.50806@oracle.com> Message-ID: <53511D5A.5040105@oracle.com> Hello Sergey, the fix looks good to me. -- Thanks, Alexander. On 04/18/2014 03:48 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > The link was changed from http://java.net/jira/browse/MACOSX_PORT to > http://bugreport.java.com/bugreport > Also additional "\t" was added to "Cocoa AWT:" to properly align it > with all other messages. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026252 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8026252/webrev.00 > From petr.pchelko at oracle.com Fri Apr 18 13:49:32 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 18 Apr 2014 17:49:32 +0400 Subject: [9] Review Request: 8027148 SystemFlavorMap.getNativesForFlavor returns list of native formats in incorrect order Message-ID: <0008EDB8-C0C6-447B-B4A6-EEFF3B94CB99@oracle.com> Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8027148 The fix is available at: http://cr.openjdk.java.net/~pchelko/9/8027148/webrev/ Sorry for the long text, but it?s quite tangled) The problem: The flavor map contains some predefined mappings which are stored in the flavormap.properties file. But we can extend these mappings using addUnencodedNativeForFlavor method. Javadoc states, that these new mappings would have lower priority that standard mappings. But in the current implementation this was not the case, because getNativesForFlavor method relied on the fact, that standard text mappings were stored as FlavorBaseType<->Native and newly added mappings were stored as DataFlavor<->Native, but after some fix in Java 8 this is not the case any more. Everything is stored as a DataFlavor as a key. This is important only for text flavors, because we support different text charsets and can reencode the text on the fly. So each native text format could be represented in many different DataFlavors with different encodings and representation classes. When we generate the set of DataFlavor?s that a text native can be translated to we no longer know how to distinguish the standard mappings and additional mappings and the get shuffled when we generate missing mappings for text formats. The solution: I?ve added an additional map for standard text mappings. With this map we can now take natives for mime types directly and not "find all flavors for a mime-type and than all natives for each flavor". This is not only faster, but we can distinguish standard text mappings from custom and return the list in the correct order. The new hash map contains only a few elements. Also I?ve replaced the ArrayList as a collection of natives for a particular Flavor with a LinkedHashSet, because this list could not contain duplicated which we were enforcing ourselves. Now it works out of the box and some code can be removed. I?ve measured the performance of a couple of most hot methods and on average the new implementation is 1.7 times faster. The test is being open sources. I?ve tested this with JCK and our regression tests, everything looks good. Also I?ve tested with a couple of hand-made toys. Thank you. With best regards. Petr. From oleg.pekhovskiy at oracle.com Fri Apr 18 14:13:54 2014 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 18 Apr 2014 18:13:54 +0400 Subject: [9] Review request for 8014754: [TEST_BUG] child.exe remains after execution java/awt/dnd/ Win32TYMEDSelectionTest and Win32DropTYMEDSelectionTest Message-ID: <53513322.5000002@oracle.com> Hi all, please review the fix http://cr.openjdk.java.net/~bagiras/9/8014754.1/ for https://bugs.openjdk.java.net/browse/JDK-8014754 Start of 'child.exe' has no timeout, that's why if dragging fails the executable keeps running and prevents temporary folder from being cleared. So I forcibly terminate the process if it was not exited after dnd action (lines 74-76 in Win32TYMEDSelectionTest.java) PS: Webrev doesn't include child.exe but it's also moved with the others from the closed repository. Thanks, Oleg From anthony.petrov at oracle.com Fri Apr 18 14:18:48 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 18 Apr 2014 18:18:48 +0400 Subject: [9] Review request for 8014754: [TEST_BUG] child.exe remains after execution java/awt/dnd/ Win32TYMEDSelectionTest and Win32DropTYMEDSelectionTest In-Reply-To: <53513322.5000002@oracle.com> References: <53513322.5000002@oracle.com> Message-ID: <53513448.8030400@oracle.com> Hi Oleg, We don't want to add binary files to the open repository. If you can only add the source code to it and make it compile itself upon test execution, then it is fine. But the .exe file itself should not be pushed to the repo. -- best regards, Anthony On 4/18/2014 6:13 PM, Oleg Pekhovskiy wrote: > Hi all, > > please review the fix > http://cr.openjdk.java.net/~bagiras/9/8014754.1/ > for > https://bugs.openjdk.java.net/browse/JDK-8014754 > > Start of 'child.exe' has no timeout, that's why if dragging fails the > executable keeps running and prevents temporary folder from being cleared. > So I forcibly terminate the process if it was not exited after dnd > action (lines 74-76 in Win32TYMEDSelectionTest.java) > > PS: Webrev doesn't include child.exe but it's also moved with the others > from the closed repository. > > Thanks, > Oleg From alexey.ivanov at oracle.com Fri Apr 18 14:48:59 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 18 Apr 2014 18:48:59 +0400 Subject: [9] Review request for JDK-8039383: NPE when changing Windows Theme In-Reply-To: <5351143C.8010100@oracle.com> References: <5350DDBC.30603@oracle.com> <5351143C.8010100@oracle.com> Message-ID: <53513B5B.4050104@oracle.com> Hi Anthony, Thank you for your review. Yes, user code can install a property change listener... It was my concern too, that's why I explicitly noted about this. Do you have any suggestion how this situation can be handled? Is it a general rule that all desktop property change listeners must be called on EDT? Thanks, Alexey. On 18.04.2014 16:02, Anthony Petrov wrote: > Hi Alexey, > >> With this change, property "win.xpstyle.themeActive" change is fired >> on the toolkit thread > > Is it possible to install a change listener for this property from > user code, and hence eventually allow executing some user code on the > toolkit thread with your fix? > > -- > best regards, > Anthony > > On 4/18/2014 12:09 PM, Alexey Ivanov wrote: >> Hello Swing and AWT teams, >> >> Could you please review the fix for jdk9: >> bug: https://bugs.openjdk.java.net/browse/JDK-8039383 >> webrev: http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.00/ >> >> Problem description: >> When changing Windows themes from a theme with visual styles (Windows >> Aero or Windows Basic) to a classic one, NullPointerException could be >> thrown from Swing code during component tree validation, or >> InternalError could be thrown during component painting. >> >> Root cause: >> Windows theme data are "cached" in XPStyle object. When the theme is >> switched to a classic one, HTHEME handle becomes unavailable and data >> cannot be accessed from the theme any more. The change in theme in >> posted to EDT via invokeLater. At the same time, the UI needs to repaint >> itself as soon as Windows changed the theme, and paint code is often >> called before the theme change is handled in Java. This leads to NPE and >> InternalError as the code tries to access the data that has become >> unavailable. >> >> The fix: >> Update "win.xpstyle.themeActive" desktop property and invalidate the >> cached XPStyle as soon as windowsSettingChange() is called from native >> code. Thus when Swing code needs to access theme data, it will see no >> theme is available and will fallback to classic painting. >> >> Note: Before the fix, PropertyChangeEvents for desktop properties in >> Windows were fired on the Event Dispatch Thread. With this change, >> property "win.xpstyle.themeActive" change is fired on the toolkit >> thread; all other properties are changed on the EDT as before. >> >> >> Regards, >> Alexey. From anthony.petrov at oracle.com Fri Apr 18 14:52:22 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 18 Apr 2014 18:52:22 +0400 Subject: [9] Review request for JDK-8039383: NPE when changing Windows Theme In-Reply-To: <53513B5B.4050104@oracle.com> References: <5350DDBC.30603@oracle.com> <5351143C.8010100@oracle.com> <53513B5B.4050104@oracle.com> Message-ID: <53513C26.9060305@oracle.com> Hi Alexey, No, unfortunately I don't have any suggestions right now. As for allowing executing user code on the toolkit thread, we can't accept such a fix. Sorry about that. -- best regards, Anthony On 4/18/2014 6:48 PM, Alexey Ivanov wrote: > Hi Anthony, > > Thank you for your review. > > Yes, user code can install a property change listener... It was my > concern too, that's why I explicitly noted about this. > > Do you have any suggestion how this situation can be handled? > Is it a general rule that all desktop property change listeners must be > called on EDT? > > > Thanks, > Alexey. > > On 18.04.2014 16:02, Anthony Petrov wrote: >> Hi Alexey, >> >>> With this change, property "win.xpstyle.themeActive" change is fired >>> on the toolkit thread >> >> Is it possible to install a change listener for this property from >> user code, and hence eventually allow executing some user code on the >> toolkit thread with your fix? >> >> -- >> best regards, >> Anthony >> >> On 4/18/2014 12:09 PM, Alexey Ivanov wrote: >>> Hello Swing and AWT teams, >>> >>> Could you please review the fix for jdk9: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8039383 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.00/ >>> >>> Problem description: >>> When changing Windows themes from a theme with visual styles (Windows >>> Aero or Windows Basic) to a classic one, NullPointerException could be >>> thrown from Swing code during component tree validation, or >>> InternalError could be thrown during component painting. >>> >>> Root cause: >>> Windows theme data are "cached" in XPStyle object. When the theme is >>> switched to a classic one, HTHEME handle becomes unavailable and data >>> cannot be accessed from the theme any more. The change in theme in >>> posted to EDT via invokeLater. At the same time, the UI needs to repaint >>> itself as soon as Windows changed the theme, and paint code is often >>> called before the theme change is handled in Java. This leads to NPE and >>> InternalError as the code tries to access the data that has become >>> unavailable. >>> >>> The fix: >>> Update "win.xpstyle.themeActive" desktop property and invalidate the >>> cached XPStyle as soon as windowsSettingChange() is called from native >>> code. Thus when Swing code needs to access theme data, it will see no >>> theme is available and will fallback to classic painting. >>> >>> Note: Before the fix, PropertyChangeEvents for desktop properties in >>> Windows were fired on the Event Dispatch Thread. With this change, >>> property "win.xpstyle.themeActive" change is fired on the toolkit >>> thread; all other properties are changed on the EDT as before. >>> >>> >>> Regards, >>> Alexey. > From henry.jen at oracle.com Fri Apr 18 18:56:30 2014 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 18 Apr 2014 11:56:30 -0700 Subject: [OpenJDK 2D-Dev] JDK9: RFR: 8039342: Fix raw and unchecked warnings in sun.awt.* In-Reply-To: <5345CA3D.5000008@oracle.com> References: <53430EAB.3090504@oracle.com> <5343312E.4060207@oracle.com> <534348E7.6010207@oracle.com> <5345BD2C.2020104@oracle.com> <5345CA3D.5000008@oracle.com> Message-ID: <5351755E.1020803@oracle.com> Ping. The webrev is updated(rebase) to latest jdk9/client repo, http://cr.openjdk.java.net/~henryjen/jdk9/8039342/1/webrev/ I also run Java2Demo with the result build and it seems fine. Cheers, Henry On 04/09/2014 03:31 PM, Henry Jen wrote: > On 04/09/2014 02:35 PM, Phil Race wrote: >> >> It seems fine except that >> 1. How are you testing all these changes ? >> > > I ran jtreg on test/sun/awt and test/java/awt(which contains quite a few > manual test that I simply click pass without verifying based on > instruction). > > Also jprt. > >> 2. The changes in sun/awt/geom need closer examination and I would really >> like Jim to weigh in on those .. >> > > Would certainly appreciate that. > > Cheers, > Henry From oleg.pekhovskiy at oracle.com Sat Apr 19 07:41:44 2014 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Sat, 19 Apr 2014 11:41:44 +0400 Subject: [9] Review request for 8014754: [TEST_BUG] child.exe remains after execution java/awt/dnd/ Win32TYMEDSelectionTest and Win32DropTYMEDSelectionTest In-Reply-To: <53513448.8030400@oracle.com> References: <53513322.5000002@oracle.com> <53513448.8030400@oracle.com> Message-ID: <535228B8.1000002@oracle.com> Hi Anthony, thank you for pointing that out. Please review the new version of fix that meets mentioned requirements: http://cr.openjdk.java.net/~bagiras/9/8014754.2 Thanks, Oleg On 18.04.2014 18:18, Anthony Petrov wrote: > Hi Oleg, > > We don't want to add binary files to the open repository. If you can > only add the source code to it and make it compile itself upon test > execution, then it is fine. But the .exe file itself should not be > pushed to the repo. > > -- > best regards, > Anthony > > On 4/18/2014 6:13 PM, Oleg Pekhovskiy wrote: >> Hi all, >> >> please review the fix >> http://cr.openjdk.java.net/~bagiras/9/8014754.1/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8014754 >> >> Start of 'child.exe' has no timeout, that's why if dragging fails the >> executable keeps running and prevents temporary folder from being >> cleared. >> So I forcibly terminate the process if it was not exited after dnd >> action (lines 74-76 in Win32TYMEDSelectionTest.java) >> >> PS: Webrev doesn't include child.exe but it's also moved with the others >> from the closed repository. >> >> Thanks, >> Oleg From alexandr.scherbatiy at oracle.com Mon Apr 21 10:06:46 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 21 Apr 2014 14:06:46 +0400 Subject: Review request for JDK-8039279: Move first batch of functional tests to openjdk repository In-Reply-To: <534F9D51.7030906@oracle.com> References: <534BB5CA.6020801@oracle.com> <534F9D51.7030906@oracle.com> Message-ID: <5354EDB6.1000109@oracle.com> The fix looks good for me. If it is unlikely to use sun.awt.* classes to check the OS version, may be it would be better to add the OS version check method to the ExtendedRobot? Thanks, Alexandr. On 4/17/2014 1:22 PM, Dmitriy Ermashov wrote: > Hi, > Please, review the changeset for: > https://bugs.openjdk.java.net/browse/JDK-8039279 > > Webrev is here: > http://cr.openjdk.java.net/~yan/8039279/webrev.03/ > > Changelist: > 1. Removed internal API usage (sun.awt.*) > 2. Removed Asserts library dependency from all tests except of > ModifierRobotKeyTest (too much usage of asserts in it). > 3. Improved thread synchronization in ComponentPreferredSize, > ChangeGridSize, ModifierRobotKeyTest, LockingKeyStateTest > 4. Added disposing frame at the end of each test. > > Test runs on the following platforms seems stable: > Windows 7 x64, Intel graphical card > Ubuntu Linux 12.04 x64, Intel graphical card > OS X 10.8.5 x64, NVIDIA GeForce 9400 > Ubuntu 10.04 ARMv7 > > --Dima From petr.pchelko at oracle.com Mon Apr 21 10:36:00 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 21 Apr 2014 14:36:00 +0400 Subject: [9] Review request for 8040279 [macosx] Do not use the base image in the MultiResolutionBufferedImage constructor In-Reply-To: <534D43D0.2010808@oracle.com> References: <534D43D0.2010808@oracle.com> Message-ID: Hello, Alexander. Just one minor comment: In CImage createBufferedImage method does not create a BufferredImage any more, so it worths renaming. With best regards. Petr. On 15.04.2014, at 18:36, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8040279 > webrev: http://cr.openjdk.java.net/~alexsch/8040279/webrev.00 > > MultiResolutionBufferedImage extends BufferedImage. In this case it needs to use the base image to write it to the BufferedImage. > > The fix renames MultiResolutionBufferedImage to MultiResolutionCahcedImage and does not use the BufferedImage as the super class. > The base image is created and cached by demand. > > CImage now always returns MultiResolutionCahcedImage. All requested resolution variants are scaled by NSImage. > > Thanks, > Alexandr. > From alexey.ivanov at oracle.com Mon Apr 21 10:57:34 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 21 Apr 2014 14:57:34 +0400 Subject: [9] Review Request for JDK-8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: <534FF1B2.2080700@oracle.com> References: <534653BF.8090104@oracle.com> <53469F14.4000507@oracle.com> <534D11C5.2090901@oracle.com> <44CF8F6F-DA12-44C8-906A-8CBAC73979E9@oracle.com> <534FF1B2.2080700@oracle.com> Message-ID: <5354F99E.1060103@oracle.com> Hi Sergey, Thank you for your review. Regards, Alexey. On 17.04.2014 19:22, Sergey Bylokhov wrote: > Hi, Alexey. > The fix looks good. > > On 4/15/14 3:13 PM, Petr Pchelko wrote: >> Hello, Alexey. >> >> I?m fine with your fix. >> >> Thank you for filing a new bug for JDK 9. >> >> With best regards. Petr. >> >> 15 ???. 2014 ?., ? 3:02 ????? ???????, Alexey Ivanov >> ???????(?): >> >>> Hi Petr, >>> >>> Please look at the updated webrev with comment explaining why >>> additional 'if' clause is added: >>> http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.01/ >>> >>> I have submitted a new bug JDK-8040248: >>> "Drag and drop between two components fails if performed quickly" >>> https://bugs.openjdk.java.net/browse/JDK-8040248 >>> >>> Regards, >>> Alexey. >>> >>> On 10.04.2014 18:31, Petr Pchelko wrote: >>>> Hello, Alexey. >>>> >>>> Thank you for the clarification. >>>> >>>>> What actually happens is that native drag-and-drop operation >>>>> completed already whereas this drag-and-drop operation on EDT >>>>> didn't even started yet. Does throwing >>>>> InvalidDnDOperationException look more appropriate than returning >>>>> null in this case? >>>> No, I think it?s not good. As a workaround it?s better to not >>>> return the data than to throw an exception. It would be really hard >>>> for the users to deal with such an exception. >>>> >>>> Please add some comment to the if clause to clarify what?s happening. >>>> Otherwise the fix looks good to me. >>>> >>>> With best regards. Petr. >>>> >>>> 10 ???. 2014 ?., ? 5:39 ????? ???????, Alexey Ivanov >>>> ???????(?): >>>> >>>>> Hi Petr, >>>>> >>>>> If the requested data flavor is >>>>> DataFlavor.javaJVMLocalObjectMimeType, then transferable is local >>>>> to the JVM. It is stored to a static variable in >>>>> SunDropTargetContextPeer.setCurrentJVMLocalSourceTransferable(). >>>>> When processEnterMessage() is handled, its value is copied to >>>>> instance variable "local". The instance variable is cleaned by >>>>> processExitMessage(), the static variable is cleared by >>>>> SunDragSourceContextPeer.cleanup(). >>>>> >>>>> If drag-and-drop operation is performed quickly, >>>>> SunDragSourceContextPeer.cleanup() is called when mouse button is >>>>> released and *before* processEnterMessage() is called. So when EDT >>>>> finally handles MOUSE_ENTERED event and >>>>> DropTargetListener.dragEnter() gets called, "local" transferable >>>>> is already null. The listener tries to get the data from the >>>>> transferable: >>>>> DropTargetDragEvent.getTransferable(), and then >>>>> Transferable.getTransferData(dataFlavor). >>>>> >>>>> The dataFlavor has MIME type of >>>>> DataFlavor.javaJVMLocalObjectMimeType, and >>>>> SunDropTargetContextPeer.currentJVMLocalSourceTransferable is >>>>> already cleared. The representationClass field of the DataFlavor >>>>> object is set to java.io.InputStream.class. So when >>>>> SunDropTargetContextPeer.getNativeData() executes it tries to cast >>>>> the data object to java.io.InputStream to deserialize the data but >>>>> fails with the exception: >>>>> java.lang.ClassCastException: DnD$DropObject cannot be cast to >>>>> java.io.InputStream. >>>>> >>>>> This exception is caught internally, and IOException is thrown as >>>>> it failed to get the data. At the same time, no IO should have >>>>> occurred because a local source was dragged, so this exception is >>>>> rather unexpected. >>>>> >>>>> >>>>> What actually happens is that native drag-and-drop operation >>>>> completed already whereas this drag-and-drop operation on EDT >>>>> didn't even started yet. Does throwing >>>>> InvalidDnDOperationException look more appropriate than returning >>>>> null in this case? >>>>> >>>>> >>>>> Sure, I'll submit a new bug for 9 to implement the proper fix. >>>>> >>>>> >>>>> Regards, >>>>> Alexey. >>>>> >>>>> On 10.04.2014 12:52, Petr Pchelko wrote: >>>>>> Hello, Dmitry. >>>>>> >>>>>> Thank you for the detailed explanation of the issue. >>>>>> >>>>>> I?m OK with this workaround as this should be back ported to 8u >>>>>> and 7u, but I think we could try to provide a real fix in 9. >>>>>> Could you please add some comment which shortly explains why the >>>>>> if clause was added? >>>>>> And could you also file a new bug for 9 so that we try to replace >>>>>> the workaround with a real fix? >>>>>> >>>>>> Thank you. >>>>>> With best regards. Petr. >>>>>> >>>>>> 10 ???. 2014 ?., ? 12:18 ????? ???????, Alexey Ivanov >>>>>> ???????(?): >>>>>> >>>>>>> Hello AWT team, >>>>>>> >>>>>>> Could you please review the fix for jdk9: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8024061 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.00/ >>>>>>> >>>>>>> Problem description: >>>>>>> Dragging and dropping an object from one panel to another very >>>>>>> quickly causes an exception. >>>>>>> >>>>>>> Fix: >>>>>>> The fix addresses only the thrown exception. >>>>>>> The dragged object would not be moved. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Alexey. > > From alexey.ivanov at oracle.com Mon Apr 21 10:58:48 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 21 Apr 2014 14:58:48 +0400 Subject: [9] Review Request for JDK-8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: <44CF8F6F-DA12-44C8-906A-8CBAC73979E9@oracle.com> References: <534653BF.8090104@oracle.com> <53469F14.4000507@oracle.com> <534D11C5.2090901@oracle.com> <44CF8F6F-DA12-44C8-906A-8CBAC73979E9@oracle.com> Message-ID: <5354F9E8.1070003@oracle.com> Hi Petr, Thank you for your review. Regards, Alexey. On 15.04.2014 15:13, Petr Pchelko wrote: > Hello, Alexey. > > I?m fine with your fix. > > Thank you for filing a new bug for JDK 9. > > With best regards. Petr. > > 15 ???. 2014 ?., ? 3:02 ????? ???????, Alexey Ivanov ???????(?): > >> Hi Petr, >> >> Please look at the updated webrev with comment explaining why additional 'if' clause is added: >> http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.01/ >> >> I have submitted a new bug JDK-8040248: >> "Drag and drop between two components fails if performed quickly" >> https://bugs.openjdk.java.net/browse/JDK-8040248 >> >> Regards, >> Alexey. >> >> On 10.04.2014 18:31, Petr Pchelko wrote: >>> Hello, Alexey. >>> >>> Thank you for the clarification. >>> >>>> What actually happens is that native drag-and-drop operation completed already whereas this drag-and-drop operation on EDT didn't even started yet. Does throwing InvalidDnDOperationException look more appropriate than returning null in this case? >>> No, I think it?s not good. As a workaround it?s better to not return the data than to throw an exception. It would be really hard for the users to deal with such an exception. >>> >>> Please add some comment to the if clause to clarify what?s happening. >>> Otherwise the fix looks good to me. >>> >>> With best regards. Petr. >>> >>> 10 ???. 2014 ?., ? 5:39 ????? ???????, Alexey Ivanov ???????(?): >>> >>>> Hi Petr, >>>> >>>> If the requested data flavor is DataFlavor.javaJVMLocalObjectMimeType, then transferable is local to the JVM. It is stored to a static variable in SunDropTargetContextPeer.setCurrentJVMLocalSourceTransferable(). When processEnterMessage() is handled, its value is copied to instance variable "local". The instance variable is cleaned by processExitMessage(), the static variable is cleared by SunDragSourceContextPeer.cleanup(). >>>> >>>> If drag-and-drop operation is performed quickly, SunDragSourceContextPeer.cleanup() is called when mouse button is released and *before* processEnterMessage() is called. So when EDT finally handles MOUSE_ENTERED event and DropTargetListener.dragEnter() gets called, "local" transferable is already null. The listener tries to get the data from the transferable: >>>> DropTargetDragEvent.getTransferable(), and then >>>> Transferable.getTransferData(dataFlavor). >>>> >>>> The dataFlavor has MIME type of DataFlavor.javaJVMLocalObjectMimeType, and SunDropTargetContextPeer.currentJVMLocalSourceTransferable is already cleared. The representationClass field of the DataFlavor object is set to java.io.InputStream.class. So when SunDropTargetContextPeer.getNativeData() executes it tries to cast the data object to java.io.InputStream to deserialize the data but fails with the exception: >>>> java.lang.ClassCastException: DnD$DropObject cannot be cast to java.io.InputStream. >>>> >>>> This exception is caught internally, and IOException is thrown as it failed to get the data. At the same time, no IO should have occurred because a local source was dragged, so this exception is rather unexpected. >>>> >>>> >>>> What actually happens is that native drag-and-drop operation completed already whereas this drag-and-drop operation on EDT didn't even started yet. Does throwing InvalidDnDOperationException look more appropriate than returning null in this case? >>>> >>>> >>>> Sure, I'll submit a new bug for 9 to implement the proper fix. >>>> >>>> >>>> Regards, >>>> Alexey. >>>> >>>> On 10.04.2014 12:52, Petr Pchelko wrote: >>>>> Hello, Dmitry. >>>>> >>>>> Thank you for the detailed explanation of the issue. >>>>> >>>>> I?m OK with this workaround as this should be back ported to 8u and 7u, but I think we could try to provide a real fix in 9. >>>>> Could you please add some comment which shortly explains why the if clause was added? >>>>> And could you also file a new bug for 9 so that we try to replace the workaround with a real fix? >>>>> >>>>> Thank you. >>>>> With best regards. Petr. >>>>> >>>>> 10 ???. 2014 ?., ? 12:18 ????? ???????, Alexey Ivanov ???????(?): >>>>> >>>>>> Hello AWT team, >>>>>> >>>>>> Could you please review the fix for jdk9: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8024061 >>>>>> webrev: http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.00/ >>>>>> >>>>>> Problem description: >>>>>> Dragging and dropping an object from one panel to another very quickly causes an exception. >>>>>> >>>>>> Fix: >>>>>> The fix addresses only the thrown exception. >>>>>> The dragged object would not be moved. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Alexey. From alexey.ivanov at oracle.com Mon Apr 21 11:00:22 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 21 Apr 2014 15:00:22 +0400 Subject: [9] Review request for JDK-8039383: NPE when changing Windows Theme In-Reply-To: <53513C26.9060305@oracle.com> References: <5350DDBC.30603@oracle.com> <5351143C.8010100@oracle.com> <53513B5B.4050104@oracle.com> <53513C26.9060305@oracle.com> Message-ID: <5354FA46.9020709@oracle.com> Hi Anthony, Thank you for your review and your concern. I'll try another solution. Regards, Alexey. On 18.04.2014 18:52, Anthony Petrov wrote: > Hi Alexey, > > No, unfortunately I don't have any suggestions right now. > > As for allowing executing user code on the toolkit thread, we can't > accept such a fix. Sorry about that. > > -- > best regards, > Anthony > > On 4/18/2014 6:48 PM, Alexey Ivanov wrote: >> Hi Anthony, >> >> Thank you for your review. >> >> Yes, user code can install a property change listener... It was my >> concern too, that's why I explicitly noted about this. >> >> Do you have any suggestion how this situation can be handled? >> Is it a general rule that all desktop property change listeners must be >> called on EDT? >> >> >> Thanks, >> Alexey. >> >> On 18.04.2014 16:02, Anthony Petrov wrote: >>> Hi Alexey, >>> >>>> With this change, property "win.xpstyle.themeActive" change is fired >>>> on the toolkit thread >>> >>> Is it possible to install a change listener for this property from >>> user code, and hence eventually allow executing some user code on the >>> toolkit thread with your fix? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote: >>>> Hello Swing and AWT teams, >>>> >>>> Could you please review the fix for jdk9: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039383 >>>> webrev: >>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.00/ >>>> >>>> Problem description: >>>> When changing Windows themes from a theme with visual styles (Windows >>>> Aero or Windows Basic) to a classic one, NullPointerException could be >>>> thrown from Swing code during component tree validation, or >>>> InternalError could be thrown during component painting. >>>> >>>> Root cause: >>>> Windows theme data are "cached" in XPStyle object. When the theme is >>>> switched to a classic one, HTHEME handle becomes unavailable and data >>>> cannot be accessed from the theme any more. The change in theme in >>>> posted to EDT via invokeLater. At the same time, the UI needs to >>>> repaint >>>> itself as soon as Windows changed the theme, and paint code is often >>>> called before the theme change is handled in Java. This leads to >>>> NPE and >>>> InternalError as the code tries to access the data that has become >>>> unavailable. >>>> >>>> The fix: >>>> Update "win.xpstyle.themeActive" desktop property and invalidate the >>>> cached XPStyle as soon as windowsSettingChange() is called from native >>>> code. Thus when Swing code needs to access theme data, it will see no >>>> theme is available and will fallback to classic painting. >>>> >>>> Note: Before the fix, PropertyChangeEvents for desktop properties in >>>> Windows were fired on the Event Dispatch Thread. With this change, >>>> property "win.xpstyle.themeActive" change is fired on the toolkit >>>> thread; all other properties are changed on the EDT as before. >>>> >>>> >>>> Regards, >>>> Alexey. >> From petr.pchelko at oracle.com Mon Apr 21 12:34:05 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 21 Apr 2014 16:34:05 +0400 Subject: [9] Review Request: 8036917 [macosx] Native memory leaks. Message-ID: Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8036917 The fix is available at: http://cr.openjdk.java.net/~pchelko/9/8036917/webrev/ The problem: We overretain native images so they are never deleted. The solution: When we return a native image pointer to Java it's retain count should be 1, so in case we use alloc-init we should not use retain. The image will be deleted in CFRetainedResource.dispose It's impossible to make a regression test. With best regards. Petr. From alexandr.scherbatiy at oracle.com Mon Apr 21 12:43:07 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 21 Apr 2014 16:43:07 +0400 Subject: [9] Review request for 8040279 [macosx] Do not use the base image in the MultiResolutionBufferedImage constructor In-Reply-To: References: <534D43D0.2010808@oracle.com> Message-ID: <5355125B.7030000@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8040279/webrev.01/ The createBufferedImage method is renamed to createImage in the CImage class. Thanks, Alexandr. On 4/21/2014 2:36 PM, Petr Pchelko wrote: > Hello, Alexander. > > Just one minor comment: In CImage createBufferedImage method does not create a BufferredImage any more, so it worths renaming. > > With best regards. Petr. > > On 15.04.2014, at 18:36, Alexander Scherbatiy wrote: > >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8040279 >> webrev: http://cr.openjdk.java.net/~alexsch/8040279/webrev.00 >> >> MultiResolutionBufferedImage extends BufferedImage. In this case it needs to use the base image to write it to the BufferedImage. >> >> The fix renames MultiResolutionBufferedImage to MultiResolutionCahcedImage and does not use the BufferedImage as the super class. >> The base image is created and cached by demand. >> >> CImage now always returns MultiResolutionCahcedImage. All requested resolution variants are scaled by NSImage. >> >> Thanks, >> Alexandr. >> From petr.pchelko at oracle.com Mon Apr 21 12:45:12 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 21 Apr 2014 16:45:12 +0400 Subject: [9] Review request for 8040279 [macosx] Do not use the base image in the MultiResolutionBufferedImage constructor In-Reply-To: <5355125B.7030000@oracle.com> References: <534D43D0.2010808@oracle.com> <5355125B.7030000@oracle.com> Message-ID: <26CE9FA5-206A-4F53-B439-53F45BD98C75@oracle.com> Hello, Alexander. The fix looks good. With best regards. Petr. On 21.04.2014, at 16:43, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8040279/webrev.01/ > > The createBufferedImage method is renamed to createImage in the CImage class. > > Thanks, > Alexandr. > > On 4/21/2014 2:36 PM, Petr Pchelko wrote: >> Hello, Alexander. >> >> Just one minor comment: In CImage createBufferedImage method does not create a BufferredImage any more, so it worths renaming. >> >> With best regards. Petr. >> >> On 15.04.2014, at 18:36, Alexander Scherbatiy wrote: >> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8040279 >>> webrev: http://cr.openjdk.java.net/~alexsch/8040279/webrev.00 >>> >>> MultiResolutionBufferedImage extends BufferedImage. In this case it needs to use the base image to write it to the BufferedImage. >>> >>> The fix renames MultiResolutionBufferedImage to MultiResolutionCahcedImage and does not use the BufferedImage as the super class. >>> The base image is created and cached by demand. >>> >>> CImage now always returns MultiResolutionCahcedImage. All requested resolution variants are scaled by NSImage. >>> >>> Thanks, >>> Alexandr. >>> > From anthony.petrov at oracle.com Mon Apr 21 13:20:59 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 21 Apr 2014 17:20:59 +0400 Subject: [9] Review Request: 8027148 SystemFlavorMap.getNativesForFlavor returns list of native formats in incorrect order In-Reply-To: <0008EDB8-C0C6-447B-B4A6-EEFF3B94CB99@oracle.com> References: <0008EDB8-C0C6-447B-B4A6-EEFF3B94CB99@oracle.com> Message-ID: <53551B3B.4060509@oracle.com> Hi Petr, 1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java > 118 private Map> getNativeToFlavor() { Usually we use a generic interface, such as Set, instead of a concrete implementation class (LinkedHashSet) in generic types declarations to avoid dependencies on concrete implementations that may change in the future. Would that be possible to do the same for method return type declarations in this file? 2. I'm not sure if the new formatting for htmlDocumntTypes at new lines 887 - 889 looks better than the old one. 3. In setNativesForFlavor() and addFlavorForUnencodedNative() we used to remove(null) from the getNativesForFlavorCache and getFlavorsForNativeCache caches. Now we don't. What is the story behind the nulls? How did they get there previously, and how do we avoid them now? Otherwise the fix looks okay. Note that I'm not an expert in this code, so I may have missed some issues in the logic changes. -- best regards, Anthony On 4/18/2014 5:49 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8027148 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8027148/webrev/ > > Sorry for the long text, but it?s quite tangled) > > The problem: > The flavor map contains some predefined mappings which are stored in the flavormap.properties file. But we can extend these mappings using > addUnencodedNativeForFlavor method. Javadoc states, that these new mappings would have lower priority that standard mappings. But in the current implementation this was not the case, because getNativesForFlavor method relied on the fact, that standard text mappings were stored as FlavorBaseType<->Native and newly added mappings were stored as DataFlavor<->Native, but after some fix in Java 8 this is not the case any more. Everything is stored as a DataFlavor as a key. This is important only for text flavors, because we support different text charsets and can reencode the text on the fly. So each native text format could be represented in many different DataFlavors with different encodings and representation classes. When we generate the set of DataFlavor?s that a text native can be translated to we no longer know how to distinguish the standard mappings and additional mappings and the get shuffled when we generate missing mappings for text formats. > > The solution: > I?ve added an additional map for standard text mappings. With this map we can now take natives for mime types directly and not "find all flavors for a mime-type and than all natives for each flavor". This is not only faster, but we can distinguish standard text mappings from custom and return the list in the correct order. The new hash map contains only a few elements. > > Also I?ve replaced the ArrayList as a collection of natives for a particular Flavor with a LinkedHashSet, because this list could not contain duplicated which we were enforcing ourselves. Now it works out of the box and some code can be removed. > > I?ve measured the performance of a couple of most hot methods and on average the new implementation is 1.7 times faster. > > The test is being open sources. > > I?ve tested this with JCK and our regression tests, everything looks good. Also I?ve tested with a couple of hand-made toys. > > Thank you. > With best regards. Petr. > From anthony.petrov at oracle.com Mon Apr 21 13:28:14 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 21 Apr 2014 17:28:14 +0400 Subject: [9] Review request for 8014754: [TEST_BUG] child.exe remains after execution java/awt/dnd/ Win32TYMEDSelectionTest and Win32DropTYMEDSelectionTest In-Reply-To: <535228B8.1000002@oracle.com> References: <53513322.5000002@oracle.com> <53513448.8030400@oracle.com> <535228B8.1000002@oracle.com> Message-ID: <53551CEE.5030109@oracle.com> Hi Oleg, The test now requires Visual Studio to be installed on the testing system, and the vcvars32.bat to be on PATH. This is not the case for most systems used by SQE to run tests. Therefore, leaving this test automatic seems undesirable. I suggest to make it a manual test, so that testers would have to run it explicitly. Note that it still should perform all the testing automatically using the Robot, and simply report to the user whether it's failed or passed. -- best regards, Anthony On 4/19/2014 11:41 AM, Oleg Pekhovskiy wrote: > Hi Anthony, > > thank you for pointing that out. > > Please review the new version of fix that meets mentioned requirements: > http://cr.openjdk.java.net/~bagiras/9/8014754.2 > > Thanks, > Oleg > > On 18.04.2014 18:18, Anthony Petrov wrote: >> Hi Oleg, >> >> We don't want to add binary files to the open repository. If you can >> only add the source code to it and make it compile itself upon test >> execution, then it is fine. But the .exe file itself should not be >> pushed to the repo. >> >> -- >> best regards, >> Anthony >> >> On 4/18/2014 6:13 PM, Oleg Pekhovskiy wrote: >>> Hi all, >>> >>> please review the fix >>> http://cr.openjdk.java.net/~bagiras/9/8014754.1/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8014754 >>> >>> Start of 'child.exe' has no timeout, that's why if dragging fails the >>> executable keeps running and prevents temporary folder from being >>> cleared. >>> So I forcibly terminate the process if it was not exited after dnd >>> action (lines 74-76 in Win32TYMEDSelectionTest.java) >>> >>> PS: Webrev doesn't include child.exe but it's also moved with the others >>> from the closed repository. >>> >>> Thanks, >>> Oleg From petr.pchelko at oracle.com Mon Apr 21 13:39:42 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 21 Apr 2014 17:39:42 +0400 Subject: [9] Review Request: 8027148 SystemFlavorMap.getNativesForFlavor returns list of native formats in incorrect order In-Reply-To: <53551B3B.4060509@oracle.com> References: <0008EDB8-C0C6-447B-B4A6-EEFF3B94CB99@oracle.com> <53551B3B.4060509@oracle.com> Message-ID: <73FA4A1E-80FF-46EB-9F6B-DC9E604DF72F@oracle.com> Hello, Anthony. I've updated the fix: http://cr.openjdk.java.net/~pchelko/9/8027148/webrev.01/ > 2. I'm not sure if the new formatting for htmlDocumntTypes at new lines 887 - 889 looks better than the old one. Reverted. > 1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java >> 118 private Map> getNativeToFlavor() { > > Usually we use a generic interface, such as Set, instead of a concrete implementation class (LinkedHashSet) in generic types declarations to avoid dependencies on concrete implementations that may change in the future. Would that be possible to do the same for method return type declarations in this file? I've done this on purpose here. It is VERY important for the collection used here to have a predictable iteration order, but it must not be sorted. We do not have any generic interface for this type of Set, so I've decided to place an exact class here so that nobody could by accident use a wrong Set and break everything. If a generic Set would be used someone could easily change it to HashSet somewhere in the overrides and not notice the bug. > 3. In setNativesForFlavor() and addFlavorForUnencodedNative() we used to remove(null) from the getNativesForFlavorCache and getFlavorsForNativeCache caches. Now we don't. What is the story behind the nulls? How did they get there previously, and how do we avoid them now? I've made a wrapper class for this cache (see the bottom of the file). With the wrapper we can create the cache lazily and the cache logic is now in one place. With best regards. Petr. On 21.04.2014, at 17:20, Anthony Petrov wrote: > Hi Petr, > > 1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java >> 118 private Map> getNativeToFlavor() { > > Usually we use a generic interface, such as Set, instead of a concrete implementation class (LinkedHashSet) in generic types declarations to avoid dependencies on concrete implementations that may change in the future. Would that be possible to do the same for method return type declarations in this file? > > 2. I'm not sure if the new formatting for htmlDocumntTypes at new lines 887 - 889 looks better than the old one. > > 3. In setNativesForFlavor() and addFlavorForUnencodedNative() we used to remove(null) from the getNativesForFlavorCache and getFlavorsForNativeCache caches. Now we don't. What is the story behind the nulls? How did they get there previously, and how do we avoid them now? > > Otherwise the fix looks okay. Note that I'm not an expert in this code, so I may have missed some issues in the logic changes. > > -- > best regards, > Anthony > > On 4/18/2014 5:49 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8027148 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/8027148/webrev/ >> >> Sorry for the long text, but it?s quite tangled) >> >> The problem: >> The flavor map contains some predefined mappings which are stored in the flavormap.properties file. But we can extend these mappings using >> addUnencodedNativeForFlavor method. Javadoc states, that these new mappings would have lower priority that standard mappings. But in the current implementation this was not the case, because getNativesForFlavor method relied on the fact, that standard text mappings were stored as FlavorBaseType<->Native and newly added mappings were stored as DataFlavor<->Native, but after some fix in Java 8 this is not the case any more. Everything is stored as a DataFlavor as a key. This is important only for text flavors, because we support different text charsets and can reencode the text on the fly. So each native text format could be represented in many different DataFlavors with different encodings and representation classes. When we generate the set of DataFlavor?s that a text native can be translated to we no longer know how to distinguish the standard mappings and additional mappings and the get shuffled when we generate missing mappings for text formats. >> >> The solution: >> I?ve added an additional map for standard text mappings. With this map we can now take natives for mime types directly and not "find all flavors for a mime-type and than all natives for each flavor". This is not only faster, but we can distinguish standard text mappings from custom and return the list in the correct order. The new hash map contains only a few elements. >> >> Also I?ve replaced the ArrayList as a collection of natives for a particular Flavor with a LinkedHashSet, because this list could not contain duplicated which we were enforcing ourselves. Now it works out of the box and some code can be removed. >> >> I?ve measured the performance of a couple of most hot methods and on average the new implementation is 1.7 times faster. >> >> The test is being open sources. >> >> I?ve tested this with JCK and our regression tests, everything looks good. Also I?ve tested with a couple of hand-made toys. >> >> Thank you. >> With best regards. Petr. >> From Sergey.Bylokhov at oracle.com Mon Apr 21 13:43:10 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 Apr 2014 17:43:10 +0400 Subject: [9] Review request for 8014754: [TEST_BUG] child.exe remains after execution java/awt/dnd/ Win32TYMEDSelectionTest and Win32DropTYMEDSelectionTest In-Reply-To: <53551CEE.5030109@oracle.com> References: <53513322.5000002@oracle.com> <53513448.8030400@oracle.com> <535228B8.1000002@oracle.com> <53551CEE.5030109@oracle.com> Message-ID: <5355206E.6010902@oracle.com> On 21.04.2014 17:28, Anthony Petrov wrote: > Hi Oleg, > > The test now requires Visual Studio to be installed on the testing > system, and the vcvars32.bat to be on PATH. This is not the case for > most systems used by SQE to run tests. Therefore, leaving this test > automatic seems undesirable. > > I suggest to make it a manual test, so that testers would have to run > it explicitly. Note that it still should perform all the testing > automatically using the Robot, and simply report to the user whether > it's failed or passed. I guess this is overkill. Why we cannot make this test closed? > > -- > best regards, > Anthony > > On 4/19/2014 11:41 AM, Oleg Pekhovskiy wrote: >> Hi Anthony, >> >> thank you for pointing that out. >> >> Please review the new version of fix that meets mentioned requirements: >> http://cr.openjdk.java.net/~bagiras/9/8014754.2 >> >> Thanks, >> Oleg >> >> On 18.04.2014 18:18, Anthony Petrov wrote: >>> Hi Oleg, >>> >>> We don't want to add binary files to the open repository. If you can >>> only add the source code to it and make it compile itself upon test >>> execution, then it is fine. But the .exe file itself should not be >>> pushed to the repo. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/18/2014 6:13 PM, Oleg Pekhovskiy wrote: >>>> Hi all, >>>> >>>> please review the fix >>>> http://cr.openjdk.java.net/~bagiras/9/8014754.1/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-8014754 >>>> >>>> Start of 'child.exe' has no timeout, that's why if dragging fails the >>>> executable keeps running and prevents temporary folder from being >>>> cleared. >>>> So I forcibly terminate the process if it was not exited after dnd >>>> action (lines 74-76 in Win32TYMEDSelectionTest.java) >>>> >>>> PS: Webrev doesn't include child.exe but it's also moved with the >>>> others >>>> from the closed repository. >>>> >>>> Thanks, >>>> Oleg -- Best regards, Sergey. From anthony.petrov at oracle.com Mon Apr 21 13:48:02 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 21 Apr 2014 17:48:02 +0400 Subject: [9] Review Request: 8027148 SystemFlavorMap.getNativesForFlavor returns list of native formats in incorrect order In-Reply-To: <73FA4A1E-80FF-46EB-9F6B-DC9E604DF72F@oracle.com> References: <0008EDB8-C0C6-447B-B4A6-EEFF3B94CB99@oracle.com> <53551B3B.4060509@oracle.com> <73FA4A1E-80FF-46EB-9F6B-DC9E604DF72F@oracle.com> Message-ID: <53552192.2090502@oracle.com> Thanks for the clarifications. The updated fix looks good to me. -- best regards, Anthony On 4/21/2014 5:39 PM, Petr Pchelko wrote: > Hello, Anthony. > > I've updated the fix: http://cr.openjdk.java.net/~pchelko/9/8027148/webrev.01/ > >> 2. I'm not sure if the new formatting for htmlDocumntTypes at new lines 887 - 889 looks better than the old one. > Reverted. > >> 1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java >>> 118 private Map> getNativeToFlavor() { >> >> Usually we use a generic interface, such as Set, instead of a concrete implementation class (LinkedHashSet) in generic types declarations to avoid dependencies on concrete implementations that may change in the future. Would that be possible to do the same for method return type declarations in this file? > I've done this on purpose here. It is VERY important for the collection used here to have a predictable iteration order, but it must not be sorted. We do not have any generic interface for this type of Set, so I've decided to place an exact class here so that nobody could by accident use a wrong Set and break everything. > If a generic Set would be used someone could easily change it to HashSet somewhere in the overrides and not notice the bug. > >> 3. In setNativesForFlavor() and addFlavorForUnencodedNative() we used to remove(null) from the getNativesForFlavorCache and getFlavorsForNativeCache caches. Now we don't. What is the story behind the nulls? How did they get there previously, and how do we avoid them now? > I've made a wrapper class for this cache (see the bottom of the file). With the wrapper we can create the cache lazily and the cache logic is now in one place. > > With best regards. Petr. > > On 21.04.2014, at 17:20, Anthony Petrov wrote: > >> Hi Petr, >> >> 1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java >>> 118 private Map> getNativeToFlavor() { >> >> Usually we use a generic interface, such as Set, instead of a concrete implementation class (LinkedHashSet) in generic types declarations to avoid dependencies on concrete implementations that may change in the future. Would that be possible to do the same for method return type declarations in this file? >> >> 2. I'm not sure if the new formatting for htmlDocumntTypes at new lines 887 - 889 looks better than the old one. >> >> 3. In setNativesForFlavor() and addFlavorForUnencodedNative() we used to remove(null) from the getNativesForFlavorCache and getFlavorsForNativeCache caches. Now we don't. What is the story behind the nulls? How did they get there previously, and how do we avoid them now? >> >> Otherwise the fix looks okay. Note that I'm not an expert in this code, so I may have missed some issues in the logic changes. >> >> -- >> best regards, >> Anthony >> >> On 4/18/2014 5:49 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8027148 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/9/8027148/webrev/ >>> >>> Sorry for the long text, but it?s quite tangled) >>> >>> The problem: >>> The flavor map contains some predefined mappings which are stored in the flavormap.properties file. But we can extend these mappings using >>> addUnencodedNativeForFlavor method. Javadoc states, that these new mappings would have lower priority that standard mappings. But in the current implementation this was not the case, because getNativesForFlavor method relied on the fact, that standard text mappings were stored as FlavorBaseType<->Native and newly added mappings were stored as DataFlavor<->Native, but after some fix in Java 8 this is not the case any more. Everything is stored as a DataFlavor as a key. This is important only for text flavors, because we support different text charsets and can reencode the text on the fly. So each native text format could be represented in many different DataFlavors with different encodings and representation classes. When we generate the set of DataFlavor?s that a text native can be translated to we no longer know how to distinguish the standard mappings and additional mappings and the get shuffled when we generate missing mappings for text formats. >>> >>> The solution: >>> I?ve added an additional map for standard text mappings. With this map we can now take natives for mime types directly and not "find all flavors for a mime-type and than all natives for each flavor". This is not only faster, but we can distinguish standard text mappings from custom and return the list in the correct order. The new hash map contains only a few elements. >>> >>> Also I?ve replaced the ArrayList as a collection of natives for a particular Flavor with a LinkedHashSet, because this list could not contain duplicated which we were enforcing ourselves. Now it works out of the box and some code can be removed. >>> >>> I?ve measured the performance of a couple of most hot methods and on average the new implementation is 1.7 times faster. >>> >>> The test is being open sources. >>> >>> I?ve tested this with JCK and our regression tests, everything looks good. Also I?ve tested with a couple of hand-made toys. >>> >>> Thank you. >>> With best regards. Petr. >>> > From Sergey.Bylokhov at oracle.com Tue Apr 22 14:46:34 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Apr 2014 18:46:34 +0400 Subject: [9] Review Request: 8027148 SystemFlavorMap.getNativesForFlavor returns list of native formats in incorrect order In-Reply-To: <73FA4A1E-80FF-46EB-9F6B-DC9E604DF72F@oracle.com> References: <0008EDB8-C0C6-447B-B4A6-EEFF3B94CB99@oracle.com> <53551B3B.4060509@oracle.com> <73FA4A1E-80FF-46EB-9F6B-DC9E604DF72F@oracle.com> Message-ID: <535680CA.1030203@oracle.com> Hi, Petr. Not an expert here, just a few notes. - I guess textTypeToNative must be initialized only once and can be replaced by Collections.unmodifiableMap(q); - Please check all related tests on all supported platforms, since we have a lots of regressions here. On 4/21/14 5:39 PM, Petr Pchelko wrote: > Hello, Anthony. > > I've updated the fix: http://cr.openjdk.java.net/~pchelko/9/8027148/webrev.01/ > >> 2. I'm not sure if the new formatting for htmlDocumntTypes at new lines 887 - 889 looks better than the old one. > Reverted. > >> 1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java >>> 118 private Map> getNativeToFlavor() { >> Usually we use a generic interface, such as Set, instead of a concrete implementation class (LinkedHashSet) in generic types declarations to avoid dependencies on concrete implementations that may change in the future. Would that be possible to do the same for method return type declarations in this file? > I've done this on purpose here. It is VERY important for the collection used here to have a predictable iteration order, but it must not be sorted. We do not have any generic interface for this type of Set, so I've decided to place an exact class here so that nobody could by accident use a wrong Set and break everything. > If a generic Set would be used someone could easily change it to HashSet somewhere in the overrides and not notice the bug. > >> 3. In setNativesForFlavor() and addFlavorForUnencodedNative() we used to remove(null) from the getNativesForFlavorCache and getFlavorsForNativeCache caches. Now we don't. What is the story behind the nulls? How did they get there previously, and how do we avoid them now? > I've made a wrapper class for this cache (see the bottom of the file). With the wrapper we can create the cache lazily and the cache logic is now in one place. > > With best regards. Petr. > > On 21.04.2014, at 17:20, Anthony Petrov wrote: > >> Hi Petr, >> >> 1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java >>> 118 private Map> getNativeToFlavor() { >> Usually we use a generic interface, such as Set, instead of a concrete implementation class (LinkedHashSet) in generic types declarations to avoid dependencies on concrete implementations that may change in the future. Would that be possible to do the same for method return type declarations in this file? >> >> 2. I'm not sure if the new formatting for htmlDocumntTypes at new lines 887 - 889 looks better than the old one. >> >> 3. In setNativesForFlavor() and addFlavorForUnencodedNative() we used to remove(null) from the getNativesForFlavorCache and getFlavorsForNativeCache caches. Now we don't. What is the story behind the nulls? How did they get there previously, and how do we avoid them now? >> >> Otherwise the fix looks okay. Note that I'm not an expert in this code, so I may have missed some issues in the logic changes. >> >> -- >> best regards, >> Anthony >> >> On 4/18/2014 5:49 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8027148 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/9/8027148/webrev/ >>> >>> Sorry for the long text, but it?s quite tangled) >>> >>> The problem: >>> The flavor map contains some predefined mappings which are stored in the flavormap.properties file. But we can extend these mappings using >>> addUnencodedNativeForFlavor method. Javadoc states, that these new mappings would have lower priority that standard mappings. But in the current implementation this was not the case, because getNativesForFlavor method relied on the fact, that standard text mappings were stored as FlavorBaseType<->Native and newly added mappings were stored as DataFlavor<->Native, but after some fix in Java 8 this is not the case any more. Everything is stored as a DataFlavor as a key. This is important only for text flavors, because we support different text charsets and can reencode the text on the fly. So each native text format could be represented in many different DataFlavors with different encodings and representation classes. When we generate the set of DataFlavor?s that a text native can be translated to we no longer know how to distinguish the standard mappings and additional mappings and the get shuffled when we generate missing mappings for text formats. >>> >>> The solution: >>> I?ve added an additional map for standard text mappings. With this map we can now take natives for mime types directly and not "find all flavors for a mime-type and than all natives for each flavor". This is not only faster, but we can distinguish standard text mappings from custom and return the list in the correct order. The new hash map contains only a few elements. >>> >>> Also I?ve replaced the ArrayList as a collection of natives for a particular Flavor with a LinkedHashSet, because this list could not contain duplicated which we were enforcing ourselves. Now it works out of the box and some code can be removed. >>> >>> I?ve measured the performance of a couple of most hot methods and on average the new implementation is 1.7 times faster. >>> >>> The test is being open sources. >>> >>> I?ve tested this with JCK and our regression tests, everything looks good. Also I?ve tested with a couple of hand-made toys. >>> >>> Thank you. >>> With best regards. Petr. >>> -- Best regards, Sergey. From petr.pchelko at oracle.com Wed Apr 23 09:39:48 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 23 Apr 2014 13:39:48 +0400 Subject: [9] Review request: 8041572 [macosx] huge native memory leak in AWTWindow.m Message-ID: <586A51CC-2B56-403A-89A6-C3A93AD255DD@oracle.com> Hello, AWT Team. Another huge native leak was found: https://bugs.openjdk.java.net/browse/JDK-8041572 The fix is simple and available here: http://cr.openjdk.java.net/~pchelko/9/8041572/webrev/ Along with fixing the bug in AWTWindow.m I've also grepped the sources for any core foundation methods that return a copied objects that needs to be released and found 2 mode similar leaks in GraphicsDevice.m Thank you. With best regards. Petr. From petr.pchelko at oracle.com Wed Apr 23 10:59:34 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 23 Apr 2014 14:59:34 +0400 Subject: [9] Review request: 8041490 PIT: [macosx] Crash in system tray functionality check test Message-ID: Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8041490 The fix is available at: http://cr.openjdk.java.net/~pchelko/9/8041490/webrev/ After Toolkit.sync() was implemented on OS X we've found a bug which was unnoticed: when the WarningWindow is disposed it's surface is not invalidated. So if we attempt to flush the GL queue after that we would crash. I've added the loop in the test to increase the probability of the crash. With best regards. Petr. From petr.pchelko at oracle.com Wed Apr 23 12:58:14 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 23 Apr 2014 16:58:14 +0400 Subject: [9] Review Request: 8027148 SystemFlavorMap.getNativesForFlavor returns list of native formats in incorrect order In-Reply-To: <535680CA.1030203@oracle.com> References: <0008EDB8-C0C6-447B-B4A6-EEFF3B94CB99@oracle.com> <53551B3B.4060509@oracle.com> <73FA4A1E-80FF-46EB-9F6B-DC9E604DF72F@oracle.com> <535680CA.1030203@oracle.com> Message-ID: Hello, Sergey. Please see the updated fix here: http://cr.openjdk.java.net/~pchelko/9/8027148/webrev.02/ > - I guess textTypeToNative must be initialized only once and can be replaced by Collections.unmodifiableMap(q); Done. > - Please check all related tests on all supported platforms, since we have a lots of regressions here. I've run all regression and functional datatransfer tests on all platforms.. And JCK. With best regards. Petr. On 22.04.2014, at 18:46, Sergey Bylokhov wrote: > Hi, Petr. > Not an expert here, just a few notes. > - I guess textTypeToNative must be initialized only once and can be replaced by Collections.unmodifiableMap(q); > - Please check all related tests on all supported platforms, since we have a lots of regressions here. > > On 4/21/14 5:39 PM, Petr Pchelko wrote: >> Hello, Anthony. >> >> I've updated the fix: http://cr.openjdk.java.net/~pchelko/9/8027148/webrev.01/ >> >>> 2. I'm not sure if the new formatting for htmlDocumntTypes at new lines 887 - 889 looks better than the old one. >> Reverted. >> >>> 1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java >>>> 118 private Map> getNativeToFlavor() { >>> Usually we use a generic interface, such as Set, instead of a concrete implementation class (LinkedHashSet) in generic types declarations to avoid dependencies on concrete implementations that may change in the future. Would that be possible to do the same for method return type declarations in this file? >> I've done this on purpose here. It is VERY important for the collection used here to have a predictable iteration order, but it must not be sorted. We do not have any generic interface for this type of Set, so I've decided to place an exact class here so that nobody could by accident use a wrong Set and break everything. >> If a generic Set would be used someone could easily change it to HashSet somewhere in the overrides and not notice the bug. >> >>> 3. In setNativesForFlavor() and addFlavorForUnencodedNative() we used to remove(null) from the getNativesForFlavorCache and getFlavorsForNativeCache caches. Now we don't. What is the story behind the nulls? How did they get there previously, and how do we avoid them now? >> I've made a wrapper class for this cache (see the bottom of the file). With the wrapper we can create the cache lazily and the cache logic is now in one place. >> >> With best regards. Petr. >> >> On 21.04.2014, at 17:20, Anthony Petrov wrote: >> >>> Hi Petr, >>> >>> 1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java >>>> 118 private Map> getNativeToFlavor() { >>> Usually we use a generic interface, such as Set, instead of a concrete implementation class (LinkedHashSet) in generic types declarations to avoid dependencies on concrete implementations that may change in the future. Would that be possible to do the same for method return type declarations in this file? >>> >>> 2. I'm not sure if the new formatting for htmlDocumntTypes at new lines 887 - 889 looks better than the old one. >>> >>> 3. In setNativesForFlavor() and addFlavorForUnencodedNative() we used to remove(null) from the getNativesForFlavorCache and getFlavorsForNativeCache caches. Now we don't. What is the story behind the nulls? How did they get there previously, and how do we avoid them now? >>> >>> Otherwise the fix looks okay. Note that I'm not an expert in this code, so I may have missed some issues in the logic changes. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/18/2014 5:49 PM, Petr Pchelko wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8027148 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/9/8027148/webrev/ >>>> >>>> Sorry for the long text, but it?s quite tangled) >>>> >>>> The problem: >>>> The flavor map contains some predefined mappings which are stored in the flavormap.properties file. But we can extend these mappings using >>>> addUnencodedNativeForFlavor method. Javadoc states, that these new mappings would have lower priority that standard mappings. But in the current implementation this was not the case, because getNativesForFlavor method relied on the fact, that standard text mappings were stored as FlavorBaseType<->Native and newly added mappings were stored as DataFlavor<->Native, but after some fix in Java 8 this is not the case any more. Everything is stored as a DataFlavor as a key. This is important only for text flavors, because we support different text charsets and can reencode the text on the fly. So each native text format could be represented in many different DataFlavors with different encodings and representation classes. When we generate the set of DataFlavor?s that a text native can be translated to we no longer know how to distinguish the standard mappings and additional mappings and the get shuffled when we generate missing mappings for text formats. >>>> >>>> The solution: >>>> I?ve added an additional map for standard text mappings. With this map we can now take natives for mime types directly and not "find all flavors for a mime-type and than all natives for each flavor". This is not only faster, but we can distinguish standard text mappings from custom and return the list in the correct order. The new hash map contains only a few elements. >>>> >>>> Also I?ve replaced the ArrayList as a collection of natives for a particular Flavor with a LinkedHashSet, because this list could not contain duplicated which we were enforcing ourselves. Now it works out of the box and some code can be removed. >>>> >>>> I?ve measured the performance of a couple of most hot methods and on average the new implementation is 1.7 times faster. >>>> >>>> The test is being open sources. >>>> >>>> I?ve tested this with JCK and our regression tests, everything looks good. Also I?ve tested with a couple of hand-made toys. >>>> >>>> Thank you. >>>> With best regards. Petr. >>>> > > > -- > Best regards, Sergey. > > From Sergey.Bylokhov at oracle.com Wed Apr 23 13:31:45 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 Apr 2014 17:31:45 +0400 Subject: [9] Review request: 8041490 PIT: [macosx] Crash in system tray functionality check test In-Reply-To: References: Message-ID: <5357C0C1.1080109@oracle.com> Hi, Petr. The fix looks good. On 4/23/14 2:59 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8041490 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8041490/webrev/ > > After Toolkit.sync() was implemented on OS X we've found a bug which was unnoticed: > when the WarningWindow is disposed it's surface is not invalidated. > So if we attempt to flush the GL queue after that we would crash. > I've added the loop in the test to increase the probability of the crash. > > With best regards. Petr. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Apr 23 13:39:52 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 Apr 2014 17:39:52 +0400 Subject: [9] Review Request: 8027148 SystemFlavorMap.getNativesForFlavor returns list of native formats in incorrect order In-Reply-To: References: <0008EDB8-C0C6-447B-B4A6-EEFF3B94CB99@oracle.com> <53551B3B.4060509@oracle.com> <73FA4A1E-80FF-46EB-9F6B-DC9E604DF72F@oracle.com> <535680CA.1030203@oracle.com> Message-ID: <5357C2A8.4060309@oracle.com> Hi, Petr. Thanks! The fix looks good. On 4/23/14 4:58 PM, Petr Pchelko wrote: > Hello, Sergey. > > Please see the updated fix here: http://cr.openjdk.java.net/~pchelko/9/8027148/webrev.02/ > >> - I guess textTypeToNative must be initialized only once and can be replaced by Collections.unmodifiableMap(q); > Done. > >> - Please check all related tests on all supported platforms, since we have a lots of regressions here. > I've run all regression and functional datatransfer tests on all platforms.. And JCK. > > With best regards. Petr. > > On 22.04.2014, at 18:46, Sergey Bylokhov wrote: > >> Hi, Petr. >> Not an expert here, just a few notes. >> - I guess textTypeToNative must be initialized only once and can be replaced by Collections.unmodifiableMap(q); >> - Please check all related tests on all supported platforms, since we have a lots of regressions here. >> >> On 4/21/14 5:39 PM, Petr Pchelko wrote: >>> Hello, Anthony. >>> >>> I've updated the fix: http://cr.openjdk.java.net/~pchelko/9/8027148/webrev.01/ >>> >>>> 2. I'm not sure if the new formatting for htmlDocumntTypes at new lines 887 - 889 looks better than the old one. >>> Reverted. >>> >>>> 1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java >>>>> 118 private Map> getNativeToFlavor() { >>>> Usually we use a generic interface, such as Set, instead of a concrete implementation class (LinkedHashSet) in generic types declarations to avoid dependencies on concrete implementations that may change in the future. Would that be possible to do the same for method return type declarations in this file? >>> I've done this on purpose here. It is VERY important for the collection used here to have a predictable iteration order, but it must not be sorted. We do not have any generic interface for this type of Set, so I've decided to place an exact class here so that nobody could by accident use a wrong Set and break everything. >>> If a generic Set would be used someone could easily change it to HashSet somewhere in the overrides and not notice the bug. >>> >>>> 3. In setNativesForFlavor() and addFlavorForUnencodedNative() we used to remove(null) from the getNativesForFlavorCache and getFlavorsForNativeCache caches. Now we don't. What is the story behind the nulls? How did they get there previously, and how do we avoid them now? >>> I've made a wrapper class for this cache (see the bottom of the file). With the wrapper we can create the cache lazily and the cache logic is now in one place. >>> >>> With best regards. Petr. >>> >>> On 21.04.2014, at 17:20, Anthony Petrov wrote: >>> >>>> Hi Petr, >>>> >>>> 1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java >>>>> 118 private Map> getNativeToFlavor() { >>>> Usually we use a generic interface, such as Set, instead of a concrete implementation class (LinkedHashSet) in generic types declarations to avoid dependencies on concrete implementations that may change in the future. Would that be possible to do the same for method return type declarations in this file? >>>> >>>> 2. I'm not sure if the new formatting for htmlDocumntTypes at new lines 887 - 889 looks better than the old one. >>>> >>>> 3. In setNativesForFlavor() and addFlavorForUnencodedNative() we used to remove(null) from the getNativesForFlavorCache and getFlavorsForNativeCache caches. Now we don't. What is the story behind the nulls? How did they get there previously, and how do we avoid them now? >>>> >>>> Otherwise the fix looks okay. Note that I'm not an expert in this code, so I may have missed some issues in the logic changes. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 4/18/2014 5:49 PM, Petr Pchelko wrote: >>>>> Hello, AWT Team. >>>>> >>>>> Please review the fix for the issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8027148 >>>>> The fix is available at: >>>>> http://cr.openjdk.java.net/~pchelko/9/8027148/webrev/ >>>>> >>>>> Sorry for the long text, but it?s quite tangled) >>>>> >>>>> The problem: >>>>> The flavor map contains some predefined mappings which are stored in the flavormap.properties file. But we can extend these mappings using >>>>> addUnencodedNativeForFlavor method. Javadoc states, that these new mappings would have lower priority that standard mappings. But in the current implementation this was not the case, because getNativesForFlavor method relied on the fact, that standard text mappings were stored as FlavorBaseType<->Native and newly added mappings were stored as DataFlavor<->Native, but after some fix in Java 8 this is not the case any more. Everything is stored as a DataFlavor as a key. This is important only for text flavors, because we support different text charsets and can reencode the text on the fly. So each native text format could be represented in many different DataFlavors with different encodings and representation classes. When we generate the set of DataFlavor?s that a text native can be translated to we no longer know how to distinguish the standard mappings and additional mappings and the get shuffled when we generate missing mappings for text formats. >>>>> >>>>> The solution: >>>>> I?ve added an additional map for standard text mappings. With this map we can now take natives for mime types directly and not "find all flavors for a mime-type and than all natives for each flavor". This is not only faster, but we can distinguish standard text mappings from custom and return the list in the correct order. The new hash map contains only a few elements. >>>>> >>>>> Also I?ve replaced the ArrayList as a collection of natives for a particular Flavor with a LinkedHashSet, because this list could not contain duplicated which we were enforcing ourselves. Now it works out of the box and some code can be removed. >>>>> >>>>> I?ve measured the performance of a couple of most hot methods and on average the new implementation is 1.7 times faster. >>>>> >>>>> The test is being open sources. >>>>> >>>>> I?ve tested this with JCK and our regression tests, everything looks good. Also I?ve tested with a couple of hand-made toys. >>>>> >>>>> Thank you. >>>>> With best regards. Petr. >>>>> >> >> -- >> Best regards, Sergey. >> >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Apr 23 13:45:19 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 Apr 2014 17:45:19 +0400 Subject: [9] Review request for 8040279 [macosx] Do not use the base image in the MultiResolutionBufferedImage constructor In-Reply-To: <26CE9FA5-206A-4F53-B439-53F45BD98C75@oracle.com> References: <534D43D0.2010808@oracle.com> <5355125B.7030000@oracle.com> <26CE9FA5-206A-4F53-B439-53F45BD98C75@oracle.com> Message-ID: <5357C3EF.6090402@oracle.com> Hi, Alexander. The fix looks good. Thanks! On 4/21/14 4:45 PM, Petr Pchelko wrote: > Hello, Alexander. > > The fix looks good. > > With best regards. Petr. > > On 21.04.2014, at 16:43, Alexander Scherbatiy wrote: > >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8040279/webrev.01/ >> >> The createBufferedImage method is renamed to createImage in the CImage class. >> >> Thanks, >> Alexandr. >> >> On 4/21/2014 2:36 PM, Petr Pchelko wrote: >>> Hello, Alexander. >>> >>> Just one minor comment: In CImage createBufferedImage method does not create a BufferredImage any more, so it worths renaming. >>> >>> With best regards. Petr. >>> >>> On 15.04.2014, at 18:36, Alexander Scherbatiy wrote: >>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8040279 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8040279/webrev.00 >>>> >>>> MultiResolutionBufferedImage extends BufferedImage. In this case it needs to use the base image to write it to the BufferedImage. >>>> >>>> The fix renames MultiResolutionBufferedImage to MultiResolutionCahcedImage and does not use the BufferedImage as the super class. >>>> The base image is created and cached by demand. >>>> >>>> CImage now always returns MultiResolutionCahcedImage. All requested resolution variants are scaled by NSImage. >>>> >>>> Thanks, >>>> Alexandr. >>>> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Apr 23 13:59:45 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 Apr 2014 17:59:45 +0400 Subject: [9] Review request: 8041572 [macosx] huge native memory leak in AWTWindow.m In-Reply-To: <586A51CC-2B56-403A-89A6-C3A93AD255DD@oracle.com> References: <586A51CC-2B56-403A-89A6-C3A93AD255DD@oracle.com> Message-ID: <5357C751.8000509@oracle.com> Hi, Petr. The fix looks good. On 4/23/14 1:39 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Another huge native leak was found: > https://bugs.openjdk.java.net/browse/JDK-8041572 > The fix is simple and available here: > http://cr.openjdk.java.net/~pchelko/9/8041572/webrev/ > > Along with fixing the bug in AWTWindow.m I've also grepped the sources for any core foundation methods that return a copied objects that needs to be released > and found 2 mode similar leaks in GraphicsDevice.m > > Thank you. > With best regards. Petr. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Apr 23 14:02:23 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 Apr 2014 18:02:23 +0400 Subject: [9] Review Request: 8039567 Duplicated code in DataTransferer In-Reply-To: References: <06D2CA5B-B72A-46D4-A611-08AD640828B2@oracle.com> <53455FF7.7070901@oracle.com> <534FF6E0.2070504@oracle.com> Message-ID: <5357C7EF.8060607@oracle.com> Hi, Petr. The fix looks good. On 4/18/14 11:04 AM, Petr Pchelko wrote: > Hello, > > Could you please review the updated version: > http://cr.openjdk.java.net/~pchelko/9/8039567/webrev.01/ > > Splited the long line. > Previously I didn?t add a couple of files into the webrev. Adding them now. > > With best regards. Petr. > > On Apr 17, 2014, at 7:44 PM, Sergey Bylokhov wrote: > >> Hi, Petr. >> The fix looks good. But can you split the long lines in the DataTransferer.java, it seems it has right margin = 80. >> On 4/17/14 1:00 PM, Petr Pchelko wrote: >>> Hello, >>> >>> Could I get a second review on this. >>> >>> With best regards. Petr. >>> >>> On 09.04.2014, at 18:57, Alexander Zvegintsev wrote: >>> >>>> Hi Petr, >>>> >>>> the fix looks good to me. >>>> >>>> Thanks, >>>> >>>> Alexander. >>>> >>>> On 04/09/2014 06:27 PM, Petr Pchelko wrote: >>>>> Hello AWT team. >>>>> >>>>> Please review a simple cleanup fix for the issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8039567 >>>>> The fix is available here: >>>>> http://cr.openjdk.java.net/~pchelko/9/8039567/webrev/ >>>>> >>>>> 1. The getBestCharsetForTextFormat is duplicated 3 times in the code. >>>>> 2. Caching of the default Charset in DataTransferer does not make sense as it's already cached in the Charset class itself. >>>>> Adding more references to the nio.Charset is not a problem since it's used in this class anyway and we cannot break this >>>>> dependency. >>>>> >>>>> With best regards. Petr. >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From petr.pchelko at oracle.com Wed Apr 23 14:26:49 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 23 Apr 2014 18:26:49 +0400 Subject: [9] Review Request: 7124250 [macosx] JOptionPane dialogs show wrong icons In-Reply-To: References: Message-ID: <1AADE6DA-B3B6-4CFA-A544-EAAB1C4E968D@oracle.com> Hello, AWT Team. Friendly reminder) With best regards. Petr. On 02.04.2014, at 19:02, Petr Pchelko wrote: > Hello, AWT team. > > Please review a step 1 fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-7124250 > The fix is here: > http://cr.openjdk.java.net/~pchelko/9/7124250/webrev/ > > In case Java is not installed we've requested an icon that Finder would've used for the folder where the java executable is located. > I have no idea why this was done, I've tested this fix with 10.8 and 10.9, Oracle JDK and OpenJDK, with simple apps, applets, JavaWS and bundled apps. > I've run Netbeans and Idea on top of the JDK with the fix and could not find any regressions, so I propose to remove the suspicious code. > > After this is fixed I'll file a new bug against the test, because it is wrong - it does not take into account that the OpenJDK and OracleJDK icons are different, > also golden images should be updated. > > With best regards. Petr. From petr.pchelko at oracle.com Wed Apr 23 16:58:31 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 23 Apr 2014 20:58:31 +0400 Subject: [9] Review Request: 7124250 [macosx] JOptionPane dialogs show wrong icons In-Reply-To: <5357E06D.6020607@oracle.com> References: <1AADE6DA-B3B6-4CFA-A544-EAAB1C4E968D@oracle.com> <5357E06D.6020607@oracle.com> Message-ID: <26A676F5-BA2A-4276-BD53-980007E57AB2@oracle.com> Hello, Leonid. > I see you've removed a call to AquaUtils.getCImageCreator().createImageOfFile(path, height, width). What was the original purpose of that call? What icon it is used to return? This returned the icon of a folder where java executable is located! So, normally this retuned a folder icon. So there was a strange situation: if java is installed on the system or bundled into .app we use one icon, if java is located somewhere else (like in build/images) we use another icon. We do not know the original purpose of this code, because it was written before the beginning of macosx port. But, as I?ve written, I?ve tested all possible combinations of JDK/OSX version/Bundling/Webstart and all looks correct, because we always use the icon from the Dock. With best regards. Petr. On Apr 23, 2014, at 7:46 PM, Leonid Romanov wrote: > Hello, > I see you've removed a call to AquaUtils.getCImageCreator().createImageOfFile(path, height, width). What was the original purpose of that call? What icon it is used to return? > > On 4/23/2014 18:26, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Friendly reminder) >> >> With best regards. Petr. >> >> On 02.04.2014, at 19:02, Petr Pchelko wrote: >> >>> Hello, AWT team. >>> >>> Please review a step 1 fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-7124250 >>> The fix is here: >>> http://cr.openjdk.java.net/~pchelko/9/7124250/webrev/ >>> >>> In case Java is not installed we've requested an icon that Finder would've used for the folder where the java executable is located. >>> I have no idea why this was done, I've tested this fix with 10.8 and 10.9, Oracle JDK and OpenJDK, with simple apps, applets, JavaWS and bundled apps. >>> I've run Netbeans and Idea on top of the JDK with the fix and could not find any regressions, so I propose to remove the suspicious code. >>> >>> After this is fixed I'll file a new bug against the test, because it is wrong - it does not take into account that the OpenJDK and OracleJDK icons are different, >>> also golden images should be updated. >>> >>> With best regards. Petr. > From yuri.nesterenko at oracle.com Thu Apr 24 09:26:12 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 24 Apr 2014 13:26:12 +0400 Subject: [9] Review Request for 8041592: [TEST_BUG] Move 42 AWT hw/lw mixing tests to jdk Message-ID: <5358D8B4.1090407@oracle.com> Hi, please review this change for https://bugs.openjdk.java.net/browse/JDK-8041592 Webrev is in: http://cr.openjdk.java.net/~yan/8041592/webrev.00/ Thanks, -yan Here's an excerpt from the bug Description: ________________________________________ There are 42 automatic functional tests verifying various aspects of HW/LW mixing in AWT. We will move them to a separate directory test/java/awt/Mixing/AWT_Mixing/. Note that: (1) we decided to make only small changes to the tests as it is just some 5% of our task at hand; (2) tests are written in someway different styles; (3) most of them extend some basic class (included in the same directory); (4) they use an utility class (included) someway duplicating new functionality of ExtendedRobot. However we left this part intact to avoid unnecessary refactoring; (5) the tests seems stable enough. They were run on 3 platforms continuously many times together demonstrating exactly the same output. (6) Of the 42 in total, 3 fail on OS X (2 of them also on Linux and Windows) because of the open product bugs. From leonid.romanov at oracle.com Wed Apr 23 17:15:33 2014 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 23 Apr 2014 21:15:33 +0400 Subject: [9] Review Request: 7124250 [macosx] JOptionPane dialogs show wrong icons In-Reply-To: <26A676F5-BA2A-4276-BD53-980007E57AB2@oracle.com> References: <1AADE6DA-B3B6-4CFA-A544-EAAB1C4E968D@oracle.com> <5357E06D.6020607@oracle.com> <26A676F5-BA2A-4276-BD53-980007E57AB2@oracle.com> Message-ID: Thanks for refreshing my memory: now, I remember what this bug is about. I also was unable to find a reason for such strange behavior. May be the original purpose of the code was to ensure that if JRE was bundled within an .app bundle with the custom icon, then the correct icon would be used. But I don?t think we support the old way of JRE bundling. So, if you say that with your fix the Dock icon is always used, them it looks good to me. On Apr 23, 2014, at 8:58 PM, Petr Pchelko wrote: > Hello, Leonid. > >> I see you've removed a call to AquaUtils.getCImageCreator().createImageOfFile(path, height, width). What was the original purpose of that call? What icon it is used to return? > This returned the icon of a folder where java executable is located! So, normally this retuned a folder icon. So there was a strange situation: if java is installed on the system or bundled into .app we use one icon, if java is located somewhere else (like in build/images) we use another icon. > > We do not know the original purpose of this code, because it was written before the beginning of macosx port. But, as I?ve written, I?ve tested all possible combinations of JDK/OSX version/Bundling/Webstart and all looks correct, because we always use the icon from the Dock. > > With best regards. Petr. > > On Apr 23, 2014, at 7:46 PM, Leonid Romanov wrote: > >> Hello, >> I see you've removed a call to AquaUtils.getCImageCreator().createImageOfFile(path, height, width). What was the original purpose of that call? What icon it is used to return? >> >> On 4/23/2014 18:26, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Friendly reminder) >>> >>> With best regards. Petr. >>> >>> On 02.04.2014, at 19:02, Petr Pchelko wrote: >>> >>>> Hello, AWT team. >>>> >>>> Please review a step 1 fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-7124250 >>>> The fix is here: >>>> http://cr.openjdk.java.net/~pchelko/9/7124250/webrev/ >>>> >>>> In case Java is not installed we've requested an icon that Finder would've used for the folder where the java executable is located. >>>> I have no idea why this was done, I've tested this fix with 10.8 and 10.9, Oracle JDK and OpenJDK, with simple apps, applets, JavaWS and bundled apps. >>>> I've run Netbeans and Idea on top of the JDK with the fix and could not find any regressions, so I propose to remove the suspicious code. >>>> >>>> After this is fixed I'll file a new bug against the test, because it is wrong - it does not take into account that the OpenJDK and OracleJDK icons are different, >>>> also golden images should be updated. >>>> >>>> With best regards. Petr. >> > From Sergey.Bylokhov at oracle.com Thu Apr 24 11:11:13 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 24 Apr 2014 15:11:13 +0400 Subject: [9] Review Request: 7124250 [macosx] JOptionPane dialogs show wrong icons In-Reply-To: <26A676F5-BA2A-4276-BD53-980007E57AB2@oracle.com> References: <1AADE6DA-B3B6-4CFA-A544-EAAB1C4E968D@oracle.com> <5357E06D.6020607@oracle.com> <26A676F5-BA2A-4276-BD53-980007E57AB2@oracle.com> Message-ID: <5358F151.70808@oracle.com> Hi, Petr. The fix looks good. On 4/23/14 8:58 PM, Petr Pchelko wrote: > Hello, Leonid. > >> I see you've removed a call to AquaUtils.getCImageCreator().createImageOfFile(path, height, width). What was the original purpose of that call? What icon it is used to return? > This returned the icon of a folder where java executable is located! So, normally this retuned a folder icon. So there was a strange situation: if java is installed on the system or bundled into .app we use one icon, if java is located somewhere else (like in build/images) we use another icon. > > We do not know the original purpose of this code, because it was written before the beginning of macosx port. But, as I?ve written, I?ve tested all possible combinations of JDK/OSX version/Bundling/Webstart and all looks correct, because we always use the icon from the Dock. > > With best regards. Petr. > > On Apr 23, 2014, at 7:46 PM, Leonid Romanov wrote: > >> Hello, >> I see you've removed a call to AquaUtils.getCImageCreator().createImageOfFile(path, height, width). What was the original purpose of that call? What icon it is used to return? >> >> On 4/23/2014 18:26, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Friendly reminder) >>> >>> With best regards. Petr. >>> >>> On 02.04.2014, at 19:02, Petr Pchelko wrote: >>> >>>> Hello, AWT team. >>>> >>>> Please review a step 1 fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-7124250 >>>> The fix is here: >>>> http://cr.openjdk.java.net/~pchelko/9/7124250/webrev/ >>>> >>>> In case Java is not installed we've requested an icon that Finder would've used for the folder where the java executable is located. >>>> I have no idea why this was done, I've tested this fix with 10.8 and 10.9, Oracle JDK and OpenJDK, with simple apps, applets, JavaWS and bundled apps. >>>> I've run Netbeans and Idea on top of the JDK with the fix and could not find any regressions, so I propose to remove the suspicious code. >>>> >>>> After this is fixed I'll file a new bug against the test, because it is wrong - it does not take into account that the OpenJDK and OracleJDK icons are different, >>>> also golden images should be updated. >>>> >>>> With best regards. Petr. -- Best regards, Sergey. From alexey.ivanov at oracle.com Thu Apr 24 12:23:14 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 24 Apr 2014 16:23:14 +0400 Subject: [9] Review request for JDK-8039383: NPE when changing Windows Theme In-Reply-To: <53513C26.9060305@oracle.com> References: <5350DDBC.30603@oracle.com> <5351143C.8010100@oracle.com> <53513B5B.4050104@oracle.com> <53513C26.9060305@oracle.com> Message-ID: <53590232.4080703@oracle.com> Hi Anthony, AWT and Swing teams, Here's the updated fix: http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/ Description: In the new version of the fix, I use a new xpstyleEnabled field of AtomicBoolean in WToolkit to track the current value of "win.xpstyle.themeActive" desktop property. Its value is updated in windowsSettingChange() and in updateProperties(). XPStyle.getXP() checks its cached value in themeActive and the current value in WToolkit; if the value changes, it schedules updateAllUIs and invalidates the current style right away, so that components would not access data from the theme that became unavailable. Two functions in ThemeReader also check this special field from WToolkit which prevents throwing InternalError when paint is called before theme change is fully handled. Before updateAllUIs is invoked, it's possible that application will paint with some values cached from the previous theme. Usually it happens before "Theme change" dialog disappears from the screen, at least I noticed no UI glitches during normal theme change. Regression test: No regression test is provided due to its complexity. Additionally, whether NullPointerException or InternalError are thrown depends on the order of event handling, sometimes exceptions do not occur when changing theme of visual styles enabled theme to a classic theme. Thank you, Alexey. On 18.04.2014 18:52, Anthony Petrov wrote: > Hi Alexey, > > No, unfortunately I don't have any suggestions right now. > > As for allowing executing user code on the toolkit thread, we can't > accept such a fix. Sorry about that. > > -- > best regards, > Anthony > > On 4/18/2014 6:48 PM, Alexey Ivanov wrote: >> Hi Anthony, >> >> Thank you for your review. >> >> Yes, user code can install a property change listener... It was my >> concern too, that's why I explicitly noted about this. >> >> Do you have any suggestion how this situation can be handled? >> Is it a general rule that all desktop property change listeners must be >> called on EDT? >> >> >> Thanks, >> Alexey. >> >> On 18.04.2014 16:02, Anthony Petrov wrote: >>> Hi Alexey, >>> >>>> With this change, property "win.xpstyle.themeActive" change is fired >>>> on the toolkit thread >>> >>> Is it possible to install a change listener for this property from >>> user code, and hence eventually allow executing some user code on the >>> toolkit thread with your fix? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote: >>>> Hello Swing and AWT teams, >>>> >>>> Could you please review the fix for jdk9: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039383 >>>> webrev: >>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.00/ >>>> >>>> Problem description: >>>> When changing Windows themes from a theme with visual styles (Windows >>>> Aero or Windows Basic) to a classic one, NullPointerException could be >>>> thrown from Swing code during component tree validation, or >>>> InternalError could be thrown during component painting. >>>> >>>> Root cause: >>>> Windows theme data are "cached" in XPStyle object. When the theme is >>>> switched to a classic one, HTHEME handle becomes unavailable and data >>>> cannot be accessed from the theme any more. The change in theme in >>>> posted to EDT via invokeLater. At the same time, the UI needs to >>>> repaint >>>> itself as soon as Windows changed the theme, and paint code is often >>>> called before the theme change is handled in Java. This leads to >>>> NPE and >>>> InternalError as the code tries to access the data that has become >>>> unavailable. >>>> >>>> The fix: >>>> Update "win.xpstyle.themeActive" desktop property and invalidate the >>>> cached XPStyle as soon as windowsSettingChange() is called from native >>>> code. Thus when Swing code needs to access theme data, it will see no >>>> theme is available and will fallback to classic painting. >>>> >>>> Note: Before the fix, PropertyChangeEvents for desktop properties in >>>> Windows were fired on the Event Dispatch Thread. With this change, >>>> property "win.xpstyle.themeActive" change is fired on the toolkit >>>> thread; all other properties are changed on the EDT as before. >>>> >>>> >>>> Regards, >>>> Alexey. >> From alexandr.scherbatiy at oracle.com Thu Apr 24 14:33:25 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 24 Apr 2014 18:33:25 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: <533E9D42.10409@oracle.com> References: <52D51764.8020103@oracle.com> <52DF2F98.3030503@oracle.com> <52F4BCEB.9040702@oracle.com> <52F5782A.9060300@oracle.com> <52FB7E3E.6050000@oracle.com> <52FC14EC.9080503@oracle.com> <53037D3D.80709@oracle.com> <5307E71E.50607@oracle.com> <530F3592.40600@oracle.com> <532B00AD.1000704@oracle.com> <532B7EC5.9000206@oracle.com> <532C4DD7.1080804@oracle.com> <532CD202.5070508@oracle.com> <53302A8E.6090107@oracle.com> <53343914.6090004@oracle.com> <533C8DDB.5000406@oracle.com> <533E9D42.10409@oracle.com> Message-ID: <535920B5.5070406@oracle.com> Hello, I have decided to split the current issue on two parts: - 8029339 Custom MultiResolution image support on HiDPI displays that covers only MultiResolutionImage interface and AbstractMultiResolutionImage class realization - 8041714 Add methods that create MultiResolutionImage from collection of images Could you review the fix for the issue 8029339 : http://cr.openjdk.java.net/~alexsch/8029339/webrev.05 The fix adds: - MultiResolutionImage interface and AbstractMultiResolutionImage class - Resolution variant rendering hints It needs to extend the AbstractMultiResolutionImage class and override only 3 methods to create a multi-resolution image. For example: --------------------- public class CustomMultiResolutionImage extends AbstractMultiResolutionImage { int baseImageIndex; Image[] resolutionVariants; public CustomMultiResolutionImage(int baseImageIndex, Image... resolutionVariants) { this.baseImageIndex = baseImageIndex; this.resolutionVariants = resolutionVariants; } @Override public Image getResolutionVariant(float logicalDPIX, float logicalDPIY, float baseImageWidth, float baseImageHeight, float destImageWidth, float destImageHeight) { // return a resolution variant based on the given logical DPI, // base image size, or destination image size } @Override public List getResolutionVariants() { return Arrays.asList(resolutionVariants); } protected Image getBaseImage() { return resolutionVariants[baseImageIndex]; } } --------------------- The multi-resolution image creation from collection of images is covered by the issue 8041714. Thanks, Alexandr. On 4/4/2014 3:53 PM, Alexander Scherbatiy wrote: > On 4/3/2014 2:23 AM, Jim Graham wrote: >> Hi Alexandr, >> >> The back and forth is getting confusing here, so I thought I'd try to >> summarize and start fresh(ish): >> >> 1. We need to support @2x internally for MacOS compatibility (done). >> >> 2. We will need to support _DPI images for Win-DPI compatibility (TBD). >> >> 3. Customers may have their own collection of images to bundle >> together into an MR image (working on that here). What is the push >> for this? Is this simply parity with Mac interfaces? > > ---------- > Image[] resolutionVariants = // get sorted by sizes array of > resolution variants; > Image mrImage = > Toolkit.getDefaultToolkit().createMRImage(baseImageIndex, > resolutionVariants); > ---------- > > Here is the proposed patch: > http://cr.openjdk.java.net/~alexsch/8029339/webrev.04/ > >> 4. Customers may want to synthetically generate images at arbitrary >> resolutions (a variation that is impacting this solution). What is >> the push for this? > ---------- > Image mrImage = > Toolkit.getDefaultToolkit().createMRImage(baseImageWidth, > baseImageHeight, > new float[][]{{100, 100}, {150, 150}, {200, 200}}, // > resolution variants sizes > (rvWidth, rvHeight) -> { /* generate a resolution > variant */ }); > ---------- > >> >> 5. I'm guessing that customers might want to override the logic to >> choose from among multiple resolutions. That came from me based on >> seeing Mac and Win using different selection logic and our history of >> developers split between those wanting cross-platform consistency and >> those wanting consistency with native apps on each platform. Also, >> the needs of an animator may differ from the needs of a >> resolution-settable-document editor as to how dynamically the images >> shift between resolution variants. > ---------- > Image[] resolutionVariants = // get sorted by sizes array of > resolution variants; > Image mrImage = ImageResolutionHelper.createMRImage( > (rvWidth, rvHeight, resolutionVariants) -> { /*use a > custom logic to choose a resolution variant from an array of images*/}, > (logicalDPI, baseImageSize, destImageSize) -> > destImageSize, // calculate the custom aware resolution variant size > baseImageIndex, resolutionVariants); > ---------- > > or just extend the CustomMultiResolutionImage which has Image as > the parent class: > > -------------------- > public class CustomMultiResolutionImage extends > AbstractMultiResolutionImage { > > @Override > public Image getResolutionVariant(float logicalDPIX, float > logicalDPIY, > float baseImageWidth, float baseImageHeight, > float destImageWidth, float destImageHeight) { > // return a resolution variant based on the given logical DPI, > // base image size, or destination image size > } > > @Override > public List getResolutionVariants() { > // return a list of resolution variants > } > > @Override > protected Image getBaseImage() { > // return the base image > } > } > -------------------- >> >> Is that a fair summary of all of the considerations so far, or did I >> miss something? > I think it should cover the main needs. > > Thanks, > Alexandr. >> >> ...jim >> >> On 3/27/14 7:43 AM, Alexander Scherbatiy wrote: >>> >>> Below are some thoughts about TK.createMRImage(...) method >>> >>> On 3/24/2014 4:52 PM, Alexander Scherbatiy wrote: >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.03/ >>>> >>>> - baseImageWidth/Height arguments are added to the >>>> getResolutionVariant(...) method >>>> - dest image sizes are reverted to included DPI scale >>>> - AbstractMultiResolutionImage is added. It needs only to implement >>>> only 3 methods from the AbstractMultiResolutionImage class >>>> to create a custom multi-resolution image. For example: >>>> >>>> On 3/22/2014 3:57 AM, Jim Graham wrote: >>>>> >>>>> Your code example below can be expressed as an implementation of the >>>>> single-method, lambda-compatible interface that expresses just the >>>>> getRV() method. They could easily do: >>>>> >>>>> final Image baseImage = ...; >>>>> TK.createMRImage(new RVInterface() { >>>>> public Image getRV(...) { >>>>> // calculate rvWidth and rvHeight >>>>> // look up rvWidth/rvHeight in a database of images >>>>> // possibly contruct a new image >>>>> return rvImage; >>>>> } >>>>> }, baseImage); >>>>> >>> The RVInterface mixes the logic that construct an image and >>> chooses the necessary resolution variant. >>> It is ok if a developer always implements this interface. If it >>> needs to have DPI/Transform/Platform aware RVInterface the image >>> construction logic should be separated. >>> >>> Does TK.createMRImage() method implies that Platform aware logic >>> should be used for a resolution-variant choosing? >>> If so, may be general createMRImage() can be placed in the >>> ImageResolutionHelper. >>>>> The main issue I see is if you might want the newly constructed >>>>> variants to appear in the List returned from the getVariants() >>>>> method. I'm not sure what value that would have beyond simply >>>>> returning the base media that the object uses from which to construct >>>>> its variants...? >>> >>> It can be solved by using something like array of image sizes or >>> other seeds and a mapper that can create an image from the given seed. >>> >>> It can look like: >>> ------------------------- >>> public class ImageResolutionHelper { >>> public interface RVChooser { >>> >>> public Image getRV( >>> float logicalDPIX, float logicalDPIY, >>> float baseImageWidth, float baseImageHeight, >>> float destImageWidth, float destImageHeight, >>> final Image... resolutionVariants); >>> } >>> >>> public static final RVChooser DPI_AWARE = ...; >>> public static final RVChooser TRANSFORM_AWARE = ...; >>> >>> // resolutionVariants is an array of sorted by width/height >>> images >>> static Image createMRImage(final RVChooser rvChooser, >>> final int baseImageIndex, final Image... >>> resolutionVariants) { ... } >>> >>> // sorted by width/height images should be generated from seeds >>> static Image createMRImage(final RVChooser rvChooser, >>> final Type baseImageSeed, final Function >>> mapper, final Type... rvSeeds) {...} >>> } >>> >>> public abstract class Toolkit { >>> public abstract Image createMRImage(int baseImageIndex, Image... >>> resolutionVariants); // Platform aware rv chooser is used >>> public abstract RVChooser getPlatformRVChooser() ; >>> } >>> -------------------------- >>> Thanks, >>> Alexandr. >>> >>>>> >>>>>> I think it is better to provide both the >>>>>> MultiResolutionImage and >>>>>> its implementation based on the given resolution variants array. >>>>> >>>>> It occurs to me that even if we don't go with a lambda-factory-based >>>>> approach like what I'm describing, it might make sense to provide a >>>>> baseMR implementation that they can subclass to keep them from trying >>>>> to subclass off of BufferedImage instead. I really would like to >>>>> avoid "custom MR images are subclasses of BufImg" if we can as I >>>>> think the mix of concepts is a little jarring... >>>>> >>>>> ...jim >>>>> >>>>>> The implementation could look like: >>>>>> --------------------------------- >>>>>> public class CustomMultiResolutionImage extends Image implements >>>>>> MultiResolutionImage { >>>>>> >>>>>> int baseImageIndex; >>>>>> Image[] resolutionVariants; >>>>>> >>>>>> public CustomMultiResolutionImage(int baseImageIndex, >>>>>> Image... resolutionVariants) { >>>>>> this.baseImageIndex = baseImageIndex; >>>>>> this.resolutionVariants = resolutionVariants; >>>>>> } >>>>>> >>>>>> @Override >>>>>> public int getWidth(ImageObserver observer) { >>>>>> return getBaseImage().getWidth(null); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public int getHeight(ImageObserver observer) { >>>>>> return getBaseImage().getHeight(null); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public ImageProducer getSource() { >>>>>> return getBaseImage().getSource(); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public Graphics getGraphics() { >>>>>> return getBaseImage().getGraphics(); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public Object getProperty(String name, ImageObserver >>>>>> observer) { >>>>>> return getBaseImage().getProperty(name, observer); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>>> logicalDPIY, >>>>>> float destinationImageWidth, float >>>>>> destinationImageHeight) { >>>>>> // calculate resolution variant width/height >>>>>> return getResolutionVariant(rvWidth, rvHeight); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public List getResolutionVariants() { >>>>>> return Arrays.asList(resolutionVariants); >>>>>> } >>>>>> >>>>>> private Image getResolutionVariant(float rvWidth, float >>>>>> rvHeight) { >>>>>> // return a resolution variant based on the given width and >>>>>> height >>>>>> } >>>>>> >>>>>> private Image getBaseImage() { >>>>>> return resolutionVariants[baseImageIndex]; >>>>>> } >>>>>> } >>>>>> --------------------------------- >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> >>>>>>> Then we provide one of these from TK.get/createImage() when the >>>>>>> platform detects @2x, or Win8-style variants. >>>>>>> >>>>>>> For custom images we provide TK.createMRImage(lambda getRV, Image >>>>>>> variants...) and TK.createMRImage(Image variants...); >>>>>>> >>>>>>> Since the get method is just bookkeeping, I don't see them >>>>>>> needing to override it, so the getRV() method is really the only >>>>>>> thing >>>>>>> they might want to override, and we can tie into the new Lambda >>>>>>> capabilities by making a single-method interface for it that they >>>>>>> supply in a factory method. >>>>>>> >>>>>>> I realize that the interface you created is more fundamentally >>>>>>> OO, but >>>>>>> the Image class has always been special in this regard in the AWT >>>>>>> ecosystem (in so far as we do not support someone implementing >>>>>>> their >>>>>>> own Image subclass even though it is technically possible). >>>>>>> Because of >>>>>>> this special nature of Image, we end up with the situation that if >>>>>>> someone were given a need to create a subclass of Image, then they >>>>>>> would turn to BufImg as their superclass even though BufImg is >>>>>>> essentially an implementation-specific leaf node on the Image class >>>>>>> hierarchy. This approach with a factory method to create an >>>>>>> internal >>>>>>> subclass of the new MRI class mirrors the existing cases of Image >>>>>>> objects that come from factories as well. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> >>>>>>> On 3/20/14 7:52 AM, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the updated version of the fix: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.01/ >>>>>>>> >>>>>>>> - The "getResolutionVariant(int width, int height)" method from >>>>>>>> MultiResolutionImage class is changed to >>>>>>>> Image getResolutionVariant(float logicalDPIX, float >>>>>>>> logicalDPIY, >>>>>>>> float width, float height, AffineTransform transform); >>>>>>>> >>>>>>>> - sun.awt.image.ImageResolutionHelper class is added. The >>>>>>>> sun.awt.image.MultiResolutionToolkitImage and >>>>>>>> sun.awt.image.MultiResolutionBufferedImage classes are used >>>>>>>> PLATFORM ImageResolutionHelper. >>>>>>>> >>>>>>>> The MultiResolutionImage interface implementation could look >>>>>>>> like: >>>>>>>> ------------------------------ >>>>>>>> public class CustomMultiResolutionImage extends BufferedImage >>>>>>>> implements >>>>>>>> MultiResolutionImage { >>>>>>>> >>>>>>>> private final Image[] resolutionVariants; >>>>>>>> >>>>>>>> public CustomMultiResolutionImage(int baseIndex, Image... >>>>>>>> images) { >>>>>>>> super(images[baseIndex].getWidth(null), >>>>>>>> images[baseIndex].getHeight(null), >>>>>>>> BufferedImage.TYPE_INT_RGB); >>>>>>>> this.resolutionVariants = images; >>>>>>>> Graphics g = getGraphics(); >>>>>>>> g.drawImage(images[baseIndex], 0, 0, null); >>>>>>>> g.dispose(); >>>>>>>> } >>>>>>>> >>>>>>>> @Override >>>>>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>>>>> logicalDPIY, >>>>>>>> float width, float height, AffineTransform >>>>>>>> transform) { >>>>>>>> return getResolutionVariant(logicalDPIX * width, >>>>>>>> logicalDPIY * >>>>>>>> height); >>>>>>>> } >>>>>>>> >>>>>>>> @Override >>>>>>>> public List getResolutionVariants() { >>>>>>>> return Arrays.asList(resolutionVariants); >>>>>>>> } >>>>>>>> >>>>>>>> public Image getResolutionVariant(double width, double >>>>>>>> height) { >>>>>>>> for (Image image : resolutionVariants) { >>>>>>>> if (width <= image.getWidth(null) && height <= >>>>>>>> image.getHeight(null)) { >>>>>>>> return image; >>>>>>>> } >>>>>>>> } >>>>>>>> return this; >>>>>>>> } >>>>>>>> } >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 2/27/2014 4:54 PM, Alexander Scherbatiy wrote: >>>>>>>>> On 2/22/2014 3:54 AM, Jim Graham wrote: >>>>>>>>>> Hi Alexandr, >>>>>>>>>> >>>>>>>>>> On 2/18/14 7:33 AM, Alexander Scherbatiy wrote: >>>>>>>>>>> Hi Jim, >>>>>>>>>>> >>>>>>>>>>> Let's divide the discussion into two part. >>>>>>>>>>> >>>>>>>>>>> 1. Where it is better to hold resolution variants? >>>>>>>>>>> Putting resolution variants in Image class brings some >>>>>>>>>>> questions like: >>>>>>>>>>> - Some type of images do not need to have resolution >>>>>>>>>>> variants >>>>>>>>>>> - Should resolution variants have the same type as the base >>>>>>>>>>> image? >>>>>>>>>>> - getResolutionVariants() method can return copy of the >>>>>>>>>>> original >>>>>>>>>>> list >>>>>>>>>>> so add/removeRV methods should be also added. >>>>>>>>>>> >>>>>>>>>>> There are pros and cons for placing resolution variants to >>>>>>>>>>> Image >>>>>>>>>>> class or to a separate intreface. >>>>>>>>>> >>>>>>>>>> I agree that this could be a separate interface. In my examples >>>>>>>>>> below I was just sticking them inside an "Image{}" to show where >>>>>>>>>> they >>>>>>>>>> lived in the set of involved objects, not a specific >>>>>>>>>> recommendation >>>>>>>>>> that they actually be new methods on the base class itself. I >>>>>>>>>> probably should have put a comment there about that. >>>>>>>>>> >>>>>>>>>> With respect to add/remove - that is assuming a need for manual >>>>>>>>>> construction of an image set, right? Forgive me if I'm >>>>>>>>>> forgetting >>>>>>>>>> something, but I seem to recall that manual Multi-Res images was >>>>>>>>>> proposed as a way for developers to introduce @2x support >>>>>>>>>> themselves, >>>>>>>>>> but if we are internally managing @2x and -DPI variants for >>>>>>>>>> them, >>>>>>>>>> then I'm not sure if there is actual developer need to manually >>>>>>>>>> construct their own. Am I forgetting something? >>>>>>>>> The NSImage has addRepresentation/removeRepresentation >>>>>>>>> methods to >>>>>>>>> work with image representations on Mac OS X. >>>>>>>>> The java.awt.Image class should provide similar >>>>>>>>> functionality to >>>>>>>>> have the possibilities as Cocoa on HiDPI displays. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 2. Using scale factor/image sizes/scaled image sizes to >>>>>>>>>>> retreive a >>>>>>>>>>> resolution variant. >>>>>>>>>>> >>>>>>>>>>> May be it is better to have a structure that provide all >>>>>>>>>>> necessary >>>>>>>>>>> information to query the resolution variant: scale factor, >>>>>>>>>>> draw area >>>>>>>>>>> width/height, transformed area width/height? >>>>>>>>>>> >>>>>>>>>>> For example: >>>>>>>>>>> --------------------- >>>>>>>>>>> public interface MultiResolutionImage { >>>>>>>>>>> >>>>>>>>>>> interface DrawAreaInfo { >>>>>>>>>>> >>>>>>>>>>> float getScaleFactor(); >>>>>>>>>>> float getAreaWidth(); >>>>>>>>>>> float getAreaHeight(); >>>>>>>>>>> float getTransformedAreaWidth(); >>>>>>>>>>> float getTransformedAreaHeight(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> public Image getResolutionVariant(DrawAreaInfo >>>>>>>>>>> drawAreaInfo) ; >>>>>>>>>>> public List getResolutionVariants(); >>>>>>>>>>> } >>>>>>>>>>> --------------------- >>>>>>>>>> >>>>>>>>>> The problem with a constructor is that this is something that is >>>>>>>>>> (potentially) done on every drawImage() call, which means we are >>>>>>>>>> inviting GC into the equation. If we can come up with a simple >>>>>>>>>> "just >>>>>>>>>> a couple/3/4 numbers" way to embed that data into a method call >>>>>>>>>> argument list then we can make this lighter weight. >>>>>>>>>> >>>>>>>>>> What about simply having floating point (double) dimensions >>>>>>>>>> on the >>>>>>>>>> rendered size >>>>>>>>> There should be a way to choose a resolution variant >>>>>>>>> based on >>>>>>>>> requested drawing size or transformed drawing size. >>>>>>>>> At least a current transformation should be included too. >>>>>>>>>> plus a single floating point "logical DPI" for the screen? >>>>>>>>> There is the ID2D1Factory::GetDesktopDpi method which >>>>>>>>> returns >>>>>>>>> dpiX and dpiY. >>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316 >>>>>>>>> >>>>>>>>> That means that logicalDPIX/Y can have different values. >>>>>>>>> At least it is described in the >>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/ff684173 >>>>>>>>> "To get the DPI setting, call the >>>>>>>>> ID2D1Factory::GetDesktopDpi >>>>>>>>> method. The DPI is returned as two floating-point values, one for >>>>>>>>> the >>>>>>>>> x-axis and one for the y-axis. In theory, these values can >>>>>>>>> differ. >>>>>>>>> Calculate a separate scaling factor for each axis." >>>>>>>>> >>>>>>>>> The getResolutionVariant method could look like: >>>>>>>>> -------------------------------------- >>>>>>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>>>>>> logicalDPIY, >>>>>>>>> float widthX, float widthY, AffineTransform >>>>>>>>> transform); >>>>>>>>> -------------------------------------- >>>>>>>>> >>>>>>>>>> If the image is known (either passed as an argument or the >>>>>>>>>> method is >>>>>>>>>> called on the image), then it can provide the original WH. >>>>>>>>>> >>>>>>>>>>> The MultiResolutionImage default implementation could allow >>>>>>>>>>> to use >>>>>>>>>>> different strategies like scale factor/transfom/OS based >>>>>>>>>>> to query a resolution variant. The OS based strategy can be >>>>>>>>>>> used by >>>>>>>>>>> default. >>>>>>>>>> >>>>>>>>>> For Mac policy, all we need is the transformed dimensions, which >>>>>>>>>> can >>>>>>>>>> be passed in as FP for generality. For Windows policy, all >>>>>>>>>> we need >>>>>>>>>> is logical DPI for the screen. What other information would we >>>>>>>>>> need, or would an algorithm like to use, that can't be computed >>>>>>>>>> from >>>>>>>>>> those 2 pieces? >>>>>>>>> The aim is to provide a base class that can be used to >>>>>>>>> create a >>>>>>>>> MultiResolutionImage like: >>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/diff/ae53ebce5fa3/src/share/classes/sun/awt/image/MultiResolutionBufferedImage.java >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> A developer should be able to implement a custom >>>>>>>>> algorithm to >>>>>>>>> query a resolution variant. >>>>>>>>> >>>>>>>>> It can be done by overriding the getResolutionVariant image: >>>>>>>>> ----------------------- >>>>>>>>> Image mrImage = new MultiResolutionBufferedImage(){ >>>>>>>>> @Override >>>>>>>>> public Image getResolutionVariant(...) { >>>>>>>>> // Custom logic here >>>>>>>>> } >>>>>>>>> }; >>>>>>>>> ----------------------- >>>>>>>>> >>>>>>>>> Or it can be done by using resolution variant choosers so a >>>>>>>>> developer can implement custom resolution variant query: >>>>>>>>> ----------------------- >>>>>>>>> public class MultiResolutionBufferedImage implements >>>>>>>>> MultiResolutionImage{ >>>>>>>>> >>>>>>>>> interface ResolutionVariantChooser{ >>>>>>>>> Image getResolutionVariant(dpi, size,..., List >>>>>>>>> resolutionVariants); >>>>>>>>> } >>>>>>>>> ResolutionVariantChooser TRANSFORM_BASED = null; >>>>>>>>> ResolutionVariantChooser DPI_BASED = null; >>>>>>>>> >>>>>>>>> ResolutionVariantChooser rvChooser; >>>>>>>>> >>>>>>>>> @Override >>>>>>>>> public Image getResolutionVariant(dpi, size,...,) { >>>>>>>>> return rvChooser.getResolutionVariant(dpi, size,..., >>>>>>>>> getResolutionVariants()); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> ----------------------- >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ...jim >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2/13/2014 4:42 AM, Jim Graham wrote: >>>>>>>>>>>> On 2/12/14 5:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>> On 2/8/2014 4:19 AM, Jim Graham wrote: >>>>>>>>>>>>>> The primary thing that I was concerned about was the >>>>>>>>>>>>>> presence of >>>>>>>>>>>>>> integers in the API when Windows uses non-integer multiples >>>>>>>>>>>>> It would make sense to pass real numbers to the >>>>>>>>>>>>> getResolutionVariant() method if the difference between >>>>>>>>>>>>> resolution >>>>>>>>>>>>> variants sizes is 1. >>>>>>>>>>>>> It seems that it is not a common case. >>>>>>>>>>>> >>>>>>>>>>>> I was thinking of other API that is related to this, such as >>>>>>>>>>>> the API >>>>>>>>>>>> that queries the scaling factor from a SurfaceManager. I >>>>>>>>>>>> seem to >>>>>>>>>>>> remember some integer return values in that, but Windows might >>>>>>>>>>>> have >>>>>>>>>>>> the answer 1.4 or 1.8, depending on the screen scaling factor >>>>>>>>>>>> that was >>>>>>>>>>>> determined from the UI. >>>>>>>>>>>> >>>>>>>>>>>> In terms of the getResolutionVariant() method here, those >>>>>>>>>>>> non-integer >>>>>>>>>>>> screen scaling factors don't directly impact this API. But, we >>>>>>>>>>>> have >>>>>>>>>>>> some issues with the use of integers there from other sources: >>>>>>>>>>>> >>>>>>>>>>>> - That API assumes that the caller will determine the pixel >>>>>>>>>>>> size >>>>>>>>>>>> needed, but the actual media choice is determined with >>>>>>>>>>>> different >>>>>>>>>>>> techniques on Mac and Windows so this means that the caller >>>>>>>>>>>> will >>>>>>>>>>>> have >>>>>>>>>>>> to worry about platform conventions. Is that the right >>>>>>>>>>>> tradeoff? >>>>>>>>>>>> >>>>>>>>>>>> - The technique recommended for Mac involves computing the >>>>>>>>>>>> precise >>>>>>>>>>>> size desired using the current transform, which may be a >>>>>>>>>>>> floating >>>>>>>>>>>> point value, so the integer values used in this API are >>>>>>>>>>>> already >>>>>>>>>>>> approximations and there is no documentation on how to >>>>>>>>>>>> generate the >>>>>>>>>>>> proper integer. In particular, the current code in SG2D >>>>>>>>>>>> naively >>>>>>>>>>>> uses >>>>>>>>>>>> a cast to integer to determine the values to supply which >>>>>>>>>>>> means a >>>>>>>>>>>> transformed size of W+0.5 will be truncated to W and the lower >>>>>>>>>>>> resolution image will be used. Does that conform to Mac >>>>>>>>>>>> guidelines? Do >>>>>>>>>>>> they require the truncated size to reach W+1 before the next >>>>>>>>>>>> size is >>>>>>>>>>>> used? Passing in float or double values would sidestep all of >>>>>>>>>>>> that >>>>>>>>>>>> since then the comparisons would be done with full precision, >>>>>>>>>>>> but as >>>>>>>>>>>> long as we can determine a "best practices compatible with all >>>>>>>>>>>> platforms" rule on how to round to integers, then integers >>>>>>>>>>>> are OK >>>>>>>>>>>> there. >>>>>>>>>>>> >>>>>>>>>>>> - The Windows document you cite below suggests that the >>>>>>>>>>>> determination >>>>>>>>>>>> should be made by looking at the Screen DPI and choosing >>>>>>>>>>>> the next >>>>>>>>>>>> higher media variant based on that screen DPI. They do not >>>>>>>>>>>> specify >>>>>>>>>>>> choosing media based on the current transform as is done for >>>>>>>>>>>> Mac. If >>>>>>>>>>>> we stick with supplying values that are used to determine >>>>>>>>>>>> which >>>>>>>>>>>> media >>>>>>>>>>>> to use, then on Windows we should not take the transform into >>>>>>>>>>>> account, >>>>>>>>>>>> but instead query the SurfaceManager for the scale factor and >>>>>>>>>>>> only >>>>>>>>>>>> transform by those values (even if the current transform was >>>>>>>>>>>> manually >>>>>>>>>>>> overridden to identity). >>>>>>>>>>>> >>>>>>>>>>>> There are pros and cons to both approaches. >>>>>>>>>>>> >>>>>>>>>>>> Mac ensures that you are always using the best media for any >>>>>>>>>>>> given >>>>>>>>>>>> render operation. >>>>>>>>>>>> >>>>>>>>>>>> But, Windows ensure more consistency in the face of other >>>>>>>>>>>> scaling. >>>>>>>>>>>> >>>>>>>>>>>> The thing to consider is that if you have a 500x500 image >>>>>>>>>>>> with a >>>>>>>>>>>> 1000x1000 variant and you rendering it at 500x500 and then >>>>>>>>>>>> 501x501, >>>>>>>>>>>> that first jump will be fairly jarring as the scaled version >>>>>>>>>>>> of the >>>>>>>>>>>> 1000x1000 will not look precisely like the original 500x500 >>>>>>>>>>>> did. >>>>>>>>>>>> With >>>>>>>>>>>> @2x images only, this effect is minimized so the advantage of >>>>>>>>>>>> always >>>>>>>>>>>> using "the best media for a given render operation" may >>>>>>>>>>>> outweigh the >>>>>>>>>>>> inconsistency issue. But, on Windows where the media are >>>>>>>>>>>> 1.4x or >>>>>>>>>>>> 1.8x >>>>>>>>>>>> in size, a downscaled image will start to show more >>>>>>>>>>>> interpolation >>>>>>>>>>>> noise and so the balance of the two choices may shift more >>>>>>>>>>>> towards not >>>>>>>>>>>> wanting a jarring shift. >>>>>>>>>>>> >>>>>>>>>>>> We might want one or more of the following: >>>>>>>>>>>> >>>>>>>>>>>> - Developer chooses policy (TX_AWARE, DPI_AWARE, >>>>>>>>>>>> ALWAYS_LARGEST, >>>>>>>>>>>> NONE, >>>>>>>>>>>> PLATFORM) where the last policy would use TX_AWARE on Mac and >>>>>>>>>>>> DPI_AWARE on Windows >>>>>>>>>>>> >>>>>>>>>>>> - We create our own policy and always use it (TX_AWARE? or >>>>>>>>>>>> DPI_AWARE?) >>>>>>>>>>>> >>>>>>>>>>>> - We create our own policy that dynamically chooses one of the >>>>>>>>>>>> above >>>>>>>>>>>> strategies depending on platform or available media or ??? >>>>>>>>>>>> >>>>>>>>>>>> - We could create an optional interface for them to install >>>>>>>>>>>> their >>>>>>>>>>>> own >>>>>>>>>>>> algorithm as well. I think it would work best as a delegate >>>>>>>>>>>> interface >>>>>>>>>>>> that one installs into Image so that it can be used with any >>>>>>>>>>>> image >>>>>>>>>>>> without having to subclass (it wouldn't really have much to do >>>>>>>>>>>> for >>>>>>>>>>>> BufferedImages or VolatileImages, though): >>>>>>>>>>>> >>>>>>>>>>>> class Image { >>>>>>>>>>>> void setResolutionHelper(ImageResolutionHelper foo); >>>>>>>>>>>> List getResolutionVariants(); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> or: >>>>>>>>>>>> >>>>>>>>>>>> class Graphics { >>>>>>>>>>>> void setResolutionHelper(ImageResolutionHelper foo); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> or - anywhere else it could be installed more centrally >>>>>>>>>>>> (per App >>>>>>>>>>>> context)? >>>>>>>>>>>> >>>>>>>>>>>> and the interface would be something like one of these >>>>>>>>>>>> variants: >>>>>>>>>>>> >>>>>>>>>>>> interface ImageResolutionHelper { >>>>>>>>>>>> // This version would prevent substituting a random image: >>>>>>>>>>>> // They have to return an index into the List >>>>>>>>>>>> for that >>>>>>>>>>>> image... >>>>>>>>>>>> public int chooseVariant(Image img, double dpi, number w, >>>>>>>>>>>> number h); >>>>>>>>>>>> >>>>>>>>>>>> or: >>>>>>>>>>>> >>>>>>>>>>>> // This version would allow substituting an arbitrary >>>>>>>>>>>> image: >>>>>>>>>>>> public Image getVariant(Image img, double dpi, number w, >>>>>>>>>>>> number >>>>>>>>>>>> h); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Since they would be in full control of the policy, though, we >>>>>>>>>>>> would >>>>>>>>>>>> unfortunately always have to call this, there would be no more >>>>>>>>>>>> testing >>>>>>>>>>>> in SG2D to see "if" we need to deal with DPI, though >>>>>>>>>>>> perhaps we >>>>>>>>>>>> could >>>>>>>>>>>> document some internal conditions in which we do not call >>>>>>>>>>>> it for >>>>>>>>>>>> common cases (but that would have to be well agreed not to >>>>>>>>>>>> get in >>>>>>>>>>>> the >>>>>>>>>>>> way of reasonable uses of the API and well documented)? >>>>>>>>>>>> >>>>>>>>>>>> Note that we would have to do a security audit to make sure >>>>>>>>>>>> that >>>>>>>>>>>> random image substitution couldn't allow any sort of "screen >>>>>>>>>>>> phishing" >>>>>>>>>>>> exploit. >>>>>>>>>>>> >>>>>>>>>>>> ...jim >>>>>>>>>>>> >>>>>>>>>>>>>> and also what policy they use for choosing scaled images. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't see a mention of taking the current transform into >>>>>>>>>>>>>> account, >>>>>>>>>>>>>> just physical issues like screen DPI and form factor. >>>>>>>>>>>>>> They talk >>>>>>>>>>>>>> about >>>>>>>>>>>>>> resolution plateaus and in their recommendations section >>>>>>>>>>>>>> they >>>>>>>>>>>>>> tell the >>>>>>>>>>>>>> developer to use a particular property that tells them the >>>>>>>>>>>>>> screen >>>>>>>>>>>>>> resolution to figure out which image to load if they are >>>>>>>>>>>>>> loading >>>>>>>>>>>>>> manually. There is no discussion about dynamically loading >>>>>>>>>>>>>> multiple >>>>>>>>>>>>>> versions of the image based on a dynamic program-applied >>>>>>>>>>>>>> transform >>>>>>>>>>>>>> factor as is done on MacOS. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also, they tell developers to draw images to a specific size >>>>>>>>>>>>>> rather >>>>>>>>>>>>>> than using auto-sizing. That begs the question as to how >>>>>>>>>>>>>> they >>>>>>>>>>>>>> interpret a call to draw an image just using a location >>>>>>>>>>>>>> in the >>>>>>>>>>>>>> presence of various DPI factors. >>>>>>>>>>>>> There is an interesting doc that describes how to write >>>>>>>>>>>>> DPI-aware >>>>>>>>>>>>> Win32 applications: >>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464646%28v=vs.85%29.aspx >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It is suggested to handle WM_DPICHANGED message, >>>>>>>>>>>>> load the >>>>>>>>>>>>> graphic >>>>>>>>>>>>> that has slightly greater resolution to the current DPI >>>>>>>>>>>>> and use >>>>>>>>>>>>> StretchBlt >>>>>>>>>>>>> to scale down the image. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2/7/14 3:00 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> On 1/22/2014 6:40 AM, Jim Graham wrote: >>>>>>>>>>>>>>>> Hi Alexander, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Before we get too far down the road on this API, I >>>>>>>>>>>>>>>> think we >>>>>>>>>>>>>>>> understand >>>>>>>>>>>>>>>> the way in which MacOS processes multi-resolution >>>>>>>>>>>>>>>> images for >>>>>>>>>>>>>>>> HiDPI >>>>>>>>>>>>>>>> screens, but have we investigated the processes that >>>>>>>>>>>>>>>> Windows >>>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>>> under Windows 8? My impression is that Windows 8 has >>>>>>>>>>>>>>>> included a >>>>>>>>>>>>>>>> number of new techniques for dealing with the high >>>>>>>>>>>>>>>> resolution >>>>>>>>>>>>>>>> displays >>>>>>>>>>>>>>>> that it will run on in the Windows tablet and mobile >>>>>>>>>>>>>>>> industries >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> that these will also come into play as 4K displays >>>>>>>>>>>>>>>> (already >>>>>>>>>>>>>>>> available) >>>>>>>>>>>>>>>> become more common on the desktop. We should make sure >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> what we >>>>>>>>>>>>>>>> come up with here can provide native compatibility with >>>>>>>>>>>>>>>> either >>>>>>>>>>>>>>>> platform's policies and standard practices. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If you've investigated the MS policies I'd like to see a >>>>>>>>>>>>>>>> summary so >>>>>>>>>>>>>>>> that we can consider them as we review this API... >>>>>>>>>>>>>>> There is the Windows Guidelines for scaling to pixel >>>>>>>>>>>>>>> density: >>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> which says that Windows has automatic resource loading >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> supports >>>>>>>>>>>>>>> three version of images scaling (100%, 140%, and 180%) >>>>>>>>>>>>>>> -------------------------------- >>>>>>>>>>>>>>> Without scaling, as the pixel density of a display device >>>>>>>>>>>>>>> increases, the >>>>>>>>>>>>>>> physical sizes of objects on screen get smaller. >>>>>>>>>>>>>>> When UI would otherwise be too small to touch and when text >>>>>>>>>>>>>>> gets >>>>>>>>>>>>>>> too >>>>>>>>>>>>>>> small to read, >>>>>>>>>>>>>>> Windows scales the system and app UI to one of the >>>>>>>>>>>>>>> following >>>>>>>>>>>>>>> scaling >>>>>>>>>>>>>>> plateaus: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1.0 (100%, no scaling is applied) >>>>>>>>>>>>>>> 1.4 (140% scaling) >>>>>>>>>>>>>>> 1.8 (180% scaling) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Windows determines which scaling plateau to use based on >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> physical >>>>>>>>>>>>>>> screen size, the screen resolution, the DPI of the >>>>>>>>>>>>>>> screen, and >>>>>>>>>>>>>>> form >>>>>>>>>>>>>>> factor. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Use resource loading for bitmap images in the app >>>>>>>>>>>>>>> package For >>>>>>>>>>>>>>> bitmap >>>>>>>>>>>>>>> images stored >>>>>>>>>>>>>>> in the app package, provide a separate image for each >>>>>>>>>>>>>>> scaling >>>>>>>>>>>>>>> factor(100%, 140%, and 180%), >>>>>>>>>>>>>>> and name your image files using the "scale" naming >>>>>>>>>>>>>>> convention >>>>>>>>>>>>>>> described >>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>> Windows loads the right image for the current scale >>>>>>>>>>>>>>> automatically. >>>>>>>>>>>>>>> -------------------------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The image name convention for the various scales is: >>>>>>>>>>>>>>> images/logo.scale-100.png >>>>>>>>>>>>>>> images/logo.scale-140.png >>>>>>>>>>>>>>> images/logo.scale-180.png >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The 'ms-appx:///images/logo.png' uri is used to load the >>>>>>>>>>>>>>> image >>>>>>>>>>>>>>> in an >>>>>>>>>>>>>>> application. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If we want to support this in the same way as it is done >>>>>>>>>>>>>>> for Mac >>>>>>>>>>>>>>> OS X >>>>>>>>>>>>>>> the WToolkit should return MultiResolution image in >>>>>>>>>>>>>>> case if >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> loaded image has .scale-* qualifiers. >>>>>>>>>>>>>>> The Graphics class can request an image with necessary >>>>>>>>>>>>>>> resolution >>>>>>>>>>>>>>> from the MultiResolution image. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It seems that nothing should be changed in the >>>>>>>>>>>>>>> MultiResolution >>>>>>>>>>>>>>> interface in this case. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 1/14/14 2:54 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8029339 >>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.00 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This is a proposal to introduce an API that allows to >>>>>>>>>>>>>>>>> create a >>>>>>>>>>>>>>>>> custom >>>>>>>>>>>>>>>>> multi resolution image. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I. It seems reasonable that the API should provide two >>>>>>>>>>>>>>>>> basic >>>>>>>>>>>>>>>>> operations: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1. Get the resolution variant based on the requested >>>>>>>>>>>>>>>>> image >>>>>>>>>>>>>>>>> width and >>>>>>>>>>>>>>>>> height: >>>>>>>>>>>>>>>>> - Image getResolutionVariant(int width, int height) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Usually the system provides the scale factor which >>>>>>>>>>>>>>>>> represents >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> number of pixels corresponding to each linear unit on the >>>>>>>>>>>>>>>>> display. >>>>>>>>>>>>>>>>> However, it has sense to combine the scale factor and >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>>> transformations to get the actual image size to be >>>>>>>>>>>>>>>>> displayed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2. Get all provided resolution variants: >>>>>>>>>>>>>>>>> - List getResolutionVariants() >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There are several uses cases: >>>>>>>>>>>>>>>>> - Create a new multi-resolution image based on the >>>>>>>>>>>>>>>>> given >>>>>>>>>>>>>>>>> multi-resolution image. >>>>>>>>>>>>>>>>> - Pass to the native system the multi-resolution >>>>>>>>>>>>>>>>> image. For >>>>>>>>>>>>>>>>> example, >>>>>>>>>>>>>>>>> a use can set to the system the custom multi-resolution >>>>>>>>>>>>>>>>> cursor. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> II. There are some possible ways where the new API can be >>>>>>>>>>>>>>>>> added >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1. java.awt.Image. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The 2 new methods can be added to the Image class. >>>>>>>>>>>>>>>>> A user >>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>> override >>>>>>>>>>>>>>>>> the getResolutionVariant() and getResolutionVariants() >>>>>>>>>>>>>>>>> methods to >>>>>>>>>>>>>>>>> provide the resolution variants >>>>>>>>>>>>>>>>> or there can be default implementations of these >>>>>>>>>>>>>>>>> methods >>>>>>>>>>>>>>>>> if a >>>>>>>>>>>>>>>>> user >>>>>>>>>>>>>>>>> puts resolution variants >>>>>>>>>>>>>>>>> to the list in the sorted order. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> To check that the image has resolution variants the >>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>> statement can be used: >>>>>>>>>>>>>>>>> image.getResolutionVariants().size() >>>>>>>>>>>>>>>>> != 1 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The disadvantage is that there is an overhead that the >>>>>>>>>>>>>>>>> Image >>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>> should contain the List object and not all >>>>>>>>>>>>>>>>> images can have resolution variants. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2. Introduce new MultiResolutionImage interface. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A user should extend Image class and implement the >>>>>>>>>>>>>>>>> MultiResolutionImage interface. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For example: >>>>>>>>>>>>>>>>> --------------------- >>>>>>>>>>>>>>>>> public class CustomMultiResolutionImage extends >>>>>>>>>>>>>>>>> BufferedImage >>>>>>>>>>>>>>>>> implements MultiResolutionImage { >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Image highResolutionImage; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> public CustomMultiResolutionImage(BufferedImage >>>>>>>>>>>>>>>>> baseImage, >>>>>>>>>>>>>>>>> BufferedImage highResolutionImage) { >>>>>>>>>>>>>>>>> super(baseImage.getWidth(), >>>>>>>>>>>>>>>>> baseImage.getHeight(), >>>>>>>>>>>>>>>>> baseImage.getType()); >>>>>>>>>>>>>>>>> this.highResolutionImage = highResolutionImage; >>>>>>>>>>>>>>>>> Graphics g = getGraphics(); >>>>>>>>>>>>>>>>> g.drawImage(baseImage, 0, 0, null); >>>>>>>>>>>>>>>>> g.dispose(); >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>>>> public Image getResolutionVariant(int width, int >>>>>>>>>>>>>>>>> height) { >>>>>>>>>>>>>>>>> return ((width <= getWidth() && height <= >>>>>>>>>>>>>>>>> getHeight())) >>>>>>>>>>>>>>>>> ? this : highResolutionImage; >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>>>> public List getResolutionVariants() { >>>>>>>>>>>>>>>>> return Arrays.asList(this, >>>>>>>>>>>>>>>>> highResolutionImage); >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> --------------------- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The current fix adds the MultiResolutionImage interface >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> public >>>>>>>>>>>>>>>>> resolution variant rendering hints. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From james.graham at oracle.com Thu Apr 24 22:17:42 2014 From: james.graham at oracle.com (Jim Graham) Date: Thu, 24 Apr 2014 15:17:42 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: <533E9D42.10409@oracle.com> References: <52D51764.8020103@oracle.com> <52DF2F98.3030503@oracle.com> <52F4BCEB.9040702@oracle.com> <52F5782A.9060300@oracle.com> <52FB7E3E.6050000@oracle.com> <52FC14EC.9080503@oracle.com> <53037D3D.80709@oracle.com> <5307E71E.50607@oracle.com> <530F3592.40600@oracle.com> <532B00AD.1000704@oracle.com> <532B7EC5.9000206@oracle.com> <532C4DD7.1080804@oracle.com> <532CD202.5070508@oracle.com> <53302A8E.6090107@oracle.com> <53343914.6090004@oracle.com> <533C8DDB.5000406@oracle.com> <533E9D42.10409@oracle.com> Message-ID: <53598D86.5020607@oracle.com> Hi Alexandr, I asked for who was requesting these facilities and you responded with the solution you are planning to provide. I don't care what the solution looks like if we have nobody asking for the feature - I am asking who is asking for these capabilities? ...jim On 4/4/14 4:53 AM, Alexander Scherbatiy wrote: > On 4/3/2014 2:23 AM, Jim Graham wrote: >> Hi Alexandr, >> >> The back and forth is getting confusing here, so I thought I'd try to >> summarize and start fresh(ish): >> >> 1. We need to support @2x internally for MacOS compatibility (done). >> >> 2. We will need to support _DPI images for Win-DPI compatibility (TBD). >> >> 3. Customers may have their own collection of images to bundle >> together into an MR image (working on that here). What is the push >> for this? Is this simply parity with Mac interfaces? > > ---------- > Image[] resolutionVariants = // get sorted by sizes array of > resolution variants; > Image mrImage = > Toolkit.getDefaultToolkit().createMRImage(baseImageIndex, > resolutionVariants); > ---------- > > Here is the proposed patch: > http://cr.openjdk.java.net/~alexsch/8029339/webrev.04/ > >> 4. Customers may want to synthetically generate images at arbitrary >> resolutions (a variation that is impacting this solution). What is >> the push for this? > ---------- > Image mrImage = > Toolkit.getDefaultToolkit().createMRImage(baseImageWidth, baseImageHeight, > new float[][]{{100, 100}, {150, 150}, {200, 200}}, // > resolution variants sizes > (rvWidth, rvHeight) -> { /* generate a resolution > variant */ }); > ---------- > >> >> 5. I'm guessing that customers might want to override the logic to >> choose from among multiple resolutions. That came from me based on >> seeing Mac and Win using different selection logic and our history of >> developers split between those wanting cross-platform consistency and >> those wanting consistency with native apps on each platform. Also, >> the needs of an animator may differ from the needs of a >> resolution-settable-document editor as to how dynamically the images >> shift between resolution variants. > ---------- > Image[] resolutionVariants = // get sorted by sizes array of > resolution variants; > Image mrImage = ImageResolutionHelper.createMRImage( > (rvWidth, rvHeight, resolutionVariants) -> { /*use a > custom logic to choose a resolution variant from an array of images*/}, > (logicalDPI, baseImageSize, destImageSize) -> > destImageSize, // calculate the custom aware resolution variant size > baseImageIndex, resolutionVariants); > ---------- > > or just extend the CustomMultiResolutionImage which has Image as the > parent class: > > -------------------- > public class CustomMultiResolutionImage extends > AbstractMultiResolutionImage { > > @Override > public Image getResolutionVariant(float logicalDPIX, float > logicalDPIY, > float baseImageWidth, float baseImageHeight, > float destImageWidth, float destImageHeight) { > // return a resolution variant based on the given logical DPI, > // base image size, or destination image size > } > > @Override > public List getResolutionVariants() { > // return a list of resolution variants > } > > @Override > protected Image getBaseImage() { > // return the base image > } > } > -------------------- >> >> Is that a fair summary of all of the considerations so far, or did I >> miss something? > I think it should cover the main needs. > > Thanks, > Alexandr. >> >> ...jim >> >> On 3/27/14 7:43 AM, Alexander Scherbatiy wrote: >>> >>> Below are some thoughts about TK.createMRImage(...) method >>> >>> On 3/24/2014 4:52 PM, Alexander Scherbatiy wrote: >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.03/ >>>> >>>> - baseImageWidth/Height arguments are added to the >>>> getResolutionVariant(...) method >>>> - dest image sizes are reverted to included DPI scale >>>> - AbstractMultiResolutionImage is added. It needs only to implement >>>> only 3 methods from the AbstractMultiResolutionImage class >>>> to create a custom multi-resolution image. For example: >>>> >>>> On 3/22/2014 3:57 AM, Jim Graham wrote: >>>>> >>>>> Your code example below can be expressed as an implementation of the >>>>> single-method, lambda-compatible interface that expresses just the >>>>> getRV() method. They could easily do: >>>>> >>>>> final Image baseImage = ...; >>>>> TK.createMRImage(new RVInterface() { >>>>> public Image getRV(...) { >>>>> // calculate rvWidth and rvHeight >>>>> // look up rvWidth/rvHeight in a database of images >>>>> // possibly contruct a new image >>>>> return rvImage; >>>>> } >>>>> }, baseImage); >>>>> >>> The RVInterface mixes the logic that construct an image and >>> chooses the necessary resolution variant. >>> It is ok if a developer always implements this interface. If it >>> needs to have DPI/Transform/Platform aware RVInterface the image >>> construction logic should be separated. >>> >>> Does TK.createMRImage() method implies that Platform aware logic >>> should be used for a resolution-variant choosing? >>> If so, may be general createMRImage() can be placed in the >>> ImageResolutionHelper. >>>>> The main issue I see is if you might want the newly constructed >>>>> variants to appear in the List returned from the getVariants() >>>>> method. I'm not sure what value that would have beyond simply >>>>> returning the base media that the object uses from which to construct >>>>> its variants...? >>> >>> It can be solved by using something like array of image sizes or >>> other seeds and a mapper that can create an image from the given seed. >>> >>> It can look like: >>> ------------------------- >>> public class ImageResolutionHelper { >>> public interface RVChooser { >>> >>> public Image getRV( >>> float logicalDPIX, float logicalDPIY, >>> float baseImageWidth, float baseImageHeight, >>> float destImageWidth, float destImageHeight, >>> final Image... resolutionVariants); >>> } >>> >>> public static final RVChooser DPI_AWARE = ...; >>> public static final RVChooser TRANSFORM_AWARE = ...; >>> >>> // resolutionVariants is an array of sorted by width/height images >>> static Image createMRImage(final RVChooser rvChooser, >>> final int baseImageIndex, final Image... >>> resolutionVariants) { ... } >>> >>> // sorted by width/height images should be generated from seeds >>> static Image createMRImage(final RVChooser rvChooser, >>> final Type baseImageSeed, final Function >>> mapper, final Type... rvSeeds) {...} >>> } >>> >>> public abstract class Toolkit { >>> public abstract Image createMRImage(int baseImageIndex, Image... >>> resolutionVariants); // Platform aware rv chooser is used >>> public abstract RVChooser getPlatformRVChooser() ; >>> } >>> -------------------------- >>> Thanks, >>> Alexandr. >>> >>>>> >>>>>> I think it is better to provide both the MultiResolutionImage >>>>>> and >>>>>> its implementation based on the given resolution variants array. >>>>> >>>>> It occurs to me that even if we don't go with a lambda-factory-based >>>>> approach like what I'm describing, it might make sense to provide a >>>>> baseMR implementation that they can subclass to keep them from trying >>>>> to subclass off of BufferedImage instead. I really would like to >>>>> avoid "custom MR images are subclasses of BufImg" if we can as I >>>>> think the mix of concepts is a little jarring... >>>>> >>>>> ...jim >>>>> >>>>>> The implementation could look like: >>>>>> --------------------------------- >>>>>> public class CustomMultiResolutionImage extends Image implements >>>>>> MultiResolutionImage { >>>>>> >>>>>> int baseImageIndex; >>>>>> Image[] resolutionVariants; >>>>>> >>>>>> public CustomMultiResolutionImage(int baseImageIndex, >>>>>> Image... resolutionVariants) { >>>>>> this.baseImageIndex = baseImageIndex; >>>>>> this.resolutionVariants = resolutionVariants; >>>>>> } >>>>>> >>>>>> @Override >>>>>> public int getWidth(ImageObserver observer) { >>>>>> return getBaseImage().getWidth(null); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public int getHeight(ImageObserver observer) { >>>>>> return getBaseImage().getHeight(null); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public ImageProducer getSource() { >>>>>> return getBaseImage().getSource(); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public Graphics getGraphics() { >>>>>> return getBaseImage().getGraphics(); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public Object getProperty(String name, ImageObserver observer) { >>>>>> return getBaseImage().getProperty(name, observer); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>>> logicalDPIY, >>>>>> float destinationImageWidth, float >>>>>> destinationImageHeight) { >>>>>> // calculate resolution variant width/height >>>>>> return getResolutionVariant(rvWidth, rvHeight); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public List getResolutionVariants() { >>>>>> return Arrays.asList(resolutionVariants); >>>>>> } >>>>>> >>>>>> private Image getResolutionVariant(float rvWidth, float >>>>>> rvHeight) { >>>>>> // return a resolution variant based on the given width and >>>>>> height >>>>>> } >>>>>> >>>>>> private Image getBaseImage() { >>>>>> return resolutionVariants[baseImageIndex]; >>>>>> } >>>>>> } >>>>>> --------------------------------- >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> >>>>>>> Then we provide one of these from TK.get/createImage() when the >>>>>>> platform detects @2x, or Win8-style variants. >>>>>>> >>>>>>> For custom images we provide TK.createMRImage(lambda getRV, Image >>>>>>> variants...) and TK.createMRImage(Image variants...); >>>>>>> >>>>>>> Since the get method is just bookkeeping, I don't see them >>>>>>> needing to override it, so the getRV() method is really the only >>>>>>> thing >>>>>>> they might want to override, and we can tie into the new Lambda >>>>>>> capabilities by making a single-method interface for it that they >>>>>>> supply in a factory method. >>>>>>> >>>>>>> I realize that the interface you created is more fundamentally >>>>>>> OO, but >>>>>>> the Image class has always been special in this regard in the AWT >>>>>>> ecosystem (in so far as we do not support someone implementing their >>>>>>> own Image subclass even though it is technically possible). >>>>>>> Because of >>>>>>> this special nature of Image, we end up with the situation that if >>>>>>> someone were given a need to create a subclass of Image, then they >>>>>>> would turn to BufImg as their superclass even though BufImg is >>>>>>> essentially an implementation-specific leaf node on the Image class >>>>>>> hierarchy. This approach with a factory method to create an >>>>>>> internal >>>>>>> subclass of the new MRI class mirrors the existing cases of Image >>>>>>> objects that come from factories as well. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> >>>>>>> On 3/20/14 7:52 AM, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the updated version of the fix: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.01/ >>>>>>>> >>>>>>>> - The "getResolutionVariant(int width, int height)" method from >>>>>>>> MultiResolutionImage class is changed to >>>>>>>> Image getResolutionVariant(float logicalDPIX, float >>>>>>>> logicalDPIY, >>>>>>>> float width, float height, AffineTransform transform); >>>>>>>> >>>>>>>> - sun.awt.image.ImageResolutionHelper class is added. The >>>>>>>> sun.awt.image.MultiResolutionToolkitImage and >>>>>>>> sun.awt.image.MultiResolutionBufferedImage classes are used >>>>>>>> PLATFORM ImageResolutionHelper. >>>>>>>> >>>>>>>> The MultiResolutionImage interface implementation could look >>>>>>>> like: >>>>>>>> ------------------------------ >>>>>>>> public class CustomMultiResolutionImage extends BufferedImage >>>>>>>> implements >>>>>>>> MultiResolutionImage { >>>>>>>> >>>>>>>> private final Image[] resolutionVariants; >>>>>>>> >>>>>>>> public CustomMultiResolutionImage(int baseIndex, Image... >>>>>>>> images) { >>>>>>>> super(images[baseIndex].getWidth(null), >>>>>>>> images[baseIndex].getHeight(null), >>>>>>>> BufferedImage.TYPE_INT_RGB); >>>>>>>> this.resolutionVariants = images; >>>>>>>> Graphics g = getGraphics(); >>>>>>>> g.drawImage(images[baseIndex], 0, 0, null); >>>>>>>> g.dispose(); >>>>>>>> } >>>>>>>> >>>>>>>> @Override >>>>>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>>>>> logicalDPIY, >>>>>>>> float width, float height, AffineTransform >>>>>>>> transform) { >>>>>>>> return getResolutionVariant(logicalDPIX * width, >>>>>>>> logicalDPIY * >>>>>>>> height); >>>>>>>> } >>>>>>>> >>>>>>>> @Override >>>>>>>> public List getResolutionVariants() { >>>>>>>> return Arrays.asList(resolutionVariants); >>>>>>>> } >>>>>>>> >>>>>>>> public Image getResolutionVariant(double width, double >>>>>>>> height) { >>>>>>>> for (Image image : resolutionVariants) { >>>>>>>> if (width <= image.getWidth(null) && height <= >>>>>>>> image.getHeight(null)) { >>>>>>>> return image; >>>>>>>> } >>>>>>>> } >>>>>>>> return this; >>>>>>>> } >>>>>>>> } >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 2/27/2014 4:54 PM, Alexander Scherbatiy wrote: >>>>>>>>> On 2/22/2014 3:54 AM, Jim Graham wrote: >>>>>>>>>> Hi Alexandr, >>>>>>>>>> >>>>>>>>>> On 2/18/14 7:33 AM, Alexander Scherbatiy wrote: >>>>>>>>>>> Hi Jim, >>>>>>>>>>> >>>>>>>>>>> Let's divide the discussion into two part. >>>>>>>>>>> >>>>>>>>>>> 1. Where it is better to hold resolution variants? >>>>>>>>>>> Putting resolution variants in Image class brings some >>>>>>>>>>> questions like: >>>>>>>>>>> - Some type of images do not need to have resolution variants >>>>>>>>>>> - Should resolution variants have the same type as the base >>>>>>>>>>> image? >>>>>>>>>>> - getResolutionVariants() method can return copy of the >>>>>>>>>>> original >>>>>>>>>>> list >>>>>>>>>>> so add/removeRV methods should be also added. >>>>>>>>>>> >>>>>>>>>>> There are pros and cons for placing resolution variants to >>>>>>>>>>> Image >>>>>>>>>>> class or to a separate intreface. >>>>>>>>>> >>>>>>>>>> I agree that this could be a separate interface. In my examples >>>>>>>>>> below I was just sticking them inside an "Image{}" to show where >>>>>>>>>> they >>>>>>>>>> lived in the set of involved objects, not a specific >>>>>>>>>> recommendation >>>>>>>>>> that they actually be new methods on the base class itself. I >>>>>>>>>> probably should have put a comment there about that. >>>>>>>>>> >>>>>>>>>> With respect to add/remove - that is assuming a need for manual >>>>>>>>>> construction of an image set, right? Forgive me if I'm >>>>>>>>>> forgetting >>>>>>>>>> something, but I seem to recall that manual Multi-Res images was >>>>>>>>>> proposed as a way for developers to introduce @2x support >>>>>>>>>> themselves, >>>>>>>>>> but if we are internally managing @2x and -DPI variants for them, >>>>>>>>>> then I'm not sure if there is actual developer need to manually >>>>>>>>>> construct their own. Am I forgetting something? >>>>>>>>> The NSImage has addRepresentation/removeRepresentation >>>>>>>>> methods to >>>>>>>>> work with image representations on Mac OS X. >>>>>>>>> The java.awt.Image class should provide similar >>>>>>>>> functionality to >>>>>>>>> have the possibilities as Cocoa on HiDPI displays. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 2. Using scale factor/image sizes/scaled image sizes to >>>>>>>>>>> retreive a >>>>>>>>>>> resolution variant. >>>>>>>>>>> >>>>>>>>>>> May be it is better to have a structure that provide all >>>>>>>>>>> necessary >>>>>>>>>>> information to query the resolution variant: scale factor, >>>>>>>>>>> draw area >>>>>>>>>>> width/height, transformed area width/height? >>>>>>>>>>> >>>>>>>>>>> For example: >>>>>>>>>>> --------------------- >>>>>>>>>>> public interface MultiResolutionImage { >>>>>>>>>>> >>>>>>>>>>> interface DrawAreaInfo { >>>>>>>>>>> >>>>>>>>>>> float getScaleFactor(); >>>>>>>>>>> float getAreaWidth(); >>>>>>>>>>> float getAreaHeight(); >>>>>>>>>>> float getTransformedAreaWidth(); >>>>>>>>>>> float getTransformedAreaHeight(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> public Image getResolutionVariant(DrawAreaInfo >>>>>>>>>>> drawAreaInfo) ; >>>>>>>>>>> public List getResolutionVariants(); >>>>>>>>>>> } >>>>>>>>>>> --------------------- >>>>>>>>>> >>>>>>>>>> The problem with a constructor is that this is something that is >>>>>>>>>> (potentially) done on every drawImage() call, which means we are >>>>>>>>>> inviting GC into the equation. If we can come up with a simple >>>>>>>>>> "just >>>>>>>>>> a couple/3/4 numbers" way to embed that data into a method call >>>>>>>>>> argument list then we can make this lighter weight. >>>>>>>>>> >>>>>>>>>> What about simply having floating point (double) dimensions on >>>>>>>>>> the >>>>>>>>>> rendered size >>>>>>>>> There should be a way to choose a resolution variant >>>>>>>>> based on >>>>>>>>> requested drawing size or transformed drawing size. >>>>>>>>> At least a current transformation should be included too. >>>>>>>>>> plus a single floating point "logical DPI" for the screen? >>>>>>>>> There is the ID2D1Factory::GetDesktopDpi method which returns >>>>>>>>> dpiX and dpiY. >>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316 >>>>>>>>> >>>>>>>>> That means that logicalDPIX/Y can have different values. >>>>>>>>> At least it is described in the >>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/ff684173 >>>>>>>>> "To get the DPI setting, call the ID2D1Factory::GetDesktopDpi >>>>>>>>> method. The DPI is returned as two floating-point values, one for >>>>>>>>> the >>>>>>>>> x-axis and one for the y-axis. In theory, these values can differ. >>>>>>>>> Calculate a separate scaling factor for each axis." >>>>>>>>> >>>>>>>>> The getResolutionVariant method could look like: >>>>>>>>> -------------------------------------- >>>>>>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>>>>>> logicalDPIY, >>>>>>>>> float widthX, float widthY, AffineTransform >>>>>>>>> transform); >>>>>>>>> -------------------------------------- >>>>>>>>> >>>>>>>>>> If the image is known (either passed as an argument or the >>>>>>>>>> method is >>>>>>>>>> called on the image), then it can provide the original WH. >>>>>>>>>> >>>>>>>>>>> The MultiResolutionImage default implementation could allow >>>>>>>>>>> to use >>>>>>>>>>> different strategies like scale factor/transfom/OS based >>>>>>>>>>> to query a resolution variant. The OS based strategy can be >>>>>>>>>>> used by >>>>>>>>>>> default. >>>>>>>>>> >>>>>>>>>> For Mac policy, all we need is the transformed dimensions, which >>>>>>>>>> can >>>>>>>>>> be passed in as FP for generality. For Windows policy, all we >>>>>>>>>> need >>>>>>>>>> is logical DPI for the screen. What other information would we >>>>>>>>>> need, or would an algorithm like to use, that can't be computed >>>>>>>>>> from >>>>>>>>>> those 2 pieces? >>>>>>>>> The aim is to provide a base class that can be used to >>>>>>>>> create a >>>>>>>>> MultiResolutionImage like: >>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/diff/ae53ebce5fa3/src/share/classes/sun/awt/image/MultiResolutionBufferedImage.java >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> A developer should be able to implement a custom algorithm to >>>>>>>>> query a resolution variant. >>>>>>>>> >>>>>>>>> It can be done by overriding the getResolutionVariant image: >>>>>>>>> ----------------------- >>>>>>>>> Image mrImage = new MultiResolutionBufferedImage(){ >>>>>>>>> @Override >>>>>>>>> public Image getResolutionVariant(...) { >>>>>>>>> // Custom logic here >>>>>>>>> } >>>>>>>>> }; >>>>>>>>> ----------------------- >>>>>>>>> >>>>>>>>> Or it can be done by using resolution variant choosers so a >>>>>>>>> developer can implement custom resolution variant query: >>>>>>>>> ----------------------- >>>>>>>>> public class MultiResolutionBufferedImage implements >>>>>>>>> MultiResolutionImage{ >>>>>>>>> >>>>>>>>> interface ResolutionVariantChooser{ >>>>>>>>> Image getResolutionVariant(dpi, size,..., List >>>>>>>>> resolutionVariants); >>>>>>>>> } >>>>>>>>> ResolutionVariantChooser TRANSFORM_BASED = null; >>>>>>>>> ResolutionVariantChooser DPI_BASED = null; >>>>>>>>> >>>>>>>>> ResolutionVariantChooser rvChooser; >>>>>>>>> >>>>>>>>> @Override >>>>>>>>> public Image getResolutionVariant(dpi, size,...,) { >>>>>>>>> return rvChooser.getResolutionVariant(dpi, size,..., >>>>>>>>> getResolutionVariants()); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> ----------------------- >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ...jim >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2/13/2014 4:42 AM, Jim Graham wrote: >>>>>>>>>>>> On 2/12/14 5:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>> On 2/8/2014 4:19 AM, Jim Graham wrote: >>>>>>>>>>>>>> The primary thing that I was concerned about was the >>>>>>>>>>>>>> presence of >>>>>>>>>>>>>> integers in the API when Windows uses non-integer multiples >>>>>>>>>>>>> It would make sense to pass real numbers to the >>>>>>>>>>>>> getResolutionVariant() method if the difference between >>>>>>>>>>>>> resolution >>>>>>>>>>>>> variants sizes is 1. >>>>>>>>>>>>> It seems that it is not a common case. >>>>>>>>>>>> >>>>>>>>>>>> I was thinking of other API that is related to this, such as >>>>>>>>>>>> the API >>>>>>>>>>>> that queries the scaling factor from a SurfaceManager. I >>>>>>>>>>>> seem to >>>>>>>>>>>> remember some integer return values in that, but Windows might >>>>>>>>>>>> have >>>>>>>>>>>> the answer 1.4 or 1.8, depending on the screen scaling factor >>>>>>>>>>>> that was >>>>>>>>>>>> determined from the UI. >>>>>>>>>>>> >>>>>>>>>>>> In terms of the getResolutionVariant() method here, those >>>>>>>>>>>> non-integer >>>>>>>>>>>> screen scaling factors don't directly impact this API. But, we >>>>>>>>>>>> have >>>>>>>>>>>> some issues with the use of integers there from other sources: >>>>>>>>>>>> >>>>>>>>>>>> - That API assumes that the caller will determine the pixel >>>>>>>>>>>> size >>>>>>>>>>>> needed, but the actual media choice is determined with >>>>>>>>>>>> different >>>>>>>>>>>> techniques on Mac and Windows so this means that the caller >>>>>>>>>>>> will >>>>>>>>>>>> have >>>>>>>>>>>> to worry about platform conventions. Is that the right >>>>>>>>>>>> tradeoff? >>>>>>>>>>>> >>>>>>>>>>>> - The technique recommended for Mac involves computing the >>>>>>>>>>>> precise >>>>>>>>>>>> size desired using the current transform, which may be a >>>>>>>>>>>> floating >>>>>>>>>>>> point value, so the integer values used in this API are already >>>>>>>>>>>> approximations and there is no documentation on how to >>>>>>>>>>>> generate the >>>>>>>>>>>> proper integer. In particular, the current code in SG2D >>>>>>>>>>>> naively >>>>>>>>>>>> uses >>>>>>>>>>>> a cast to integer to determine the values to supply which >>>>>>>>>>>> means a >>>>>>>>>>>> transformed size of W+0.5 will be truncated to W and the lower >>>>>>>>>>>> resolution image will be used. Does that conform to Mac >>>>>>>>>>>> guidelines? Do >>>>>>>>>>>> they require the truncated size to reach W+1 before the next >>>>>>>>>>>> size is >>>>>>>>>>>> used? Passing in float or double values would sidestep all of >>>>>>>>>>>> that >>>>>>>>>>>> since then the comparisons would be done with full precision, >>>>>>>>>>>> but as >>>>>>>>>>>> long as we can determine a "best practices compatible with all >>>>>>>>>>>> platforms" rule on how to round to integers, then integers >>>>>>>>>>>> are OK >>>>>>>>>>>> there. >>>>>>>>>>>> >>>>>>>>>>>> - The Windows document you cite below suggests that the >>>>>>>>>>>> determination >>>>>>>>>>>> should be made by looking at the Screen DPI and choosing the >>>>>>>>>>>> next >>>>>>>>>>>> higher media variant based on that screen DPI. They do not >>>>>>>>>>>> specify >>>>>>>>>>>> choosing media based on the current transform as is done for >>>>>>>>>>>> Mac. If >>>>>>>>>>>> we stick with supplying values that are used to determine which >>>>>>>>>>>> media >>>>>>>>>>>> to use, then on Windows we should not take the transform into >>>>>>>>>>>> account, >>>>>>>>>>>> but instead query the SurfaceManager for the scale factor and >>>>>>>>>>>> only >>>>>>>>>>>> transform by those values (even if the current transform was >>>>>>>>>>>> manually >>>>>>>>>>>> overridden to identity). >>>>>>>>>>>> >>>>>>>>>>>> There are pros and cons to both approaches. >>>>>>>>>>>> >>>>>>>>>>>> Mac ensures that you are always using the best media for any >>>>>>>>>>>> given >>>>>>>>>>>> render operation. >>>>>>>>>>>> >>>>>>>>>>>> But, Windows ensure more consistency in the face of other >>>>>>>>>>>> scaling. >>>>>>>>>>>> >>>>>>>>>>>> The thing to consider is that if you have a 500x500 image >>>>>>>>>>>> with a >>>>>>>>>>>> 1000x1000 variant and you rendering it at 500x500 and then >>>>>>>>>>>> 501x501, >>>>>>>>>>>> that first jump will be fairly jarring as the scaled version >>>>>>>>>>>> of the >>>>>>>>>>>> 1000x1000 will not look precisely like the original 500x500 >>>>>>>>>>>> did. >>>>>>>>>>>> With >>>>>>>>>>>> @2x images only, this effect is minimized so the advantage of >>>>>>>>>>>> always >>>>>>>>>>>> using "the best media for a given render operation" may >>>>>>>>>>>> outweigh the >>>>>>>>>>>> inconsistency issue. But, on Windows where the media are >>>>>>>>>>>> 1.4x or >>>>>>>>>>>> 1.8x >>>>>>>>>>>> in size, a downscaled image will start to show more >>>>>>>>>>>> interpolation >>>>>>>>>>>> noise and so the balance of the two choices may shift more >>>>>>>>>>>> towards not >>>>>>>>>>>> wanting a jarring shift. >>>>>>>>>>>> >>>>>>>>>>>> We might want one or more of the following: >>>>>>>>>>>> >>>>>>>>>>>> - Developer chooses policy (TX_AWARE, DPI_AWARE, >>>>>>>>>>>> ALWAYS_LARGEST, >>>>>>>>>>>> NONE, >>>>>>>>>>>> PLATFORM) where the last policy would use TX_AWARE on Mac and >>>>>>>>>>>> DPI_AWARE on Windows >>>>>>>>>>>> >>>>>>>>>>>> - We create our own policy and always use it (TX_AWARE? or >>>>>>>>>>>> DPI_AWARE?) >>>>>>>>>>>> >>>>>>>>>>>> - We create our own policy that dynamically chooses one of the >>>>>>>>>>>> above >>>>>>>>>>>> strategies depending on platform or available media or ??? >>>>>>>>>>>> >>>>>>>>>>>> - We could create an optional interface for them to install >>>>>>>>>>>> their >>>>>>>>>>>> own >>>>>>>>>>>> algorithm as well. I think it would work best as a delegate >>>>>>>>>>>> interface >>>>>>>>>>>> that one installs into Image so that it can be used with any >>>>>>>>>>>> image >>>>>>>>>>>> without having to subclass (it wouldn't really have much to do >>>>>>>>>>>> for >>>>>>>>>>>> BufferedImages or VolatileImages, though): >>>>>>>>>>>> >>>>>>>>>>>> class Image { >>>>>>>>>>>> void setResolutionHelper(ImageResolutionHelper foo); >>>>>>>>>>>> List getResolutionVariants(); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> or: >>>>>>>>>>>> >>>>>>>>>>>> class Graphics { >>>>>>>>>>>> void setResolutionHelper(ImageResolutionHelper foo); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> or - anywhere else it could be installed more centrally (per >>>>>>>>>>>> App >>>>>>>>>>>> context)? >>>>>>>>>>>> >>>>>>>>>>>> and the interface would be something like one of these >>>>>>>>>>>> variants: >>>>>>>>>>>> >>>>>>>>>>>> interface ImageResolutionHelper { >>>>>>>>>>>> // This version would prevent substituting a random image: >>>>>>>>>>>> // They have to return an index into the List for >>>>>>>>>>>> that >>>>>>>>>>>> image... >>>>>>>>>>>> public int chooseVariant(Image img, double dpi, number w, >>>>>>>>>>>> number h); >>>>>>>>>>>> >>>>>>>>>>>> or: >>>>>>>>>>>> >>>>>>>>>>>> // This version would allow substituting an arbitrary >>>>>>>>>>>> image: >>>>>>>>>>>> public Image getVariant(Image img, double dpi, number w, >>>>>>>>>>>> number >>>>>>>>>>>> h); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Since they would be in full control of the policy, though, we >>>>>>>>>>>> would >>>>>>>>>>>> unfortunately always have to call this, there would be no more >>>>>>>>>>>> testing >>>>>>>>>>>> in SG2D to see "if" we need to deal with DPI, though perhaps we >>>>>>>>>>>> could >>>>>>>>>>>> document some internal conditions in which we do not call it >>>>>>>>>>>> for >>>>>>>>>>>> common cases (but that would have to be well agreed not to >>>>>>>>>>>> get in >>>>>>>>>>>> the >>>>>>>>>>>> way of reasonable uses of the API and well documented)? >>>>>>>>>>>> >>>>>>>>>>>> Note that we would have to do a security audit to make sure >>>>>>>>>>>> that >>>>>>>>>>>> random image substitution couldn't allow any sort of "screen >>>>>>>>>>>> phishing" >>>>>>>>>>>> exploit. >>>>>>>>>>>> >>>>>>>>>>>> ...jim >>>>>>>>>>>> >>>>>>>>>>>>>> and also what policy they use for choosing scaled images. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't see a mention of taking the current transform into >>>>>>>>>>>>>> account, >>>>>>>>>>>>>> just physical issues like screen DPI and form factor. They >>>>>>>>>>>>>> talk >>>>>>>>>>>>>> about >>>>>>>>>>>>>> resolution plateaus and in their recommendations section they >>>>>>>>>>>>>> tell the >>>>>>>>>>>>>> developer to use a particular property that tells them the >>>>>>>>>>>>>> screen >>>>>>>>>>>>>> resolution to figure out which image to load if they are >>>>>>>>>>>>>> loading >>>>>>>>>>>>>> manually. There is no discussion about dynamically loading >>>>>>>>>>>>>> multiple >>>>>>>>>>>>>> versions of the image based on a dynamic program-applied >>>>>>>>>>>>>> transform >>>>>>>>>>>>>> factor as is done on MacOS. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also, they tell developers to draw images to a specific size >>>>>>>>>>>>>> rather >>>>>>>>>>>>>> than using auto-sizing. That begs the question as to how >>>>>>>>>>>>>> they >>>>>>>>>>>>>> interpret a call to draw an image just using a location in >>>>>>>>>>>>>> the >>>>>>>>>>>>>> presence of various DPI factors. >>>>>>>>>>>>> There is an interesting doc that describes how to write >>>>>>>>>>>>> DPI-aware >>>>>>>>>>>>> Win32 applications: >>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464646%28v=vs.85%29.aspx >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It is suggested to handle WM_DPICHANGED message, load >>>>>>>>>>>>> the >>>>>>>>>>>>> graphic >>>>>>>>>>>>> that has slightly greater resolution to the current DPI and >>>>>>>>>>>>> use >>>>>>>>>>>>> StretchBlt >>>>>>>>>>>>> to scale down the image. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2/7/14 3:00 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> On 1/22/2014 6:40 AM, Jim Graham wrote: >>>>>>>>>>>>>>>> Hi Alexander, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Before we get too far down the road on this API, I think we >>>>>>>>>>>>>>>> understand >>>>>>>>>>>>>>>> the way in which MacOS processes multi-resolution images >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> HiDPI >>>>>>>>>>>>>>>> screens, but have we investigated the processes that >>>>>>>>>>>>>>>> Windows >>>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>>> under Windows 8? My impression is that Windows 8 has >>>>>>>>>>>>>>>> included a >>>>>>>>>>>>>>>> number of new techniques for dealing with the high >>>>>>>>>>>>>>>> resolution >>>>>>>>>>>>>>>> displays >>>>>>>>>>>>>>>> that it will run on in the Windows tablet and mobile >>>>>>>>>>>>>>>> industries >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> that these will also come into play as 4K displays (already >>>>>>>>>>>>>>>> available) >>>>>>>>>>>>>>>> become more common on the desktop. We should make sure >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> what we >>>>>>>>>>>>>>>> come up with here can provide native compatibility with >>>>>>>>>>>>>>>> either >>>>>>>>>>>>>>>> platform's policies and standard practices. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If you've investigated the MS policies I'd like to see a >>>>>>>>>>>>>>>> summary so >>>>>>>>>>>>>>>> that we can consider them as we review this API... >>>>>>>>>>>>>>> There is the Windows Guidelines for scaling to pixel >>>>>>>>>>>>>>> density: >>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> which says that Windows has automatic resource loading >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> supports >>>>>>>>>>>>>>> three version of images scaling (100%, 140%, and 180%) >>>>>>>>>>>>>>> -------------------------------- >>>>>>>>>>>>>>> Without scaling, as the pixel density of a display device >>>>>>>>>>>>>>> increases, the >>>>>>>>>>>>>>> physical sizes of objects on screen get smaller. >>>>>>>>>>>>>>> When UI would otherwise be too small to touch and when text >>>>>>>>>>>>>>> gets >>>>>>>>>>>>>>> too >>>>>>>>>>>>>>> small to read, >>>>>>>>>>>>>>> Windows scales the system and app UI to one of the following >>>>>>>>>>>>>>> scaling >>>>>>>>>>>>>>> plateaus: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1.0 (100%, no scaling is applied) >>>>>>>>>>>>>>> 1.4 (140% scaling) >>>>>>>>>>>>>>> 1.8 (180% scaling) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Windows determines which scaling plateau to use based on the >>>>>>>>>>>>>>> physical >>>>>>>>>>>>>>> screen size, the screen resolution, the DPI of the >>>>>>>>>>>>>>> screen, and >>>>>>>>>>>>>>> form >>>>>>>>>>>>>>> factor. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Use resource loading for bitmap images in the app package >>>>>>>>>>>>>>> For >>>>>>>>>>>>>>> bitmap >>>>>>>>>>>>>>> images stored >>>>>>>>>>>>>>> in the app package, provide a separate image for each >>>>>>>>>>>>>>> scaling >>>>>>>>>>>>>>> factor(100%, 140%, and 180%), >>>>>>>>>>>>>>> and name your image files using the "scale" naming >>>>>>>>>>>>>>> convention >>>>>>>>>>>>>>> described >>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>> Windows loads the right image for the current scale >>>>>>>>>>>>>>> automatically. >>>>>>>>>>>>>>> -------------------------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The image name convention for the various scales is: >>>>>>>>>>>>>>> images/logo.scale-100.png >>>>>>>>>>>>>>> images/logo.scale-140.png >>>>>>>>>>>>>>> images/logo.scale-180.png >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The 'ms-appx:///images/logo.png' uri is used to load the >>>>>>>>>>>>>>> image >>>>>>>>>>>>>>> in an >>>>>>>>>>>>>>> application. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If we want to support this in the same way as it is done >>>>>>>>>>>>>>> for Mac >>>>>>>>>>>>>>> OS X >>>>>>>>>>>>>>> the WToolkit should return MultiResolution image in >>>>>>>>>>>>>>> case if >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> loaded image has .scale-* qualifiers. >>>>>>>>>>>>>>> The Graphics class can request an image with necessary >>>>>>>>>>>>>>> resolution >>>>>>>>>>>>>>> from the MultiResolution image. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It seems that nothing should be changed in the >>>>>>>>>>>>>>> MultiResolution >>>>>>>>>>>>>>> interface in this case. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 1/14/14 2:54 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8029339 >>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.00 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This is a proposal to introduce an API that allows to >>>>>>>>>>>>>>>>> create a >>>>>>>>>>>>>>>>> custom >>>>>>>>>>>>>>>>> multi resolution image. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I. It seems reasonable that the API should provide two >>>>>>>>>>>>>>>>> basic >>>>>>>>>>>>>>>>> operations: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1. Get the resolution variant based on the requested >>>>>>>>>>>>>>>>> image >>>>>>>>>>>>>>>>> width and >>>>>>>>>>>>>>>>> height: >>>>>>>>>>>>>>>>> - Image getResolutionVariant(int width, int height) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Usually the system provides the scale factor which >>>>>>>>>>>>>>>>> represents >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> number of pixels corresponding to each linear unit on the >>>>>>>>>>>>>>>>> display. >>>>>>>>>>>>>>>>> However, it has sense to combine the scale factor and >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>>> transformations to get the actual image size to be >>>>>>>>>>>>>>>>> displayed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2. Get all provided resolution variants: >>>>>>>>>>>>>>>>> - List getResolutionVariants() >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There are several uses cases: >>>>>>>>>>>>>>>>> - Create a new multi-resolution image based on the >>>>>>>>>>>>>>>>> given >>>>>>>>>>>>>>>>> multi-resolution image. >>>>>>>>>>>>>>>>> - Pass to the native system the multi-resolution >>>>>>>>>>>>>>>>> image. For >>>>>>>>>>>>>>>>> example, >>>>>>>>>>>>>>>>> a use can set to the system the custom multi-resolution >>>>>>>>>>>>>>>>> cursor. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> II. There are some possible ways where the new API can be >>>>>>>>>>>>>>>>> added >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1. java.awt.Image. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The 2 new methods can be added to the Image class. A >>>>>>>>>>>>>>>>> user >>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>> override >>>>>>>>>>>>>>>>> the getResolutionVariant() and getResolutionVariants() >>>>>>>>>>>>>>>>> methods to >>>>>>>>>>>>>>>>> provide the resolution variants >>>>>>>>>>>>>>>>> or there can be default implementations of these >>>>>>>>>>>>>>>>> methods >>>>>>>>>>>>>>>>> if a >>>>>>>>>>>>>>>>> user >>>>>>>>>>>>>>>>> puts resolution variants >>>>>>>>>>>>>>>>> to the list in the sorted order. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> To check that the image has resolution variants the >>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>> statement can be used: >>>>>>>>>>>>>>>>> image.getResolutionVariants().size() >>>>>>>>>>>>>>>>> != 1 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The disadvantage is that there is an overhead that the >>>>>>>>>>>>>>>>> Image >>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>> should contain the List object and not all >>>>>>>>>>>>>>>>> images can have resolution variants. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2. Introduce new MultiResolutionImage interface. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A user should extend Image class and implement the >>>>>>>>>>>>>>>>> MultiResolutionImage interface. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For example: >>>>>>>>>>>>>>>>> --------------------- >>>>>>>>>>>>>>>>> public class CustomMultiResolutionImage extends >>>>>>>>>>>>>>>>> BufferedImage >>>>>>>>>>>>>>>>> implements MultiResolutionImage { >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Image highResolutionImage; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> public CustomMultiResolutionImage(BufferedImage >>>>>>>>>>>>>>>>> baseImage, >>>>>>>>>>>>>>>>> BufferedImage highResolutionImage) { >>>>>>>>>>>>>>>>> super(baseImage.getWidth(), >>>>>>>>>>>>>>>>> baseImage.getHeight(), >>>>>>>>>>>>>>>>> baseImage.getType()); >>>>>>>>>>>>>>>>> this.highResolutionImage = highResolutionImage; >>>>>>>>>>>>>>>>> Graphics g = getGraphics(); >>>>>>>>>>>>>>>>> g.drawImage(baseImage, 0, 0, null); >>>>>>>>>>>>>>>>> g.dispose(); >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>>>> public Image getResolutionVariant(int width, int >>>>>>>>>>>>>>>>> height) { >>>>>>>>>>>>>>>>> return ((width <= getWidth() && height <= >>>>>>>>>>>>>>>>> getHeight())) >>>>>>>>>>>>>>>>> ? this : highResolutionImage; >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>>>> public List getResolutionVariants() { >>>>>>>>>>>>>>>>> return Arrays.asList(this, >>>>>>>>>>>>>>>>> highResolutionImage); >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> --------------------- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The current fix adds the MultiResolutionImage interface >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> public >>>>>>>>>>>>>>>>> resolution variant rendering hints. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From anthony.petrov at oracle.com Fri Apr 25 11:47:49 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 Apr 2014 15:47:49 +0400 Subject: [9] Review request: 8041490 PIT: [macosx] Crash in system tray functionality check test In-Reply-To: <5357C0C1.1080109@oracle.com> References: <5357C0C1.1080109@oracle.com> Message-ID: <535A4B65.9040900@oracle.com> +1 -- best regards, Anthony On 4/23/2014 5:31 PM, Sergey Bylokhov wrote: > Hi, Petr. > The fix looks good. > > On 4/23/14 2:59 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8041490 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/8041490/webrev/ >> >> After Toolkit.sync() was implemented on OS X we've found a bug which >> was unnoticed: >> when the WarningWindow is disposed it's surface is not invalidated. >> So if we attempt to flush the GL queue after that we would crash. >> I've added the loop in the test to increase the probability of the crash. >> >> With best regards. Petr. > > From anthony.petrov at oracle.com Fri Apr 25 11:49:01 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 Apr 2014 15:49:01 +0400 Subject: [9] Review Request: 8027148 SystemFlavorMap.getNativesForFlavor returns list of native formats in incorrect order In-Reply-To: <5357C2A8.4060309@oracle.com> References: <0008EDB8-C0C6-447B-B4A6-EEFF3B94CB99@oracle.com> <53551B3B.4060509@oracle.com> <73FA4A1E-80FF-46EB-9F6B-DC9E604DF72F@oracle.com> <535680CA.1030203@oracle.com> <5357C2A8.4060309@oracle.com> Message-ID: <535A4BAD.7020905@oracle.com> The fix still looks good to me. -- best regards, Anthony On 4/23/2014 5:39 PM, Sergey Bylokhov wrote: > Hi, Petr. > Thanks! The fix looks good. > > On 4/23/14 4:58 PM, Petr Pchelko wrote: >> Hello, Sergey. >> >> Please see the updated fix here: >> http://cr.openjdk.java.net/~pchelko/9/8027148/webrev.02/ >> >>> - I guess textTypeToNative must be initialized only once and can be >>> replaced by Collections.unmodifiableMap(q); >> Done. >> >>> - Please check all related tests on all supported platforms, since we >>> have a lots of regressions here. >> I've run all regression and functional datatransfer tests on all >> platforms.. And JCK. >> >> With best regards. Petr. >> >> On 22.04.2014, at 18:46, Sergey Bylokhov >> wrote: >> >>> Hi, Petr. >>> Not an expert here, just a few notes. >>> - I guess textTypeToNative must be initialized only once and can be >>> replaced by Collections.unmodifiableMap(q); >>> - Please check all related tests on all supported platforms, since we >>> have a lots of regressions here. >>> >>> On 4/21/14 5:39 PM, Petr Pchelko wrote: >>>> Hello, Anthony. >>>> >>>> I've updated the fix: >>>> http://cr.openjdk.java.net/~pchelko/9/8027148/webrev.01/ >>>> >>>>> 2. I'm not sure if the new formatting for htmlDocumntTypes at new >>>>> lines 887 - 889 looks better than the old one. >>>> Reverted. >>>> >>>>> 1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java >>>>>> 118 private Map> >>>>>> getNativeToFlavor() { >>>>> Usually we use a generic interface, such as Set, instead of a >>>>> concrete implementation class (LinkedHashSet) in generic types >>>>> declarations to avoid dependencies on concrete implementations that >>>>> may change in the future. Would that be possible to do the same for >>>>> method return type declarations in this file? >>>> I've done this on purpose here. It is VERY important for the >>>> collection used here to have a predictable iteration order, but it >>>> must not be sorted. We do not have any generic interface for this >>>> type of Set, so I've decided to place an exact class here so that >>>> nobody could by accident use a wrong Set and break everything. >>>> If a generic Set would be used someone could easily change it to >>>> HashSet somewhere in the overrides and not notice the bug. >>>> >>>>> 3. In setNativesForFlavor() and addFlavorForUnencodedNative() we >>>>> used to remove(null) from the getNativesForFlavorCache and >>>>> getFlavorsForNativeCache caches. Now we don't. What is the story >>>>> behind the nulls? How did they get there previously, and how do we >>>>> avoid them now? >>>> I've made a wrapper class for this cache (see the bottom of the >>>> file). With the wrapper we can create the cache lazily and the cache >>>> logic is now in one place. >>>> >>>> With best regards. Petr. >>>> >>>> On 21.04.2014, at 17:20, Anthony Petrov >>>> wrote: >>>> >>>>> Hi Petr, >>>>> >>>>> 1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java >>>>>> 118 private Map> >>>>>> getNativeToFlavor() { >>>>> Usually we use a generic interface, such as Set, instead of a >>>>> concrete implementation class (LinkedHashSet) in generic types >>>>> declarations to avoid dependencies on concrete implementations that >>>>> may change in the future. Would that be possible to do the same for >>>>> method return type declarations in this file? >>>>> >>>>> 2. I'm not sure if the new formatting for htmlDocumntTypes at new >>>>> lines 887 - 889 looks better than the old one. >>>>> >>>>> 3. In setNativesForFlavor() and addFlavorForUnencodedNative() we >>>>> used to remove(null) from the getNativesForFlavorCache and >>>>> getFlavorsForNativeCache caches. Now we don't. What is the story >>>>> behind the nulls? How did they get there previously, and how do we >>>>> avoid them now? >>>>> >>>>> Otherwise the fix looks okay. Note that I'm not an expert in this >>>>> code, so I may have missed some issues in the logic changes. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 4/18/2014 5:49 PM, Petr Pchelko wrote: >>>>>> Hello, AWT Team. >>>>>> >>>>>> Please review the fix for the issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8027148 >>>>>> The fix is available at: >>>>>> http://cr.openjdk.java.net/~pchelko/9/8027148/webrev/ >>>>>> >>>>>> Sorry for the long text, but it?s quite tangled) >>>>>> >>>>>> The problem: >>>>>> The flavor map contains some predefined mappings which are stored >>>>>> in the flavormap.properties file. But we can extend these mappings >>>>>> using >>>>>> addUnencodedNativeForFlavor method. Javadoc states, that these new >>>>>> mappings would have lower priority that standard mappings. But in >>>>>> the current implementation this was not the case, because >>>>>> getNativesForFlavor method relied on the fact, that standard text >>>>>> mappings were stored as FlavorBaseType<->Native and newly added >>>>>> mappings were stored as DataFlavor<->Native, but after some fix in >>>>>> Java 8 this is not the case any more. Everything is stored as a >>>>>> DataFlavor as a key. This is important only for text flavors, >>>>>> because we support different text charsets and can reencode the >>>>>> text on the fly. So each native text format could be represented >>>>>> in many different DataFlavors with different encodings and >>>>>> representation classes. When we generate the set of DataFlavor?s >>>>>> that a text native can be translated to we no longer know how to >>>>>> distinguish the standard mappings and additional mappings and the >>>>>> get shuffled when we generate missing mappings for text formats. >>>>>> >>>>>> The solution: >>>>>> I?ve added an additional map for standard text mappings. With this >>>>>> map we can now take natives for mime types directly and not "find >>>>>> all flavors for a mime-type and than all natives for each flavor". >>>>>> This is not only faster, but we can distinguish standard text >>>>>> mappings from custom and return the list in the correct order. The >>>>>> new hash map contains only a few elements. >>>>>> >>>>>> Also I?ve replaced the ArrayList as a collection of natives for a >>>>>> particular Flavor with a LinkedHashSet, because this list could >>>>>> not contain duplicated which we were enforcing ourselves. Now it >>>>>> works out of the box and some code can be removed. >>>>>> >>>>>> I?ve measured the performance of a couple of most hot methods and >>>>>> on average the new implementation is 1.7 times faster. >>>>>> >>>>>> The test is being open sources. >>>>>> >>>>>> I?ve tested this with JCK and our regression tests, everything >>>>>> looks good. Also I?ve tested with a couple of hand-made toys. >>>>>> >>>>>> Thank you. >>>>>> With best regards. Petr. >>>>>> >>> >>> -- >>> Best regards, Sergey. >>> >>> > > From anthony.petrov at oracle.com Fri Apr 25 11:50:50 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 Apr 2014 15:50:50 +0400 Subject: [9] Review request: 8041572 [macosx] huge native memory leak in AWTWindow.m In-Reply-To: <5357C751.8000509@oracle.com> References: <586A51CC-2B56-403A-89A6-C3A93AD255DD@oracle.com> <5357C751.8000509@oracle.com> Message-ID: <535A4C1A.8040308@oracle.com> +1 -- best regards, Anthony On 4/23/2014 5:59 PM, Sergey Bylokhov wrote: > Hi, Petr. > The fix looks good. > > On 4/23/14 1:39 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Another huge native leak was found: >> https://bugs.openjdk.java.net/browse/JDK-8041572 >> The fix is simple and available here: >> http://cr.openjdk.java.net/~pchelko/9/8041572/webrev/ >> >> Along with fixing the bug in AWTWindow.m I've also grepped the sources >> for any core foundation methods that return a copied objects that >> needs to be released >> and found 2 mode similar leaks in GraphicsDevice.m >> >> Thank you. >> With best regards. Petr. > > From anthony.petrov at oracle.com Fri Apr 25 11:57:17 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 Apr 2014 15:57:17 +0400 Subject: [9] Review Request for 8041592: [TEST_BUG] Move 42 AWT hw/lw mixing tests to jdk In-Reply-To: <5358D8B4.1090407@oracle.com> References: <5358D8B4.1090407@oracle.com> Message-ID: <535A4D9D.2060701@oracle.com> Hi Yuri, Great to see more tests covering the HW/LW Mixing functionality coming in! I briefly skimmed through the patch, and it looks good to me. -- best regards, Anthony On 4/24/2014 1:26 PM, Yuri Nesterenko wrote: > Hi, > > please review this change for > https://bugs.openjdk.java.net/browse/JDK-8041592 > > Webrev is in: > http://cr.openjdk.java.net/~yan/8041592/webrev.00/ > > Thanks, > -yan > > Here's an excerpt from the bug Description: > ________________________________________ > > There are 42 automatic functional tests verifying various aspects of > HW/LW mixing in AWT. We will move them to a separate directory > test/java/awt/Mixing/AWT_Mixing/. > > Note that: > (1) we decided to make only small changes to the tests as it is just > some 5% of our task at hand; > (2) tests are written in someway different styles; > (3) most of them extend some basic class (included in the > same directory); > (4) they use an utility class (included) someway duplicating new > functionality of ExtendedRobot. However we left this part intact to > avoid unnecessary refactoring; > (5) the tests seems stable enough. They were run on 3 platforms > continuously many times together demonstrating exactly the same output. > (6) Of the 42 in total, 3 fail on OS X (2 of them also on Linux and > Windows) because of the open product bugs. > From anthony.petrov at oracle.com Fri Apr 25 12:03:36 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 Apr 2014 16:03:36 +0400 Subject: [9] Review request for JDK-8039383: NPE when changing Windows Theme In-Reply-To: <53590232.4080703@oracle.com> References: <5350DDBC.30603@oracle.com> <5351143C.8010100@oracle.com> <53513B5B.4050104@oracle.com> <53513C26.9060305@oracle.com> <53590232.4080703@oracle.com> Message-ID: <535A4F18.3060907@oracle.com> Hi Alexey, I'm not an expert in this particular code, but as long as the suggested fix doesn't allow user code to run on the toolkit thread, I'm fine with the fix. -- best regards, Anthony On 4/24/2014 4:23 PM, Alexey Ivanov wrote: > Hi Anthony, AWT and Swing teams, > > Here's the updated fix: > http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/ > > Description: > In the new version of the fix, I use a new xpstyleEnabled field of > AtomicBoolean in WToolkit to track the current value of > "win.xpstyle.themeActive" desktop property. Its value is updated in > windowsSettingChange() and in updateProperties(). > XPStyle.getXP() checks its cached value in themeActive and the current > value in WToolkit; if the value changes, it schedules updateAllUIs and > invalidates the current style right away, so that components would not > access data from the theme that became unavailable. > Two functions in ThemeReader also check this special field from WToolkit > which prevents throwing InternalError when paint is called before theme > change is fully handled. > > Before updateAllUIs is invoked, it's possible that application will > paint with some values cached from the previous theme. Usually it > happens before "Theme change" dialog disappears from the screen, at > least I noticed no UI glitches during normal theme change. > > > Regression test: > No regression test is provided due to its complexity. Additionally, > whether NullPointerException or InternalError are thrown depends on the > order of event handling, sometimes exceptions do not occur when changing > theme of visual styles enabled theme to a classic theme. > > > Thank you, > Alexey. > > On 18.04.2014 18:52, Anthony Petrov wrote: >> Hi Alexey, >> >> No, unfortunately I don't have any suggestions right now. >> >> As for allowing executing user code on the toolkit thread, we can't >> accept such a fix. Sorry about that. >> >> -- >> best regards, >> Anthony >> >> On 4/18/2014 6:48 PM, Alexey Ivanov wrote: >>> Hi Anthony, >>> >>> Thank you for your review. >>> >>> Yes, user code can install a property change listener... It was my >>> concern too, that's why I explicitly noted about this. >>> >>> Do you have any suggestion how this situation can be handled? >>> Is it a general rule that all desktop property change listeners must be >>> called on EDT? >>> >>> >>> Thanks, >>> Alexey. >>> >>> On 18.04.2014 16:02, Anthony Petrov wrote: >>>> Hi Alexey, >>>> >>>>> With this change, property "win.xpstyle.themeActive" change is fired >>>>> on the toolkit thread >>>> >>>> Is it possible to install a change listener for this property from >>>> user code, and hence eventually allow executing some user code on the >>>> toolkit thread with your fix? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 4/18/2014 12:09 PM, Alexey Ivanov wrote: >>>>> Hello Swing and AWT teams, >>>>> >>>>> Could you please review the fix for jdk9: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039383 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.00/ >>>>> >>>>> Problem description: >>>>> When changing Windows themes from a theme with visual styles (Windows >>>>> Aero or Windows Basic) to a classic one, NullPointerException could be >>>>> thrown from Swing code during component tree validation, or >>>>> InternalError could be thrown during component painting. >>>>> >>>>> Root cause: >>>>> Windows theme data are "cached" in XPStyle object. When the theme is >>>>> switched to a classic one, HTHEME handle becomes unavailable and data >>>>> cannot be accessed from the theme any more. The change in theme in >>>>> posted to EDT via invokeLater. At the same time, the UI needs to >>>>> repaint >>>>> itself as soon as Windows changed the theme, and paint code is often >>>>> called before the theme change is handled in Java. This leads to >>>>> NPE and >>>>> InternalError as the code tries to access the data that has become >>>>> unavailable. >>>>> >>>>> The fix: >>>>> Update "win.xpstyle.themeActive" desktop property and invalidate the >>>>> cached XPStyle as soon as windowsSettingChange() is called from native >>>>> code. Thus when Swing code needs to access theme data, it will see no >>>>> theme is available and will fallback to classic painting. >>>>> >>>>> Note: Before the fix, PropertyChangeEvents for desktop properties in >>>>> Windows were fired on the Event Dispatch Thread. With this change, >>>>> property "win.xpstyle.themeActive" change is fired on the toolkit >>>>> thread; all other properties are changed on the EDT as before. >>>>> >>>>> >>>>> Regards, >>>>> Alexey. >>> > From dmitriy.ermashov at oracle.com Fri Apr 25 13:04:51 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Fri, 25 Apr 2014 17:04:51 +0400 Subject: Review Request for 8041915: Move 8 awt tests to OpenJDK regression tests tree Message-ID: <535A5D73.4090002@oracle.com> Hi, Please review the changeset for https://bugs.openjdk.java.net/browse/JDK-8041915 Webrev is here: http://cr.openjdk.java.net/~yan/8041915/webrev.00/ -- Thanks, Dima From petr.pchelko at oracle.com Fri Apr 25 13:19:23 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 25 Apr 2014 17:19:23 +0400 Subject: Review Request for 8041915: Move 8 awt tests to OpenJDK regression tests tree In-Reply-To: <535A5D73.4090002@oracle.com> References: <535A5D73.4090002@oracle.com> Message-ID: <0F2D6903-0F7C-45EA-88C4-1FE9852AA69D@oracle.com> Hello, Dmitriy. A couple of questions: 1. checkTranslucencyMode throws an exception if some mode is not supported on the device, so the test would fail. Should it? Normally we just skip the test if some capability is absent. 2. Didn't you consider moving the drag method into the ExtendedRobot? I expect it to be very commonly used. With best regards. Petr. On 25.04.2014, at 17:04, Dmitriy Ermashov wrote: > Hi, > > Please review the changeset for > https://bugs.openjdk.java.net/browse/JDK-8041915 > > Webrev is here: > http://cr.openjdk.java.net/~yan/8041915/webrev.00/ > > -- > Thanks, > Dima > From alexandr.scherbatiy at oracle.com Fri Apr 25 14:45:29 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 25 Apr 2014 18:45:29 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: <53598D86.5020607@oracle.com> References: <52D51764.8020103@oracle.com> <52DF2F98.3030503@oracle.com> <52F4BCEB.9040702@oracle.com> <52F5782A.9060300@oracle.com> <52FB7E3E.6050000@oracle.com> <52FC14EC.9080503@oracle.com> <53037D3D.80709@oracle.com> <5307E71E.50607@oracle.com> <530F3592.40600@oracle.com> <532B00AD.1000704@oracle.com> <532B7EC5.9000206@oracle.com> <532C4DD7.1080804@oracle.com> <532CD202.5070508@oracle.com> <53302A8E.6090107@oracle.com> <53343914.6090004@oracle.com> <533C8DDB.5000406@oracle.com> <533E9D42.10409@oracle.com> <53598D86.5020607@oracle.com> Message-ID: <535A7509.6050802@oracle.com> On 4/25/2014 2:17 AM, Jim Graham wrote: > Hi Alexandr, > > I asked for who was requesting these facilities and you responded with > the solution you are planning to provide. > > I don't care what the solution looks like if we have nobody asking for > the feature - I am asking who is asking for these capabilities? This is the request from the AWT team for the HiDPI support. Thanks, Alexandr. > > ...jim > > On 4/4/14 4:53 AM, Alexander Scherbatiy wrote: >> On 4/3/2014 2:23 AM, Jim Graham wrote: >>> Hi Alexandr, >>> >>> The back and forth is getting confusing here, so I thought I'd try to >>> summarize and start fresh(ish): >>> >>> 1. We need to support @2x internally for MacOS compatibility (done). >>> >>> 2. We will need to support _DPI images for Win-DPI compatibility (TBD). >>> >>> 3. Customers may have their own collection of images to bundle >>> together into an MR image (working on that here). What is the push >>> for this? Is this simply parity with Mac interfaces? >> >> ---------- >> Image[] resolutionVariants = // get sorted by sizes array of >> resolution variants; >> Image mrImage = >> Toolkit.getDefaultToolkit().createMRImage(baseImageIndex, >> resolutionVariants); >> ---------- >> >> Here is the proposed patch: >> http://cr.openjdk.java.net/~alexsch/8029339/webrev.04/ >> >>> 4. Customers may want to synthetically generate images at arbitrary >>> resolutions (a variation that is impacting this solution). What is >>> the push for this? >> ---------- >> Image mrImage = >> Toolkit.getDefaultToolkit().createMRImage(baseImageWidth, >> baseImageHeight, >> new float[][]{{100, 100}, {150, 150}, {200, 200}}, // >> resolution variants sizes >> (rvWidth, rvHeight) -> { /* generate a resolution >> variant */ }); >> ---------- >> >>> >>> 5. I'm guessing that customers might want to override the logic to >>> choose from among multiple resolutions. That came from me based on >>> seeing Mac and Win using different selection logic and our history of >>> developers split between those wanting cross-platform consistency and >>> those wanting consistency with native apps on each platform. Also, >>> the needs of an animator may differ from the needs of a >>> resolution-settable-document editor as to how dynamically the images >>> shift between resolution variants. >> ---------- >> Image[] resolutionVariants = // get sorted by sizes array of >> resolution variants; >> Image mrImage = ImageResolutionHelper.createMRImage( >> (rvWidth, rvHeight, resolutionVariants) -> { /*use a >> custom logic to choose a resolution variant from an array of images*/}, >> (logicalDPI, baseImageSize, destImageSize) -> >> destImageSize, // calculate the custom aware resolution variant size >> baseImageIndex, resolutionVariants); >> ---------- >> >> or just extend the CustomMultiResolutionImage which has Image as the >> parent class: >> >> -------------------- >> public class CustomMultiResolutionImage extends >> AbstractMultiResolutionImage { >> >> @Override >> public Image getResolutionVariant(float logicalDPIX, float >> logicalDPIY, >> float baseImageWidth, float baseImageHeight, >> float destImageWidth, float destImageHeight) { >> // return a resolution variant based on the given logical DPI, >> // base image size, or destination image size >> } >> >> @Override >> public List getResolutionVariants() { >> // return a list of resolution variants >> } >> >> @Override >> protected Image getBaseImage() { >> // return the base image >> } >> } >> -------------------- >>> >>> Is that a fair summary of all of the considerations so far, or did I >>> miss something? >> I think it should cover the main needs. >> >> Thanks, >> Alexandr. >>> >>> ...jim >>> >>> On 3/27/14 7:43 AM, Alexander Scherbatiy wrote: >>>> >>>> Below are some thoughts about TK.createMRImage(...) method >>>> >>>> On 3/24/2014 4:52 PM, Alexander Scherbatiy wrote: >>>>> Hello, >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.03/ >>>>> >>>>> - baseImageWidth/Height arguments are added to the >>>>> getResolutionVariant(...) method >>>>> - dest image sizes are reverted to included DPI scale >>>>> - AbstractMultiResolutionImage is added. It needs only to implement >>>>> only 3 methods from the AbstractMultiResolutionImage class >>>>> to create a custom multi-resolution image. For example: >>>>> >>>>> On 3/22/2014 3:57 AM, Jim Graham wrote: >>>>>> >>>>>> Your code example below can be expressed as an implementation of the >>>>>> single-method, lambda-compatible interface that expresses just the >>>>>> getRV() method. They could easily do: >>>>>> >>>>>> final Image baseImage = ...; >>>>>> TK.createMRImage(new RVInterface() { >>>>>> public Image getRV(...) { >>>>>> // calculate rvWidth and rvHeight >>>>>> // look up rvWidth/rvHeight in a database of images >>>>>> // possibly contruct a new image >>>>>> return rvImage; >>>>>> } >>>>>> }, baseImage); >>>>>> >>>> The RVInterface mixes the logic that construct an image and >>>> chooses the necessary resolution variant. >>>> It is ok if a developer always implements this interface. If it >>>> needs to have DPI/Transform/Platform aware RVInterface the image >>>> construction logic should be separated. >>>> >>>> Does TK.createMRImage() method implies that Platform aware logic >>>> should be used for a resolution-variant choosing? >>>> If so, may be general createMRImage() can be placed in the >>>> ImageResolutionHelper. >>>>>> The main issue I see is if you might want the newly constructed >>>>>> variants to appear in the List returned from the getVariants() >>>>>> method. I'm not sure what value that would have beyond simply >>>>>> returning the base media that the object uses from which to >>>>>> construct >>>>>> its variants...? >>>> >>>> It can be solved by using something like array of image sizes or >>>> other seeds and a mapper that can create an image from the given seed. >>>> >>>> It can look like: >>>> ------------------------- >>>> public class ImageResolutionHelper { >>>> public interface RVChooser { >>>> >>>> public Image getRV( >>>> float logicalDPIX, float logicalDPIY, >>>> float baseImageWidth, float baseImageHeight, >>>> float destImageWidth, float destImageHeight, >>>> final Image... resolutionVariants); >>>> } >>>> >>>> public static final RVChooser DPI_AWARE = ...; >>>> public static final RVChooser TRANSFORM_AWARE = ...; >>>> >>>> // resolutionVariants is an array of sorted by width/height >>>> images >>>> static Image createMRImage(final RVChooser rvChooser, >>>> final int baseImageIndex, final Image... >>>> resolutionVariants) { ... } >>>> >>>> // sorted by width/height images should be generated from seeds >>>> static Image createMRImage(final RVChooser rvChooser, >>>> final Type baseImageSeed, final Function >>>> mapper, final Type... rvSeeds) {...} >>>> } >>>> >>>> public abstract class Toolkit { >>>> public abstract Image createMRImage(int baseImageIndex, Image... >>>> resolutionVariants); // Platform aware rv chooser is used >>>> public abstract RVChooser getPlatformRVChooser() ; >>>> } >>>> -------------------------- >>>> Thanks, >>>> Alexandr. >>>> >>>>>> >>>>>>> I think it is better to provide both the MultiResolutionImage >>>>>>> and >>>>>>> its implementation based on the given resolution variants array. >>>>>> >>>>>> It occurs to me that even if we don't go with a lambda-factory-based >>>>>> approach like what I'm describing, it might make sense to provide a >>>>>> baseMR implementation that they can subclass to keep them from >>>>>> trying >>>>>> to subclass off of BufferedImage instead. I really would like to >>>>>> avoid "custom MR images are subclasses of BufImg" if we can as I >>>>>> think the mix of concepts is a little jarring... >>>>>> >>>>>> ...jim >>>>>> >>>>>>> The implementation could look like: >>>>>>> --------------------------------- >>>>>>> public class CustomMultiResolutionImage extends Image implements >>>>>>> MultiResolutionImage { >>>>>>> >>>>>>> int baseImageIndex; >>>>>>> Image[] resolutionVariants; >>>>>>> >>>>>>> public CustomMultiResolutionImage(int baseImageIndex, >>>>>>> Image... resolutionVariants) { >>>>>>> this.baseImageIndex = baseImageIndex; >>>>>>> this.resolutionVariants = resolutionVariants; >>>>>>> } >>>>>>> >>>>>>> @Override >>>>>>> public int getWidth(ImageObserver observer) { >>>>>>> return getBaseImage().getWidth(null); >>>>>>> } >>>>>>> >>>>>>> @Override >>>>>>> public int getHeight(ImageObserver observer) { >>>>>>> return getBaseImage().getHeight(null); >>>>>>> } >>>>>>> >>>>>>> @Override >>>>>>> public ImageProducer getSource() { >>>>>>> return getBaseImage().getSource(); >>>>>>> } >>>>>>> >>>>>>> @Override >>>>>>> public Graphics getGraphics() { >>>>>>> return getBaseImage().getGraphics(); >>>>>>> } >>>>>>> >>>>>>> @Override >>>>>>> public Object getProperty(String name, ImageObserver >>>>>>> observer) { >>>>>>> return getBaseImage().getProperty(name, observer); >>>>>>> } >>>>>>> >>>>>>> @Override >>>>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>>>> logicalDPIY, >>>>>>> float destinationImageWidth, float >>>>>>> destinationImageHeight) { >>>>>>> // calculate resolution variant width/height >>>>>>> return getResolutionVariant(rvWidth, rvHeight); >>>>>>> } >>>>>>> >>>>>>> @Override >>>>>>> public List getResolutionVariants() { >>>>>>> return Arrays.asList(resolutionVariants); >>>>>>> } >>>>>>> >>>>>>> private Image getResolutionVariant(float rvWidth, float >>>>>>> rvHeight) { >>>>>>> // return a resolution variant based on the given width >>>>>>> and >>>>>>> height >>>>>>> } >>>>>>> >>>>>>> private Image getBaseImage() { >>>>>>> return resolutionVariants[baseImageIndex]; >>>>>>> } >>>>>>> } >>>>>>> --------------------------------- >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>> >>>>>>>> Then we provide one of these from TK.get/createImage() when the >>>>>>>> platform detects @2x, or Win8-style variants. >>>>>>>> >>>>>>>> For custom images we provide TK.createMRImage(lambda getRV, Image >>>>>>>> variants...) and TK.createMRImage(Image variants...); >>>>>>>> >>>>>>>> Since the get method is just bookkeeping, I don't see them >>>>>>>> needing to override it, so the getRV() method is really the only >>>>>>>> thing >>>>>>>> they might want to override, and we can tie into the new Lambda >>>>>>>> capabilities by making a single-method interface for it that they >>>>>>>> supply in a factory method. >>>>>>>> >>>>>>>> I realize that the interface you created is more fundamentally >>>>>>>> OO, but >>>>>>>> the Image class has always been special in this regard in the AWT >>>>>>>> ecosystem (in so far as we do not support someone implementing >>>>>>>> their >>>>>>>> own Image subclass even though it is technically possible). >>>>>>>> Because of >>>>>>>> this special nature of Image, we end up with the situation that if >>>>>>>> someone were given a need to create a subclass of Image, then they >>>>>>>> would turn to BufImg as their superclass even though BufImg is >>>>>>>> essentially an implementation-specific leaf node on the Image >>>>>>>> class >>>>>>>> hierarchy. This approach with a factory method to create an >>>>>>>> internal >>>>>>>> subclass of the new MRI class mirrors the existing cases of Image >>>>>>>> objects that come from factories as well. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> >>>>>>>> On 3/20/14 7:52 AM, Alexander Scherbatiy wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the updated version of the fix: >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.01/ >>>>>>>>> >>>>>>>>> - The "getResolutionVariant(int width, int height)" method from >>>>>>>>> MultiResolutionImage class is changed to >>>>>>>>> Image getResolutionVariant(float logicalDPIX, float >>>>>>>>> logicalDPIY, >>>>>>>>> float width, float height, AffineTransform transform); >>>>>>>>> >>>>>>>>> - sun.awt.image.ImageResolutionHelper class is added. The >>>>>>>>> sun.awt.image.MultiResolutionToolkitImage and >>>>>>>>> sun.awt.image.MultiResolutionBufferedImage classes are used >>>>>>>>> PLATFORM ImageResolutionHelper. >>>>>>>>> >>>>>>>>> The MultiResolutionImage interface implementation could look >>>>>>>>> like: >>>>>>>>> ------------------------------ >>>>>>>>> public class CustomMultiResolutionImage extends BufferedImage >>>>>>>>> implements >>>>>>>>> MultiResolutionImage { >>>>>>>>> >>>>>>>>> private final Image[] resolutionVariants; >>>>>>>>> >>>>>>>>> public CustomMultiResolutionImage(int baseIndex, Image... >>>>>>>>> images) { >>>>>>>>> super(images[baseIndex].getWidth(null), >>>>>>>>> images[baseIndex].getHeight(null), >>>>>>>>> BufferedImage.TYPE_INT_RGB); >>>>>>>>> this.resolutionVariants = images; >>>>>>>>> Graphics g = getGraphics(); >>>>>>>>> g.drawImage(images[baseIndex], 0, 0, null); >>>>>>>>> g.dispose(); >>>>>>>>> } >>>>>>>>> >>>>>>>>> @Override >>>>>>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>>>>>> logicalDPIY, >>>>>>>>> float width, float height, AffineTransform >>>>>>>>> transform) { >>>>>>>>> return getResolutionVariant(logicalDPIX * width, >>>>>>>>> logicalDPIY * >>>>>>>>> height); >>>>>>>>> } >>>>>>>>> >>>>>>>>> @Override >>>>>>>>> public List getResolutionVariants() { >>>>>>>>> return Arrays.asList(resolutionVariants); >>>>>>>>> } >>>>>>>>> >>>>>>>>> public Image getResolutionVariant(double width, double >>>>>>>>> height) { >>>>>>>>> for (Image image : resolutionVariants) { >>>>>>>>> if (width <= image.getWidth(null) && height <= >>>>>>>>> image.getHeight(null)) { >>>>>>>>> return image; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> return this; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> ------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> On 2/27/2014 4:54 PM, Alexander Scherbatiy wrote: >>>>>>>>>> On 2/22/2014 3:54 AM, Jim Graham wrote: >>>>>>>>>>> Hi Alexandr, >>>>>>>>>>> >>>>>>>>>>> On 2/18/14 7:33 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>> Hi Jim, >>>>>>>>>>>> >>>>>>>>>>>> Let's divide the discussion into two part. >>>>>>>>>>>> >>>>>>>>>>>> 1. Where it is better to hold resolution variants? >>>>>>>>>>>> Putting resolution variants in Image class brings some >>>>>>>>>>>> questions like: >>>>>>>>>>>> - Some type of images do not need to have resolution >>>>>>>>>>>> variants >>>>>>>>>>>> - Should resolution variants have the same type as the base >>>>>>>>>>>> image? >>>>>>>>>>>> - getResolutionVariants() method can return copy of the >>>>>>>>>>>> original >>>>>>>>>>>> list >>>>>>>>>>>> so add/removeRV methods should be also added. >>>>>>>>>>>> >>>>>>>>>>>> There are pros and cons for placing resolution variants to >>>>>>>>>>>> Image >>>>>>>>>>>> class or to a separate intreface. >>>>>>>>>>> >>>>>>>>>>> I agree that this could be a separate interface. In my examples >>>>>>>>>>> below I was just sticking them inside an "Image{}" to show >>>>>>>>>>> where >>>>>>>>>>> they >>>>>>>>>>> lived in the set of involved objects, not a specific >>>>>>>>>>> recommendation >>>>>>>>>>> that they actually be new methods on the base class itself. I >>>>>>>>>>> probably should have put a comment there about that. >>>>>>>>>>> >>>>>>>>>>> With respect to add/remove - that is assuming a need for manual >>>>>>>>>>> construction of an image set, right? Forgive me if I'm >>>>>>>>>>> forgetting >>>>>>>>>>> something, but I seem to recall that manual Multi-Res images >>>>>>>>>>> was >>>>>>>>>>> proposed as a way for developers to introduce @2x support >>>>>>>>>>> themselves, >>>>>>>>>>> but if we are internally managing @2x and -DPI variants for >>>>>>>>>>> them, >>>>>>>>>>> then I'm not sure if there is actual developer need to manually >>>>>>>>>>> construct their own. Am I forgetting something? >>>>>>>>>> The NSImage has addRepresentation/removeRepresentation >>>>>>>>>> methods to >>>>>>>>>> work with image representations on Mac OS X. >>>>>>>>>> The java.awt.Image class should provide similar >>>>>>>>>> functionality to >>>>>>>>>> have the possibilities as Cocoa on HiDPI displays. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 2. Using scale factor/image sizes/scaled image sizes to >>>>>>>>>>>> retreive a >>>>>>>>>>>> resolution variant. >>>>>>>>>>>> >>>>>>>>>>>> May be it is better to have a structure that provide all >>>>>>>>>>>> necessary >>>>>>>>>>>> information to query the resolution variant: scale factor, >>>>>>>>>>>> draw area >>>>>>>>>>>> width/height, transformed area width/height? >>>>>>>>>>>> >>>>>>>>>>>> For example: >>>>>>>>>>>> --------------------- >>>>>>>>>>>> public interface MultiResolutionImage { >>>>>>>>>>>> >>>>>>>>>>>> interface DrawAreaInfo { >>>>>>>>>>>> >>>>>>>>>>>> float getScaleFactor(); >>>>>>>>>>>> float getAreaWidth(); >>>>>>>>>>>> float getAreaHeight(); >>>>>>>>>>>> float getTransformedAreaWidth(); >>>>>>>>>>>> float getTransformedAreaHeight(); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> public Image getResolutionVariant(DrawAreaInfo >>>>>>>>>>>> drawAreaInfo) ; >>>>>>>>>>>> public List getResolutionVariants(); >>>>>>>>>>>> } >>>>>>>>>>>> --------------------- >>>>>>>>>>> >>>>>>>>>>> The problem with a constructor is that this is something >>>>>>>>>>> that is >>>>>>>>>>> (potentially) done on every drawImage() call, which means we >>>>>>>>>>> are >>>>>>>>>>> inviting GC into the equation. If we can come up with a simple >>>>>>>>>>> "just >>>>>>>>>>> a couple/3/4 numbers" way to embed that data into a method call >>>>>>>>>>> argument list then we can make this lighter weight. >>>>>>>>>>> >>>>>>>>>>> What about simply having floating point (double) dimensions on >>>>>>>>>>> the >>>>>>>>>>> rendered size >>>>>>>>>> There should be a way to choose a resolution variant >>>>>>>>>> based on >>>>>>>>>> requested drawing size or transformed drawing size. >>>>>>>>>> At least a current transformation should be included too. >>>>>>>>>>> plus a single floating point "logical DPI" for the screen? >>>>>>>>>> There is the ID2D1Factory::GetDesktopDpi method which >>>>>>>>>> returns >>>>>>>>>> dpiX and dpiY. >>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316 >>>>>>>>>> >>>>>>>>>> That means that logicalDPIX/Y can have different values. >>>>>>>>>> At least it is described in the >>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/ff684173 >>>>>>>>>> "To get the DPI setting, call the >>>>>>>>>> ID2D1Factory::GetDesktopDpi >>>>>>>>>> method. The DPI is returned as two floating-point values, one >>>>>>>>>> for >>>>>>>>>> the >>>>>>>>>> x-axis and one for the y-axis. In theory, these values can >>>>>>>>>> differ. >>>>>>>>>> Calculate a separate scaling factor for each axis." >>>>>>>>>> >>>>>>>>>> The getResolutionVariant method could look like: >>>>>>>>>> -------------------------------------- >>>>>>>>>> public Image getResolutionVariant(float logicalDPIX, float >>>>>>>>>> logicalDPIY, >>>>>>>>>> float widthX, float widthY, AffineTransform >>>>>>>>>> transform); >>>>>>>>>> -------------------------------------- >>>>>>>>>> >>>>>>>>>>> If the image is known (either passed as an argument or the >>>>>>>>>>> method is >>>>>>>>>>> called on the image), then it can provide the original WH. >>>>>>>>>>> >>>>>>>>>>>> The MultiResolutionImage default implementation could allow >>>>>>>>>>>> to use >>>>>>>>>>>> different strategies like scale factor/transfom/OS based >>>>>>>>>>>> to query a resolution variant. The OS based strategy can be >>>>>>>>>>>> used by >>>>>>>>>>>> default. >>>>>>>>>>> >>>>>>>>>>> For Mac policy, all we need is the transformed dimensions, >>>>>>>>>>> which >>>>>>>>>>> can >>>>>>>>>>> be passed in as FP for generality. For Windows policy, all we >>>>>>>>>>> need >>>>>>>>>>> is logical DPI for the screen. What other information >>>>>>>>>>> would we >>>>>>>>>>> need, or would an algorithm like to use, that can't be computed >>>>>>>>>>> from >>>>>>>>>>> those 2 pieces? >>>>>>>>>> The aim is to provide a base class that can be used to >>>>>>>>>> create a >>>>>>>>>> MultiResolutionImage like: >>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/diff/ae53ebce5fa3/src/share/classes/sun/awt/image/MultiResolutionBufferedImage.java >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A developer should be able to implement a custom >>>>>>>>>> algorithm to >>>>>>>>>> query a resolution variant. >>>>>>>>>> >>>>>>>>>> It can be done by overriding the getResolutionVariant image: >>>>>>>>>> ----------------------- >>>>>>>>>> Image mrImage = new MultiResolutionBufferedImage(){ >>>>>>>>>> @Override >>>>>>>>>> public Image getResolutionVariant(...) { >>>>>>>>>> // Custom logic here >>>>>>>>>> } >>>>>>>>>> }; >>>>>>>>>> ----------------------- >>>>>>>>>> >>>>>>>>>> Or it can be done by using resolution variant choosers so a >>>>>>>>>> developer can implement custom resolution variant query: >>>>>>>>>> ----------------------- >>>>>>>>>> public class MultiResolutionBufferedImage implements >>>>>>>>>> MultiResolutionImage{ >>>>>>>>>> >>>>>>>>>> interface ResolutionVariantChooser{ >>>>>>>>>> Image getResolutionVariant(dpi, size,..., List >>>>>>>>>> resolutionVariants); >>>>>>>>>> } >>>>>>>>>> ResolutionVariantChooser TRANSFORM_BASED = null; >>>>>>>>>> ResolutionVariantChooser DPI_BASED = null; >>>>>>>>>> >>>>>>>>>> ResolutionVariantChooser rvChooser; >>>>>>>>>> >>>>>>>>>> @Override >>>>>>>>>> public Image getResolutionVariant(dpi, size,...,) { >>>>>>>>>> return rvChooser.getResolutionVariant(dpi, size,..., >>>>>>>>>> getResolutionVariants()); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> ----------------------- >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ...jim >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2/13/2014 4:42 AM, Jim Graham wrote: >>>>>>>>>>>>> On 2/12/14 5:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> On 2/8/2014 4:19 AM, Jim Graham wrote: >>>>>>>>>>>>>>> The primary thing that I was concerned about was the >>>>>>>>>>>>>>> presence of >>>>>>>>>>>>>>> integers in the API when Windows uses non-integer multiples >>>>>>>>>>>>>> It would make sense to pass real numbers to the >>>>>>>>>>>>>> getResolutionVariant() method if the difference between >>>>>>>>>>>>>> resolution >>>>>>>>>>>>>> variants sizes is 1. >>>>>>>>>>>>>> It seems that it is not a common case. >>>>>>>>>>>>> >>>>>>>>>>>>> I was thinking of other API that is related to this, such as >>>>>>>>>>>>> the API >>>>>>>>>>>>> that queries the scaling factor from a SurfaceManager. I >>>>>>>>>>>>> seem to >>>>>>>>>>>>> remember some integer return values in that, but Windows >>>>>>>>>>>>> might >>>>>>>>>>>>> have >>>>>>>>>>>>> the answer 1.4 or 1.8, depending on the screen scaling factor >>>>>>>>>>>>> that was >>>>>>>>>>>>> determined from the UI. >>>>>>>>>>>>> >>>>>>>>>>>>> In terms of the getResolutionVariant() method here, those >>>>>>>>>>>>> non-integer >>>>>>>>>>>>> screen scaling factors don't directly impact this API. >>>>>>>>>>>>> But, we >>>>>>>>>>>>> have >>>>>>>>>>>>> some issues with the use of integers there from other >>>>>>>>>>>>> sources: >>>>>>>>>>>>> >>>>>>>>>>>>> - That API assumes that the caller will determine the pixel >>>>>>>>>>>>> size >>>>>>>>>>>>> needed, but the actual media choice is determined with >>>>>>>>>>>>> different >>>>>>>>>>>>> techniques on Mac and Windows so this means that the caller >>>>>>>>>>>>> will >>>>>>>>>>>>> have >>>>>>>>>>>>> to worry about platform conventions. Is that the right >>>>>>>>>>>>> tradeoff? >>>>>>>>>>>>> >>>>>>>>>>>>> - The technique recommended for Mac involves computing the >>>>>>>>>>>>> precise >>>>>>>>>>>>> size desired using the current transform, which may be a >>>>>>>>>>>>> floating >>>>>>>>>>>>> point value, so the integer values used in this API are >>>>>>>>>>>>> already >>>>>>>>>>>>> approximations and there is no documentation on how to >>>>>>>>>>>>> generate the >>>>>>>>>>>>> proper integer. In particular, the current code in SG2D >>>>>>>>>>>>> naively >>>>>>>>>>>>> uses >>>>>>>>>>>>> a cast to integer to determine the values to supply which >>>>>>>>>>>>> means a >>>>>>>>>>>>> transformed size of W+0.5 will be truncated to W and the >>>>>>>>>>>>> lower >>>>>>>>>>>>> resolution image will be used. Does that conform to Mac >>>>>>>>>>>>> guidelines? Do >>>>>>>>>>>>> they require the truncated size to reach W+1 before the next >>>>>>>>>>>>> size is >>>>>>>>>>>>> used? Passing in float or double values would sidestep >>>>>>>>>>>>> all of >>>>>>>>>>>>> that >>>>>>>>>>>>> since then the comparisons would be done with full precision, >>>>>>>>>>>>> but as >>>>>>>>>>>>> long as we can determine a "best practices compatible with >>>>>>>>>>>>> all >>>>>>>>>>>>> platforms" rule on how to round to integers, then integers >>>>>>>>>>>>> are OK >>>>>>>>>>>>> there. >>>>>>>>>>>>> >>>>>>>>>>>>> - The Windows document you cite below suggests that the >>>>>>>>>>>>> determination >>>>>>>>>>>>> should be made by looking at the Screen DPI and choosing the >>>>>>>>>>>>> next >>>>>>>>>>>>> higher media variant based on that screen DPI. They do not >>>>>>>>>>>>> specify >>>>>>>>>>>>> choosing media based on the current transform as is done for >>>>>>>>>>>>> Mac. If >>>>>>>>>>>>> we stick with supplying values that are used to determine >>>>>>>>>>>>> which >>>>>>>>>>>>> media >>>>>>>>>>>>> to use, then on Windows we should not take the transform into >>>>>>>>>>>>> account, >>>>>>>>>>>>> but instead query the SurfaceManager for the scale factor and >>>>>>>>>>>>> only >>>>>>>>>>>>> transform by those values (even if the current transform was >>>>>>>>>>>>> manually >>>>>>>>>>>>> overridden to identity). >>>>>>>>>>>>> >>>>>>>>>>>>> There are pros and cons to both approaches. >>>>>>>>>>>>> >>>>>>>>>>>>> Mac ensures that you are always using the best media for any >>>>>>>>>>>>> given >>>>>>>>>>>>> render operation. >>>>>>>>>>>>> >>>>>>>>>>>>> But, Windows ensure more consistency in the face of other >>>>>>>>>>>>> scaling. >>>>>>>>>>>>> >>>>>>>>>>>>> The thing to consider is that if you have a 500x500 image >>>>>>>>>>>>> with a >>>>>>>>>>>>> 1000x1000 variant and you rendering it at 500x500 and then >>>>>>>>>>>>> 501x501, >>>>>>>>>>>>> that first jump will be fairly jarring as the scaled version >>>>>>>>>>>>> of the >>>>>>>>>>>>> 1000x1000 will not look precisely like the original 500x500 >>>>>>>>>>>>> did. >>>>>>>>>>>>> With >>>>>>>>>>>>> @2x images only, this effect is minimized so the advantage of >>>>>>>>>>>>> always >>>>>>>>>>>>> using "the best media for a given render operation" may >>>>>>>>>>>>> outweigh the >>>>>>>>>>>>> inconsistency issue. But, on Windows where the media are >>>>>>>>>>>>> 1.4x or >>>>>>>>>>>>> 1.8x >>>>>>>>>>>>> in size, a downscaled image will start to show more >>>>>>>>>>>>> interpolation >>>>>>>>>>>>> noise and so the balance of the two choices may shift more >>>>>>>>>>>>> towards not >>>>>>>>>>>>> wanting a jarring shift. >>>>>>>>>>>>> >>>>>>>>>>>>> We might want one or more of the following: >>>>>>>>>>>>> >>>>>>>>>>>>> - Developer chooses policy (TX_AWARE, DPI_AWARE, >>>>>>>>>>>>> ALWAYS_LARGEST, >>>>>>>>>>>>> NONE, >>>>>>>>>>>>> PLATFORM) where the last policy would use TX_AWARE on Mac and >>>>>>>>>>>>> DPI_AWARE on Windows >>>>>>>>>>>>> >>>>>>>>>>>>> - We create our own policy and always use it (TX_AWARE? or >>>>>>>>>>>>> DPI_AWARE?) >>>>>>>>>>>>> >>>>>>>>>>>>> - We create our own policy that dynamically chooses one of >>>>>>>>>>>>> the >>>>>>>>>>>>> above >>>>>>>>>>>>> strategies depending on platform or available media or ??? >>>>>>>>>>>>> >>>>>>>>>>>>> - We could create an optional interface for them to install >>>>>>>>>>>>> their >>>>>>>>>>>>> own >>>>>>>>>>>>> algorithm as well. I think it would work best as a delegate >>>>>>>>>>>>> interface >>>>>>>>>>>>> that one installs into Image so that it can be used with any >>>>>>>>>>>>> image >>>>>>>>>>>>> without having to subclass (it wouldn't really have much >>>>>>>>>>>>> to do >>>>>>>>>>>>> for >>>>>>>>>>>>> BufferedImages or VolatileImages, though): >>>>>>>>>>>>> >>>>>>>>>>>>> class Image { >>>>>>>>>>>>> void setResolutionHelper(ImageResolutionHelper foo); >>>>>>>>>>>>> List getResolutionVariants(); >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> or: >>>>>>>>>>>>> >>>>>>>>>>>>> class Graphics { >>>>>>>>>>>>> void setResolutionHelper(ImageResolutionHelper foo); >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> or - anywhere else it could be installed more centrally (per >>>>>>>>>>>>> App >>>>>>>>>>>>> context)? >>>>>>>>>>>>> >>>>>>>>>>>>> and the interface would be something like one of these >>>>>>>>>>>>> variants: >>>>>>>>>>>>> >>>>>>>>>>>>> interface ImageResolutionHelper { >>>>>>>>>>>>> // This version would prevent substituting a random >>>>>>>>>>>>> image: >>>>>>>>>>>>> // They have to return an index into the List for >>>>>>>>>>>>> that >>>>>>>>>>>>> image... >>>>>>>>>>>>> public int chooseVariant(Image img, double dpi, number w, >>>>>>>>>>>>> number h); >>>>>>>>>>>>> >>>>>>>>>>>>> or: >>>>>>>>>>>>> >>>>>>>>>>>>> // This version would allow substituting an arbitrary >>>>>>>>>>>>> image: >>>>>>>>>>>>> public Image getVariant(Image img, double dpi, number w, >>>>>>>>>>>>> number >>>>>>>>>>>>> h); >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> Since they would be in full control of the policy, though, we >>>>>>>>>>>>> would >>>>>>>>>>>>> unfortunately always have to call this, there would be no >>>>>>>>>>>>> more >>>>>>>>>>>>> testing >>>>>>>>>>>>> in SG2D to see "if" we need to deal with DPI, though >>>>>>>>>>>>> perhaps we >>>>>>>>>>>>> could >>>>>>>>>>>>> document some internal conditions in which we do not call it >>>>>>>>>>>>> for >>>>>>>>>>>>> common cases (but that would have to be well agreed not to >>>>>>>>>>>>> get in >>>>>>>>>>>>> the >>>>>>>>>>>>> way of reasonable uses of the API and well documented)? >>>>>>>>>>>>> >>>>>>>>>>>>> Note that we would have to do a security audit to make sure >>>>>>>>>>>>> that >>>>>>>>>>>>> random image substitution couldn't allow any sort of "screen >>>>>>>>>>>>> phishing" >>>>>>>>>>>>> exploit. >>>>>>>>>>>>> >>>>>>>>>>>>> ...jim >>>>>>>>>>>>> >>>>>>>>>>>>>>> and also what policy they use for choosing scaled images. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't see a mention of taking the current transform into >>>>>>>>>>>>>>> account, >>>>>>>>>>>>>>> just physical issues like screen DPI and form factor. They >>>>>>>>>>>>>>> talk >>>>>>>>>>>>>>> about >>>>>>>>>>>>>>> resolution plateaus and in their recommendations section >>>>>>>>>>>>>>> they >>>>>>>>>>>>>>> tell the >>>>>>>>>>>>>>> developer to use a particular property that tells them the >>>>>>>>>>>>>>> screen >>>>>>>>>>>>>>> resolution to figure out which image to load if they are >>>>>>>>>>>>>>> loading >>>>>>>>>>>>>>> manually. There is no discussion about dynamically loading >>>>>>>>>>>>>>> multiple >>>>>>>>>>>>>>> versions of the image based on a dynamic program-applied >>>>>>>>>>>>>>> transform >>>>>>>>>>>>>>> factor as is done on MacOS. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also, they tell developers to draw images to a specific >>>>>>>>>>>>>>> size >>>>>>>>>>>>>>> rather >>>>>>>>>>>>>>> than using auto-sizing. That begs the question as to how >>>>>>>>>>>>>>> they >>>>>>>>>>>>>>> interpret a call to draw an image just using a location in >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> presence of various DPI factors. >>>>>>>>>>>>>> There is an interesting doc that describes how to >>>>>>>>>>>>>> write >>>>>>>>>>>>>> DPI-aware >>>>>>>>>>>>>> Win32 applications: >>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464646%28v=vs.85%29.aspx >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is suggested to handle WM_DPICHANGED message, load >>>>>>>>>>>>>> the >>>>>>>>>>>>>> graphic >>>>>>>>>>>>>> that has slightly greater resolution to the current DPI and >>>>>>>>>>>>>> use >>>>>>>>>>>>>> StretchBlt >>>>>>>>>>>>>> to scale down the image. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2/7/14 3:00 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>> On 1/22/2014 6:40 AM, Jim Graham wrote: >>>>>>>>>>>>>>>>> Hi Alexander, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Before we get too far down the road on this API, I >>>>>>>>>>>>>>>>> think we >>>>>>>>>>>>>>>>> understand >>>>>>>>>>>>>>>>> the way in which MacOS processes multi-resolution images >>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>> HiDPI >>>>>>>>>>>>>>>>> screens, but have we investigated the processes that >>>>>>>>>>>>>>>>> Windows >>>>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>>>> under Windows 8? My impression is that Windows 8 has >>>>>>>>>>>>>>>>> included a >>>>>>>>>>>>>>>>> number of new techniques for dealing with the high >>>>>>>>>>>>>>>>> resolution >>>>>>>>>>>>>>>>> displays >>>>>>>>>>>>>>>>> that it will run on in the Windows tablet and mobile >>>>>>>>>>>>>>>>> industries >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> that these will also come into play as 4K displays >>>>>>>>>>>>>>>>> (already >>>>>>>>>>>>>>>>> available) >>>>>>>>>>>>>>>>> become more common on the desktop. We should make sure >>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>> what we >>>>>>>>>>>>>>>>> come up with here can provide native compatibility with >>>>>>>>>>>>>>>>> either >>>>>>>>>>>>>>>>> platform's policies and standard practices. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If you've investigated the MS policies I'd like to see a >>>>>>>>>>>>>>>>> summary so >>>>>>>>>>>>>>>>> that we can consider them as we review this API... >>>>>>>>>>>>>>>> There is the Windows Guidelines for scaling to pixel >>>>>>>>>>>>>>>> density: >>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> which says that Windows has automatic resource loading >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> supports >>>>>>>>>>>>>>>> three version of images scaling (100%, 140%, and 180%) >>>>>>>>>>>>>>>> -------------------------------- >>>>>>>>>>>>>>>> Without scaling, as the pixel density of a display device >>>>>>>>>>>>>>>> increases, the >>>>>>>>>>>>>>>> physical sizes of objects on screen get smaller. >>>>>>>>>>>>>>>> When UI would otherwise be too small to touch and when >>>>>>>>>>>>>>>> text >>>>>>>>>>>>>>>> gets >>>>>>>>>>>>>>>> too >>>>>>>>>>>>>>>> small to read, >>>>>>>>>>>>>>>> Windows scales the system and app UI to one of the >>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>> scaling >>>>>>>>>>>>>>>> plateaus: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1.0 (100%, no scaling is applied) >>>>>>>>>>>>>>>> 1.4 (140% scaling) >>>>>>>>>>>>>>>> 1.8 (180% scaling) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Windows determines which scaling plateau to use based >>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>> physical >>>>>>>>>>>>>>>> screen size, the screen resolution, the DPI of the >>>>>>>>>>>>>>>> screen, and >>>>>>>>>>>>>>>> form >>>>>>>>>>>>>>>> factor. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Use resource loading for bitmap images in the app package >>>>>>>>>>>>>>>> For >>>>>>>>>>>>>>>> bitmap >>>>>>>>>>>>>>>> images stored >>>>>>>>>>>>>>>> in the app package, provide a separate image for each >>>>>>>>>>>>>>>> scaling >>>>>>>>>>>>>>>> factor(100%, 140%, and 180%), >>>>>>>>>>>>>>>> and name your image files using the "scale" naming >>>>>>>>>>>>>>>> convention >>>>>>>>>>>>>>>> described >>>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>>> Windows loads the right image for the current scale >>>>>>>>>>>>>>>> automatically. >>>>>>>>>>>>>>>> -------------------------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The image name convention for the various scales is: >>>>>>>>>>>>>>>> images/logo.scale-100.png >>>>>>>>>>>>>>>> images/logo.scale-140.png >>>>>>>>>>>>>>>> images/logo.scale-180.png >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The 'ms-appx:///images/logo.png' uri is used to load >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> image >>>>>>>>>>>>>>>> in an >>>>>>>>>>>>>>>> application. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If we want to support this in the same way as it is >>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>> for Mac >>>>>>>>>>>>>>>> OS X >>>>>>>>>>>>>>>> the WToolkit should return MultiResolution image in >>>>>>>>>>>>>>>> case if >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> loaded image has .scale-* qualifiers. >>>>>>>>>>>>>>>> The Graphics class can request an image with necessary >>>>>>>>>>>>>>>> resolution >>>>>>>>>>>>>>>> from the MultiResolution image. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It seems that nothing should be changed in the >>>>>>>>>>>>>>>> MultiResolution >>>>>>>>>>>>>>>> interface in this case. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 1/14/14 2:54 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8029339 >>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.00 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This is a proposal to introduce an API that allows to >>>>>>>>>>>>>>>>>> create a >>>>>>>>>>>>>>>>>> custom >>>>>>>>>>>>>>>>>> multi resolution image. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I. It seems reasonable that the API should provide two >>>>>>>>>>>>>>>>>> basic >>>>>>>>>>>>>>>>>> operations: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1. Get the resolution variant based on the requested >>>>>>>>>>>>>>>>>> image >>>>>>>>>>>>>>>>>> width and >>>>>>>>>>>>>>>>>> height: >>>>>>>>>>>>>>>>>> - Image getResolutionVariant(int width, int height) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Usually the system provides the scale factor which >>>>>>>>>>>>>>>>>> represents >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> number of pixels corresponding to each linear unit on >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> display. >>>>>>>>>>>>>>>>>> However, it has sense to combine the scale factor >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>>>> transformations to get the actual image size to be >>>>>>>>>>>>>>>>>> displayed. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2. Get all provided resolution variants: >>>>>>>>>>>>>>>>>> - List getResolutionVariants() >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There are several uses cases: >>>>>>>>>>>>>>>>>> - Create a new multi-resolution image based on the >>>>>>>>>>>>>>>>>> given >>>>>>>>>>>>>>>>>> multi-resolution image. >>>>>>>>>>>>>>>>>> - Pass to the native system the multi-resolution >>>>>>>>>>>>>>>>>> image. For >>>>>>>>>>>>>>>>>> example, >>>>>>>>>>>>>>>>>> a use can set to the system the custom multi-resolution >>>>>>>>>>>>>>>>>> cursor. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> II. There are some possible ways where the new API >>>>>>>>>>>>>>>>>> can be >>>>>>>>>>>>>>>>>> added >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1. java.awt.Image. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The 2 new methods can be added to the Image class. A >>>>>>>>>>>>>>>>>> user >>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>> override >>>>>>>>>>>>>>>>>> the getResolutionVariant() and >>>>>>>>>>>>>>>>>> getResolutionVariants() >>>>>>>>>>>>>>>>>> methods to >>>>>>>>>>>>>>>>>> provide the resolution variants >>>>>>>>>>>>>>>>>> or there can be default implementations of these >>>>>>>>>>>>>>>>>> methods >>>>>>>>>>>>>>>>>> if a >>>>>>>>>>>>>>>>>> user >>>>>>>>>>>>>>>>>> puts resolution variants >>>>>>>>>>>>>>>>>> to the list in the sorted order. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> To check that the image has resolution variants the >>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>> statement can be used: >>>>>>>>>>>>>>>>>> image.getResolutionVariants().size() >>>>>>>>>>>>>>>>>> != 1 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The disadvantage is that there is an overhead that >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> Image >>>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>>> should contain the List object and not all >>>>>>>>>>>>>>>>>> images can have resolution variants. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2. Introduce new MultiResolutionImage interface. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> A user should extend Image class and implement the >>>>>>>>>>>>>>>>>> MultiResolutionImage interface. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> For example: >>>>>>>>>>>>>>>>>> --------------------- >>>>>>>>>>>>>>>>>> public class CustomMultiResolutionImage extends >>>>>>>>>>>>>>>>>> BufferedImage >>>>>>>>>>>>>>>>>> implements MultiResolutionImage { >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Image highResolutionImage; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> public CustomMultiResolutionImage(BufferedImage >>>>>>>>>>>>>>>>>> baseImage, >>>>>>>>>>>>>>>>>> BufferedImage highResolutionImage) { >>>>>>>>>>>>>>>>>> super(baseImage.getWidth(), >>>>>>>>>>>>>>>>>> baseImage.getHeight(), >>>>>>>>>>>>>>>>>> baseImage.getType()); >>>>>>>>>>>>>>>>>> this.highResolutionImage = highResolutionImage; >>>>>>>>>>>>>>>>>> Graphics g = getGraphics(); >>>>>>>>>>>>>>>>>> g.drawImage(baseImage, 0, 0, null); >>>>>>>>>>>>>>>>>> g.dispose(); >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>>>>> public Image getResolutionVariant(int width, >>>>>>>>>>>>>>>>>> int >>>>>>>>>>>>>>>>>> height) { >>>>>>>>>>>>>>>>>> return ((width <= getWidth() && height <= >>>>>>>>>>>>>>>>>> getHeight())) >>>>>>>>>>>>>>>>>> ? this : highResolutionImage; >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>>>>> public List getResolutionVariants() { >>>>>>>>>>>>>>>>>> return Arrays.asList(this, >>>>>>>>>>>>>>>>>> highResolutionImage); >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> --------------------- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The current fix adds the MultiResolutionImage >>>>>>>>>>>>>>>>>> interface >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> public >>>>>>>>>>>>>>>>>> resolution variant rendering hints. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> From petr.pchelko at oracle.com Mon Apr 28 09:50:59 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 28 Apr 2014 13:50:59 +0400 Subject: [9] Review request: 8041987 [macosx] setDisplayMode crashes Message-ID: <0ED80700-796C-4AA0-BD0E-2E30ACA5B2C3@oracle.com> Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8041987 The fix is available at: http://cr.openjdk.java.net/~pchelko/9/8041987/ My recent fix with memory leak uncovered one more issue: in nativeSetDisplayMode the reference obtained outside of the block we use in the block. That's fine for Objective-C pointers, because they are auto-retained and autoreleased in this case. But for core foundation types we need to retain/release them manually. I've run all GraphicsDevice/GraphicsConfiguration/Fullscreen tests. I've also briefly skimmed the codebase for similar issues, but didn't find any obvious problems of such kind. Also I'm open-sourcing the tests which found the problem. With best regards. Petr. From anthony.petrov at oracle.com Mon Apr 28 12:19:31 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 28 Apr 2014 16:19:31 +0400 Subject: [9] Review request: 8041987 [macosx] setDisplayMode crashes In-Reply-To: <0ED80700-796C-4AA0-BD0E-2E30ACA5B2C3@oracle.com> References: <0ED80700-796C-4AA0-BD0E-2E30ACA5B2C3@oracle.com> Message-ID: <535E4753.5000407@oracle.com> Hi Petr, The fix looks fine. -- best regards, Anthony On 4/28/2014 1:50 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8041987 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8041987/ > > My recent fix with memory leak uncovered one more issue: in nativeSetDisplayMode the reference obtained outside of the block we use in the block. > That's fine for Objective-C pointers, because they are auto-retained and autoreleased in this case. But for core foundation types we need to retain/release > them manually. I've run all GraphicsDevice/GraphicsConfiguration/Fullscreen tests. I've also briefly skimmed the codebase for similar issues, but didn't find > any obvious problems of such kind. > > Also I'm open-sourcing the tests which found the problem. > > With best regards. Petr. > From Sergey.Bylokhov at oracle.com Mon Apr 28 12:33:04 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 28 Apr 2014 16:33:04 +0400 Subject: [9] Review request: 8041987 [macosx] setDisplayMode crashes In-Reply-To: <0ED80700-796C-4AA0-BD0E-2E30ACA5B2C3@oracle.com> References: <0ED80700-796C-4AA0-BD0E-2E30ACA5B2C3@oracle.com> Message-ID: <535E4A80.70304@oracle.com> Hi, Petr. The fix looks good. On 4/28/14 1:50 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8041987 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8041987/ > > My recent fix with memory leak uncovered one more issue: in nativeSetDisplayMode the reference obtained outside of the block we use in the block. > That's fine for Objective-C pointers, because they are auto-retained and autoreleased in this case. But for core foundation types we need to retain/release > them manually. I've run all GraphicsDevice/GraphicsConfiguration/Fullscreen tests. I've also briefly skimmed the codebase for similar issues, but didn't find > any obvious problems of such kind. > > Also I'm open-sourcing the tests which found the problem. > > With best regards. Petr. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Apr 28 16:33:22 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 28 Apr 2014 20:33:22 +0400 Subject: [9] Review Request: 8042007 Javadoc cleanup of javax.sound.sampled.spi package Message-ID: <535E82D2.4040101@oracle.com> Hello. Please review another one javadoc "weekend cleanup" in jdk 9 in sound area. - 80 column limit - replaced to @tags - empty line after description/before the first tag - sets of spaces in the middle of text were deleted - @param, @throws, @return now align, to be more readable Bug: https://bugs.openjdk.java.net/browse/JDK-8042007 Webrev can be found at: http://cr.openjdk.java.net/~serb/8042007/webrev.00 -- Best regards, Sergey. From petr.pchelko at oracle.com Tue Apr 29 08:32:01 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 29 Apr 2014 12:32:01 +0400 Subject: [9] Review Request: JDK-8042087 [macosx] LWCToolkit.inokeAndWait is calling EventQueue.invokeLater Message-ID: <1D7DB08D-48E5-4633-9D65-23FC90D2F0F8@oracle.com> Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8042087 The fix is available at: http://cr.openjdk.java.net/~pchelko/9/8042087/webrev/ The problem is that we are using EventQueue.invokeLater on the Toolkit thread. In applet mode this would fail with NPE. So I've removed the non-working code branch, made general cleanup and added a null check for the component provided to invokeAndWait and invokeLater methods. We don't have open bugs on Mac about NPE in applet mode, so most likely the removed branch was never executed. But with this fix we would catch possible errors early. With best regards. Petr. From yuri.nesterenko at oracle.com Tue Apr 29 08:42:45 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Tue, 29 Apr 2014 12:42:45 +0400 Subject: [9] Review Request for 8041592: [TEST_BUG] Move 42 AWT hw/lw mixing tests to jdk In-Reply-To: <535A4D9D.2060701@oracle.com> References: <5358D8B4.1090407@oracle.com> <535A4D9D.2060701@oracle.com> Message-ID: <535F6605.9040600@oracle.com> Could anyone please look at this, too: we need 2 reviewers to go on. And thank you Anthony! -yan On 04/25/2014 03:57 PM, Anthony Petrov wrote: > Hi Yuri, > > Great to see more tests covering the HW/LW Mixing functionality coming > in! I briefly skimmed through the patch, and it looks good to me. > > -- > best regards, > Anthony > > On 4/24/2014 1:26 PM, Yuri Nesterenko wrote: >> Hi, >> >> please review this change for >> https://bugs.openjdk.java.net/browse/JDK-8041592 >> >> Webrev is in: >> http://cr.openjdk.java.net/~yan/8041592/webrev.00/ >> >> Thanks, >> -yan >> >> Here's an excerpt from the bug Description: >> ________________________________________ >> >> There are 42 automatic functional tests verifying various aspects of >> HW/LW mixing in AWT. We will move them to a separate directory >> test/java/awt/Mixing/AWT_Mixing/. >> >> Note that: >> (1) we decided to make only small changes to the tests as it is just >> some 5% of our task at hand; >> (2) tests are written in someway different styles; >> (3) most of them extend some basic class (included in the >> same directory); >> (4) they use an utility class (included) someway duplicating new >> functionality of ExtendedRobot. However we left this part intact to >> avoid unnecessary refactoring; >> (5) the tests seems stable enough. They were run on 3 platforms >> continuously many times together demonstrating exactly the same output. >> (6) Of the 42 in total, 3 fail on OS X (2 of them also on Linux and >> Windows) because of the open product bugs. >> From petr.pchelko at oracle.com Tue Apr 29 09:30:25 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 29 Apr 2014 13:30:25 +0400 Subject: [9] Review Request for 8041592: [TEST_BUG] Move 42 AWT hw/lw mixing tests to jdk In-Reply-To: <535F6605.9040600@oracle.com> References: <5358D8B4.1090407@oracle.com> <535A4D9D.2060701@oracle.com> <535F6605.9040600@oracle.com> Message-ID: <6D1B2A4F-09D8-4E3E-A92A-02D5EA4691E1@oracle.com> Hello, Yuri. I didn't look at every line, but generally the fix looks good to me. With best regards. Petr. On 29.04.2014, at 12:42, Yuri Nesterenko wrote: > Could anyone please look at this, too: we need 2 reviewers to go on. > And thank you Anthony! > > -yan > > On 04/25/2014 03:57 PM, Anthony Petrov wrote: >> Hi Yuri, >> >> Great to see more tests covering the HW/LW Mixing functionality coming >> in! I briefly skimmed through the patch, and it looks good to me. >> >> -- >> best regards, >> Anthony >> >> On 4/24/2014 1:26 PM, Yuri Nesterenko wrote: >>> Hi, >>> >>> please review this change for >>> https://bugs.openjdk.java.net/browse/JDK-8041592 >>> >>> Webrev is in: >>> http://cr.openjdk.java.net/~yan/8041592/webrev.00/ >>> >>> Thanks, >>> -yan >>> >>> Here's an excerpt from the bug Description: >>> ________________________________________ >>> >>> There are 42 automatic functional tests verifying various aspects of >>> HW/LW mixing in AWT. We will move them to a separate directory >>> test/java/awt/Mixing/AWT_Mixing/. >>> >>> Note that: >>> (1) we decided to make only small changes to the tests as it is just >>> some 5% of our task at hand; >>> (2) tests are written in someway different styles; >>> (3) most of them extend some basic class (included in the >>> same directory); >>> (4) they use an utility class (included) someway duplicating new >>> functionality of ExtendedRobot. However we left this part intact to >>> avoid unnecessary refactoring; >>> (5) the tests seems stable enough. They were run on 3 platforms >>> continuously many times together demonstrating exactly the same output. >>> (6) Of the 42 in total, 3 fail on OS X (2 of them also on Linux and >>> Windows) because of the open product bugs. >>> > From Sergey.Bylokhov at oracle.com Tue Apr 29 10:38:18 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 Apr 2014 14:38:18 +0400 Subject: [9] Review Request: JDK-8042087 [macosx] LWCToolkit.inokeAndWait is calling EventQueue.invokeLater In-Reply-To: <1D7DB08D-48E5-4633-9D65-23FC90D2F0F8@oracle.com> References: <1D7DB08D-48E5-4633-9D65-23FC90D2F0F8@oracle.com> Message-ID: <535F811A.5070505@oracle.com> On 4/29/14 12:32 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8042087 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8042087/webrev/ > > The problem is that we are using EventQueue.invokeLater on the Toolkit thread. I guess the fix changes getSystemEventQueueForInvokeAndWait().postEvent(), and EventQueue.invokeLater is used in another place of LWCToolkit in systemColorsChanged(). > In applet mode this would fail with NPE. So I've removed the non-working code branch, made general cleanup and added a null check for the component provided to invokeAndWait and invokeLater methods. > We don't have open bugs on Mac about NPE in applet mode, so most likely the removed branch was never executed. But with this fix we would catch possible errors early. > > With best regards. Petr. -- Best regards, Sergey. From dmitriy.ermashov at oracle.com Tue Apr 29 10:49:00 2014 From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov) Date: Tue, 29 Apr 2014 14:49:00 +0400 Subject: Review Request for 8041915: Move 8 awt tests to OpenJDK regression tests tree In-Reply-To: <0F2D6903-0F7C-45EA-88C4-1FE9852AA69D@oracle.com> References: <535A5D73.4090002@oracle.com> <0F2D6903-0F7C-45EA-88C4-1FE9852AA69D@oracle.com> Message-ID: <535F839C.2080408@oracle.com> Hi, Please review the changeset for https://bugs.openjdk.java.net/browse/JDK-8041915 Webrev is here: http://cr.openjdk.java.net/~yan/8041915/webrev.01/ Latest changes: 1. If some translucency mode is not supported, the test will pass with System.out warning message 2. New method dragAndDrop implemented in ExtendedRobot class Thanks, Dima On 04/25/2014 05:19 PM, Petr Pchelko wrote: > Hello, Dmitriy. > > A couple of questions: > > 1. checkTranslucencyMode throws an exception if some mode is not supported on the device, so the test would fail. Should it? Normally we just skip the test if some capability is absent. > 2. Didn't you consider moving the drag method into the ExtendedRobot? I expect it to be very commonly used. > > With best regards. Petr. > > On 25.04.2014, at 17:04, Dmitriy Ermashov wrote: > >> Hi, >> >> Please review the changeset for >> https://bugs.openjdk.java.net/browse/JDK-8041915 >> >> Webrev is here: >> http://cr.openjdk.java.net/~yan/8041915/webrev.00/ >> >> -- >> Thanks, >> Dima >> From petr.pchelko at oracle.com Tue Apr 29 11:04:31 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 29 Apr 2014 15:04:31 +0400 Subject: [9] Review Request: JDK-8042087 [macosx] LWCToolkit.inokeAndWait is calling EventQueue.invokeLater In-Reply-To: <535F811A.5070505@oracle.com> References: <1D7DB08D-48E5-4633-9D65-23FC90D2F0F8@oracle.com> <535F811A.5070505@oracle.com> Message-ID: <71BF37D8-3759-4989-8093-314A0AECAC1F@oracle.com> Hello, Sergey. >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8042087 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/8042087/webrev/ >> >> The problem is that we are using EventQueue.invokeLater on the Toolkit thread. > I guess the fix changes getSystemEventQueueForInvokeAndWait().postEvent(), and EventQueue.invokeLater is used in another place of LWCToolkit in systemColorsChanged(). >> In applet mode this would fail with NPE. So I've removed the non-working code branch, made general cleanup and added a null check for the component provided to invokeAndWait and invokeLater methods. Yes, I've called the bug incorrectly) It should be called "[macosx] LWCToolkit.inokeAndWait is relying on main AppContext".. Sorry for inaccuracy. I've renamed the issue. With best regards. Petr. On 29.04.2014, at 14:38, Sergey Bylokhov wrote: > On 4/29/14 12:32 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8042087 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/8042087/webrev/ >> >> The problem is that we are using EventQueue.invokeLater on the Toolkit thread. > I guess the fix changes getSystemEventQueueForInvokeAndWait().postEvent(), and EventQueue.invokeLater is used in another place of LWCToolkit in systemColorsChanged(). >> In applet mode this would fail with NPE. So I've removed the non-working code branch, made general cleanup and added a null check for the component provided to invokeAndWait and invokeLater methods. >> We don't have open bugs on Mac about NPE in applet mode, so most likely the removed branch was never executed. But with this fix we would catch possible errors early. >> >> With best regards. Petr. > > > -- > Best regards, Sergey. > From petr.pchelko at oracle.com Tue Apr 29 11:08:32 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 29 Apr 2014 15:08:32 +0400 Subject: Review Request for 8041915: Move 8 awt tests to OpenJDK regression tests tree In-Reply-To: <535F839C.2080408@oracle.com> References: <535A5D73.4090002@oracle.com> <0F2D6903-0F7C-45EA-88C4-1FE9852AA69D@oracle.com> <535F839C.2080408@oracle.com> Message-ID: <5A688155-BE6C-4893-A8A7-29CF5413BDF1@oracle.com> Hello, Dmitriy. The new version looks good. With best regards. Petr. On 29.04.2014, at 14:49, Dmitriy Ermashov wrote: > Hi, > > Please review the changeset for > https://bugs.openjdk.java.net/browse/JDK-8041915 > > Webrev is here: > http://cr.openjdk.java.net/~yan/8041915/webrev.01/ > > Latest changes: > 1. If some translucency mode is not supported, the test will pass with System.out warning message > 2. New method dragAndDrop implemented in ExtendedRobot class > > Thanks, > Dima > > On 04/25/2014 05:19 PM, Petr Pchelko wrote: >> Hello, Dmitriy. >> >> A couple of questions: >> >> 1. checkTranslucencyMode throws an exception if some mode is not supported on the device, so the test would fail. Should it? Normally we just skip the test if some capability is absent. >> 2. Didn't you consider moving the drag method into the ExtendedRobot? I expect it to be very commonly used. >> >> With best regards. Petr. >> >> On 25.04.2014, at 17:04, Dmitriy Ermashov wrote: >> >>> Hi, >>> >>> Please review the changeset for >>> https://bugs.openjdk.java.net/browse/JDK-8041915 >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~yan/8041915/webrev.00/ >>> >>> -- >>> Thanks, >>> Dima >>> > From Sergey.Bylokhov at oracle.com Tue Apr 29 11:14:56 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 Apr 2014 15:14:56 +0400 Subject: [9] Review Request for 8041592: [TEST_BUG] Move 42 AWT hw/lw mixing tests to jdk In-Reply-To: <535F6605.9040600@oracle.com> References: <5358D8B4.1090407@oracle.com> <535A4D9D.2060701@oracle.com> <535F6605.9040600@oracle.com> Message-ID: <535F89B0.2040403@oracle.com> Hi, Yuri. I think the patch quite big, so it is expected that it was not reviewed in 3 days. A few comments: - System.exit(1) is used in the tests and should be replaced by exception. - in some places empty "catch" block is used - JSplitPaneOverlapping.java LOONG line can be splitted. - in some place like JSplitPaneOverlapping.java we call to fail() and after call mouseRelease. This methods can be flipped - MixingFrameResizing.java skip osx. I think the test can override paint method for tested component and fill the whole component area with some solid color, instead of testing via setBackground(). - Looks like Util.java is the same file as jdk/test/java/awt/regtesthelpers/Util.java On 4/29/14 12:42 PM, Yuri Nesterenko wrote: > Could anyone please look at this, too: we need 2 reviewers to go on. > And thank you Anthony! > > -yan > > On 04/25/2014 03:57 PM, Anthony Petrov wrote: >> Hi Yuri, >> >> Great to see more tests covering the HW/LW Mixing functionality coming >> in! I briefly skimmed through the patch, and it looks good to me. >> >> -- >> best regards, >> Anthony >> >> On 4/24/2014 1:26 PM, Yuri Nesterenko wrote: >>> Hi, >>> >>> please review this change for >>> https://bugs.openjdk.java.net/browse/JDK-8041592 >>> >>> Webrev is in: >>> http://cr.openjdk.java.net/~yan/8041592/webrev.00/ >>> >>> Thanks, >>> -yan >>> >>> Here's an excerpt from the bug Description: >>> ________________________________________ >>> >>> There are 42 automatic functional tests verifying various aspects of >>> HW/LW mixing in AWT. We will move them to a separate directory >>> test/java/awt/Mixing/AWT_Mixing/. >>> >>> Note that: >>> (1) we decided to make only small changes to the tests as it is just >>> some 5% of our task at hand; >>> (2) tests are written in someway different styles; >>> (3) most of them extend some basic class (included in the >>> same directory); >>> (4) they use an utility class (included) someway duplicating new >>> functionality of ExtendedRobot. However we left this part intact to >>> avoid unnecessary refactoring; >>> (5) the tests seems stable enough. They were run on 3 platforms >>> continuously many times together demonstrating exactly the same output. >>> (6) Of the 42 in total, 3 fail on OS X (2 of them also on Linux and >>> Windows) because of the open product bugs. >>> > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuri.nesterenko at oracle.com Tue Apr 29 11:26:53 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Tue, 29 Apr 2014 15:26:53 +0400 Subject: [9] Review Request for 8041592: [TEST_BUG] Move 42 AWT hw/lw mixing tests to jdk In-Reply-To: <535F89B0.2040403@oracle.com> References: <5358D8B4.1090407@oracle.com> <535A4D9D.2060701@oracle.com> <535F6605.9040600@oracle.com> <535F89B0.2040403@oracle.com> Message-ID: <535F8C7D.30405@oracle.com> Thank you Sergey! Unfortunately I have already pushed the patch. I'll fix these oversights as a part of the next batch or as a separate bugfix. -yan On 04/29/2014 03:14 PM, Sergey Bylokhov wrote: > Hi, Yuri. > I think the patch quite big, so it is expected that it was not reviewed > in 3 days. > A few comments: > - System.exit(1) is used in the tests and should be replaced by exception. > - in some places empty "catch" block is used > - JSplitPaneOverlapping.java LOONG line can be splitted. > - in some place like JSplitPaneOverlapping.java we call to fail() and > after call mouseRelease. This methods can be flipped > - MixingFrameResizing.java skip osx. I think the test can override > paint method for tested component and fill the whole component area with > some solid color, instead of testing via setBackground(). > - Looks like Util.java is the same file as > jdk/test/java/awt/regtesthelpers/Util.java > > On 4/29/14 12:42 PM, Yuri Nesterenko wrote: >> Could anyone please look at this, too: we need 2 reviewers to go on. >> And thank you Anthony! >> >> -yan >> >> On 04/25/2014 03:57 PM, Anthony Petrov wrote: >>> Hi Yuri, >>> >>> Great to see more tests covering the HW/LW Mixing functionality coming >>> in! I briefly skimmed through the patch, and it looks good to me. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/24/2014 1:26 PM, Yuri Nesterenko wrote: >>>> Hi, >>>> >>>> please review this change for >>>> https://bugs.openjdk.java.net/browse/JDK-8041592 >>>> >>>> Webrev is in: >>>> http://cr.openjdk.java.net/~yan/8041592/webrev.00/ >>>> >>>> Thanks, >>>> -yan >>>> >>>> Here's an excerpt from the bug Description: >>>> ________________________________________ >>>> >>>> There are 42 automatic functional tests verifying various aspects of >>>> HW/LW mixing in AWT. We will move them to a separate directory >>>> test/java/awt/Mixing/AWT_Mixing/. >>>> >>>> Note that: >>>> (1) we decided to make only small changes to the tests as it is just >>>> some 5% of our task at hand; >>>> (2) tests are written in someway different styles; >>>> (3) most of them extend some basic class (included in the >>>> same directory); >>>> (4) they use an utility class (included) someway duplicating new >>>> functionality of ExtendedRobot. However we left this part intact to >>>> avoid unnecessary refactoring; >>>> (5) the tests seems stable enough. They were run on 3 platforms >>>> continuously many times together demonstrating exactly the same output. >>>> (6) Of the 42 in total, 3 fail on OS X (2 of them also on Linux and >>>> Windows) because of the open product bugs. >>>> >> > > > -- > Best regards, Sergey. > From anthony.petrov at oracle.com Tue Apr 29 17:37:59 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 29 Apr 2014 21:37:59 +0400 Subject: [9] Review Request: JDK-8042087 [macosx] LWCToolkit.inokeAndWait is calling EventQueue.invokeLater In-Reply-To: <71BF37D8-3759-4989-8093-314A0AECAC1F@oracle.com> References: <1D7DB08D-48E5-4633-9D65-23FC90D2F0F8@oracle.com> <535F811A.5070505@oracle.com> <71BF37D8-3759-4989-8093-314A0AECAC1F@oracle.com> Message-ID: <535FE377.5060903@oracle.com> Hi Petr, While the bug description and the solution sound reasonable, I'm still a bit concerned about the presence of the if(component==null) branch in the old code. I see that the code has been updated recently (with lambdas and friends), and is aware of the app contexts thing. So someone who wrote it, added that branch consciously. Or left it there from the former version of the code that might not be aware of the app contexts problems. In either case, w/o knowing why the branch is there in the first place, it seems a bit scary to just chop it off. Could you please investigate a bit more and provide some details so that we could be sure this change doesn't cause any regressions? -- best regards, Anthony On 4/29/2014 3:04 PM, Petr Pchelko wrote: > Hello, Sergey. > >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8042087 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/9/8042087/webrev/ >>> >>> The problem is that we are using EventQueue.invokeLater on the Toolkit thread. >> I guess the fix changes getSystemEventQueueForInvokeAndWait().postEvent(), and EventQueue.invokeLater is used in another place of LWCToolkit in systemColorsChanged(). >>> In applet mode this would fail with NPE. So I've removed the non-working code branch, made general cleanup and added a null check for the component provided to invokeAndWait and invokeLater methods. > Yes, I've called the bug incorrectly) It should be called "[macosx] LWCToolkit.inokeAndWait is relying on main AppContext".. Sorry for inaccuracy. I've renamed the issue. > > With best regards. Petr. > > On 29.04.2014, at 14:38, Sergey Bylokhov wrote: > >> On 4/29/14 12:32 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8042087 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/9/8042087/webrev/ >>> >>> The problem is that we are using EventQueue.invokeLater on the Toolkit thread. >> I guess the fix changes getSystemEventQueueForInvokeAndWait().postEvent(), and EventQueue.invokeLater is used in another place of LWCToolkit in systemColorsChanged(). >>> In applet mode this would fail with NPE. So I've removed the non-working code branch, made general cleanup and added a null check for the component provided to invokeAndWait and invokeLater methods. >>> We don't have open bugs on Mac about NPE in applet mode, so most likely the removed branch was never executed. But with this fix we would catch possible errors early. >>> >>> With best regards. Petr. >> >> >> -- >> Best regards, Sergey. >> > From petr.pchelko at oracle.com Tue Apr 29 17:54:07 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 29 Apr 2014 21:54:07 +0400 Subject: [9] Review Request: JDK-8042087 [macosx] LWCToolkit.inokeAndWait is calling EventQueue.invokeLater In-Reply-To: <535FE377.5060903@oracle.com> References: <1D7DB08D-48E5-4633-9D65-23FC90D2F0F8@oracle.com> <535F811A.5070505@oracle.com> <71BF37D8-3759-4989-8093-314A0AECAC1F@oracle.com> <535FE377.5060903@oracle.com> Message-ID: <712FA8DC-3C36-4FA7-A5E9-062C5EBE689C@oracle.com> Hello, Anthony. Than you for the review. > While the bug description and the solution sound reasonable, I'm still a bit concerned about the presence of the if(component==null) branch in the old code. I see that the code has been updated recently (with lambdas and friends), and is aware of the app contexts thing. So someone who wrote it, added that branch consciously. Or left it there from the former version of the code that might not be aware of the app contexts problems. In either case, w/o knowing why the branch is there in the first place, it seems a bit scary to just chop it off. > Could you please investigate a bit more and provide some details so that we could be sure this change doesn't cause any regressions? I?ve updated this code many times and the null branch was there from the very beginning. At first Appkit thread was in the main thread group, so this branch could work and it was scary to remove it. It was obviously wrong for security reasons, because it was posting an event to plugin event queue. After we?ve moved Appkit to the root thread group which does not have any AppContext in plugin mode, this branch will always fail with NPE. This could lead to regressions, but these would be not ?regressions?, but existing bugs that we didn?t find yet. If applets were tested more, all the regressions would have already been filed in JBS. So the idea of this fix is to remove the branch which will always fail in plugin mode so that we could find plugin bugs while running in desktop mode. I?m not going to back port this change, because it?s too risky for update releases, but I think it?s OK for JDK 9. It?s always better to catch bugs early. With best regards. Petr. On Apr 29, 2014, at 9:37 PM, Anthony Petrov wrote: > Hi Petr, > > While the bug description and the solution sound reasonable, I'm still a bit concerned about the presence of the if(component==null) branch in the old code. I see that the code has been updated recently (with lambdas and friends), and is aware of the app contexts thing. So someone who wrote it, added that branch consciously. Or left it there from the former version of the code that might not be aware of the app contexts problems. In either case, w/o knowing why the branch is there in the first place, it seems a bit scary to just chop it off. > > Could you please investigate a bit more and provide some details so that we could be sure this change doesn't cause any regressions? > > -- > best regards, > Anthony > > On 4/29/2014 3:04 PM, Petr Pchelko wrote: >> Hello, Sergey. >> >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8042087 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/9/8042087/webrev/ >>>> >>>> The problem is that we are using EventQueue.invokeLater on the Toolkit thread. >>> I guess the fix changes getSystemEventQueueForInvokeAndWait().postEvent(), and EventQueue.invokeLater is used in another place of LWCToolkit in systemColorsChanged(). >>>> In applet mode this would fail with NPE. So I've removed the non-working code branch, made general cleanup and added a null check for the component provided to invokeAndWait and invokeLater methods. >> Yes, I've called the bug incorrectly) It should be called "[macosx] LWCToolkit.inokeAndWait is relying on main AppContext".. Sorry for inaccuracy. I've renamed the issue. >> >> With best regards. Petr. >> >> On 29.04.2014, at 14:38, Sergey Bylokhov wrote: >> >>> On 4/29/14 12:32 PM, Petr Pchelko wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8042087 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/9/8042087/webrev/ >>>> >>>> The problem is that we are using EventQueue.invokeLater on the Toolkit thread. >>> I guess the fix changes getSystemEventQueueForInvokeAndWait().postEvent(), and EventQueue.invokeLater is used in another place of LWCToolkit in systemColorsChanged(). >>>> In applet mode this would fail with NPE. So I've removed the non-working code branch, made general cleanup and added a null check for the component provided to invokeAndWait and invokeLater methods. >>>> We don't have open bugs on Mac about NPE in applet mode, so most likely the removed branch was never executed. But with this fix we would catch possible errors early. >>>> >>>> With best regards. Petr. >>> >>> >>> -- >>> Best regards, Sergey. >>> >> From anthony.petrov at oracle.com Tue Apr 29 17:57:43 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 29 Apr 2014 21:57:43 +0400 Subject: [9] Review Request: JDK-8042087 [macosx] LWCToolkit.inokeAndWait is calling EventQueue.invokeLater In-Reply-To: <712FA8DC-3C36-4FA7-A5E9-062C5EBE689C@oracle.com> References: <1D7DB08D-48E5-4633-9D65-23FC90D2F0F8@oracle.com> <535F811A.5070505@oracle.com> <71BF37D8-3759-4989-8093-314A0AECAC1F@oracle.com> <535FE377.5060903@oracle.com> <712FA8DC-3C36-4FA7-A5E9-062C5EBE689C@oracle.com> Message-ID: <535FE817.7060500@oracle.com> Sounds good. Thanks for the clarification. If our existing regression tests don't fail with the fix, then I'm OK with it. -- best regards, Anthony On 4/29/2014 9:54 PM, Petr Pchelko wrote: > Hello, Anthony. > > Than you for the review. > >> While the bug description and the solution sound reasonable, I'm still a bit concerned about the presence of the if(component==null) branch in the old code. I see that the code has been updated recently (with lambdas and friends), and is aware of the app contexts thing. So someone who wrote it, added that branch consciously. Or left it there from the former version of the code that might not be aware of the app contexts problems. In either case, w/o knowing why the branch is there in the first place, it seems a bit scary to just chop it off. >> Could you please investigate a bit more and provide some details so that we could be sure this change doesn't cause any regressions? > I?ve updated this code many times and the null branch was there from the very beginning. At first Appkit thread was in the main thread group, so this branch could work and it was scary to remove it. It was obviously wrong for security reasons, because it was posting an event to plugin event queue. > After we?ve moved Appkit to the root thread group which does not have any AppContext in plugin mode, this branch will always fail with NPE. > > This could lead to regressions, but these would be not ?regressions?, but existing bugs that we didn?t find yet. If applets were tested more, all the regressions would have already been filed in JBS. So the idea of this fix is to remove the branch which will always fail in plugin mode so that we could find plugin bugs while running in desktop mode. I?m not going to back port this change, because it?s too risky for update releases, but I think it?s OK for JDK 9. It?s always better to catch bugs early. > > With best regards. Petr. > > On Apr 29, 2014, at 9:37 PM, Anthony Petrov wrote: > >> Hi Petr, >> >> While the bug description and the solution sound reasonable, I'm still a bit concerned about the presence of the if(component==null) branch in the old code. I see that the code has been updated recently (with lambdas and friends), and is aware of the app contexts thing. So someone who wrote it, added that branch consciously. Or left it there from the former version of the code that might not be aware of the app contexts problems. In either case, w/o knowing why the branch is there in the first place, it seems a bit scary to just chop it off. >> >> Could you please investigate a bit more and provide some details so that we could be sure this change doesn't cause any regressions? >> >> -- >> best regards, >> Anthony >> >> On 4/29/2014 3:04 PM, Petr Pchelko wrote: >>> Hello, Sergey. >>> >>>>> Hello, AWT Team. >>>>> >>>>> Please review the fix for the issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8042087 >>>>> The fix is available at: >>>>> http://cr.openjdk.java.net/~pchelko/9/8042087/webrev/ >>>>> >>>>> The problem is that we are using EventQueue.invokeLater on the Toolkit thread. >>>> I guess the fix changes getSystemEventQueueForInvokeAndWait().postEvent(), and EventQueue.invokeLater is used in another place of LWCToolkit in systemColorsChanged(). >>>>> In applet mode this would fail with NPE. So I've removed the non-working code branch, made general cleanup and added a null check for the component provided to invokeAndWait and invokeLater methods. >>> Yes, I've called the bug incorrectly) It should be called "[macosx] LWCToolkit.inokeAndWait is relying on main AppContext".. Sorry for inaccuracy. I've renamed the issue. >>> >>> With best regards. Petr. >>> >>> On 29.04.2014, at 14:38, Sergey Bylokhov wrote: >>> >>>> On 4/29/14 12:32 PM, Petr Pchelko wrote: >>>>> Hello, AWT Team. >>>>> >>>>> Please review the fix for the issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8042087 >>>>> The fix is available at: >>>>> http://cr.openjdk.java.net/~pchelko/9/8042087/webrev/ >>>>> >>>>> The problem is that we are using EventQueue.invokeLater on the Toolkit thread. >>>> I guess the fix changes getSystemEventQueueForInvokeAndWait().postEvent(), and EventQueue.invokeLater is used in another place of LWCToolkit in systemColorsChanged(). >>>>> In applet mode this would fail with NPE. So I've removed the non-working code branch, made general cleanup and added a null check for the component provided to invokeAndWait and invokeLater methods. >>>>> We don't have open bugs on Mac about NPE in applet mode, so most likely the removed branch was never executed. But with this fix we would catch possible errors early. >>>>> >>>>> With best regards. Petr. >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >>> > From Sergey.Bylokhov at oracle.com Tue Apr 29 18:59:38 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 Apr 2014 22:59:38 +0400 Subject: [9] Review Request: JDK-8042087 [macosx] LWCToolkit.inokeAndWait is calling EventQueue.invokeLater In-Reply-To: <535FE817.7060500@oracle.com> References: <1D7DB08D-48E5-4633-9D65-23FC90D2F0F8@oracle.com> <535F811A.5070505@oracle.com> <71BF37D8-3759-4989-8093-314A0AECAC1F@oracle.com> <535FE377.5060903@oracle.com> <712FA8DC-3C36-4FA7-A5E9-062C5EBE689C@oracle.com> <535FE817.7060500@oracle.com> Message-ID: <535FF69A.9040806@oracle.com> On 4/29/14 9:57 PM, Anthony Petrov wrote: > Sounds good. Thanks for the clarification. If our existing regression > tests don't fail with the fix, then I'm OK with it. Looks fine to me too. Do not forget to file CR against EventQueue.invokeLater in systemColorsChanged. > > -- > best regards, > Anthony > > On 4/29/2014 9:54 PM, Petr Pchelko wrote: >> Hello, Anthony. >> >> Than you for the review. >> >>> While the bug description and the solution sound reasonable, I'm >>> still a bit concerned about the presence of the if(component==null) >>> branch in the old code. I see that the code has been updated >>> recently (with lambdas and friends), and is aware of the app >>> contexts thing. So someone who wrote it, added that branch >>> consciously. Or left it there from the former version of the code >>> that might not be aware of the app contexts problems. In either >>> case, w/o knowing why the branch is there in the first place, it >>> seems a bit scary to just chop it off. >>> Could you please investigate a bit more and provide some details so >>> that we could be sure this change doesn't cause any regressions? >> I?ve updated this code many times and the null branch was there from >> the very beginning. At first Appkit thread was in the main thread >> group, so this branch could work and it was scary to remove it. It >> was obviously wrong for security reasons, because it was posting an >> event to plugin event queue. >> After we?ve moved Appkit to the root thread group which does not have >> any AppContext in plugin mode, this branch will always fail with NPE. >> >> This could lead to regressions, but these would be not ?regressions?, >> but existing bugs that we didn?t find yet. If applets were tested >> more, all the regressions would have already been filed in JBS. So >> the idea of this fix is to remove the branch which will always fail >> in plugin mode so that we could find plugin bugs while running in >> desktop mode. I?m not going to back port this change, because it?s >> too risky for update releases, but I think it?s OK for JDK 9. It?s >> always better to catch bugs early. >> >> With best regards. Petr. >> >> On Apr 29, 2014, at 9:37 PM, Anthony Petrov >> wrote: >> >>> Hi Petr, >>> >>> While the bug description and the solution sound reasonable, I'm >>> still a bit concerned about the presence of the if(component==null) >>> branch in the old code. I see that the code has been updated >>> recently (with lambdas and friends), and is aware of the app >>> contexts thing. So someone who wrote it, added that branch >>> consciously. Or left it there from the former version of the code >>> that might not be aware of the app contexts problems. In either >>> case, w/o knowing why the branch is there in the first place, it >>> seems a bit scary to just chop it off. >>> >>> Could you please investigate a bit more and provide some details so >>> that we could be sure this change doesn't cause any regressions? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/29/2014 3:04 PM, Petr Pchelko wrote: >>>> Hello, Sergey. >>>> >>>>>> Hello, AWT Team. >>>>>> >>>>>> Please review the fix for the issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8042087 >>>>>> The fix is available at: >>>>>> http://cr.openjdk.java.net/~pchelko/9/8042087/webrev/ >>>>>> >>>>>> The problem is that we are using EventQueue.invokeLater on the >>>>>> Toolkit thread. >>>>> I guess the fix changes >>>>> getSystemEventQueueForInvokeAndWait().postEvent(), and >>>>> EventQueue.invokeLater is used in another place of LWCToolkit in >>>>> systemColorsChanged(). >>>>>> In applet mode this would fail with NPE. So I've removed the >>>>>> non-working code branch, made general cleanup and added a null >>>>>> check for the component provided to invokeAndWait and invokeLater >>>>>> methods. >>>> Yes, I've called the bug incorrectly) It should be called "[macosx] >>>> LWCToolkit.inokeAndWait is relying on main AppContext".. Sorry >>>> for inaccuracy. I've renamed the issue. >>>> >>>> With best regards. Petr. >>>> >>>> On 29.04.2014, at 14:38, Sergey Bylokhov >>>> wrote: >>>> >>>>> On 4/29/14 12:32 PM, Petr Pchelko wrote: >>>>>> Hello, AWT Team. >>>>>> >>>>>> Please review the fix for the issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8042087 >>>>>> The fix is available at: >>>>>> http://cr.openjdk.java.net/~pchelko/9/8042087/webrev/ >>>>>> >>>>>> The problem is that we are using EventQueue.invokeLater on the >>>>>> Toolkit thread. >>>>> I guess the fix changes >>>>> getSystemEventQueueForInvokeAndWait().postEvent(), and >>>>> EventQueue.invokeLater is used in another place of LWCToolkit in >>>>> systemColorsChanged(). >>>>>> In applet mode this would fail with NPE. So I've removed the >>>>>> non-working code branch, made general cleanup and added a null >>>>>> check for the component provided to invokeAndWait and invokeLater >>>>>> methods. >>>>>> We don't have open bugs on Mac about NPE in applet mode, so most >>>>>> likely the removed branch was never executed. But with this fix >>>>>> we would catch possible errors early. >>>>>> >>>>>> With best regards. Petr. >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>>> >> -- Best regards, Sergey. From joe.darcy at oracle.com Tue Apr 29 20:26:13 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 29 Apr 2014 13:26:13 -0700 Subject: JDK 9 RFR of JDK-8039109 : Fix unchecked and raw lint warnings in java.awt Message-ID: <53600AE5.8080008@oracle.com> Hello, Now that Henry's fixes of raw and unchecked warnings in sun.awt has been pushed, please review this change to fix issues in java.awt: JDK-8039109 : Fix unchecked and raw lint warnings in java.awt http://cr.openjdk.java.net/~darcy/8039109.1/ Full patch below. A few points of interest in the patch: * There is a change to the signature of a public method in java.awt.image.renderable.ParameterBlock.java (I believe that is the only such change in this patch; internally, a ccc request will be filed for this part of the fix.) * In my estimation the changes in java.awt.GraphicsEnvironment.java are a better use of generics and reflection. Thanks, -Joe --- old/src/share/classes/java/awt/AWTKeyStroke.java 2014-04-29 13:01:10.000000000 -0700 +++ new/src/share/classes/java/awt/AWTKeyStroke.java 2014-04-29 13:01:10.000000000 -0700 @@ -86,7 +86,8 @@ * Must be called under locked AWTKeyStro */ private static Class getAWTKeyStrokeClass() { - Class clazz = (Class)AppContext.getAppContext().get(AWTKeyStroke.class); + @SuppressWarnings("unchecked") + Class clazz = (Class)AppContext.getAppContext().get(AWTKeyStroke.class); if (clazz == null) { clazz = AWTKeyStroke.class; AppContext.getAppContext().put(AWTKeyStroke.class, AWTKeyStroke.class); @@ -182,6 +183,7 @@ throw new IllegalArgumentException("subclass cannot be null"); } synchronized (AWTKeyStroke.class) { + @SuppressWarnings("unchecked") Class keyStrokeClass = (Class)AppContext.getAppContext().get(AWTKeyStroke.class); if (keyStrokeClass != null && keyStrokeClass.equals(subclass)){ // Already registered @@ -192,7 +194,7 @@ throw new ClassCastException("subclass is not derived from AWTKeyStroke"); } - Constructor ctor = getCtor(subclass); + Constructor ctor = getCtor(subclass); String couldNotInstantiate = "subclass could not be instantiated"; @@ -227,12 +229,12 @@ threat as accessible flag is set only for this Constructor object, not for Class constructor. */ - private static Constructor getCtor(final Class clazz) + private static Constructor getCtor(final Class clazz) { - Constructor ctor = AccessController.doPrivileged(new PrivilegedAction() { - public Constructor run() { + Constructor ctor = AccessController.doPrivileged(new PrivilegedAction>() { + public Constructor run() { try { - Constructor ctor = clazz.getDeclaredConstructor((Class[]) null); + Constructor ctor = clazz.getDeclaredConstructor((Class[]) null); if (ctor != null) { ctor.setAccessible(true); } @@ -249,7 +251,9 @@ private static synchronized AWTKeyStroke getCachedStroke (char keyChar, int keyCode, int modifiers, boolean onKeyRelease) { + @SuppressWarnings("unchecked") Map cache = (Map)AppContext.getAppContext().get(APP_CONTEXT_CACHE_KEY); + @SuppressWarnings("unchecked") AWTKeyStroke cacheKey = (AWTKeyStroke)AppContext.getAppContext().get(APP_CONTEXT_KEYSTROKE_KEY); if (cache == null) { --- old/src/share/classes/java/awt/CardLayout.java 2014-04-29 13:01:11.000000000 -0700 +++ new/src/share/classes/java/awt/CardLayout.java 2014-04-29 13:01:11.000000000 -0700 @@ -560,6 +560,7 @@ /** * Reads serializable fields from stream. */ + @SuppressWarnings("unchecked") private void readObject(ObjectInputStream s) throws ClassNotFoundException, IOException { --- old/src/share/classes/java/awt/Component.java 2014-04-29 13:01:11.000000000 -0700 +++ new/src/share/classes/java/awt/Component.java 2014-04-29 13:01:11.000000000 -0700 @@ -6184,7 +6184,7 @@ /** * Parameter types of coalesceEvents(AWTEvent,AWTEVent). */ - private static final Class[] coalesceEventsParams = { + private static final Class[] coalesceEventsParams = { AWTEvent.class, AWTEvent.class }; --- old/src/share/classes/java/awt/GraphicsEnvironment.java 2014-04-29 13:01:12.000000000 -0700 +++ new/src/share/classes/java/awt/GraphicsEnvironment.java 2014-04-29 13:01:12.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -95,18 +95,18 @@ String nm = AccessController.doPrivileged(new GetPropertyAction("java.awt.graphicsenv", null)); try { // long t0 = System.currentTimeMillis(); - Class geCls; + Class geCls; try { // First we try if the bootclassloader finds the requested // class. This way we can avoid to run in a privileged block. - geCls = (Class)Class.forName(nm); + geCls = Class.forName(nm); } catch (ClassNotFoundException ex) { // If the bootclassloader fails, we try again with the // application classloader. ClassLoader cl = ClassLoader.getSystemClassLoader(); - geCls = (Class)Class.forName(nm, true, cl); + geCls = Class.forName(nm, true, cl); } - ge = geCls.newInstance(); + ge = GraphicsEnvironment.class.cast(geCls.newInstance()); // long t1 = System.currentTimeMillis(); // System.out.println("GE creation took " + (t1-t0)+ "ms."); if (isHeadless()) { --- old/src/share/classes/java/awt/KeyboardFocusManager.java 2014-04-29 13:01:13.000000000 -0700 +++ new/src/share/classes/java/awt/KeyboardFocusManager.java 2014-04-29 13:01:12.000000000 -0700 @@ -348,6 +348,7 @@ * Component of those Windows that has no such array of its own explicitly * set. */ + @SuppressWarnings({"unchecked", "rawtypes"}) private Set[] defaultFocusTraversalKeys = new Set[4]; /** @@ -422,7 +423,7 @@ targetSet.add(AWTKeyStroke.getAWTKeyStroke(tokens.nextToken())); } return (targetSet.isEmpty()) - ? Collections.EMPTY_SET + ? Collections.emptySet() : Collections.unmodifiableSet(targetSet); } @@ -436,7 +437,7 @@ work_set.add(defaultFocusTraversalKeyStrokes[i][j]); } defaultFocusTraversalKeys[i] = (work_set.isEmpty()) - ? Collections.EMPTY_SET + ? Collections.emptySet() : Collections.unmodifiableSet(work_set); } initPeer(); @@ -1750,11 +1751,12 @@ * @see #addKeyEventDispatcher * @see #removeKeyEventDispatcher */ + @SuppressWarnings("unchecked") // Cast of result of clone protected synchronized java.util.List getKeyEventDispatchers() { return (keyEventDispatchers != null) - ? (java.util.List)keyEventDispatchers.clone() + ? (java.util.List)keyEventDispatchers.clone() : null; } @@ -1841,11 +1843,12 @@ * @see #addKeyEventPostProcessor * @see #removeKeyEventPostProcessor */ + @SuppressWarnings("unchecked") // Cast of result of clone protected java.util.List getKeyEventPostProcessors() { return (keyEventPostProcessors != null) - ? (java.util.List)keyEventPostProcessors.clone() + ? (java.util.List)keyEventPostProcessors.clone() : null; } @@ -1907,8 +1910,7 @@ * javax.swing.JComponent.runInputVerifier() using reflection. */ static synchronized Component getMostRecentFocusOwner(Window window) { - WeakReference weakValue = - (WeakReference)mostRecentFocusOwners.get(window); + WeakReference weakValue = mostRecentFocusOwners.get(window); return weakValue == null ? null : weakValue.get(); } --- old/src/share/classes/java/awt/SystemTray.java 2014-04-29 13:01:13.000000000 -0700 +++ new/src/share/classes/java/awt/SystemTray.java 2014-04-29 13:01:13.000000000 -0700 @@ -259,7 +259,9 @@ Vector icons = null; synchronized (this) { oldArray = systemTray.getTrayIcons(); - icons = (Vector)AppContext.getAppContext().get(TrayIcon.class); + @SuppressWarnings("unchecked") + Vector tmp = (Vector)AppContext.getAppContext().get(TrayIcon.class); + icons = tmp; if (icons == null) { icons = new Vector(3); AppContext.getAppContext().put(TrayIcon.class, icons); @@ -304,6 +306,7 @@ TrayIcon[] oldArray = null, newArray = null; synchronized (this) { oldArray = systemTray.getTrayIcons(); + @SuppressWarnings("unchecked") Vector icons = (Vector)AppContext.getAppContext().get(TrayIcon.class); // TrayIcon with no peer is not contained in the array. if (icons == null || !icons.remove(trayIcon)) { @@ -335,6 +338,7 @@ * @see TrayIcon */ public TrayIcon[] getTrayIcons() { + @SuppressWarnings("unchecked") Vector icons = (Vector)AppContext.getAppContext().get(TrayIcon.class); if (icons != null) { return icons.toArray(new TrayIcon[icons.size()]); --- old/src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java 2014-04-29 13:01:14.000000000 -0700 +++ new/src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java 2014-04-29 13:01:14.000000000 -0700 @@ -296,14 +296,14 @@ /** * @return a clone of this object */ - + @SuppressWarnings("unchecked") // Cast from clone public Object clone() { MimeTypeParameterList newObj = null; try { newObj = (MimeTypeParameterList)super.clone(); } catch (CloneNotSupportedException cannotHappen) { } - newObj.parameters = (Hashtable)parameters.clone(); + newObj.parameters = (Hashtable)parameters.clone(); return newObj; } --- old/src/share/classes/java/awt/dnd/DragGestureEvent.java 2014-04-29 13:01:14.000000000 -0700 +++ new/src/share/classes/java/awt/dnd/DragGestureEvent.java 2014-04-29 13:01:14.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -357,6 +357,7 @@ action = newAction; // Pre-1.4 support. 'events' was previously non-transient + @SuppressWarnings("rawtypes") List newEvents; try { newEvents = (List)f.get("events", null); --- old/src/share/classes/java/awt/geom/Area.java 2014-04-29 13:01:15.000000000 -0700 +++ new/src/share/classes/java/awt/geom/Area.java 2014-04-29 13:01:15.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2006, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -97,9 +97,9 @@ * @since 1.2 */ public class Area implements Shape, Cloneable { - private static Vector EmptyCurves = new Vector(); + private static Vector EmptyCurves = new Vector<>(); - private Vector curves; + private Vector curves; /** * Default constructor which creates an empty area. @@ -127,8 +127,8 @@ } } - private static Vector pathToCurves(PathIterator pi) { - Vector curves = new Vector(); + private static Vector pathToCurves(PathIterator pi) { + Vector curves = new Vector<>(); int windingRule = pi.getWindingRule(); // coords array is big enough for holding: // coordinates returned from currentSegment (6) @@ -334,7 +334,7 @@ * @since 1.2 */ public void reset() { - curves = new Vector(); + curves = new Vector<>(); invalidateBounds(); } @@ -357,9 +357,9 @@ * @since 1.2 */ public boolean isPolygonal() { - Enumeration enum_ = curves.elements(); + Enumeration enum_ = curves.elements(); while (enum_.hasMoreElements()) { - if (((Curve) enum_.nextElement()).getOrder() > 1) { + if (enum_.nextElement().getOrder() > 1) { return false; } } @@ -381,8 +381,8 @@ if (size > 3) { return false; } - Curve c1 = (Curve) curves.get(1); - Curve c2 = (Curve) curves.get(2); + Curve c1 = curves.get(1); + Curve c2 = curves.get(2); if (c1.getOrder() != 1 || c2.getOrder() != 1) { return false; } @@ -411,10 +411,10 @@ if (curves.size() < 3) { return true; } - Enumeration enum_ = curves.elements(); + Enumeration enum_ = curves.elements(); enum_.nextElement(); // First Order0 "moveto" while (enum_.hasMoreElements()) { - if (((Curve) enum_.nextElement()).getOrder() == 0) { + if (enum_.nextElement().getOrder() == 0) { return false; } } @@ -431,11 +431,11 @@ } Rectangle2D r = new Rectangle2D.Double(); if (curves.size() > 0) { - Curve c = (Curve) curves.get(0); + Curve c = curves.get(0); // First point is always an order 0 curve (moveto) r.setRect(c.getX0(), c.getY0(), 0, 0); for (int i = 1; i < curves.size(); i++) { - ((Curve) curves.get(i)).enlarge(r); + curves.get(i).enlarge(r); } } return (cachedBounds = r); @@ -507,7 +507,7 @@ if (other == null) { return false; } - Vector c = new AreaOp.XorOp().calculate(this.curves, other.curves); + Vector c = new AreaOp.XorOp().calculate(this.curves, other.curves); return c.isEmpty(); } @@ -555,10 +555,10 @@ if (!getCachedBounds().contains(x, y)) { return false; } - Enumeration enum_ = curves.elements(); + Enumeration enum_ = curves.elements(); int crossings = 0; while (enum_.hasMoreElements()) { - Curve c = (Curve) enum_.nextElement(); + Curve c = enum_.nextElement(); crossings += c.crossingsFor(x, y); } return ((crossings & 1) == 1); @@ -658,16 +658,16 @@ class AreaIterator implements PathIterator { private AffineTransform transform; - private Vector curves; + private Vector curves; private int index; private Curve prevcurve; private Curve thiscurve; - public AreaIterator(Vector curves, AffineTransform at) { + public AreaIterator(Vector curves, AffineTransform at) { this.curves = curves; this.transform = at; if (curves.size() >= 1) { - thiscurve = (Curve) curves.get(0); + thiscurve = curves.get(0); } } @@ -689,7 +689,7 @@ prevcurve = thiscurve; index++; if (index < curves.size()) { - thiscurve = (Curve) curves.get(index); + thiscurve = curves.get(index); if (thiscurve.getOrder() != 0 && prevcurve.getX1() == thiscurve.getX0() && prevcurve.getY1() == thiscurve.getY0()) --- old/src/share/classes/java/awt/image/BufferedImage.java 2014-04-29 13:01:15.000000000 -0700 +++ new/src/share/classes/java/awt/image/BufferedImage.java 2014-04-29 13:01:15.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -76,7 +76,7 @@ ColorModel colorModel; WritableRaster raster; OffScreenImageSource osis; - Hashtable properties; + Hashtable properties; boolean isAlphaPremultiplied;// If true, alpha has been premultiplied in // color channels @@ -1106,7 +1106,7 @@ public ImageProducer getSource() { if (osis == null) { if (properties == null) { - properties = new Hashtable(); + properties = new Hashtable<>(); } osis = new OffScreenImageSource(this, properties); } --- old/src/share/classes/java/awt/image/CropImageFilter.java 2014-04-29 13:01:16.000000000 -0700 +++ new/src/share/classes/java/awt/image/CropImageFilter.java 2014-04-29 13:01:16.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -79,6 +79,7 @@ * with the filtering operation. */ public void setProperties(Hashtable props) { + @SuppressWarnings("unchecked") Hashtable p = (Hashtable)props.clone(); p.put("croprect", new Rectangle(cropX, cropY, cropW, cropH)); super.setProperties(p); --- old/src/share/classes/java/awt/image/FilteredImageSource.java 2014-04-29 13:01:16.000000000 -0700 +++ new/src/share/classes/java/awt/image/FilteredImageSource.java 2014-04-29 13:01:16.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -68,7 +68,7 @@ filter = imgf; } - private Hashtable proxies; + private Hashtable proxies; /** * Adds the specified ImageConsumer @@ -94,7 +94,7 @@ */ public synchronized void addConsumer(ImageConsumer ic) { if (proxies == null) { - proxies = new Hashtable(); + proxies = new Hashtable<>(); } if (!proxies.containsKey(ic)) { ImageFilter imgf = filter.getFilterInstance(ic); @@ -137,7 +137,7 @@ */ public synchronized void removeConsumer(ImageConsumer ic) { if (proxies != null) { - ImageFilter imgf = (ImageFilter) proxies.get(ic); + ImageFilter imgf = proxies.get(ic); if (imgf != null) { src.removeConsumer(imgf); proxies.remove(ic); @@ -173,9 +173,9 @@ */ public void startProduction(ImageConsumer ic) { if (proxies == null) { - proxies = new Hashtable(); + proxies = new Hashtable<>(); } - ImageFilter imgf = (ImageFilter) proxies.get(ic); + ImageFilter imgf = proxies.get(ic); if (imgf == null) { imgf = filter.getFilterInstance(ic); proxies.put(ic, imgf); @@ -200,7 +200,7 @@ */ public void requestTopDownLeftRightResend(ImageConsumer ic) { if (proxies != null) { - ImageFilter imgf = (ImageFilter) proxies.get(ic); + ImageFilter imgf = proxies.get(ic); if (imgf != null) { imgf.resendTopDownLeftRight(src); } --- old/src/share/classes/java/awt/image/ImageFilter.java 2014-04-29 13:01:17.000000000 -0700 +++ new/src/share/classes/java/awt/image/ImageFilter.java 2014-04-29 13:01:17.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -104,6 +104,7 @@ * @exception NullPointerException if props is null */ public void setProperties(Hashtable props) { + @SuppressWarnings("unchecked") Hashtable p = (Hashtable)props.clone(); Object o = p.get("filters"); if (o == null) { --- old/src/share/classes/java/awt/image/MemoryImageSource.java 2014-04-29 13:01:17.000000000 -0700 +++ new/src/share/classes/java/awt/image/MemoryImageSource.java 2014-04-29 13:01:17.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -111,8 +111,8 @@ Object pixels; int pixeloffset; int pixelscan; - Hashtable properties; - Vector theConsumers = new Vector(); + Hashtable properties; + Vector theConsumers = new Vector<>(); boolean animating; boolean fullbuffers; @@ -197,7 +197,7 @@ } private void initialize(int w, int h, ColorModel cm, - Object pix, int off, int scan, Hashtable props) { + Object pix, int off, int scan, Hashtable props) { width = w; height = h; model = cm; @@ -205,7 +205,7 @@ pixeloffset = off; pixelscan = scan; if (props == null) { - props = new Hashtable(); + props = new Hashtable<>(); } properties = props; } @@ -343,9 +343,9 @@ public synchronized void setAnimated(boolean animated) { this.animating = animated; if (!animating) { - Enumeration enum_ = theConsumers.elements(); + Enumeration enum_ = theConsumers.elements(); while (enum_.hasMoreElements()) { - ImageConsumer ic = (ImageConsumer) enum_.nextElement(); + ImageConsumer ic = enum_.nextElement(); ic.imageComplete(ImageConsumer.STATICIMAGEDONE); if (isConsumer(ic)) { ic.imageComplete(ImageConsumer.IMAGEERROR); @@ -376,9 +376,9 @@ } this.fullbuffers = fullbuffers; if (animating) { - Enumeration enum_ = theConsumers.elements(); + Enumeration enum_ = theConsumers.elements(); while (enum_.hasMoreElements()) { - ImageConsumer ic = (ImageConsumer) enum_.nextElement(); + ImageConsumer ic = enum_.nextElement(); ic.setHints(fullbuffers ? (ImageConsumer.TOPDOWNLEFTRIGHT | ImageConsumer.COMPLETESCANLINES) @@ -474,9 +474,9 @@ if ((w <= 0 || h <= 0) && !framenotify) { return; } - Enumeration enum_ = theConsumers.elements(); + Enumeration enum_ = theConsumers.elements(); while (enum_.hasMoreElements()) { - ImageConsumer ic = (ImageConsumer) enum_.nextElement(); + ImageConsumer ic = enum_.nextElement(); if (w > 0 && h > 0) { sendPixels(ic, x, y, w, h); } --- old/src/share/classes/java/awt/image/ReplicateScaleFilter.java 2014-04-29 13:01:18.000000000 -0700 +++ new/src/share/classes/java/awt/image/ReplicateScaleFilter.java 2014-04-29 13:01:17.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -121,6 +121,7 @@ * with the filtering operation. */ public void setProperties(Hashtable props) { + @SuppressWarnings("unchecked") Hashtable p = (Hashtable)props.clone(); String key = "rescale"; String val = destWidth + "x" + destHeight; --- old/src/share/classes/java/awt/image/renderable/ParameterBlock.java 2014-04-29 13:01:18.000000000 -0700 +++ new/src/share/classes/java/awt/image/renderable/ParameterBlock.java 2014-04-29 13:01:18.000000000 -0700 @@ -153,6 +153,7 @@ * * @return an Object clone of the ParameterBlock. */ + @SuppressWarnings("unchecked") // casts from clone public Object clone() { ParameterBlock theClone; @@ -164,10 +165,10 @@ } if (sources != null) { - theClone.setSources((Vector)sources.clone()); + theClone.setSources((Vector)sources.clone()); } if (parameters != null) { - theClone.setParameters((Vector)parameters.clone()); + theClone.setParameters((Vector)parameters.clone()); } return (Object) theClone; } @@ -280,7 +281,7 @@ /** Clears the list of source images. */ public void removeSources() { - sources = new Vector(); + sources = new Vector<>(); } /** @@ -313,7 +314,7 @@ /** Clears the list of parameters. */ public void removeParameters() { - parameters = new Vector(); + parameters = new Vector<>(); } /** @@ -696,9 +697,9 @@ * of the parameters. * @return an array of Class objects. */ - public Class [] getParamClasses() { + public Class[] getParamClasses() { int numParams = getNumParameters(); - Class [] classes = new Class[numParams]; + Class[] classes = new Class[numParams]; int i; for (i = 0; i < numParams; i++) { --- old/src/share/classes/java/awt/image/renderable/RenderableImageOp.java 2014-04-29 13:01:19.000000000 -0700 +++ new/src/share/classes/java/awt/image/renderable/RenderableImageOp.java 2014-04-29 13:01:18.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -83,15 +83,16 @@ * * @return a (possibly empty) Vector of RenderableImages, or null. */ + @SuppressWarnings("unchecked") public Vector getSources() { - return getRenderableSources(); + return (Vector)(Vector)getRenderableSources(); } - private Vector getRenderableSources() { - Vector sources = null; + private Vector getRenderableSources() { + Vector sources = null; if (paramBlock.getNumSources() > 0) { - sources = new Vector(); + sources = new Vector<>(); int i = 0; while (i < paramBlock.getNumSources()) { Object o = paramBlock.getSource(i); @@ -314,19 +315,19 @@ // contains RenderableImage sources, they will be replaced by // RenderedImages. ParameterBlock renderedParamBlock = (ParameterBlock)paramBlock.clone(); - Vector sources = getRenderableSources(); + Vector sources = getRenderableSources(); try { // This assumes that if there is no renderable source, that there // is a rendered source in paramBlock if (sources != null) { - Vector renderedSources = new Vector(); + Vector renderedSources = new Vector<>(); for (int i = 0; i < sources.size(); i++) { rcOut = myCRIF.mapRenderContext(i, renderContext, paramBlock, this); RenderedImage rdrdImage = - ((RenderableImage)sources.elementAt(i)).createRendering(rcOut); + ((RenderableImage)sources.elementAt(i)).createRendering(rcOut); if (rdrdImage == null) { return null; } --- old/src/share/classes/java/awt/image/renderable/RenderableImageProducer.java 2014-04-29 13:01:19.000000000 -0700 +++ new/src/share/classes/java/awt/image/renderable/RenderableImageProducer.java 2014-04-29 13:01:19.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2008, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -68,7 +68,7 @@ RenderContext rc; /** A Vector of image consumers. */ - Vector ics = new Vector(); + Vector ics = new Vector<>(); /** * Constructs a new RenderableImageProducer from a RenderableImage @@ -177,12 +177,12 @@ int width = raster.getWidth(); int height = raster.getHeight(); - Enumeration icList; + Enumeration icList; ImageConsumer ic; // Set up the ImageConsumers icList = ics.elements(); while (icList.hasMoreElements()) { - ic = (ImageConsumer)icList.nextElement(); + ic = icList.nextElement(); ic.setDimensions(width,height); ic.setHints(ImageConsumer.TOPDOWNLEFTRIGHT | ImageConsumer.COMPLETESCANLINES | @@ -204,7 +204,7 @@ // Now send the scanline to the Consumers icList = ics.elements(); while (icList.hasMoreElements()) { - ic = (ImageConsumer)icList.nextElement(); + ic = icList.nextElement(); ic.setPixels(0, j, width, 1, colorModel, pix, 0, width); } } @@ -212,7 +212,7 @@ // Now tell the consumers we're done. icList = ics.elements(); while (icList.hasMoreElements()) { - ic = (ImageConsumer)icList.nextElement(); + ic = icList.nextElement(); ic.imageComplete(ImageConsumer.STATICIMAGEDONE); } } --- old/src/share/classes/java/awt/print/Book.java 2014-04-29 13:01:19.000000000 -0700 +++ new/src/share/classes/java/awt/print/Book.java 2014-04-29 13:01:19.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -47,7 +47,7 @@ /** * The set of pages that make up the Book. */ - private Vector mPages; + private Vector mPages; /* Instance Methods */ @@ -55,7 +55,7 @@ * Creates a new, empty Book. */ public Book() { - mPages = new Vector(); + mPages = new Vector(); } /** @@ -167,7 +167,7 @@ private BookPage getPage(int pageIndex) throws ArrayIndexOutOfBoundsException { - return (BookPage) mPages.elementAt(pageIndex); + return mPages.elementAt(pageIndex); } /** --- old/src/share/classes/java/awt/print/PrinterJob.java 2014-04-29 13:01:20.000000000 -0700 +++ new/src/share/classes/java/awt/print/PrinterJob.java 2014-04-29 13:01:20.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -74,9 +74,9 @@ if (security != null) { security.checkPrintJobAccess(); } - return (PrinterJob) java.security.AccessController.doPrivileged( - new java.security.PrivilegedAction() { - public Object run() { + return java.security.AccessController.doPrivileged( + new java.security.PrivilegedAction() { + public PrinterJob run() { String nm = System.getProperty("java.awt.printerjob", null); try { return (PrinterJob)Class.forName(nm).newInstance(); From petr.pchelko at oracle.com Wed Apr 30 06:21:17 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 30 Apr 2014 10:21:17 +0400 Subject: JDK 9 RFR of JDK-8039109 : Fix unchecked and raw lint warnings in java.awt In-Reply-To: <53600AE5.8080008@oracle.com> References: <53600AE5.8080008@oracle.com> Message-ID: <4D6E95D7-3CF0-4031-A817-60DF44215AFC@oracle.com> Hello, Joe. In RenderableImageOp.getRenderableSources only RenderableImage instances are added to the Vector. So the method could return Vector to avoid the cast in getSources() method. With best regards. Petr. On 30.04.2014, at 0:26, Joe Darcy wrote: > Hello, > > Now that Henry's fixes of raw and unchecked warnings in sun.awt has been pushed, please review this change to fix issues in java.awt: > > JDK-8039109 : Fix unchecked and raw lint warnings in java.awt > http://cr.openjdk.java.net/~darcy/8039109.1/ > > Full patch below. A few points of interest in the patch: > > * There is a change to the signature of a public method in java.awt.image.renderable.ParameterBlock.java (I believe that is the only such change in this patch; internally, a ccc request will be filed for this part of the fix.) > > * In my estimation the changes in java.awt.GraphicsEnvironment.java are a better use of generics and reflection. > > Thanks, > > -Joe > > --- old/src/share/classes/java/awt/AWTKeyStroke.java 2014-04-29 13:01:10.000000000 -0700 > +++ new/src/share/classes/java/awt/AWTKeyStroke.java 2014-04-29 13:01:10.000000000 -0700 > @@ -86,7 +86,8 @@ > * Must be called under locked AWTKeyStro > */ > private static Class getAWTKeyStrokeClass() { > - Class clazz = (Class)AppContext.getAppContext().get(AWTKeyStroke.class); > + @SuppressWarnings("unchecked") > + Class clazz = (Class)AppContext.getAppContext().get(AWTKeyStroke.class); > if (clazz == null) { > clazz = AWTKeyStroke.class; > AppContext.getAppContext().put(AWTKeyStroke.class, AWTKeyStroke.class); > @@ -182,6 +183,7 @@ > throw new IllegalArgumentException("subclass cannot be null"); > } > synchronized (AWTKeyStroke.class) { > + @SuppressWarnings("unchecked") > Class keyStrokeClass = (Class)AppContext.getAppContext().get(AWTKeyStroke.class); > if (keyStrokeClass != null && keyStrokeClass.equals(subclass)){ > // Already registered > @@ -192,7 +194,7 @@ > throw new ClassCastException("subclass is not derived from AWTKeyStroke"); > } > > - Constructor ctor = getCtor(subclass); > + Constructor ctor = getCtor(subclass); > > String couldNotInstantiate = "subclass could not be instantiated"; > > @@ -227,12 +229,12 @@ > threat as accessible flag is set only for this Constructor object, > not for Class constructor. > */ > - private static Constructor getCtor(final Class clazz) > + private static Constructor getCtor(final Class clazz) > { > - Constructor ctor = AccessController.doPrivileged(new PrivilegedAction() { > - public Constructor run() { > + Constructor ctor = AccessController.doPrivileged(new PrivilegedAction>() { > + public Constructor run() { > try { > - Constructor ctor = clazz.getDeclaredConstructor((Class[]) null); > + Constructor ctor = clazz.getDeclaredConstructor((Class[]) null); > if (ctor != null) { > ctor.setAccessible(true); > } > @@ -249,7 +251,9 @@ > private static synchronized AWTKeyStroke getCachedStroke > (char keyChar, int keyCode, int modifiers, boolean onKeyRelease) > { > + @SuppressWarnings("unchecked") > Map cache = (Map)AppContext.getAppContext().get(APP_CONTEXT_CACHE_KEY); > + @SuppressWarnings("unchecked") > AWTKeyStroke cacheKey = (AWTKeyStroke)AppContext.getAppContext().get(APP_CONTEXT_KEYSTROKE_KEY); > > if (cache == null) { > --- old/src/share/classes/java/awt/CardLayout.java 2014-04-29 13:01:11.000000000 -0700 > +++ new/src/share/classes/java/awt/CardLayout.java 2014-04-29 13:01:11.000000000 -0700 > @@ -560,6 +560,7 @@ > /** > * Reads serializable fields from stream. > */ > + @SuppressWarnings("unchecked") > private void readObject(ObjectInputStream s) > throws ClassNotFoundException, IOException > { > --- old/src/share/classes/java/awt/Component.java 2014-04-29 13:01:11.000000000 -0700 > +++ new/src/share/classes/java/awt/Component.java 2014-04-29 13:01:11.000000000 -0700 > @@ -6184,7 +6184,7 @@ > /** > * Parameter types of coalesceEvents(AWTEvent,AWTEVent). > */ > - private static final Class[] coalesceEventsParams = { > + private static final Class[] coalesceEventsParams = { > AWTEvent.class, AWTEvent.class > }; > > --- old/src/share/classes/java/awt/GraphicsEnvironment.java 2014-04-29 13:01:12.000000000 -0700 > +++ new/src/share/classes/java/awt/GraphicsEnvironment.java 2014-04-29 13:01:12.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -95,18 +95,18 @@ > String nm = AccessController.doPrivileged(new GetPropertyAction("java.awt.graphicsenv", null)); > try { > // long t0 = System.currentTimeMillis(); > - Class geCls; > + Class geCls; > try { > // First we try if the bootclassloader finds the requested > // class. This way we can avoid to run in a privileged block. > - geCls = (Class)Class.forName(nm); > + geCls = Class.forName(nm); > } catch (ClassNotFoundException ex) { > // If the bootclassloader fails, we try again with the > // application classloader. > ClassLoader cl = ClassLoader.getSystemClassLoader(); > - geCls = (Class)Class.forName(nm, true, cl); > + geCls = Class.forName(nm, true, cl); > } > - ge = geCls.newInstance(); > + ge = GraphicsEnvironment.class.cast(geCls.newInstance()); > // long t1 = System.currentTimeMillis(); > // System.out.println("GE creation took " + (t1-t0)+ "ms."); > if (isHeadless()) { > --- old/src/share/classes/java/awt/KeyboardFocusManager.java 2014-04-29 13:01:13.000000000 -0700 > +++ new/src/share/classes/java/awt/KeyboardFocusManager.java 2014-04-29 13:01:12.000000000 -0700 > @@ -348,6 +348,7 @@ > * Component of those Windows that has no such array of its own explicitly > * set. > */ > + @SuppressWarnings({"unchecked", "rawtypes"}) > private Set[] defaultFocusTraversalKeys = new Set[4]; > > /** > @@ -422,7 +423,7 @@ > targetSet.add(AWTKeyStroke.getAWTKeyStroke(tokens.nextToken())); > } > return (targetSet.isEmpty()) > - ? Collections.EMPTY_SET > + ? Collections.emptySet() > : Collections.unmodifiableSet(targetSet); > } > > @@ -436,7 +437,7 @@ > work_set.add(defaultFocusTraversalKeyStrokes[i][j]); > } > defaultFocusTraversalKeys[i] = (work_set.isEmpty()) > - ? Collections.EMPTY_SET > + ? Collections.emptySet() > : Collections.unmodifiableSet(work_set); > } > initPeer(); > @@ -1750,11 +1751,12 @@ > * @see #addKeyEventDispatcher > * @see #removeKeyEventDispatcher > */ > + @SuppressWarnings("unchecked") // Cast of result of clone > protected synchronized java.util.List > getKeyEventDispatchers() > { > return (keyEventDispatchers != null) > - ? (java.util.List)keyEventDispatchers.clone() > + ? (java.util.List)keyEventDispatchers.clone() > : null; > } > > @@ -1841,11 +1843,12 @@ > * @see #addKeyEventPostProcessor > * @see #removeKeyEventPostProcessor > */ > + @SuppressWarnings("unchecked") // Cast of result of clone > protected java.util.List > getKeyEventPostProcessors() > { > return (keyEventPostProcessors != null) > - ? (java.util.List)keyEventPostProcessors.clone() > + ? (java.util.List)keyEventPostProcessors.clone() > : null; > } > > @@ -1907,8 +1910,7 @@ > * javax.swing.JComponent.runInputVerifier() using reflection. > */ > static synchronized Component getMostRecentFocusOwner(Window window) { > - WeakReference weakValue = > - (WeakReference)mostRecentFocusOwners.get(window); > + WeakReference weakValue = mostRecentFocusOwners.get(window); > return weakValue == null ? null : weakValue.get(); > } > > --- old/src/share/classes/java/awt/SystemTray.java 2014-04-29 13:01:13.000000000 -0700 > +++ new/src/share/classes/java/awt/SystemTray.java 2014-04-29 13:01:13.000000000 -0700 > @@ -259,7 +259,9 @@ > Vector icons = null; > synchronized (this) { > oldArray = systemTray.getTrayIcons(); > - icons = (Vector)AppContext.getAppContext().get(TrayIcon.class); > + @SuppressWarnings("unchecked") > + Vector tmp = (Vector)AppContext.getAppContext().get(TrayIcon.class); > + icons = tmp; > if (icons == null) { > icons = new Vector(3); > AppContext.getAppContext().put(TrayIcon.class, icons); > @@ -304,6 +306,7 @@ > TrayIcon[] oldArray = null, newArray = null; > synchronized (this) { > oldArray = systemTray.getTrayIcons(); > + @SuppressWarnings("unchecked") > Vector icons = (Vector)AppContext.getAppContext().get(TrayIcon.class); > // TrayIcon with no peer is not contained in the array. > if (icons == null || !icons.remove(trayIcon)) { > @@ -335,6 +338,7 @@ > * @see TrayIcon > */ > public TrayIcon[] getTrayIcons() { > + @SuppressWarnings("unchecked") > Vector icons = (Vector)AppContext.getAppContext().get(TrayIcon.class); > if (icons != null) { > return icons.toArray(new TrayIcon[icons.size()]); > --- old/src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java 2014-04-29 13:01:14.000000000 -0700 > +++ new/src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java 2014-04-29 13:01:14.000000000 -0700 > @@ -296,14 +296,14 @@ > /** > * @return a clone of this object > */ > - > + @SuppressWarnings("unchecked") // Cast from clone > public Object clone() { > MimeTypeParameterList newObj = null; > try { > newObj = (MimeTypeParameterList)super.clone(); > } catch (CloneNotSupportedException cannotHappen) { > } > - newObj.parameters = (Hashtable)parameters.clone(); > + newObj.parameters = (Hashtable)parameters.clone(); > return newObj; > } > > --- old/src/share/classes/java/awt/dnd/DragGestureEvent.java 2014-04-29 13:01:14.000000000 -0700 > +++ new/src/share/classes/java/awt/dnd/DragGestureEvent.java 2014-04-29 13:01:14.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -357,6 +357,7 @@ > action = newAction; > > // Pre-1.4 support. 'events' was previously non-transient > + @SuppressWarnings("rawtypes") > List newEvents; > try { > newEvents = (List)f.get("events", null); > --- old/src/share/classes/java/awt/geom/Area.java 2014-04-29 13:01:15.000000000 -0700 > +++ new/src/share/classes/java/awt/geom/Area.java 2014-04-29 13:01:15.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2006, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -97,9 +97,9 @@ > * @since 1.2 > */ > public class Area implements Shape, Cloneable { > - private static Vector EmptyCurves = new Vector(); > + private static Vector EmptyCurves = new Vector<>(); > > - private Vector curves; > + private Vector curves; > > /** > * Default constructor which creates an empty area. > @@ -127,8 +127,8 @@ > } > } > > - private static Vector pathToCurves(PathIterator pi) { > - Vector curves = new Vector(); > + private static Vector pathToCurves(PathIterator pi) { > + Vector curves = new Vector<>(); > int windingRule = pi.getWindingRule(); > // coords array is big enough for holding: > // coordinates returned from currentSegment (6) > @@ -334,7 +334,7 @@ > * @since 1.2 > */ > public void reset() { > - curves = new Vector(); > + curves = new Vector<>(); > invalidateBounds(); > } > > @@ -357,9 +357,9 @@ > * @since 1.2 > */ > public boolean isPolygonal() { > - Enumeration enum_ = curves.elements(); > + Enumeration enum_ = curves.elements(); > while (enum_.hasMoreElements()) { > - if (((Curve) enum_.nextElement()).getOrder() > 1) { > + if (enum_.nextElement().getOrder() > 1) { > return false; > } > } > @@ -381,8 +381,8 @@ > if (size > 3) { > return false; > } > - Curve c1 = (Curve) curves.get(1); > - Curve c2 = (Curve) curves.get(2); > + Curve c1 = curves.get(1); > + Curve c2 = curves.get(2); > if (c1.getOrder() != 1 || c2.getOrder() != 1) { > return false; > } > @@ -411,10 +411,10 @@ > if (curves.size() < 3) { > return true; > } > - Enumeration enum_ = curves.elements(); > + Enumeration enum_ = curves.elements(); > enum_.nextElement(); // First Order0 "moveto" > while (enum_.hasMoreElements()) { > - if (((Curve) enum_.nextElement()).getOrder() == 0) { > + if (enum_.nextElement().getOrder() == 0) { > return false; > } > } > @@ -431,11 +431,11 @@ > } > Rectangle2D r = new Rectangle2D.Double(); > if (curves.size() > 0) { > - Curve c = (Curve) curves.get(0); > + Curve c = curves.get(0); > // First point is always an order 0 curve (moveto) > r.setRect(c.getX0(), c.getY0(), 0, 0); > for (int i = 1; i < curves.size(); i++) { > - ((Curve) curves.get(i)).enlarge(r); > + curves.get(i).enlarge(r); > } > } > return (cachedBounds = r); > @@ -507,7 +507,7 @@ > if (other == null) { > return false; > } > - Vector c = new AreaOp.XorOp().calculate(this.curves, other.curves); > + Vector c = new AreaOp.XorOp().calculate(this.curves, other.curves); > return c.isEmpty(); > } > > @@ -555,10 +555,10 @@ > if (!getCachedBounds().contains(x, y)) { > return false; > } > - Enumeration enum_ = curves.elements(); > + Enumeration enum_ = curves.elements(); > int crossings = 0; > while (enum_.hasMoreElements()) { > - Curve c = (Curve) enum_.nextElement(); > + Curve c = enum_.nextElement(); > crossings += c.crossingsFor(x, y); > } > return ((crossings & 1) == 1); > @@ -658,16 +658,16 @@ > > class AreaIterator implements PathIterator { > private AffineTransform transform; > - private Vector curves; > + private Vector curves; > private int index; > private Curve prevcurve; > private Curve thiscurve; > > - public AreaIterator(Vector curves, AffineTransform at) { > + public AreaIterator(Vector curves, AffineTransform at) { > this.curves = curves; > this.transform = at; > if (curves.size() >= 1) { > - thiscurve = (Curve) curves.get(0); > + thiscurve = curves.get(0); > } > } > > @@ -689,7 +689,7 @@ > prevcurve = thiscurve; > index++; > if (index < curves.size()) { > - thiscurve = (Curve) curves.get(index); > + thiscurve = curves.get(index); > if (thiscurve.getOrder() != 0 && > prevcurve.getX1() == thiscurve.getX0() && > prevcurve.getY1() == thiscurve.getY0()) > --- old/src/share/classes/java/awt/image/BufferedImage.java 2014-04-29 13:01:15.000000000 -0700 > +++ new/src/share/classes/java/awt/image/BufferedImage.java 2014-04-29 13:01:15.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -76,7 +76,7 @@ > ColorModel colorModel; > WritableRaster raster; > OffScreenImageSource osis; > - Hashtable properties; > + Hashtable properties; > > boolean isAlphaPremultiplied;// If true, alpha has been premultiplied in > // color channels > @@ -1106,7 +1106,7 @@ > public ImageProducer getSource() { > if (osis == null) { > if (properties == null) { > - properties = new Hashtable(); > + properties = new Hashtable<>(); > } > osis = new OffScreenImageSource(this, properties); > } > --- old/src/share/classes/java/awt/image/CropImageFilter.java 2014-04-29 13:01:16.000000000 -0700 > +++ new/src/share/classes/java/awt/image/CropImageFilter.java 2014-04-29 13:01:16.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2004, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -79,6 +79,7 @@ > * with the filtering operation. > */ > public void setProperties(Hashtable props) { > + @SuppressWarnings("unchecked") > Hashtable p = (Hashtable)props.clone(); > p.put("croprect", new Rectangle(cropX, cropY, cropW, cropH)); > super.setProperties(p); > --- old/src/share/classes/java/awt/image/FilteredImageSource.java 2014-04-29 13:01:16.000000000 -0700 > +++ new/src/share/classes/java/awt/image/FilteredImageSource.java 2014-04-29 13:01:16.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2003, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -68,7 +68,7 @@ > filter = imgf; > } > > - private Hashtable proxies; > + private Hashtable proxies; > > /** > * Adds the specified ImageConsumer > @@ -94,7 +94,7 @@ > */ > public synchronized void addConsumer(ImageConsumer ic) { > if (proxies == null) { > - proxies = new Hashtable(); > + proxies = new Hashtable<>(); > } > if (!proxies.containsKey(ic)) { > ImageFilter imgf = filter.getFilterInstance(ic); > @@ -137,7 +137,7 @@ > */ > public synchronized void removeConsumer(ImageConsumer ic) { > if (proxies != null) { > - ImageFilter imgf = (ImageFilter) proxies.get(ic); > + ImageFilter imgf = proxies.get(ic); > if (imgf != null) { > src.removeConsumer(imgf); > proxies.remove(ic); > @@ -173,9 +173,9 @@ > */ > public void startProduction(ImageConsumer ic) { > if (proxies == null) { > - proxies = new Hashtable(); > + proxies = new Hashtable<>(); > } > - ImageFilter imgf = (ImageFilter) proxies.get(ic); > + ImageFilter imgf = proxies.get(ic); > if (imgf == null) { > imgf = filter.getFilterInstance(ic); > proxies.put(ic, imgf); > @@ -200,7 +200,7 @@ > */ > public void requestTopDownLeftRightResend(ImageConsumer ic) { > if (proxies != null) { > - ImageFilter imgf = (ImageFilter) proxies.get(ic); > + ImageFilter imgf = proxies.get(ic); > if (imgf != null) { > imgf.resendTopDownLeftRight(src); > } > --- old/src/share/classes/java/awt/image/ImageFilter.java 2014-04-29 13:01:17.000000000 -0700 > +++ new/src/share/classes/java/awt/image/ImageFilter.java 2014-04-29 13:01:17.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -104,6 +104,7 @@ > * @exception NullPointerException if props is null > */ > public void setProperties(Hashtable props) { > + @SuppressWarnings("unchecked") > Hashtable p = (Hashtable)props.clone(); > Object o = p.get("filters"); > if (o == null) { > --- old/src/share/classes/java/awt/image/MemoryImageSource.java 2014-04-29 13:01:17.000000000 -0700 > +++ new/src/share/classes/java/awt/image/MemoryImageSource.java 2014-04-29 13:01:17.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -111,8 +111,8 @@ > Object pixels; > int pixeloffset; > int pixelscan; > - Hashtable properties; > - Vector theConsumers = new Vector(); > + Hashtable properties; > + Vector theConsumers = new Vector<>(); > boolean animating; > boolean fullbuffers; > > @@ -197,7 +197,7 @@ > } > > private void initialize(int w, int h, ColorModel cm, > - Object pix, int off, int scan, Hashtable props) { > + Object pix, int off, int scan, Hashtable props) { > width = w; > height = h; > model = cm; > @@ -205,7 +205,7 @@ > pixeloffset = off; > pixelscan = scan; > if (props == null) { > - props = new Hashtable(); > + props = new Hashtable<>(); > } > properties = props; > } > @@ -343,9 +343,9 @@ > public synchronized void setAnimated(boolean animated) { > this.animating = animated; > if (!animating) { > - Enumeration enum_ = theConsumers.elements(); > + Enumeration enum_ = theConsumers.elements(); > while (enum_.hasMoreElements()) { > - ImageConsumer ic = (ImageConsumer) enum_.nextElement(); > + ImageConsumer ic = enum_.nextElement(); > ic.imageComplete(ImageConsumer.STATICIMAGEDONE); > if (isConsumer(ic)) { > ic.imageComplete(ImageConsumer.IMAGEERROR); > @@ -376,9 +376,9 @@ > } > this.fullbuffers = fullbuffers; > if (animating) { > - Enumeration enum_ = theConsumers.elements(); > + Enumeration enum_ = theConsumers.elements(); > while (enum_.hasMoreElements()) { > - ImageConsumer ic = (ImageConsumer) enum_.nextElement(); > + ImageConsumer ic = enum_.nextElement(); > ic.setHints(fullbuffers > ? (ImageConsumer.TOPDOWNLEFTRIGHT | > ImageConsumer.COMPLETESCANLINES) > @@ -474,9 +474,9 @@ > if ((w <= 0 || h <= 0) && !framenotify) { > return; > } > - Enumeration enum_ = theConsumers.elements(); > + Enumeration enum_ = theConsumers.elements(); > while (enum_.hasMoreElements()) { > - ImageConsumer ic = (ImageConsumer) enum_.nextElement(); > + ImageConsumer ic = enum_.nextElement(); > if (w > 0 && h > 0) { > sendPixels(ic, x, y, w, h); > } > --- old/src/share/classes/java/awt/image/ReplicateScaleFilter.java 2014-04-29 13:01:18.000000000 -0700 > +++ new/src/share/classes/java/awt/image/ReplicateScaleFilter.java 2014-04-29 13:01:17.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, 2004, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1996, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -121,6 +121,7 @@ > * with the filtering operation. > */ > public void setProperties(Hashtable props) { > + @SuppressWarnings("unchecked") > Hashtable p = (Hashtable)props.clone(); > String key = "rescale"; > String val = destWidth + "x" + destHeight; > --- old/src/share/classes/java/awt/image/renderable/ParameterBlock.java 2014-04-29 13:01:18.000000000 -0700 > +++ new/src/share/classes/java/awt/image/renderable/ParameterBlock.java 2014-04-29 13:01:18.000000000 -0700 > @@ -153,6 +153,7 @@ > * > * @return an Object clone of the ParameterBlock. > */ > + @SuppressWarnings("unchecked") // casts from clone > public Object clone() { > ParameterBlock theClone; > > @@ -164,10 +165,10 @@ > } > > if (sources != null) { > - theClone.setSources((Vector)sources.clone()); > + theClone.setSources((Vector)sources.clone()); > } > if (parameters != null) { > - theClone.setParameters((Vector)parameters.clone()); > + theClone.setParameters((Vector)parameters.clone()); > } > return (Object) theClone; > } > @@ -280,7 +281,7 @@ > > /** Clears the list of source images. */ > public void removeSources() { > - sources = new Vector(); > + sources = new Vector<>(); > } > > /** > @@ -313,7 +314,7 @@ > > /** Clears the list of parameters. */ > public void removeParameters() { > - parameters = new Vector(); > + parameters = new Vector<>(); > } > > /** > @@ -696,9 +697,9 @@ > * of the parameters. > * @return an array of Class objects. > */ > - public Class [] getParamClasses() { > + public Class[] getParamClasses() { > int numParams = getNumParameters(); > - Class [] classes = new Class[numParams]; > + Class[] classes = new Class[numParams]; > int i; > > for (i = 0; i < numParams; i++) { > --- old/src/share/classes/java/awt/image/renderable/RenderableImageOp.java 2014-04-29 13:01:19.000000000 -0700 > +++ new/src/share/classes/java/awt/image/renderable/RenderableImageOp.java 2014-04-29 13:01:18.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -83,15 +83,16 @@ > * > * @return a (possibly empty) Vector of RenderableImages, or null. > */ > + @SuppressWarnings("unchecked") > public Vector getSources() { > - return getRenderableSources(); > + return (Vector)(Vector)getRenderableSources(); > } > > - private Vector getRenderableSources() { > - Vector sources = null; > + private Vector getRenderableSources() { > + Vector sources = null; > > if (paramBlock.getNumSources() > 0) { > - sources = new Vector(); > + sources = new Vector<>(); > int i = 0; > while (i < paramBlock.getNumSources()) { > Object o = paramBlock.getSource(i); > @@ -314,19 +315,19 @@ > // contains RenderableImage sources, they will be replaced by > // RenderedImages. > ParameterBlock renderedParamBlock = (ParameterBlock)paramBlock.clone(); > - Vector sources = getRenderableSources(); > + Vector sources = getRenderableSources(); > > try { > // This assumes that if there is no renderable source, that there > // is a rendered source in paramBlock > > if (sources != null) { > - Vector renderedSources = new Vector(); > + Vector renderedSources = new Vector<>(); > for (int i = 0; i < sources.size(); i++) { > rcOut = myCRIF.mapRenderContext(i, renderContext, > paramBlock, this); > RenderedImage rdrdImage = > - ((RenderableImage)sources.elementAt(i)).createRendering(rcOut); > + ((RenderableImage)sources.elementAt(i)).createRendering(rcOut); > if (rdrdImage == null) { > return null; > } > --- old/src/share/classes/java/awt/image/renderable/RenderableImageProducer.java 2014-04-29 13:01:19.000000000 -0700 > +++ new/src/share/classes/java/awt/image/renderable/RenderableImageProducer.java 2014-04-29 13:01:19.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2008, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -68,7 +68,7 @@ > RenderContext rc; > > /** A Vector of image consumers. */ > - Vector ics = new Vector(); > + Vector ics = new Vector<>(); > > /** > * Constructs a new RenderableImageProducer from a RenderableImage > @@ -177,12 +177,12 @@ > int width = raster.getWidth(); > int height = raster.getHeight(); > > - Enumeration icList; > + Enumeration icList; > ImageConsumer ic; > // Set up the ImageConsumers > icList = ics.elements(); > while (icList.hasMoreElements()) { > - ic = (ImageConsumer)icList.nextElement(); > + ic = icList.nextElement(); > ic.setDimensions(width,height); > ic.setHints(ImageConsumer.TOPDOWNLEFTRIGHT | > ImageConsumer.COMPLETESCANLINES | > @@ -204,7 +204,7 @@ > // Now send the scanline to the Consumers > icList = ics.elements(); > while (icList.hasMoreElements()) { > - ic = (ImageConsumer)icList.nextElement(); > + ic = icList.nextElement(); > ic.setPixels(0, j, width, 1, colorModel, pix, 0, width); > } > } > @@ -212,7 +212,7 @@ > // Now tell the consumers we're done. > icList = ics.elements(); > while (icList.hasMoreElements()) { > - ic = (ImageConsumer)icList.nextElement(); > + ic = icList.nextElement(); > ic.imageComplete(ImageConsumer.STATICIMAGEDONE); > } > } > --- old/src/share/classes/java/awt/print/Book.java 2014-04-29 13:01:19.000000000 -0700 > +++ new/src/share/classes/java/awt/print/Book.java 2014-04-29 13:01:19.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -47,7 +47,7 @@ > /** > * The set of pages that make up the Book. > */ > - private Vector mPages; > + private Vector mPages; > > /* Instance Methods */ > > @@ -55,7 +55,7 @@ > * Creates a new, empty Book. > */ > public Book() { > - mPages = new Vector(); > + mPages = new Vector(); > } > > /** > @@ -167,7 +167,7 @@ > private BookPage getPage(int pageIndex) > throws ArrayIndexOutOfBoundsException > { > - return (BookPage) mPages.elementAt(pageIndex); > + return mPages.elementAt(pageIndex); > } > > /** > --- old/src/share/classes/java/awt/print/PrinterJob.java 2014-04-29 13:01:20.000000000 -0700 > +++ new/src/share/classes/java/awt/print/PrinterJob.java 2014-04-29 13:01:20.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -74,9 +74,9 @@ > if (security != null) { > security.checkPrintJobAccess(); > } > - return (PrinterJob) java.security.AccessController.doPrivileged( > - new java.security.PrivilegedAction() { > - public Object run() { > + return java.security.AccessController.doPrivileged( > + new java.security.PrivilegedAction() { > + public PrinterJob run() { > String nm = System.getProperty("java.awt.printerjob", null); > try { > return (PrinterJob)Class.forName(nm).newInstance(); > > From joe.darcy at oracle.com Wed Apr 30 08:17:38 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Apr 2014 01:17:38 -0700 Subject: JDK 9 RFR of JDK-8039109 : Fix unchecked and raw lint warnings in java.awt In-Reply-To: <4D6E95D7-3CF0-4031-A817-60DF44215AFC@oracle.com> References: <53600AE5.8080008@oracle.com> <4D6E95D7-3CF0-4031-A817-60DF44215AFC@oracle.com> Message-ID: <5360B1A2.7090206@oracle.com> Hi Petr, Updated webrev uploaded: http://cr.openjdk.java.net/~darcy/8039109.2/ Thanks, -Joe On 04/29/2014 11:21 PM, Petr Pchelko wrote: > Hello, Joe. > > In RenderableImageOp.getRenderableSources only RenderableImage instances are added to the Vector. > So the method could return Vector to avoid the cast in getSources() method. > > With best regards. Petr. > > On 30.04.2014, at 0:26, Joe Darcy wrote: > >> Hello, >> >> Now that Henry's fixes of raw and unchecked warnings in sun.awt has been pushed, please review this change to fix issues in java.awt: >> >> JDK-8039109 : Fix unchecked and raw lint warnings in java.awt >> http://cr.openjdk.java.net/~darcy/8039109.1/ >> >> Full patch below. A few points of interest in the patch: >> >> * There is a change to the signature of a public method in java.awt.image.renderable.ParameterBlock.java (I believe that is the only such change in this patch; internally, a ccc request will be filed for this part of the fix.) >> >> * In my estimation the changes in java.awt.GraphicsEnvironment.java are a better use of generics and reflection. >> >> Thanks, >> >> -Joe >> >> From petr.pchelko at oracle.com Wed Apr 30 08:40:12 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 30 Apr 2014 12:40:12 +0400 Subject: JDK 9 RFR of JDK-8039109 : Fix unchecked and raw lint warnings in java.awt In-Reply-To: <5360B1A2.7090206@oracle.com> References: <53600AE5.8080008@oracle.com> <4D6E95D7-3CF0-4031-A817-60DF44215AFC@oracle.com> <5360B1A2.7090206@oracle.com> Message-ID: <9540C26F-832D-4605-BF00-6337EF38369A@oracle.com> Hello, Joe. The new version looks good to me. Please note that I'm not an expert in java.awt.image.* code, so I'm speaking mostly for the AWT and DnD part. With best regards. Petr. On 30.04.2014, at 12:17, Joe Darcy wrote: > Hi Petr, > > Updated webrev uploaded: > > http://cr.openjdk.java.net/~darcy/8039109.2/ > > Thanks, > > -Joe > > On 04/29/2014 11:21 PM, Petr Pchelko wrote: >> Hello, Joe. >> >> In RenderableImageOp.getRenderableSources only RenderableImage instances are added to the Vector. >> So the method could return Vector to avoid the cast in getSources() method. >> >> With best regards. Petr. >> On 30.04.2014, at 0:26, Joe Darcy wrote: >> >>> Hello, >>> >>> Now that Henry's fixes of raw and unchecked warnings in sun.awt has been pushed, please review this change to fix issues in java.awt: >>> >>> JDK-8039109 : Fix unchecked and raw lint warnings in java.awt >>> http://cr.openjdk.java.net/~darcy/8039109.1/ >>> >>> Full patch below. A few points of interest in the patch: >>> >>> * There is a change to the signature of a public method in java.awt.image.renderable.ParameterBlock.java (I believe that is the only such change in this patch; internally, a ccc request will be filed for this part of the fix.) >>> >>> * In my estimation the changes in java.awt.GraphicsEnvironment.java are a better use of generics and reflection. >>> >>> Thanks, >>> >>> -Joe >>> >>> > From petr.pchelko at oracle.com Wed Apr 30 08:58:00 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 30 Apr 2014 12:58:00 +0400 Subject: [9] Review Request: 8041904 [TESTBUG] Test java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java timesout on Mac Message-ID: Hello, AWT Team. Please review the one-liner fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8041904 The fix is available here: http://cr.openjdk.java.net/~pchelko/9/8041904/webrev/ The problem's that realSync could hang if called during or immediately after DnD operation. I have a bug about this, but I still cannot provide a reliable and simple solution. Everything I have is way overcomplex. This is the only test I know which's affected by the realSync problem, so let's fix it and defer the realSync hang. With best regards. Petr. From petr.pchelko at oracle.com Wed Apr 30 09:04:31 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 30 Apr 2014 13:04:31 +0400 Subject: [9] Review Request: 8036917 [macosx] Native memory leaks. In-Reply-To: References: Message-ID: Hello, It's a reminder about this review. With best regards. Petr. On 21.04.2014, at 16:34, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8036917 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8036917/webrev/ > > The problem: > We overretain native images so they are never deleted. > > The solution: > When we return a native image pointer to Java it's retain count should be 1, > so in case we use alloc-init we should not use retain. The image will be deleted > in CFRetainedResource.dispose > > It's impossible to make a regression test. > > With best regards. Petr. From alexander.zvegintsev at oracle.com Wed Apr 30 09:42:34 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 30 Apr 2014 13:42:34 +0400 Subject: [9] Review Request: 8036917 [macosx] Native memory leaks. In-Reply-To: References: Message-ID: <5360C58A.5070202@oracle.com> Hello, Petr, the fix looks good to me. Thanks, Alexander. On 04/30/2014 01:04 PM, Petr Pchelko wrote: > Hello, > > It's a reminder about this review. > > With best regards. Petr. > > On 21.04.2014, at 16:34, Petr Pchelko wrote: > >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8036917 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/8036917/webrev/ >> >> The problem: >> We overretain native images so they are never deleted. >> >> The solution: >> When we return a native image pointer to Java it's retain count should be 1, >> so in case we use alloc-init we should not use retain. The image will be deleted >> in CFRetainedResource.dispose >> >> It's impossible to make a regression test. >> >> With best regards. Petr. From Sergey.Bylokhov at oracle.com Wed Apr 30 10:16:56 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 30 Apr 2014 14:16:56 +0400 Subject: [9] Review Request: 8041904 [TESTBUG] Test java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java timesout on Mac In-Reply-To: References: Message-ID: <5360CD98.5020807@oracle.com> On 4/30/14 12:58 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the one-liner fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8041904 > The fix is available here: > http://cr.openjdk.java.net/~pchelko/9/8041904/webrev/ > > The problem's that realSync could hang if called during or immediately after DnD operation. I have a bug about > this, but I still cannot provide a reliable and simple solution. Everything I have is way overcomplex. This is the only > test I know which's affected by the realSync problem, so let's fix it and defer the realSync hang. If this is the only one test, which is affected by the bug in the realSync why we try to workaround it? because the fix for realsync can be verified by this test. > > With best regards. Petr. -- Best regards, Sergey. From petr.pchelko at oracle.com Wed Apr 30 10:20:48 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 30 Apr 2014 14:20:48 +0400 Subject: [9] Review Request: 8041904 [TESTBUG] Test java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java timesout on Mac In-Reply-To: <5360CD98.5020807@oracle.com> References: <5360CD98.5020807@oracle.com> Message-ID: <8EAE2E06-6618-4016-AF33-F0DC1139FC45@oracle.com> Hello, Sergey. > If this is the only one test, which is affected by the bug in the realSync why we try to workaround it? because the fix for realsync can be verified by this test. I can write a new test for realSync when I finally come up with some solution. With best regards. Petr. On 30.04.2014, at 14:16, Sergey Bylokhov wrote: > On 4/30/14 12:58 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the one-liner fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8041904 >> The fix is available here: >> http://cr.openjdk.java.net/~pchelko/9/8041904/webrev/ >> >> The problem's that realSync could hang if called during or immediately after DnD operation. I have a bug about >> this, but I still cannot provide a reliable and simple solution. Everything I have is way overcomplex. This is the only >> test I know which's affected by the realSync problem, so let's fix it and defer the realSync hang. > If this is the only one test, which is affected by the bug in the realSync why we try to workaround it? because the fix for realsync can be verified by this test. >> >> With best regards. Petr. > > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Wed Apr 30 10:26:18 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 30 Apr 2014 14:26:18 +0400 Subject: [9] Review Request: 8041904 [TESTBUG] Test java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java timesout on Mac In-Reply-To: <8EAE2E06-6618-4016-AF33-F0DC1139FC45@oracle.com> References: <5360CD98.5020807@oracle.com> <8EAE2E06-6618-4016-AF33-F0DC1139FC45@oracle.com> Message-ID: <5360CFCA.3010104@oracle.com> On 4/30/14 2:20 PM, Petr Pchelko wrote: > Hello, Sergey. > >> If this is the only one test, which is affected by the bug in the realSync why we try to workaround it? because the fix for realsync can be verified by this test. > I can write a new test for realSync when I finally come up with some solution. And most likely it will duplicate this one? > > With best regards. Petr. > > On 30.04.2014, at 14:16, Sergey Bylokhov wrote: > >> On 4/30/14 12:58 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the one-liner fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8041904 >>> The fix is available here: >>> http://cr.openjdk.java.net/~pchelko/9/8041904/webrev/ >>> >>> The problem's that realSync could hang if called during or immediately after DnD operation. I have a bug about >>> this, but I still cannot provide a reliable and simple solution. Everything I have is way overcomplex. This is the only >>> test I know which's affected by the realSync problem, so let's fix it and defer the realSync hang. >> If this is the only one test, which is affected by the bug in the realSync why we try to workaround it? because the fix for realsync can be verified by this test. >>> With best regards. Petr. >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From forax at univ-mlv.fr Wed Apr 30 10:40:52 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 30 Apr 2014 12:40:52 +0200 Subject: JDK 9 RFR of JDK-8039109 : Fix unchecked and raw lint warnings in java.awt In-Reply-To: <53600AE5.8080008@oracle.com> References: <53600AE5.8080008@oracle.com> Message-ID: <5360D334.9070100@univ-mlv.fr> On 04/29/2014 10:26 PM, Joe Darcy wrote: > Hello, > > Now that Henry's fixes of raw and unchecked warnings in sun.awt has > been pushed, please review this change to fix issues in java.awt: > > JDK-8039109 : Fix unchecked and raw lint warnings in java.awt > http://cr.openjdk.java.net/~darcy/8039109.1/ > > Full patch below. A few points of interest in the patch: > > * There is a change to the signature of a public method in > java.awt.image.renderable.ParameterBlock.java (I believe that is the > only such change in this patch; internally, a ccc request will be > filed for this part of the fix.) > > * In my estimation the changes in java.awt.GraphicsEnvironment.java > are a better use of generics and reflection. > > Thanks, > > -Joe > Hi Joe, in AWTKeyStroke, instead of Class clazz = (Class)AppContext.getAppContext().get(AWTKeyStroke.class); I should have the right type Class (the class is a subclass of AWTKeyStroke) and do a classcheck at runtime when the class is extracted instead of later Class clazz = ((Class)AppContext.getAppContext().get(AWTKeyStroke.class)).asSubClass(AWTKeyStroke.class); and I think the second @SuppressWarnings in getCachedStroke() is unnecessary. in GraphicsEnvironment, the last line of your diff can be simplified, ge = GraphicsEnvironment.class.cast(geCls.newInstance()); can be written ge = (GraphicsEnvironment)geCls.newInstance(); which is more readable IMO but will also generate exactly the same bytecode as the current implementation. in KeyboardFocusManager, private Set[] defaultFocusTraversalKeys = new Set[4]; should be private Set[] defaultFocusTraversalKeys = new Set[4]; so @SuppressWarnings("rawtypes") is not needed. in DragGestureEvent, the newEvents should be a List, and @SuppressWarnings("rawtypes") should be a @SuppressWarnings("unchecked") in RenderableImageOp, getRenderableSources() should return a Vector of RenderableImage, public Vector getSources() { getRenderableSources(); } private Vector getRenderableSources() { Vector [9] Review Request: 8042212 [macosx] Toolkit.getScreenResolution() can return incorrect resolution Message-ID: <5360E8F2.5050406@oracle.com> Hello. Please review the small fix for jdk 9. According to documentation CGDisplayScreenSize() can return 0 if display is invalid we should be ready for that. Bug: https://bugs.openjdk.java.net/browse/JDK-8042212 Webrev can be found at: http://cr.openjdk.java.net/~serb/8042212/webrev.00 -- Best regards, Sergey. From petr.pchelko at oracle.com Wed Apr 30 12:17:41 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 30 Apr 2014 16:17:41 +0400 Subject: [9] Review Request: 8042212 [macosx] Toolkit.getScreenResolution() can return incorrect resolution In-Reply-To: <5360E8F2.5050406@oracle.com> References: <5360E8F2.5050406@oracle.com> Message-ID: <1E9FD7F5-BA45-4B38-BD0C-4ED7B4AB4AF7@oracle.com> Hello, Sergey. Looks good. With best regards. Petr. On 30.04.2014, at 16:13, Sergey Bylokhov wrote: > Hello. > Please review the small fix for jdk 9. According to documentation CGDisplayScreenSize() can return 0 if display is invalid we should be ready for that. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8042212 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8042212/webrev.00 > > -- > Best regards, Sergey. > From petr.pchelko at oracle.com Wed Apr 30 13:33:23 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 30 Apr 2014 17:33:23 +0400 Subject: [9] Review Request: 8042219 [macosx] LWComponentPeer should not reference classes from sun.lwawt.macosx Message-ID: <5A83FC97-9887-4759-B6A1-E2DBE71DBEBB@oracle.com> Hello, AWT Team. Please review a simple cleanup fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8042219 The fix is available here: http://cr.openjdk.java.net/~pchelko/9/8042219/webrev/ We should not reference macosx classes in lwawt package. I've also cleaned up CDropTarget class a bit. Thank you. With best regards. Petr. From Sergey.Bylokhov at oracle.com Wed Apr 30 13:58:21 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 30 Apr 2014 17:58:21 +0400 Subject: [9] Review Request: 8042219 [macosx] LWComponentPeer should not reference classes from sun.lwawt.macosx In-Reply-To: <5A83FC97-9887-4759-B6A1-E2DBE71DBEBB@oracle.com> References: <5A83FC97-9887-4759-B6A1-E2DBE71DBEBB@oracle.com> Message-ID: <5361017D.3090200@oracle.com> Hi, Petr. A few comments: 1) if (fDropTarget != null) 1065 System.err.println("CComponent.addDropTarget(): current drop target is non-null."); Should we throw an exception instead or dispose the previous drop target? 2) We can create/dispose DT on any thread? 3) {@inheritDoc} is obvious if no additional information is added. On 4/30/14 5:33 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review a simple cleanup fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8042219 > The fix is available here: > http://cr.openjdk.java.net/~pchelko/9/8042219/webrev/ > > We should not reference macosx classes in lwawt package. I've also cleaned up CDropTarget class a bit. > > Thank you. > With best regards. Petr. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Wed Apr 30 14:34:22 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 30 Apr 2014 18:34:22 +0400 Subject: [9] Review request for 8040291 [macosx] Http-Images are not fully loaded when using ImageIcon Message-ID: <536109EE.1020303@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8040291 webrev: http://cr.openjdk.java.net/~alexsch/8040291/webrev.00 The SunToolkit.prepareResolutionVariant() method wraps the base image observer and passes it to the resolution variant. It leads that the resolution variant notifies the base image about info changing. When the base image is loaded by the MediaTracker and the resolution variant is loaded first it calls the base image observer and wrongly finishes the base image loading. The fix passes the reduced resolution variant info flags to the base image so the base image loading is finished only after notifiing by the original base image observer. Thanks, Alexandr. From philip.race at oracle.com Wed Apr 30 21:19:24 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 Apr 2014 14:19:24 -0700 Subject: [OpenJDK 2D-Dev] Dont use libjpeg-internal macros in splashscreen In-Reply-To: <53616753.9060704@oracle.com> References: <20140430204832.GB2584@redhat.com> <53616753.9060704@oracle.com> Message-ID: <536168DC.3000203@oracle.com> Trying again with awt as "To:" rather than bcc: .. -phil. On 4/30/2014 2:12 PM, Phil Race wrote: > Looks OK to me, but adding awt-dev as splashscreen is owned by AWT. > > -phil. > > On 4/30/2014 1:48 PM, Omair Majid wrote: >> Hi, >> >> As indicated in the libjpeg API documentation [1], the standard libjpeg >> headers are: jpeglib.h, jerror.h, jconfig.h, jmorecfg.h. >> >> splashscreen_jpeg.c violates this layering and uses the SIZEOF macro >> from the non-public header jinclude.h directly. This macro is a wrapper >> over sizeof. The code in splashscreen_jpeg.c already uses sizeof in >> multiple places so it seems like it should be okay to use it in some >> more. >> >> The following webrev fixes it: >> http://cr.openjdk.java.net/~omajid/webrevs/libjpeg-internal-macros/01/ >> >> One motivation of having this patch is that if/when we add >> system-libjpeg support, the header jinclude.h will become inaccessible. >> >> Thanks, >> Omair >> >> [1] http://svn.code.sf.net/p/libjpeg-turbo/code/trunk/libjpeg.txt >> > From joe.darcy at oracle.com Wed Apr 30 23:04:35 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Apr 2014 16:04:35 -0700 Subject: JDK 9 RFR of JDK-8039109 : Fix unchecked and raw lint warnings in java.awt Message-ID: <53618183.2090008@oracle.com> Hi R?mi, > Hi Joe, > > in AWTKeyStroke, instead of > > Class clazz = (Class)AppContext.getAppContext().get(AWTKeyStroke.class); > > I should have the right type Class (the class is a > subclass of AWTKeyStroke) and > do a classcheck at runtime when the class is extracted instead of later > > Class clazz = ((Class)AppContext.getAppContext().get(AWTKeyStroke.class)).asSubClass(AWTKeyStroke.class); As I'm not overly familiar with this code and the app context mechanism, in the context of this lint removal exercise, I'd prefer to leave the timing of the checks as they are today. > > and I think the second @SuppressWarnings in getCachedStroke() is > unnecessary. Right you are; I've removed the second @SuppressWarnings in the next iteration of the patch. > > > in GraphicsEnvironment, the last line of your diff can be simplified, > > ge = GraphicsEnvironment.class.cast(geCls.newInstance()); > > can be written > > ge = (GraphicsEnvironment)geCls.newInstance(); > > which is more readable IMO but will also generate exactly the same > bytecode as the current implementation. Yes, since the type being cast to is unchanging, it is not necessary to do the cast using core reflection; updated in the next iteration. > > > in KeyboardFocusManager, > > private Set[] defaultFocusTraversalKeys = new Set[4]; > > should be > > private Set[] defaultFocusTraversalKeys = new Set[4]; > > so @SuppressWarnings("rawtypes") is not needed. Actually, javac objects to the code you've proposed: src/share/classes/java/awt/KeyboardFocusManager.java:352: error: incompatible types: Set[] cannot be converted to Set[] private Set[] defaultFocusTraversalKeys = new Set[4]; (IIRC, I ran into this when I was first putting the changeset together.) > > > in DragGestureEvent, the newEvents should be a List, > and @SuppressWarnings("rawtypes") should be a @SuppressWarnings("unchecked") For the purposes of this clean up effort, I'm not eager to take on more extensive updates to DragGestureEvent than adding the one @SuppressWarnings. I would encourage the awt team to consider the update you've suggested. > > in RenderableImageOp, > getRenderableSources() should return a Vector of RenderableImage, > > public Vector getSources() { > getRenderableSources(); > } > > private Vector getRenderableSources() { > Vector > all other modifications are OK for me. Newest iteration at: http://cr.openjdk.java.net/~darcy/8039109.3/ Thanks for the review, -Joe From philip.race at oracle.com Wed Apr 30 21:12:51 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 Apr 2014 14:12:51 -0700 Subject: [OpenJDK 2D-Dev] Dont use libjpeg-internal macros in splashscreen In-Reply-To: <20140430204832.GB2584@redhat.com> References: <20140430204832.GB2584@redhat.com> Message-ID: <53616753.9060704@oracle.com> Looks OK to me, but adding awt-dev as splashscreen is owned by AWT. -phil. On 4/30/2014 1:48 PM, Omair Majid wrote: > Hi, > > As indicated in the libjpeg API documentation [1], the standard libjpeg > headers are: jpeglib.h, jerror.h, jconfig.h, jmorecfg.h. > > splashscreen_jpeg.c violates this layering and uses the SIZEOF macro > from the non-public header jinclude.h directly. This macro is a wrapper > over sizeof. The code in splashscreen_jpeg.c already uses sizeof in > multiple places so it seems like it should be okay to use it in some > more. > > The following webrev fixes it: > http://cr.openjdk.java.net/~omajid/webrevs/libjpeg-internal-macros/01/ > > One motivation of having this patch is that if/when we add > system-libjpeg support, the header jinclude.h will become inaccessible. > > Thanks, > Omair > > [1] http://svn.code.sf.net/p/libjpeg-turbo/code/trunk/libjpeg.txt >