From Sergey.Bylokhov at oracle.com Thu Dec 1 00:07:58 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 1 Dec 2016 03:07:58 +0300 Subject: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used In-Reply-To: <49fbb096-b295-f9ef-a1ce-0910d17529f2@oracle.com> References: <88705586-0a68-10d2-ff88-de92f2a65ca4@oracle.com>

<13d71cfb-31b2-927f-a946-6267328d7ca2@oracle.com> Message-ID: <6385dc6a-4562-bbe8-35f1-0b68e041f98d@oracle.com> The fix looks good to me. I suggest to investigate the case where old applications can be broken and provide a public API for all valid cases. Thanks, Alexandr. On 11/30/2016 7:30 PM, Sergey Bylokhov wrote: > On 29.11.16 17:21, Alexandr Scherbatiy wrote: >> On 11/28/2016 7:41 PM, Sergey Bylokhov wrote: >>> Hello. >>> >>> Please review the fix for jdk9. >>> >>> This fix improve encapsulation of java.desktop module. After the fix >>> the method "UIDefaults::addResourceBundle()" will not be able to >>> register resource bundles which are located in the java.desktop >>> module. Only the java.desktop module itself will be able to use such >>> bundles. >> - Will it break existed applications? > > The risk exists, if the application(or custom l&f) uses resource > bundle from the java.desktop module. But these bundles were not a part > of specification(the are located in non-public packages) and a content > is not specified as well. The possible workaround for this is to have > an application/L&f specific bundle. Or to use UIDefault.put(key,value) > to use some non-default values. > >> - Is it a common case that some applications register resource bundles >> from JDK? > > I do not found the usage of UID.addResourceBundle() which register an > internal bundles. > >> - What is the reason that resource bundles from JDK are not supposed >> to be registered by external applications? > > This is internal data which are not exported by the public api in thd > java.desktop module. > >> - Is it applicable for all JDK bundles or it should be allowed to load >> bundles for public L&Fs like Metal and not for internal (Windows)? > > It is applicable for all, because we do not have the public bundles. > >> - Was there the similar issue before the modularization? For example >> an application is not supposed to load internal Java resource bundles if >> the security manager is set. > > Yes, there was such restriction. > > > From alexandr.scherbatiy at oracle.com Thu Dec 1 12:44:30 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 1 Dec 2016 15:44:30 +0300 Subject: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used In-Reply-To: <49fbb096-b295-f9ef-a1ce-0910d17529f2@oracle.com> References: <88705586-0a68-10d2-ff88-de92f2a65ca4@oracle.com>

<8da8b3a8-1387-a309-715c-cebfdea8aded@oracle.com> <9d638874-75ad-6a2c-cce0-10dad221aef7@oracle.com> <4ef3364d-c41b-0790-8eeb-b2b28d657761@oracle.com> <43d71670-cbe8-c46c-1f49-f33877a8c130@oracle.com> <70400080-9986-687e-4c26-513c9158a925@oracle.com> <4071c36f-fd4f-ce3d-9f6b-6280da83f96a@oracle.com> <49fbb096-b295-f9ef-a1ce-0910d17529f2@oracle.com> Message-ID: On 11/30/2016 2:11 AM, Jim Graham wrote: > I agree that the two versions of the paintDoubleBuffered functions > look like they may not have any noticeable performance difference. It > would be nice to avoid the duplication if they don't, I had assumed > that such a performance test had already been done...? There could be 2 problems - There were checks that Graphics g is instanceof Grpahics2D. If it fails it is necessary to fall down to the scale 1. - The BufferedImage is used if the volatile image buffer is disabled. It seems it is necessary to keep both pixels coordinates and sizes for both graphics the passed and the buffer. I would prefer to keep the current fix as is and investigate the problems with the non volatile offscreen image and the paintDoubleBufferedImpl method elimination in a separate issue: JDK-8170593 Non volatile OffscreenBuffer should be scaled in RepaintManager for HiDPI display https://bugs.openjdk.java.net/browse/JDK-8170593 Thanks, Alexandr. > > clipRound() has appropriate logic for matching the results of filling > a path. clipScale() is a more basic "just scale this value and clip > it" type of operation that has uses - not everything needs to match > the rasterization logic of fills. I did a quick grep to see where > clipScale() is used: > > - SG2D.constrain(, ... region) - this method needs to be overhauled as > it currently relies on scaling a region which is not a valid operation > - only paths can be scaled, once they are rasterized into a region it > is too late to adjust their coordinate transform, but I think fixing > this involves fixing shaped components to remember their outline shape > rather than an outline region. :( > > - SG2D.drawHiDPI() - this fix changes one of the instances of using > clipScale() in that method, but not the other one. They should > probably both match. I don't have a good answer for which is the best > rounding method to use here in any case since the original concept was > that we'd extract the integer pixels and pretend that they were an > isolated image, but if we end up with a fractional scale then that > isn't really possible. It may be better to just leave this alone for > now. Does anything about the rest of this fix depend on that change? > Hopefully if RepaintManager does its job right we end up painting the > back buffer to the destination all on integer pixel boundaries on both > the source and dest and so rounding isn't an issue? > > - Region.getScaledRegion() - this method should be deleted. I think > it is only used in SG2D.constrain() which needs to be rewritten as you > cannot scale a region and expect any amount of accuracy, but we live > with it for now until a better fix comes along. I don't think > changing the rounding method used by this method will have any useful > impact, it just needs to be eliminated by fixing the callers to no > longer need it. > > There are a couple of more uses in the AWT that I didn't look too > closely into at this point, but those are the uses within the Java2D > area... > > ...jim > > On 11/24/16 8:40 AM, Sergey Bylokhov wrote: >> I have a few questions which probably discussed already, then ignore it: >> >> - SunGraphics2D.java: As far as I understand the clipScale() was >> replaced by clipRound(), because they have different >> round logic? It seems that when I wrote the clipScale() I was not >> aware about round logic, and looks like we can change >> the clipScale implementation to use clipRound internally instead of >> Math.round(newv), can be fixed by othe fix. >> - Did you check the difference in performance between >> paintDoubleBufferedImpl vs paintDoubleBufferedFPScales? At least >> in terms of heavyweight operations it looks similar, and probably we >> can have only one of them? It has an additional >> benefits that the new code will be tested on the usual system as well. >> >> On 21.11.16 16:59, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8162350/webrev.04 >>> >>> - isFloatingPointScale(AffineTransform) is moved from the >>> SunGraphics2D >>> to the SwingUtilities2 class. >>> >>> Thanks, >>> Alexandr. >>> >>> On 11/18/2016 11:23 PM, Jim Graham wrote: >>>> Hi ALexandr, >>>> >>>> This looks great. >>>> >>>> BTW, when I suggested moving the FPscale test into SG2D I was >>>> suggesting that to avoid having to copy the transform out of it via >>>> getTransform(), but you've found a different solution to that issue >>>> (i.e. the new getTransform(g) method) so it no longer matters where >>>> that utility static function is located. You can move it back to one >>>> of the Swing classes. >>>> >>>> In terms of the logic of choosing which repaint function to use, it >>>> looks like you use the old-style function if the scales don't match, >>>> but won't that cause rendering anomalies? The new code is still an >>>> improvement for the standard HiDPI case, and I'm guessing that >>>> mismatched scales probably never tends to happen, but we might want to >>>> flag it for further investigation. >>>> >>>> +1 relative to whether you want to move the FPscale test back out of >>>> SG2D or not... >>>> >>>> ...jim >>>> >>>> On 11/18/16 1:44 AM, Alexandr Scherbatiy wrote: >>>>> >>>>> Thank you. I see that using the integer device-pixel translations >>>>> preserves the component painting in the same way for >>>>> floating point scales. >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8162350/webrev.03 >>>>> >>>>> - translation adjustment is removed >>>>> - Region.clipRound() is used for pixels coordinates rounding. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 11/16/2016 1:52 AM, Jim Graham wrote: >>>>>> Let me clarify something... >>>>>> >>>>>> On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote: >>>>>>> Let's consider the following use case: >>>>>>> scale = 1.5 >>>>>>> A component calls fillRect(1, 1, 1, 1). >>>>>>> This is (1.5, 1.5, 3.0, 3.0) in the device space >>>>>>> which fills (1, 1, 3, 3) and covers 2x2 pixels >>>>>> >>>>>> Agreed. >>>>>> >>>>>>> Now the area (1, 1, 1, 1) needs to be repainted >>>>>>> create a backbuffer >>>>>>> translate(-1, -1) // move the top left corner of the area to >>>>>>> the zero point >>>>>>> draw the component into the backbuffer: >>>>>>> fillRect(1, 1, 1, 1) -> after translation fillRect(0, 0, 1, >>>>>>> 1) -> after scaling (0.0, 0.0, 1.5, 1.5 ) in the >>>>>>> device space >>>>>>> which fills (0, 0, 1, 1) and covers 1x1 pixels >>>>>> >>>>>> If you did g.setTransform(identity), g.translate(-1, -1), (then >>>>>> restore the scale) then the analysis is as follows: >>>>>> >>>>>> g.setTransform(identity) => [1 0 0] [0 1 0] >>>>>> g.translate(-1, -1) => [1 0 -1] [0 1 -1] >>>>>> g.scale(1.5, 1.5) => [1.5 0 -1] [0 1.5 -1] >>>>>> g.fillRect(1, 1, 1, 1) >>>>>> => coordinates are (1.5-1, 1.5-1, 3-1, 3-1) >>>>>> => (.5, .5, 2, 2) >>>>>> => fills (0, 0, 2, 2) >>>>>> => which covers 2x2 pixels >>>>>> >>>>>> If you did g.translate(-1, -1) on the scaled transform then the >>>>>> analysis is as follows: >>>>>> >>>>>> g.transform is [1.5 0 0] [0 1.5 0] >>>>>> g.translate(-1, -1) is [1.5 0 -1.5] [0 1.5 -1.5] >>>>>> g.fillRect(1, 1, 1, 1) >>>>>> => coordinates are (1.5-1.5, 1.5-1.5, 3-1.5, 3-1.5) >>>>>> => (0, 0, 1.5, 1.5) >>>>>> => fill (0, 0, 1, 1) >>>>>> => covers 1x1 pixels >>>>>> >>>>>> The second operation is what you are describing above and that would >>>>>> be an inappropriate way to perform damage repair >>>>>> because you used a scaled translation which did not result in an >>>>>> integer coordinate translation. >>>>>> >>>>>> Please re-read my previous analysis that shows what happens when you >>>>>> use integer device-pixel translations which are >>>>>> translations that happen using integers on a non-scaled transform. >>>>>> Note that you can add a scale *AFTER* you apply >>>>>> the integer device pixel translation and it will not affect the >>>>>> integer-ness of the translation. You can see above >>>>>> that the difference in how the translate command is issues affects >>>>>> where the translation components of the matrix end >>>>>> up being -1,-1 or -1.5,-1.5... >>>>>> >>>>>> ...jim >>>>> >>> >> >> From ajit.ghaisas at oracle.com Fri Dec 2 06:23:08 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 1 Dec 2016 22:23:08 -0800 (PST) Subject: [9] Review Request: [JDK-8169879] [TEST_BUG] javax/swing/text/GlyphPainter2/6427244/bug6427244.java - compilation failed In-Reply-To: References: <0b9af036-9495-40a9-9448-ffe2805a73e5@default> <3dcbf9c3-ec10-4bc0-a10c-2be6f1407879@default> Message-ID: <727b8ecb-3603-4d2d-9fa7-d39a10f6d692@default> The Fix looks good. Regards, Ajit From: Prasanta Sadhukhan Sent: Wednesday, November 30, 2016 4:47 PM To: Prahalad Kumar Narayanan; swing-dev at openjdk.java.net Subject: Re: [9] Review Request: [JDK-8169879] [TEST_BUG] javax/swing/text/GlyphPainter2/6427244/bug6427244.java - compilation failed ok .looks fine. Regards Prasanta On 11/30/2016 9:35 AM, Prahalad Kumar Narayanan wrote: Thank you for your time in review Prasanta. Please find my responses inline. I guess JComponent.isVisible() does not throw IllegalStateException so 141 } catch (IllegalStateException ex) { is not valid here. As you rightly pointed, IllegalStateException is not invoked by JComponent.isVisble() method. Hence this has been corrected in the new webrev. I also think there is no need of storing in array as we are supposed to get only one point from getLocationOnScreen(). The code is absolutely normal. If we use a local variable (non-array) we will end up with a compilation error saying - " local variables accessed from inner class should be final or effectively final. " The only way you could work around this compilation error is by making the local variable- member of class. I prefer to have the code without deviating much from the author 's original code unless a bizzare bug exists. The new changes are available for review under: http://cr.openjdk.java.net/~pnarayanan/8169879/webrev.03/ Kindly review at your convenience & share feedback. Thank you Have a good day Prahalad N. From: Prasanta Sadhukhan Sent: Tuesday, November 29, 2016 7:15 PM To: Prahalad Kumar Narayanan; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Cc: Sergey Bylokhov Subject: Re: [9] Review Request: [JDK-8169879] [TEST_BUG] javax/swing/text/GlyphPainter2/6427244/bug6427244.java - compilation failed I guess JComponent.isVisible() does not throw IllegalStateException so 141 } catch (IllegalStateException ex) { is not valid here. Probably you can call JComponent.getLocationOnScreen() which throws IllegalStateException in blockTillDisplayed() and update "Point". I also think there is no need of storing in array as we are supposed to get only one point from getLocationOnScreen(). Regards Prasanta On 11/29/2016 10:19 AM, Prahalad Kumar Narayanan wrote: Hello Everyone Request your time in reviewing the fix for - Bug ID: JDK-8169879 Bug Description: . A jtreg test case failed with a compilation error. Fix Description: . Prior to raising the review under the swing umbrella, the fix went through few reviews under 2D group. . In the earlier fix revisions, . The compiler error was fixed and . Dispose method was trigged on the JFrame object upon completion of the test case . The subsequent suggestion was to include all swing API calls on EDT thread . This is addressed in the current fix. . Changes are available for your review. Link: http://cr.openjdk.java.net/~pnarayanan/8169879/webrev.02/ Kindly review at your convenience and provide your suggestions Thank you Have a good day Prahalad N. -----Original Message----- From: Phil Race Sent: Tuesday, November 22, 2016 12:21 AM To: Prahalad Kumar Narayanan; Prasanta Sadhukhan; Sergey Bylokhov; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: [JDK-8169879] [TEST_BUG] javax/swing/text/GlyphPainter2/6427244/bug6427244.java - compilation failed The test does not have the "manual" tag/key so it is intended to be run as an automated test. User interaction will break a lot of automated tests that display a UI. Without looking at the specifics of this one, I'd guess it likely that it just an example of that .. rather than a unique problem. -phil On 11/21/2016 04:56 AM, Prahalad Kumar Narayanan wrote: Thank you for your time in review Prasanta. Appreciate your views. As you noticed, I observed test-failures as well ( by simply moving the mouse ) . There are quite some improvements that could be done to this test-case . But we could address them in a new bug . The current bug fix and related bug (JDK-8166003) relate to fixing critical compilation error that prevents the execution of the test-case. Secondly blockTillDisplayed(tp) holds the current thread with Thread.sleep(). In this case, the Main thread is held from proceeding further. So it's better executed in non EDT thread. I've seen many swing test-cases that deploy same logic ( Correct me if my understanding is wrong ). Thank you Have a good day Prahalad N. -----Original Message----- From: Prasanta Sadhukhan Sent: Monday, November 21, 2016 3:48 PM To: Prahalad Kumar Narayanan; Sergey Bylokhov; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: [JDK-8169879] [TEST_BUG] javax/swing/text/GlyphPainter2/6427244/bug6427244.java - compilation failed It seems if user minimize/maximize the frame (which is allowed as per testcase), then the test might fail. I guess we can set the frame to "undecorated" to prevent the user to play with minimize/maximize/close. Also, I am not sure if we can call blockTillDisplayed(tp); outside EDT. Maybe Sergey can comment on that. Lastly, this review should have been done in swing-dev and not 2d-dev. Regards Prasanta On 11/21/2016 1:11 PM, Prahalad Kumar Narayanan wrote: Thank you Prasanta & Sergey for your time in review. Yes. As you pointed, the test file did not have JFrame.dispose() call at the completion of the test. This has been added now and the changes are available for review. Webrev Link: http://cr.openjdk.java.net/~pnarayanan/8169879/webrev.01/ Kindly review the code at your convenience Thank you Have a good day Prahalad N. -----Original Message----- From: Sergey Bylokhov Sent: Friday, November 18, 2016 7:42 PM To: Prasanta Sadhukhan; Prahalad Kumar Narayanan; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: [JDK-8169879] [TEST_BUG] javax/swing/text/GlyphPainter2/6427244/bug6427244.java - compilation failed On 18.11.16 14:33, Prasanta Sadhukhan wrote: I guess in this test too JFrame should be disposed at the end of the test(when the test passed or failed) Correct, good catch. Regards Prasanta On 11/18/2016 2:06 PM, Sergey Bylokhov wrote: Looks fine. On 18.11.16 10:32, Prasanta Sadhukhan wrote: +1 Regards Prasanta On 11/18/2016 12:24 PM, Prahalad Kumar Narayanan wrote: Hello Everyone Good day to you Request your time in reviewing the fix for an error that I introduced in my submission. Bug ID: [JDK-8169879] [TEST_BUG] javax/swing/text/GlyphPainter2/6427244/bug6427244.java - compilation failed Relates to: [JDK-8166003] [PIT][TEST_BUG] missing helper for javax/swing/text/GlyphPainter2/6427244/bug6427244.java Root Cause: . I had missed to merge one-line of code while raising the webrev for JDK-8166003. . This caused the compilation error to persist. . Kindly excuse for this mistake. Fix: . The correction has been done . The change has been verified to work on win7, ubuntu 14, and max sierra OS. . Kindly review the change at your convenience. . Webrev link: http://cr.openjdk.java.net/~pnarayanan/8169879/webrev.00/ Thank you for your time in review Have a good day Prahalad N. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maksim.khramov at oracle.com Fri Dec 2 12:22:41 2016 From: maksim.khramov at oracle.com (Maksim Khramov) Date: Fri, 2 Dec 2016 15:22:41 +0300 Subject: [9] Review request for JDK-8159906: [TEST_BUG] javax/swing/JDialog/Transparency/TransparencyTest.java Message-ID: <187d98d6-9f00-f1be-d40c-ba2bf447514e@oracle.com> Hello, please review this request... Webrev: http://cr.openjdk.java.net/~yan/8159906/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8159906 Test bug. Windows transparency is not supported on Solaris. Test just skip execution in that case Thanks, Maksim. From prasanta.sadhukhan at oracle.com Fri Dec 2 15:01:38 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 2 Dec 2016 20:31:38 +0530 Subject: [9] Review request for JDK-8159906: [TEST_BUG] javax/swing/JDialog/Transparency/TransparencyTest.java In-Reply-To: <187d98d6-9f00-f1be-d40c-ba2bf447514e@oracle.com> References: <187d98d6-9f00-f1be-d40c-ba2bf447514e@oracle.com> Message-ID: You need to add 8159906 to @bug tag. Also, one more thing, since dlgPos is accessed from EDT and main thread shouldn't it be declared volatile? Rest looks fine. Regards Prasanta On 12/2/2016 5:52 PM, Maksim Khramov wrote: > Hello, > > please review this request... > > Webrev: http://cr.openjdk.java.net/~yan/8159906/webrev.00/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8159906 > > Test bug. Windows transparency is not supported on Solaris. Test just > skip execution in that case > > Thanks, > Maksim. From maksim.khramov at oracle.com Mon Dec 5 12:08:27 2016 From: maksim.khramov at oracle.com (Maksim Khramov) Date: Mon, 5 Dec 2016 15:08:27 +0300 Subject: [9] Review request for JDK-8159906: [TEST_BUG] javax/swing/JDialog/Transparency/TransparencyTest.java In-Reply-To: References: <187d98d6-9f00-f1be-d40c-ba2bf447514e@oracle.com> Message-ID: Hello, webrev updated: http://cr.openjdk.java.net/~yan/8159906/webrev.01/ Added bugid DlgPos variable marked as volatile. Thanks, Maksim. On 02.12.2016 18:01, Prasanta Sadhukhan wrote: > You need to add 8159906 to @bug tag. > > Also, one more thing, since dlgPos is accessed from EDT and main > thread shouldn't it be declared volatile? > > Rest looks fine. > Regards > Prasanta > On 12/2/2016 5:52 PM, Maksim Khramov wrote: >> Hello, >> >> please review this request... >> >> Webrev: http://cr.openjdk.java.net/~yan/8159906/webrev.00/ >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8159906 >> >> Test bug. Windows transparency is not supported on Solaris. Test just >> skip execution in that case >> >> Thanks, >> Maksim. > From prasanta.sadhukhan at oracle.com Mon Dec 5 14:11:30 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 5 Dec 2016 19:41:30 +0530 Subject: [9] Review request for JDK-8159906: [TEST_BUG] javax/swing/JDialog/Transparency/TransparencyTest.java In-Reply-To: References: <187d98d6-9f00-f1be-d40c-ba2bf447514e@oracle.com>

Message-ID: +1 Regards Prasanta On 12/5/2016 5:38 PM, Maksim Khramov wrote: > Hello, > > webrev updated: http://cr.openjdk.java.net/~yan/8159906/webrev.01/ > > > Added bugid > DlgPos variable marked as volatile. > > Thanks, > Maksim. > > On 02.12.2016 18:01, Prasanta Sadhukhan wrote: >> You need to add 8159906 to @bug tag. >> >> Also, one more thing, since dlgPos is accessed from EDT and main >> thread shouldn't it be declared volatile? >> >> Rest looks fine. >> Regards >> Prasanta >> On 12/2/2016 5:52 PM, Maksim Khramov wrote: >>> Hello, >>> >>> please review this request... >>> >>> Webrev: http://cr.openjdk.java.net/~yan/8159906/webrev.00/ >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8159906 >>> >>> Test bug. Windows transparency is not supported on Solaris. Test >>> just skip execution in that case >>> >>> Thanks, >>> Maksim. >> > From yuri.nesterenko at oracle.com Mon Dec 5 14:59:49 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Mon, 5 Dec 2016 17:59:49 +0300 Subject: [9] Review request for JDK-8159906: [TEST_BUG] javax/swing/JDialog/Transparency/TransparencyTest.java In-Reply-To: References: <187d98d6-9f00-f1be-d40c-ba2bf447514e@oracle.com>

Message-ID: Fine with me. -yan On 12/05/2016 03:08 PM, Maksim Khramov wrote: > Hello, > > webrev updated: http://cr.openjdk.java.net/~yan/8159906/webrev.01/ > > > Added bugid > DlgPos variable marked as volatile. > > Thanks, > Maksim. > > On 02.12.2016 18:01, Prasanta Sadhukhan wrote: >> You need to add 8159906 to @bug tag. >> >> Also, one more thing, since dlgPos is accessed from EDT and main >> thread shouldn't it be declared volatile? >> >> Rest looks fine. >> Regards >> Prasanta >> On 12/2/2016 5:52 PM, Maksim Khramov wrote: >>> Hello, >>> >>> please review this request... >>> >>> Webrev: http://cr.openjdk.java.net/~yan/8159906/webrev.00/ >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8159906 >>> >>> Test bug. Windows transparency is not supported on Solaris. Test just >>> skip execution in that case >>> >>> Thanks, >>> Maksim. >> > From sergey.bylokhov at oracle.com Tue Dec 6 06:51:41 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 5 Dec 2016 22:51:41 -0800 Subject: [9] Review request for 8027639: JComboBox's popup leaves tracks after closing In-Reply-To: <498c43ff-00f6-1f42-11a9-a01f238f1feb@oracle.com> References: <1a80cff6-a73c-b488-439f-d575bcab76cc@oracle.com> <85c0e893-a986-ef8d-4a77-6e0a24193461@oracle.com> <963dd99c-b677-92b9-15fd-f291846ad741@oracle.com> <42d7e4c1-9696-93e7-e01d-0a9401eff339@oracle.com> <73481511-7931-e352-3214-e05e826093de@oracle.com> <1a776830-5a46-53b5-6e88-b88da0c2db43@oracle.com> <6651f73d-04a6-22a4-fd33-5f8ecc7406c8@oracle.com> <516833ea-7bfb-be0e-7c67-d2584839bf8b@oracle.com> <59db4047-ca31-3bc3-4df1-214fe6c0c652@oracle.com> <96f5fe60-2f2a-72ff-3eef-5bc352694732@oracle.com> <195e6dfc-4514-f7e2-661e-9ee6f93b4194@oracle.com>

<396c3448-0db9-acaf-2cdd-af0ce19006c7@oracle.com> <642d370f-01a6-3668-ecdb-25b37d851826@oracle.com> <498c43ff-00f6-1f42-11a9-a01f238f1feb@oracle.com> Message-ID: <2DB26662-F6C7-402C-A51A-CD91701BB2C8@oracle.com> > 24 ????. 2016 ?., ? 11:32, Semyon Sadetsky ???????(?): > > > > On 24.11.2016 21:11, Sergey Bylokhov wrote: >> On 24.11.16 20:42, Semyon Sadetsky wrote: >>>> It have a different implementations because it has different meaning: >>>> - The non-opaque window is a window which uses transparent background. >>>> - The non-opaque component is the component which require the parents >>>> be painted first. it is not necessary that the background in this case >>>> should be transparent(It is possible that the component draw something >>>> only in some place of its bounds) And transparent color is not always >>>> requires that the component should be non-opaque, because components >>>> can ignore its background. >>> Hmm.. Both JComponent and Window override the same Component.isOpaque() >>> but the property has different meaning for each of them. >> >> The requirements for Window.isOpaque() are a subset of JComponent.isOpaque(). Because the Window does not have the parents, which should/shouldn't be painted. And to be a transparent the Window must have a transparent color. Both of these cases are not applicable to the components. > Having opaque property regulated by user for per-pixel translucency is a mistake because the painted result of the translucent and opaque component will depend on the platform, the used buffer type and the pipe. Why it will depend from the platform, buffer type and pipeline? It should work for all components, and should work for all top level windows if per-pixel translucent is supported. >> >>> Probably, this is a design mistake? >> >> This is how it was implemented long time ago. > It is a good chance to fix the bug at last. This is not a bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Dec 6 14:47:50 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 6 Dec 2016 17:47:50 +0300 Subject: [9] RFR: JDK-8170349: The printed content is beyond the borders. In-Reply-To: <23101f9d-a668-255b-46b5-17c185de55e3@oracle.com> References: <23101f9d-a668-255b-46b5-17c185de55e3@oracle.com> Message-ID: On 12/1/2016 9:16 AM, Prasanta Sadhukhan wrote: > On 11/30/2016 2:53 PM, Prasanta Sadhukhan wrote: >> >> Hi All, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170349 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8170349/webrev.00/ >> >> Please review a fix for a continuation/regression of JDK-8081491 >> in which we made >> sure that we print only the JTable rows/columns that is visible on >> console. >> >> This bug manifests itself as, despite marking JTable PrintMode to >> FIT_WIDTH, we are printing only those columns that are visible on >> console. >> >> However, if JTable PrintMode is FIT_WIDTH, then as per spec >> https://docs.oracle.com/javase/8/docs/api/javax/swing/JTable.PrintMode.html#FIT_WIDTH >> we should print all columns on each page (apparently irrespective of >> what is visible) >> >> The fix takes care of that by making sure the table bounds is >> adjusted to clipwidth [which is already adjusted to total column >> width here >> ] >> so that all columns are printed and also rectangle border is drawn >> encompassing all columns. >> > The reason of adjusting the table bounds was because table.print() > calls BasicTableUI.paint() where we compute visibleBounds > http://hg.openjdk.java.net/jdk9/client/jdk/file/a5e270f2c97d/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java#l1817 > therefore we need to adjust the visibleBounds to entire columns > instead of just the visible columns. Did the test Swing_JTable/Manual/PrintManualTest_FitWidthMultiple pass before the fix for the JDK-8081491? It looks like the table bounds never have been changed in the TablePrintable. Thanks, Alexandr. > > Regards > Prasanta >> The 8081491 testcases passed with this fix as well. >> >> Regards >> Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Dec 6 14:51:03 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 6 Dec 2016 17:51:03 +0300 Subject: [9] Review request for 8074883: Tab key should move to focused button in a button group In-Reply-To: <4a10ac21-693c-fdc3-8b1c-ad84bc9db296@oracle.com> References: <28fd190a-c8dc-fb96-5010-22063186a7e3@oracle.com> <5a628ad3-edac-0b45-7c9e-840315e6d07f@oracle.com> <1aa50e8b-6ac3-9431-2bbc-fea5ec4754a8@oracle.com> <1ab82825-e9c4-5c68-c2bf-63018fb393e4@oracle.com>

<5aecaa3b-6fbc-e4a5-da09-d47de6c201bd@oracle.com> <44aeb9e7-92f0-45cb-bf75-06de3c612199@oracle.com> <80642c14-c243-37df-0c4c-5e7fcf77f3eb@oracle.com> <86049691-31c5-1744-6b03-de609e631b02@oracle.com> <394f97d9-2f39-2fac-61f6-97fa1bc07d00@oracle.com> <421640b9-27de-d5ae-bc1a-2f45605e23fa@oracle.com> <43926eeb-135a-3078-8894-59259a119d1c@oracle.com> <4a10ac21-693c-fdc3-8b1c-ad84bc9db296@oracle.com> Message-ID: The fix looks good to me. Thanks, Alexandr. On 11/29/2016 7:42 PM, Semyon Sadetsky wrote: > Please review the updated webrev: > http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.03/ > > changes: > - according to Sergey's suggestion in the specs term "focusable" is > replaced with "can be the focus owner". > > --Semyon > > > On 11/29/2016 6:34 PM, Sergey Bylokhov wrote: >> On 29.11.16 17:52, Semyon Sadetsky wrote: >>> On 11/29/2016 5:41 PM, Sergey Bylokhov wrote: >>>> On 24.11.16 18:34, Semyon Sadetsky wrote: >>>>>> Yes they are different and can results the different results, but >>>>>> currently spec says the opposite: "(1) method execution is the >>>>>> same as >>>>>> calling (2)". It will be good to rephrase it somehow that we will >>>>>> try >>>>>> to move focus to the selected component. >>>>> I still do not understand what inconsistency between the code and the >>>>> spec did you find. I think it would be easier if you just write your >>>>> vision of the spec. >>>> >>>> Inconsistency is that the "focusable" property can be true but the >>>> component can be disabled. So from the specification point of view the >>>> "selected" button should be focused, but we filter it out in >>>> getGroupSelection() and move the focus to the current button. See >>>> comment below. >>> The specification did not mean the focusable property it "can be a >>> focus >>> owner" (see below) which includes enabled criteria. >> >> And this is what I suggested below: >> >>>> take a look to the parent method where the >>>> next states are covered "displayable, focusable, visible"(enable state >>>> is missing??). So you can use the same text here or use "can be a >>>> focus owner". >> > From prasanta.sadhukhan at oracle.com Tue Dec 6 14:52:29 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 6 Dec 2016 20:22:29 +0530 Subject: [9] RFR: JDK-8170349: The printed content is beyond the borders. In-Reply-To: References: <23101f9d-a668-255b-46b5-17c185de55e3@oracle.com> Message-ID: <17ee522a-a87d-e971-6100-f5ab254a2aa5@oracle.com> On 12/6/2016 8:17 PM, Alexandr Scherbatiy wrote: > On 12/1/2016 9:16 AM, Prasanta Sadhukhan wrote: >> On 11/30/2016 2:53 PM, Prasanta Sadhukhan wrote: >>> >>> Hi All, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170349 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170349/webrev.00/ >>> >>> Please review a fix for a continuation/regression of JDK-8081491 >>> in which we made >>> sure that we print only the JTable rows/columns that is visible on >>> console. >>> >>> This bug manifests itself as, despite marking JTable PrintMode to >>> FIT_WIDTH, we are printing only those columns that are visible on >>> console. >>> >>> However, if JTable PrintMode is FIT_WIDTH, then as per spec >>> https://docs.oracle.com/javase/8/docs/api/javax/swing/JTable.PrintMode.html#FIT_WIDTH >>> we should print all columns on each page (apparently irrespective of >>> what is visible) >>> >>> The fix takes care of that by making sure the table bounds is >>> adjusted to clipwidth [which is already adjusted to total column >>> width here >>> ] >>> so that all columns are printed and also rectangle border is drawn >>> encompassing all columns. >>> >> The reason of adjusting the table bounds was because table.print() >> calls BasicTableUI.paint() where we compute visibleBounds >> http://hg.openjdk.java.net/jdk9/client/jdk/file/a5e270f2c97d/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java#l1817 >> therefore we need to adjust the visibleBounds to entire columns >> instead of just the visible columns. > Did the test Swing_JTable/Manual/PrintManualTest_FitWidthMultiple > pass before the fix for the JDK-8081491? Yes, it did. Regards Prasanta > It looks like the table bounds never have been changed in the > TablePrintable. > > Thanks, > Alexandr. >> >> Regards >> Prasanta >>> The 8081491 testcases passed with this fix as well. >>> >>> Regards >>> Prasanta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Tue Dec 6 20:00:20 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 6 Dec 2016 12:00:20 -0800 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: <1091d2bd-2ff3-6395-9e19-f51ae0413eea@oracle.com> References:

<70594bd0-7b21-f04e-df86-926bdbf340b6@oracle.com> <4971e484-5933-27a2-d2ad-ed58a8f817d6@oracle.com> <2d4dee6e-34aa-77c5-976f-1431976e794b@oracle.com> <34fe8cf6-fbdb-f042-c137-c7035908020d@oracle.com> <668e9d35-82f7-be58-da55-49a40283a52e@oracle.com> <1091d2bd-2ff3-6395-9e19-f51ae0413eea@oracle.com> Message-ID: > 30 ????. 2016 ?., ? 23:11, Semyon Sadetsky ???????(?): > > > > On 01.12.2016 02:52, Sergey Bylokhov wrote: >> On 30.11.16 21:12, Semyon Sadetsky wrote: >>> On 30.11.2016 20:51, Sergey Bylokhov wrote: >>>> On 30.11.16 20:39, Semyon Sadetsky wrote: >>>>>> The user cannot remove internal bundle from the java.desktop, >>>>> Why user cannot remove it? The method is exported. >>>> >>>> Do we talking about UIDefaults.removeResourceBundle()? This method >>>> removes the name of the bundle from the Vector in UIDefault, so when >>>> the data will be requested via UIDefaults.get() an internal resource >>>> bundle will not be used. This method can be used in situations when >>>> the application/L&F want to remove predefined data for some reason. >>>> The bundle itself will be available in java.desktop module, and will >>>> be registered again when some of our l&f will be set. >>>> The purpose of the fix is to encapsulate the java.desktop module >>>> itself, not the data which were loaded already to the UIDefaults map. >>> Interesting. Does it mean that if I register some custom resource bundle >>> it will not affect any UI values because all the values is already >>> cached in some UIDefaults map, is that what you mean? >> >> The cache will be cleared when you register a new bundle. > And if bundle remove the cache is not cleared? If bundle is removed from the list of bundles then the cache will be cleared as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Tue Dec 6 20:01:30 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 6 Dec 2016 12:01:30 -0800 Subject: [9] Review request for 8170387: JLightweightFrame#syncCopyBuffer() may throw IOOBE In-Reply-To: References: <54810d8a-8ae1-e90d-b98f-2f9f4b55fbf1@oracle.com> <00ab93f0-c404-1339-efbd-88813d02ad24@oracle.com> <24403af7-2ba0-ca30-80d4-cf6dde0cd435@oracle.com> Message-ID: >> the x,y,w,h passed to the method are inside the bounds of the component. so the simple expectation which can be done is that >> R(x*scale),R(x*scale),R(y*scale),R(w*scale),R(h*scale) should be inside the image which was created in resizeBuffer(): BufferedImage(R(imgW), R(imgH)). where the "R" is a round operation. >> >> But for some reason the size of the image is smaller, I guess this is because resizeBuffer() use Math.round() and syncCopyBuffer() uses ceil+floor. > No. In most cases this method is called for area less than buffer image size. Global repaint is also possible but it is not often happens, usually on window resize. > Since ceil() is used in JDK as coordinates rounding method it should be used here as well to obtain the maximum repainted area bounds in integer coordinates. But for the global size the round() is used, because the image should fit the external size which uses another coordinates rounding approach. Looks fine to me. I hope Jim can double check this round logic. >> >> >>>> >>>> On 28.11.16 16:50, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Please review fix for JDK9: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8170387 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8170387/webrev.00/ >>>>> >>>>> After the rounding the resulting rectangular area may became bigger than >>>>> the buffer image size and this will cause IOOB error during the >>>>> consequent System#arraycopy() calls. To prevent this error the updated >>>>> area is bounded to the buffer image size. >>>>> >>>>> --Semyon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ox38popugaev at yandex.ru Wed Dec 7 12:53:16 2016 From: ox38popugaev at yandex.ru (=?utf-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCf0L7Qv9C+0LI=?=) Date: Wed, 07 Dec 2016 15:53:16 +0300 Subject: Review request for 8160441: [PIT][TEST_BUG][macosx] javax/swing/JComboBox/8041909/ActionListenerExceptionTest.java Message-ID: <4703821481115196@web6o.yandex.ru> An HTML attachment was scrubbed... URL: From ox38popugaev at yandex.ru Wed Dec 7 12:57:49 2016 From: ox38popugaev at yandex.ru (Alexander Popov) Date: Wed, 07 Dec 2016 15:57:49 +0300 Subject: [9] Review request for 8160441: [PIT][TEST_BUG][macosx] javax/swing/JComboBox/8041909/ActionListenerExceptionTest.java In-Reply-To: <4703821481115196@web6o.yandex.ru> References: <4703821481115196@web6o.yandex.ru> Message-ID: <3633621481115469@web29m.yandex.ru> Hello, review my changes please. Webrev: http://cr.openjdk.java.net/~yan/8160441/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8160441 This is a test bug. On Aqua LaF JScrollPane has index 1. On Metal LaF it has index 0 inside JPopupPane. So, I've decided to generalize finding correct index using do-while loop. Tested on Mac OS X with different LaFs - Aqua, Nimbus, Metal. Works perfectly after fix. I used jdk 9b144 (>b127 See JDK-8041909) for testing. I will add 8160441 to @bug if it is needed. --? Best regards, Alexander. From semyon.sadetsky at oracle.com Wed Dec 7 13:23:26 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 7 Dec 2016 16:23:26 +0300 Subject: [9] Review request for 8160441: [PIT][TEST_BUG][macosx] javax/swing/JComboBox/8041909/ActionListenerExceptionTest.java In-Reply-To: <3633621481115469@web29m.yandex.ru> References: <4703821481115196@web6o.yandex.ru> <3633621481115469@web29m.yandex.ru> Message-ID: Looks good. --Semyon On 07.12.2016 15:57, Alexander Popov wrote: > Hello, > review my changes please. > > Webrev: http://cr.openjdk.java.net/~yan/8160441/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8160441 > > This is a test bug. On Aqua LaF JScrollPane has index 1. On Metal LaF it has index 0 inside JPopupPane. > So, I've decided to generalize finding correct index using do-while loop. > Tested on Mac OS X with different LaFs - Aqua, Nimbus, Metal. Works perfectly after fix. > I used jdk 9b144 (>b127 See JDK-8041909) for testing. > I will add 8160441 to @bug if it is needed. > > -- > Best regards, > Alexander. From yuri.nesterenko at oracle.com Wed Dec 7 13:38:31 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 7 Dec 2016 16:38:31 +0300 Subject: [9] Review request for 8160441: [PIT][TEST_BUG][macosx] javax/swing/JComboBox/8041909/ActionListenerExceptionTest.java In-Reply-To: <3633621481115469@web29m.yandex.ru> References: <4703821481115196@web6o.yandex.ru> <3633621481115469@web29m.yandex.ru> Message-ID: +1 (I personally never add test bug numbers: it is in commit message anyway) -yan On 12/07/2016 03:57 PM, Alexander Popov wrote: > Hello, > review my changes please. > > Webrev: http://cr.openjdk.java.net/~yan/8160441/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8160441 > > This is a test bug. On Aqua LaF JScrollPane has index 1. On Metal LaF it has index 0 inside JPopupPane. > So, I've decided to generalize finding correct index using do-while loop. > Tested on Mac OS X with different LaFs - Aqua, Nimbus, Metal. Works perfectly after fix. > I used jdk 9b144 (>b127 See JDK-8041909) for testing. > I will add 8160441 to @bug if it is needed. > > -- > Best regards, > Alexander. > From semyon.sadetsky at oracle.com Fri Dec 9 09:21:52 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 9 Dec 2016 12:21:52 +0300 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: References:

<70594bd0-7b21-f04e-df86-926bdbf340b6@oracle.com> <4971e484-5933-27a2-d2ad-ed58a8f817d6@oracle.com> <2d4dee6e-34aa-77c5-976f-1431976e794b@oracle.com> <34fe8cf6-fbdb-f042-c137-c7035908020d@oracle.com> <668e9d35-82f7-be58-da55-49a40283a52e@oracle.com> <1091d2bd-2ff3-6395-9e19-f51ae0413eea@oracle.com> Message-ID: On 06.12.2016 23:00, Sergey Bylokhov wrote: > >> 30 ????. 2016 ?., ? 23:11, Semyon Sadetsky >> > >> ???????(?): >> >> >> >> On 01.12.2016 02:52, Sergey Bylokhov wrote: >>> On 30.11.16 21:12, Semyon Sadetsky wrote: >>>> On 30.11.2016 20:51, Sergey Bylokhov wrote: >>>>> On 30.11.16 20:39, Semyon Sadetsky wrote: >>>>>>> The user cannot remove internal bundle from the java.desktop, >>>>>> Why user cannot remove it? The method is exported. >>>>> >>>>> Do we talking about UIDefaults.removeResourceBundle()? This method >>>>> removes the name of the bundle from the Vector in UIDefault, so when >>>>> the data will be requested via UIDefaults.get() an internal resource >>>>> bundle will not be used. This method can be used in situations when >>>>> the application/L&F want to remove predefined data for some reason. >>>>> The bundle itself will be available in java.desktop module, and will >>>>> be registered again when some of our l&f will be set. >>>>> The purpose of the fix is to encapsulate the java.desktop module >>>>> itself, not the data which were loaded already to the UIDefaults map. >>>> Interesting. Does it mean that if I register some custom resource >>>> bundle >>>> it will not affect any UI values because all the values is already >>>> cached in some UIDefaults map, is that what you mean? >>> >>> The cache will be cleared when you register a new bundle. >> And if bundle remove the cache is not cleared? > > If bundle is removed from the list of bundles then the cache will be > cleared as well. Nice. Why the remove method is not modified in the fix? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Dec 9 14:48:57 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 9 Dec 2016 17:48:57 +0300 Subject: [9] RFR: JDK-8170349: The printed content is beyond the borders. In-Reply-To: <17ee522a-a87d-e971-6100-f5ab254a2aa5@oracle.com> References: <23101f9d-a668-255b-46b5-17c185de55e3@oracle.com> <17ee522a-a87d-e971-6100-f5ab254a2aa5@oracle.com> Message-ID: <03e7b947-6969-2ec4-a875-f784d5c03441@oracle.com> On 12/6/2016 5:52 PM, Prasanta Sadhukhan wrote: > On 12/6/2016 8:17 PM, Alexandr Scherbatiy wrote: >> On 12/1/2016 9:16 AM, Prasanta Sadhukhan wrote: >>> On 11/30/2016 2:53 PM, Prasanta Sadhukhan wrote: >>>> >>>> Hi All, >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170349 >>>> >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170349/webrev.00/ >>>> >>>> Please review a fix for a continuation/regression of JDK-8081491 >>>> in which we made >>>> sure that we print only the JTable rows/columns that is visible on >>>> console. >>>> >>>> This bug manifests itself as, despite marking JTable PrintMode to >>>> FIT_WIDTH, we are printing only those columns that are visible on >>>> console. >>>> >>>> However, if JTable PrintMode is FIT_WIDTH, then as per spec >>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/JTable.PrintMode.html#FIT_WIDTH >>>> we should print all columns on each page (apparently irrespective >>>> of what is visible) >>>> >>>> The fix takes care of that by making sure the table bounds is >>>> adjusted to clipwidth [which is already adjusted to total column >>>> width here >>>> ] >>>> so that all columns are printed and also rectangle border is drawn >>>> encompassing all columns. >>>> >>> The reason of adjusting the table bounds was because table.print() >>> calls BasicTableUI.paint() where we compute visibleBounds >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a5e270f2c97d/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java#l1817 >>> therefore we need to adjust the visibleBounds to entire columns >>> instead of just the visible columns. >> Did the test Swing_JTable/Manual/PrintManualTest_FitWidthMultiple >> pass before the fix for the JDK-8081491? Which logic in the fix JDK-8081491 causes that the printing a table with FIT_WIDTH mode stopped to properly work? Thanks, Alexandr. > Yes, it did. > > Regards > Prasanta >> It looks like the table bounds never have been changed in the >> TablePrintable. >> >> Thanks, >> Alexandr. >>> >>> Regards >>> Prasanta >>>> The 8081491 testcases passed with this fix as well. >>>> >>>> Regards >>>> Prasanta >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Dec 9 14:57:52 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 9 Dec 2016 20:27:52 +0530 Subject: [9] RFR: JDK-8170349: The printed content is beyond the borders. In-Reply-To: <03e7b947-6969-2ec4-a875-f784d5c03441@oracle.com> References: <23101f9d-a668-255b-46b5-17c185de55e3@oracle.com> <17ee522a-a87d-e971-6100-f5ab254a2aa5@oracle.com> <03e7b947-6969-2ec4-a875-f784d5c03441@oracle.com> Message-ID: <12ce78ad-39ca-5b25-8c1e-31042b075fc6@oracle.com> On 12/9/2016 8:18 PM, Alexandr Scherbatiy wrote: > On 12/6/2016 5:52 PM, Prasanta Sadhukhan wrote: >> On 12/6/2016 8:17 PM, Alexandr Scherbatiy wrote: >>> On 12/1/2016 9:16 AM, Prasanta Sadhukhan wrote: >>>> On 11/30/2016 2:53 PM, Prasanta Sadhukhan wrote: >>>>> >>>>> Hi All, >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170349 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170349/webrev.00/ >>>>> >>>>> Please review a fix for a continuation/regression of JDK-8081491 >>>>> in which we >>>>> made sure that we print only the JTable rows/columns that is >>>>> visible on console. >>>>> >>>>> This bug manifests itself as, despite marking JTable PrintMode to >>>>> FIT_WIDTH, we are printing only those columns that are visible on >>>>> console. >>>>> >>>>> However, if JTable PrintMode is FIT_WIDTH, then as per spec >>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/JTable.PrintMode.html#FIT_WIDTH >>>>> we should print all columns on each page (apparently irrespective >>>>> of what is visible) >>>>> >>>>> The fix takes care of that by making sure the table bounds is >>>>> adjusted to clipwidth [which is already adjusted to total column >>>>> width here >>>>> ] >>>>> so that all columns are printed and also rectangle border is drawn >>>>> encompassing all columns. >>>>> >>>> The reason of adjusting the table bounds was because table.print() >>>> calls BasicTableUI.paint() where we compute visibleBounds >>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a5e270f2c97d/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java#l1817 >>>> therefore we need to adjust the visibleBounds to entire columns >>>> instead of just the visible columns. >>> Did the test Swing_JTable/Manual/PrintManualTest_FitWidthMultiple >>> pass before the fix for the JDK-8081491? > Which logic in the fix JDK-8081491 causes that the printing a > table with FIT_WIDTH mode stopped to properly work? We calculate visibleBounds in BasicTableUI for 8081491 so even for FIT_WIDTH, it was printing the visible portion of table. Since, in BasicTableUI we cannot access TablePrintable.PrintMode value(since it is private), we need to make sure the table bounds set to full column width so that visibleBounds calculated in BasicTableUI is tricked to believe, that we are printing whole columns. Regards Prasanta > > Thanks, > Alexandr. >> Yes, it did. >> >> Regards >> Prasanta >>> It looks like the table bounds never have been changed in the >>> TablePrintable. >>> >>> Thanks, >>> Alexandr. >>>> >>>> Regards >>>> Prasanta >>>>> The 8081491 testcases passed with this fix as well. >>>>> >>>>> Regards >>>>> Prasanta >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Fri Dec 9 19:21:19 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 9 Dec 2016 11:21:19 -0800 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: References:

Message-ID: Interesting. Does it mean that if I register some custom resource bundle >>>>> it will not affect any UI values because all the values is already >>>>> cached in some UIDefaults map, is that what you mean? >>>> >>>> The cache will be cleared when you register a new bundle. >>> And if bundle remove the cache is not cleared? >> >> If bundle is removed from the list of bundles then the cache will be cleared as well. > Nice. Why the remove method is not modified in the fix? Why it should be modified? It does not expose an internal resource bundles and allow the user to modify the list of bundles in the UIDefaults. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Mon Dec 12 09:09:29 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 12 Dec 2016 12:09:29 +0300 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: References:

Message-ID: On 12/9/2016 10:21 PM, Sergey Bylokhov wrote: > Interesting. Does it mean that if I register some custom resource bundle >>>>>> it will not affect any UI values because all the values is already >>>>>> cached in some UIDefaults map, is that what you mean? >>>>> >>>>> The cache will be cleared when you register a new bundle. >>>> And if bundle remove the cache is not cleared? >>> >>> If bundle is removed from the list of bundles then the cache will be >>> cleared as well. >> Nice. Why the remove method is not modified in the fix? > > Why it should be modified? It does not expose an internal resource > bundles and allow the user to modify the list of bundles in the > UIDefaults. Then why addResourceBundle() is modified to ***not*** > allow the user to modify the list of bundles in the UIDefaults. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Dec 12 21:42:59 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 12 Dec 2016 13:42:59 -0800 Subject: RFR: 8171074 : Test api/javax_swing/UIManager/index.html\#Methods is failing Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8171074 Webrev: http://cr.openjdk.java.net/~prr/8171074/ Other than the @SuppressWarnings, UIManager.setLookAndFeel(String className) is now reverted to how it was before 8155874 -phil. From alexandr.scherbatiy at oracle.com Tue Dec 13 12:43:19 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 13 Dec 2016 15:43:19 +0300 Subject: RFR: 8171074 : Test api/javax_swing/UIManager/index.html\#Methods is failing In-Reply-To: References: Message-ID: The fix looks good to me. Thanks, Alexandr. On 12/13/2016 12:42 AM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8171074 > Webrev: http://cr.openjdk.java.net/~prr/8171074/ > > Other than the @SuppressWarnings, > UIManager.setLookAndFeel(String className) is now reverted > to how it was before 8155874 > > -phil. From semyon.sadetsky at oracle.com Tue Dec 13 12:48:01 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 13 Dec 2016 15:48:01 +0300 Subject: RFR: 8171074 : Test api/javax_swing/UIManager/index.html\#Methods is failing In-Reply-To: References:

Message-ID: <88c191f9-ba8b-1af9-6e37-cdd5e7556458@oracle.com> +1 --Semyon On 13.12.2016 15:43, Alexandr Scherbatiy wrote: > The fix looks good to me. > > Thanks, > Alexandr. > > On 12/13/2016 12:42 AM, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8171074 >> Webrev: http://cr.openjdk.java.net/~prr/8171074/ >> >> Other than the @SuppressWarnings, >> UIManager.setLookAndFeel(String className) is now reverted >> to how it was before 8155874 >> >> -phil. > From alexandr.scherbatiy at oracle.com Tue Dec 13 15:41:39 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 13 Dec 2016 18:41:39 +0300 Subject: [9] Review request for 8169922 SwingMark/TextArea: 2-7% regression on Linux, Mac, Windows in 9-b143 Message-ID: Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8169922 webrev: http://cr.openjdk.java.net/~alexsch/8169922/webrev.00 The fix JDK-8156217 checks presence of the overridden methods with floating point arguments. The proposed fix caches results of found overridden methods with floating point arguments. I run the SwingSet2 with the custom test which intensively creates JTextField, JPasswordField, JTextArea, and JEditorPane. The results of the test running with the following JDK are: 1. Methods with int arguments are always called without the methods overridden check: 45822 // before the fix JDK-8156217 2. Methods with floating point arguments are always called without the methods overridden check: 46175 performance decreasing: 100 * (46175 - 45822) / 45822 = 0.77% 3. Methods with floating point arguments are always called with the methods overridden check: 48836 // fix JDK-8156217 performance decreasing: 100 * (48836 - 45822) / 45822 = 6.58% 4. Methods with floating point arguments are always called and the methods overridden checks are cached: 46592 // current fix performance decreasing: 100 * (46592 - 45822) / 45822 = 1.68% Thanks, Alexandr. From philip.race at oracle.com Tue Dec 13 17:59:14 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 13 Dec 2016 09:59:14 -0800 Subject: [9] Review request for 8169922 SwingMark/TextArea: 2-7% regression on Linux, Mac, Windows in 9-b143 In-Reply-To: References: Message-ID: 821 822 static boolean getFPMethodOverriden(Class cls, String method, 823 FPMethodArgs methodArgs) { 824 FPMethodItem methodItem = new FPMethodItem(cls, method); Where are the definitions of the types FPMethodItem and FPMethodArgs ? 842 methodArgs.getMethodAruments(false), 843 methodArgs.getMethodAruments(true)); getMethodAruments ->getMethodArguments -phil. On 12/13/2016 07:41 AM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8169922 > webrev: http://cr.openjdk.java.net/~alexsch/8169922/webrev.00 > > The fix JDK-8156217 checks presence of the overridden methods with > floating point arguments. > The proposed fix caches results of found overridden methods with > floating point arguments. > > I run the SwingSet2 with the custom test which intensively creates > JTextField, JPasswordField, JTextArea, and JEditorPane. > > The results of the test running with the following JDK are: > 1. Methods with int arguments are always called without the methods > overridden check: 45822 // before the fix JDK-8156217 > 2. Methods with floating point arguments are always called without > the methods overridden check: 46175 > performance decreasing: 100 * (46175 - 45822) / 45822 = 0.77% > 3. Methods with floating point arguments are always called with the > methods overridden check: 48836 // fix JDK-8156217 > performance decreasing: 100 * (48836 - 45822) / 45822 = 6.58% > 4. Methods with floating point arguments are always called and the > methods overridden checks are cached: 46592 // current fix > performance decreasing: 100 * (46592 - 45822) / 45822 = 1.68% > > Thanks, > Alexandr. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Dec 14 10:37:43 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 14 Dec 2016 16:07:43 +0530 Subject: [9] RFR: JDK-8170349: The printed content is beyond the borders. In-Reply-To: <12ce78ad-39ca-5b25-8c1e-31042b075fc6@oracle.com> References: <23101f9d-a668-255b-46b5-17c185de55e3@oracle.com> <17ee522a-a87d-e971-6100-f5ab254a2aa5@oracle.com> <03e7b947-6969-2ec4-a875-f784d5c03441@oracle.com> <12ce78ad-39ca-5b25-8c1e-31042b075fc6@oracle.com> Message-ID: <08956778-484b-3d15-cb2b-e172774f34be@oracle.com> Gentle reminder... Regards Prasanta On 12/9/2016 8:27 PM, Prasanta Sadhukhan wrote: > > > > On 12/9/2016 8:18 PM, Alexandr Scherbatiy wrote: >> On 12/6/2016 5:52 PM, Prasanta Sadhukhan wrote: >>> On 12/6/2016 8:17 PM, Alexandr Scherbatiy wrote: >>>> On 12/1/2016 9:16 AM, Prasanta Sadhukhan wrote: >>>>> On 11/30/2016 2:53 PM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170349 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170349/webrev.00/ >>>>>> >>>>>> Please review a fix for a continuation/regression of JDK-8081491 >>>>>> in which we >>>>>> made sure that we print only the JTable rows/columns that is >>>>>> visible on console. >>>>>> >>>>>> This bug manifests itself as, despite marking JTable PrintMode to >>>>>> FIT_WIDTH, we are printing only those columns that are visible on >>>>>> console. >>>>>> >>>>>> However, if JTable PrintMode is FIT_WIDTH, then as per spec >>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/JTable.PrintMode.html#FIT_WIDTH >>>>>> we should print all columns on each page (apparently irrespective >>>>>> of what is visible) >>>>>> >>>>>> The fix takes care of that by making sure the table bounds is >>>>>> adjusted to clipwidth [which is already adjusted to total column >>>>>> width here >>>>>> ] >>>>>> so that all columns are printed and also rectangle border is >>>>>> drawn encompassing all columns. >>>>>> >>>>> The reason of adjusting the table bounds was because table.print() >>>>> calls BasicTableUI.paint() where we compute visibleBounds >>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a5e270f2c97d/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java#l1817 >>>>> therefore we need to adjust the visibleBounds to entire columns >>>>> instead of just the visible columns. >>>> Did the test Swing_JTable/Manual/PrintManualTest_FitWidthMultiple >>>> pass before the fix for the JDK-8081491? >> Which logic in the fix JDK-8081491 causes that the printing a >> table with FIT_WIDTH mode stopped to properly work? > We calculate visibleBounds in BasicTableUI for 8081491 so even for > FIT_WIDTH, it was printing the visible portion of table. Since, in > BasicTableUI we cannot access TablePrintable.PrintMode value(since it > is private), we need to make sure the table bounds set to full column > width so that visibleBounds calculated in BasicTableUI is tricked to > believe, that we are printing whole columns. > > Regards > Prasanta >> >> Thanks, >> Alexandr. >>> Yes, it did. >>> >>> Regards >>> Prasanta >>>> It looks like the table bounds never have been changed in the >>>> TablePrintable. >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> Regards >>>>> Prasanta >>>>>> The 8081491 testcases passed with this fix as well. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Wed Dec 14 17:11:31 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 14 Dec 2016 20:11:31 +0300 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: References:

Message-ID: >> Interesting. Does it mean that if I register some custom resource bundle >>>>>>> it will not affect any UI values because all the values is already >>>>>>> cached in some UIDefaults map, is that what you mean? >>>>>> >>>>>> The cache will be cleared when you register a new bundle. >>>>> And if bundle remove the cache is not cleared? >>>> >>>> If bundle is removed from the list of bundles then the cache will be cleared as well. >>> Nice. Why the remove method is not modified in the fix? >> >> Why it should be modified? It does not expose an internal resource bundles and allow the user to modify the list of bundles in the UIDefaults. > Then why addResourceBundle() is modified to ***not*** > > allow the user to modify the list of bundles in the UIDefaults. > ? Because addResourceBundle() was modified to ?not? allow the users to expose internal resource bundles(for example the users are not able to read content of some random bundle), only if internal bundles were registered already by java.desktop the user will be able to change/override/remove the data in UIDefauls since this data is accessible already to him(via custom resource bundle or via UIDefault.put(key,value) or via removeResourceBundle()). -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Wed Dec 14 17:30:49 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 14 Dec 2016 20:30:49 +0300 Subject: [9] Review request for 8169922 SwingMark/TextArea: 2-7% regression on Linux, Mac, Windows in 9-b143 In-Reply-To: References: Message-ID: Hi, Alexander. Should not the storage be based on soft references? In the current solution we will store the references to the checked classes forever in the static map. > 13 ???. 2016 ?., ? 18:41, Alexandr Scherbatiy ???????(?): > > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8169922 > webrev: http://cr.openjdk.java.net/~alexsch/8169922/webrev.00 > > The fix JDK-8156217 checks presence of the overridden methods with floating point arguments. > The proposed fix caches results of found overridden methods with floating point arguments. > > I run the SwingSet2 with the custom test which intensively creates JTextField, JPasswordField, JTextArea, and JEditorPane. > > The results of the test running with the following JDK are: > 1. Methods with int arguments are always called without the methods overridden check: 45822 // before the fix JDK-8156217 > 2. Methods with floating point arguments are always called without the methods overridden check: 46175 > performance decreasing: 100 * (46175 - 45822) / 45822 = 0.77% > 3. Methods with floating point arguments are always called with the methods overridden check: 48836 // fix JDK-8156217 > performance decreasing: 100 * (48836 - 45822) / 45822 = 6.58% > 4. Methods with floating point arguments are always called and the methods overridden checks are cached: 46592 // current fix > performance decreasing: 100 * (46592 - 45822) / 45822 = 1.68% > > Thanks, > Alexandr. > From alexandr.scherbatiy at oracle.com Wed Dec 14 20:05:39 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 14 Dec 2016 23:05:39 +0300 Subject: [9] Review request for 8133919 [macosx] JTable grid lines are incorrectly positioned on HiDPI display Message-ID: <9ff48336-b0b5-9f14-0989-fe675cafa5cf@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8133919 webrev: http://cr.openjdk.java.net/~alexsch/8133919/webrev.00 Draw lines calls are replaced by SwingUtilities2.drawHLine()/drawVLine in BasicTableUI. The added test is manual because the Robot takes low-resolution screen-shot so necessary artifacts can be hidden. It will be possible to make the test automated after the fix JDK-8162959 [HiDPI] screenshot artifacts using AWT Robot (see [1]) Thanks, Alexandr. [1] http://mail.openjdk.java.net/pipermail/awt-dev/2016-December/012448.html From philip.race at oracle.com Wed Dec 14 20:43:10 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 14 Dec 2016 12:43:10 -0800 Subject: [9] Review Request: 8169900 The code which use Applets should be deprecated In-Reply-To: References: Message-ID: <2529ee1d-c21a-b57c-a163-250377b10154@oracle.com> Looks OK except for a couple of typo nits below. You can fix those without a new review However you will need a CCC for deprecating the public API AppletInitializer and the Beans.instantiate method which references it 159 * @deprecated It s recommended to use "It is" ? -- 160 * {@link #instantiate(ClassLoader, String, BeanContext)}, because the 161 * Applet API is deprecated. See the Nit picky, but since you need to edit this anyway please break the above in the source as 160 * {@link #instantiate(ClassLoader, String, BeanContext)}, 161 * because the Applet API is deprecated. See the -phil. On 11/17/2016 09:31 AM, Sergey Bylokhov wrote: > Hello. > > Please review the fix for jdk9. > > Some time ago the Applets were deprecated,see JEP-289[1]. After that > the code which uses Applets were marked with > "@SuppressWarnings("deprecation")"[2]. > > This is a request to deprecate such API in JavaBeans and in Swing. > I also mark as deprecated the code which is related to AppletViewer(it > is also deprecated[3]) > > [1] http://openjdk.java.net/jeps/289 > [2] > http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006788.html > [3] https://bugs.openjdk.java.net/browse/JDK-8074165 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169900 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8169900/webrev.00 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Dec 15 06:58:45 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 15 Dec 2016 09:58:45 +0300 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: References:

Message-ID: <586534fe-0ac6-42a4-27c7-f9e9ba8352ed@oracle.com> On 14.12.2016 20:11, Sergey Bylokhov wrote: >>> Interesting. Does it mean that if I register some custom resource bundle >>>>>>>> it will not affect any UI values because all the values is already >>>>>>>> cached in some UIDefaults map, is that what you mean? >>>>>>> >>>>>>> The cache will be cleared when you register a new bundle. >>>>>> And if bundle remove the cache is not cleared? >>>>> >>>>> If bundle is removed from the list of bundles then the cache will >>>>> be cleared as well. >>>> Nice. Why the remove method is not modified in the fix? >>> >>> Why it should be modified? It does not expose an internal resource >>> bundles and allow the user to modify the list of bundles in the >>> UIDefaults. >> Then why addResourceBundle() is modified to ***not*** >> > allow the user to modify the list of bundles in the UIDefaults. >> ? > > Because addResourceBundle() was modified to ?not? allow the users to > expose internal resource bundles(for example the users are not able to > read content of some random bundle), only if internal bundles were > registered already by java.desktop the user will be able to > change/override/remove the data in UIDefauls since this data is > accessible already to him(via custom resource bundle or via > UIDefault.put(key,value) or via removeResourceBundle()). Why not to allow user to load any resource bundle from the java.desktop module assuming that we allow user to modify UIDefaults resource bandles arbitrary? Which violation may take place because of still enabling this? Why specification of the addResourceBundle() doesn't reflect this limitation? It is obvious that the fix bears impact in compatibility. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Thu Dec 15 10:19:08 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 15 Dec 2016 13:19:08 +0300 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: <586534fe-0ac6-42a4-27c7-f9e9ba8352ed@oracle.com> References:

<586534fe-0ac6-42a4-27c7-f9e9ba8352ed@oracle.com> Message-ID: <3661820D-965A-4B4B-8BFB-45D7F7C1C0BC@oracle.com> >> Because addResourceBundle() was modified to ?not? allow the users to expose internal resource bundles(for example the users are not able to read content of some random bundle), only if internal bundles were registered already by java.desktop the user will be able to change/override/remove the data in UIDefauls since this data is accessible already to him(via custom resource bundle or via UIDefault.put(key,value) or via removeResourceBundle()). > Why not to allow user to load any resource bundle from the java.desktop module assuming that we allow user to modify UIDefaults resource bandles arbitrary? Which violation may take place because of still enabling this? Because it is a way to read the data from internal resource bundle. The user can load this data to UIDefaults and read it. This is unrelated to the modification of UIDefault itself, it is related to the fact that private data can be read. > Why specification of the addResourceBundle() doesn't reflect this limitation? It is obvious that the fix bears impact in compatibility. The current spec will allow us to revert back the fix, if the impact on the applications will be hight, but for now it is not expected. From sergey.bylokhov at oracle.com Thu Dec 15 10:24:07 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 15 Dec 2016 13:24:07 +0300 Subject: [9] Review request for 8133919 [macosx] JTable grid lines are incorrectly positioned on HiDPI display In-Reply-To: <9ff48336-b0b5-9f14-0989-fe675cafa5cf@oracle.com> References: <9ff48336-b0b5-9f14-0989-fe675cafa5cf@oracle.com> Message-ID: <45DD5C52-280C-48D6-81E6-CCFD63EE54B7@oracle.com> > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8133919 > webrev: http://cr.openjdk.java.net/~alexsch/8133919/webrev.00 > > Draw lines calls are replaced by SwingUtilities2.drawHLine()/drawVLine in BasicTableUI. > The added test is manual because the Robot takes low-resolution screen-shot so necessary artifacts can be hidden. > It will be possible to make the test automated after the fix JDK-8162959 [HiDPI] screenshot artifacts using AWT Robot (see [1]) Probably it Is possible to automate it via drawing to the image in the paint() method? From alexandr.scherbatiy at oracle.com Thu Dec 15 17:06:06 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 15 Dec 2016 20:06:06 +0300 Subject: [9] Review request for 8169922 SwingMark/TextArea: 2-7% regression on Linux, Mac, Windows in 9-b143 In-Reply-To: References:

Message-ID: Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8169922/webrev.01 - the HashMap is stored in SoftRefence - the typo in getMethodArguments() is fixed - classes FPMethodItem and FPMethodArgs are defined in the PlainView class. Thanks, Alexandr. On 12/14/2016 8:30 PM, Sergey Bylokhov wrote: > Hi, Alexander. > Should not the storage be based on soft references? In the current solution we will store the references to the checked classes forever in the static map. > >> 13 ???. 2016 ?., ? 18:41, Alexandr Scherbatiy ???????(?): >> >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8169922 >> webrev: http://cr.openjdk.java.net/~alexsch/8169922/webrev.00 >> >> The fix JDK-8156217 checks presence of the overridden methods with floating point arguments. >> The proposed fix caches results of found overridden methods with floating point arguments. >> >> I run the SwingSet2 with the custom test which intensively creates JTextField, JPasswordField, JTextArea, and JEditorPane. >> >> The results of the test running with the following JDK are: >> 1. Methods with int arguments are always called without the methods overridden check: 45822 // before the fix JDK-8156217 >> 2. Methods with floating point arguments are always called without the methods overridden check: 46175 >> performance decreasing: 100 * (46175 - 45822) / 45822 = 0.77% >> 3. Methods with floating point arguments are always called with the methods overridden check: 48836 // fix JDK-8156217 >> performance decreasing: 100 * (48836 - 45822) / 45822 = 6.58% >> 4. Methods with floating point arguments are always called and the methods overridden checks are cached: 46592 // current fix >> performance decreasing: 100 * (46592 - 45822) / 45822 = 1.68% >> >> Thanks, >> Alexandr. >> From philip.race at oracle.com Thu Dec 15 23:36:58 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 15 Dec 2016 15:36:58 -0800 Subject: [9] Review request for 8169922 SwingMark/TextArea: 2-7% regression on Linux, Mac, Windows in 9-b143 In-Reply-To: References:

Message-ID: <5e61c9a3-becc-9db7-4ec6-95dfba12ff1a@oracle.com> I just noticed that you spell the new methods with a single d :eg : getFPMethodOverriden Like the variables that were there before it should be getFPMethodOverridden and checkFPMethodOverridden Also, although rather unlikely to be a problem in practice, since there is nothing in the swing rules to prevent constructing a Swing component on a random thread, before adding it to the hierarchy, and the shared Map is populated at construction time, it seems like we need a ConcurrentHashMap .. -phil. On 12/15/2016 09:06 AM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8169922/webrev.01 > > - the HashMap is stored in SoftRefence > - the typo in getMethodArguments() is fixed > - classes FPMethodItem and FPMethodArgs are defined in the PlainView > class. > > Thanks, > Alexandr. > > On 12/14/2016 8:30 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Should not the storage be based on soft references? In the current >> solution we will store the references to the checked classes forever >> in the static map. >> >>> 13 ???. 2016 ?., ? 18:41, Alexandr Scherbatiy >>> ???????(?): >>> >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8169922 >>> webrev: http://cr.openjdk.java.net/~alexsch/8169922/webrev.00 >>> >>> The fix JDK-8156217 checks presence of the overridden methods with >>> floating point arguments. >>> The proposed fix caches results of found overridden methods with >>> floating point arguments. >>> >>> I run the SwingSet2 with the custom test which intensively creates >>> JTextField, JPasswordField, JTextArea, and JEditorPane. >>> >>> The results of the test running with the following JDK are: >>> 1. Methods with int arguments are always called without the >>> methods overridden check: 45822 // before the fix JDK-8156217 >>> 2. Methods with floating point arguments are always called without >>> the methods overridden check: 46175 >>> performance decreasing: 100 * (46175 - 45822) / 45822 = 0.77% >>> 3. Methods with floating point arguments are always called with >>> the methods overridden check: 48836 // fix JDK-8156217 >>> performance decreasing: 100 * (48836 - 45822) / 45822 = 6.58% >>> 4. Methods with floating point arguments are always called and the >>> methods overridden checks are cached: 46592 // current fix >>> performance decreasing: 100 * (46592 - 45822) / 45822 = 1.68% >>> >>> Thanks, >>> Alexandr. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Dec 16 06:35:16 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 16 Dec 2016 09:35:16 +0300 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: <3661820D-965A-4B4B-8BFB-45D7F7C1C0BC@oracle.com> References:

<586534fe-0ac6-42a4-27c7-f9e9ba8352ed@oracle.com> <3661820D-965A-4B4B-8BFB-45D7F7C1C0BC@oracle.com> Message-ID: <4ab60466-8b8a-f2ff-cb99-f6c4cebd017e@oracle.com> On 15.12.2016 13:19, Sergey Bylokhov wrote: >>> Because addResourceBundle() was modified to ?not? allow the users to expose internal resource bundles(for example the users are not able to read content of some random bundle), only if internal bundles were registered already by java.desktop the user will be able to change/override/remove the data in UIDefauls since this data is accessible already to him(via custom resource bundle or via UIDefault.put(key,value) or via removeResourceBundle()). >> Why not to allow user to load any resource bundle from the java.desktop module assuming that we allow user to modify UIDefaults resource bandles arbitrary? Which violation may take place because of still enabling this? > Because it is a way to read the data from internal resource bundle. The user can load this data to UIDefaults and read it. This is unrelated to the modification of UIDefault itself, it is related to the fact that private data can be read. If this private data can be loaded to the UIDefaults or to other class then it will be read anyway. Are the Swing/AWT properties files content really secret? >> Why specification of the addResourceBundle() doesn't reflect this limitation? It is obvious that the fix bears impact in compatibility. > The current spec will allow us to revert back the fix, if the impact on the applications will be hight, but for now it is not expected. This is not a correct approach. If you are really sure that the method should have this restriction to not allow to load any internal resources externally, please present it in the spec. Potential compatibility issues you can address by introducing a new system property. From mandy.chung at oracle.com Fri Dec 16 07:34:42 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 15 Dec 2016 23:34:42 -0800 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: <4ab60466-8b8a-f2ff-cb99-f6c4cebd017e@oracle.com> References:

<586534fe-0ac6-42a4-27c7-f9e9ba8352ed@oracle.com> <3661820D-965A-4B4B-8BFB-45D7F7C1C0BC@oracle.com> <4ab60466-8b8a-f2ff-cb99-f6c4cebd017e@oracle.com> Message-ID: > On Dec 15, 2016, at 10:35 PM, Semyon Sadetsky wrote: > > On 15.12.2016 13:19, Sergey Bylokhov wrote: > >>>> Because addResourceBundle() was modified to ?not? allow the users to expose internal resource bundles(for example the users are not able to read content of some random bundle), only if internal bundles were registered already by java.desktop the user will be able to change/override/remove the data in UIDefauls since this data is accessible already to him(via custom resource bundle or via UIDefault.put(key,value) or via removeResourceBundle()). >>> Why not to allow user to load any resource bundle from the java.desktop module assuming that we allow user to modify UIDefaults resource bandles arbitrary? Which violation may take place because of still enabling this? >> Because it is a way to read the data from internal resource bundle. The user can load this data to UIDefaults and read it. This is unrelated to the modification of UIDefault itself, it is related to the fact that private data can be read. > If this private data can be loaded to the UIDefaults or to other class then it will be read anyway. Are the Swing/AWT properties files content really secret? > >>> Why specification of the addResourceBundle() doesn't reflect this limitation? It is obvious that the fix bears impact in compatibility. >> The current spec will allow us to revert back the fix, if the impact on the applications will be hight, but for now it is not expected. > This is not a correct approach. If you are really sure that the method should have this restriction to not allow to load any internal resources externally, please present it in the spec. Potential compatibility issues you can address by introducing a new system property. Sergey, I suggest to update the spec of UIDefaults::addResourceBundle to: Adds a resource bundle to the list of resource bundles that are searched for localized values. Resource bundles are searched in the reverse order they were added, using the {@linkplain ClassLoader#getSystemClassLoader application class loader}. In other words, the most recently added bundle is searched first. ?? Resource bundles in named module are encapsulated. So resource bundles in java.desktop can?t be accessed by user code. The above spec change will cover this change. This API should be revisited when there is a need to access resource bundles in user-defined module in the future (you may want to file a RFE for it). As for UIDefaults::removeResourceBundle, just an idea to address Semyon?s concern of the inconsistency. Perhaps we want to separate the builtin java.desktop resource bundles from the resourceBundles list so that it can?t be removed. In other words, only the ones added by user code can be removed. Mandy From avik.niyogi at oracle.com Fri Dec 16 08:39:34 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Fri, 16 Dec 2016 14:09:34 +0530 Subject: [9] RFR: JDK-8170349: The printed content is beyond the borders. Message-ID: Fix looks good to me. > > > > On 12/9/2016 8:18 PM, Alexandr Scherbatiy wrote: >> On 12/6/2016 5:52 PM, Prasanta Sadhukhan wrote: >>> On 12/6/2016 8:17 PM, Alexandr Scherbatiy wrote: >>>> On 12/1/2016 9:16 AM, Prasanta Sadhukhan wrote: >>>>> On 11/30/2016 2:53 PM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170349 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170349/webrev.00/ >>>>>> >>>>>> Please review a fix for a continuation/regression of JDK-8081491 >>>>>> > in which we >>>>>> made sure that we print only the JTable rows/columns that is >>>>>> visible on console. >>>>>> >>>>>> This bug manifests itself as, despite marking JTable PrintMode to >>>>>> FIT_WIDTH, we are printing only those columns that are visible on >>>>>> console. >>>>>> >>>>>> However, if JTable PrintMode is FIT_WIDTH, then as per spec >>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/JTable.PrintMode.html#FIT_WIDTH >>>>>> we should print all columns on each page (apparently irrespective >>>>>> of what is visible) >>>>>> >>>>>> The fix takes care of that by making sure the table bounds is >>>>>> adjusted to clipwidth [which is already adjusted to total column >>>>>> width here >>>>>> >] >>>>>> so that all columns are printed and also rectangle border is >>>>>> drawn encompassing all columns. >>>>>> >>>>> The reason of adjusting the table bounds was because table.print() >>>>> calls BasicTableUI.paint() where we compute visibleBounds >>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a5e270f2c97d/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java#l1817 >>>>> therefore we need to adjust the visibleBounds to entire columns >>>>> instead of just the visible columns. >>>> Did the test Swing_JTable/Manual/PrintManualTest_FitWidthMultiple >>>> pass before the fix for the JDK-8081491? >> Which logic in the fix JDK-8081491 causes that the printing a >> table with FIT_WIDTH mode stopped to properly work? > We calculate visibleBounds in BasicTableUI for 8081491 so even for > FIT_WIDTH, it was printing the visible portion of table. Since, in > BasicTableUI we cannot access TablePrintable.PrintMode value(since it > is private), we need to make sure the table bounds set to full column > width so that visibleBounds calculated in BasicTableUI is tricked to > believe, that we are printing whole columns. > > Regards > Prasanta >> >> Thanks, >> Alexandr. >>> Yes, it did. >>> >>> Regards >>> Prasanta >>>> It looks like the table bounds never have been changed in the >>>> TablePrintable. >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> Regards >>>>> Prasanta >>>>>> The 8081491 testcases passed with this fix as well. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Dec 16 11:45:44 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 16 Dec 2016 14:45:44 +0300 Subject: [9] Review request for 8133919 [macosx] JTable grid lines are incorrectly positioned on HiDPI display In-Reply-To: <45DD5C52-280C-48D6-81E6-CCFD63EE54B7@oracle.com> References: <9ff48336-b0b5-9f14-0989-fe675cafa5cf@oracle.com> <45DD5C52-280C-48D6-81E6-CCFD63EE54B7@oracle.com> Message-ID: Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8133919/webrev.01 The test is converted to the automated. Thanks, Alexandr. On 12/15/2016 1:24 PM, Sergey Bylokhov wrote: >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8133919 >> webrev: http://cr.openjdk.java.net/~alexsch/8133919/webrev.00 >> >> Draw lines calls are replaced by SwingUtilities2.drawHLine()/drawVLine in BasicTableUI. >> The added test is manual because the Robot takes low-resolution screen-shot so necessary artifacts can be hidden. >> It will be possible to make the test automated after the fix JDK-8162959 [HiDPI] screenshot artifacts using AWT Robot (see [1]) > Probably it Is possible to automate it via drawing to the image in the paint() method? > From philip.race at oracle.com Fri Dec 16 23:27:20 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 16 Dec 2016 15:27:20 -0800 Subject: RFR: 8171363: [PIT] Four Windows-specific tests fail with InaccessibleObjectException when calling Field.setAccessible() Message-ID: <070054c8-0c66-f6ae-ea54-1ab8a58d75cd@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8171363 Webrev: http://cr.openjdk.java.net/~prr/8171363/ this is mostly about jtreg syntax. A few tests fail due to the updated module system spec. jtreg needs to allow them to access package private fields. ":open" is added on the tests that do this and need runtime access to the non-exported package ":+open" is added on the tests also need compile-time access. -phil. From mandy.chung at oracle.com Fri Dec 16 23:32:20 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 16 Dec 2016 15:32:20 -0800 Subject: RFR: 8171363: [PIT] Four Windows-specific tests fail with InaccessibleObjectException when calling Field.setAccessible() In-Reply-To: <070054c8-0c66-f6ae-ea54-1ab8a58d75cd@oracle.com> References: <070054c8-0c66-f6ae-ea54-1ab8a58d75cd@oracle.com> Message-ID: <320C8F88-AA9C-4EE5-9C0A-9AC6D8DED9A8@oracle.com> > On Dec 16, 2016, at 3:27 PM, Phil Race wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171363 > Webrev: http://cr.openjdk.java.net/~prr/8171363/ +1 Mandy From sergey.bylokhov at oracle.com Mon Dec 19 13:50:58 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 19 Dec 2016 16:50:58 +0300 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: <4ab60466-8b8a-f2ff-cb99-f6c4cebd017e@oracle.com> References:

<586534fe-0ac6-42a4-27c7-f9e9ba8352ed@oracle.com> <3661820D-965A-4B4B-8BFB-45D7F7C1C0BC@oracle.com> <4ab60466-8b8a-f2ff-cb99-f6c4cebd017e@oracle.com> Message-ID: <280CE82D-3847-4ADA-B7F4-E60BB6356025@oracle.com> > Sergey, > > I suggest to update the spec of UIDefaults::addResourceBundle to: > > Adds a resource bundle to the list of resource bundles that are > searched for localized values. Resource bundles are searched in > the reverse order they were added, using the {@linkplain ClassLoader#getSystemClassLoader application class loader}. > In other words, the most recently added bundle is searched first. > > ?? > > Resource bundles in named module are encapsulated. So resource > bundles in java.desktop can?t be accessed by user code. The above > spec change will cover this change. This API should be revisited > when there is a need to access resource bundles in user-defined > module in the future (you may want to file a RFE for it). I am not sure that we should update the spec to clarify its internal implementation, because right now it is unclear how it should work in modules world, when the custom look&feel will be stored in a separate module. This is only the fix for a theoretical security issue, if it is not critical then I prefer to leave the code as is. Or just apply the current change, and leave the possibility to future changes > > As for UIDefaults::removeResourceBundle, just an idea to address > Semyon?s concern of the inconsistency. Perhaps we want to separate > the builtin java.desktop resource bundles from the resourceBundles > list so that it can?t be removed. In other words, only the ones > added by user code can be removed. This change adds unnecessary limitation in UIDefault class, since the problem exists when the user can register internal model which cannot be accessed directly. From mandy.chung at oracle.com Mon Dec 19 16:14:54 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 19 Dec 2016 08:14:54 -0800 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: <280CE82D-3847-4ADA-B7F4-E60BB6356025@oracle.com> References:

<586534fe-0ac6-42a4-27c7-f9e9ba8352ed@oracle.com> <3661820D-965A-4B4B-8BFB-45D7F7C1C0BC@oracle.com> <4ab60466-8b8a-f2ff-cb99-f6c4cebd017e@oracle.com> <280CE82D-3847-4ADA-B7F4-E6! 0BB6356025@oracle.com> Message-ID: <86EA50C3-E073-414A-A3F9-976B3CC16CF8@oracle.com> > On Dec 19, 2016, at 5:59 AM, Sergey Bylokhov wrote: > >> Sergey, >> >> I suggest to update the spec of UIDefaults::addResourceBundle to: >> >> Adds a resource bundle to the list of resource bundles that are >> searched for localized values. Resource bundles are searched in >> the reverse order they were added, using the {@linkplain ClassLoader#getSystemClassLoader application class loader}. >> In other words, the most recently added bundle is searched first. >> This suggests spec clarification not only applies to internal implementation but also reflects the resource encapsulation in JDK 9. java.desktop can?t access to any normal module besides itself unless they are open for it to access. This spec clarification is useful. Mandy >> ?? >> >> Resource bundles in named module are encapsulated. So resource >> bundles in java.desktop can?t be accessed by user code. The above >> spec change will cover this change. This API should be revisited >> when there is a need to access resource bundles in user-defined >> module in the future (you may want to file a RFE for it). > > I am not sure that we should update the spec to clarify its internal implementation, because right now it is unclear how it should work in modules world, when the custom look&feel will be stored in a separate module. > This is only the fix for a theoretical security issue, if it is not critical then I prefer to leave the code as is. Or just apply the current change, and leave the possibility to future changes > >> >> As for UIDefaults::removeResourceBundle, just an idea to address >> Semyon?s concern of the inconsistency. Perhaps we want to separate >> the builtin java.desktop resource bundles from the resourceBundles >> list so that it can?t be removed. In other words, only the ones >> added by user code can be removed. > > This change adds unnecessary limitation in UIDefault class, since the problem exists when the user can register internal model which cannot be accessed directly. From ox38popugaev at yandex.ru Mon Dec 19 16:52:21 2016 From: ox38popugaev at yandex.ru (=?utf-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCf0L7Qv9C+0LI=?=) Date: Mon, 19 Dec 2016 19:52:21 +0300 Subject: [9] Review request for 8165207: [macosx] Test javax/swing/Popup/TaskbarPositionTest.java fails on Mac 10.12 Message-ID: <8642971482166341@web23j.yandex.ru> Hello, review my changes please. Fix for https://bugs.openjdk.java.net/browse/JDK-8165207: Webrev:http://cr.openjdk.java.net/~avstepan/8165207/webrev.01/ Issue: https://bugs.openjdk.java.net/browse/JDK-8165207 This is a test bug. On Aqua LaF JCombobox popup could appear both upper label and arrow and lower. So - check for its coordinates does not make sense. Also fixed Ctrl-down shortcut. It is invalid - it is special shortcut for OS X. Down key is enough to expand combobox. Tested on Mac OS X with different LaFs - Aqua, Nimbus, Metal. Works perfectly after fix. I used jdk 9b144 for testing. --? Best regards, Alexander. From semyon.sadetsky at oracle.com Mon Dec 19 17:10:43 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 19 Dec 2016 20:10:43 +0300 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: References:

<586534fe-0ac6-42a4-27c7-f9e9ba8352ed@oracle.com> <3661820D-965A-4B4B-8BFB-45D7F7C1C0BC@oracle.com> <4ab60466-8b8a-f2ff-cb99-f6c4cebd017e@oracle.com> Message-ID: On 19.12.2016 16:50, Sergey Bylokhov wrote: >> 16 ???. 2016 ?., ? 9:35, Semyon Sadetsky ???????(?): >> >> On 15.12.2016 13:19, Sergey Bylokhov wrote: >> >>>>> Because addResourceBundle() was modified to ?not? allow the users to expose internal resource bundles(for example the users are not able to read content of some random bundle), only if internal bundles were registered already by java.desktop the user will be able to change/override/remove the data in UIDefauls since this data is accessible already to him(via custom resource bundle or via UIDefault.put(key,value) or via removeResourceBundle()). >>>> Why not to allow user to load any resource bundle from the java.desktop module assuming that we allow user to modify UIDefaults resource bandles arbitrary? Which violation may take place because of still enabling this? >>> Because it is a way to read the data from internal resource bundle. The user can load this data to UIDefaults and read it. This is unrelated to the modification of UIDefault itself, it is related to the fact that private data can be read. >> If this private data can be loaded to the UIDefaults or to other class then it will be read anyway. Are the Swing/AWT properties files content really secret? > My point is that there are no secrets, but the bug description states that such bundles can be added some day later. But what secret can be here? >>>> Why specification of the addResourceBundle() doesn't reflect this limitation? It is obvious that the fix bears impact in compatibility. >>> The current spec will allow us to revert back the fix, if the impact on the applications will be hight, but for now it is not expected. >> This is not a correct approach. If you are really sure that the method should have this restriction to not allow to load any internal resources externally, please present it in the spec. Potential compatibility issues you can address by introducing a new system property. > There are no compatibility issues which contradicts the specification, because all our resource bundles are private(unspecified), they are located in the com.XXX packages and all of them can be changed/removed in any time. The fix blocks resources form all desktop module packages not only from "com.XXX", doesn't it? From sergey.bylokhov at oracle.com Mon Dec 19 18:58:13 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 19 Dec 2016 21:58:13 +0300 Subject: [9] Review request for 8165207: [macosx] Test javax/swing/Popup/TaskbarPositionTest.java fails on Mac 10.12 In-Reply-To: <8642971482166341@web23j.yandex.ru> References: <8642971482166341@web23j.yandex.ru> Message-ID: <68F4D5A8-FD17-4224-BCB1-23D38CF8DCAD@oracle.com> Hi, Alex. Can you please clarify on what versions of OS X and JDK the bug can be reproduced? Thanks. > > Hello, > review my changes please. > > Fix for https://bugs.openjdk.java.net/browse/JDK-8165207: > Webrev:http://cr.openjdk.java.net/~avstepan/8165207/webrev.01/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8165207 > > This is a test bug. On Aqua LaF JCombobox popup could appear both upper label and arrow and lower. > So - check for its coordinates does not make sense. Also fixed Ctrl-down shortcut. It is invalid - it is special shortcut for OS X. Down key is enough to expand combobox. > Tested on Mac OS X with different LaFs - Aqua, Nimbus, Metal. Works perfectly after fix. > I used jdk 9b144 for testing. > > -- > Best regards, > Alexander. From sergey.bylokhov at oracle.com Mon Dec 19 19:28:40 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 19 Dec 2016 22:28:40 +0300 Subject: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK In-Reply-To: References: <5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com> <7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com> <7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>

<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com> <3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com> <0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com> <5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com> <5bda0f8a-5dfb-7356-5942-015fc27d6b07@oracle.com> <255c4e87-b58c-1d4d-30ca-97d1d9a710d0@oracle.com> <750f4ba6-5dea-7fb0-c7c1-c207d5cd2912@oracle.com> <241007aa-5fdb-d6a6-f1f8-2eb83433ea69@oracle.com> <027efb5a-666e-debe-cd03-bccb25e7a4e5@oracle.com> Message-ID: <622010F8-1BD8-42D9-926A-D7F12C893949@oracle.com> Hello. Please review an updated version of the fix. - The comments are updated. Two additional public api are deprecated: - KeyEvent.getKeyModifiersText() - AWTEvent(Event event) Note that I have to add @SuppressWarnings("deprecation?) in places where the old API is used, because the option which ignores this warning was removed from the makefile. We will need to fix all of them one by one in jdk10, I?ll file a CR for this. > On 10/26/2016 6:43 PM, Sergey Bylokhov wrote: >> On 25.10.16 18:46, Semyon Sadetsky wrote: >>>> I wonder why he should decide that the old code can be "simply >>>> replaced" by the new one? I suppose that at least he should read the >>>> specification of the new extended API. There is no notion that this >>>> api is replaced by the new one, there is a recommendation that the new >>>> one should be used instead. >>> After reading such recommendation it's hard to conclude that one "should >>> read the specification of the new extended API". Even "@see" tag >>> pointing to the extended API is not provided (I'm not even mentioning >>> the warning that the extended API may be nonequivalent replacement is >>> absent). I read this recommendation as it is: replace one constant with >>> another, no side effects expected. >> >> Good to know that you don't read the specification of the methods before using. So what is your proposal? Should I add a notion that these extendent constants contains different int values, and if the user depends from them in some way then he should not replace the old one to the new one? Or what @see reference should be added from some fields to another? > The proposal is the same to notify user that he/she should not only replace the constant but start to use another API. It's up to you how to formulate this. If I did this in minimalistic way I would write: > > @deprecated It is recommended that SHIFT_DOWN_MASK and {@link getModifiersEx()} be used instead. >> >>>> >>>>>> We already have a notions that these "extended modifier constant" >>>>>> should be used in the constructor of InputEvent and moreover in spec >>>>>> of getModifiersEx() we have an additional examples how to use this >>>>>> constants. This is why we will have a reference from old constans to >>>>>> the new, and from getModifiers() to the getModifiersEx(); -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Mon Dec 19 19:29:21 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 19 Dec 2016 22:29:21 +0300 Subject: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK In-Reply-To: <622010F8-1BD8-42D9-926A-D7F12C893949@oracle.com> References: <5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com> <7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com> <7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>

<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com> <3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com> <0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com> <5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com> <5bda0f8a-5dfb-7356-5942-015fc27d6b07@oracle.com> <255c4e87-b58c-1d4d-30ca-97d1d9a710d0@oracle.com> <750f4ba6-5dea-7fb0-c7c1-c207d5cd2912@oracle.com> <241007aa-5fdb-d6a6-f1f8-2eb83433ea69@oracle.com> <027efb5a-666e-debe-cd03-bccb25e7a4e5@oracle.com> <622010F8-1BD8-42D9-926A-D7F12C893949@oracle.com> Message-ID: <0CC8F46C-C873-4617-B4E4-F2E9BA3F4360@oracle.com> > 19 ???. 2016 ?., ? 22:28, Sergey Bylokhov ???????(?): > > Hello. > Please review an updated version of the fix. > - The comments are updated. > Two additional public api are deprecated: > - KeyEvent.getKeyModifiersText() > - AWTEvent(Event event) > > Note that I have to add @SuppressWarnings("deprecation?) in places where the old API is used, because the option which ignores this warning was removed from the makefile. We will need to fix all of them one by one in jdk10, I?ll file a CR for this. Ouch the link is: http://cr.openjdk.java.net/~serb/8143077/webrev.04/ > >> On 10/26/2016 6:43 PM, Sergey Bylokhov wrote: >>> On 25.10.16 18:46, Semyon Sadetsky wrote: >>>>> I wonder why he should decide that the old code can be "simply >>>>> replaced" by the new one? I suppose that at least he should read the >>>>> specification of the new extended API. There is no notion that this >>>>> api is replaced by the new one, there is a recommendation that the new >>>>> one should be used instead. >>>> After reading such recommendation it's hard to conclude that one "should >>>> read the specification of the new extended API". Even "@see" tag >>>> pointing to the extended API is not provided (I'm not even mentioning >>>> the warning that the extended API may be nonequivalent replacement is >>>> absent). I read this recommendation as it is: replace one constant with >>>> another, no side effects expected. >>> >>> Good to know that you don't read the specification of the methods before using. So what is your proposal? Should I add a notion that these extendent constants contains different int values, and if the user depends from them in some way then he should not replace the old one to the new one? Or what @see reference should be added from some fields to another? >> The proposal is the same to notify user that he/she should not only replace the constant but start to use another API. It's up to you how to formulate this. If I did this in minimalistic way I would write: >> >> @deprecated It is recommended that SHIFT_DOWN_MASK and {@link getModifiersEx()} be used instead. >>> >>>>> >>>>>>> We already have a notions that these "extended modifier constant" >>>>>>> should be used in the constructor of InputEvent and moreover in spec >>>>>>> of getModifiersEx() we have an additional examples how to use this >>>>>>> constants. This is why we will have a reference from old constans to >>>>>>> the new, and from getModifiers() to the getModifiersEx(); > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Tue Dec 20 13:45:14 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 20 Dec 2016 16:45:14 +0300 Subject: [9] Review request for 8133919 [macosx] JTable grid lines are incorrectly positioned on HiDPI display In-Reply-To: References: <9ff48336-b0b5-9f14-0989-fe675cafa5cf@oracle.com> <45DD5C52-280C-48D6-81E6-CCFD63EE54B7@oracle.com> Message-ID: Looks fine. > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8133919/webrev.01 > > The test is converted to the automated. > > Thanks, > Alexandr. > > On 12/15/2016 1:24 PM, Sergey Bylokhov wrote: >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8133919 >>> webrev: http://cr.openjdk.java.net/~alexsch/8133919/webrev.00 >>> >>> Draw lines calls are replaced by SwingUtilities2.drawHLine()/drawVLine in BasicTableUI. >>> The added test is manual because the Robot takes low-resolution screen-shot so necessary artifacts can be hidden. >>> It will be possible to make the test automated after the fix JDK-8162959 [HiDPI] screenshot artifacts using AWT Robot (see [1]) >> Probably it Is possible to automate it via drawing to the image in the paint() method? >> > From sergey.bylokhov at oracle.com Tue Dec 20 14:56:48 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 20 Dec 2016 17:56:48 +0300 Subject: [9] Review request for 8169922 SwingMark/TextArea: 2-7% regression on Linux, Mac, Windows in 9-b143 In-Reply-To: References:

Message-ID: Looks fine. > > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8169922/webrev.01 > > - the HashMap is stored in SoftRefence > - the typo in getMethodArguments() is fixed > - classes FPMethodItem and FPMethodArgs are defined in the PlainView class. > > Thanks, > Alexandr. > > On 12/14/2016 8:30 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Should not the storage be based on soft references? In the current solution we will store the references to the checked classes forever in the static map. >> >>> 13 ???. 2016 ?., ? 18:41, Alexandr Scherbatiy ???????(?): >>> >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8169922 >>> webrev: http://cr.openjdk.java.net/~alexsch/8169922/webrev.00 >>> >>> The fix JDK-8156217 checks presence of the overridden methods with floating point arguments. >>> The proposed fix caches results of found overridden methods with floating point arguments. >>> >>> I run the SwingSet2 with the custom test which intensively creates JTextField, JPasswordField, JTextArea, and JEditorPane. >>> >>> The results of the test running with the following JDK are: >>> 1. Methods with int arguments are always called without the methods overridden check: 45822 // before the fix JDK-8156217 >>> 2. Methods with floating point arguments are always called without the methods overridden check: 46175 >>> performance decreasing: 100 * (46175 - 45822) / 45822 = 0.77% >>> 3. Methods with floating point arguments are always called with the methods overridden check: 48836 // fix JDK-8156217 >>> performance decreasing: 100 * (48836 - 45822) / 45822 = 6.58% >>> 4. Methods with floating point arguments are always called and the methods overridden checks are cached: 46592 // current fix >>> performance decreasing: 100 * (46592 - 45822) / 45822 = 1.68% >>> >>> Thanks, >>> Alexandr. >>> > From sergey.bylokhov at oracle.com Tue Dec 20 16:24:31 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 20 Dec 2016 19:24:31 +0300 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: References:

<586534fe-0ac6-42a4-27c7-f9e9ba8352ed@oracle.com> <3661820D-965A-4B4B-8BFB-45D7F7C1C0BC@oracle.com> <4ab60466-8b8a-f2ff-cb99-f6c4cebd017e@oracle.com>

Message-ID: <5FA74751-DECC-4A73-8778-62F61F37F1F6@oracle.com> >>> If this private data can be loaded to the UIDefaults or to other class then it will be read anyway. Are the Swing/AWT properties files content really secret? >> My point is that there are no secrets, but the bug description states that such bundles can be added some day later. > But what secret can be here? I think Mandy can clarify that. >>>>> Why specification of the addResourceBundle() doesn't reflect this limitation? It is obvious that the fix bears impact in compatibility. >>>> The current spec will allow us to revert back the fix, if the impact on the applications will be hight, but for now it is not expected. >>> This is not a correct approach. If you are really sure that the method should have this restriction to not allow to load any internal resources externally, please present it in the spec. Potential compatibility issues you can address by introducing a new system property. >> There are no compatibility issues which contradicts the specification, because all our resource bundles are private(unspecified), they are located in the com.XXX packages and all of them can be changed/removed in any time. > The fix blocks resources form all desktop module packages not only from "com.XXX", doesn't it? It blocks all, because all of bundles which are used in UIDefault are private. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Dec 20 16:41:56 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 20 Dec 2016 08:41:56 -0800 Subject: [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation In-Reply-To: <5FA74751-DECC-4A73-8778-62F61F37F1F6@oracle.com> References:

<586534fe-0ac6-42a4-27c7-f9e9ba8352ed@oracle.com> <3661820D-965A-4B4B-8BFB-45D7F7C1C0BC@oracle.com> <4ab60466-8b8a-f2ff-cb99-f6c4cebd017e@oracle.com>

<5FA74751-DECC-4A73-8778-62F61F37F1F6@oracle.com> Message-ID: <4FE75E35-86BA-4255-87FB-DB0856DE4F0B@oracle.com> > On Dec 20, 2016, at 8:24 AM, Sergey Bylokhov wrote: > >>>> If this private data can be loaded to the UIDefaults or to other class then it will be read anyway. Are the Swing/AWT properties files content really secret? >>> My point is that there are no secrets, but the bug description states that such bundles can be added some day later. >> But what secret can be here? > > I think Mandy can clarify that. The API should only allow user code to request adding a resource bundle that is accessible to the user. A private resource bundle in java.desktop that may contain security sensitive information is not intended to be registered in UIDefaults and of course it should be encapsulated. You may think that today there is no security sensitive information but we can?t guarantee until an audit to all resource bundles is done and also continuously for every change is made. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Dec 20 20:52:47 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 20 Dec 2016 23:52:47 +0300 Subject: [9] Review request for 8169922 SwingMark/TextArea: 2-7% regression on Linux, Mac, Windows in 9-b143 In-Reply-To: <5e61c9a3-becc-9db7-4ec6-95dfba12ff1a@oracle.com> References:

<5e61c9a3-becc-9db7-4ec6-95dfba12ff1a@oracle.com> Message-ID: <0c4c9c82-094f-1b0e-82d0-cd2ab7e3a8f1@oracle.com> On 12/16/2016 2:36 AM, Phil Race wrote: > I just noticed that you spell the new methods with a single d :eg : > getFPMethodOverriden > > Like the variables that were there before it should be > getFPMethodOverridden > and checkFPMethodOverridden Here is the updated fix where the typo is updated: http://cr.openjdk.java.net/~alexsch/8169922/webrev.02 > > Also, although rather unlikely to be a problem in practice, since there > is nothing in the swing rules to prevent constructing a Swing component on > a random thread, before adding it to the hierarchy, and the shared Map > is populated > at construction time, it seems like we need a ConcurrentHashMap .. It seems that it could be possible that a constructor can schedule to run some actions calling SwingUtilities.invokeLater(). In this case both threads (the thread where a Swing component is constructor and EDT) can simultaneously start the object fields updating. There is still no guarantee that all works as expected if a Swing component is constructed in non-EDT. Thanks, Alexandr. > > -phil. > > On 12/15/2016 09:06 AM, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8169922/webrev.01 >> >> - the HashMap is stored in SoftRefence >> - the typo in getMethodArguments() is fixed >> - classes FPMethodItem and FPMethodArgs are defined in the PlainView >> class. >> >> Thanks, >> Alexandr. >> >> On 12/14/2016 8:30 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> Should not the storage be based on soft references? In the current >>> solution we will store the references to the checked classes forever >>> in the static map. >>> >>>> 13 ???. 2016 ?., ? 18:41, Alexandr Scherbatiy >>>> ???????(?): >>>> >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8169922 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8169922/webrev.00 >>>> >>>> The fix JDK-8156217 checks presence of the overridden methods >>>> with floating point arguments. >>>> The proposed fix caches results of found overridden methods with >>>> floating point arguments. >>>> >>>> I run the SwingSet2 with the custom test which intensively >>>> creates JTextField, JPasswordField, JTextArea, and JEditorPane. >>>> >>>> The results of the test running with the following JDK are: >>>> 1. Methods with int arguments are always called without the >>>> methods overridden check: 45822 // before the fix JDK-8156217 >>>> 2. Methods with floating point arguments are always called >>>> without the methods overridden check: 46175 >>>> performance decreasing: 100 * (46175 - 45822) / 45822 = 0.77% >>>> 3. Methods with floating point arguments are always called with >>>> the methods overridden check: 48836 // fix JDK-8156217 >>>> performance decreasing: 100 * (48836 - 45822) / 45822 = 6.58% >>>> 4. Methods with floating point arguments are always called and >>>> the methods overridden checks are cached: 46592 // current fix >>>> performance decreasing: 100 * (46592 - 45822) / 45822 = 1.68% >>>> >>>> Thanks, >>>> Alexandr. >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Dec 20 21:01:22 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 20 Dec 2016 13:01:22 -0800 Subject: [9] Review request for 8169922 SwingMark/TextArea: 2-7% regression on Linux, Mac, Windows in 9-b143 In-Reply-To: <0c4c9c82-094f-1b0e-82d0-cd2ab7e3a8f1@oracle.com> References:

<5e61c9a3-becc-9db7-4ec6-95dfba12ff1a@oracle.com> <0c4c9c82-094f-1b0e-82d0-cd2ab7e3a8f1@oracle.com> Message-ID: <756b453d-baf4-e420-b9a4-bcce115adf32@oracle.com> I notice that there is a variable that was already there (not one you added this time) also mis-spelled : isFPMethodOverriden I'd prefer that be fixed in this push but I don't need to see an updated webrev for that. Comments about threading noted. +1 -phil. On 12/20/2016 12:52 PM, Alexandr Scherbatiy wrote: > On 12/16/2016 2:36 AM, Phil Race wrote: >> I just noticed that you spell the new methods with a single d :eg : >> getFPMethodOverriden >> >> Like the variables that were there before it should be >> getFPMethodOverridden >> and checkFPMethodOverridden > Here is the updated fix where the typo is updated: > http://cr.openjdk.java.net/~alexsch/8169922/webrev.02 > >> >> Also, although rather unlikely to be a problem in practice, since there >> is nothing in the swing rules to prevent constructing a Swing >> component on >> a random thread, before adding it to the hierarchy, and the shared >> Map is populated >> at construction time, it seems like we need a ConcurrentHashMap .. > It seems that it could be possible that a constructor can schedule > to run some actions calling SwingUtilities.invokeLater(). > In this case both threads (the thread where a Swing component is > constructor and EDT) can simultaneously start the object fields updating. > There is still no guarantee that all works as expected if a Swing > component is constructed in non-EDT. > > Thanks, > Alexandr. > >> >> -phil. >> >> On 12/15/2016 09:06 AM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8169922/webrev.01 >>> >>> - the HashMap is stored in SoftRefence >>> - the typo in getMethodArguments() is fixed >>> - classes FPMethodItem and FPMethodArgs are defined in the PlainView >>> class. >>> >>> Thanks, >>> Alexandr. >>> >>> On 12/14/2016 8:30 PM, Sergey Bylokhov wrote: >>>> Hi, Alexander. >>>> Should not the storage be based on soft references? In the current >>>> solution we will store the references to the checked classes >>>> forever in the static map. >>>> >>>>> 13 ???. 2016 ?., ? 18:41, Alexandr Scherbatiy >>>>> ???????(?): >>>>> >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8169922 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8169922/webrev.00 >>>>> >>>>> The fix JDK-8156217 checks presence of the overridden methods >>>>> with floating point arguments. >>>>> The proposed fix caches results of found overridden methods with >>>>> floating point arguments. >>>>> >>>>> I run the SwingSet2 with the custom test which intensively >>>>> creates JTextField, JPasswordField, JTextArea, and JEditorPane. >>>>> >>>>> The results of the test running with the following JDK are: >>>>> 1. Methods with int arguments are always called without the >>>>> methods overridden check: 45822 // before the fix JDK-8156217 >>>>> 2. Methods with floating point arguments are always called >>>>> without the methods overridden check: 46175 >>>>> performance decreasing: 100 * (46175 - 45822) / 45822 = 0.77% >>>>> 3. Methods with floating point arguments are always called with >>>>> the methods overridden check: 48836 // fix JDK-8156217 >>>>> performance decreasing: 100 * (48836 - 45822) / 45822 = 6.58% >>>>> 4. Methods with floating point arguments are always called and >>>>> the methods overridden checks are cached: 46592 // current fix >>>>> performance decreasing: 100 * (46592 - 45822) / 45822 = 1.68% >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Dec 21 14:06:30 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 21 Dec 2016 17:06:30 +0300 Subject: