From semyon.sadetsky at oracle.com Wed Jul 1 07:29:13 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 01 Jul 2015 10:29:13 +0300 Subject: debugging a regression In-Reply-To: <5590F006.3030601@oracle.com> References: <558DC085.5020606@oracle.com> <55900FAE.3020604@oracle.com> <559057FD.9000806@oracle.com> <5590987A.3010809@oracle.com> <5590C9CB.9040204@oracle.com> <5590F006.3030601@oracle.com> Message-ID: <559396C9.1090601@oracle.com> Hi Pete, I heard that you got performance issue in b68 connected to text components. It can be caused by https://bugs.openjdk.java.net/browse/JDK-8098835. The next patch can help: --- old/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java 2015-06-16 20:20:42.678311800 +0300 +++ new/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java 2015-06-16 20:20:42.136257600 +0300 @@ -971,7 +971,7 @@ ((AbstractDocument)doc).readLock(); } try { - d.width = (int) rootView.getMinimumSpan(View.X_AXIS) + i.left + i.right; + d.width = (int) rootView.getMinimumSpan(View.X_AXIS) + i.left + i.right + caretMargin; d.height = (int) rootView.getMinimumSpan(View.Y_AXIS) + i.top + i.bottom; } finally { if (doc instanceof AbstractDocument) { @@ -996,7 +996,7 @@ } try { d.width = (int) Math.min((long) rootView.getMaximumSpan(View.X_AXIS) + - (long) i.left + (long) i.right, Integer.MAX_VALUE); + (long) i.left + (long) i.right + caretMargin, Integer.MAX_VALUE); d.height = (int) Math.min((long) rootView.getMaximumSpan(View.Y_AXIS) + (long) i.top + (long) i.bottom, Integer.MAX_VALUE); } finally { @@ -1027,7 +1027,7 @@ Insets insets = editor.getInsets(); alloc.x += insets.left; alloc.y += insets.top; - alloc.width -= insets.left + insets.right; + alloc.width -= insets.left + insets.right + caretMargin; alloc.height -= insets.top + insets.bottom; return alloc; } --Semyon On 6/29/2015 10:13 AM, Vadim Pakhnushev wrote: > I think './common/bin/hgforest bisect ...' should do the trick then. > > On 29.06.2015 7:30, Phil Race wrote: >> >> Just be aware that you will need to apply the same to each repo in >> the JDK forest. >> Else it will very likely not build. Eg the jdk repo must be in sync >> with the top-level repo. >> >> -phil. >> >> On 6/28/15 5:59 PM, Pete Brunet wrote: >>> Thanks Vadim, I'll give it a try. -Pete >>> >>> On 6/28/15 3:24 PM, Vadim Pakhnushev wrote: >>>> Pete, >>>> >>>> Actually you should use hg bisect command to do this. >>>> First, you mark 2 revisions you now as bad and good, like this: >>>> hg bisect --good jdk9-b67 >>>> hg bisect --bad tip >>>> The last command will bisect the list of changesets and update the >>>> repo to some changeset in between. >>>> Then you build the repo, test it and mark it as either bad or good: >>>> hg bisect --bad >>>> This will advance the current changeset and you test it again until >>>> you arrive at the 'first bad' changeset. >>>> See here for reference: https://www.selenic.com/hg/help/bisect >>>> >>>> Hope this helps, >>>> Vadim >>>> >>>> On 28.06.2015 18:15, Pete Brunet wrote: >>>>> Looks like I can use hg update to accomplish this, i.e. hg update >>>>> to the >>>>> rev that is b67 and then hg update to each possibly offending rev >>>>> of the >>>>> jdk repo. Sound right? >>>>> >>>>> On 6/26/15 4:13 PM, Pete Brunet wrote: >>>>>> Hi, I found a problem on b68 and there are a half dozen possible >>>>>> changesets that could be responsible. What is the best way to do >>>>>> the >>>>>> process of elimination. It seems like the right approach would >>>>>> be to >>>>>> start with b67 and then add changesets one at a time until the >>>>>> problem >>>>>> surfaces. Is that right or is there a better way? >>>>>> >>>>>> Starting with a fresh current clone what are the steps to strip >>>>>> back to >>>>>> b67 and then to add changesets? >>>>>> >>>>>> This will be in the jdk branch of the forest. >>>>>> >>>>>> Thanks, Pete >> > From mikhail.cherkasov at oracle.com Wed Jul 1 11:27:24 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Wed, 01 Jul 2015 14:27:24 +0300 Subject: [9] Review request for 8081787: [macosx] MalformedURLException is thrown during reading data for application/x-java-url; class=java.net.URL flavor Message-ID: <5593CE9C.20108@oracle.com> Hi there, Could you please review a fix for: 8081787 [macosx] MalformedURLException is thrown during reading data for application/x-java-url;class=java.net.URL flavor https://bugs.openjdk.java.net/browse/JDK-8081787 http://cr.openjdk.java.net/~mcherkas/8081787.8/webrev.01/src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java.udiff.html Mac Os X pasteboard returns a property list that consists of one URL, but our code supposes to get pure URL. I added extracting URL before passing text to URL ctor. I'm not sure how to implement a test for the fix, to test it properly we need a particular content in pasteboard, I don't know how to get this without manual coping it. Thanks, Mikhail. From anton.nashatyrev at oracle.com Wed Jul 1 13:07:05 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Wed, 01 Jul 2015 16:07:05 +0300 Subject: [9, 8] Review request for 8081485: EDT auto shutdown is broken in case of new event queue usage Message-ID: <5593E5F9.205@oracle.com> Hello Artem, Sergey thanks for your help with the issue investigation! could you please review the following fix: fix: http://cr.openjdk.java.net/~anashaty/8081485/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8081485 Problem: EventQueue.push() at the very beginning prevents the app from shutting down automatically Reason: the EventQueue.push() first checks if the EDT for the top EventQeue exists (to transfer it to the new EventQueue) and then implicitly starts it. Fix: do posting of dummy event only in case if the EventQueue had the EDT Thanks! Anton. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.brunet at oracle.com Wed Jul 1 13:25:18 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 01 Jul 2015 08:25:18 -0500 Subject: debugging a regression In-Reply-To: <559396C9.1090601@oracle.com> References: <558DC085.5020606@oracle.com> <55900FAE.3020604@oracle.com> <559057FD.9000806@oracle.com> <5590987A.3010809@oracle.com> <5590C9CB.9040204@oracle.com> <5590F006.3030601@oracle.com> <559396C9.1090601@oracle.com> Message-ID: <5593EA3E.5090800@oracle.com> Thanks Semyon! I'll give it a try. -Pete On 7/1/15 2:29 AM, Semyon Sadetsky wrote: > Hi Pete, > > I heard that you got performance issue in b68 connected to text > components. > It can be caused by https://bugs.openjdk.java.net/browse/JDK-8098835. > > The next patch can help: > > --- > old/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java > 2015-06-16 20:20:42.678311800 +0300 > +++ > new/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java > 2015-06-16 20:20:42.136257600 +0300 > @@ -971,7 +971,7 @@ > ((AbstractDocument)doc).readLock(); > } > try { > - d.width = (int) rootView.getMinimumSpan(View.X_AXIS) + > i.left + i.right; > + d.width = (int) rootView.getMinimumSpan(View.X_AXIS) + > i.left + i.right + caretMargin; > d.height = (int) rootView.getMinimumSpan(View.Y_AXIS) + > i.top + i.bottom; > } finally { > if (doc instanceof AbstractDocument) { > @@ -996,7 +996,7 @@ > } > try { > d.width = (int) Math.min((long) > rootView.getMaximumSpan(View.X_AXIS) + > - (long) i.left + (long) i.right, > Integer.MAX_VALUE); > + (long) i.left + (long) i.right + > caretMargin, Integer.MAX_VALUE); > d.height = (int) Math.min((long) > rootView.getMaximumSpan(View.Y_AXIS) + > (long) i.top + (long) i.bottom, > Integer.MAX_VALUE); > } finally { > @@ -1027,7 +1027,7 @@ > Insets insets = editor.getInsets(); > alloc.x += insets.left; > alloc.y += insets.top; > - alloc.width -= insets.left + insets.right; > + alloc.width -= insets.left + insets.right + caretMargin; > alloc.height -= insets.top + insets.bottom; > return alloc; > } > > --Semyon > > > On 6/29/2015 10:13 AM, Vadim Pakhnushev wrote: >> I think './common/bin/hgforest bisect ...' should do the trick then. >> >> On 29.06.2015 7:30, Phil Race wrote: >>> >>> Just be aware that you will need to apply the same to each repo in >>> the JDK forest. >>> Else it will very likely not build. Eg the jdk repo must be in sync >>> with the top-level repo. >>> >>> -phil. >>> >>> On 6/28/15 5:59 PM, Pete Brunet wrote: >>>> Thanks Vadim, I'll give it a try. -Pete >>>> >>>> On 6/28/15 3:24 PM, Vadim Pakhnushev wrote: >>>>> Pete, >>>>> >>>>> Actually you should use hg bisect command to do this. >>>>> First, you mark 2 revisions you now as bad and good, like this: >>>>> hg bisect --good jdk9-b67 >>>>> hg bisect --bad tip >>>>> The last command will bisect the list of changesets and update the >>>>> repo to some changeset in between. >>>>> Then you build the repo, test it and mark it as either bad or good: >>>>> hg bisect --bad >>>>> This will advance the current changeset and you test it again until >>>>> you arrive at the 'first bad' changeset. >>>>> See here for reference: https://www.selenic.com/hg/help/bisect >>>>> >>>>> Hope this helps, >>>>> Vadim >>>>> >>>>> On 28.06.2015 18:15, Pete Brunet wrote: >>>>>> Looks like I can use hg update to accomplish this, i.e. hg update >>>>>> to the >>>>>> rev that is b67 and then hg update to each possibly offending rev >>>>>> of the >>>>>> jdk repo. Sound right? >>>>>> >>>>>> On 6/26/15 4:13 PM, Pete Brunet wrote: >>>>>>> Hi, I found a problem on b68 and there are a half dozen possible >>>>>>> changesets that could be responsible. What is the best way to >>>>>>> do the >>>>>>> process of elimination. It seems like the right approach would >>>>>>> be to >>>>>>> start with b67 and then add changesets one at a time until the >>>>>>> problem >>>>>>> surfaces. Is that right or is there a better way? >>>>>>> >>>>>>> Starting with a fresh current clone what are the steps to strip >>>>>>> back to >>>>>>> b67 and then to add changesets? >>>>>>> >>>>>>> This will be in the jdk branch of the forest. >>>>>>> >>>>>>> Thanks, Pete >>> >> > From peter.brunet at oracle.com Wed Jul 1 14:17:15 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 01 Jul 2015 09:17:15 -0500 Subject: debugging a regression In-Reply-To: <5593EA3E.5090800@oracle.com> References: <558DC085.5020606@oracle.com> <55900FAE.3020604@oracle.com> <559057FD.9000806@oracle.com> <5590987A.3010809@oracle.com> <5590C9CB.9040204@oracle.com> <5590F006.3030601@oracle.com> <559396C9.1090601@oracle.com> <5593EA3E.5090800@oracle.com> Message-ID: <5593F66B.4080005@oracle.com> That fixed it. Thanks Semyon. On 7/1/15 8:25 AM, Pete Brunet wrote: > Thanks Semyon! I'll give it a try. -Pete > > On 7/1/15 2:29 AM, Semyon Sadetsky wrote: >> Hi Pete, >> >> I heard that you got performance issue in b68 connected to text >> components. >> It can be caused by https://bugs.openjdk.java.net/browse/JDK-8098835. >> >> The next patch can help: >> >> --- >> old/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java >> 2015-06-16 20:20:42.678311800 +0300 >> +++ >> new/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java >> 2015-06-16 20:20:42.136257600 +0300 >> @@ -971,7 +971,7 @@ >> ((AbstractDocument)doc).readLock(); >> } >> try { >> - d.width = (int) rootView.getMinimumSpan(View.X_AXIS) + >> i.left + i.right; >> + d.width = (int) rootView.getMinimumSpan(View.X_AXIS) + >> i.left + i.right + caretMargin; >> d.height = (int) rootView.getMinimumSpan(View.Y_AXIS) + >> i.top + i.bottom; >> } finally { >> if (doc instanceof AbstractDocument) { >> @@ -996,7 +996,7 @@ >> } >> try { >> d.width = (int) Math.min((long) >> rootView.getMaximumSpan(View.X_AXIS) + >> - (long) i.left + (long) i.right, >> Integer.MAX_VALUE); >> + (long) i.left + (long) i.right + >> caretMargin, Integer.MAX_VALUE); >> d.height = (int) Math.min((long) >> rootView.getMaximumSpan(View.Y_AXIS) + >> (long) i.top + (long) i.bottom, >> Integer.MAX_VALUE); >> } finally { >> @@ -1027,7 +1027,7 @@ >> Insets insets = editor.getInsets(); >> alloc.x += insets.left; >> alloc.y += insets.top; >> - alloc.width -= insets.left + insets.right; >> + alloc.width -= insets.left + insets.right + caretMargin; >> alloc.height -= insets.top + insets.bottom; >> return alloc; >> } >> >> --Semyon >> >> >> On 6/29/2015 10:13 AM, Vadim Pakhnushev wrote: >>> I think './common/bin/hgforest bisect ...' should do the trick then. >>> >>> On 29.06.2015 7:30, Phil Race wrote: >>>> Just be aware that you will need to apply the same to each repo in >>>> the JDK forest. >>>> Else it will very likely not build. Eg the jdk repo must be in sync >>>> with the top-level repo. >>>> >>>> -phil. >>>> >>>> On 6/28/15 5:59 PM, Pete Brunet wrote: >>>>> Thanks Vadim, I'll give it a try. -Pete >>>>> >>>>> On 6/28/15 3:24 PM, Vadim Pakhnushev wrote: >>>>>> Pete, >>>>>> >>>>>> Actually you should use hg bisect command to do this. >>>>>> First, you mark 2 revisions you now as bad and good, like this: >>>>>> hg bisect --good jdk9-b67 >>>>>> hg bisect --bad tip >>>>>> The last command will bisect the list of changesets and update the >>>>>> repo to some changeset in between. >>>>>> Then you build the repo, test it and mark it as either bad or good: >>>>>> hg bisect --bad >>>>>> This will advance the current changeset and you test it again until >>>>>> you arrive at the 'first bad' changeset. >>>>>> See here for reference: https://www.selenic.com/hg/help/bisect >>>>>> >>>>>> Hope this helps, >>>>>> Vadim >>>>>> >>>>>> On 28.06.2015 18:15, Pete Brunet wrote: >>>>>>> Looks like I can use hg update to accomplish this, i.e. hg update >>>>>>> to the >>>>>>> rev that is b67 and then hg update to each possibly offending rev >>>>>>> of the >>>>>>> jdk repo. Sound right? >>>>>>> >>>>>>> On 6/26/15 4:13 PM, Pete Brunet wrote: >>>>>>>> Hi, I found a problem on b68 and there are a half dozen possible >>>>>>>> changesets that could be responsible. What is the best way to >>>>>>>> do the >>>>>>>> process of elimination. It seems like the right approach would >>>>>>>> be to >>>>>>>> start with b67 and then add changesets one at a time until the >>>>>>>> problem >>>>>>>> surfaces. Is that right or is there a better way? >>>>>>>> >>>>>>>> Starting with a fresh current clone what are the steps to strip >>>>>>>> back to >>>>>>>> b67 and then to add changesets? >>>>>>>> >>>>>>>> This will be in the jdk branch of the forest. >>>>>>>> >>>>>>>> Thanks, Pete From philip.race at oracle.com Wed Jul 1 15:27:21 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 01 Jul 2015 08:27:21 -0700 Subject: debugging a regression In-Reply-To: <5593F66B.4080005@oracle.com> References: <558DC085.5020606@oracle.com> <55900FAE.3020604@oracle.com> <559057FD.9000806@oracle.com> <5590987A.3010809@oracle.com> <5590C9CB.9040204@oracle.com> <5590F006.3030601@oracle.com> <559396C9.1090601@oracle.com> <5593EA3E.5090800@oracle.com> <5593F66B.4080005@oracle.com> Message-ID: <559406D9.7070103@oracle.com> BTW I meant to send email on this but yesterday whilst doing manual testing of the final PIT builds on 64 bit Linux I still saw one CPU core max out on the HTMLEditor test in SwingSet2. I think it was GTK L&F but I do not remember for sure .. I suspect it is actually all of them. I did not see the same on OS X (for example). Yuri ?? -phil. On 7/1/15 7:17 AM, Pete Brunet wrote: > That fixed it. Thanks Semyon. > > On 7/1/15 8:25 AM, Pete Brunet wrote: >> Thanks Semyon! I'll give it a try. -Pete >> >> On 7/1/15 2:29 AM, Semyon Sadetsky wrote: >>> Hi Pete, >>> >>> I heard that you got performance issue in b68 connected to text >>> components. >>> It can be caused by https://bugs.openjdk.java.net/browse/JDK-8098835. >>> >>> The next patch can help: >>> >>> --- >>> old/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java >>> 2015-06-16 20:20:42.678311800 +0300 >>> +++ >>> new/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java >>> 2015-06-16 20:20:42.136257600 +0300 >>> @@ -971,7 +971,7 @@ >>> ((AbstractDocument)doc).readLock(); >>> } >>> try { >>> - d.width = (int) rootView.getMinimumSpan(View.X_AXIS) + >>> i.left + i.right; >>> + d.width = (int) rootView.getMinimumSpan(View.X_AXIS) + >>> i.left + i.right + caretMargin; >>> d.height = (int) rootView.getMinimumSpan(View.Y_AXIS) + >>> i.top + i.bottom; >>> } finally { >>> if (doc instanceof AbstractDocument) { >>> @@ -996,7 +996,7 @@ >>> } >>> try { >>> d.width = (int) Math.min((long) >>> rootView.getMaximumSpan(View.X_AXIS) + >>> - (long) i.left + (long) i.right, >>> Integer.MAX_VALUE); >>> + (long) i.left + (long) i.right + >>> caretMargin, Integer.MAX_VALUE); >>> d.height = (int) Math.min((long) >>> rootView.getMaximumSpan(View.Y_AXIS) + >>> (long) i.top + (long) i.bottom, >>> Integer.MAX_VALUE); >>> } finally { >>> @@ -1027,7 +1027,7 @@ >>> Insets insets = editor.getInsets(); >>> alloc.x += insets.left; >>> alloc.y += insets.top; >>> - alloc.width -= insets.left + insets.right; >>> + alloc.width -= insets.left + insets.right + caretMargin; >>> alloc.height -= insets.top + insets.bottom; >>> return alloc; >>> } >>> >>> --Semyon >>> >>> >>> On 6/29/2015 10:13 AM, Vadim Pakhnushev wrote: >>>> I think './common/bin/hgforest bisect ...' should do the trick then. >>>> >>>> On 29.06.2015 7:30, Phil Race wrote: >>>>> Just be aware that you will need to apply the same to each repo in >>>>> the JDK forest. >>>>> Else it will very likely not build. Eg the jdk repo must be in sync >>>>> with the top-level repo. >>>>> >>>>> -phil. >>>>> >>>>> On 6/28/15 5:59 PM, Pete Brunet wrote: >>>>>> Thanks Vadim, I'll give it a try. -Pete >>>>>> >>>>>> On 6/28/15 3:24 PM, Vadim Pakhnushev wrote: >>>>>>> Pete, >>>>>>> >>>>>>> Actually you should use hg bisect command to do this. >>>>>>> First, you mark 2 revisions you now as bad and good, like this: >>>>>>> hg bisect --good jdk9-b67 >>>>>>> hg bisect --bad tip >>>>>>> The last command will bisect the list of changesets and update the >>>>>>> repo to some changeset in between. >>>>>>> Then you build the repo, test it and mark it as either bad or good: >>>>>>> hg bisect --bad >>>>>>> This will advance the current changeset and you test it again until >>>>>>> you arrive at the 'first bad' changeset. >>>>>>> See here for reference: https://www.selenic.com/hg/help/bisect >>>>>>> >>>>>>> Hope this helps, >>>>>>> Vadim >>>>>>> >>>>>>> On 28.06.2015 18:15, Pete Brunet wrote: >>>>>>>> Looks like I can use hg update to accomplish this, i.e. hg update >>>>>>>> to the >>>>>>>> rev that is b67 and then hg update to each possibly offending rev >>>>>>>> of the >>>>>>>> jdk repo. Sound right? >>>>>>>> >>>>>>>> On 6/26/15 4:13 PM, Pete Brunet wrote: >>>>>>>>> Hi, I found a problem on b68 and there are a half dozen possible >>>>>>>>> changesets that could be responsible. What is the best way to >>>>>>>>> do the >>>>>>>>> process of elimination. It seems like the right approach would >>>>>>>>> be to >>>>>>>>> start with b67 and then add changesets one at a time until the >>>>>>>>> problem >>>>>>>>> surfaces. Is that right or is there a better way? >>>>>>>>> >>>>>>>>> Starting with a fresh current clone what are the steps to strip >>>>>>>>> back to >>>>>>>>> b67 and then to add changesets? >>>>>>>>> >>>>>>>>> This will be in the jdk branch of the forest. >>>>>>>>> >>>>>>>>> Thanks, Pete From yuri.nesterenko at oracle.com Wed Jul 1 15:53:02 2015 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 01 Jul 2015 18:53:02 +0300 Subject: debugging a regression In-Reply-To: <559406D9.7070103@oracle.com> References: <558DC085.5020606@oracle.com> <55900FAE.3020604@oracle.com> <559057FD.9000806@oracle.com> <5590987A.3010809@oracle.com> <5590C9CB.9040204@oracle.com> <5590F006.3030601@oracle.com> <559396C9.1090601@oracle.com> <5593EA3E.5090800@oracle.com> <5593F66B.4080005@oracle.com> <559406D9.7070103@oracle.com> Message-ID: <55940CDE.2060102@oracle.com> Well, yes, I'm afraid so. On Nimbus, however, I don't see any degradation, and it seems that after switching from Nimbus to Metal or GTK SwingSet2 is more responsive. But the fix is not in this PIT, is it? -yan On 07/01/2015 06:27 PM, Phil Race wrote: > BTW I meant to send email on this but yesterday whilst doing > manual testing of the final PIT builds on 64 bit Linux I still saw one > CPU core > max out on the HTMLEditor test in SwingSet2. > I think it was GTK L&F but I do not remember for sure .. > I suspect it is actually all of them. > > I did not see the same on OS X (for example). > > Yuri ?? > > -phil. > > On 7/1/15 7:17 AM, Pete Brunet wrote: >> That fixed it. Thanks Semyon. >> >> On 7/1/15 8:25 AM, Pete Brunet wrote: >>> Thanks Semyon! I'll give it a try. -Pete >>> >>> On 7/1/15 2:29 AM, Semyon Sadetsky wrote: >>>> Hi Pete, >>>> >>>> I heard that you got performance issue in b68 connected to text >>>> components. >>>> It can be caused by https://bugs.openjdk.java.net/browse/JDK-8098835. >>>> >>>> The next patch can help: >>>> >>>> --- >>>> old/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java >>>> >>>> 2015-06-16 20:20:42.678311800 +0300 >>>> +++ >>>> new/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java >>>> >>>> 2015-06-16 20:20:42.136257600 +0300 >>>> @@ -971,7 +971,7 @@ >>>> ((AbstractDocument)doc).readLock(); >>>> } >>>> try { >>>> - d.width = (int) rootView.getMinimumSpan(View.X_AXIS) + >>>> i.left + i.right; >>>> + d.width = (int) rootView.getMinimumSpan(View.X_AXIS) + >>>> i.left + i.right + caretMargin; >>>> d.height = (int) rootView.getMinimumSpan(View.Y_AXIS) + >>>> i.top + i.bottom; >>>> } finally { >>>> if (doc instanceof AbstractDocument) { >>>> @@ -996,7 +996,7 @@ >>>> } >>>> try { >>>> d.width = (int) Math.min((long) >>>> rootView.getMaximumSpan(View.X_AXIS) + >>>> - (long) i.left + (long) i.right, >>>> Integer.MAX_VALUE); >>>> + (long) i.left + (long) i.right + >>>> caretMargin, Integer.MAX_VALUE); >>>> d.height = (int) Math.min((long) >>>> rootView.getMaximumSpan(View.Y_AXIS) + >>>> (long) i.top + (long) i.bottom, >>>> Integer.MAX_VALUE); >>>> } finally { >>>> @@ -1027,7 +1027,7 @@ >>>> Insets insets = editor.getInsets(); >>>> alloc.x += insets.left; >>>> alloc.y += insets.top; >>>> - alloc.width -= insets.left + insets.right; >>>> + alloc.width -= insets.left + insets.right + caretMargin; >>>> alloc.height -= insets.top + insets.bottom; >>>> return alloc; >>>> } >>>> >>>> --Semyon >>>> >>>> >>>> On 6/29/2015 10:13 AM, Vadim Pakhnushev wrote: >>>>> I think './common/bin/hgforest bisect ...' should do the trick then. >>>>> >>>>> On 29.06.2015 7:30, Phil Race wrote: >>>>>> Just be aware that you will need to apply the same to each repo in >>>>>> the JDK forest. >>>>>> Else it will very likely not build. Eg the jdk repo must be in sync >>>>>> with the top-level repo. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 6/28/15 5:59 PM, Pete Brunet wrote: >>>>>>> Thanks Vadim, I'll give it a try. -Pete >>>>>>> >>>>>>> On 6/28/15 3:24 PM, Vadim Pakhnushev wrote: >>>>>>>> Pete, >>>>>>>> >>>>>>>> Actually you should use hg bisect command to do this. >>>>>>>> First, you mark 2 revisions you now as bad and good, like this: >>>>>>>> hg bisect --good jdk9-b67 >>>>>>>> hg bisect --bad tip >>>>>>>> The last command will bisect the list of changesets and update the >>>>>>>> repo to some changeset in between. >>>>>>>> Then you build the repo, test it and mark it as either bad or good: >>>>>>>> hg bisect --bad >>>>>>>> This will advance the current changeset and you test it again until >>>>>>>> you arrive at the 'first bad' changeset. >>>>>>>> See here for reference: https://www.selenic.com/hg/help/bisect >>>>>>>> >>>>>>>> Hope this helps, >>>>>>>> Vadim >>>>>>>> >>>>>>>> On 28.06.2015 18:15, Pete Brunet wrote: >>>>>>>>> Looks like I can use hg update to accomplish this, i.e. hg update >>>>>>>>> to the >>>>>>>>> rev that is b67 and then hg update to each possibly offending rev >>>>>>>>> of the >>>>>>>>> jdk repo. Sound right? >>>>>>>>> >>>>>>>>> On 6/26/15 4:13 PM, Pete Brunet wrote: >>>>>>>>>> Hi, I found a problem on b68 and there are a half dozen possible >>>>>>>>>> changesets that could be responsible. What is the best way to >>>>>>>>>> do the >>>>>>>>>> process of elimination. It seems like the right approach would >>>>>>>>>> be to >>>>>>>>>> start with b67 and then add changesets one at a time until the >>>>>>>>>> problem >>>>>>>>>> surfaces. Is that right or is there a better way? >>>>>>>>>> >>>>>>>>>> Starting with a fresh current clone what are the steps to strip >>>>>>>>>> back to >>>>>>>>>> b67 and then to add changesets? >>>>>>>>>> >>>>>>>>>> This will be in the jdk branch of the forest. >>>>>>>>>> >>>>>>>>>> Thanks, Pete > From semyon.sadetsky at oracle.com Thu Jul 2 05:38:42 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 02 Jul 2015 08:38:42 +0300 Subject: debugging a regression In-Reply-To: <55940CDE.2060102@oracle.com> References: <558DC085.5020606@oracle.com> <55900FAE.3020604@oracle.com> <559057FD.9000806@oracle.com> <5590987A.3010809@oracle.com> <5590C9CB.9040204@oracle.com> <5590F006.3030601@oracle.com> <559396C9.1090601@oracle.com> <5593EA3E.5090800@oracle.com> <5593F66B.4080005@oracle.com> <559406D9.7070103@oracle.com> <55940CDE.2060102@oracle.com> Message-ID: <5594CE62.8080400@oracle.com> Hi Yuri, If you remember we had a quick discussion about this issue before the PIT. Fix was ready but did not go into the PIT. --Semyon On 7/1/2015 6:53 PM, Yuri Nesterenko wrote: > Well, yes, I'm afraid so. On Nimbus, however, I don't see > any degradation, and it seems that after switching from Nimbus > to Metal or GTK SwingSet2 is more responsive. > But the fix is not in this PIT, is it? > > -yan > > On 07/01/2015 06:27 PM, Phil Race wrote: >> BTW I meant to send email on this but yesterday whilst doing >> manual testing of the final PIT builds on 64 bit Linux I still saw one >> CPU core >> max out on the HTMLEditor test in SwingSet2. >> I think it was GTK L&F but I do not remember for sure .. >> I suspect it is actually all of them. >> >> I did not see the same on OS X (for example). >> >> Yuri ?? >> >> -phil. >> >> On 7/1/15 7:17 AM, Pete Brunet wrote: >>> That fixed it. Thanks Semyon. >>> >>> On 7/1/15 8:25 AM, Pete Brunet wrote: >>>> Thanks Semyon! I'll give it a try. -Pete >>>> >>>> On 7/1/15 2:29 AM, Semyon Sadetsky wrote: >>>>> Hi Pete, >>>>> >>>>> I heard that you got performance issue in b68 connected to text >>>>> components. >>>>> It can be caused by https://bugs.openjdk.java.net/browse/JDK-8098835. >>>>> >>>>> The next patch can help: >>>>> >>>>> --- >>>>> old/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java >>>>> >>>>> >>>>> 2015-06-16 20:20:42.678311800 +0300 >>>>> +++ >>>>> new/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java >>>>> >>>>> >>>>> 2015-06-16 20:20:42.136257600 +0300 >>>>> @@ -971,7 +971,7 @@ >>>>> ((AbstractDocument)doc).readLock(); >>>>> } >>>>> try { >>>>> - d.width = (int) rootView.getMinimumSpan(View.X_AXIS) + >>>>> i.left + i.right; >>>>> + d.width = (int) rootView.getMinimumSpan(View.X_AXIS) + >>>>> i.left + i.right + caretMargin; >>>>> d.height = (int) rootView.getMinimumSpan(View.Y_AXIS) + >>>>> i.top + i.bottom; >>>>> } finally { >>>>> if (doc instanceof AbstractDocument) { >>>>> @@ -996,7 +996,7 @@ >>>>> } >>>>> try { >>>>> d.width = (int) Math.min((long) >>>>> rootView.getMaximumSpan(View.X_AXIS) + >>>>> - (long) i.left + (long) i.right, >>>>> Integer.MAX_VALUE); >>>>> + (long) i.left + (long) >>>>> i.right + >>>>> caretMargin, Integer.MAX_VALUE); >>>>> d.height = (int) Math.min((long) >>>>> rootView.getMaximumSpan(View.Y_AXIS) + >>>>> (long) i.top + (long) >>>>> i.bottom, >>>>> Integer.MAX_VALUE); >>>>> } finally { >>>>> @@ -1027,7 +1027,7 @@ >>>>> Insets insets = editor.getInsets(); >>>>> alloc.x += insets.left; >>>>> alloc.y += insets.top; >>>>> - alloc.width -= insets.left + insets.right; >>>>> + alloc.width -= insets.left + insets.right + caretMargin; >>>>> alloc.height -= insets.top + insets.bottom; >>>>> return alloc; >>>>> } >>>>> >>>>> --Semyon >>>>> >>>>> >>>>> On 6/29/2015 10:13 AM, Vadim Pakhnushev wrote: >>>>>> I think './common/bin/hgforest bisect ...' should do the trick then. >>>>>> >>>>>> On 29.06.2015 7:30, Phil Race wrote: >>>>>>> Just be aware that you will need to apply the same to each repo in >>>>>>> the JDK forest. >>>>>>> Else it will very likely not build. Eg the jdk repo must be in sync >>>>>>> with the top-level repo. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 6/28/15 5:59 PM, Pete Brunet wrote: >>>>>>>> Thanks Vadim, I'll give it a try. -Pete >>>>>>>> >>>>>>>> On 6/28/15 3:24 PM, Vadim Pakhnushev wrote: >>>>>>>>> Pete, >>>>>>>>> >>>>>>>>> Actually you should use hg bisect command to do this. >>>>>>>>> First, you mark 2 revisions you now as bad and good, like this: >>>>>>>>> hg bisect --good jdk9-b67 >>>>>>>>> hg bisect --bad tip >>>>>>>>> The last command will bisect the list of changesets and update >>>>>>>>> the >>>>>>>>> repo to some changeset in between. >>>>>>>>> Then you build the repo, test it and mark it as either bad or >>>>>>>>> good: >>>>>>>>> hg bisect --bad >>>>>>>>> This will advance the current changeset and you test it again >>>>>>>>> until >>>>>>>>> you arrive at the 'first bad' changeset. >>>>>>>>> See here for reference: https://www.selenic.com/hg/help/bisect >>>>>>>>> >>>>>>>>> Hope this helps, >>>>>>>>> Vadim >>>>>>>>> >>>>>>>>> On 28.06.2015 18:15, Pete Brunet wrote: >>>>>>>>>> Looks like I can use hg update to accomplish this, i.e. hg >>>>>>>>>> update >>>>>>>>>> to the >>>>>>>>>> rev that is b67 and then hg update to each possibly offending >>>>>>>>>> rev >>>>>>>>>> of the >>>>>>>>>> jdk repo. Sound right? >>>>>>>>>> >>>>>>>>>> On 6/26/15 4:13 PM, Pete Brunet wrote: >>>>>>>>>>> Hi, I found a problem on b68 and there are a half dozen >>>>>>>>>>> possible >>>>>>>>>>> changesets that could be responsible. What is the best way to >>>>>>>>>>> do the >>>>>>>>>>> process of elimination. It seems like the right approach would >>>>>>>>>>> be to >>>>>>>>>>> start with b67 and then add changesets one at a time until the >>>>>>>>>>> problem >>>>>>>>>>> surfaces. Is that right or is there a better way? >>>>>>>>>>> >>>>>>>>>>> Starting with a fresh current clone what are the steps to strip >>>>>>>>>>> back to >>>>>>>>>>> b67 and then to add changesets? >>>>>>>>>>> >>>>>>>>>>> This will be in the jdk branch of the forest. >>>>>>>>>>> >>>>>>>>>>> Thanks, Pete >> > From pooja.chopra at oracle.com Thu Jul 2 07:28:37 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Thu, 02 Jul 2015 12:58:37 +0530 Subject: [9] Review Request: JDK-8080932 [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java fails with Bad script error due to improper @run notation In-Reply-To: <5581151C.8070908@oracle.com> References: <555F3496.5030900@oracle.com> <555F34EA.3050603@oracle.com> <556EF814.40404@oracle.com> <55706545.9010709@oracle.com> <5581151C.8070908@oracle.com> Message-ID: <5594E825.2080304@oracle.com> Hi All, Please review below fix. Regards, Pooja On 6/17/2015 12:05 PM, pooja chopra wrote: > Hi All, > Gentle reminder .Please review below fix . > Regards, > Pooja > On 6/4/2015 8:18 PM, Alexander Scherbatiy wrote: >> >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 6/3/2015 3:50 PM, pooja chopra wrote: >>> Hi All , >>> Please review below fix. >>> Regards, >>> Pooja >>> On 5/22/2015 7:23 PM, pooja chopra wrote: >>>> Hello, >>>>> Please review a fix for issue: >>>>> 8080932 [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java >>>>> fails with Bad script error due to improper @run notation >>>>> Test bug fix. >>>>> https://bugs.openjdk.java.net/browse/JDK-8080932 >>>>> The webrev is : http://cr.openjdk.java.net/~pchopra/8080932/webrev.00 >>>>> >>>>> Thanks, >>>>> Pooja >>>> >>> >> > From pooja.chopra at oracle.com Thu Jul 2 07:29:28 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Thu, 02 Jul 2015 12:59:28 +0530 Subject: [9] Review Request: JDK-8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to wrongly typed bugid In-Reply-To: <55811563.1050609@oracle.com> References: <555F606B.3040606@oracle.com> <555F618B.7090507@oracle.com> <55811563.1050609@oracle.com> Message-ID: <5594E858.1020502@oracle.com> Hi All, Please review below fix. Regards, Pooja On 6/17/2015 12:06 PM, pooja chopra wrote: > Hi All , > Gentle Reminder. Please review below fix . > Regards, > Pooja > On 5/22/2015 10:34 PM, Sergey Bylokhov wrote: >> cc 2d >> On 22.05.15 19:59, pooja chopra wrote: >>> Hello, >>> Please review a fix for issue: >>> 8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due >>> to wrongly typed bugid >>> Test bug fix. >>> https://bugs.openjdk.java.net/browse/JDK-8080953 >>> The webrev is : http://cr.openjdk.java.net/~pchopra/8080953/webrev.00 >>> >>> Thanks, >>> Pooja >>> >> >> > From yuri.nesterenko at oracle.com Thu Jul 2 10:55:28 2015 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 02 Jul 2015 13:55:28 +0300 Subject: [9] Review Request for 8130125: [TEST_BUG] add @modules to the several client tests unaffected by the automated bulk update Message-ID: <559518A0.1020107@oracle.com> Colleagues, please review this test change: http://cr.openjdk.java.net/~yan/8130125/webrev.00/ In the most of the tests just @modules directive added; other than that, see a short comment in https://bugs.openjdk.java.net/browse/JDK-8130125 Also I'd like to piggyback in the push 3 tests moved from closed part in already approved http://cr.openjdk.java.net/~yan/8081306/ I forgot to do 'hg add', sorry. Thank you! -yan From alexander.zvegintsev at oracle.com Thu Jul 2 11:41:03 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 02 Jul 2015 14:41:03 +0300 Subject: [9] Review Request: JDK-8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to wrongly typed bugid In-Reply-To: <5594E858.1020502@oracle.com> References: <555F606B.3040606@oracle.com> <555F618B.7090507@oracle.com> <55811563.1050609@oracle.com> <5594E858.1020502@oracle.com> Message-ID: <5595234F.7050807@oracle.com> Looks fine to me. Thanks, Alexander. On 07/02/2015 10:29 AM, pooja chopra wrote: > Hi All, > Please review below fix. > Regards, > Pooja > On 6/17/2015 12:06 PM, pooja chopra wrote: >> Hi All , >> Gentle Reminder. Please review below fix . >> Regards, >> Pooja >> On 5/22/2015 10:34 PM, Sergey Bylokhov wrote: >>> cc 2d >>> On 22.05.15 19:59, pooja chopra wrote: >>>> Hello, >>>> Please review a fix for issue: >>>> 8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due >>>> to wrongly typed bugid >>>> Test bug fix. >>>> https://bugs.openjdk.java.net/browse/JDK-8080953 >>>> The webrev is : http://cr.openjdk.java.net/~pchopra/8080953/webrev.00 >>>> >>>> Thanks, >>>> Pooja >>>> >>> >>> >> > From Sergey.Bylokhov at oracle.com Thu Jul 2 11:43:26 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 02 Jul 2015 14:43:26 +0300 Subject: [9] Review Request: JDK-8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to wrongly typed bugid In-Reply-To: <5595234F.7050807@oracle.com> References: <555F606B.3040606@oracle.com> <555F618B.7090507@oracle.com> <55811563.1050609@oracle.com> <5594E858.1020502@oracle.com> <5595234F.7050807@oracle.com> Message-ID: <559523DE.60409@oracle.com> +1 On 02.07.15 14:41, Alexander Zvegintsev wrote: > Looks fine to me. > > Thanks, > > Alexander. > > On 07/02/2015 10:29 AM, pooja chopra wrote: >> Hi All, >> Please review below fix. >> Regards, >> Pooja >> On 6/17/2015 12:06 PM, pooja chopra wrote: >>> Hi All , >>> Gentle Reminder. Please review below fix . >>> Regards, >>> Pooja >>> On 5/22/2015 10:34 PM, Sergey Bylokhov wrote: >>>> cc 2d >>>> On 22.05.15 19:59, pooja chopra wrote: >>>>> Hello, >>>>> Please review a fix for issue: >>>>> 8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails >>>>> due to wrongly typed bugid >>>>> Test bug fix. >>>>> https://bugs.openjdk.java.net/browse/JDK-8080953 >>>>> The webrev is : http://cr.openjdk.java.net/~pchopra/8080953/webrev.00 >>>>> >>>>> Thanks, >>>>> Pooja >>>>> >>>> >>>> >>> >> > -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Thu Jul 2 11:48:48 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 02 Jul 2015 14:48:48 +0300 Subject: [9] Review Request: JDK-8080932 [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java fails with Bad script error due to improper @run notation In-Reply-To: <5594E825.2080304@oracle.com> References: <555F3496.5030900@oracle.com> <555F34EA.3050603@oracle.com> <556EF814.40404@oracle.com> <55706545.9010709@oracle.com> <5581151C.8070908@oracle.com> <5594E825.2080304@oracle.com> Message-ID: <55952520.6060801@oracle.com> Hi, you already have two reviewers, it is sufficient to push. Anyway, the fix looks good to me. Thanks, Alexander. On 07/02/2015 10:28 AM, pooja chopra wrote: > Hi All, > Please review below fix. > Regards, > Pooja > On 6/17/2015 12:05 PM, pooja chopra wrote: >> Hi All, >> Gentle reminder .Please review below fix . >> Regards, >> Pooja >> On 6/4/2015 8:18 PM, Alexander Scherbatiy wrote: >>> >>> The fix looks good to me. >>> >>> Thanks, >>> Alexandr. >>> >>> On 6/3/2015 3:50 PM, pooja chopra wrote: >>>> Hi All , >>>> Please review below fix. >>>> Regards, >>>> Pooja >>>> On 5/22/2015 7:23 PM, pooja chopra wrote: >>>>> Hello, >>>>>> Please review a fix for issue: >>>>>> 8080932 [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java >>>>>> fails with Bad script error due to improper @run notation >>>>>> Test bug fix. >>>>>> https://bugs.openjdk.java.net/browse/JDK-8080932 >>>>>> The webrev is : >>>>>> http://cr.openjdk.java.net/~pchopra/8080932/webrev.00 >>>>>> >>>>>> Thanks, >>>>>> Pooja >>>>> >>>> >>> >> > From Sergey.Bylokhov at oracle.com Thu Jul 2 12:57:49 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 02 Jul 2015 15:57:49 +0300 Subject: [9] Review Request for 8130125: [TEST_BUG] add @modules to the several client tests unaffected by the automated bulk update In-Reply-To: <559518A0.1020107@oracle.com> References: <559518A0.1020107@oracle.com> Message-ID: <5595354D.2030303@oracle.com> Hi, Yuri. - bug6980209.java can use some public logging? - FocusEmbeddedFrameTest/ JButtonInGlassPaneOverlapping/etc why it needs a peer? - JSplitPaneOverlapping please split the long description - bug6608456 why it needs com.sun.java.swing? On 02.07.15 13:55, Yuri Nesterenko wrote: > Colleagues, > > please review this test change: > http://cr.openjdk.java.net/~yan/8130125/webrev.00/ > > In the most of the tests just @modules directive added; > other than that, see a short comment in > https://bugs.openjdk.java.net/browse/JDK-8130125 > > Also I'd like to piggyback in the push 3 tests > moved from closed part in already approved > http://cr.openjdk.java.net/~yan/8081306/ > I forgot to do 'hg add', sorry. > > Thank you! > -yan -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jul 2 13:31:07 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 02 Jul 2015 16:31:07 +0300 Subject: [9] Review Request: JDK-8081361 [TEST_BUG] Test java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest fails In-Reply-To: <559260C8.5080709@oracle.com> References: <55828DC7.3000202@oracle.com> <55912B15.80608@oracle.com> <559260C8.5080709@oracle.com> Message-ID: <55953D1B.4070004@oracle.com> The fix looks good to me. It would be useful to check that the fix that causes the change of the JTextField size made it by purposes and not as side effect. Thanks, Alexander. On 6/30/2015 12:26 PM, pooja chopra wrote: > Hi Alexander, > I fixed the test to match the spec as mentioned > https://docs.oracle.com/javase/8/docs/api/java/awt/GridBagLayout.html > that the width of the component will be at least its minimum width > plus ipadx pixels. Similarly, the height of the component will be at > least the minimum height plus ipady pixels. > > Whereas in the test it is checking for both to be equal and therefore > test will fail for cases where component width or height is greater > than minimum width plus ipadx pixels or minimum height plus ipady > pixels.In the existing test the comparison is done as below :- > > Dimension minSize = jtf.getMinimumSize(); > if ( minSize.width + customIpadx != jtf.getSize().width || > minSize.height + customIpady != jtf.getSize().height ) > > And I changed the comparison to match Spec as below :- > > Dimension minSize = jtf.getMinimumSize(); > if (!(minSize.width + customIpadx <= jtf.getSize().width) || > !(minSize.height + customIpady <= jtf.getSize().height)) > > Regards, > Pooja > On 6/29/2015 4:55 PM, Alexander Scherbatiy wrote: >> >> >> Hello Pooja, >> >> What was the fix that causes the regression? >> >> Thanks, >> Alexandr. >> >> On 6/18/2015 12:22 PM, pooja chopra wrote: >>> Hello, >>> Please review a fix for issue: >>> 8081361 [TEST_BUG] Test >>> java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest >>> fails >>> >>> Test bug fix. >>> https://bugs.openjdk.java.net/browse/JDK-8081361 >>> >>> The webrev is : http://cr.openjdk.java.net/~pchopra/8081361/webrev.00/ >>> >>> Regards, >>> Pooja >> > From yuri.nesterenko at oracle.com Thu Jul 2 13:50:58 2015 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 02 Jul 2015 16:50:58 +0300 Subject: [9] Review Request for 8130125: [TEST_BUG] add @modules to the several client tests unaffected by the automated bulk update In-Reply-To: <5595354D.2030303@oracle.com> References: <559518A0.1020107@oracle.com> <5595354D.2030303@oracle.com> Message-ID: <559541C2.6020305@oracle.com> On 07/02/2015 03:57 PM, Sergey Bylokhov wrote: > Hi, Yuri. > - bug6980209.java can use some public logging? > - FocusEmbeddedFrameTest/ JButtonInGlassPaneOverlapping/etc why it > needs a peer? It's UtilInternal needs it, and that helper should be fixed in Jake by addExports. > - JSplitPaneOverlapping please split the long description > - bug6608456 why it needs com.sun.java.swing? That's for SwingUtilities3 (sic)! I'll be back with logging and description. Thank you! -yan > > On 02.07.15 13:55, Yuri Nesterenko wrote: >> Colleagues, >> >> please review this test change: >> http://cr.openjdk.java.net/~yan/8130125/webrev.00/ >> >> In the most of the tests just @modules directive added; >> other than that, see a short comment in >> https://bugs.openjdk.java.net/browse/JDK-8130125 >> >> Also I'd like to piggyback in the push 3 tests >> moved from closed part in already approved >> http://cr.openjdk.java.net/~yan/8081306/ >> I forgot to do 'hg add', sorry. >> >> Thank you! >> -yan > > > -- > Best regards, Sergey. > From yuri.nesterenko at oracle.com Thu Jul 2 14:35:06 2015 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 02 Jul 2015 17:35:06 +0300 Subject: [9] Review Request for 8130125: [TEST_BUG] add @modules to the several client tests unaffected by the automated bulk update In-Reply-To: <559541C2.6020305@oracle.com> References: <559518A0.1020107@oracle.com> <5595354D.2030303@oracle.com> <559541C2.6020305@oracle.com> Message-ID: <55954C1A.6090503@oracle.com> Hi, could you please take a look at the 2nd version: http://cr.openjdk.java.net/~yan/8130125/webrev.01 Bug is here: https://bugs.openjdk.java.net/browse/JDK-8130125 Thanks, -yan On 07/02/2015 04:50 PM, Yuri Nesterenko wrote: > On 07/02/2015 03:57 PM, Sergey Bylokhov wrote: >> Hi, Yuri. >> - bug6980209.java can use some public logging? >> - FocusEmbeddedFrameTest/ JButtonInGlassPaneOverlapping/etc why it >> needs a peer? > It's UtilInternal needs it, and that helper should be fixed > in Jake by addExports. > >> - JSplitPaneOverlapping please split the long description >> - bug6608456 why it needs com.sun.java.swing? > That's for SwingUtilities3 (sic)! > > I'll be back with logging and description. > > Thank you! > > -yan > >> >> On 02.07.15 13:55, Yuri Nesterenko wrote: >>> Colleagues, >>> >>> please review this test change: >>> http://cr.openjdk.java.net/~yan/8130125/webrev.00/ >>> >>> In the most of the tests just @modules directive added; >>> other than that, see a short comment in >>> https://bugs.openjdk.java.net/browse/JDK-8130125 >>> >>> Also I'd like to piggyback in the push 3 tests >>> moved from closed part in already approved >>> http://cr.openjdk.java.net/~yan/8081306/ >>> I forgot to do 'hg add', sorry. >>> >>> Thank you! >>> -yan >> >> >> -- >> Best regards, Sergey. >> > From Sergey.Bylokhov at oracle.com Thu Jul 2 19:00:51 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 02 Jul 2015 22:00:51 +0300 Subject: [9] Review request for 8081787: [macosx] MalformedURLException is thrown during reading data for application/x-java-url; class=java.net.URL flavor In-Reply-To: <5593CE9C.20108@oracle.com> References: <5593CE9C.20108@oracle.com> Message-ID: <55958A63.10201@oracle.com> Hi, Mikhail. The test will be useful, at least for verification. On my osx for example the test from the bug description fails with UnsupportedFlavorException: application/x-java-url On 01.07.15 14:27, mikhail cherkasov wrote: > Hi there, > > Could you please review a fix for: > 8081787 [macosx] MalformedURLException is thrown during reading data > for application/x-java-url;class=java.net.URL flavor > https://bugs.openjdk.java.net/browse/JDK-8081787 > > http://cr.openjdk.java.net/~mcherkas/8081787.8/webrev.01/src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java.udiff.html > > > Mac Os X pasteboard returns a property list that consists of one URL, > but our code supposes to get pure URL. I added extracting URL before > passing > text to URL ctor. > > I'm not sure how to implement a test for the fix, to test it properly > we need a particular content in pasteboard, I don't know how to get this > without manual coping it. > > Thanks, > Mikhail. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Jul 2 19:52:24 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 02 Jul 2015 22:52:24 +0300 Subject: [9, 8] Review request for 8081485: EDT auto shutdown is broken in case of new event queue usage In-Reply-To: <5593E5F9.205@oracle.com> References: <5593E5F9.205@oracle.com> Message-ID: <55959678.2050405@oracle.com> Hi, Anton. The fix looks fine. On 01.07.15 16:07, Anton Nashatyrev wrote: > Hello Artem, Sergey > > thanks for your help with the issue investigation! > > could you please review the following fix: > > fix: http://cr.openjdk.java.net/~anashaty/8081485/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8081485 > > Problem: EventQueue.push() at the very beginning prevents the app > from shutting down automatically > > Reason: the EventQueue.push() first checks if the EDT for the top > EventQeue exists (to transfer it to the new EventQueue) and then > implicitly starts it. > > Fix: do posting of dummy event only in case if the EventQueue had > the EDT > > Thanks! > Anton. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 3 00:33:11 2015 From: philip.race at oracle.com (Phil Race) Date: Thu, 02 Jul 2015 17:33:11 -0700 Subject: [9] Review Request for 8085948: [Regression] Few Swing, AWT and 2D case fails with Decoder isn't implemented for WingDings Charset error on Windows In-Reply-To: <5579B4FD.6070200@oracle.com> References: <5579B4FD.6070200@oracle.com> Message-ID: <5595D847.6090709@oracle.com> +1 -phil. On 6/11/15 9:19 AM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > bug: https://bugs.openjdk.java.net/browse/JDK-8085948 > webrev: http://cr.openjdk.java.net/~ssadetsky/8085948/webrev.00/ > > It is a regression of JDK-8035302. The charset name is requested from > a dummy stream reader. But it requires creating of the charset decoder > to create the reader but decoder is not implemented for WingDings and > Symbol charsets in Windows. To fix I propose to retarget to writer's > encoding name. > > --Semyon From Sergey.Bylokhov at oracle.com Fri Jul 3 13:45:42 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 03 Jul 2015 16:45:42 +0300 Subject: [9] Review Request for 8130125: [TEST_BUG] add @modules to the several client tests unaffected by the automated bulk update In-Reply-To: <55954C1A.6090503@oracle.com> References: <559518A0.1020107@oracle.com> <5595354D.2030303@oracle.com> <559541C2.6020305@oracle.com> <55954C1A.6090503@oracle.com> Message-ID: <55969206.2010103@oracle.com> Hi, Yuri. The fix looks fine. But I suggest to move bug8075609 to the separate issue to be sure that we do not break the fix for 8075609(at least the test should check what component should has a focus). On 02.07.15 17:35, Yuri Nesterenko wrote: > Hi, > > could you please take a look at the 2nd version: > > http://cr.openjdk.java.net/~yan/8130125/webrev.01 > > Bug is here: > https://bugs.openjdk.java.net/browse/JDK-8130125 > > Thanks, > -yan > > > On 07/02/2015 04:50 PM, Yuri Nesterenko wrote: >> On 07/02/2015 03:57 PM, Sergey Bylokhov wrote: >>> Hi, Yuri. >>> - bug6980209.java can use some public logging? >>> - FocusEmbeddedFrameTest/ JButtonInGlassPaneOverlapping/etc why it >>> needs a peer? >> It's UtilInternal needs it, and that helper should be fixed >> in Jake by addExports. >> >>> - JSplitPaneOverlapping please split the long description >>> - bug6608456 why it needs com.sun.java.swing? >> That's for SwingUtilities3 (sic)! >> >> I'll be back with logging and description. >> >> Thank you! >> >> -yan >> >>> >>> On 02.07.15 13:55, Yuri Nesterenko wrote: >>>> Colleagues, >>>> >>>> please review this test change: >>>> http://cr.openjdk.java.net/~yan/8130125/webrev.00/ >>>> >>>> In the most of the tests just @modules directive added; >>>> other than that, see a short comment in >>>> https://bugs.openjdk.java.net/browse/JDK-8130125 >>>> >>>> Also I'd like to piggyback in the push 3 tests >>>> moved from closed part in already approved >>>> http://cr.openjdk.java.net/~yan/8081306/ >>>> I forgot to do 'hg add', sorry. >>>> >>>> Thank you! >>>> -yan >>> >>> >>> -- >>> Best regards, Sergey. >>> >> > -- Best regards, Sergey. From yuri.nesterenko at oracle.com Fri Jul 3 13:56:53 2015 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 03 Jul 2015 16:56:53 +0300 Subject: [9] Review Request for 8130125: [TEST_BUG] add @modules to the several client tests unaffected by the automated bulk update In-Reply-To: <55969206.2010103@oracle.com> References: <559518A0.1020107@oracle.com> <5595354D.2030303@oracle.com> <559541C2.6020305@oracle.com> <55954C1A.6090503@oracle.com> <55969206.2010103@oracle.com> Message-ID: <559694A5.6030007@oracle.com> OK, thank you Sergey, I'll remove bug8075609 from this changeset. I hope I can push this pure test fix with your single approval? -yan On 07/03/2015 04:45 PM, Sergey Bylokhov wrote: > Hi, Yuri. > The fix looks fine. But I suggest to move bug8075609 to the separate > issue to be sure that we do not break the fix for 8075609(at least the > test should check what component should has a focus). > > On 02.07.15 17:35, Yuri Nesterenko wrote: >> Hi, >> >> could you please take a look at the 2nd version: >> >> http://cr.openjdk.java.net/~yan/8130125/webrev.01 >> >> Bug is here: >> https://bugs.openjdk.java.net/browse/JDK-8130125 >> >> Thanks, >> -yan >> >> >> On 07/02/2015 04:50 PM, Yuri Nesterenko wrote: >>> On 07/02/2015 03:57 PM, Sergey Bylokhov wrote: >>>> Hi, Yuri. >>>> - bug6980209.java can use some public logging? >>>> - FocusEmbeddedFrameTest/ JButtonInGlassPaneOverlapping/etc why it >>>> needs a peer? >>> It's UtilInternal needs it, and that helper should be fixed >>> in Jake by addExports. >>> >>>> - JSplitPaneOverlapping please split the long description >>>> - bug6608456 why it needs com.sun.java.swing? >>> That's for SwingUtilities3 (sic)! >>> >>> I'll be back with logging and description. >>> >>> Thank you! >>> >>> -yan >>> >>>> >>>> On 02.07.15 13:55, Yuri Nesterenko wrote: >>>>> Colleagues, >>>>> >>>>> please review this test change: >>>>> http://cr.openjdk.java.net/~yan/8130125/webrev.00/ >>>>> >>>>> In the most of the tests just @modules directive added; >>>>> other than that, see a short comment in >>>>> https://bugs.openjdk.java.net/browse/JDK-8130125 >>>>> >>>>> Also I'd like to piggyback in the push 3 tests >>>>> moved from closed part in already approved >>>>> http://cr.openjdk.java.net/~yan/8081306/ >>>>> I forgot to do 'hg add', sorry. >>>>> >>>>> Thank you! >>>>> -yan >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >>> >> > > From alexandr.scherbatiy at oracle.com Fri Jul 3 14:14:33 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 03 Jul 2015 17:14:33 +0300 Subject: [9] Review Request for 8130125: [TEST_BUG] add @modules to the several client tests unaffected by the automated bulk update In-Reply-To: <559694A5.6030007@oracle.com> References: <559518A0.1020107@oracle.com> <5595354D.2030303@oracle.com> <559541C2.6020305@oracle.com> <55954C1A.6090503@oracle.com> <55969206.2010103@oracle.com> <559694A5.6030007@oracle.com> Message-ID: <559698C9.7070804@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/3/2015 4:56 PM, Yuri Nesterenko wrote: > OK, thank you Sergey, > > I'll remove bug8075609 from this changeset. > I hope I can push this pure test fix with your single approval? > > -yan > > On 07/03/2015 04:45 PM, Sergey Bylokhov wrote: >> Hi, Yuri. >> The fix looks fine. But I suggest to move bug8075609 to the separate >> issue to be sure that we do not break the fix for 8075609(at least the >> test should check what component should has a focus). >> >> On 02.07.15 17:35, Yuri Nesterenko wrote: >>> Hi, >>> >>> could you please take a look at the 2nd version: >>> >>> http://cr.openjdk.java.net/~yan/8130125/webrev.01 >>> >>> Bug is here: >>> https://bugs.openjdk.java.net/browse/JDK-8130125 >>> >>> Thanks, >>> -yan >>> >>> >>> On 07/02/2015 04:50 PM, Yuri Nesterenko wrote: >>>> On 07/02/2015 03:57 PM, Sergey Bylokhov wrote: >>>>> Hi, Yuri. >>>>> - bug6980209.java can use some public logging? >>>>> - FocusEmbeddedFrameTest/ JButtonInGlassPaneOverlapping/etc why it >>>>> needs a peer? >>>> It's UtilInternal needs it, and that helper should be fixed >>>> in Jake by addExports. >>>> >>>>> - JSplitPaneOverlapping please split the long description >>>>> - bug6608456 why it needs com.sun.java.swing? >>>> That's for SwingUtilities3 (sic)! >>>> >>>> I'll be back with logging and description. >>>> >>>> Thank you! >>>> >>>> -yan >>>> >>>>> >>>>> On 02.07.15 13:55, Yuri Nesterenko wrote: >>>>>> Colleagues, >>>>>> >>>>>> please review this test change: >>>>>> http://cr.openjdk.java.net/~yan/8130125/webrev.00/ >>>>>> >>>>>> In the most of the tests just @modules directive added; >>>>>> other than that, see a short comment in >>>>>> https://bugs.openjdk.java.net/browse/JDK-8130125 >>>>>> >>>>>> Also I'd like to piggyback in the push 3 tests >>>>>> moved from closed part in already approved >>>>>> http://cr.openjdk.java.net/~yan/8081306/ >>>>>> I forgot to do 'hg add', sorry. >>>>>> >>>>>> Thank you! >>>>>> -yan >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>>> >>> >> >> > From alexandr.scherbatiy at oracle.com Fri Jul 3 17:06:31 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 03 Jul 2015 20:06:31 +0300 Subject: [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display Message-ID: <5596C117.1040806@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8076545 webrev: http://cr.openjdk.java.net/~alexsch/8076545/webrev.00 Windows L&F fonts and size of components are rescaled according to the system DPI. Thanks, Alexandr. From pooja.chopra at oracle.com Mon Jul 6 08:58:27 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Mon, 06 Jul 2015 14:28:27 +0530 Subject: [9] Review Request: JDK-8080932 [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java fails with Bad script error due to improper @run notation In-Reply-To: <55952520.6060801@oracle.com> References: <555F3496.5030900@oracle.com> <555F34EA.3050603@oracle.com> <556EF814.40404@oracle.com> <55706545.9010709@oracle.com> <5581151C.8070908@oracle.com> <5594E825.2080304@oracle.com> <55952520.6060801@oracle.com> Message-ID: <559A4333.3010605@oracle.com> Thanks. On 7/2/2015 5:18 PM, Alexander Zvegintsev wrote: > Hi, > > you already have two reviewers, it is sufficient to push. > Anyway, the fix looks good to me. > > Thanks, > > Alexander. > > On 07/02/2015 10:28 AM, pooja chopra wrote: >> Hi All, >> Please review below fix. >> Regards, >> Pooja >> On 6/17/2015 12:05 PM, pooja chopra wrote: >>> Hi All, >>> Gentle reminder .Please review below fix . >>> Regards, >>> Pooja >>> On 6/4/2015 8:18 PM, Alexander Scherbatiy wrote: >>>> >>>> The fix looks good to me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 6/3/2015 3:50 PM, pooja chopra wrote: >>>>> Hi All , >>>>> Please review below fix. >>>>> Regards, >>>>> Pooja >>>>> On 5/22/2015 7:23 PM, pooja chopra wrote: >>>>>> Hello, >>>>>>> Please review a fix for issue: >>>>>>> 8080932 [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java >>>>>>> fails with Bad script error due to improper @run notation >>>>>>> Test bug fix. >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8080932 >>>>>>> The webrev is : >>>>>>> http://cr.openjdk.java.net/~pchopra/8080932/webrev.00 >>>>>>> >>>>>>> Thanks, >>>>>>> Pooja >>>>>> >>>>> >>>> >>> >> > From pooja.chopra at oracle.com Mon Jul 6 08:58:45 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Mon, 06 Jul 2015 14:28:45 +0530 Subject: [9] Review Request: JDK-8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to wrongly typed bugid In-Reply-To: <559523DE.60409@oracle.com> References: <555F606B.3040606@oracle.com> <555F618B.7090507@oracle.com> <55811563.1050609@oracle.com> <5594E858.1020502@oracle.com> <5595234F.7050807@oracle.com> <559523DE.60409@oracle.com> Message-ID: <559A4345.2050107@oracle.com> Thanks. On 7/2/2015 5:13 PM, Sergey Bylokhov wrote: > +1 > > On 02.07.15 14:41, Alexander Zvegintsev wrote: >> Looks fine to me. >> >> Thanks, >> >> Alexander. >> >> On 07/02/2015 10:29 AM, pooja chopra wrote: >>> Hi All, >>> Please review below fix. >>> Regards, >>> Pooja >>> On 6/17/2015 12:06 PM, pooja chopra wrote: >>>> Hi All , >>>> Gentle Reminder. Please review below fix . >>>> Regards, >>>> Pooja >>>> On 5/22/2015 10:34 PM, Sergey Bylokhov wrote: >>>>> cc 2d >>>>> On 22.05.15 19:59, pooja chopra wrote: >>>>>> Hello, >>>>>> Please review a fix for issue: >>>>>> 8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails >>>>>> due to wrongly typed bugid >>>>>> Test bug fix. >>>>>> https://bugs.openjdk.java.net/browse/JDK-8080953 >>>>>> The webrev is : >>>>>> http://cr.openjdk.java.net/~pchopra/8080953/webrev.00 >>>>>> >>>>>> Thanks, >>>>>> Pooja >>>>>> >>>>> >>>>> >>>> >>> >> > > From mikhail.cherkasov at oracle.com Mon Jul 6 10:53:36 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Mon, 06 Jul 2015 13:53:36 +0300 Subject: [9] Review request for 8081787: [macosx] MalformedURLException is thrown during reading data for application/x-java-url; class=java.net.URL flavor In-Reply-To: <55958A63.10201@oracle.com> References: <5593CE9C.20108@oracle.com> <55958A63.10201@oracle.com> Message-ID: <559A5E30.3070908@oracle.com> Hi Sergey, UnsupportedFlavorException is thrown because clipboard has something that can't be translated to application/x-java-url. You should copy link from Safari or copy file from finder, only then you will see MalformedURLException. So testing requires manual actions, because we need a content formed by macosx. Thanks, Mikhail. On 7/2/2015 22:00, Sergey Bylokhov wrote: > Hi, Mikhail. > The test will be useful, at least for verification. On my osx for > example the test from the bug description fails with > UnsupportedFlavorException: application/x-java-url > > On 01.07.15 14:27, mikhail cherkasov wrote: >> Hi there, >> >> Could you please review a fix for: >> 8081787 [macosx] MalformedURLException is thrown during reading data >> for application/x-java-url;class=java.net.URL flavor >> https://bugs.openjdk.java.net/browse/JDK-8081787 >> >> http://cr.openjdk.java.net/~mcherkas/8081787.8/webrev.01/src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java.udiff.html >> >> >> Mac Os X pasteboard returns a property list that consists of one URL, >> but our code supposes to get pure URL. I added extracting URL before >> passing >> text to URL ctor. >> >> I'm not sure how to implement a test for the fix, to test it properly >> we need a particular content in pasteboard, I don't know how to get this >> without manual coping it. >> >> Thanks, >> Mikhail. >> > > From semyon.sadetsky at oracle.com Mon Jul 6 11:17:21 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 06 Jul 2015 14:17:21 +0300 Subject: [9] Review Request for 8130242: DataFlavorComparator transitivity exception In-Reply-To: <559A615F.4060708@oracle.com> References: <559A615F.4060708@oracle.com> Message-ID: <559A63C1.9060104@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8130242 webrev: http://cr.openjdk.java.net/~ssadetsky/8130242/webrev.00/ Data transfer's flavor comparator violates transitivity. --Semyon From Sergey.Bylokhov at oracle.com Mon Jul 6 13:20:16 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 06 Jul 2015 16:20:16 +0300 Subject: [9] Review Request: 8130525 Build failure on jdk9-client solaris-sparcv9 Message-ID: <559A8090.9060600@oracle.com> Hello. Please review the fix for jdk9. In the fix for JDK-7188942 I forgot to cleanup the mapfiles when I removed initPbuffer() method. Bug: https://bugs.openjdk.java.net/browse/JDK-8130525 Webrev can be found at: http://cr.openjdk.java.net/~serb/8130525/webrev.00 -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Mon Jul 6 14:21:59 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 06 Jul 2015 17:21:59 +0300 Subject: [9] Review Request for 8130242: DataFlavorComparator transitivity exception In-Reply-To: <559A63C1.9060104@oracle.com> References: <559A615F.4060708@oracle.com> <559A63C1.9060104@oracle.com> Message-ID: <559A8F07.1030005@oracle.com> On 7/6/2015 2:17 PM, Semyon Sadetsky wrote: > > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8130242 > webrev: http://cr.openjdk.java.net/~ssadetsky/8130242/webrev.00/ > > Data transfer's flavor comparator violates transitivity. Could you give an example of DataFlavors which violated the comparator transitivity contracts before the fix? Thanks, Alexandr. > > --Semyon > > > From alexander.zvegintsev at oracle.com Mon Jul 6 14:27:05 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 06 Jul 2015 17:27:05 +0300 Subject: [9] Review Request: 8130525 Build failure on jdk9-client solaris-sparcv9 In-Reply-To: <559A8090.9060600@oracle.com> References: <559A8090.9060600@oracle.com> Message-ID: <559A9039.70806@oracle.com> Looks fine to me. Thanks, Alexander. On 07/06/2015 04:20 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > > In the fix for JDK-7188942 I forgot to cleanup the mapfiles when I > removed initPbuffer() method. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130525 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8130525/webrev.00 > From semyon.sadetsky at oracle.com Mon Jul 6 14:33:59 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 06 Jul 2015 17:33:59 +0300 Subject: [9] Review Request for 8130242: DataFlavorComparator transitivity exception In-Reply-To: <559A8F07.1030005@oracle.com> References: <559A615F.4060708@oracle.com> <559A63C1.9060104@oracle.com> <559A8F07.1030005@oracle.com> Message-ID: <559A91D7.6060605@oracle.com> Transitivity (2) violated: X: java.awt.datatransfer.DataFlavor[mimetype=text/uri-list;representationclass=java.nio.ByteBuffer;charset=UTF-8], Y: java.awt.datatransfer.DataFlavor[mimetype=application/x-java-text-encoding;representationclass=java.io.InputStream], Z: java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String] X < Y < Z but X > Z --Semyon On 7/6/2015 5:21 PM, Alexander Scherbatiy wrote: > On 7/6/2015 2:17 PM, Semyon Sadetsky wrote: >> >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8130242 >> webrev: http://cr.openjdk.java.net/~ssadetsky/8130242/webrev.00/ >> >> Data transfer's flavor comparator violates transitivity. > > Could you give an example of DataFlavors which violated the > comparator transitivity contracts before the fix? > > Thanks, > Alexandr. > >> >> --Semyon >> >> >> > From james.graham at oracle.com Mon Jul 6 21:11:05 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 06 Jul 2015 14:11:05 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <5596C117.1040806@oracle.com> References: <5596C117.1040806@oracle.com> Message-ID: <559AEEE9.90104@oracle.com> I'll let someone familiar with how the AWT/Swing use all of those metrics respond on whether you've scaled all the right ones, but I wanted to make a minor comment about how the scaling is done. If you inverted it so that scale was 96f/dpi then you could use multiplication everywhere instead of division. Since this code is only executed once on startup (I presume) that isn't all that important, but if we were to use it in other code on the fly then it might add up. (This is not an issue with the fix, just a comment.) ...jim On 7/3/15 10:06 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8076545 > webrev: http://cr.openjdk.java.net/~alexsch/8076545/webrev.00 > > Windows L&F fonts and size of components are rescaled according to > the system DPI. > > Thanks, > Alexandr. > From semyon.sadetsky at oracle.com Tue Jul 7 10:38:38 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 07 Jul 2015 13:38:38 +0300 Subject: [9] Review Request for 8130390: Applet fails to launch on virtual desktop Message-ID: <559BAC2E.2070808@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8130390 webrev: http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.00/ The FlipBufferStrategy did not take an Applet possibility into account. --Semyon From alexander.zvegintsev at oracle.com Tue Jul 7 11:48:22 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 07 Jul 2015 14:48:22 +0300 Subject: [9] Review Request for 8130390: Applet fails to launch on virtual desktop In-Reply-To: <559BAC2E.2070808@oracle.com> References: <559BAC2E.2070808@oracle.com> Message-ID: <559BBC86.5050003@oracle.com> looks fine to me. Thanks, Alexander. On 07/07/2015 01:38 PM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8130390 > webrev: http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.00/ > > The FlipBufferStrategy did not take an Applet possibility into account. > > --Semyon From Sergey.Bylokhov at oracle.com Tue Jul 7 18:46:43 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 07 Jul 2015 21:46:43 +0300 Subject: [9] Review Request for 8130390: Applet fails to launch on virtual desktop In-Reply-To: <559BAC2E.2070808@oracle.com> References: <559BAC2E.2070808@oracle.com> Message-ID: <559C1E93.3050107@oracle.com> Hi, Semyon. It seems that the javadoc of this method/class should be updated via ccc? On 07.07.15 13:38, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8130390 > webrev: http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.00/ > > The FlipBufferStrategy did not take an Applet possibility into account. > > --Semyon -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Wed Jul 8 08:50:50 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 08 Jul 2015 11:50:50 +0300 Subject: [9] Review Request for 8130242: DataFlavorComparator transitivity exception In-Reply-To: <559A91D7.6060605@oracle.com> References: <559A615F.4060708@oracle.com> <559A63C1.9060104@oracle.com> <559A8F07.1030005@oracle.com> <559A91D7.6060605@oracle.com> Message-ID: <559CE46A.3030608@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/6/2015 5:33 PM, Semyon Sadetsky wrote: > > Transitivity (2) violated: > X: > java.awt.datatransfer.DataFlavor[mimetype=text/uri-list;representationclass=java.nio.ByteBuffer;charset=UTF-8], > > Y: > java.awt.datatransfer.DataFlavor[mimetype=application/x-java-text-encoding;representationclass=java.io.InputStream], > > Z: > java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String] > > X < Y < Z but X > Z > > --Semyon > > > On 7/6/2015 5:21 PM, Alexander Scherbatiy wrote: >> On 7/6/2015 2:17 PM, Semyon Sadetsky wrote: >>> >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8130242 >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8130242/webrev.00/ >>> >>> Data transfer's flavor comparator violates transitivity. >> >> Could you give an example of DataFlavors which violated the >> comparator transitivity contracts before the fix? >> >> Thanks, >> Alexandr. >> >>> >>> --Semyon >>> >>> >>> >> > From semyon.sadetsky at oracle.com Wed Jul 8 09:37:35 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 08 Jul 2015 12:37:35 +0300 Subject: [9] Review Request for 8130390: Applet fails to launch on virtual desktop In-Reply-To: <559C1E93.3050107@oracle.com> References: <559BAC2E.2070808@oracle.com> <559C1E93.3050107@oracle.com> Message-ID: <559CEF5F.4090408@oracle.com> Thanks, Sergey! The update fix: http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.01/ --Semyon On 7/7/2015 9:46 PM, Sergey Bylokhov wrote: > Hi, Semyon. > It seems that the javadoc of this method/class should be updated via ccc? > > On 07.07.15 13:38, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8130390 >> webrev: http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.00/ >> >> The FlipBufferStrategy did not take an Applet possibility into account. >> >> --Semyon > > From Sergey.Bylokhov at oracle.com Wed Jul 8 10:50:37 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 08 Jul 2015 13:50:37 +0300 Subject: [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <5596C117.1040806@oracle.com> References: <5596C117.1040806@oracle.com> Message-ID: <559D007D.7040907@oracle.com> Hi, Alexander. Will the fix work in case of multimonitor configuration? When one of the screen is hidpi and another one no? On 03.07.15 20:06, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8076545 > webrev: http://cr.openjdk.java.net/~alexsch/8076545/webrev.00 > > Windows L&F fonts and size of components are rescaled according to > the system DPI. > > Thanks, > Alexandr. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Jul 8 11:35:36 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 08 Jul 2015 14:35:36 +0300 Subject: [9] Review Request for 8130390: Applet fails to launch on virtual desktop In-Reply-To: <559CEF5F.4090408@oracle.com> References: <559BAC2E.2070808@oracle.com> <559C1E93.3050107@oracle.com> <559CEF5F.4090408@oracle.com> Message-ID: <559D0B08.9040609@oracle.com> On 08.07.15 12:37, Semyon Sadetsky wrote: > Thanks, Sergey! > The update fix: http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.01/ You forgot to update the javadoc for class itself: * Inner class for flipping buffers on a component. That component must * be a Canvas or Window. > > --Semyon > > On 7/7/2015 9:46 PM, Sergey Bylokhov wrote: >> Hi, Semyon. >> It seems that the javadoc of this method/class should be updated via >> ccc? >> >> On 07.07.15 13:38, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8130390 >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.00/ >>> >>> The FlipBufferStrategy did not take an Applet possibility into account. >>> >>> --Semyon >> >> > -- Best regards, Sergey. From mikhail.cherkasov at oracle.com Wed Jul 8 11:44:41 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Wed, 08 Jul 2015 14:44:41 +0300 Subject: [8-dev] Review request for 8130752: Wrong changes were pushed with 8068886 Message-ID: <559D0D29.9050807@oracle.com> Hello, Into jdk8 repository wrong changes were pushed mistakenly: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/b26427c5b3fe Those changes were reverted: http://cr.openjdk.java.net/~mcherkas/8130752/webrev.00/src/share/classes/sun/awt/datatransfer/DataTransferer.java.udiff.html bug: https://bugs.openjdk.java.net/browse/JDK-8130752 Thanks, Mikhail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Wed Jul 8 11:48:54 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 08 Jul 2015 14:48:54 +0300 Subject: [9] Review Request for 8130390: Applet fails to launch on virtual desktop In-Reply-To: <559D0B08.9040609@oracle.com> References: <559BAC2E.2070808@oracle.com> <559C1E93.3050107@oracle.com> <559CEF5F.4090408@oracle.com> <559D0B08.9040609@oracle.com> Message-ID: <559D0E26.2030003@oracle.com> Sergey, thanks, again! http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.02/ --Semyon On 7/8/2015 2:35 PM, Sergey Bylokhov wrote: > On 08.07.15 12:37, Semyon Sadetsky wrote: >> Thanks, Sergey! >> The update fix: http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.01/ > You forgot to update the javadoc for class itself: > * Inner class for flipping buffers on a component. That > component must > * be a Canvas or Window. > >> >> --Semyon >> >> On 7/7/2015 9:46 PM, Sergey Bylokhov wrote: >>> Hi, Semyon. >>> It seems that the javadoc of this method/class should be updated via >>> ccc? >>> >>> On 07.07.15 13:38, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Please review fix for JDK9: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8130390 >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.00/ >>>> >>>> The FlipBufferStrategy did not take an Applet possibility into >>>> account. >>>> >>>> --Semyon >>> >>> >> > > From Sergey.Bylokhov at oracle.com Wed Jul 8 12:20:24 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 08 Jul 2015 15:20:24 +0300 Subject: [8-dev] Review request for 8130752: Wrong changes were pushed with 8068886 In-Reply-To: <559D0D29.9050807@oracle.com> References: <559D0D29.9050807@oracle.com> Message-ID: <559D1588.1040308@oracle.com> Looks fine. On 08.07.15 14:44, mikhail cherkasov wrote: > Hello, > > Into jdk8 repository wrong changes were pushed mistakenly: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/b26427c5b3fe > > Those changes were reverted: > http://cr.openjdk.java.net/~mcherkas/8130752/webrev.00/src/share/classes/sun/awt/datatransfer/DataTransferer.java.udiff.html > bug: https://bugs.openjdk.java.net/browse/JDK-8130752 > > Thanks, > Mikhail. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.cherkasov at oracle.com Wed Jul 8 12:22:15 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Wed, 08 Jul 2015 15:22:15 +0300 Subject: [8-dev] Review request for 8130752: Wrong changes were pushed with 8068886 In-Reply-To: <559D1588.1040308@oracle.com> References: <559D0D29.9050807@oracle.com> <559D1588.1040308@oracle.com> Message-ID: <559D15F7.402@oracle.com> Thank you. I believe one review is enough to such kind of fixes. On 7/8/2015 15:20, Sergey Bylokhov wrote: > Looks fine. > > On 08.07.15 14:44, mikhail cherkasov wrote: >> Hello, >> >> Into jdk8 repository wrong changes were pushed mistakenly: >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/b26427c5b3fe >> >> Those changes were reverted: >> http://cr.openjdk.java.net/~mcherkas/8130752/webrev.00/src/share/classes/sun/awt/datatransfer/DataTransferer.java.udiff.html >> bug: https://bugs.openjdk.java.net/browse/JDK-8130752 >> >> Thanks, >> Mikhail. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Jul 8 16:15:27 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 08 Jul 2015 19:15:27 +0300 Subject: [9] Review Request for 8085948: [Regression] Few Swing, AWT and 2D case fails with Decoder isn't implemented for WingDings Charset error on Windows In-Reply-To: <5595D847.6090709@oracle.com> References: <5579B4FD.6070200@oracle.com> <5595D847.6090709@oracle.com> Message-ID: <559D4C9F.2090000@oracle.com> Hi, Semyon. The fix looks fine, but I think you should rename isr->osw. On 03.07.15 3:33, Phil Race wrote: > +1 > > -phil. > > On 6/11/15 9:19 AM, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> bug: https://bugs.openjdk.java.net/browse/JDK-8085948 >> webrev: http://cr.openjdk.java.net/~ssadetsky/8085948/webrev.00/ >> >> It is a regression of JDK-8035302. The charset name is requested from >> a dummy stream reader. But it requires creating of the charset >> decoder to create the reader but decoder is not implemented for >> WingDings and Symbol charsets in Windows. To fix I propose to >> retarget to writer's encoding name. >> >> --Semyon > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Jul 8 16:54:56 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 08 Jul 2015 19:54:56 +0300 Subject: [9] Review Request for 8130390: Applet fails to launch on virtual desktop In-Reply-To: <559D0E26.2030003@oracle.com> References: <559BAC2E.2070808@oracle.com> <559C1E93.3050107@oracle.com> <559CEF5F.4090408@oracle.com> <559D0B08.9040609@oracle.com> <559D0E26.2030003@oracle.com> Message-ID: <559D55E0.7020004@oracle.com> The fix looks fine. On 08.07.15 14:48, Semyon Sadetsky wrote: > Sergey, thanks, again! > http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.02/ > > --Semyon > > On 7/8/2015 2:35 PM, Sergey Bylokhov wrote: >> On 08.07.15 12:37, Semyon Sadetsky wrote: >>> Thanks, Sergey! >>> The update fix: >>> http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.01/ >> You forgot to update the javadoc for class itself: >> * Inner class for flipping buffers on a component. That >> component must >> * be a Canvas or Window. >> >>> >>> --Semyon >>> >>> On 7/7/2015 9:46 PM, Sergey Bylokhov wrote: >>>> Hi, Semyon. >>>> It seems that the javadoc of this method/class should be updated >>>> via ccc? >>>> >>>> On 07.07.15 13:38, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Please review fix for JDK9: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8130390 >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.00/ >>>>> >>>>> The FlipBufferStrategy did not take an Applet possibility into >>>>> account. >>>>> >>>>> --Semyon >>>> >>>> >>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Wed Jul 8 23:32:11 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 8 Jul 2015 16:32:11 -0700 Subject: [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <5596C117.1040806@oracle.com> References: <5596C117.1040806@oracle.com> Message-ID: <559DB2FB.5000208@oracle.com> Hi, - Note that the size you are re-scaling is the real pixel size GDI says to use, so this is presumably to prevent double-scaling ? I can't really tell from the attached images if the size the user perceives in the Win L&F is the same as the rest of the native desktop or much bigger. In other words is Win L&F just right and Metal too small, or is Metal just right and Win L&F too big ? - why use ceil instead of rounding ? For 120 dpi and a reported 14 pixel font you probably want the closest int to "11.2" which is 11 but you will return 12. - I am not familiar with what the effect is of the change in ThemeReader_getSize. Can you explain this. - Sergey's point about multi-mon should be checked out. -phil. On 7/3/2015 10:06 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8076545 > webrev: http://cr.openjdk.java.net/~alexsch/8076545/webrev.00 > > Windows L&F fonts and size of components are rescaled according to > the system DPI. > > Thanks, > Alexandr. > From alexandr.scherbatiy at oracle.com Thu Jul 9 09:25:07 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 09 Jul 2015 12:25:07 +0300 Subject: [8-dev] Review request for 8130752: Wrong changes were pushed with 8068886 In-Reply-To: <559D15F7.402@oracle.com> References: <559D0D29.9050807@oracle.com> <559D1588.1040308@oracle.com> <559D15F7.402@oracle.com> Message-ID: <559E3DF3.6030001@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/8/2015 3:22 PM, mikhail cherkasov wrote: > Thank you. > I believe one review is enough to such kind of fixes. > > > On 7/8/2015 15:20, Sergey Bylokhov wrote: >> Looks fine. >> >> On 08.07.15 14:44, mikhail cherkasov wrote: >>> Hello, >>> >>> Into jdk8 repository wrong changes were pushed mistakenly: >>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/b26427c5b3fe >>> >>> Those changes were reverted: >>> http://cr.openjdk.java.net/~mcherkas/8130752/webrev.00/src/share/classes/sun/awt/datatransfer/DataTransferer.java.udiff.html >>> bug: https://bugs.openjdk.java.net/browse/JDK-8130752 >>> >>> Thanks, >>> Mikhail. >> >> >> -- >> Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Thu Jul 9 10:49:27 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 09 Jul 2015 13:49:27 +0300 Subject: [9] Review Request: 8129894 NSApplicationAWT.m:343:72: error: comparison of constant 777 with expression of type 'NSEventSubtype' Message-ID: <559E51B7.1020700@oracle.com> Hello. Please review the fix for jdk9. This is the last issue, which prevents us to build the jdk on osx using the latest clang w/o --disable-warnings-as-errors. This code was integrated in http://cr.openjdk.java.net/~anashaty/8068886/webrev.00. The new clang complains that our constant is not related to NSEventSubtype. But actually this is not a problem, because our custom events are NSApplicationDefined and subtype is "a numeric identifier that further differentiates custom events"[1]. To supress the warning we can change constant 777 to some value from NSEventSubtype. + small cleanup. I also tried to split the long lines but in this case the change became much bigger, because there are a number of such places. [1] https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSEvent_Class/ Bug: https://bugs.openjdk.java.net/browse/JDK-8129894 Webrev can be found at: http://cr.openjdk.java.net/~serb/8129894/webrev.02 -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Thu Jul 9 11:58:03 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 09 Jul 2015 14:58:03 +0300 Subject: [9] Review Request: 8129894 NSApplicationAWT.m:343:72: error: comparison of constant 777 with expression of type 'NSEventSubtype' In-Reply-To: <559E51B7.1020700@oracle.com> References: <559E51B7.1020700@oracle.com> Message-ID: <559E61CB.9010906@oracle.com> Hello Sergey, the fix looks good to me. Thanks, Alexander. On 07/09/2015 01:49 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > > This is the last issue, which prevents us to build the jdk on osx > using the latest clang w/o --disable-warnings-as-errors. > This code was integrated in > http://cr.openjdk.java.net/~anashaty/8068886/webrev.00. The new clang > complains that our constant is not related to NSEventSubtype. But > actually this is not a problem, because our custom events are > NSApplicationDefined and subtype is "a numeric identifier that further > differentiates custom events"[1]. > To supress the warning we can change constant 777 to some value from > NSEventSubtype. + small cleanup. I also tried to split the long lines > but in this case the change became much bigger, because there are a > number of such places. > > [1] > https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSEvent_Class/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129894 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8129894/webrev.02 > From alexandr.scherbatiy at oracle.com Thu Jul 9 13:40:30 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 09 Jul 2015 16:40:30 +0300 Subject: [9] Review Request: 8129894 NSApplicationAWT.m:343:72: error: comparison of constant 777 with expression of type 'NSEventSubtype' In-Reply-To: <559E61CB.9010906@oracle.com> References: <559E51B7.1020700@oracle.com> <559E61CB.9010906@oracle.com> Message-ID: <559E79CE.9010403@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/9/2015 2:58 PM, Alexander Zvegintsev wrote: > Hello Sergey, > > the fix looks good to me. > > Thanks, > > Alexander. > > On 07/09/2015 01:49 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk9. >> >> This is the last issue, which prevents us to build the jdk on osx >> using the latest clang w/o --disable-warnings-as-errors. >> This code was integrated in >> http://cr.openjdk.java.net/~anashaty/8068886/webrev.00. The new clang >> complains that our constant is not related to NSEventSubtype. But >> actually this is not a problem, because our custom events are >> NSApplicationDefined and subtype is "a numeric identifier that >> further differentiates custom events"[1]. >> To supress the warning we can change constant 777 to some value from >> NSEventSubtype. + small cleanup. I also tried to split the long lines >> but in this case the change became much bigger, because there are a >> number of such places. >> >> [1] >> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSEvent_Class/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8129894 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8129894/webrev.02 >> > From mikhail.cherkasov at oracle.com Fri Jul 10 17:46:19 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Fri, 10 Jul 2015 20:46:19 +0300 Subject: [9] Review request for 8081787: [macosx] MalformedURLException is thrown during reading data for application/x-java-url; class=java.net.URL flavor In-Reply-To: <559A5E30.3070908@oracle.com> References: <5593CE9C.20108@oracle.com> <55958A63.10201@oracle.com> <559A5E30.3070908@oracle.com> Message-ID: <55A004EB.2080206@oracle.com> Hi all, this is kindly reminder about this review request. Thanks, Mikhail. On 7/6/2015 13:53, mikhail cherkasov wrote: > Hi Sergey, > > UnsupportedFlavorException is thrown because clipboard has something > that can't be translated to application/x-java-url. > You should copy link from Safari or copy file from finder, only then > you will see MalformedURLException. > > So testing requires manual actions, because we need a content formed > by macosx. > > Thanks, > Mikhail. > > On 7/2/2015 22:00, Sergey Bylokhov wrote: >> Hi, Mikhail. >> The test will be useful, at least for verification. On my osx for >> example the test from the bug description fails with >> UnsupportedFlavorException: application/x-java-url >> >> On 01.07.15 14:27, mikhail cherkasov wrote: >>> Hi there, >>> >>> Could you please review a fix for: >>> 8081787 [macosx] MalformedURLException is thrown during reading data >>> for application/x-java-url;class=java.net.URL flavor >>> https://bugs.openjdk.java.net/browse/JDK-8081787 >>> >>> http://cr.openjdk.java.net/~mcherkas/8081787.8/webrev.01/src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java.udiff.html >>> >>> >>> Mac Os X pasteboard returns a property list that consists of one >>> URL, but our code supposes to get pure URL. I added extracting URL >>> before passing >>> text to URL ctor. >>> >>> I'm not sure how to implement a test for the fix, to test it >>> properly we need a particular content in pasteboard, I don't know >>> how to get this >>> without manual coping it. >>> >>> Thanks, >>> Mikhail. >>> >> >> > From semyon.sadetsky at oracle.com Mon Jul 13 13:59:29 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 13 Jul 2015 16:59:29 +0300 Subject: [9] Review Request for 8025815: Child FileDialog of modal dialog does not get focus on Gnome Message-ID: <55A3C441.4050609@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8025815 wbrev: http://cr.openjdk.java.net/~ssadetsky/8025815/webrev.00/ The root cause is a mixing of GTK and XLib windows. Normally Java uses XLib windows and manage focus transitivity on its side. But for the file chooser we use a native GTK widget if it is available and this widget is crated without parent window because we don't have any other GTK windows. This breaks the focus transitivity chain on Java side because focus is managed by the WM for GTK dialog. Without parent window the GTK file dialog is managed by the WM as a detached standalone window. So modality and focus transitivity with Java windows do not work correctly: the dialog can be overlapped by other java windows and focus can be transferred to them. The proposed solution obtains XID of the GTK dialog window and pass it to the java side to take into account in the focus transitivity chain by sending messages to the WM. Yet another issue I found in the GTK file chooser code is a dispose concurrency issue. The GTK dialog widget is being created in a separate thread upon the setVisible(true) call but it can be hidden or disposed without any synchronization with this thread. It can prevent the VM from stopping if the dialog is hidden or disposed right after its creation. This also was fixed in the proposed solution. --Semyon From alexander.zvegintsev at oracle.com Mon Jul 13 16:21:53 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 13 Jul 2015 19:21:53 +0300 Subject: [9] Review Request for 8025815: Child FileDialog of modal dialog does not get focus on Gnome In-Reply-To: <55A3C441.4050609@oracle.com> References: <55A3C441.4050609@oracle.com> Message-ID: <55A3E5A1.6090408@oracle.com> Hello Semyon, the fix itself look good to me, but the test seems to be broken, it passes for me before the fix and fails after( Ubuntu 14.04, Unity) Thanks, Alexander. On 07/13/2015 04:59 PM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8025815 > wbrev: http://cr.openjdk.java.net/~ssadetsky/8025815/webrev.00/ > > The root cause is a mixing of GTK and XLib windows. Normally Java uses > XLib windows and manage focus transitivity on its side. But for the > file chooser we use a native GTK widget if it is available and this > widget is crated without parent window because we don't have any other > GTK windows. This breaks the focus transitivity chain on Java side > because focus is managed by the WM for GTK dialog. Without parent > window the GTK file dialog is managed by the WM as a detached > standalone window. So modality and focus transitivity with Java > windows do not work correctly: the dialog can be overlapped by other > java windows and focus can be transferred to them. > The proposed solution obtains XID of the GTK dialog window and pass it > to the java side to take into account in the focus transitivity chain > by sending messages to the WM. > > Yet another issue I found in the GTK file chooser code is a dispose > concurrency issue. The GTK dialog widget is being created in a > separate thread upon the setVisible(true) call but it can be hidden or > disposed without any synchronization with this thread. It can prevent > the VM from stopping if the dialog is hidden or disposed right after > its creation. This also was fixed in the proposed solution. > > --Semyon From peter.brunet at oracle.com Mon Jul 13 22:34:48 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Mon, 13 Jul 2015 17:34:48 -0500 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities Message-ID: <55A43D08.7030106@oracle.com> Please review the webrev for https://bugs.openjdk.java.net/browse/JDK-8051626 http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ This is so the the Java Accessibility Utilities package, com.sun.java.accessibility.util, can be run with the security manager active but the non-public accessibility packages won't, i.e. com.sun.java.accessibility.internal and com.sun.java.accessibility.util.internal. Running the regression test proves that there will be a security exception when using a method of com.sun.java.accessibility.util before the fix but not after. Pete From james.graham at oracle.com Mon Jul 13 23:36:02 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 13 Jul 2015 16:36:02 -0700 Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: <552E7006.70101@oracle.com> References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com> <5502E763.7080008@oracle.com> <55147EBE.3010002@oracle.com> <551BF6AC.8000705@oracle.com> <5523AB20.30704@oracle.com> <552E7006.70101@oracle.com> Message-ID: <55A44B62.7070703@oracle.com> Hi Alexandr, Sorry that this fell into the cracks. Here are some fairly minor updates: AbstractMRI - getGraphics() should include "getGraphics() not supported on Multi-Resolution Images" as the exception description text. AbstractMRI - getBaseImage() should have doc comments: /** * Return the base image representing the best version of the image * for rendering at the default width and height. * @return the base image of the set of multi-resolution images */ (Does it need an @since given that the entire interface is @since 1.9?) BaseMRI - the doc comments (both the class comment and the constructor comments) don't start with "/**" so they aren't really doc comments, but they look good so make them so. BaseMRI - class comment - "The implementation will return the first ... satisfy the rendering request." Add another sentence right there "The last image in the array will be returned if no suitable image is found that is larger than the rendering request." BaseMRI - move "For best effect ..." should be moved to a new paragraph and mention that no exception will be thrown if the images are not sorted as suggested. RenderingHints - comments: DEFAULT, SIZE_FIT, DPI_FIT - "an image resolution variant is chosen ..." (add "an") DEFAULT - "... which may depend on the policies of the platform" SIZE_FIT, DPI_FIT "... on the DPI of ..." (add "the") SunHints - descriptor texts: SIZE_FIT, DPI_FIT "based on the DPI" (add "the") MRCachedImage - remind me what this is used for? MRCachedImage.getResolutionVariant - use ceil or round instead of (int) cast? ceil() would match the actions of MRToolkitImage better. Also note following comment about precision with SG2D. SG2D/MRI - the interface declares the values as float, the usage in SG2D computes values in double and then truncates them to int to pass to the interface - should we upgrade the interface to double for completeness? If not, then the usage in SG2D should at least pass in float precision. SG2D.getResolutionVariant - using destRegionWH to calculate destImageWH can involve a lot of "do some math and then later have additional code undo it". Would it be faster to just compute destImageWH directly, as in: float destImageWidth, destImageHeight; if (BASE) { destImageWH = srcWH; } else if (DPI) { destImageWH = (float) abs(srcWH * devScale); } else { double destRegionWidth, destRegionHeight; if (type) { ... } destImageWH = (float) abs(srcWH * destRegionWH / swh); } Image rv = img.getRV(destImageWH); On the other hand, the last "else" is probably the most common case so this doesn't save anything in the common case, but it avoids a bunch of math that could introduce rounding error for the BASE/DPI cases (even though it is done in doubles). Is there intent to have the default case be mapped to DPI_FIT for Windows? MultiResolutionRenderinHints.java - should have "Test" appended to the name MRRHTest - why not render to a BufferedImage and avoid Robot? Could it tap into internal APIs to create a BImg/compatibleImage with a given devScale? MRRHTest - why allow up to delta=50 on the comparison? MRRHTest - since the scale factor comes from a dialog, we depend on running this on a HiDPI display to fully test the hints? Could using "scaled compatible images" allow testing this more definitively? MRRHTest - remove println before pushing? MRRHTest - probably shouldn't have a "right answer" for DEFAULT - it should probably just pass if the operation doesn't throw an exception? ...jim On 4/15/15 7:04 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8029339/webrev.08/ > > - SunGraphics2D is updated to calculate the resolution variant size > according to the _BASE, _DPI_FIT, and _SIZE_FIT resolution rendering hint > - MultiResolutionRenderingHints test is added > > Thanks, > Alexandr. > > > On 4/7/2015 1:02 PM, Jim Graham wrote: >> This is an interesting suggestion that would let us keep the >> implementation of the various hints centralized and simplify the >> interface to the part of the mechanism that is most tied in to the >> implementation specifics of the database of media variants - which is >> housed in the MRI-implementing object. >> >> I'm not sure we ever identified any need to customize the logic of >> "what size is needed for this render operation" beyond what we >> expressed in the hints, and given that the platform defaults may not >> be easy to express to an arbitrary implementation, it is probably >> better to put that part of the logic in SG2D, controlled by the easy >> to express hints and keep the current API both simple to implement and >> flexible to use. Even if there was a need to customize that part of >> the operation (the "what size is relevant to this rendering operation" >> decision) beyond what the hints suggest, it would be inappropriate to >> tie that in to the "find me media" aspect of the MRI interface >> anyway. So, best to keep them separate and have the hints affect what >> SG2D does and have the MRI focused on just storing (possibly creating) >> and managing/finding the variants. >> >> ...jim >> >> On 4/1/15 6:46 AM, Alexander Scherbatiy wrote: >>> On 3/27/2015 12:48 AM, Jim Graham wrote: >>>> Hi Alexander, >>> >>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.07/ >>> I have updated the fix according to the comments except >>> RenderingHints. >>> >>> RenderingHints are supposed to be set on Graphics2D and they have >>> keys/values which are not relevant to the getResolutionVariant() method. >>> Graphics objects chooses an alternative according to the set >>> rendering hints. >>> May be what SG2D should do just calculate dest image size for the >>> given resolution variant hint (_BASE - base image size, _SIZE_FIT - >>> including scale factor and graphics transform (Mac algorithm), >>> _DPI_FIT - scaled according to the system DPI) and then pass them to >>> the getResolutionVariant() method? >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> MRI.java: >>>> >>>> Who is the intended audience for the recommendation in the interface >>>> to cache image variants? Are we asking the developers who call the >>>> methods on the interface to cache the answers? That would be unwise >>>> because the list of variants may change over time for some MRIs. Are >>>> we speaking to the implementer? If so, then I think that it is >>>> unnecessary to remind implementers of basic implementation >>>> strategies like "cache complicated objects". >>>> >>>> How about this wording for the getRV() method? - "Gets a specific >>>> image that is the best variant to represent this logical image at >>>> the indicated size and screen resolution." >>>> >>>> Perhaps we should clarify in the doc comments for the dimension >>>> arguments in getRV() that the dimensions are measured in pixels? >>>> >>>> line 56 - delete blank line between doc comment and method declaration >>>> >>>> Also, it is probably overkill to document that the interface >>>> getVariants() method returns an unmodifiable list. Responsible >>>> implementations would probably use an unmodifiable list, but I don't >>>> think it should be required by the interface. We do need to specify >>>> that it isn't required to be modifiable so that a caller doesn't >>>> expect to be able to modify it, but that is a looser spec. How >>>> about "Gets a readable list of all resolution variants. Note that >>>> many implementations might return an unmodifiable list."? >>>> >>>> AbstractMIR.java: >>>> >>>> "provides a default implementation for the MRI" or "provides default >>>> implementations of several methods in the interface and the >>>> class"? Actually, I'll note that it provides none of the >>>> implementations of the MRI methods so maybe it should be "provides >>>> default implementations of several methods for classes that >>>> want to implement the interface"? >>>> >>>> In the doc example - wrap the list to make it unmodifiable >>>> >>>> The doc example could be made 2 or 3 lines shorter by simply >>>> assuming the base image is in index 0 (it's just an example so I'm >>>> not sure the flexibility needs to be a part of the example). >>>> >>>> getGraphics is allowed by the Image interface to return null. >>>> Actually, the exact wording is that it can only be called for >>>> "offscreen images" and a MRI is technically not "an offscreen >>>> image". Perhaps we should return null here since modifying the base >>>> image is unlikely to modify the variants and arguably it would be >>>> required by the wording in the method docs (even if the base image >>>> was an offscreen, the MRI produced from it stops being an offscreen)? >>>> >>>> Are all of the empty "@Inherit" comments needed? I thought >>>> inheritance was the default? >>>> >>>> BaseMRI.java: >>>> >>>> "This class is [an] array-based implementation of the {AMRI} class" >>>> (missing "an" and "the") >>>> >>>> We should probably include the comment about the sorting of the >>>> images in the class comments as well as document that the algorithm >>>> is a simple scan from the beginning for the first image large enough >>>> (and default == last image). The algorithm also might not work very >>>> well if the images are not monotonically both wider and taller. How >>>> about adding this to the class comments: >>>> >>>> "The implementation will return the first image variant in the array >>>> that is large enough to satisfy the rendering request. For best >>>> effect the array of images should be sorted with each image being >>>> both wider and taller than the previous image. The base image need >>>> not be the first image in the array." >>>> >>>> getVariants() - you need to return an unmodifiable list. asList() >>>> returns a list that "writes back" to the array. You need to use >>>> Collections.unmodifiableList(Arrays.asList(array)). >>>> >>>> RenderingHints.java: >>>> >>>> Where do we process this hint? Don't we need to pass it to the >>>> getVariant() method? >>>> >>>> I don't understand the hint values other than the one that always >>>> uses the base image. Default I guess gives us the ability to use >>>> the Mac algorithm of "next larger size" on Mac and "based on Screen >>>> DPI" on Windows, but the 3rd value "ON" is so vague as to not have >>>> any meaning. Perhaps we should just delete it, but then do we just >>>> always do the Mac method? Or do we vaguely have our internal images >>>> have a platform-specific method and the Abstract/Base classes just >>>> do what they want with no control from the user? In FX we are also >>>> still struggling with this issue and we may likely just do what the >>>> Mac does in all cases, but perhaps AWT needs to "behave like the >>>> platform" more? If we are going to have actual values, then we need >>>> to have them do something, which means: >>>> >>>> - SG2D needs to track the hint just like we do the other hints that >>>> affect our processing >>>> - MRI.getVariant() needs to have the hint as an argument >>>> - BaseMRI should probably do something with that hint >>>> - hint values should include: >>>> - ..._DEFAULT - implementation gets to decide >>>> - ..._BASE - always use the base image >>>> - ..._SIZE_FIT - Mac algorithm of smallest image that is big enough >>>> - ..._DPI_FIT - choose based on DPI of the screen, ignoring >>>> transform >>>> >>>> line 978 - missing blank line between fields >>>> >>>> SG2D.java: >>>> >>>> - The interface says that you will be passing in the "logical DPI" >>>> of the display, but here you are actually passing in the screen's >>>> scale factor. >>>> >>>> BaseMRITest.java: >>>> >>>> - testBaseMRI also passes in a scale rather than a DPI to the MRI >>>> method. >>>> >>>> - How does the modification test pass when the implementation >>>> doesn't use unmodifiable lists? >>>> >>>> MRITest.java: >>>> >>>> - also uses scale rather than DPI in several places >>>> >>>> ...jim >>>> >>>> On 3/13/15 6:34 AM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the proposed API based on MultiresolutionImage >>>>> interface: >>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.06/ >>>>> >>>>> - return unmodifiable list comment is added to the >>>>> getResolutionVariants() method javadoc in MultiresolutionImage >>>>> interface >>>>> - base image size arguments are removed form the >>>>> getResolutionVariant(...) method in MultiresolutionImage interface >>>>> - BaseMultiResolutionImage class that allows to create a >>>>> multi-resolution image based on resolution variant array is added >>>>> - the test for the BaseMultiResolutionImage is added >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 2/14/2015 3:23 AM, Jim Graham wrote: >>>>>> The second solution looks good. I'd make it standard practice >>>>>> (perhaps even mentioned in the documentation) to return unmodifiable >>>>>> lists from the getVariants() method. The Collections class provides >>>>>> easy methods to create these lists, and it sends a clear message to >>>>>> the caller that the list was provided for them to read, but not write >>>>>> to. Otherwise they may add a new image to the list you provided them >>>>>> and wonder why it wasn't showing up. Also, an unmodifiable list can >>>>>> be cached and reused for subsequent calls without having to create a >>>>>> new list every time. >>>>>> >>>>>> In getResolutionVariant() was there a reason why the base dimensions >>>>>> were provided as float? The destination dimensions make sense as >>>>>> float since they could be the result of a scale, but the source >>>>>> dimensions are typically getWidth/getHeight() on the base image. A >>>>>> related question would be if they are needed at all, since the >>>>>> implementation should probably already be aware of what the base >>>>>> image >>>>>> is and what its dimensions are. I'm guessing they are provided >>>>>> because the implementation in SG2D already knows them and it makes it >>>>>> easier to forward the implementation on to a shared (static?) method? >>>>>> >>>>>> With respect to default implementations, I take it that the >>>>>> BaseMRI is >>>>>> along the pattern that we see in Swing for Base classes. Would it be >>>>>> helpful to provide an implementation (in addition or instead) that >>>>>> allows a developer to take a bunch of images and quickly make an MRI >>>>>> without having to override anything? The implementations of >>>>>> getBaseImage() and getResolutionVariants() are pretty straightforward >>>>>> and a fairly reasonable default algorithm can be provided for >>>>>> getRV(dimensions). This question is more of an idle question for my >>>>>> own curiosity than a stumbling block... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 1/22/2015 6:49 AM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hi Phil, >>>>>>> >>>>>>> I have prepared two versions of the proposed API: >>>>>>> >>>>>>> I) Resolution variants are added directly to the Image: >>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/list/webrev.00 >>>>>>> >>>>>>> II) MultiResolutionImage interface is used: >>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.05 >>>>>>> >>>>>>> It could help to decide which way should be chosen for the the >>>>>>> multi-resolution image support. >>>>>>> >>>>>>> Below are some comments: >>>>>>> >>>>>>> 1. High level goal: >>>>>>> Introduce an API that allows to create and handle an image >>>>>>> with >>>>>>> resolution variants. >>>>>>> >>>>>>> 2. What is not subject of the provided API >>>>>>> - Scale naming convention for high-resolution images >>>>>>> - Providing pixel scale factor for the screen/window >>>>>>> >>>>>>> 3. Use cases >>>>>>> 3.1 Loading and drawing high-resolution icons in IntelliJ IDEA >>>>>>> A high-resolution image is loaded from resources and stored in >>>>>>> JBHiDPIScaledImage class which is a subclass of the buffered image. >>>>>>> The high-resolution image is used to create a disabled icon >>>>>>> in the >>>>>>> IconLoader.getDisabledIcon(icon) method. >>>>>>> https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/openapi/util/IconLoader.java >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 3.2 Loading and drawing high-resolution icons in NetBeans >>>>>>> NetBeans does not have support for the high-resolution icons >>>>>>> loading. >>>>>>> It loads an icon from the file system using >>>>>>> Toolkit.getDefaultToolkit().getImage(url) method or from resources >>>>>>> by ImageReader and store it in ToolTipImage class which is >>>>>>> subclass of the buffered image. >>>>>>> ImageUtilities.createDisabledIcon(icon) method creates a >>>>>>> disabled >>>>>>> icon by applying RGBImageFilter to the icon. >>>>>>> http://hg.netbeans.org/main/file/97dcf49eb4a7/openide.util/src/org/openide/util/ImageUtilities.java >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 3.3 Loading system icons in JDK 1.8 >>>>>>> JDK requests icons from the native system for system L&Fs and >>>>>>> applies filters for them. >>>>>>> See for example AquaUtils.generateLightenedImage() method: >>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e6f48c4fad38/src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 4. HiDPI support for Images on different OSes >>>>>>> >>>>>>> 4.1 Mac OS X >>>>>>> Cocoa API contains NSImage that allows to work with image >>>>>>> representations: add/remove/get all representations. >>>>>>> It picks up an image with necessary resolution based on the >>>>>>> screen backing store pixel scale factor and applied transforms. >>>>>>> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/Reference/Reference.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 4.2 Linux >>>>>>> GTK+ 3 API has gtkcssimagescaled lib (it seems that it is not >>>>>>> public/stable) >>>>>>> that parses the -gtk-scaled css property and draws a >>>>>>> GtkCssImage >>>>>>> according to the given scale factor. >>>>>>> >>>>>>> I have not found information about the HiDPI support in Xlib. >>>>>>> >>>>>>> 4.3 Windows >>>>>>> I have only found the tutorial that suggests to select and >>>>>>> draw a >>>>>>> bitmap using the queried DPI >>>>>>> and scale the coordinates for drawing a rectangular frame >>>>>>> http://msdn.microsoft.com/en-us/library/dd464659%28v=vs.85%29.aspx >>>>>>> >>>>>>> Windows also provides the horizontal and vertical DPI of the >>>>>>> desktop >>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316 >>>>>>> >>>>>>> 5. Pseudo API >>>>>>> Below are some ways which illustrates how multi-resolution >>>>>>> images >>>>>>> can be created and used. >>>>>>> >>>>>>> 5.1 Resolution variants are stored directly in Image class. >>>>>>> To query a resolution variant it needs to compare the >>>>>>> resolution >>>>>>> variant width/height >>>>>>> with the requested high-resolution size. >>>>>>> ------------ >>>>>>> public abstract class Image { >>>>>>> >>>>>>> public void addResolutionVariant(Image image) {...} >>>>>>> public List getResolutionVariants() {...} >>>>>>> } >>>>>>> ------------ >>>>>>> // create a disabled image with resolution variants >>>>>>> >>>>>>> Image disabledImage = getDisabledImage(image); >>>>>>> >>>>>>> for (Image rv : image.getResolutionVariants()) { >>>>>>> disabledImage.addResolutionVariant(getDisabledImage(rv)); >>>>>>> } >>>>>>> ------------ >>>>>>> This approach requires that all resolution variants have been >>>>>>> created even not of them are really used. >>>>>>> >>>>>>> 5.2 Resolution variants are stored in a separate object that >>>>>>> allows to create them by demand. >>>>>>> To query a resolution variant it needs to compare the >>>>>>> resolution >>>>>>> variant scale factor >>>>>>> with the requested scale (that can include both screen DPI >>>>>>> scale >>>>>>> and applied transforms). >>>>>>> ------------ >>>>>>> public abstract class Image { >>>>>>> >>>>>>> public static interface ResolutionVariant { >>>>>>> Image getImage(); >>>>>>> float getScaleFactor(); >>>>>>> } >>>>>>> >>>>>>> public void addResolutionVariant(ResolutionVariant >>>>>>> resolutionVariant) {...} >>>>>>> public List getResolutionVariants() >>>>>>> {...} >>>>>>> } >>>>>>> ------------ >>>>>>> // create a disabled image with resolution variants >>>>>>> Image disabledImage = getDisabledImage(image); >>>>>>> >>>>>>> for (Image.ResolutionVariant rv : >>>>>>> image.getResolutionVariants()) { >>>>>>> disabledImage.addResolutionVariant(new >>>>>>> Image.ResolutionVariant() { >>>>>>> >>>>>>> public Image getImage() { >>>>>>> return getDisabledImage(rv.getImage()); >>>>>>> } >>>>>>> >>>>>>> public float getScaleFactor() { >>>>>>> return rv.getScaleFactor(); >>>>>>> } >>>>>>> }); >>>>>>> } >>>>>>> ------------ >>>>>>> >>>>>>> It does not have problem if a predefined set of images is >>>>>>> provided >>>>>>> (like image.png and image at 2x.png on the file system). >>>>>>> This does not cover cases where a resolution variant can be >>>>>>> created >>>>>>> using the exact requested size (like loading icons from the native >>>>>>> system). >>>>>>> A resolution variant can be queried based on a scale factor and >>>>>>> applied transforms. >>>>>>> >>>>>>> 5.3 The provided example allows to create a resolution variant >>>>>>> using the requested high-resolution image size. >>>>>>> ------------ >>>>>>> public interface MultiResolutionImage { >>>>>>> Image getResolutionVariant(float width, float height); >>>>>>> } >>>>>>> ------------ >>>>>>> // create a multi-resolution image >>>>>>> Image mrImage = new AbstractMultiResolutionImage() { >>>>>>> >>>>>>> public Image getResolutionVariant(float width, float >>>>>>> height) { >>>>>>> // create and return a resolution variant with >>>>>>> exact >>>>>>> requested width/height size >>>>>>> } >>>>>>> >>>>>>> protected Image getBaseImage() { >>>>>>> return baseImage; >>>>>>> } >>>>>>> }; >>>>>>> ------------ >>>>>>> // create a disabled image with resolution variants >>>>>>> Image disabledImage = null; >>>>>>> if (image instanceof MultiResolutionImage) { >>>>>>> final MultiResolutionImage mrImage = (MultiResolutionImage) >>>>>>> image; >>>>>>> disabledImage = new AbstractMultiResolutionImage(){ >>>>>>> >>>>>>> public Image getResolutionVariant(float width, float >>>>>>> height) { >>>>>>> return >>>>>>> getDisabledImage(mrImage.getResolutionVariant(width, height)); >>>>>>> } >>>>>>> >>>>>>> protected Image getBaseImage() { >>>>>>> return getDisabledImage(mrImage); >>>>>>> } >>>>>>> }; >>>>>>> } else { >>>>>>> disabledImage = getDisabledImage(image); >>>>>>> } >>>>>>> ------------ >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>> >>> >> > From javalists at cbfiddle.com Tue Jul 14 00:18:47 2015 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 13 Jul 2015 17:18:47 -0700 Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: <55A44B62.7070703@oracle.com> References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com> <5502E763.7080008@oracle.com> <55147EBE.3010002@oracle.com> <551BF6AC.8000705@oracle.com> <5523AB20.30704@oracle.com> <552E7006.70101@oracle.com> <55A44B62.7070703@oracle.com> Message-ID: I have a concern about how custom multiresolution images are supported based on a problem I ran into using the JDK 8 classes, which are similar. The problem is that the selection of a variant image happens during painting. That is a very bad time to actually try to render an image, if one is in a situation where images of arbitrary resolution can be produced by rendering. If I have code now that uses a background thread to create an image in this manner, how can I support HiDPI displays? Creating a multiresolution image defeats the purpose of using a background thread if it defers rendering until paint time. It seems that the best I can do is to guess what resolutions might be wanted and generate them all in advance or, alternatively, generate the highest resolution I expect to need, and have the graphics system scale it down for lower resolutions when requested. Neither of these alternatives is optimal. Although the Image class does allow images to be produced in the background, that API is way too complex for use by an application, and the supporting code for Toolkit images is not accessible. It would be nice to have a simple way to return an image that is produced in the background. Something like Future? Alan From Sergey.Bylokhov at oracle.com Tue Jul 14 10:00:41 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 14 Jul 2015 13:00:41 +0300 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55A43D08.7030106@oracle.com> References: <55A43D08.7030106@oracle.com> Message-ID: <55A4DDC9.7070704@oracle.com> Hi, Pete. The fix looks fine, but you should tweak the test a little bit. - You access the swing components on non-EDT thread. - You should not use System.exit in the test. - The JFrame should be disposed before the end of the test. On 14.07.15 1:34, Pete Brunet wrote: > Please review the webrev for > https://bugs.openjdk.java.net/browse/JDK-8051626 > > http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ > > This is so the the Java Accessibility Utilities package, > com.sun.java.accessibility.util, can be run with the security manager > active but the non-public accessibility packages won't, i.e. > com.sun.java.accessibility.internal and > com.sun.java.accessibility.util.internal. > > Running the regression test proves that there will be a security > exception when using a method of com.sun.java.accessibility.util before > the fix but not after. > > Pete -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 14 10:08:54 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 14 Jul 2015 13:08:54 +0300 Subject: [9] Review Request for 8025815: Child FileDialog of modal dialog does not get focus on Gnome In-Reply-To: <55A3C441.4050609@oracle.com> References: <55A3C441.4050609@oracle.com> Message-ID: <55A4DFB6.9070700@oracle.com> On 13.07.15 16:59, Semyon Sadetsky wrote: > Yet another issue I found in the GTK file chooser code is a dispose > concurrency issue. The GTK dialog widget is being created in a > separate thread upon the setVisible(true) call but it can be hidden or > disposed without any synchronization with this thread. It can prevent > the VM from stopping if the dialog is hidden or disposed right after > its creation. This also was fixed in the proposed solution. Is it possible to write the test for this issue also? > > --Semyon -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 14 10:19:42 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 14 Jul 2015 13:19:42 +0300 Subject: [9] Review Request for 8025815: Child FileDialog of modal dialog does not get focus on Gnome In-Reply-To: <55A3C441.4050609@oracle.com> References: <55A3C441.4050609@oracle.com> Message-ID: <55A4E23E.1020106@oracle.com> Small comment: GtkFileDialogPeer.c: you will need to add a CHECK_NULL( widgetFieldID) before setWindowMethodID, and CHECK_NULL(setWindowMethodID); at the end of the method is not necessary. On 13.07.15 16:59, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8025815 > wbrev: http://cr.openjdk.java.net/~ssadetsky/8025815/webrev.00/ > > The root cause is a mixing of GTK and XLib windows. Normally Java uses > XLib windows and manage focus transitivity on its side. But for the > file chooser we use a native GTK widget if it is available and this > widget is crated without parent window because we don't have any other > GTK windows. This breaks the focus transitivity chain on Java side > because focus is managed by the WM for GTK dialog. Without parent > window the GTK file dialog is managed by the WM as a detached > standalone window. So modality and focus transitivity with Java > windows do not work correctly: the dialog can be overlapped by other > java windows and focus can be transferred to them. > The proposed solution obtains XID of the GTK dialog window and pass it > to the java side to take into account in the focus transitivity chain > by sending messages to the WM. > > Yet another issue I found in the GTK file chooser code is a dispose > concurrency issue. The GTK dialog widget is being created in a > separate thread upon the setVisible(true) call but it can be hidden or > disposed without any synchronization with this thread. It can prevent > the VM from stopping if the dialog is hidden or disposed right after > its creation. This also was fixed in the proposed solution. > > --Semyon -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Tue Jul 14 11:16:04 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 14 Jul 2015 14:16:04 +0300 Subject: [9] Review Request for 8025815: Child FileDialog of modal dialog does not get focus on Gnome In-Reply-To: <55A4DFB6.9070700@oracle.com> References: <55A3C441.4050609@oracle.com> <55A4DFB6.9070700@oracle.com> Message-ID: <55A4EF74.5030603@oracle.com> This is concurrency issue. Such test would be unstable or take a lot of time. On 7/14/2015 1:08 PM, Sergey Bylokhov wrote: > On 13.07.15 16:59, Semyon Sadetsky wrote: >> Yet another issue I found in the GTK file chooser code is a dispose >> concurrency issue. The GTK dialog widget is being created in a >> separate thread upon the setVisible(true) call but it can be hidden >> or disposed without any synchronization with this thread. It can >> prevent the VM from stopping if the dialog is hidden or disposed >> right after its creation. This also was fixed in the proposed solution. > > Is it possible to write the test for this issue also? > >> >> --Semyon > > From Sergey.Bylokhov at oracle.com Tue Jul 14 12:02:49 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 14 Jul 2015 15:02:49 +0300 Subject: [9] Review Request for 8025815: Child FileDialog of modal dialog does not get focus on Gnome In-Reply-To: <55A4EF74.5030603@oracle.com> References: <55A3C441.4050609@oracle.com> <55A4DFB6.9070700@oracle.com> <55A4EF74.5030603@oracle.com> Message-ID: <55A4FA69.4030500@oracle.com> On 14.07.15 14:16, Semyon Sadetsky wrote: > This is concurrency issue. Such test would be unstable or take a lot > of time. I guess after the fix it should be stable? or there are some other issues? > > On 7/14/2015 1:08 PM, Sergey Bylokhov wrote: >> On 13.07.15 16:59, Semyon Sadetsky wrote: >>> Yet another issue I found in the GTK file chooser code is a dispose >>> concurrency issue. The GTK dialog widget is being created in a >>> separate thread upon the setVisible(true) call but it can be hidden >>> or disposed without any synchronization with this thread. It can >>> prevent the VM from stopping if the dialog is hidden or disposed >>> right after its creation. This also was fixed in the proposed solution. >> >> Is it possible to write the test for this issue also? >> >>> >>> --Semyon >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Tue Jul 14 12:05:17 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 14 Jul 2015 15:05:17 +0300 Subject: [9] Review Request for 8025815: Child FileDialog of modal dialog does not get focus on Gnome In-Reply-To: <55A4FA69.4030500@oracle.com> References: <55A3C441.4050609@oracle.com> <55A4DFB6.9070700@oracle.com> <55A4EF74.5030603@oracle.com> <55A4FA69.4030500@oracle.com> Message-ID: <55A4FAFD.2000000@oracle.com> The fix is stable. On 7/14/2015 3:02 PM, Sergey Bylokhov wrote: > On 14.07.15 14:16, Semyon Sadetsky wrote: >> This is concurrency issue. Such test would be unstable or take a lot >> of time. > I guess after the fix it should be stable? or there are some other > issues? > >> >> On 7/14/2015 1:08 PM, Sergey Bylokhov wrote: >>> On 13.07.15 16:59, Semyon Sadetsky wrote: >>>> Yet another issue I found in the GTK file chooser code is a dispose >>>> concurrency issue. The GTK dialog widget is being created in a >>>> separate thread upon the setVisible(true) call but it can be hidden >>>> or disposed without any synchronization with this thread. It can >>>> prevent the VM from stopping if the dialog is hidden or disposed >>>> right after its creation. This also was fixed in the proposed >>>> solution. >>> >>> Is it possible to write the test for this issue also? >>> >>>> >>>> --Semyon >>> >>> >> > > From alexander.zvegintsev at oracle.com Tue Jul 14 12:14:04 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 14 Jul 2015 15:14:04 +0300 Subject: [9] Review Request for 8130242: DataFlavorComparator transitivity exception In-Reply-To: <559CE46A.3030608@oracle.com> References: <559A615F.4060708@oracle.com> <559A63C1.9060104@oracle.com> <559A8F07.1030005@oracle.com> <559A91D7.6060605@oracle.com> <559CE46A.3030608@oracle.com> Message-ID: <55A4FD0C.5070400@oracle.com> looks good to me too. Thanks, Alexander. On 07/08/2015 11:50 AM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/6/2015 5:33 PM, Semyon Sadetsky wrote: >> >> Transitivity (2) violated: >> X: >> java.awt.datatransfer.DataFlavor[mimetype=text/uri-list;representationclass=java.nio.ByteBuffer;charset=UTF-8], >> >> Y: >> java.awt.datatransfer.DataFlavor[mimetype=application/x-java-text-encoding;representationclass=java.io.InputStream], >> >> Z: >> java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String] >> >> X < Y < Z but X > Z >> >> --Semyon >> >> >> On 7/6/2015 5:21 PM, Alexander Scherbatiy wrote: >>> On 7/6/2015 2:17 PM, Semyon Sadetsky wrote: >>>> >>>> Hello, >>>> >>>> Please review fix for JDK9: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8130242 >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8130242/webrev.00/ >>>> >>>> Data transfer's flavor comparator violates transitivity. >>> >>> Could you give an example of DataFlavors which violated the >>> comparator transitivity contracts before the fix? >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> --Semyon >>>> >>>> >>>> >>> >> > From sean.mullan at oracle.com Tue Jul 14 15:57:48 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Jul 2015 11:57:48 -0400 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55A43D08.7030106@oracle.com> References: <55A43D08.7030106@oracle.com> Message-ID: <55A5317C.5040809@oracle.com> You don't need to add the /secure option to jtreg. That's overriding jtreg's SecurityManager and causing you to have to grant jtreg permissions to read files in the jtreg.security.policy file. Just add the /java.security.policy option -- this will use jtreg's SecurityManager which is sufficient for testing this bug, and then you won't need the jtreg.security.policy file. Looks good otherwise. --Sean On 07/13/2015 06:34 PM, Pete Brunet wrote: > Please review the webrev for > https://bugs.openjdk.java.net/browse/JDK-8051626 > > http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ > > This is so the the Java Accessibility Utilities package, > com.sun.java.accessibility.util, can be run with the security manager > active but the non-public accessibility packages won't, i.e. > com.sun.java.accessibility.internal and > com.sun.java.accessibility.util.internal. > > Running the regression test proves that there will be a security > exception when using a method of com.sun.java.accessibility.util before > the fix but not after. > > Pete > From mandy.chung at oracle.com Wed Jul 15 03:48:10 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Jul 2015 11:48:10 +0800 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55A5317C.5040809@oracle.com> References: <55A43D08.7030106@oracle.com> <55A5317C.5040809@oracle.com> Message-ID: <1CF42E03-D436-48C5-8F66-B9C447778BB6@oracle.com> Moving the internal classes to com.sun.java.accessibility.internal is right as com.sun.java.accessibility is a supported API. Sean is right that no need to specify /secure=java.lang.SecurityManager. Mandy > On Jul 14, 2015, at 11:57 PM, Sean Mullan wrote: > > You don't need to add the /secure option to jtreg. That's overriding jtreg's SecurityManager and causing you to have to grant jtreg permissions to read files in the jtreg.security.policy file. Just add the /java.security.policy option -- this will use jtreg's SecurityManager which is sufficient for testing this bug, and then you won't need the jtreg.security.policy file. > > Looks good otherwise. > > --Sean > > On 07/13/2015 06:34 PM, Pete Brunet wrote: >> Please review the webrev for >> https://bugs.openjdk.java.net/browse/JDK-8051626 >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ >> >> This is so the the Java Accessibility Utilities package, >> com.sun.java.accessibility.util, can be run with the security manager >> active but the non-public accessibility packages won't, i.e. >> com.sun.java.accessibility.internal and >> com.sun.java.accessibility.util.internal. >> >> Running the regression test proves that there will be a security >> exception when using a method of com.sun.java.accessibility.util before >> the fix but not after. >> >> Pete >> From pooja.chopra at oracle.com Wed Jul 15 09:56:22 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Wed, 15 Jul 2015 15:26:22 +0530 Subject: < Swing Dev> [9] Review Request:JDK-8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java failed with UnsupportedOperation exception Message-ID: <55A62E46.3020504@oracle.com> Hello, Please review a fix for issue :- 8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java failed with UnsupportedOperation exception Test bug fix. https://bugs.openjdk.java.net/browse/JDK-8130481 The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.00/ Regards, Pooja From pooja.chopra at oracle.com Wed Jul 15 10:07:26 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Wed, 15 Jul 2015 15:37:26 +0530 Subject: < Swing Dev> [9] Review Request:JDK-8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java failed with UnsupportedOperation exception In-Reply-To: <55A62E46.3020504@oracle.com> References: <55A62E46.3020504@oracle.com> Message-ID: <55A630DE.4080500@oracle.com> Hello , Corrected the webrev link below . Please review. Regards, Pooja On 7/15/2015 3:26 PM, pooja chopra wrote: > Hello, > > Please review a fix for issue :- > > 8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java > failed with UnsupportedOperation exception > Test bug fix. > https://bugs.openjdk.java.net/browse/JDK-8130481 > The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.01/ > > Regards, > Pooja > From alexandr.scherbatiy at oracle.com Wed Jul 15 11:07:38 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 15 Jul 2015 14:07:38 +0300 Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com> <5502E763.7080008@oracle.com> <55147EBE.3010002@oracle.com> <551BF6AC.8000705@oracle.com> <5523AB20.30704@oracle.com> <552E7006.70101@oracle.com> <55A44B62.7070703@oracle.com> Message-ID: <55A63EFA.6000104@oracle.com> On 7/14/2015 3:18 AM, Alan Snyder wrote: > I have a concern about how custom multiresolution images are supported based on a problem I ran into using the JDK 8 classes, which are similar. > > The problem is that the selection of a variant image happens during painting. That is a very bad time to actually try to render an image, if one is in a situation where images of arbitrary resolution can be produced by rendering. > > If I have code now that uses a background thread to create an image in this manner, how can I support HiDPI displays? Creating a multiresolution image defeats the purpose of using a background thread if it defers rendering until paint time. It seems that the best I can do is to guess what resolutions might be wanted and generate them all in advance or, alternatively, generate the highest resolution I expect to need, and have the graphics system scale it down for lower resolutions when requested. Neither of these alternatives is optimal. JDK 9 has the fix that includes the scale factor in the GraphicsConfiguration default transform: http://hg.openjdk.java.net/jdk9/client/jdk/rev/661136704d07 It is possible to iterate over all graphics devices, decide on which device the image is supposed to be rendered and generate an image resolution according to the scale factor from the device graphics configuration. Thanks, Alexandr. > > Although the Image class does allow images to be produced in the background, that API is way too complex for use by an application, and the supporting code for Toolkit images is not accessible. > > It would be nice to have a simple way to return an image that is produced in the background. Something like Future? > > Alan > From semyon.sadetsky at oracle.com Wed Jul 15 12:59:29 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 15 Jul 2015 15:59:29 +0300 Subject: [9] Review Request for 8025815: Child FileDialog of modal dialog does not get focus on Gnome In-Reply-To: <55A3E5A1.6090408@oracle.com> References: <55A3C441.4050609@oracle.com> <55A3E5A1.6090408@oracle.com> Message-ID: <55A65931.6050802@oracle.com> Hi Alexander, In the next version I have updated the test and Sergey's notes are taken into account. http://cr.openjdk.java.net/~ssadetsky/8025815/webrev.01/ --Semyon On 7/13/2015 7:21 PM, Alexander Zvegintsev wrote: > Hello Semyon, > > the fix itself look good to me, but the test seems to be broken, it > passes for me before the fix and fails after( Ubuntu 14.04, Unity) > > Thanks, > > Alexander. > > On 07/13/2015 04:59 PM, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8025815 >> wbrev: http://cr.openjdk.java.net/~ssadetsky/8025815/webrev.00/ >> >> The root cause is a mixing of GTK and XLib windows. Normally Java >> uses XLib windows and manage focus transitivity on its side. But for >> the file chooser we use a native GTK widget if it is available and >> this widget is crated without parent window because we don't have any >> other GTK windows. This breaks the focus transitivity chain on Java >> side because focus is managed by the WM for GTK dialog. Without >> parent window the GTK file dialog is managed by the WM as a detached >> standalone window. So modality and focus transitivity with Java >> windows do not work correctly: the dialog can be overlapped by other >> java windows and focus can be transferred to them. >> The proposed solution obtains XID of the GTK dialog window and pass >> it to the java side to take into account in the focus transitivity >> chain by sending messages to the WM. >> >> Yet another issue I found in the GTK file chooser code is a dispose >> concurrency issue. The GTK dialog widget is being created in a >> separate thread upon the setVisible(true) call but it can be hidden >> or disposed without any synchronization with this thread. It can >> prevent the VM from stopping if the dialog is hidden or disposed >> right after its creation. This also was fixed in the proposed solution. >> >> --Semyon > From alexander.zvegintsev at oracle.com Wed Jul 15 13:23:16 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 15 Jul 2015 16:23:16 +0300 Subject: [9] Review Request for 8025815: Child FileDialog of modal dialog does not get focus on Gnome In-Reply-To: <55A65931.6050802@oracle.com> References: <55A3C441.4050609@oracle.com> <55A3E5A1.6090408@oracle.com> <55A65931.6050802@oracle.com> Message-ID: <55A65EC4.7070407@oracle.com> still looks good to me. Thanks, Alexander. On 07/15/2015 03:59 PM, Semyon Sadetsky wrote: > Hi Alexander, > > In the next version I have updated the test and Sergey's notes are > taken into account. > > http://cr.openjdk.java.net/~ssadetsky/8025815/webrev.01/ > > --Semyon > > On 7/13/2015 7:21 PM, Alexander Zvegintsev wrote: >> Hello Semyon, >> >> the fix itself look good to me, but the test seems to be broken, it >> passes for me before the fix and fails after( Ubuntu 14.04, Unity) >> >> Thanks, >> >> Alexander. >> >> On 07/13/2015 04:59 PM, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8025815 >>> wbrev: http://cr.openjdk.java.net/~ssadetsky/8025815/webrev.00/ >>> >>> The root cause is a mixing of GTK and XLib windows. Normally Java >>> uses XLib windows and manage focus transitivity on its side. But for >>> the file chooser we use a native GTK widget if it is available and >>> this widget is crated without parent window because we don't have >>> any other GTK windows. This breaks the focus transitivity chain on >>> Java side because focus is managed by the WM for GTK dialog. Without >>> parent window the GTK file dialog is managed by the WM as a detached >>> standalone window. So modality and focus transitivity with Java >>> windows do not work correctly: the dialog can be overlapped by other >>> java windows and focus can be transferred to them. >>> The proposed solution obtains XID of the GTK dialog window and pass >>> it to the java side to take into account in the focus transitivity >>> chain by sending messages to the WM. >>> >>> Yet another issue I found in the GTK file chooser code is a dispose >>> concurrency issue. The GTK dialog widget is being created in a >>> separate thread upon the setVisible(true) call but it can be hidden >>> or disposed without any synchronization with this thread. It can >>> prevent the VM from stopping if the dialog is hidden or disposed >>> right after its creation. This also was fixed in the proposed solution. >>> >>> --Semyon >> > From javalists at cbfiddle.com Wed Jul 15 14:09:25 2015 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 15 Jul 2015 07:09:25 -0700 Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: <55A63EFA.6000104@oracle.com> References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com> <5502E763.7080008@oracle.com> <55147EBE.3010002@oracle.com> <551BF6AC.8000705@oracle.com> <5523AB20.30704@oracle.com> <552E7006.70101@oracle.com> <55A44B62.7070703@oracle.com> <55A63EFA.6000104@oracle.com> Message-ID: It seems you are making an assumption that the code that creates the image is somehow initiated from a paint method so that the display scale factor can be obtained from the graphics context and used to determine the required image resolution. That is not the scenario I am concerned about. I am talking about what I would consider a common case: a program that was written before the concept of HiDPI displays existed and is being adapted to support HiDPI displays. In this case, because the image creation is potentially a long running process, the program is written to use a background thread to create the image. Once the image is created, it is stored somewhere that can be accessed by a painting method of a component. Prior to the image becoming available, the component will paint some default background or perhaps paint a default image. I do not want to rearchitect the program to support HiDPI displays. Using the display scale information for the available displays, I could create a multiresolution image in the background thread that either contains multiple images for all available displays or contains one image at the maximum required resolution of the available displays. However, these solutions are non-optimal. Either images may be created that will never be used or image scaling may be used to reduce the resolution, which may result in a lower quality image. What I would like to do is create a multiresolution image that tells my code what resolution image is needed and allows me to create that image on a background thread. In additional to solving the HiDPI problem optimally, this solution would support less common cases, such as displays added to the system at run time and graphics contexts that are scaled for some reason other than supporting a HiDPI display. I am assuming this capability already exists to support toolkit images. It would be nice to make that capability available to applications. Alan > On Jul 15, 2015, at 4:07 AM, Alexander Scherbatiy wrote: > > On 7/14/2015 3:18 AM, Alan Snyder wrote: >> I have a concern about how custom multiresolution images are supported based on a problem I ran into using the JDK 8 classes, which are similar. >> >> The problem is that the selection of a variant image happens during painting. That is a very bad time to actually try to render an image, if one is in a situation where images of arbitrary resolution can be produced by rendering. >> >> If I have code now that uses a background thread to create an image in this manner, how can I support HiDPI displays? Creating a multiresolution image defeats the purpose of using a background thread if it defers rendering until paint time. It seems that the best I can do is to guess what resolutions might be wanted and generate them all in advance or, alternatively, generate the highest resolution I expect to need, and have the graphics system scale it down for lower resolutions when requested. Neither of these alternatives is optimal. > JDK 9 has the fix that includes the scale factor in the GraphicsConfiguration default transform: http://hg.openjdk.java.net/jdk9/client/jdk/rev/661136704d07 > > It is possible to iterate over all graphics devices, decide on which device the image is supposed to be rendered and generate an image resolution according to the scale factor from the device graphics configuration. > > Thanks, > Alexandr. > >> >> Although the Image class does allow images to be produced in the background, that API is way too complex for use by an application, and the supporting code for Toolkit images is not accessible. >> >> It would be nice to have a simple way to return an image that is produced in the background. Something like Future? >> >> Alan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Wed Jul 15 14:42:10 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 15 Jul 2015 17:42:10 +0300 Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com> <5502E763.7080008@oracle.com> <55147EBE.3010002@oracle.com> <551BF6AC.8000705@oracle.com> <5523AB20.30704@oracle.com> <552E7006.70101@oracle.com> <55A44B62.7070703@oracle.com> <55A63EFA.6000104@oracle.com> Message-ID: <55A67142.8090302@oracle.com> On 7/15/2015 5:09 PM, Alan Snyder wrote: > > It seems you are making an assumption that the code that creates the > image is somehow initiated from a paint method so that the display > scale factor can be obtained from the graphics context and used to > determine the required image resolution. That is not the scenario I am > concerned about. > The information about screen devices are available from the GraphicsEnvironment. Something like: ---------------------- public static void main(String[] args) { GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); for(GraphicsDevice device: ge.getScreenDevices()){ for(GraphicsConfiguration config: device.getConfigurations()){ if(!config.getDefaultTransform().isIdentity()){ System.out.println("Start high-resolution image loading"); } } } } ---------------------- Thanks, Alexandr. > > > I am talking about what I would consider a common case: a program that > was written before the concept of HiDPI displays existed and is being > adapted to support HiDPI displays. In this case, because the image > creation is potentially a long running process, the program is written > to use a background thread to create the image. Once the image is > created, it is stored somewhere that can be accessed by a painting > method of a component. Prior to the image becoming available, the > component will paint some default background or perhaps paint a > default image. > > I do not want to rearchitect the program to support HiDPI displays. > Using the display scale information for the available displays, I > could create a multiresolution image in the background thread that > either contains multiple images for all available displays or contains > one image at the maximum required resolution of the available > displays. However, these solutions are non-optimal. Either images may > be created that will never be used or image scaling may be used to > reduce the resolution, which may result in a lower quality image. > > What I would like to do is create a multiresolution image that tells > my code what resolution image is needed and allows me to create that > image on a background thread. In additional to solving the HiDPI > problem optimally, this solution would support less common cases, such > as displays added to the system at run time and graphics contexts that > are scaled for some reason other than supporting a HiDPI display. > > I am assuming this capability already exists to support toolkit > images. It would be nice to make that capability available to > applications. > > Alan > > >> On Jul 15, 2015, at 4:07 AM, Alexander Scherbatiy >> > > wrote: >> >> On 7/14/2015 3:18 AM, Alan Snyder wrote: >>> I have a concern about how custom multiresolution images are >>> supported based on a problem I ran into using the JDK 8 classes, >>> which are similar. >>> >>> The problem is that the selection of a variant image happens during >>> painting. That is a very bad time to actually try to render an >>> image, if one is in a situation where images of arbitrary resolution >>> can be produced by rendering. >>> >>> If I have code now that uses a background thread to create an image >>> in this manner, how can I support HiDPI displays? Creating a >>> multiresolution image defeats the purpose of using a background >>> thread if it defers rendering until paint time. It seems that the >>> best I can do is to guess what resolutions might be wanted and >>> generate them all in advance or, alternatively, generate the highest >>> resolution I expect to need, and have the graphics system scale it >>> down for lower resolutions when requested. Neither of these >>> alternatives is optimal. >> JDK 9 has the fix that includes the scale factor in the >> GraphicsConfiguration default transform: >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/661136704d07 >> >> It is possible to iterate over all graphics devices, decide on >> which device the image is supposed to be rendered and generate an >> image resolution according to the scale factor from the device >> graphics configuration. >> >> Thanks, >> Alexandr. >> >>> >>> Although the Image class does allow images to be produced in the >>> background, that API is way too complex for use by an application, >>> and the supporting code for Toolkit images is not accessible. >>> >>> It would be nice to have a simple way to return an image that is >>> produced in the background. Something like Future? >>> >>> Alan >>> >> > From javalists at cbfiddle.com Wed Jul 15 15:44:28 2015 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 15 Jul 2015 08:44:28 -0700 Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: <55A67142.8090302@oracle.com> References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com> <5502E763.7080008@oracle.com> <55147EBE.3010002@oracle.com> <551BF6AC.8000705@oracle.com> <5523AB20.30704@oracle.com> <552E7006.70101@oracle.com> <55A44B62.7070703@oracle.com> <55A63EFA.6000104@oracle.com> <55A67142.8090302@oracle.com> Message-ID: I am commenting on your suggestion that I can determine which display the image will displayed on. > On Jul 15, 2015, at 7:42 AM, Alexander Scherbatiy wrote: > > On 7/15/2015 5:09 PM, Alan Snyder wrote: >> >> It seems you are making an assumption that the code that creates the image is somehow initiated from a paint method so that the display scale factor can be obtained from the graphics context and used to determine the required image resolution. That is not the scenario I am concerned about. >> > The information about screen devices are available from the GraphicsEnvironment. > Something like: > ---------------------- > public static void main(String[] args) { > GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); > for(GraphicsDevice device: ge.getScreenDevices()){ > for(GraphicsConfiguration config: device.getConfigurations()){ > if(!config.getDefaultTransform().isIdentity()){ > System.out.println("Start high-resolution image loading"); > } > } > } > } > ---------------------- > > Thanks, > Alexandr. >> >> >> I am talking about what I would consider a common case: a program that was written before the concept of HiDPI displays existed and is being adapted to support HiDPI displays. In this case, because the image creation is potentially a long running process, the program is written to use a background thread to create the image. Once the image is created, it is stored somewhere that can be accessed by a painting method of a component. Prior to the image becoming available, the component will paint some default background or perhaps paint a default image. >> >> I do not want to rearchitect the program to support HiDPI displays. Using the display scale information for the available displays, I could create a multiresolution image in the background thread that either contains multiple images for all available displays or contains one image at the maximum required resolution of the available displays. However, these solutions are non-optimal. Either images may be created that will never be used or image scaling may be used to reduce the resolution, which may result in a lower quality image. >> >> What I would like to do is create a multiresolution image that tells my code what resolution image is needed and allows me to create that image on a background thread. In additional to solving the HiDPI problem optimally, this solution would support less common cases, such as displays added to the system at run time and graphics contexts that are scaled for some reason other than supporting a HiDPI display. >> >> I am assuming this capability already exists to support toolkit images. It would be nice to make that capability available to applications. >> >> Alan >> >> >>> On Jul 15, 2015, at 4:07 AM, Alexander Scherbatiy >> wrote: >>> >>> On 7/14/2015 3:18 AM, Alan Snyder wrote: >>>> I have a concern about how custom multiresolution images are supported based on a problem I ran into using the JDK 8 classes, which are similar. >>>> >>>> The problem is that the selection of a variant image happens during painting. That is a very bad time to actually try to render an image, if one is in a situation where images of arbitrary resolution can be produced by rendering. >>>> >>>> If I have code now that uses a background thread to create an image in this manner, how can I support HiDPI displays? Creating a multiresolution image defeats the purpose of using a background thread if it defers rendering until paint time. It seems that the best I can do is to guess what resolutions might be wanted and generate them all in advance or, alternatively, generate the highest resolution I expect to need, and have the graphics system scale it down for lower resolutions when requested. Neither of these alternatives is optimal. >>> JDK 9 has the fix that includes the scale factor in the GraphicsConfiguration default transform: http://hg.openjdk.java.net/jdk9/client/jdk/rev/661136704d07 >>> >>> It is possible to iterate over all graphics devices, decide on which device the image is supposed to be rendered and generate an image resolution according to the scale factor from the device graphics configuration. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> Although the Image class does allow images to be produced in the background, that API is way too complex for use by an application, and the supporting code for Toolkit images is not accessible. >>>> >>>> It would be nice to have a simple way to return an image that is produced in the background. Something like Future? >>>> >>>> Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Jul 15 19:02:50 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 15 Jul 2015 22:02:50 +0300 Subject: < Swing Dev> [9] Review Request:JDK-8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java failed with UnsupportedOperation exception In-Reply-To: <55A630DE.4080500@oracle.com> References: <55A62E46.3020504@oracle.com> <55A630DE.4080500@oracle.com> Message-ID: <55A6AE5A.3060408@oracle.com> Hello, I suggest to check support of systemTray at the beginning of the test. On 15.07.15 13:07, pooja chopra wrote: > Hello , > > Corrected the webrev link below . Please review. > > Regards, > Pooja > On 7/15/2015 3:26 PM, pooja chopra wrote: >> Hello, >> >> Please review a fix for issue :- >> >> 8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java >> failed with UnsupportedOperation exception >> Test bug fix. >> https://bugs.openjdk.java.net/browse/JDK-8130481 >> The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.01/ >> >> Regards, >> Pooja >> > -- Best regards, Sergey. From peter.brunet at oracle.com Wed Jul 15 21:42:25 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 15 Jul 2015 16:42:25 -0500 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55A4DDC9.7070704@oracle.com> References: <55A43D08.7030106@oracle.com> <55A4DDC9.7070704@oracle.com> Message-ID: <55A6D3C1.4080601@oracle.com> An update is available and mostly changes only the test case, Bug8151626.java. The other change is to remove jtreg.security.policy. http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.01/ Changes: >From Sean - The jtreg @run statement was removed; don't specify security manager or security policy. - Remove jtreg.security.policy - Add System.setSecurityManager(new SecurityManager()); to the beginning of the code. >From Sergey - Wrap test in invokeAndWait - Add frame.dispose in finally - Remove System.exit I also removed the Thread.sleep. It doesn't appear to be needed. Pete On 7/14/15 5:00 AM, Sergey Bylokhov wrote: > Hi, Pete. > The fix looks fine, but you should tweak the test a little bit. > - You access the swing components on non-EDT thread. > - You should not use System.exit in the test. > - The JFrame should be disposed before the end of the test. > > On 14.07.15 1:34, Pete Brunet wrote: >> Please review the webrev for >> https://bugs.openjdk.java.net/browse/JDK-8051626 >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ >> >> This is so the the Java Accessibility Utilities package, >> com.sun.java.accessibility.util, can be run with the security manager >> active but the non-public accessibility packages won't, i.e. >> com.sun.java.accessibility.internal and >> com.sun.java.accessibility.util.internal. >> >> Running the regression test proves that there will be a security >> exception when using a method of com.sun.java.accessibility.util before >> the fix but not after. >> >> Pete > > From Sergey.Bylokhov at oracle.com Thu Jul 16 10:19:06 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 16 Jul 2015 13:19:06 +0300 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55A6D3C1.4080601@oracle.com> References: <55A43D08.7030106@oracle.com> <55A4DDC9.7070704@oracle.com> <55A6D3C1.4080601@oracle.com> Message-ID: <55A7851A.7050400@oracle.com> The fix looks fine. On 16.07.15 0:42, Pete Brunet wrote: > An update is available and mostly changes only the test case, > Bug8151626.java. The other change is to remove jtreg.security.policy. > > http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.01/ > > Changes: > > From Sean > - The jtreg @run statement was removed; don't specify security manager > or security policy. > - Remove jtreg.security.policy > - Add System.setSecurityManager(new SecurityManager()); to the beginning > of the code. > > From Sergey > - Wrap test in invokeAndWait > - Add frame.dispose in finally > - Remove System.exit > > I also removed the Thread.sleep. It doesn't appear to be needed. > > Pete > > On 7/14/15 5:00 AM, Sergey Bylokhov wrote: >> Hi, Pete. >> The fix looks fine, but you should tweak the test a little bit. >> - You access the swing components on non-EDT thread. >> - You should not use System.exit in the test. >> - The JFrame should be disposed before the end of the test. >> >> On 14.07.15 1:34, Pete Brunet wrote: >>> Please review the webrev for >>> https://bugs.openjdk.java.net/browse/JDK-8051626 >>> >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ >>> >>> This is so the the Java Accessibility Utilities package, >>> com.sun.java.accessibility.util, can be run with the security manager >>> active but the non-public accessibility packages won't, i.e. >>> com.sun.java.accessibility.internal and >>> com.sun.java.accessibility.util.internal. >>> >>> Running the regression test proves that there will be a security >>> exception when using a method of com.sun.java.accessibility.util before >>> the fix but not after. >>> >>> Pete >> -- Best regards, Sergey. From yuri.nesterenko at oracle.com Thu Jul 16 14:16:26 2015 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 16 Jul 2015 17:16:26 +0300 Subject: [9] Review Request for 8131673: [TEST_BUG] add @modules to some OS X-specific regtests Message-ID: <55A7BCBA.6070509@oracle.com> Colleagues, please review this test fix for 3 tests reflecting com.apple.eawt. After the fix, they should start with a modular build. Two of them dealing with fullscreen, should now work better on OS X 10.9. I cannot, however, easily fix them for OS X 10.10 where full screen button is in different place. Let's make another bug for that. Current CR is https://bugs.openjdk.java.net/browse/JDK-8131673 Webrev is http://cr.openjdk.java.net/~yan/8131673/webrev.00/ Thanks, -yan From Sergey.Bylokhov at oracle.com Thu Jul 16 15:07:55 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 16 Jul 2015 18:07:55 +0300 Subject: [9] Review Request for 8131673: [TEST_BUG] add @modules to some OS X-specific regtests In-Reply-To: <55A7BCBA.6070509@oracle.com> References: <55A7BCBA.6070509@oracle.com> Message-ID: <55A7C8CB.2070302@oracle.com> The fix looks fine. On 16.07.15 17:16, Yuri Nesterenko wrote: > I cannot, however, easily fix them for OS X 10.10 where full screen > button is in different place. Let's make another bug for that. > > Current CR is > https://bugs.openjdk.java.net/browse/JDK-8131673 > Webrev is > http://cr.openjdk.java.net/~yan/8131673/webrev.00/ > > Thanks, > -yan -- Best regards, Sergey. From semyon.sadetsky at oracle.com Thu Jul 16 16:08:15 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 16 Jul 2015 19:08:15 +0300 Subject: [9] Review Request for 8130769: The new menu can't be shown on the menubar after clicking the "Add" button. Message-ID: <55A7D6EF.3040104@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8130769 webrev: http://cr.openjdk.java.net/~ssadetsky/8130769/webrev.00/ This is regression from JDK-7155957. Menu should be added to MenuBar collection before the adding it to MenuBar's peer otherwise it is not painted. --Semyon From alexander.zvegintsev at oracle.com Thu Jul 16 16:23:24 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 16 Jul 2015 19:23:24 +0300 Subject: [9] Review Request for 8131673: [TEST_BUG] add @modules to some OS X-specific regtests In-Reply-To: <55A7C8CB.2070302@oracle.com> References: <55A7BCBA.6070509@oracle.com> <55A7C8CB.2070302@oracle.com> Message-ID: <55A7DA7C.2060708@oracle.com> +1 Thanks, Alexander. On 07/16/2015 06:07 PM, Sergey Bylokhov wrote: > The fix looks fine. > On 16.07.15 17:16, Yuri Nesterenko wrote: >> I cannot, however, easily fix them for OS X 10.10 where full screen >> button is in different place. Let's make another bug for that. >> >> Current CR is >> https://bugs.openjdk.java.net/browse/JDK-8131673 >> Webrev is >> http://cr.openjdk.java.net/~yan/8131673/webrev.00/ >> >> Thanks, >> -yan > > From peter.brunet at oracle.com Fri Jul 17 01:48:22 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 16 Jul 2015 20:48:22 -0500 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55A6D3C1.4080601@oracle.com> References: <55A43D08.7030106@oracle.com> <55A4DDC9.7070704@oracle.com> <55A6D3C1.4080601@oracle.com> Message-ID: <55A85EE6.5010705@oracle.com> >From Mandy: - remove unused imports - add @run main/othervm http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.02/ On 7/15/15 4:42 PM, Pete Brunet wrote: > An update is available and mostly changes only the test case, > Bug8151626.java. The other change is to remove jtreg.security.policy. > > http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.01/ > > Changes: > > From Sean > - The jtreg @run statement was removed; don't specify security manager > or security policy. > - Remove jtreg.security.policy > - Add System.setSecurityManager(new SecurityManager()); to the beginning > of the code. > > From Sergey > - Wrap test in invokeAndWait > - Add frame.dispose in finally > - Remove System.exit > > I also removed the Thread.sleep. It doesn't appear to be needed. > > Pete > > On 7/14/15 5:00 AM, Sergey Bylokhov wrote: >> Hi, Pete. >> The fix looks fine, but you should tweak the test a little bit. >> - You access the swing components on non-EDT thread. >> - You should not use System.exit in the test. >> - The JFrame should be disposed before the end of the test. >> >> On 14.07.15 1:34, Pete Brunet wrote: >>> Please review the webrev for >>> https://bugs.openjdk.java.net/browse/JDK-8051626 >>> >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ >>> >>> This is so the the Java Accessibility Utilities package, >>> com.sun.java.accessibility.util, can be run with the security manager >>> active but the non-public accessibility packages won't, i.e. >>> com.sun.java.accessibility.internal and >>> com.sun.java.accessibility.util.internal. >>> >>> Running the regression test proves that there will be a security >>> exception when using a method of com.sun.java.accessibility.util before >>> the fix but not after. >>> >>> Pete >> From alexandr.scherbatiy at oracle.com Fri Jul 17 13:27:48 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 17 Jul 2015 16:27:48 +0300 Subject: [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <559DB2FB.5000208@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> Message-ID: <55A902D4.1050603@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8076545/webrev.01/ - inverted scale is used - round is used instead of ceil On 7/9/2015 2:32 AM, Phil Race wrote: > Hi, > > - Note that the size you are re-scaling is the real pixel size GDI > says to use, > so this is presumably to prevent double-scaling ? I can't really > tell from > the attached images if the size the user perceives in the Win L&F is > the same as the rest of the native desktop or much bigger. > In other words is Win L&F just right and Metal too small, or is > Metal just right and Win L&F too big ? The Win L&F is twice bigger than Metal L&F, window, and component sizes. > > - why use ceil instead of rounding ? For 120 dpi and a reported 14 > pixel font you > probably want the closest int to "11.2" which is 11 but you will > return 12. > > - I am not familiar with what the effect is of the change in > ThemeReader_getSize. > Can you explain this. It returns size of requested native controls. For example, Windows L&F can request a size of the expanded or collapsed Tree icon. > > - Sergey's point about multi-mon should be checked out. Windows 8.1 has option "Let me choose one scaling level for all my displays". If I unset it I am able to change the size of all items. However, the DPI which returns GetDPIForMonitor is still 2 on HiDPI displays. Thanks, Alexandr. > > -phil. > > On 7/3/2015 10:06 AM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8076545 >> webrev: http://cr.openjdk.java.net/~alexsch/8076545/webrev.00 >> >> Windows L&F fonts and size of components are rescaled according to >> the system DPI. >> >> Thanks, >> Alexandr. >> > From semyon.sadetsky at oracle.com Fri Jul 17 13:37:44 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 17 Jul 2015 16:37:44 +0300 Subject: [9] Review Request for 8131670: [TEST_BUG]Test java/awt/EventQueue/6980209/bug6980209.java fails on Linux Message-ID: <55A90528.9060002@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8131670 webrev: http://cr.openjdk.java.net/~ssadetsky/8131670/webrev.00/ 1ms auto-delay was set to the robot to improve stability on Linux platforms. Also additional focus request procedure added to improve focus gain on OEL7. --Semyon From semyon.sadetsky at oracle.com Fri Jul 17 16:27:12 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 17 Jul 2015 19:27:12 +0300 Subject: [9] Review Request for 8041519: JVM crash on second DnD after modal dialog opened during Swing DnD operation Message-ID: <55A92CE0.70307@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8041519 webrev: http://cr.openjdk.java.net/~ssadetsky/8041519/webrev.00/ This is regression from JDK-6342381. When a modal dialog blocks drop operation in progress state consequent mouse events clear the drop context variables (this clearing was introduced by JDK-6342381). The solution is to avoid clearing if drop operation is in progress. Test scenario for this case would be too hard and unstable. Since the fix is pretty simple I left it as noreg. --Semyon From peter.brunet at oracle.com Fri Jul 17 19:53:03 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 17 Jul 2015 14:53:03 -0500 Subject: JNI JavaVM* pointer - above 32 bits now with Java 9? Message-ID: <55A95D1F.1040509@oracle.com> This is a JNI question. Is the JavaVM* pointer returned by GetJavaVM guaranteed to not have any bits in the upper 32? There is old code I am working with that stores the JavaVM pointer in longs (32 bits on 64 bit Win) and uses longs to transfer the value all around within the code and to/from an external native API. It's not been a problem in the past but since 9 b58 and the switch to VS 2013 java.exe has the High Entropy Virtual Addresses bit set which means that all memory addresses in a 64-bit app are guaranteed to be above 4gb ( 4294967295 aka 0xFFFFFFFF) and thus have bits in the upper 32, but I don't know if that also applies to the JavaVM* pointer. If there will be address bits in the upper 32 one possible workaround to save recompilation by users of the external native API might be to save the upper 32 bits after calling GetJavaVM and then prepend those bits whenever the long comes back in from the external API. The users of the external API never manipulate those bits; they receive the bits when starting to use the API. Is there a better list for this question? Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.brunet at oracle.com Fri Jul 17 21:53:48 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 17 Jul 2015 16:53:48 -0500 Subject: JNI JavaVM* pointer - above 32 bits now with Java 9? In-Reply-To: <55A95D1F.1040509@oracle.com> References: <55A95D1F.1040509@oracle.com> Message-ID: <55A9796C.9010001@oracle.com> You can ignore this query. There was an obscure change in the code from using the JavaVM* pointer to using a dialog window handle which would be limited to 32 bits and thus not a problem. The JavaVM* pointer appears to be limited to calling Attach/DetachCurrentThread. Pete On 7/17/15 2:53 PM, Pete Brunet wrote: > This is a JNI question. Is the JavaVM* pointer returned by GetJavaVM > guaranteed to not have any bits in the upper 32? > > There is old code I am working with that stores the JavaVM pointer in > longs (32 bits on 64 bit Win) and uses longs to transfer the value all > around within the code and to/from an external native API. > > It's not been a problem in the past but since 9 b58 and the switch to > VS 2013 java.exe has the High Entropy Virtual Addresses bit set which > means that all memory addresses in a 64-bit app are guaranteed to be > above 4gb ( 4294967295 aka 0xFFFFFFFF) and thus have bits in the upper > 32, but I don't know if that also applies to the JavaVM* pointer. > > If there will be address bits in the upper 32 one possible workaround > to save recompilation by users of the external native API might be to > save the upper 32 bits after calling GetJavaVM and then prepend those > bits whenever the long comes back in from the external API. The users > of the external API never manipulate those bits; they receive the bits > when starting to use the API. > > Is there a better list for this question? > > Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Tue Jul 21 09:40:39 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 21 Jul 2015 12:40:39 +0300 Subject: [9] Review Request for 8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9 Message-ID: <55AE1397.4070709@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8130895 webrev: http://cr.openjdk.java.net/~ssadetsky/8130895/webrev.00/ realSync() used in the test's TestRunnable class causes events come to the XAWT event loop but there are no any windows created at the moment and the system application context is not initialized. This results in attempt to create the KeyboardFocusManager instance on the XAWT's thread group during the XEvent dispatching. That in its turn causes NPE. The solution: since KeyboardFocusManager should never be instantiated in the toolkit event loop, the corresponding check was added. --Semyon -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Tue Jul 21 10:17:18 2015 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 21 Jul 2015 13:17:18 +0300 Subject: [9] Review request for 8130776: Remove EmbeddedFrame.requestFocusToEmbedder() method Message-ID: <55AE1C2E.5070807@oracle.com> Hello AWT team, Could you please review the following fix: bug: https://bugs.openjdk.java.net/browse/JDK-8130776 webrev: http://cr.openjdk.java.net/~aivanov/8130776/jdk9/webrev.00/ Description: Cleaning up the unused method. It was added under JDK-8056915 "Focus lost in applet when browser window is minimized and restored". Later the code has been changed, and this method, requestFocusToEmbedder(), is not used any more. Thanks, Alexey From alexandr.scherbatiy at oracle.com Tue Jul 21 14:41:38 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 21 Jul 2015 17:41:38 +0300 Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: <55A44B62.7070703@oracle.com> References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com> <5502E763.7080008@oracle.com> <55147EBE.3010002@oracle.com> <551BF6AC.8000705@oracle.com> <5523AB20.30704@oracle.com> <552E7006.70101@oracle.com> <55A44B62.7070703@oracle.com> Message-ID: <55AE5A22.7040603@oracle.com> Hello Jim, Thank your for the review. Could you review the updated fix there the suggested comments are updated: http://cr.openjdk.java.net/~alexsch/8029339/webrev.09/ On 7/14/2015 2:36 AM, Jim Graham wrote: > Hi Alexandr, > > Sorry that this fell into the cracks. Here are some fairly minor > updates: > > AbstractMRI - getGraphics() should include "getGraphics() not > supported on Multi-Resolution Images" as the exception description text. > > AbstractMRI - getBaseImage() should have doc comments: > /** > * Return the base image representing the best version of the image > * for rendering at the default width and height. > * @return the base image of the set of multi-resolution images > */ > (Does it need an @since given that the entire interface is @since 1.9?) > > BaseMRI - the doc comments (both the class comment and the constructor > comments) don't start with "/**" so they aren't really doc comments, > but they look good so make them so. > > BaseMRI - class comment - "The implementation will return the first > ... satisfy the rendering request." Add another sentence right there > "The last image in the array will be returned if no suitable image is > found that is larger than the rendering request." > > BaseMRI - move "For best effect ..." should be moved to a new > paragraph and mention that no exception will be thrown if the images > are not sorted as suggested. > > RenderingHints - comments: > DEFAULT, SIZE_FIT, DPI_FIT - "an image resolution variant is chosen > ..." (add "an") > DEFAULT - "... which may depend on the policies of the platform" > SIZE_FIT, DPI_FIT "... on the DPI of ..." (add "the") > > SunHints - descriptor texts: > SIZE_FIT, DPI_FIT "based on the DPI" (add "the") > > MRCachedImage - remind me what this is used for? It is used by AquaLookAndFeel for images and icons rendering requested from the native system. > MRCachedImage.getResolutionVariant - use ceil or round instead of > (int) cast? ceil() would match the actions of MRToolkitImage better. > Also note following comment about precision with SG2D. > > SG2D/MRI - the interface declares the values as float, the usage in > SG2D computes values in double and then truncates them to int to pass > to the interface - should we upgrade the interface to double for > completeness? If not, then the usage in SG2D should at least pass in > float precision. I changed the argument types to double in the MRI.getResolutionVariant(...). > > SG2D.getResolutionVariant - using destRegionWH to calculate > destImageWH can involve a lot of "do some math and then later have > additional code undo it". Would it be faster to just compute > destImageWH directly, as in: > > float destImageWidth, destImageHeight; > > if (BASE) { > destImageWH = srcWH; > } else if (DPI) { > destImageWH = (float) abs(srcWH * devScale); > } else { > double destRegionWidth, destRegionHeight; > if (type) { > ... > } > destImageWH = (float) abs(srcWH * destRegionWH / swh); > } > Image rv = img.getRV(destImageWH); > > On the other hand, the last "else" is probably the most common case so > this doesn't save anything in the common case, but it avoids a bunch > of math that could introduce rounding error for the BASE/DPI cases > (even though it is done in doubles). > > Is there intent to have the default case be mapped to DPI_FIT for > Windows? I think yes. > > MultiResolutionRenderinHints.java - should have "Test" appended to the > name > > MRRHTest - why not render to a BufferedImage and avoid Robot? Could it > tap into internal APIs to create a BImg/compatibleImage with a given > devScale? The DPI_FIT test includes case there a graphics transform is identity but the device configuration transform has scale 2. There should be a way to set scale for the device configuration transform; > > MRRHTest - why allow up to delta=50 on the comparison? It is just for monitors that are calibrated on Mac OS X and they colors are different from that which was set. The test uses colors which have at least one color component differ by 255. > > MRRHTest - since the scale factor comes from a dialog, we depend on > running this on a HiDPI display to fully test the hints? Could using > "scaled compatible images" allow testing this more definitively? Could you explain more what does it mean "scaled compatible images"? Thanks, Alexandr. > > MRRHTest - remove println before pushing? > > MRRHTest - probably shouldn't have a "right answer" for DEFAULT - it > should probably just pass if the operation doesn't throw an exception? > > ...jim > > > On 4/15/15 7:04 AM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8029339/webrev.08/ >> >> - SunGraphics2D is updated to calculate the resolution variant size >> according to the _BASE, _DPI_FIT, and _SIZE_FIT resolution rendering >> hint >> - MultiResolutionRenderingHints test is added >> >> Thanks, >> Alexandr. >> >> >> On 4/7/2015 1:02 PM, Jim Graham wrote: >>> This is an interesting suggestion that would let us keep the >>> implementation of the various hints centralized and simplify the >>> interface to the part of the mechanism that is most tied in to the >>> implementation specifics of the database of media variants - which is >>> housed in the MRI-implementing object. >>> >>> I'm not sure we ever identified any need to customize the logic of >>> "what size is needed for this render operation" beyond what we >>> expressed in the hints, and given that the platform defaults may not >>> be easy to express to an arbitrary implementation, it is probably >>> better to put that part of the logic in SG2D, controlled by the easy >>> to express hints and keep the current API both simple to implement and >>> flexible to use. Even if there was a need to customize that part of >>> the operation (the "what size is relevant to this rendering operation" >>> decision) beyond what the hints suggest, it would be inappropriate to >>> tie that in to the "find me media" aspect of the MRI interface >>> anyway. So, best to keep them separate and have the hints affect what >>> SG2D does and have the MRI focused on just storing (possibly creating) >>> and managing/finding the variants. >>> >>> ...jim >>> >>> On 4/1/15 6:46 AM, Alexander Scherbatiy wrote: >>>> On 3/27/2015 12:48 AM, Jim Graham wrote: >>>>> Hi Alexander, >>>> >>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.07/ >>>> I have updated the fix according to the comments except >>>> RenderingHints. >>>> >>>> RenderingHints are supposed to be set on Graphics2D and they have >>>> keys/values which are not relevant to the getResolutionVariant() >>>> method. >>>> Graphics objects chooses an alternative according to the set >>>> rendering hints. >>>> May be what SG2D should do just calculate dest image size for the >>>> given resolution variant hint (_BASE - base image size, _SIZE_FIT - >>>> including scale factor and graphics transform (Mac algorithm), >>>> _DPI_FIT - scaled according to the system DPI) and then pass them to >>>> the getResolutionVariant() method? >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> MRI.java: >>>>> >>>>> Who is the intended audience for the recommendation in the interface >>>>> to cache image variants? Are we asking the developers who call the >>>>> methods on the interface to cache the answers? That would be unwise >>>>> because the list of variants may change over time for some MRIs. Are >>>>> we speaking to the implementer? If so, then I think that it is >>>>> unnecessary to remind implementers of basic implementation >>>>> strategies like "cache complicated objects". >>>>> >>>>> How about this wording for the getRV() method? - "Gets a specific >>>>> image that is the best variant to represent this logical image at >>>>> the indicated size and screen resolution." >>>>> >>>>> Perhaps we should clarify in the doc comments for the dimension >>>>> arguments in getRV() that the dimensions are measured in pixels? >>>>> >>>>> line 56 - delete blank line between doc comment and method >>>>> declaration >>>>> >>>>> Also, it is probably overkill to document that the interface >>>>> getVariants() method returns an unmodifiable list. Responsible >>>>> implementations would probably use an unmodifiable list, but I don't >>>>> think it should be required by the interface. We do need to specify >>>>> that it isn't required to be modifiable so that a caller doesn't >>>>> expect to be able to modify it, but that is a looser spec. How >>>>> about "Gets a readable list of all resolution variants. Note that >>>>> many implementations might return an unmodifiable list."? >>>>> >>>>> AbstractMIR.java: >>>>> >>>>> "provides a default implementation for the MRI" or "provides default >>>>> implementations of several methods in the interface and the >>>>> class"? Actually, I'll note that it provides none of the >>>>> implementations of the MRI methods so maybe it should be "provides >>>>> default implementations of several methods for classes that >>>>> want to implement the interface"? >>>>> >>>>> In the doc example - wrap the list to make it unmodifiable >>>>> >>>>> The doc example could be made 2 or 3 lines shorter by simply >>>>> assuming the base image is in index 0 (it's just an example so I'm >>>>> not sure the flexibility needs to be a part of the example). >>>>> >>>>> getGraphics is allowed by the Image interface to return null. >>>>> Actually, the exact wording is that it can only be called for >>>>> "offscreen images" and a MRI is technically not "an offscreen >>>>> image". Perhaps we should return null here since modifying the base >>>>> image is unlikely to modify the variants and arguably it would be >>>>> required by the wording in the method docs (even if the base image >>>>> was an offscreen, the MRI produced from it stops being an offscreen)? >>>>> >>>>> Are all of the empty "@Inherit" comments needed? I thought >>>>> inheritance was the default? >>>>> >>>>> BaseMRI.java: >>>>> >>>>> "This class is [an] array-based implementation of the {AMRI} class" >>>>> (missing "an" and "the") >>>>> >>>>> We should probably include the comment about the sorting of the >>>>> images in the class comments as well as document that the algorithm >>>>> is a simple scan from the beginning for the first image large enough >>>>> (and default == last image). The algorithm also might not work very >>>>> well if the images are not monotonically both wider and taller. How >>>>> about adding this to the class comments: >>>>> >>>>> "The implementation will return the first image variant in the array >>>>> that is large enough to satisfy the rendering request. For best >>>>> effect the array of images should be sorted with each image being >>>>> both wider and taller than the previous image. The base image need >>>>> not be the first image in the array." >>>>> >>>>> getVariants() - you need to return an unmodifiable list. asList() >>>>> returns a list that "writes back" to the array. You need to use >>>>> Collections.unmodifiableList(Arrays.asList(array)). >>>>> >>>>> RenderingHints.java: >>>>> >>>>> Where do we process this hint? Don't we need to pass it to the >>>>> getVariant() method? >>>>> >>>>> I don't understand the hint values other than the one that always >>>>> uses the base image. Default I guess gives us the ability to use >>>>> the Mac algorithm of "next larger size" on Mac and "based on Screen >>>>> DPI" on Windows, but the 3rd value "ON" is so vague as to not have >>>>> any meaning. Perhaps we should just delete it, but then do we just >>>>> always do the Mac method? Or do we vaguely have our internal images >>>>> have a platform-specific method and the Abstract/Base classes just >>>>> do what they want with no control from the user? In FX we are also >>>>> still struggling with this issue and we may likely just do what the >>>>> Mac does in all cases, but perhaps AWT needs to "behave like the >>>>> platform" more? If we are going to have actual values, then we need >>>>> to have them do something, which means: >>>>> >>>>> - SG2D needs to track the hint just like we do the other hints that >>>>> affect our processing >>>>> - MRI.getVariant() needs to have the hint as an argument >>>>> - BaseMRI should probably do something with that hint >>>>> - hint values should include: >>>>> - ..._DEFAULT - implementation gets to decide >>>>> - ..._BASE - always use the base image >>>>> - ..._SIZE_FIT - Mac algorithm of smallest image that is big >>>>> enough >>>>> - ..._DPI_FIT - choose based on DPI of the screen, ignoring >>>>> transform >>>>> >>>>> line 978 - missing blank line between fields >>>>> >>>>> SG2D.java: >>>>> >>>>> - The interface says that you will be passing in the "logical DPI" >>>>> of the display, but here you are actually passing in the screen's >>>>> scale factor. >>>>> >>>>> BaseMRITest.java: >>>>> >>>>> - testBaseMRI also passes in a scale rather than a DPI to the MRI >>>>> method. >>>>> >>>>> - How does the modification test pass when the implementation >>>>> doesn't use unmodifiable lists? >>>>> >>>>> MRITest.java: >>>>> >>>>> - also uses scale rather than DPI in several places >>>>> >>>>> ...jim >>>>> >>>>> On 3/13/15 6:34 AM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the proposed API based on MultiresolutionImage >>>>>> interface: >>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.06/ >>>>>> >>>>>> - return unmodifiable list comment is added to the >>>>>> getResolutionVariants() method javadoc in MultiresolutionImage >>>>>> interface >>>>>> - base image size arguments are removed form the >>>>>> getResolutionVariant(...) method in MultiresolutionImage interface >>>>>> - BaseMultiResolutionImage class that allows to create a >>>>>> multi-resolution image based on resolution variant array is added >>>>>> - the test for the BaseMultiResolutionImage is added >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 2/14/2015 3:23 AM, Jim Graham wrote: >>>>>>> The second solution looks good. I'd make it standard practice >>>>>>> (perhaps even mentioned in the documentation) to return >>>>>>> unmodifiable >>>>>>> lists from the getVariants() method. The Collections class >>>>>>> provides >>>>>>> easy methods to create these lists, and it sends a clear message to >>>>>>> the caller that the list was provided for them to read, but not >>>>>>> write >>>>>>> to. Otherwise they may add a new image to the list you provided >>>>>>> them >>>>>>> and wonder why it wasn't showing up. Also, an unmodifiable list >>>>>>> can >>>>>>> be cached and reused for subsequent calls without having to >>>>>>> create a >>>>>>> new list every time. >>>>>>> >>>>>>> In getResolutionVariant() was there a reason why the base >>>>>>> dimensions >>>>>>> were provided as float? The destination dimensions make sense as >>>>>>> float since they could be the result of a scale, but the source >>>>>>> dimensions are typically getWidth/getHeight() on the base image. A >>>>>>> related question would be if they are needed at all, since the >>>>>>> implementation should probably already be aware of what the base >>>>>>> image >>>>>>> is and what its dimensions are. I'm guessing they are provided >>>>>>> because the implementation in SG2D already knows them and it >>>>>>> makes it >>>>>>> easier to forward the implementation on to a shared (static?) >>>>>>> method? >>>>>>> >>>>>>> With respect to default implementations, I take it that the >>>>>>> BaseMRI is >>>>>>> along the pattern that we see in Swing for Base classes. Would >>>>>>> it be >>>>>>> helpful to provide an implementation (in addition or instead) that >>>>>>> allows a developer to take a bunch of images and quickly make an >>>>>>> MRI >>>>>>> without having to override anything? The implementations of >>>>>>> getBaseImage() and getResolutionVariants() are pretty >>>>>>> straightforward >>>>>>> and a fairly reasonable default algorithm can be provided for >>>>>>> getRV(dimensions). This question is more of an idle question >>>>>>> for my >>>>>>> own curiosity than a stumbling block... >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 1/22/2015 6:49 AM, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> I have prepared two versions of the proposed API: >>>>>>>> >>>>>>>> I) Resolution variants are added directly to the Image: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/list/webrev.00 >>>>>>>> >>>>>>>> II) MultiResolutionImage interface is used: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.05 >>>>>>>> >>>>>>>> It could help to decide which way should be chosen for the the >>>>>>>> multi-resolution image support. >>>>>>>> >>>>>>>> Below are some comments: >>>>>>>> >>>>>>>> 1. High level goal: >>>>>>>> Introduce an API that allows to create and handle an image >>>>>>>> with >>>>>>>> resolution variants. >>>>>>>> >>>>>>>> 2. What is not subject of the provided API >>>>>>>> - Scale naming convention for high-resolution images >>>>>>>> - Providing pixel scale factor for the screen/window >>>>>>>> >>>>>>>> 3. Use cases >>>>>>>> 3.1 Loading and drawing high-resolution icons in IntelliJ IDEA >>>>>>>> A high-resolution image is loaded from resources and >>>>>>>> stored in >>>>>>>> JBHiDPIScaledImage class which is a subclass of the buffered >>>>>>>> image. >>>>>>>> The high-resolution image is used to create a disabled icon >>>>>>>> in the >>>>>>>> IconLoader.getDisabledIcon(icon) method. >>>>>>>> https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/openapi/util/IconLoader.java >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 3.2 Loading and drawing high-resolution icons in NetBeans >>>>>>>> NetBeans does not have support for the high-resolution icons >>>>>>>> loading. >>>>>>>> It loads an icon from the file system using >>>>>>>> Toolkit.getDefaultToolkit().getImage(url) method or from resources >>>>>>>> by ImageReader and store it in ToolTipImage class which is >>>>>>>> subclass of the buffered image. >>>>>>>> ImageUtilities.createDisabledIcon(icon) method creates a >>>>>>>> disabled >>>>>>>> icon by applying RGBImageFilter to the icon. >>>>>>>> http://hg.netbeans.org/main/file/97dcf49eb4a7/openide.util/src/org/openide/util/ImageUtilities.java >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 3.3 Loading system icons in JDK 1.8 >>>>>>>> JDK requests icons from the native system for system L&Fs >>>>>>>> and >>>>>>>> applies filters for them. >>>>>>>> See for example AquaUtils.generateLightenedImage() method: >>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e6f48c4fad38/src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 4. HiDPI support for Images on different OSes >>>>>>>> >>>>>>>> 4.1 Mac OS X >>>>>>>> Cocoa API contains NSImage that allows to work with image >>>>>>>> representations: add/remove/get all representations. >>>>>>>> It picks up an image with necessary resolution based on the >>>>>>>> screen backing store pixel scale factor and applied transforms. >>>>>>>> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/Reference/Reference.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 4.2 Linux >>>>>>>> GTK+ 3 API has gtkcssimagescaled lib (it seems that it >>>>>>>> is not >>>>>>>> public/stable) >>>>>>>> that parses the -gtk-scaled css property and draws a >>>>>>>> GtkCssImage >>>>>>>> according to the given scale factor. >>>>>>>> >>>>>>>> I have not found information about the HiDPI support in >>>>>>>> Xlib. >>>>>>>> >>>>>>>> 4.3 Windows >>>>>>>> I have only found the tutorial that suggests to select and >>>>>>>> draw a >>>>>>>> bitmap using the queried DPI >>>>>>>> and scale the coordinates for drawing a rectangular frame >>>>>>>> http://msdn.microsoft.com/en-us/library/dd464659%28v=vs.85%29.aspx >>>>>>>> >>>>>>>> Windows also provides the horizontal and vertical DPI of >>>>>>>> the >>>>>>>> desktop >>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316 >>>>>>>> >>>>>>>> 5. Pseudo API >>>>>>>> Below are some ways which illustrates how multi-resolution >>>>>>>> images >>>>>>>> can be created and used. >>>>>>>> >>>>>>>> 5.1 Resolution variants are stored directly in Image class. >>>>>>>> To query a resolution variant it needs to compare the >>>>>>>> resolution >>>>>>>> variant width/height >>>>>>>> with the requested high-resolution size. >>>>>>>> ------------ >>>>>>>> public abstract class Image { >>>>>>>> >>>>>>>> public void addResolutionVariant(Image image) {...} >>>>>>>> public List getResolutionVariants() {...} >>>>>>>> } >>>>>>>> ------------ >>>>>>>> // create a disabled image with resolution variants >>>>>>>> >>>>>>>> Image disabledImage = getDisabledImage(image); >>>>>>>> >>>>>>>> for (Image rv : image.getResolutionVariants()) { >>>>>>>> disabledImage.addResolutionVariant(getDisabledImage(rv)); >>>>>>>> } >>>>>>>> ------------ >>>>>>>> This approach requires that all resolution variants have been >>>>>>>> created even not of them are really used. >>>>>>>> >>>>>>>> 5.2 Resolution variants are stored in a separate object that >>>>>>>> allows to create them by demand. >>>>>>>> To query a resolution variant it needs to compare the >>>>>>>> resolution >>>>>>>> variant scale factor >>>>>>>> with the requested scale (that can include both screen DPI >>>>>>>> scale >>>>>>>> and applied transforms). >>>>>>>> ------------ >>>>>>>> public abstract class Image { >>>>>>>> >>>>>>>> public static interface ResolutionVariant { >>>>>>>> Image getImage(); >>>>>>>> float getScaleFactor(); >>>>>>>> } >>>>>>>> >>>>>>>> public void addResolutionVariant(ResolutionVariant >>>>>>>> resolutionVariant) {...} >>>>>>>> public List getResolutionVariants() >>>>>>>> {...} >>>>>>>> } >>>>>>>> ------------ >>>>>>>> // create a disabled image with resolution variants >>>>>>>> Image disabledImage = getDisabledImage(image); >>>>>>>> >>>>>>>> for (Image.ResolutionVariant rv : >>>>>>>> image.getResolutionVariants()) { >>>>>>>> disabledImage.addResolutionVariant(new >>>>>>>> Image.ResolutionVariant() { >>>>>>>> >>>>>>>> public Image getImage() { >>>>>>>> return getDisabledImage(rv.getImage()); >>>>>>>> } >>>>>>>> >>>>>>>> public float getScaleFactor() { >>>>>>>> return rv.getScaleFactor(); >>>>>>>> } >>>>>>>> }); >>>>>>>> } >>>>>>>> ------------ >>>>>>>> >>>>>>>> It does not have problem if a predefined set of images is >>>>>>>> provided >>>>>>>> (like image.png and image at 2x.png on the file system). >>>>>>>> This does not cover cases where a resolution variant can be >>>>>>>> created >>>>>>>> using the exact requested size (like loading icons from the native >>>>>>>> system). >>>>>>>> A resolution variant can be queried based on a scale >>>>>>>> factor and >>>>>>>> applied transforms. >>>>>>>> >>>>>>>> 5.3 The provided example allows to create a resolution >>>>>>>> variant >>>>>>>> using the requested high-resolution image size. >>>>>>>> ------------ >>>>>>>> public interface MultiResolutionImage { >>>>>>>> Image getResolutionVariant(float width, float height); >>>>>>>> } >>>>>>>> ------------ >>>>>>>> // create a multi-resolution image >>>>>>>> Image mrImage = new AbstractMultiResolutionImage() { >>>>>>>> >>>>>>>> public Image getResolutionVariant(float width, float >>>>>>>> height) { >>>>>>>> // create and return a resolution variant with >>>>>>>> exact >>>>>>>> requested width/height size >>>>>>>> } >>>>>>>> >>>>>>>> protected Image getBaseImage() { >>>>>>>> return baseImage; >>>>>>>> } >>>>>>>> }; >>>>>>>> ------------ >>>>>>>> // create a disabled image with resolution variants >>>>>>>> Image disabledImage = null; >>>>>>>> if (image instanceof MultiResolutionImage) { >>>>>>>> final MultiResolutionImage mrImage = >>>>>>>> (MultiResolutionImage) >>>>>>>> image; >>>>>>>> disabledImage = new AbstractMultiResolutionImage(){ >>>>>>>> >>>>>>>> public Image getResolutionVariant(float width, float >>>>>>>> height) { >>>>>>>> return >>>>>>>> getDisabledImage(mrImage.getResolutionVariant(width, height)); >>>>>>>> } >>>>>>>> >>>>>>>> protected Image getBaseImage() { >>>>>>>> return getDisabledImage(mrImage); >>>>>>>> } >>>>>>>> }; >>>>>>>> } else { >>>>>>>> disabledImage = getDisabledImage(image); >>>>>>>> } >>>>>>>> ------------ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>> >>>> >>> >> From alexandr.scherbatiy at oracle.com Tue Jul 21 14:49:29 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 21 Jul 2015 17:49:29 +0300 Subject: [9] Review request for 8130478 Reconsider "awt.toolkit" property usage in java.awt.Toolkit getDefaultToolkit() method Message-ID: <55AE5BF9.5090806@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8130478 webrev: http://cr.openjdk.java.net/~alexsch/8130478/webrev.00 The fix suggest to remove the "awt.toolkit" property mentioning from the public API because it is not so useful to use it in external programs since the peers refactoring. For more details see http://mail.openjdk.java.net/pipermail/awt-dev/2015-February/008924.html Thanks, Alexandr. From philip.race at oracle.com Tue Jul 21 18:24:48 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 21 Jul 2015 11:24:48 -0700 Subject: [9] Review request for 8130478 Reconsider "awt.toolkit" property usage in java.awt.Toolkit getDefaultToolkit() method In-Reply-To: <55AE5BF9.5090806@oracle.com> References: <55AE5BF9.5090806@oracle.com> Message-ID: <55AE8E70.9030409@oracle.com> Seems fine to me. Since this is specification visible you will need an approved CCC request before commiting the change. -phil. On 07/21/2015 07:49 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8130478 > webrev: http://cr.openjdk.java.net/~alexsch/8130478/webrev.00 > > The fix suggest to remove the "awt.toolkit" property mentioning from > the public API because > it is not so useful to use it in external programs since the peers > refactoring. > > For more details see > http://mail.openjdk.java.net/pipermail/awt-dev/2015-February/008924.html > > Thanks, > Alexandr. > From Sergey.Bylokhov at oracle.com Tue Jul 21 21:14:13 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Jul 2015 00:14:13 +0300 Subject: [9] Review request for 8130478 Reconsider "awt.toolkit" property usage in java.awt.Toolkit getDefaultToolkit() method In-Reply-To: <55AE8E70.9030409@oracle.com> References: <55AE5BF9.5090806@oracle.com> <55AE8E70.9030409@oracle.com> Message-ID: <55AEB625.5060601@oracle.com> +1 On 21.07.15 21:24, Phil Race wrote: > Seems fine to me. > Since this is specification visible you will need an approved CCC > request before commiting the change. > > -phil. > > On 07/21/2015 07:49 AM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8130478 >> webrev: http://cr.openjdk.java.net/~alexsch/8130478/webrev.00 >> >> The fix suggest to remove the "awt.toolkit" property mentioning >> from the public API because >> it is not so useful to use it in external programs since the peers >> refactoring. >> >> For more details see >> http://mail.openjdk.java.net/pipermail/awt-dev/2015-February/008924.html >> >> Thanks, >> Alexandr. >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 21 21:16:26 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Jul 2015 00:16:26 +0300 Subject: [9] Review request for 8130776: Remove EmbeddedFrame.requestFocusToEmbedder() method In-Reply-To: <55AE1C2E.5070807@oracle.com> References: <55AE1C2E.5070807@oracle.com> Message-ID: <55AEB6AA.1070803@oracle.com> Looks fine. On 21.07.15 13:17, Alexey Ivanov wrote: > Hello AWT team, > > Could you please review the following fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8130776 > webrev: http://cr.openjdk.java.net/~aivanov/8130776/jdk9/webrev.00/ > > Description: > Cleaning up the unused method. It was added under JDK-8056915 "Focus > lost in applet when browser window is minimized and restored". Later > the code has been changed, and this method, requestFocusToEmbedder(), > is not used any more. > > Thanks, > Alexey -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 21 21:26:13 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Jul 2015 00:26:13 +0300 Subject: [9] Review Request for 8131670: [TEST_BUG]Test java/awt/EventQueue/6980209/bug6980209.java fails on Linux In-Reply-To: <55A90528.9060002@oracle.com> References: <55A90528.9060002@oracle.com> Message-ID: <55AEB8F5.1040702@oracle.com> Hi, Semyon. Why you adds back the private logging to the test(it was removed recently)? Why Logger cannot be used? I suggest to set setAutoDelay+setAutoWaitForIdle in the main method also. On 17.07.15 16:37, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > bug: https://bugs.openjdk.java.net/browse/JDK-8131670 > webrev: http://cr.openjdk.java.net/~ssadetsky/8131670/webrev.00/ > > 1ms auto-delay was set to the robot to improve stability on Linux > platforms. > Also additional focus request procedure added to improve focus gain on > OEL7. > > --Semyon -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 21 21:28:47 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Jul 2015 00:28:47 +0300 Subject: [9] Review Request for 8041519: JVM crash on second DnD after modal dialog opened during Swing DnD operation In-Reply-To: <55A92CE0.70307@oracle.com> References: <55A92CE0.70307@oracle.com> Message-ID: <55AEB98F.2020204@oracle.com> Hi, Semyon. Is it possible to write a test which ignore all possible exceptions and will fail only in case of crash? On 17.07.15 19:27, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > bug: https://bugs.openjdk.java.net/browse/JDK-8041519 > webrev: http://cr.openjdk.java.net/~ssadetsky/8041519/webrev.00/ > > This is regression from JDK-6342381. When a modal dialog blocks drop > operation in progress state consequent mouse events clear the drop > context variables (this clearing was introduced by JDK-6342381). The > solution is to avoid clearing if drop operation is in progress. > Test scenario for this case would be too hard and unstable. Since the > fix is pretty simple I left it as noreg. > > --Semyon > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 21 21:32:08 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Jul 2015 00:32:08 +0300 Subject: [9] Review Request for 8130769: The new menu can't be shown on the menubar after clicking the "Add" button. In-Reply-To: <55A7D6EF.3040104@oracle.com> References: <55A7D6EF.3040104@oracle.com> Message-ID: <55AEBA58.6010309@oracle.com> Hi, Semyon. The fix looks good. On 16.07.15 19:08, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8130769 > webrev: http://cr.openjdk.java.net/~ssadetsky/8130769/webrev.00/ > > This is regression from JDK-7155957. Menu should be added to MenuBar > collection before the adding it to MenuBar's peer otherwise it is not > painted. > > --Semyon -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 21 22:01:53 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Jul 2015 01:01:53 +0300 Subject: [9] Review Request: 8067093 Fix windows-specific deprecation warnings in the java.desktop module Message-ID: <55AEC151.5010605@oracle.com> Hello. Please review the fix for jdk9. In the fix I replace the usage of the deprecated api in WListPeer. Most of the other cases in the bug description are related to getPeer(), which was already removed. The usage of deprecated constructor of Win32GraphicsConfig in its subclasses was not changed. Bug: https://bugs.openjdk.java.net/browse/JDK-8067093 Webrev can be found at: http://cr.openjdk.java.net/~serb/8067093/webrev.01 -- Best regards, Sergey. From philip.race at oracle.com Tue Jul 21 22:05:02 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 21 Jul 2015 15:05:02 -0700 Subject: [9] Review Request: 8067093 Fix windows-specific deprecation warnings in the java.desktop module In-Reply-To: <55AEC151.5010605@oracle.com> References: <55AEC151.5010605@oracle.com> Message-ID: <55AEC20E.7090308@oracle.com> +1 -phil. On 7/21/2015 3:01 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > > In the fix I replace the usage of the deprecated api in WListPeer. > Most of the other cases in the bug description are related to > getPeer(), which was already removed. > The usage of deprecated constructor of Win32GraphicsConfig in its > subclasses was not changed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067093 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8067093/webrev.01 > From alexandr.scherbatiy at oracle.com Wed Jul 22 07:51:43 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 22 Jul 2015 10:51:43 +0300 Subject: [9] Review Request for 8130769: The new menu can't be shown on the menubar after clicking the "Add" button. In-Reply-To: <55AEBA58.6010309@oracle.com> References: <55A7D6EF.3040104@oracle.com> <55AEBA58.6010309@oracle.com> Message-ID: <55AF4B8F.10409@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/22/2015 12:32 AM, Sergey Bylokhov wrote: > Hi, Semyon. > The fix looks good. > > On 16.07.15 19:08, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8130769 >> webrev: http://cr.openjdk.java.net/~ssadetsky/8130769/webrev.00/ >> >> This is regression from JDK-7155957. Menu should be added to MenuBar >> collection before the adding it to MenuBar's peer otherwise it is not >> painted. >> >> --Semyon > > From alexandr.scherbatiy at oracle.com Wed Jul 22 08:49:09 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 22 Jul 2015 11:49:09 +0300 Subject: [9] Review Request: 8067093 Fix windows-specific deprecation warnings in the java.desktop module In-Reply-To: <55AEC151.5010605@oracle.com> References: <55AEC151.5010605@oracle.com> Message-ID: <55AF5905.8040200@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/22/2015 1:01 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > > In the fix I replace the usage of the deprecated api in WListPeer. > Most of the other cases in the bug description are related to > getPeer(), which was already removed. > The usage of deprecated constructor of Win32GraphicsConfig in its > subclasses was not changed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067093 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8067093/webrev.01 > From alexander.zvegintsev at oracle.com Wed Jul 22 09:11:55 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 22 Jul 2015 12:11:55 +0300 Subject: [9] Review request for 8130478 Reconsider "awt.toolkit" property usage in java.awt.Toolkit getDefaultToolkit() method In-Reply-To: <55AEB625.5060601@oracle.com> References: <55AE5BF9.5090806@oracle.com> <55AE8E70.9030409@oracle.com> <55AEB625.5060601@oracle.com> Message-ID: <55AF5E5B.90302@oracle.com> +1 Thanks, Alexander. On 07/22/2015 12:14 AM, Sergey Bylokhov wrote: > +1 > On 21.07.15 21:24, Phil Race wrote: >> Seems fine to me. >> Since this is specification visible you will need an approved CCC >> request before commiting the change. >> >> -phil. >> >> On 07/21/2015 07:49 AM, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8130478 >>> webrev: http://cr.openjdk.java.net/~alexsch/8130478/webrev.00 >>> >>> The fix suggest to remove the "awt.toolkit" property mentioning >>> from the public API because >>> it is not so useful to use it in external programs since the peers >>> refactoring. >>> >>> For more details see >>> http://mail.openjdk.java.net/pipermail/awt-dev/2015-February/008924.html >>> >>> >>> Thanks, >>> Alexandr. >>> >> > > From alexander.zvegintsev at oracle.com Wed Jul 22 09:14:54 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 22 Jul 2015 12:14:54 +0300 Subject: [9] Review Request for 8130769: The new menu can't be shown on the menubar after clicking the "Add" button. In-Reply-To: <55AF4B8F.10409@oracle.com> References: <55A7D6EF.3040104@oracle.com> <55AEBA58.6010309@oracle.com> <55AF4B8F.10409@oracle.com> Message-ID: <55AF5F0E.4020607@oracle.com> +1 Thanks, Alexander. On 07/22/2015 10:51 AM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/22/2015 12:32 AM, Sergey Bylokhov wrote: >> Hi, Semyon. >> The fix looks good. >> >> On 16.07.15 19:08, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8130769 >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8130769/webrev.00/ >>> >>> This is regression from JDK-7155957. Menu should be added to MenuBar >>> collection before the adding it to MenuBar's peer otherwise it is >>> not painted. >>> >>> --Semyon >> >> > From alexander.zvegintsev at oracle.com Wed Jul 22 09:18:18 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 22 Jul 2015 12:18:18 +0300 Subject: [9] Review Request: 8067093 Fix windows-specific deprecation warnings in the java.desktop module In-Reply-To: <55AF5905.8040200@oracle.com> References: <55AEC151.5010605@oracle.com> <55AF5905.8040200@oracle.com> Message-ID: <55AF5FDA.100@oracle.com> +1 Thanks, Alexander. On 07/22/2015 11:49 AM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/22/2015 1:01 AM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk9. >> >> In the fix I replace the usage of the deprecated api in WListPeer. >> Most of the other cases in the bug description are related to >> getPeer(), which was already removed. >> The usage of deprecated constructor of Win32GraphicsConfig in its >> subclasses was not changed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067093 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8067093/webrev.01 >> > From Sergey.Bylokhov at oracle.com Wed Jul 22 12:58:18 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Jul 2015 15:58:18 +0300 Subject: [9] Review Request for 8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9 In-Reply-To: <55AE1397.4070709@oracle.com> References: <55AE1397.4070709@oracle.com> Message-ID: <55AF936A.8020404@oracle.com> Hi, Semyon. NPE occurs when we initialize KFM on the Toolkit thread, but this is only a part of the bug, another issue is that we will use cached keystrokes on the toolkit thread. But this keystrokes is bound to the appcontext so we should not use objects which connect to the application on the toolkit thread. This code should be carefully checked to remove appcontext related stuff from the toolkit thread. On 21.07.15 12:40, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > bug: https://bugs.openjdk.java.net/browse/JDK-8130895 > webrev: http://cr.openjdk.java.net/~ssadetsky/8130895/webrev.00/ > > realSync() used in the test's TestRunnable class causes events come to > the XAWT event loop but there are no any windows created at the moment > and the system application context is not initialized. This results in > attempt to create the KeyboardFocusManager instance on the XAWT's > thread group during the XEvent dispatching. That in its turn causes NPE. > The solution: since KeyboardFocusManager should never be instantiated > in the toolkit event loop, the corresponding check was added. > > --Semyon -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Wed Jul 22 13:44:38 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 22 Jul 2015 16:44:38 +0300 Subject: [9] Review request for 8132123 MultiResolutionCachedImage unnecessarily creates base image to get its size Message-ID: <55AF9E46.8000901@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8132123 webrev: http://cr.openjdk.java.net/~alexsch/8132123/webrev.00 The baseImageWidth/Height and Image.UndefinedProperty are returned to not trigger base image creation in the MultiResolutionCachedImage. Thanks, Alexandr. From anton.tarasov at oracle.com Wed Jul 22 14:06:02 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 22 Jul 2015 17:06:02 +0300 Subject: [9] Review request for 8130776: Remove EmbeddedFrame.requestFocusToEmbedder() method In-Reply-To: <55AE1C2E.5070807@oracle.com> References: <55AE1C2E.5070807@oracle.com> Message-ID: <55AFA34A.4080403@oracle.com> Hi Alexey, Looks fine to me. Regards, Anton. On 21.07.2015 13:17, Alexey Ivanov wrote: > Hello AWT team, > > Could you please review the following fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8130776 > webrev: http://cr.openjdk.java.net/~aivanov/8130776/jdk9/webrev.00/ > > Description: > Cleaning up the unused method. It was added under JDK-8056915 "Focus lost in applet when browser > window is minimized and restored". Later the code has been changed, and this method, > requestFocusToEmbedder(), is not used any more. > > Thanks, > Alexey From semyon.sadetsky at oracle.com Wed Jul 22 14:09:25 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 22 Jul 2015 17:09:25 +0300 Subject: [9] Review Request for 8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9 In-Reply-To: <55AF936A.8020404@oracle.com> References: <55AE1397.4070709@oracle.com> <55AF936A.8020404@oracle.com> Message-ID: <55AFA415.8080505@oracle.com> Hi Sergey, From the process point of view it's better to fix the issue you've found in another ticket. The failed test is not related to the keystrokes caching. So I suggest to push this fix as it is and file another JIRA for the keystrokes. --Semyon On 7/22/2015 3:58 PM, Sergey Bylokhov wrote: > Hi, Semyon. > NPE occurs when we initialize KFM on the Toolkit thread, but this is > only a part of the bug, another issue is that we will use cached > keystrokes on the toolkit thread. But this keystrokes is bound to the > appcontext so we should not use objects which connect to the > application on the toolkit thread. This code should be carefully > checked to remove appcontext related stuff from the toolkit thread. > > On 21.07.15 12:40, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> bug: https://bugs.openjdk.java.net/browse/JDK-8130895 >> webrev: http://cr.openjdk.java.net/~ssadetsky/8130895/webrev.00/ >> >> realSync() used in the test's TestRunnable class causes events come >> to the XAWT event loop but there are no any windows created at the >> moment and the system application context is not initialized. This >> results in attempt to create the KeyboardFocusManager instance on the >> XAWT's thread group during the XEvent dispatching. That in its turn >> causes NPE. >> The solution: since KeyboardFocusManager should never be instantiated >> in the toolkit event loop, the corresponding check was added. >> >> --Semyon > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.tarasov at oracle.com Wed Jul 22 14:24:59 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 22 Jul 2015 17:24:59 +0300 Subject: [9] Review Request: 8067093 Fix windows-specific deprecation warnings in the java.desktop module In-Reply-To: <55AEC151.5010605@oracle.com> References: <55AEC151.5010605@oracle.com> Message-ID: <55AFA7BB.3000009@oracle.com> Looks fine. Regards, Anton. On 22.07.2015 1:01, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > > In the fix I replace the usage of the deprecated api in WListPeer. Most of the other cases in the > bug description are related to getPeer(), which was already removed. > The usage of deprecated constructor of Win32GraphicsConfig in its subclasses was not changed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067093 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8067093/webrev.01 > From alexander.zvegintsev at oracle.com Wed Jul 22 16:07:01 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 22 Jul 2015 19:07:01 +0300 Subject: [9] Review request for 8131752 [Regression] Test java/awt/GraphicsDevice/CheckDisplayModes.java fails Message-ID: <55AFBFA5.5040709@oracle.com> Hello, Please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8131752/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8131752 This fix simply restores fullscreen windows check. Actually fullscreen is not necessary to change display mode, but since I am planning to backport it to 8u66 it is too risky to change behavior. It should be reconsidered along with 8022810 [0]. [0] https://bugs.openjdk.java.net/browse/JDK-8022810 Cannot list all the available display modes on Ubuntu linux in case of two screen devices -- Thanks, Alexander. From Sergey.Bylokhov at oracle.com Wed Jul 22 17:11:08 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Jul 2015 20:11:08 +0300 Subject: [9] Review request for 8131752 [Regression] Test java/awt/GraphicsDevice/CheckDisplayModes.java fails In-Reply-To: <55AFBFA5.5040709@oracle.com> References: <55AFBFA5.5040709@oracle.com> Message-ID: <55AFCEAC.9040402@oracle.com> The fix looks fine. It is unclear why in previous fix the check for fullscreen window was removed, but the check for fullscreen support not. On 22.07.15 19:07, Alexander Zvegintsev wrote: > Hello, > > Please review the fix > http://cr.openjdk.java.net/~azvegint/jdk/9/8131752/00/ > for the issue > https://bugs.openjdk.java.net/browse/JDK-8131752 > > This fix simply restores fullscreen windows check. Actually fullscreen > is not necessary to change display mode, > but since I am planning to backport it to 8u66 it is too risky to > change behavior. It should be reconsidered along with 8022810 [0]. > > [0] https://bugs.openjdk.java.net/browse/JDK-8022810 Cannot list all > the available display modes on Ubuntu linux in case of two screen devices > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Jul 22 17:20:29 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Jul 2015 20:20:29 +0300 Subject: [9] Review Request for 8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9 In-Reply-To: <55AFA415.8080505@oracle.com> References: <55AE1397.4070709@oracle.com> <55AF936A.8020404@oracle.com> <55AFA415.8080505@oracle.com> Message-ID: <55AFD0DD.1000508@oracle.com> It is unclear why it is unrelated, the stack trace from the bug: java.lang.ExceptionInInitializerError at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.awt.AWTAccessor.getKeyboardFocusManagerAccessor(AWTAccessor.java:966) at sun.awt.KeyboardFocusManagerPeerImpl.(KeyboardFocusManagerPeerImpl.java:46) at sun.awt.X11.XToolkit.run(XToolkit.java:611) at sun.awt.X11.XToolkit.run(XToolkit.java:550) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NullPointerException at java.awt.AWTKeyStroke.getCachedStroke(AWTKeyStroke.java:255) at java.awt.AWTKeyStroke.getAWTKeyStroke(AWTKeyStroke.java:394) at java.awt.KeyboardFocusManager.(KeyboardFocusManager.java:332) ... 6 more On 22.07.15 17:09, Semyon Sadetsky wrote: > Hi Sergey, > > From the process point of view it's better to fix the issue you've > found in another ticket. The failed test is not related to the > keystrokes caching. > So I suggest to push this fix as it is and file another JIRA for the > keystrokes. > > --Semyon > > > On 7/22/2015 3:58 PM, Sergey Bylokhov wrote: >> Hi, Semyon. >> NPE occurs when we initialize KFM on the Toolkit thread, but this is >> only a part of the bug, another issue is that we will use cached >> keystrokes on the toolkit thread. But this keystrokes is bound to the >> appcontext so we should not use objects which connect to the >> application on the toolkit thread. This code should be carefully >> checked to remove appcontext related stuff from the toolkit thread. >> >> On 21.07.15 12:40, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8130895 >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8130895/webrev.00/ >>> >>> realSync() used in the test's TestRunnable class causes events come >>> to the XAWT event loop but there are no any windows created at the >>> moment and the system application context is not initialized. This >>> results in attempt to create the KeyboardFocusManager instance on >>> the XAWT's thread group during the XEvent dispatching. That in its >>> turn causes NPE. >>> The solution: since KeyboardFocusManager should never be >>> instantiated in the toolkit event loop, the corresponding check was >>> added. >>> >>> --Semyon >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Jul 22 17:23:40 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Jul 2015 20:23:40 +0300 Subject: [9] Review request for 8132123 MultiResolutionCachedImage unnecessarily creates base image to get its size In-Reply-To: <55AF9E46.8000901@oracle.com> References: <55AF9E46.8000901@oracle.com> Message-ID: <55AFD19C.9040204@oracle.com> Hi, Alexander. Why you did update of bugid in the test, but did not update the test itself? Did the test fail before the fix? On 22.07.15 16:44, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8132123 > webrev: http://cr.openjdk.java.net/~alexsch/8132123/webrev.00 > > The baseImageWidth/Height and Image.UndefinedProperty are returned > to not trigger base image creation in the MultiResolutionCachedImage. > > > Thanks, > Alexandr. > -- Best regards, Sergey. From peter.brunet at oracle.com Wed Jul 22 23:53:39 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 22 Jul 2015 18:53:39 -0500 Subject: RfR JDK-8077707 jdk9 b58 cannot run any graphical application with JAWS running Message-ID: <55B02D03.7050907@oracle.com> Please review this patch which cures a problem that appears since 9 b58 when the compiler was switched to VS2013 and as a result turned on the High Entropy Virtual Addresses bit in the executable header when running on Win 8.1. With the high-entropy 64-bit address space layout randomization option enabled, all memory addresses in a 64-bit app are guaranteed to be above 4gb. This means that if any module has latent pointer truncation issues in 64-bit builds, these issues will manifest themselves when this flag is set. The fix is to change the wparam type from UINT to WPARAM and the lparam type from LONG to LPARAM. Using UINT/LONG would cause truncation in the upper 32 bits of wparam/lparam. http://cr.openjdk.java.net/~ptbrunet/JDK-8077707/webrev.00/ Thanks, Pete From semyon.sadetsky at oracle.com Thu Jul 23 04:38:05 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 23 Jul 2015 07:38:05 +0300 Subject: [9] Review Request for 8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9 In-Reply-To: <55AFD0DD.1000508@oracle.com> References: <55AE1397.4070709@oracle.com> <55AF936A.8020404@oracle.com> <55AFA415.8080505@oracle.com> <55AFD0DD.1000508@oracle.com> Message-ID: <55B06FAD.9050503@oracle.com> Hi Sergey, As you said there are 2 issues here. The first is about KeyboardFocusManager initialization in the main event loop. And the second about initialization of the KeyboardManagerManager itself where keystrokes are shared between contexts. Or do you mean if I remove the keystrokes sharing then the KeyboardFocusManager can be initialized in the toolkit thread? Is that what you mean? --Semyon On 7/22/2015 8:20 PM, Sergey Bylokhov wrote: > It is unclear why it is unrelated, the stack trace from the bug: > > java.lang.ExceptionInInitializerError > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at > sun.awt.AWTAccessor.getKeyboardFocusManagerAccessor(AWTAccessor.java:966) > at > sun.awt.KeyboardFocusManagerPeerImpl.(KeyboardFocusManagerPeerImpl.java:46) > at sun.awt.X11.XToolkit.run(XToolkit.java:611) > at sun.awt.X11.XToolkit.run(XToolkit.java:550) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at java.awt.AWTKeyStroke.getCachedStroke(AWTKeyStroke.java:255) > at java.awt.AWTKeyStroke.getAWTKeyStroke(AWTKeyStroke.java:394) > at java.awt.KeyboardFocusManager.(KeyboardFocusManager.java:332) > ... 6 more > > > On 22.07.15 17:09, Semyon Sadetsky wrote: >> Hi Sergey, >> >> From the process point of view it's better to fix the issue you've >> found in another ticket. The failed test is not related to the >> keystrokes caching. >> So I suggest to push this fix as it is and file another JIRA for the >> keystrokes. >> >> --Semyon >> >> >> On 7/22/2015 3:58 PM, Sergey Bylokhov wrote: >>> Hi, Semyon. >>> NPE occurs when we initialize KFM on the Toolkit thread, but this is >>> only a part of the bug, another issue is that we will use cached >>> keystrokes on the toolkit thread. But this keystrokes is bound to >>> the appcontext so we should not use objects which connect to the >>> application on the toolkit thread. This code should be carefully >>> checked to remove appcontext related stuff from the toolkit thread. >>> >>> On 21.07.15 12:40, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Please review fix for JDK9: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8130895 >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8130895/webrev.00/ >>>> >>>> realSync() used in the test's TestRunnable class causes events come >>>> to the XAWT event loop but there are no any windows created at the >>>> moment and the system application context is not initialized. This >>>> results in attempt to create the KeyboardFocusManager instance on >>>> the XAWT's thread group during the XEvent dispatching. That in its >>>> turn causes NPE. >>>> The solution: since KeyboardFocusManager should never be >>>> instantiated in the toolkit event loop, the corresponding check was >>>> added. >>>> >>>> --Semyon >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jul 23 10:47:33 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 23 Jul 2015 13:47:33 +0300 Subject: [9] Review request for 8131752 [Regression] Test java/awt/GraphicsDevice/CheckDisplayModes.java fails In-Reply-To: <55AFBFA5.5040709@oracle.com> References: <55AFBFA5.5040709@oracle.com> Message-ID: <55B0C645.4040805@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/22/2015 7:07 PM, Alexander Zvegintsev wrote: > Hello, > > Please review the fix > http://cr.openjdk.java.net/~azvegint/jdk/9/8131752/00/ > for the issue > https://bugs.openjdk.java.net/browse/JDK-8131752 > > This fix simply restores fullscreen windows check. Actually fullscreen > is not necessary to change display mode, > but since I am planning to backport it to 8u66 it is too risky to > change behavior. It should be reconsidered along with 8022810 [0]. > > [0] https://bugs.openjdk.java.net/browse/JDK-8022810 Cannot list all > the available display modes on Ubuntu linux in case of two screen devices > From alexey.ivanov at oracle.com Thu Jul 23 14:09:49 2015 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 23 Jul 2015 17:09:49 +0300 Subject: [8u-dev] Review request for 8130776: Remove EmbeddedFrame.requestFocusToEmbedder() method Message-ID: <55B0F5AD.6030109@oracle.com> Hello AWT team, Could you please review the backport of JDK-8130776 to jdk8u-dev: http://cr.openjdk.java.net/~aivanov/8130776/jdk8/webrev.00/ The patch from JDK9 does not apply cleanly because of different mechanism to access peer in WEmbeddedFrame.java. Logically there are no changes. bug: https://bugs.openjdk.java.net/browse/JDK-8130776 jdk9 webrev: http://cr.openjdk.java.net/~aivanov/8130776/jdk9/webrev.00/ jdk9 review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2015-July/009667.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/207a6ebae49d Thanks, Alexey From anton.tarasov at oracle.com Thu Jul 23 14:14:45 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 23 Jul 2015 17:14:45 +0300 Subject: [8u-dev] Review request for 8130776: Remove EmbeddedFrame.requestFocusToEmbedder() method In-Reply-To: <55B0F5AD.6030109@oracle.com> References: <55B0F5AD.6030109@oracle.com> Message-ID: <55B0F6D5.9070905@oracle.com> Looks fine to me. Regards, Anton. On 23.07.2015 17:09, Alexey Ivanov wrote: > Hello AWT team, > > Could you please review the backport of JDK-8130776 to jdk8u-dev: > http://cr.openjdk.java.net/~aivanov/8130776/jdk8/webrev.00/ > > > The patch from JDK9 does not apply cleanly because of different mechanism to access peer in > WEmbeddedFrame.java. Logically there are no changes. > > bug: https://bugs.openjdk.java.net/browse/JDK-8130776 > jdk9 webrev: http://cr.openjdk.java.net/~aivanov/8130776/jdk9/webrev.00/ > jdk9 review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2015-July/009667.html > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/207a6ebae49d > > Thanks, > Alexey From alexander.zvegintsev at oracle.com Thu Jul 23 16:37:02 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 23 Jul 2015 19:37:02 +0300 Subject: [9] Review request for 8014212: Robot captures black screen Message-ID: <55B1182E.7060706@oracle.com> Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8014212/00 for the issue https://bugs.openjdk.java.net/browse/JDK-8014212 This fix trying to use gdk_pixbuf_get_from_drawable () [0] to capture screenshot(basic image data handling could be found here[1]). If it fails then we come back to our old method. Translucency support[1] is also covered by this fix, but there is another issue with toFront() call which blocks passing of a JCK test. P.S. On Solaris 11 windows appears with animation, thus sleep() call was added to work around this. [0] https://developer.gnome.org/gdk2/stable/gdk2-Pixbufs.html#gdk-pixbuf-get-from-drawable [1] https://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-The-GdkPixbuf-Structure.html#image-data [2] https://bugs.openjdk.java.net/browse/JDK-7043845 Robot should be able take screenshots with translucent windows -- Thanks, Alexander. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Thu Jul 23 17:25:01 2015 From: james.graham at oracle.com (Jim Graham) Date: Thu, 23 Jul 2015 10:25:01 -0700 Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: <55AE5A22.7040603@oracle.com> References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com> <5502E763.7080008@oracle.com> <55147EBE.3010002@oracle.com> <551BF6AC.8000705@oracle.com> <5523AB20.30704@oracle.com> <552E7006.70101@oracle.com> <55A44B62.7070703@oracle.com> <55AE5A22.7040603@oracle.com> Message-ID: <55B1236D.4020608@oracle.com> Hi Alexandr, On 7/21/15 7:41 AM, Alexander Scherbatiy wrote: > > Hello Jim, > > Thank your for the review. > > Could you review the updated fix there the suggested comments are > updated: > http://cr.openjdk.java.net/~alexsch/8029339/webrev.09/ Minor comments embedded below. > On 7/14/2015 2:36 AM, Jim Graham wrote: >> AbstractMRI - getGraphics() should include "getGraphics() not >> supported on Multi-Resolution Images" as the exception description text. AbstractMRI - the getGraphics() description string contains an embedded '\n' and an embedded '\"', are those typos? >> BaseMRI - class comment - "The implementation will return the first >> ... satisfy the rendering request." Add another sentence right there >> "The last image in the array will be returned if no suitable image is >> found that is larger than the rendering request." BaseMRI - whoops, my bad. "that is larger than" should probably be "that is as large as" to match the <= comparison >> SG2D.getResolutionVariant - using destRegionWH to calculate >> destImageWH can involve a lot of "do some math and then later have >> additional code undo it". Would it be faster to just compute >> destImageWH directly, as in: >> >> float destImageWidth, destImageHeight; >> >> if (BASE) { >> destImageWH = srcWH; >> } else if (DPI) { >> destImageWH = (float) abs(srcWH * devScale); >> } else { >> double destRegionWidth, destRegionHeight; >> if (type) { >> ... >> } >> destImageWH = (float) abs(srcWH * destRegionWH / swh); >> } >> Image rv = img.getRV(destImageWH); For the BASE and DPI_FIT cases shouldn't you use srcWidth,srcHeight instead of sw,sh? The sw,sh are affected by sub-image parameters, but srcWidth,srcHeight are literally the size of the original image, which is what you want to search the MRI for. The sw,sh should only be used to scale the srcWidth in the "else" clause - as in "srcWidth * destRegionWidth / sw". >> Is there intent to have the default case be mapped to DPI_FIT for >> Windows? > I think yes. I didn't see where this was being done - is that a TBD follow-on fix or did I miss a default somewhere? >> MRRHTest - why not render to a BufferedImage and avoid Robot? Could it >> tap into internal APIs to create a BImg/compatibleImage with a given >> devScale? > > The DPI_FIT test includes case there a graphics transform is > identity but the device configuration transform has scale 2. > There should be a way to set scale for the device configuration > transform; Ah yes, DPI_FIT needs a default transform. Also, without a way to manually create a device with a transform, that means that DPI_FIT is only successfully tested if the tests are run on a HiDPI machine, right? >> MRRHTest - why allow up to delta=50 on the comparison? > It is just for monitors that are calibrated on Mac OS X and they > colors are different from that which was set. The test uses colors which > have at least one color component differ by 255. Another issue that might go away if we could use BImg instead of robot. >> MRRHTest - since the scale factor comes from a dialog, we depend on >> running this on a HiDPI display to fully test the hints? Could using >> "scaled compatible images" allow testing this more definitively? > > Could you explain more what does it mean "scaled compatible images"? I seem to recall that there is a mechanism in there to create backbuffer images for swing that record the fact that they are scaled. I forget how this is done, but I'm wondering if it could be used to run all of this test code in a simulated scale environment rather than using the actual configurations that AWT creates for the current system. ...jim From semyon.sadetsky at oracle.com Thu Jul 23 18:21:17 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 23 Jul 2015 21:21:17 +0300 Subject: [9] Review Request for 8130471: [Regression] Test java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java fails Message-ID: <55B1309D.1050606@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8130471 webrev: http://cr.openjdk.java.net/~ssadetsky/8130471/webrev.00/ This is a regression from 8041470 in which mouse event modifiers was changed for all wheel events including button click event. That caused wrong modifiers for buttons 4 and 5 press/release/click mouse events. The solution is to restore modifiers for click events keeping 8041470 changes for scroll events. --Semyon From Sergey.Bylokhov at oracle.com Fri Jul 24 04:08:21 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 24 Jul 2015 07:08:21 +0300 Subject: [9] Review request for 8014212: Robot captures black screen In-Reply-To: <55B1182E.7060706@oracle.com> References: <55B1182E.7060706@oracle.com> Message-ID: <55B1BA35.8010501@oracle.com> Hi, Alexander. I am not sure that an assumption that we should not make a screen shot if the x and y are negative is correct. I guess that we should take a screenshot of the intersection of the requested area and the display. Can you also check this comment in the TranslucentJAppletTest.java: 106 // unfortunately, robot.getPixelColor() doesn't work for some unknown reason 107 // Color newColor2 = r.getPixelColor(200, 200); On 23.07.15 19:37, Alexander Zvegintsev wrote: > Hello, > > please review the fix > http://cr.openjdk.java.net/~azvegint/jdk/9/8014212/00 > for the issue > https://bugs.openjdk.java.net/browse/JDK-8014212 > > This fix trying to use gdk_pixbuf_get_from_drawable () [0] to capture > screenshot(basic image data handling could be found here[1]). > If it fails then we come back to our old method. > Translucency support[1] is also covered by this fix, but there is > another issue with toFront() call which blocks passing of a JCK test. > > P.S. On Solaris 11 windows appears with animation, thus sleep() call > was added to work around this. > > [0] > https://developer.gnome.org/gdk2/stable/gdk2-Pixbufs.html#gdk-pixbuf-get-from-drawable > [1] > https://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-The-GdkPixbuf-Structure.html#image-data > [2] https://bugs.openjdk.java.net/browse/JDK-7043845 Robot should be > able take screenshots with translucent windows > > -- > Thanks, > > Alexander. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Jul 24 11:10:58 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 24 Jul 2015 14:10:58 +0300 Subject: [9] Review request for 8132123 MultiResolutionCachedImage unnecessarily creates base image to get its size In-Reply-To: <55AFD19C.9040204@oracle.com> References: <55AF9E46.8000901@oracle.com> <55AFD19C.9040204@oracle.com> Message-ID: <55B21D42.7040006@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8132123/webrev.01 There is one more place where AquaSplitPaneDividerUI requests scaled smooth image. It is better to allow the native system to scale the image. So I updated the getScaledInstance(width, height, hints) method in the MultiResolutionCachedImage. It also allows to avoid base image creation. On 7/22/2015 8:23 PM, Sergey Bylokhov wrote: > Hi, Alexander. > Why you did update of bugid in the test, but did not update the test > itself? Did the test fail before the fix? There are limited number of loaded native images and they are immediately cached so it is hard to write a test which calculates the excessive memory usage using only public API. I added the new test that uses the internal MultiResolutionCachedImage class directly. Thanks, Alexandr. > > On 22.07.15 16:44, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8132123 >> webrev: http://cr.openjdk.java.net/~alexsch/8132123/webrev.00 >> >> The baseImageWidth/Height and Image.UndefinedProperty are returned >> to not trigger base image creation in the MultiResolutionCachedImage. >> >> >> Thanks, >> Alexandr. >> > > From alexandr.scherbatiy at oracle.com Fri Jul 24 14:50:50 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 24 Jul 2015 17:50:50 +0300 Subject: [9] Review request for 8131339[macosx] setMaximizedBounds() doesn't work for undecorated Frame Message-ID: <55B250CA.3070404@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8131339 webrev: http://cr.openjdk.java.net/~alexsch/8131339/webrev.00 The maximize() method is updated for an undecorated Frame. Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Fri Jul 24 15:05:20 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 24 Jul 2015 18:05:20 +0300 Subject: RfR JDK-8077707 jdk9 b58 cannot run any graphical application with JAWS running In-Reply-To: <55B02D03.7050907@oracle.com> References: <55B02D03.7050907@oracle.com> Message-ID: <55B25430.4080308@oracle.com> Looks fine. On 23.07.15 2:53, Pete Brunet wrote: > Please review this patch which cures a problem that appears since 9 b58 > when the compiler was switched to VS2013 and as a result turned on the > High Entropy Virtual Addresses bit in the executable header when running > on Win 8.1. > > With the high-entropy 64-bit address space layout randomization option > enabled, all memory addresses in a 64-bit app are guaranteed to be above > 4gb. This means that if any module has latent pointer truncation issues > in 64-bit builds, these issues will manifest themselves when this flag > is set. > > The fix is to change the wparam type from UINT to WPARAM and the lparam > type from LONG to LPARAM. > > Using UINT/LONG would cause truncation in the upper 32 bits of > wparam/lparam. > > http://cr.openjdk.java.net/~ptbrunet/JDK-8077707/webrev.00/ > > Thanks, Pete -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri Jul 24 15:31:16 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 24 Jul 2015 18:31:16 +0300 Subject: RfR JDK-8077707 jdk9 b58 cannot run any graphical application with JAWS running In-Reply-To: <55B25430.4080308@oracle.com> References: <55B02D03.7050907@oracle.com> <55B25430.4080308@oracle.com> Message-ID: <55B25A44.9000202@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/24/2015 6:05 PM, Sergey Bylokhov wrote: > Looks fine. > > On 23.07.15 2:53, Pete Brunet wrote: >> Please review this patch which cures a problem that appears since 9 b58 >> when the compiler was switched to VS2013 and as a result turned on the >> High Entropy Virtual Addresses bit in the executable header when running >> on Win 8.1. >> >> With the high-entropy 64-bit address space layout randomization option >> enabled, all memory addresses in a 64-bit app are guaranteed to be above >> 4gb. This means that if any module has latent pointer truncation issues >> in 64-bit builds, these issues will manifest themselves when this flag >> is set. >> >> The fix is to change the wparam type from UINT to WPARAM and the lparam >> type from LONG to LPARAM. >> >> Using UINT/LONG would cause truncation in the upper 32 bits of >> wparam/lparam. >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8077707/webrev.00/ >> >> Thanks, Pete > > From Sergey.Bylokhov at oracle.com Fri Jul 24 15:35:48 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 24 Jul 2015 18:35:48 +0300 Subject: [9] Review request for 8131339[macosx] setMaximizedBounds() doesn't work for undecorated Frame In-Reply-To: <55B250CA.3070404@oracle.com> References: <55B250CA.3070404@oracle.com> Message-ID: <55B25B54.5030505@oracle.com> The fix looks fine. Please take a look to related regression of 8065739. The problem occurs when you maximize Netbeans on osx 10.10 to the fullscreem mode, then the upper side of the window is broken. On 24.07.15 17:50, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8131339 > webrev: http://cr.openjdk.java.net/~alexsch/8131339/webrev.00 > > The maximize() method is updated for an undecorated Frame. > > Thanks, > Alexandr. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Jul 24 16:00:13 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 24 Jul 2015 19:00:13 +0300 Subject: [9] Review request for 8132123 MultiResolutionCachedImage unnecessarily creates base image to get its size In-Reply-To: <55B21D42.7040006@oracle.com> References: <55AF9E46.8000901@oracle.com> <55AFD19C.9040204@oracle.com> <55B21D42.7040006@oracle.com> Message-ID: <55B2610D.5020007@oracle.com> On 24.07.15 14:10, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8132123/webrev.01 > > There is one more place where AquaSplitPaneDividerUI requests scaled > smooth image. It is better to allow the native system to scale the image. > So I updated the getScaledInstance(width, height, hints) method in > the MultiResolutionCachedImage. It also allows to avoid base image > creation. Why did you change getProperty in the latest version? > > On 7/22/2015 8:23 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Why you did update of bugid in the test, but did not update the test >> itself? Did the test fail before the fix? > > There are limited number of loaded native images and they are > immediately cached so it is hard to write a test which calculates the > excessive memory usage using only public API. > > I added the new test that uses the internal > MultiResolutionCachedImage class directly. > > Thanks, > Alexandr. >> >> On 22.07.15 16:44, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8132123 >>> webrev: http://cr.openjdk.java.net/~alexsch/8132123/webrev.00 >>> >>> The baseImageWidth/Height and Image.UndefinedProperty are returned >>> to not trigger base image creation in the MultiResolutionCachedImage. >>> >>> >>> Thanks, >>> Alexandr. >>> >> >> > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri Jul 24 16:20:17 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 24 Jul 2015 19:20:17 +0300 Subject: [9] Review request for 8132123 MultiResolutionCachedImage unnecessarily creates base image to get its size In-Reply-To: <55B2610D.5020007@oracle.com> References: <55AF9E46.8000901@oracle.com> <55AFD19C.9040204@oracle.com> <55B21D42.7040006@oracle.com> <55B2610D.5020007@oracle.com> Message-ID: <55B265C1.70009@oracle.com> On 7/24/2015 7:00 PM, Sergey Bylokhov wrote: > On 24.07.15 14:10, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8132123/webrev.01 >> >> There is one more place where AquaSplitPaneDividerUI requests scaled >> smooth image. It is better to allow the native system to scale the >> image. >> So I updated the getScaledInstance(width, height, hints) method in >> the MultiResolutionCachedImage. It also allows to avoid base image >> creation. > Why did you change getProperty in the latest version? ImageIcon requests comment property from the image and it also leads to unnecessary base image creation. Thanks, Alexandr. >> >> On 7/22/2015 8:23 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> Why you did update of bugid in the test, but did not update the test >>> itself? Did the test fail before the fix? >> >> There are limited number of loaded native images and they are >> immediately cached so it is hard to write a test which calculates the >> excessive memory usage using only public API. >> >> I added the new test that uses the internal >> MultiResolutionCachedImage class directly. >> >> Thanks, >> Alexandr. >>> >>> On 22.07.15 16:44, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132123 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8132123/webrev.00 >>>> >>>> The baseImageWidth/Height and Image.UndefinedProperty are >>>> returned to not trigger base image creation in the >>>> MultiResolutionCachedImage. >>>> >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Fri Jul 24 16:26:07 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 24 Jul 2015 19:26:07 +0300 Subject: [9] Review request for 8132123 MultiResolutionCachedImage unnecessarily creates base image to get its size In-Reply-To: <55B265C1.70009@oracle.com> References: <55AF9E46.8000901@oracle.com> <55AFD19C.9040204@oracle.com> <55B21D42.7040006@oracle.com> <55B2610D.5020007@oracle.com> <55B265C1.70009@oracle.com> Message-ID: <55B2671F.1080702@oracle.com> Thanks for clarification. The fix looks fine. On 24.07.15 19:20, Alexander Scherbatiy wrote: > On 7/24/2015 7:00 PM, Sergey Bylokhov wrote: >> On 24.07.15 14:10, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8132123/webrev.01 >>> >>> There is one more place where AquaSplitPaneDividerUI requests >>> scaled smooth image. It is better to allow the native system to >>> scale the image. >>> So I updated the getScaledInstance(width, height, hints) method in >>> the MultiResolutionCachedImage. It also allows to avoid base image >>> creation. >> Why did you change getProperty in the latest version? > > ImageIcon requests comment property from the image and it also > leads to unnecessary base image creation. > > Thanks, > Alexandr. > >>> >>> On 7/22/2015 8:23 PM, Sergey Bylokhov wrote: >>>> Hi, Alexander. >>>> Why you did update of bugid in the test, but did not update the >>>> test itself? Did the test fail before the fix? >>> >>> There are limited number of loaded native images and they are >>> immediately cached so it is hard to write a test which calculates >>> the excessive memory usage using only public API. >>> >>> I added the new test that uses the internal >>> MultiResolutionCachedImage class directly. >>> >>> Thanks, >>> Alexandr. >>>> >>>> On 22.07.15 16:44, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132123 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8132123/webrev.00 >>>>> >>>>> The baseImageWidth/Height and Image.UndefinedProperty are >>>>> returned to not trigger base image creation in the >>>>> MultiResolutionCachedImage. >>>>> >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From mik3hall at gmail.com Sat Jul 25 22:20:39 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 25 Jul 2015 17:20:39 -0500 Subject: [9] Review Request: 8129894 NSApplicationAWT.m:343:72: error: comparison of constant 777 with expression of type 'NSEventSubtype' In-Reply-To: <559E51B7.1020700@oracle.com> References: <559E51B7.1020700@oracle.com> Message-ID: <86BB16CE-5FCD-4288-8EB7-E4D5EA1970F2@gmail.com> > On Jul 9, 2015, at 5:49 AM, Sergey Bylokhov wrote: > > Hello. > Please review the fix for jdk9. > > This is the last issue, which prevents us to build the jdk on osx using the latest clang w/o --disable-warnings-as-errors. I may not be understanding this correctly. But, I just did a build on OS X and after running into the error in the subject I changed to -disable-warnings-as-errors and seemed to get more warnings following this one. Including ones for awt. Like? /Users/mjh/jdk9/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m:207:21: warning: implicit conversion from enumeration type 'NSPaperOrientation' (aka 'enum NSPaperOrientation') to different enumeration type 'NSPrintingOrientation' (aka 'enum NSPrintingOrientation') [-Wenum-conversion] [[[NSPrintOperation currentOperation] printInfo] orientation]; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/mjh/jdk9/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m:214:60: warning: implicit conversion from enumeration type 'enum NSPrintingOrientation' to different enumeration type 'NSPaperOrientation' (aka 'enum NSPaperOrientation') [-Wenum-conversion] setOrientation:NSPortraitOrientation]; ^~~~~~~~~~~~~~~~~~~~~ /Users/mjh/jdk9/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m:222:60: warning: implicit conversion from enumeration type 'enum NSPrintingOrientation' to different enumeration type 'NSPaperOrientation' (aka 'enum NSPaperOrientation') [-Wenum-conversion] setOrientation:NSLandscapeOrientation]; ^~~~~~~~~~~~~~~~~~~~~~ 3 warnings generated. Would these warnings not end up as errors that would stop the build? Michael Hall -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Sun Jul 26 12:13:12 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 26 Jul 2015 15:13:12 +0300 Subject: [9] Review Request: 8129894 NSApplicationAWT.m:343:72: error: comparison of constant 777 with expression of type 'NSEventSubtype' In-Reply-To: <86BB16CE-5FCD-4288-8EB7-E4D5EA1970F2@gmail.com> References: <559E51B7.1020700@oracle.com> <86BB16CE-5FCD-4288-8EB7-E4D5EA1970F2@gmail.com> Message-ID: <55B4CED8.2030206@oracle.com> On 26.07.15 1:20, Michael Hall wrote: >> On Jul 9, 2015, at 5:49 AM, Sergey Bylokhov >> > wrote: >> >> Hello. >> Please review the fix for jdk9. >> >> This is the last issue, which prevents us to build the jdk on osx >> using the latest clang w/o --disable-warnings-as-errors. > > I may not be understanding this correctly. But, I just did a build on > OS X and after running into the error in the subject I changed to > -disable-warnings-as-errors and seemed to get more warnings following > this one. Including ones for awt. Like? > > /Users/mjh/jdk9/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m:207:21: > warning: implicit conversion from enumeration > type 'NSPaperOrientation' (aka 'enum NSPaperOrientation') to different > enumeration type 'NSPrintingOrientation' (aka 'enum > NSPrintingOrientation') [-Wenum-conversion] > [[[NSPrintOperation currentOperation] printInfo] > orientation]; > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /Users/mjh/jdk9/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m:214:60: > warning: implicit conversion from enumeration type > 'enum NSPrintingOrientation' to different enumeration type > 'NSPaperOrientation' (aka 'enum NSPaperOrientation') [-Wenum-conversion] > setOrientation:NSPortraitOrientation]; > ^~~~~~~~~~~~~~~~~~~~~ > /Users/mjh/jdk9/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m:222:60: > warning: implicit conversion from enumeration type > 'enum NSPrintingOrientation' to different enumeration type > 'NSPaperOrientation' (aka 'enum NSPaperOrientation') [-Wenum-conversion] > setOrientation:NSLandscapeOrientation]; > ^~~~~~~~~~~~~~~~~~~~~~ > 3 warnings generated. > > Would these warnings not end up as errors that would stop the build? No, because lwawt library does not set "warning as error" option for now. > > Michael Hall > > > > > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Sun Jul 26 12:18:38 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 26 Jul 2015 07:18:38 -0500 Subject: [9] Review Request: 8129894 NSApplicationAWT.m:343:72: error: comparison of constant 777 with expression of type 'NSEventSubtype' In-Reply-To: <55B4CED8.2030206@oracle.com> References: <559E51B7.1020700@oracle.com> <86BB16CE-5FCD-4288-8EB7-E4D5EA1970F2@gmail.com> <55B4CED8.2030206@oracle.com> Message-ID: <9D4449B8-D549-423C-AE1B-A675239F12C4@gmail.com> > On Jul 26, 2015, at 7:13 AM, Sergey Bylokhov wrote: >> Would these warnings not end up as errors that would stop the build? > No, because lwawt library does not set "warning as error" option for now. OK thanks. Michael Hall -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Jul 27 11:36:16 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 27 Jul 2015 14:36:16 +0300 Subject: [9] Review Request: 8132355 Incorrect guard block in HPkeysym.h, awt_Event.h Message-ID: <55B617B0.9030602@oracle.com> Hello. Please review the fix for a typo in jdk9. The HPkeysym.h is from external library, so I have filed the bug in upstream too: https://bugs.freedesktop.org/show_bug.cgi?id=91469 Bug: https://bugs.openjdk.java.net/browse/JDK-8132355 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132355/webrev.00 -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Mon Jul 27 12:16:35 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 27 Jul 2015 15:16:35 +0300 Subject: [9] Review Request: 8132355 Incorrect guard block in HPkeysym.h, awt_Event.h In-Reply-To: <55B617B0.9030602@oracle.com> References: <55B617B0.9030602@oracle.com> Message-ID: <55B62123.2090505@oracle.com> Looks fine. Thanks, Alexander. On 07/27/2015 02:36 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for a typo in jdk9. > The HPkeysym.h is from external library, so I have filed the bug in > upstream too: > https://bugs.freedesktop.org/show_bug.cgi?id=91469 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8132355 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8132355/webrev.00 > From alexandr.scherbatiy at oracle.com Mon Jul 27 13:48:25 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 27 Jul 2015 16:48:25 +0300 Subject: java.awt.AWTKeyStroke.registerSubclass(Class subclass) method usage. Message-ID: <55B636A9.80509@oracle.com> Hello, The class KeyStroke has been added to the javax.swing package first and then copied to the java.awt.AWTKeyStroke. Most of KeyStroke class methods looks like registering KeyStroke class and call to the parent AWTKeyStroke method now. That is why the AWTKeyStroke.registerSubclass(Class subclass) method was added. It is just a question: does someone use AWTKeyStroke.registerSubclass(Class subclass) in their own project? Does it brings new benefits comparing just to AWTKeyStroke and Keystroke classes usage? Thanks, Alexandr. From anton.tarasov at oracle.com Mon Jul 27 14:55:23 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 27 Jul 2015 17:55:23 +0300 Subject: [9] Review Request: 8132355 Incorrect guard block in HPkeysym.h, awt_Event.h In-Reply-To: <55B62123.2090505@oracle.com> References: <55B617B0.9030602@oracle.com> <55B62123.2090505@oracle.com> Message-ID: <55B6465B.5020702@oracle.com> +1 On 27.07.2015 15:16, Alexander Zvegintsev wrote: > Looks fine. > > Thanks, > > Alexander. > > On 07/27/2015 02:36 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for a typo in jdk9. >> The HPkeysym.h is from external library, so I have filed the bug in upstream too: >> https://bugs.freedesktop.org/show_bug.cgi?id=91469 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8132355 >> Webrev can be found at: http://cr.openjdk.java.net/~serb/8132355/webrev.00 >> > From alexander.zvegintsev at oracle.com Mon Jul 27 17:35:31 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 27 Jul 2015 20:35:31 +0300 Subject: [9] Review request for 8014212: Robot captures black screen In-Reply-To: <55B1BA35.8010501@oracle.com> References: <55B1182E.7060706@oracle.com> <55B1BA35.8010501@oracle.com> Message-ID: <55B66BE3.1070506@oracle.com> Please see the updated version: http://cr.openjdk.java.net/~azvegint/jdk/9/8014212/01/ robot makes shot of intersection of provided rectangle with root window. Old robot implementation works for negative x and y, but may return garbage outside of root window behavior, so it was updated too. ShapeNotSetSometimes reduced iteration count to prevent killing by jtreg for timeout. TranslucentJAppletTest updated to use getPixelColor() directly. Thanks, Alexander. On 07/24/2015 07:08 AM, Sergey Bylokhov wrote: > Hi, Alexander. > I am not sure that an assumption that we should not make a screen shot > if the x and y are negative is correct. I guess that we should take a > screenshot of the intersection of the requested area and the display. > > Can you also check this comment in the TranslucentJAppletTest.java: > 106 // unfortunately, robot.getPixelColor() doesn't work for > some unknown reason > 107 // Color newColor2 = r.getPixelColor(200, 200); > > On 23.07.15 19:37, Alexander Zvegintsev wrote: >> Hello, >> >> please review the fix >> http://cr.openjdk.java.net/~azvegint/jdk/9/8014212/00 >> for the issue >> https://bugs.openjdk.java.net/browse/JDK-8014212 >> >> This fix trying to use gdk_pixbuf_get_from_drawable () [0] to capture >> screenshot(basic image data handling could be found here[1]). >> If it fails then we come back to our old method. >> Translucency support[1] is also covered by this fix, but there is >> another issue with toFront() call which blocks passing of a JCK test. >> >> P.S. On Solaris 11 windows appears with animation, thus sleep() call >> was added to work around this. >> >> [0] >> https://developer.gnome.org/gdk2/stable/gdk2-Pixbufs.html#gdk-pixbuf-get-from-drawable >> [1] >> https://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-The-GdkPixbuf-Structure.html#image-data >> [2] https://bugs.openjdk.java.net/browse/JDK-7043845 Robot should be >> able take screenshots with translucent windows >> >> -- >> Thanks, >> >> Alexander. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at cjnash.com Mon Jul 27 20:15:57 2015 From: simon at cjnash.com (Simon Nash) Date: Mon, 27 Jul 2015 21:15:57 +0100 Subject: Accessing internal packages in JDK 9 Message-ID: <55B6917D.1030404@cjnash.com> I have recently discovered that applications will no longer be able to access internal packages (sun.* and com.sun.*) in JDK 9. This is a major problem for my application as it requires access to some internal packages in order to work correctly. In most cases, my need to access these internal classes is to work around "object leakage" in Swing that results in objects being created and held by Swing with no means of freeing these objects by any application action. In some cases, these "leaked" objects reference my application classloader via their protection domain, and this means that my application classloader cannot be garbage collected even if I remove all references to it from within my application. My application uses native DLLs that sometimes need to be replaced by new versions and these DLLs cannot be unloaded and reloaded unless the application classloader that loaded these DLLs has been garbage collected. The only workaround I have found for this problem is to use internal APIs together with reflection to locate the fields that are holding these internal "leaked" objects and set these fields to null. It is hard to provide a definitive list of all the internal packages that I need because the list tends to grow each time I use additional Swing functionality in my application. At present, the packages are: sun.awt.AppContext sun.awt.image.MultiResolutionToolkitImage$ObserverCache sun.awt.X11.XBaseWindow sun.lwawt.LWComponentPeer sun.java2d.pipe.BufferedContext sun.java2d.pipe.RenderQueue sun.java2d.pipe.hw.BufferedContextProvider In addition, my application is using some APIs from internal packages to access functionality that isn't available via official APIs. These aren't Swing or AWT packages, so this mailing list probably isn't the right place to go into details. Any suggestions for the correct list(s) to raise this issue would be appreciated. The packages are: com.sun.management.HotSpotDiagnosticMXBean sun.misc.Signal sun.misc.SignalHandler sun.nio.ch.ChannelInputStream Best regards, Simon Nash From philip.race at oracle.com Mon Jul 27 21:57:42 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 27 Jul 2015 14:57:42 -0700 Subject: Accessing internal packages in JDK 9 In-Reply-To: <55B6917D.1030404@cjnash.com> References: <55B6917D.1030404@cjnash.com> Message-ID: <55B6A956.90708@oracle.com> The jdeps tool bundled with current JDK 8 updates should help you produced a definitive list - of your current uses. A web page about jpdeps and current recommended replacements for some internal APIs can be viewed at https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool jigsaw-dev at openjdk.java.net is the list for the project under which the changes are being made, and folks there are probably aware of any likelihood of some of the non-client ones getting a replacement. I don't know how a classloader can prevent a dll being unloaded unless you have tied a call to dlclose into the classloader gc process yourself. Can you explain this more ? I do not see any likelihood of the client ones you list being made public. Some of them are very deep in the details of the implementation. A more viable line to file bugs describing where the leakage is - and/or point us to any bugs that are already filed on these. -phil. On 07/27/2015 01:15 PM, Simon Nash wrote: > I have recently discovered that applications will no longer be able > to access internal packages (sun.* and com.sun.*) in JDK 9. This is a > major problem for my application as it requires access to some internal > packages in order to work correctly. > > In most cases, my need to access these internal classes is to work around > "object leakage" in Swing that results in objects being created and held > by Swing with no means of freeing these objects by any application > action. > In some cases, these "leaked" objects reference my application > classloader > via their protection domain, and this means that my application > classloader > cannot be garbage collected even if I remove all references to it from > within my application. My application uses native DLLs that sometimes > need > to be replaced by new versions and these DLLs cannot be unloaded and > reloaded unless the application classloader that loaded these DLLs has > been > garbage collected. > > The only workaround I have found for this problem is to use internal APIs > together with reflection to locate the fields that are holding these > internal "leaked" objects and set these fields to null. > > It is hard to provide a definitive list of all the internal packages that > I need because the list tends to grow each time I use additional Swing > functionality in my application. At present, the packages are: > > sun.awt.AppContext > sun.awt.image.MultiResolutionToolkitImage$ObserverCache > sun.awt.X11.XBaseWindow > sun.lwawt.LWComponentPeer > sun.java2d.pipe.BufferedContext > sun.java2d.pipe.RenderQueue > sun.java2d.pipe.hw.BufferedContextProvider > > In addition, my application is using some APIs from internal packages to > access functionality that isn't available via official APIs. These aren't > Swing or AWT packages, so this mailing list probably isn't the right > place > to go into details. Any suggestions for the correct list(s) to raise > this > issue would be appreciated. The packages are: > > com.sun.management.HotSpotDiagnosticMXBean > sun.misc.Signal > sun.misc.SignalHandler > sun.nio.ch.ChannelInputStream > > Best regards, > Simon Nash From simon at cjnash.com Mon Jul 27 22:56:06 2015 From: simon at cjnash.com (Simon Nash) Date: Mon, 27 Jul 2015 23:56:06 +0100 Subject: Accessing internal packages in JDK 9 In-Reply-To: <55B6A956.90708@oracle.com> References: <55B6917D.1030404@cjnash.com> <55B6A956.90708@oracle.com> Message-ID: <55B6B706.6090406@cjnash.com> Phil Race wrote: > The jdeps tool bundled with current JDK 8 updates should help > you produced a definitive list - of your current uses. > Thanks for your quick reply. I will run this tool to check that my list is complete and correct. > A web page about jpdeps and current recommended replacements for > some internal APIs can be viewed at > https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > I will look at this to see if it helps with my issues. > jigsaw-dev at openjdk.java.net is the list for the project under which the > changes are being made, and folks there are probably aware of any > likelihood of some of the non-client ones getting a replacement. > I will raise this topic on that list. > I don't know how a classloader can prevent a dll being unloaded unless > you have tied a call to dlclose into the classloader gc process yourself. > Can you explain this more ? > See the section "Library and Version Management" in this document: http://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/invocation.html Specifically: (1) The same JNI native library cannot be loaded into more than one class loader. Doing so causes UnsatisfiedLinkError to be thrown. (2) In addition, native libraries can be unloaded when their corresponding class loaders are garbage collected. Because of (1), a new version of the native library can't be loaded until the old version is unloaded. Because of (2), the old version can't be unloaded until the original classloader has been garbage collected. I have not tied anything into the classloader GC process myself. > I do not see any likelihood of the client ones you list being made public. > Some of them are very deep in the details of the implementation. > Will there be any way to access these if they are not public (for example, by reflection)? If this is possible, I should be able to adapt my current workaround code to run on JDK 9. > A more viable line to file bugs describing where the leakage is - and/or > point us to any bugs that are already filed on these. > Some have existing bugs filed (6575402, 8029147) and many others don't. To file bugs on everything I have found would be a huge effort because I discovered these some time ago and my memory of the exact details has faded by now. The only way to be sure I have the details correct would be to remove my workarounds and analyse the leakages again using JVisualVM. This would require several weeks of work. At present, a developer can work around a bug like this until a fix is available in a new version of the JDK. If access to private classes is removed completely, such workarounds will no longer be possible. Simon Phil Race wrote: > The jdeps tool bundled with current JDK 8 updates should help > you produced a definitive list - of your current uses. > > A web page about jpdeps and current recommended replacements for > some internal APIs can be viewed at > https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > > jigsaw-dev at openjdk.java.net is the list for the project under which the > changes are being made, and folks there are probably aware of any > likelihood of some of the non-client ones getting a replacement. > > I don't know how a classloader can prevent a dll being unloaded unless > you have tied a call to dlclose into the classloader gc process yourself. > Can you explain this more ? > > I do not see any likelihood of the client ones you list being made public. > Some of them are very deep in the details of the implementation. > > A more viable line to file bugs describing where the leakage is - and/or > point us to any bugs that are already filed on these. > > -phil. > > On 07/27/2015 01:15 PM, Simon Nash wrote: >> I have recently discovered that applications will no longer be able >> to access internal packages (sun.* and com.sun.*) in JDK 9. This is a >> major problem for my application as it requires access to some internal >> packages in order to work correctly. >> >> In most cases, my need to access these internal classes is to work around >> "object leakage" in Swing that results in objects being created and held >> by Swing with no means of freeing these objects by any application >> action. >> In some cases, these "leaked" objects reference my application >> classloader >> via their protection domain, and this means that my application >> classloader >> cannot be garbage collected even if I remove all references to it from >> within my application. My application uses native DLLs that sometimes >> need >> to be replaced by new versions and these DLLs cannot be unloaded and >> reloaded unless the application classloader that loaded these DLLs has >> been >> garbage collected. >> >> The only workaround I have found for this problem is to use internal APIs >> together with reflection to locate the fields that are holding these >> internal "leaked" objects and set these fields to null. >> >> It is hard to provide a definitive list of all the internal packages that >> I need because the list tends to grow each time I use additional Swing >> functionality in my application. At present, the packages are: >> >> sun.awt.AppContext >> sun.awt.image.MultiResolutionToolkitImage$ObserverCache >> sun.awt.X11.XBaseWindow >> sun.lwawt.LWComponentPeer >> sun.java2d.pipe.BufferedContext >> sun.java2d.pipe.RenderQueue >> sun.java2d.pipe.hw.BufferedContextProvider >> >> In addition, my application is using some APIs from internal packages to >> access functionality that isn't available via official APIs. These aren't >> Swing or AWT packages, so this mailing list probably isn't the right >> place >> to go into details. Any suggestions for the correct list(s) to raise >> this >> issue would be appreciated. The packages are: >> >> com.sun.management.HotSpotDiagnosticMXBean >> sun.misc.Signal >> sun.misc.SignalHandler >> sun.nio.ch.ChannelInputStream >> >> Best regards, >> Simon Nash > > From philip.race at oracle.com Mon Jul 27 23:22:57 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 27 Jul 2015 16:22:57 -0700 Subject: Accessing internal packages in JDK 9 In-Reply-To: <55B6B706.6090406@cjnash.com> References: <55B6917D.1030404@cjnash.com> <55B6A956.90708@oracle.com> <55B6B706.6090406@cjnash.com> Message-ID: <55B6BD51.2070209@oracle.com> On 07/27/2015 03:56 PM, Simon Nash wrote: > Phil Race wrote: > > The jdeps tool bundled with current JDK 8 updates should help > > you produced a definitive list - of your current uses. > > > Thanks for your quick reply. I will run this tool to check that my list > is complete and correct. > > > A web page about jpdeps and current recommended replacements for > > some internal APIs can be viewed at > > > https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > > > I will look at this to see if it helps with my issues. > > > jigsaw-dev at openjdk.java.net is the list for the project under which the > > changes are being made, and folks there are probably aware of any > > likelihood of some of the non-client ones getting a replacement. > > > I will raise this topic on that list. > > > I don't know how a classloader can prevent a dll being unloaded unless > > you have tied a call to dlclose into the classloader gc process > yourself. > > Can you explain this more ? > > > See the section "Library and Version Management" in this document: > http://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/invocation.html > Specifically: > So these dlls contain JNI code .. and need to be found by the VM. I suspect that for client code there are few if any tests that really exercise this. > (1) The same JNI native library cannot be loaded into more than one class > loader. Doing so causes UnsatisfiedLinkError to be thrown. > > (2) In addition, native libraries can be unloaded when their > corresponding > class loaders are garbage collected. > > Because of (1), a new version of the native library can't be loaded until > the old version is unloaded. Because of (2), the old version can't be > unloaded until the original classloader has been garbage collected. I > have > not tied anything into the classloader GC process myself. > > > I do not see any likelihood of the client ones you list being made > public. > > Some of them are very deep in the details of the implementation. > > > Will there be any way to access these if they are not public (for > example, > by reflection)? If this is possible, I should be able to adapt my > current > workaround code to run on JDK 9. My understanding is that you would have to use special command line options but this is all a work in progress. > > > A more viable line to file bugs describing where the leakage is - > and/or > > point us to any bugs that are already filed on these. > > > Some have existing bugs filed (6575402, 8029147) and many others don't. > To file bugs on everything I have found would be a huge effort because I > discovered these some time ago and my memory of the exact details has > faded by now. The only way to be sure I have the details correct > would be > to remove my workarounds and analyse the leakages again using JVisualVM. > This would require several weeks of work. > > At present, a developer can work around a bug like this until a fix is > available in a new version of the JDK. If access to private classes is > removed completely, such workarounds will no longer be possible. I believe it would be worthwhile to try to identify as many of these as possible. -phil. > > Simon > > Phil Race wrote: >> The jdeps tool bundled with current JDK 8 updates should help >> you produced a definitive list - of your current uses. >> >> A web page about jpdeps and current recommended replacements for >> some internal APIs can be viewed at >> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool >> >> jigsaw-dev at openjdk.java.net is the list for the project under which the >> changes are being made, and folks there are probably aware of any >> likelihood of some of the non-client ones getting a replacement. >> >> I don't know how a classloader can prevent a dll being unloaded unless >> you have tied a call to dlclose into the classloader gc process >> yourself. >> Can you explain this more ? >> >> I do not see any likelihood of the client ones you list being made >> public. >> Some of them are very deep in the details of the implementation. >> >> A more viable line to file bugs describing where the leakage is - and/or >> point us to any bugs that are already filed on these. >> >> -phil. >> >> On 07/27/2015 01:15 PM, Simon Nash wrote: >>> I have recently discovered that applications will no longer be able >>> to access internal packages (sun.* and com.sun.*) in JDK 9. This is a >>> major problem for my application as it requires access to some internal >>> packages in order to work correctly. >>> >>> In most cases, my need to access these internal classes is to work >>> around >>> "object leakage" in Swing that results in objects being created and >>> held >>> by Swing with no means of freeing these objects by any application >>> action. >>> In some cases, these "leaked" objects reference my application >>> classloader >>> via their protection domain, and this means that my application >>> classloader >>> cannot be garbage collected even if I remove all references to it from >>> within my application. My application uses native DLLs that >>> sometimes need >>> to be replaced by new versions and these DLLs cannot be unloaded and >>> reloaded unless the application classloader that loaded these DLLs >>> has been >>> garbage collected. >>> >>> The only workaround I have found for this problem is to use internal >>> APIs >>> together with reflection to locate the fields that are holding these >>> internal "leaked" objects and set these fields to null. >>> >>> It is hard to provide a definitive list of all the internal packages >>> that >>> I need because the list tends to grow each time I use additional Swing >>> functionality in my application. At present, the packages are: >>> >>> sun.awt.AppContext >>> sun.awt.image.MultiResolutionToolkitImage$ObserverCache >>> sun.awt.X11.XBaseWindow >>> sun.lwawt.LWComponentPeer >>> sun.java2d.pipe.BufferedContext >>> sun.java2d.pipe.RenderQueue >>> sun.java2d.pipe.hw.BufferedContextProvider >>> >>> In addition, my application is using some APIs from internal >>> packages to >>> access functionality that isn't available via official APIs. These >>> aren't >>> Swing or AWT packages, so this mailing list probably isn't the right >>> place >>> to go into details. Any suggestions for the correct list(s) to >>> raise this >>> issue would be appreciated. The packages are: >>> >>> com.sun.management.HotSpotDiagnosticMXBean >>> sun.misc.Signal >>> sun.misc.SignalHandler >>> sun.nio.ch.ChannelInputStream >>> >>> Best regards, >>> Simon Nash >> >> > From philip.race at oracle.com Mon Jul 27 23:54:25 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 27 Jul 2015 16:54:25 -0700 Subject: Accessing internal packages in JDK 9 In-Reply-To: <55B6BD51.2070209@oracle.com> References: <55B6917D.1030404@cjnash.com> <55B6A956.90708@oracle.com> <55B6B706.6090406@cjnash.com> <55B6BD51.2070209@oracle.com> Message-ID: <55B6C4B1.6080601@oracle.com> PS .. when you identify a workaround that you think bears a resemblance to the required fix, you could submit it as a patch. That way you won't lose track of the issues and it has a good chance of being fixed sooner. -phil. On 7/27/15 4:22 PM, Phil Race wrote: > On 07/27/2015 03:56 PM, Simon Nash wrote: >> Phil Race wrote: >> > The jdeps tool bundled with current JDK 8 updates should help >> > you produced a definitive list - of your current uses. >> > >> Thanks for your quick reply. I will run this tool to check that my list >> is complete and correct. >> >> > A web page about jpdeps and current recommended replacements for >> > some internal APIs can be viewed at >> > >> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool >> > >> I will look at this to see if it helps with my issues. >> >> > jigsaw-dev at openjdk.java.net is the list for the project under which >> the >> > changes are being made, and folks there are probably aware of any >> > likelihood of some of the non-client ones getting a replacement. >> > >> I will raise this topic on that list. >> >> > I don't know how a classloader can prevent a dll being unloaded unless >> > you have tied a call to dlclose into the classloader gc process >> yourself. >> > Can you explain this more ? >> > >> See the section "Library and Version Management" in this document: >> http://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/invocation.html >> Specifically: >> > > So these dlls contain JNI code .. and need to be found by the VM. > > I suspect that for client code there are few if any tests that really > exercise this. > > >> (1) The same JNI native library cannot be loaded into more than one >> class >> loader. Doing so causes UnsatisfiedLinkError to be thrown. >> >> (2) In addition, native libraries can be unloaded when their >> corresponding >> class loaders are garbage collected. >> >> Because of (1), a new version of the native library can't be loaded >> until >> the old version is unloaded. Because of (2), the old version can't be >> unloaded until the original classloader has been garbage collected. >> I have >> not tied anything into the classloader GC process myself. >> >> > I do not see any likelihood of the client ones you list being made >> public. >> > Some of them are very deep in the details of the implementation. >> > >> Will there be any way to access these if they are not public (for >> example, >> by reflection)? If this is possible, I should be able to adapt my >> current >> workaround code to run on JDK 9. > > My understanding is that you would have to use special command line > options > but this is all a work in progress. > >> >> > A more viable line to file bugs describing where the leakage is - >> and/or >> > point us to any bugs that are already filed on these. >> > >> Some have existing bugs filed (6575402, 8029147) and many others don't. >> To file bugs on everything I have found would be a huge effort because I >> discovered these some time ago and my memory of the exact details has >> faded by now. The only way to be sure I have the details correct >> would be >> to remove my workarounds and analyse the leakages again using JVisualVM. >> This would require several weeks of work. >> >> At present, a developer can work around a bug like this until a fix is >> available in a new version of the JDK. If access to private classes is >> removed completely, such workarounds will no longer be possible. > > I believe it would be worthwhile to try to identify as many of these > as possible. > > -phil. >> >> Simon >> >> Phil Race wrote: >>> The jdeps tool bundled with current JDK 8 updates should help >>> you produced a definitive list - of your current uses. >>> >>> A web page about jpdeps and current recommended replacements for >>> some internal APIs can be viewed at >>> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool >>> >>> >>> jigsaw-dev at openjdk.java.net is the list for the project under which the >>> changes are being made, and folks there are probably aware of any >>> likelihood of some of the non-client ones getting a replacement. >>> >>> I don't know how a classloader can prevent a dll being unloaded unless >>> you have tied a call to dlclose into the classloader gc process >>> yourself. >>> Can you explain this more ? >>> >>> I do not see any likelihood of the client ones you list being made >>> public. >>> Some of them are very deep in the details of the implementation. >>> >>> A more viable line to file bugs describing where the leakage is - >>> and/or >>> point us to any bugs that are already filed on these. >>> >>> -phil. >>> >>> On 07/27/2015 01:15 PM, Simon Nash wrote: >>>> I have recently discovered that applications will no longer be able >>>> to access internal packages (sun.* and com.sun.*) in JDK 9. This is a >>>> major problem for my application as it requires access to some >>>> internal >>>> packages in order to work correctly. >>>> >>>> In most cases, my need to access these internal classes is to work >>>> around >>>> "object leakage" in Swing that results in objects being created and >>>> held >>>> by Swing with no means of freeing these objects by any application >>>> action. >>>> In some cases, these "leaked" objects reference my application >>>> classloader >>>> via their protection domain, and this means that my application >>>> classloader >>>> cannot be garbage collected even if I remove all references to it from >>>> within my application. My application uses native DLLs that >>>> sometimes need >>>> to be replaced by new versions and these DLLs cannot be unloaded and >>>> reloaded unless the application classloader that loaded these DLLs >>>> has been >>>> garbage collected. >>>> >>>> The only workaround I have found for this problem is to use >>>> internal APIs >>>> together with reflection to locate the fields that are holding these >>>> internal "leaked" objects and set these fields to null. >>>> >>>> It is hard to provide a definitive list of all the internal >>>> packages that >>>> I need because the list tends to grow each time I use additional Swing >>>> functionality in my application. At present, the packages are: >>>> >>>> sun.awt.AppContext >>>> sun.awt.image.MultiResolutionToolkitImage$ObserverCache >>>> sun.awt.X11.XBaseWindow >>>> sun.lwawt.LWComponentPeer >>>> sun.java2d.pipe.BufferedContext >>>> sun.java2d.pipe.RenderQueue >>>> sun.java2d.pipe.hw.BufferedContextProvider >>>> >>>> In addition, my application is using some APIs from internal >>>> packages to >>>> access functionality that isn't available via official APIs. These >>>> aren't >>>> Swing or AWT packages, so this mailing list probably isn't the >>>> right place >>>> to go into details. Any suggestions for the correct list(s) to >>>> raise this >>>> issue would be appreciated. The packages are: >>>> >>>> com.sun.management.HotSpotDiagnosticMXBean >>>> sun.misc.Signal >>>> sun.misc.SignalHandler >>>> sun.nio.ch.ChannelInputStream >>>> >>>> Best regards, >>>> Simon Nash >>> >>> >> > From mik3hall at gmail.com Tue Jul 28 00:54:21 2015 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 27 Jul 2015 19:54:21 -0500 Subject: Accessing internal packages in JDK 9 In-Reply-To: <55B6BD51.2070209@oracle.com> References: <55B6917D.1030404@cjnash.com> <55B6A956.90708@oracle.com> <55B6B706.6090406@cjnash.com> <55B6BD51.2070209@oracle.com> Message-ID: <34B86526-BB3F-4AB7-B23C-16BD2C0FE50F@gmail.com> > On Jul 27, 2015, at 6:22 PM, Phil Race > wrote: >> > >> Will there be any way to access these if they are not public (for example, >> by reflection)? If this is possible, I should be able to adapt my current >> workaround code to run on JDK 9. > > My understanding is that you would have to use special command line options > but this is all a work in progress. Re: Manually Adding exports to JDK Modules https://www.mail-archive.com/jigsaw-dev at openjdk.java.net/msg01053.html Michael Hall -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Tue Jul 28 12:49:52 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 28 Jul 2015 15:49:52 +0300 Subject: [9] Review request for 8014212: Robot captures black screen In-Reply-To: <55B66BE3.1070506@oracle.com> References: <55B1182E.7060706@oracle.com> <55B1BA35.8010501@oracle.com> <55B66BE3.1070506@oracle.com> Message-ID: <55B77A70.9010501@oracle.com> Hello Sergey, please see the updated version http://cr.openjdk.java.net/~azvegint/jdk/9/8014212/02/ GetPrimitiveArrayCritical() is used instead of manual array allocation. Thanks, Alexander. On 07/27/2015 08:35 PM, Alexander Zvegintsev wrote: > Please see the updated version: > http://cr.openjdk.java.net/~azvegint/jdk/9/8014212/01/ > > robot makes shot of intersection of provided rectangle with root > window. Old robot implementation works for negative x and y, > but may return garbage outside of root window behavior, so it was > updated too. > > ShapeNotSetSometimes reduced iteration count to prevent killing by > jtreg for timeout. > > TranslucentJAppletTest updated to use getPixelColor() directly. > Thanks, > > Alexander. > On 07/24/2015 07:08 AM, Sergey Bylokhov wrote: >> Hi, Alexander. >> I am not sure that an assumption that we should not make a screen >> shot if the x and y are negative is correct. I guess that we should >> take a screenshot of the intersection of the requested area and the >> display. >> >> Can you also check this comment in the TranslucentJAppletTest.java: >> 106 // unfortunately, robot.getPixelColor() doesn't work for >> some unknown reason >> 107 // Color newColor2 = r.getPixelColor(200, 200); >> >> On 23.07.15 19:37, Alexander Zvegintsev wrote: >>> Hello, >>> >>> please review the fix >>> http://cr.openjdk.java.net/~azvegint/jdk/9/8014212/00 >>> for the issue >>> https://bugs.openjdk.java.net/browse/JDK-8014212 >>> >>> This fix trying to use gdk_pixbuf_get_from_drawable () [0] to >>> capture screenshot(basic image data handling could be found here[1]). >>> If it fails then we come back to our old method. >>> Translucency support[1] is also covered by this fix, but there is >>> another issue with toFront() call which blocks passing of a JCK test. >>> >>> P.S. On Solaris 11 windows appears with animation, thus sleep() call >>> was added to work around this. >>> >>> [0] >>> https://developer.gnome.org/gdk2/stable/gdk2-Pixbufs.html#gdk-pixbuf-get-from-drawable >>> [1] >>> https://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-The-GdkPixbuf-Structure.html#image-data >>> [2] https://bugs.openjdk.java.net/browse/JDK-7043845 Robot should be >>> able take screenshots with translucent windows >>> >>> -- >>> Thanks, >>> >>> Alexander. >> >> >> -- >> Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Jul 28 15:33:39 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 28 Jul 2015 18:33:39 +0300 Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: <55B1236D.4020608@oracle.com> References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com> <5502E763.7080008@oracle.com> <55147EBE.3010002@oracle.com> <551BF6AC.8000705@oracle.com> <5523AB20.30704@oracle.com> <552E7006.70101@oracle.com> <55A44B62.7070703@oracle.com> <55AE5A22.7040603@oracle.com> <55B1236D.4020608@oracle.com> Message-ID: <55B7A0D3.2010404@oracle.com> Hello Jim, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8029339/webrev.10/ - the suggested comments are updated - the MultiResolutionRenderingHintsTest is updated to use custom GraphicsConfiguration and SurfaceData On 7/23/2015 8:25 PM, Jim Graham wrote: > Hi Alexandr, > > On 7/21/15 7:41 AM, Alexander Scherbatiy wrote: >> >> Hello Jim, >> >> Thank your for the review. >> >> Could you review the updated fix there the suggested comments are >> updated: >> http://cr.openjdk.java.net/~alexsch/8029339/webrev.09/ > > Minor comments embedded below. > >> On 7/14/2015 2:36 AM, Jim Graham wrote: >>> AbstractMRI - getGraphics() should include "getGraphics() not >>> supported on Multi-Resolution Images" as the exception description >>> text. > > AbstractMRI - the getGraphics() description string contains an > embedded '\n' and an embedded '\"', are those typos? Updated. > >>> BaseMRI - class comment - "The implementation will return the first >>> ... satisfy the rendering request." Add another sentence right there >>> "The last image in the array will be returned if no suitable image is >>> found that is larger than the rendering request." > > BaseMRI - whoops, my bad. "that is larger than" should probably be > "that is as large as" to match the <= comparison Updated. > >>> SG2D.getResolutionVariant - using destRegionWH to calculate >>> destImageWH can involve a lot of "do some math and then later have >>> additional code undo it". Would it be faster to just compute >>> destImageWH directly, as in: >>> >>> float destImageWidth, destImageHeight; >>> >>> if (BASE) { >>> destImageWH = srcWH; >>> } else if (DPI) { >>> destImageWH = (float) abs(srcWH * devScale); >>> } else { >>> double destRegionWidth, destRegionHeight; >>> if (type) { >>> ... >>> } >>> destImageWH = (float) abs(srcWH * destRegionWH / swh); >>> } >>> Image rv = img.getRV(destImageWH); > > For the BASE and DPI_FIT cases shouldn't you use srcWidth,srcHeight > instead of sw,sh? The sw,sh are affected by sub-image parameters, but > srcWidth,srcHeight are literally the size of the original image, which > is what you want to search the MRI for. The sw,sh should only be used > to scale the srcWidth in the "else" clause - as in "srcWidth * > destRegionWidth / sw". You are right. sw and sh are sizes of a region in the original image. I have updated the fix to use srcWidth/Height. > >>> Is there intent to have the default case be mapped to DPI_FIT for >>> Windows? >> I think yes. > > I didn't see where this was being done - is that a TBD follow-on fix > or did I miss a default somewhere? I think that it could be fixed with the updating WToolkit to load high-resolution toolkit images in the same way as it is done in LWCToolkit. At least it can be filled as a separate issue. > >>> MRRHTest - why not render to a BufferedImage and avoid Robot? Could it >>> tap into internal APIs to create a BImg/compatibleImage with a given >>> devScale? >> >> The DPI_FIT test includes case there a graphics transform is >> identity but the device configuration transform has scale 2. >> There should be a way to set scale for the device configuration >> transform; > > Ah yes, DPI_FIT needs a default transform. Also, without a way to > manually create a device with a transform, that means that DPI_FIT is > only successfully tested if the tests are run on a HiDPI machine, right? > >>> MRRHTest - why allow up to delta=50 on the comparison? >> It is just for monitors that are calibrated on Mac OS X and they >> colors are different from that which was set. The test uses colors which >> have at least one color component differ by 255. > > Another issue that might go away if we could use BImg instead of robot. > >>> MRRHTest - since the scale factor comes from a dialog, we depend on >>> running this on a HiDPI display to fully test the hints? Could using >>> "scaled compatible images" allow testing this more definitively? >> >> Could you explain more what does it mean "scaled compatible images"? > > I seem to recall that there is a mechanism in there to create > backbuffer images for swing that record the fact that they are > scaled. I forget how this is done, but I'm wondering if it could be > used to run all of this test code in a simulated scale environment > rather than using the actual configurations that AWT creates for the > current system. I have updated the test to use custom GraphicsConfiguration and SurfaceData. This allows to use custom scales both on the graphics configuration and on graphics. Thanks, Alexandr. > > ...jim From semyon.sadetsky at oracle.com Tue Jul 28 17:50:11 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 28 Jul 2015 20:50:11 +0300 Subject: [9] Review Request for 8041519: JVM crash on second DnD after modal dialog opened during Swing DnD operation In-Reply-To: <55AEB98F.2020204@oracle.com> References: <55A92CE0.70307@oracle.com> <55AEB98F.2020204@oracle.com> Message-ID: <55B7C0D3.1060602@oracle.com> Hi Sergey, Not sure that I understood what you are proposing. Could you clarify or rephrase? --Semyon On 7/22/2015 12:28 AM, Sergey Bylokhov wrote: > Hi, Semyon. > Is it possible to write a test which ignore all possible exceptions > and will fail only in case of crash? > > On 17.07.15 19:27, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> bug: https://bugs.openjdk.java.net/browse/JDK-8041519 >> webrev: http://cr.openjdk.java.net/~ssadetsky/8041519/webrev.00/ >> >> This is regression from JDK-6342381. When a modal dialog blocks drop >> operation in progress state consequent mouse events clear the drop >> context variables (this clearing was introduced by JDK-6342381). The >> solution is to avoid clearing if drop operation is in progress. >> Test scenario for this case would be too hard and unstable. Since the >> fix is pretty simple I left it as noreg. >> >> --Semyon >> >> > > From mik3hall at gmail.com Tue Jul 28 21:21:51 2015 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 28 Jul 2015 16:21:51 -0500 Subject: Accessing internal packages in JDK 9 In-Reply-To: <55B6917D.1030404@cjnash.com> References: <55B6917D.1030404@cjnash.com> Message-ID: <8B6DFE5C-5B9E-4326-ACEA-C5C2D97502B5@gmail.com> > On Jul 27, 2015, at 3:15 PM, Simon Nash wrote: > It is hard to provide a definitive list of all the internal packages that > I need because the list tends to grow each time I use additional Swing > functionality in my application. This does remind me of some code I had a while back. I was looking for a Save option for my Swing application on OS X for the Aqua L&F. I was a little familiar with serialization at the time and it would of been nice if this just could of just been usable for this function. Aqua was not serializable. I wrote a custom ObjectInputStream and a custom ObjectOutputStream that would make substitutions for classes that weren?t serializable. The substitutes wouldn?t restore the objects on the unmarshall but instead would construct new instances, via reflection I think, been a bit. I got this working for my application as it was. Of course, any changes to the gui uncovered new internal Swing platform specific code that I hadn?t mapped substitutes for. So as you mentioned very breakable and brittle. I think I remember using that very word years back. Brittle. What I thought you would probably need would be a more automated tool that could map and generate suitable substitutes for the entire api. Would be nice huh? Make virtually any code serializable and less brittle than serialization itself since you wouldn?t be restoring some possibly out of date version but instead constructing a new instance with the latest version of the class. Subtle differences between the old and new versions would probably still have weird side-effects sometimes. Never wrote that though. The other mega-meta tool I never really completed was one to automatically generate native bindings. Based off of Apple?s old JDirect. Put even more time into that one but without a really comprehensive tool it was impossible to keep up on all the native api?s. Another maintenance nightmare. (Another might of been writing my own zip filesystem. Not quite as mega-meta, but it worked in a slightly limited way, not all java.io classes implemented, until class loader changes in Java 6 broke it. I based my own little IDE off of it. javac worked fine with it to compile directly to zip files.) Ah, messing with that code was good times. I see you moved this to jigsaw. Seems like the dependency and other tools might be along these same mega-meta lines and be something you can use. Maybe I?ll revisit mine sometime with them, they might just make that work? gl, Michael Hall -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Wed Jul 29 01:42:13 2015 From: james.graham at oracle.com (Jim Graham) Date: Tue, 28 Jul 2015 18:42:13 -0700 Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays In-Reply-To: <55B7A0D3.2010404@oracle.com> References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com> <5502E763.7080008@oracle.com> <55147EBE.3010002@oracle.com> <551BF6AC.8000705@oracle.com> <5523AB20.30704@oracle.com> <552E7006.70101@oracle.com> <55A44B62.7070703@oracle.com> <55AE5A22.7040603@oracle.com> <55B1236D.4020608@oracle.com> <55B7A0D3.2010404@oracle.com> Message-ID: <55B82F75.20804@oracle.com> Hi Alexandr, All of the new changes look good. Only one minor issue in a comment in the test: MRRHT.java, line 85: should be "is not based on rendered size" or something to that effect (No need for a new webrev to fix that print statement.) I have a separate question out to Phil on whether or not using sun.* classes like this in a java.* test is good practice, but the worst case answer for that question would be "or should the test be moved to a sun.* package"... One follow-on issue to file and think about - the use of getDefaultTransform() requires the construction of a brand new transform every time it is used. For the call to it from the SG2D constructor that is fine because that becomes our initial AffineTransform that we would have had to create anyway. But, if they set the DPI_FIT hint then we end up calling that method every time we are looking at an MR image. We should look for a way to cache that value, or use internal API that doesn't require a clone, or some other way to avoid that "on every drawImage call" object creation. Unless you have an obvious fix you want to do now, I don't think we need to hold up this push to get the new MR APIs out there... ...jim On 7/28/15 8:33 AM, Alexander Scherbatiy wrote: > > Hello Jim, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8029339/webrev.10/ > - the suggested comments are updated > - the MultiResolutionRenderingHintsTest is updated to use custom > GraphicsConfiguration and SurfaceData > > On 7/23/2015 8:25 PM, Jim Graham wrote: >> Hi Alexandr, >> >> On 7/21/15 7:41 AM, Alexander Scherbatiy wrote: >>> >>> Hello Jim, >>> >>> Thank your for the review. >>> >>> Could you review the updated fix there the suggested comments are >>> updated: >>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.09/ >> >> Minor comments embedded below. >> >>> On 7/14/2015 2:36 AM, Jim Graham wrote: >>>> AbstractMRI - getGraphics() should include "getGraphics() not >>>> supported on Multi-Resolution Images" as the exception description >>>> text. >> >> AbstractMRI - the getGraphics() description string contains an >> embedded '\n' and an embedded '\"', are those typos? > Updated. >> >>>> BaseMRI - class comment - "The implementation will return the first >>>> ... satisfy the rendering request." Add another sentence right there >>>> "The last image in the array will be returned if no suitable image is >>>> found that is larger than the rendering request." >> >> BaseMRI - whoops, my bad. "that is larger than" should probably be >> "that is as large as" to match the <= comparison > Updated. >> >>>> SG2D.getResolutionVariant - using destRegionWH to calculate >>>> destImageWH can involve a lot of "do some math and then later have >>>> additional code undo it". Would it be faster to just compute >>>> destImageWH directly, as in: >>>> >>>> float destImageWidth, destImageHeight; >>>> >>>> if (BASE) { >>>> destImageWH = srcWH; >>>> } else if (DPI) { >>>> destImageWH = (float) abs(srcWH * devScale); >>>> } else { >>>> double destRegionWidth, destRegionHeight; >>>> if (type) { >>>> ... >>>> } >>>> destImageWH = (float) abs(srcWH * destRegionWH / swh); >>>> } >>>> Image rv = img.getRV(destImageWH); >> >> For the BASE and DPI_FIT cases shouldn't you use srcWidth,srcHeight >> instead of sw,sh? The sw,sh are affected by sub-image parameters, but >> srcWidth,srcHeight are literally the size of the original image, which >> is what you want to search the MRI for. The sw,sh should only be used >> to scale the srcWidth in the "else" clause - as in "srcWidth * >> destRegionWidth / sw". > > You are right. sw and sh are sizes of a region in the original > image. I have updated the fix to use srcWidth/Height. > >> >>>> Is there intent to have the default case be mapped to DPI_FIT for >>>> Windows? >>> I think yes. >> >> I didn't see where this was being done - is that a TBD follow-on fix >> or did I miss a default somewhere? > I think that it could be fixed with the updating WToolkit to load > high-resolution toolkit images in the same way as it is done in LWCToolkit. > At least it can be filled as a separate issue. > >> >>>> MRRHTest - why not render to a BufferedImage and avoid Robot? Could it >>>> tap into internal APIs to create a BImg/compatibleImage with a given >>>> devScale? >>> >>> The DPI_FIT test includes case there a graphics transform is >>> identity but the device configuration transform has scale 2. >>> There should be a way to set scale for the device configuration >>> transform; >> >> Ah yes, DPI_FIT needs a default transform. Also, without a way to >> manually create a device with a transform, that means that DPI_FIT is >> only successfully tested if the tests are run on a HiDPI machine, right? >> >>>> MRRHTest - why allow up to delta=50 on the comparison? >>> It is just for monitors that are calibrated on Mac OS X and they >>> colors are different from that which was set. The test uses colors which >>> have at least one color component differ by 255. >> >> Another issue that might go away if we could use BImg instead of robot. >> >>>> MRRHTest - since the scale factor comes from a dialog, we depend on >>>> running this on a HiDPI display to fully test the hints? Could using >>>> "scaled compatible images" allow testing this more definitively? >>> >>> Could you explain more what does it mean "scaled compatible images"? >> >> I seem to recall that there is a mechanism in there to create >> backbuffer images for swing that record the fact that they are >> scaled. I forget how this is done, but I'm wondering if it could be >> used to run all of this test code in a simulated scale environment >> rather than using the actual configurations that AWT creates for the >> current system. > > I have updated the test to use custom GraphicsConfiguration and > SurfaceData. This allows to use custom scales both on the graphics > configuration and on graphics. > > Thanks, > Alexandr. > >> >> ...jim > From pooja.chopra at oracle.com Wed Jul 29 06:12:26 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Wed, 29 Jul 2015 11:42:26 +0530 Subject: < Swing Dev> [9] Review Request:JDK-8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java failed with UnsupportedOperation exception In-Reply-To: <55A6AE5A.3060408@oracle.com> References: <55A62E46.3020504@oracle.com> <55A630DE.4080500@oracle.com> <55A6AE5A.3060408@oracle.com> Message-ID: <55B86ECA.20306@oracle.com> Hello Sergey , Please review update webrev link below :- The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.02/ Regards, Pooja On 7/16/2015 12:32 AM, Sergey Bylokhov wrote: > Hello, > I suggest to check support of systemTray at the beginning of the test. > > On 15.07.15 13:07, pooja chopra wrote: >> Hello , >> >> Corrected the webrev link below . Please review. >> >> Regards, >> Pooja >> On 7/15/2015 3:26 PM, pooja chopra wrote: >>> Hello, >>> >>> Please review a fix for issue :- >>> >>> 8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java >>> failed with UnsupportedOperation exception >>> Test bug fix. >>> https://bugs.openjdk.java.net/browse/JDK-8130481 >>> The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.01/ >>> >>> Regards, >>> Pooja >>> >> > > From pooja.chopra at oracle.com Wed Jul 29 07:00:50 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Wed, 29 Jul 2015 12:30:50 +0530 Subject: < Swing Dev> [9] Review Request: JDK-8081764 [TEST_BUG] Test javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Solaris Sparcv9 and Linux but passes on MacOSX In-Reply-To: <55794C6C.2030807@oracle.com> References: <5575670A.6060802@oracle.com> <5575678E.2080803@oracle.com> <55769992.6090505@oracle.com> <55794C6C.2030807@oracle.com> Message-ID: <55B87A22.3020207@oracle.com> Hi , As default look and feel in mac is aqua only so there is no need of setting system look and feel explicitly. Please review updated webrev link below:- 8081764 [TEST_BUG] Test javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Solaris Sparcv9 and Linux but passes on MacOSX Test bug fix. https://bugs.openjdk.java.net/browse/JDK-8081764 The webrev is : http://cr.openjdk.java.net/~pchopra/8081764/webrev.01/ Regards, Pooja On 6/11/2015 2:23 PM, pooja chopra wrote: > Hi Andrew , > The test passes with GTKLookAndFeel on Solaris but with out > GTKLookAndFeel test fails with same error as mentioned in the bug . I > had explicitly set the look and feel as system look and feel as test > was to be run for Mac only and this test was placed in plaf/aqua and > it is comparing screenshots so I thought in other look and feel there > can be a possibility that this matching fails. Please let me know if > some changes are required . > Regards, > Pooja > On 6/9/2015 1:15 PM, Andrew Brygin wrote: >> Hello Pooja, >> >> In general I tend to agree with idea to limit the scope of the test >> by macosx only. >> >> However, could you please clarify following questions: >> a) the test failure on linux/solaris: doesn't it indicate a similar >> problem with gtk laf, does it? >> b) what is purpose of the explicit LaF setup (lines 68 - 69)? >> >> Thanks, >> Andrew >> >> On 6/8/2015 12:59 PM, pooja chopra wrote: >>> Hi All, >>> Correcting the webrev link below . Please review below fix . >>> Regards, >>> Pooja >>> On 6/8/2015 3:27 PM, pooja chopra wrote: >>>> Hello, >>>> >>>> Please review a fix for issue :- >>>> 8081764 [TEST_BUG] Test >>>> javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Solaris >>>> Sparcv9 and Linux but passes on MacOSX >>>> Test bug fix. >>>> https://bugs.openjdk.java.net/browse/JDK-8081764 >>>> The webrev is : http://cr.openjdk.java.net/~pchopra/8081764/webrev.00 >>>> >>>> Regards, >>>> Pooja >>>> >>> >> > From Sergey.Bylokhov at oracle.com Wed Jul 29 10:30:37 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 29 Jul 2015 13:30:37 +0300 Subject: [8u-dev] Review request for 8130776: Remove EmbeddedFrame.requestFocusToEmbedder() method In-Reply-To: <55B0F6D5.9070905@oracle.com> References: <55B0F5AD.6030109@oracle.com> <55B0F6D5.9070905@oracle.com> Message-ID: <55B8AB4D.3040708@oracle.com> +1 On 23.07.15 17:14, Anton V. Tarasov wrote: > Looks fine to me. > > Regards, > Anton. > > On 23.07.2015 17:09, Alexey Ivanov wrote: >> Hello AWT team, >> >> Could you please review the backport of JDK-8130776 to jdk8u-dev: >> http://cr.openjdk.java.net/~aivanov/8130776/jdk8/webrev.00/ >> >> >> The patch from JDK9 does not apply cleanly because of different >> mechanism to access peer in WEmbeddedFrame.java. Logically there are >> no changes. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8130776 >> jdk9 webrev: http://cr.openjdk.java.net/~aivanov/8130776/jdk9/webrev.00/ >> jdk9 review thread: >> http://mail.openjdk.java.net/pipermail/awt-dev/2015-July/009667.html >> jdk9 changeset: >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/207a6ebae49d >> >> Thanks, >> Alexey > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Wed Jul 29 10:34:59 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 29 Jul 2015 13:34:59 +0300 Subject: < Swing Dev> [9] Review Request:JDK-8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java failed with UnsupportedOperation exception In-Reply-To: <55B86ECA.20306@oracle.com> References: <55A62E46.3020504@oracle.com> <55A630DE.4080500@oracle.com> <55A6AE5A.3060408@oracle.com> <55B86ECA.20306@oracle.com> Message-ID: <55B8AC53.3070103@oracle.com> On 7/29/2015 9:12 AM, pooja chopra wrote: > Hello Sergey , > Please review update webrev link below :- > > The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.02/ After the SystemTray.isSupported() is checked it is not expected that the UnsupportedOperationException is thrown. The test should fail in this case. Thanks, Alexandr. > > Regards, > Pooja > On 7/16/2015 12:32 AM, Sergey Bylokhov wrote: >> Hello, >> I suggest to check support of systemTray at the beginning of the test. >> >> On 15.07.15 13:07, pooja chopra wrote: >>> Hello , >>> >>> Corrected the webrev link below . Please review. >>> >>> Regards, >>> Pooja >>> On 7/15/2015 3:26 PM, pooja chopra wrote: >>>> Hello, >>>> >>>> Please review a fix for issue :- >>>> >>>> 8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java >>>> failed with UnsupportedOperation exception >>>> Test bug fix. >>>> https://bugs.openjdk.java.net/browse/JDK-8130481 >>>> The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.01/ >>>> >>>> Regards, >>>> Pooja >>>> >>> >> >> > From alexandr.scherbatiy at oracle.com Wed Jul 29 10:39:59 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 29 Jul 2015 13:39:59 +0300 Subject: < Swing Dev> [9] Review Request: JDK-8081764 [TEST_BUG] Test javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Solaris Sparcv9 and Linux but passes on MacOSX In-Reply-To: <55B87A22.3020207@oracle.com> References: <5575670A.6060802@oracle.com> <5575678E.2080803@oracle.com> <55769992.6090505@oracle.com> <55794C6C.2030807@oracle.com> <55B87A22.3020207@oracle.com> Message-ID: <55B8AD7F.6060102@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/29/2015 10:00 AM, pooja chopra wrote: > Hi , > As default look and feel in mac is aqua only so there is no need of > setting system look and feel explicitly. > > Please review updated webrev link below:- > > 8081764 [TEST_BUG] Test > javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Solaris > Sparcv9 and Linux but passes on MacOSX > Test bug fix. > https://bugs.openjdk.java.net/browse/JDK-8081764 > The webrev is : http://cr.openjdk.java.net/~pchopra/8081764/webrev.01/ > > Regards, > Pooja > > On 6/11/2015 2:23 PM, pooja chopra wrote: >> Hi Andrew , >> The test passes with GTKLookAndFeel on Solaris but with out >> GTKLookAndFeel test fails with same error as mentioned in the bug . I >> had explicitly set the look and feel as system look and feel as test >> was to be run for Mac only and this test was placed in plaf/aqua and >> it is comparing screenshots so I thought in other look and feel there >> can be a possibility that this matching fails. Please let me know if >> some changes are required . >> Regards, >> Pooja >> On 6/9/2015 1:15 PM, Andrew Brygin wrote: >>> Hello Pooja, >>> >>> In general I tend to agree with idea to limit the scope of the test >>> by macosx only. >>> >>> However, could you please clarify following questions: >>> a) the test failure on linux/solaris: doesn't it indicate a similar >>> problem with gtk laf, does it? >>> b) what is purpose of the explicit LaF setup (lines 68 - 69)? >>> >>> Thanks, >>> Andrew >>> >>> On 6/8/2015 12:59 PM, pooja chopra wrote: >>>> Hi All, >>>> Correcting the webrev link below . Please review below fix . >>>> Regards, >>>> Pooja >>>> On 6/8/2015 3:27 PM, pooja chopra wrote: >>>>> Hello, >>>>> >>>>> Please review a fix for issue :- >>>>> 8081764 [TEST_BUG] Test >>>>> javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on >>>>> Solaris Sparcv9 and Linux but passes on MacOSX >>>>> Test bug fix. >>>>> https://bugs.openjdk.java.net/browse/JDK-8081764 >>>>> The webrev is : http://cr.openjdk.java.net/~pchopra/8081764/webrev.00 >>>>> >>>>> Regards, >>>>> Pooja >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Wed Jul 29 11:06:46 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 29 Jul 2015 14:06:46 +0300 Subject: [9] Review Request for 8130471: [Regression] Test java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java fails In-Reply-To: <55B1309D.1050606@oracle.com> References: <55B1309D.1050606@oracle.com> Message-ID: <55B8B3C6.3020802@oracle.com> On 7/23/2015 9:21 PM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8130471 > webrev: http://cr.openjdk.java.net/~ssadetsky/8130471/webrev.00/ The initial name of the boolean variable in the getModifiers(...) method was wheel_mouse. Could you use name like isWheelMouse instead of the inverted one? Thanks, Alexandr. > > This is a regression from 8041470 in which mouse event modifiers was > changed for all wheel events including button click event. That caused > wrong modifiers for buttons 4 and 5 press/release/click mouse events. > The solution is to restore modifiers for click events keeping 8041470 > changes for scroll events. > > --Semyon From Sergey.Bylokhov at oracle.com Wed Jul 29 15:51:28 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 29 Jul 2015 18:51:28 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution Message-ID: <55B8F680.9000404@oracle.com> Hello. Please review the fix for jdk9. In the fix 8068886[1] the new native resources deallocation code assumes that we have a full control over the Cocoa NSApplication. This is incorrect in case of embedding, when NSApplication is controlled by swt or fx libraries. In the fix I add an additional check that the necessary selector exists in the current NSApp. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132382/webrev.02 -- Best regards, Sergey. From alexander.zuev at oracle.com Wed Jul 29 15:54:46 2015 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 29 Jul 2015 18:54:46 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55B8F680.9000404@oracle.com> References: <55B8F680.9000404@oracle.com> Message-ID: <55B8F746.2040400@oracle.com> Looks fine to me. /Alex On 29/07/15 18:51, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > > In the fix 8068886[1] the new native resources deallocation code > assumes that we have a full control over the Cocoa NSApplication. This > is incorrect in case of embedding, when NSApplication is controlled by > swt or fx libraries. In the fix I add an additional check that the > necessary selector exists in the current NSApp. > > [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe > > Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8132382/webrev.02 > From semyon.sadetsky at oracle.com Thu Jul 30 06:49:27 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 30 Jul 2015 09:49:27 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55B8F680.9000404@oracle.com> References: <55B8F680.9000404@oracle.com> Message-ID: <55B9C8F7.2010705@oracle.com> Hi Sergey, You've marked the bug as noreg-sqe. I could not find the existing test that crashes during the bug scenario. Could add this info? --Semyon On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > > In the fix 8068886[1] the new native resources deallocation code > assumes that we have a full control over the Cocoa NSApplication. This > is incorrect in case of embedding, when NSApplication is controlled by > swt or fx libraries. In the fix I add an additional check that the > necessary selector exists in the current NSApp. > > [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe > > Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8132382/webrev.02 > From alexandr.scherbatiy at oracle.com Thu Jul 30 08:34:11 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 30 Jul 2015 11:34:11 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55B8F746.2040400@oracle.com> References: <55B8F680.9000404@oracle.com> <55B8F746.2040400@oracle.com> Message-ID: <55B9E183.1030008@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/29/2015 6:54 PM, Alexander Zuev wrote: > Looks fine to me. > > /Alex > > On 29/07/15 18:51, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk9. >> >> In the fix 8068886[1] the new native resources deallocation code >> assumes that we have a full control over the Cocoa NSApplication. >> This is incorrect in case of embedding, when NSApplication is >> controlled by swt or fx libraries. In the fix I add an additional >> check that the necessary selector exists in the current NSApp. >> >> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8132382/webrev.02 >> > From alexandr.scherbatiy at oracle.com Thu Jul 30 11:08:16 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 30 Jul 2015 14:08:16 +0300 Subject: [9] Review request for 8131339[macosx] setMaximizedBounds() doesn't work for undecorated Frame In-Reply-To: <55B25B54.5030505@oracle.com> References: <55B250CA.3070404@oracle.com> <55B25B54.5030505@oracle.com> Message-ID: <55BA05A0.6060206@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8131339/webrev.01/ It is not necessary to add default getMaximizedBounds() method to the PlatformWindow so I reverted this change. Thanks, Alexandr. On 7/24/2015 6:35 PM, Sergey Bylokhov wrote: > The fix looks fine. > Please take a look to related regression of 8065739. The problem > occurs when you maximize Netbeans on osx 10.10 to the fullscreem > mode, then the upper side of the window is broken. > > On 24.07.15 17:50, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8131339 >> webrev: http://cr.openjdk.java.net/~alexsch/8131339/webrev.00 >> >> The maximize() method is updated for an undecorated Frame. >> >> Thanks, >> Alexandr. >> > > From yuri.nesterenko at oracle.com Thu Jul 30 13:13:27 2015 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 30 Jul 2015 16:13:27 +0300 Subject: [9] Review request for 6544871: java/awt/event/KeyEvent/KeyTyped/CtrlASCII.html fails from jdk b09 on windows Message-ID: <55BA22F7.7030105@oracle.com> Colleagues, please review this small test-only fix for https://bugs.openjdk.java.net/browse/JDK-6544871 Webrev: http://cr.openjdk.java.net/~yan/6544871/webrev.00 As a result, the test should pass on Windows without stray Ctrl keypress left in the keyboard buffer. Thanks, -yan From Sergey.Bylokhov at oracle.com Thu Jul 30 14:55:19 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 30 Jul 2015 17:55:19 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55B9C8F7.2010705@oracle.com> References: <55B8F680.9000404@oracle.com> <55B9C8F7.2010705@oracle.com> Message-ID: <55BA3AD7.1010504@oracle.com> Hi, Semyon. There are two tests which failed, see JMC-4034( jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). On 30.07.15 9:49, Semyon Sadetsky wrote: > Hi Sergey, > > You've marked the bug as noreg-sqe. I could not find the existing test > that crashes during the bug scenario. Could add this info? > > --Semyon > > On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk9. >> >> In the fix 8068886[1] the new native resources deallocation code >> assumes that we have a full control over the Cocoa NSApplication. >> This is incorrect in case of embedding, when NSApplication is >> controlled by swt or fx libraries. In the fix I add an additional >> check that the necessary selector exists in the current NSApp. >> >> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8132382/webrev.02 >> > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Jul 30 15:56:21 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 30 Jul 2015 18:56:21 +0300 Subject: [9] Review request for 6544871: java/awt/event/KeyEvent/KeyTyped/CtrlASCII.html fails from jdk b09 on windows In-Reply-To: <55BA22F7.7030105@oracle.com> References: <55BA22F7.7030105@oracle.com> Message-ID: <55BA4925.7000109@oracle.com> Looks fine. On 30.07.15 16:13, Yuri Nesterenko wrote: > Colleagues, > > please review this small test-only fix for > https://bugs.openjdk.java.net/browse/JDK-6544871 > > Webrev: > http://cr.openjdk.java.net/~yan/6544871/webrev.00 > > As a result, the test should pass on Windows without > stray Ctrl keypress left in the keyboard buffer. > > Thanks, > -yan -- Best regards, Sergey. From chsu79 at gmail.com Thu Jul 30 14:23:54 2015 From: chsu79 at gmail.com (Christian) Date: Thu, 30 Jul 2015 16:23:54 +0200 Subject: JDK-8015471 "Deadlock or infinit loop in XAWT on Ubuntu 12.04" Message-ID: Sorry if you dont want bug talk here, I just feel that i need to send some information somewhere. I'm talking about https://bugs.openjdk.java.net/browse/JDK-8015471 This exact issue happen to me quite frequently. I'm running the below jdk version, but it has happened during 1.7.0 jdks also. The bug is closed as not reproducable. java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) By running jstack -l on the jvm I see these threads in deadlock with each other. "AWT-EventQueue-0" #21 prio=6 os_prio=0 tid=0x00007fa8b05ec800 nid=0x316c waiting on condition [0x00007fa892e4f000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f064a248> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) at sun.awt.SunToolkit.awtLock(SunToolkit.java:253) at sun.awt.X11GraphicsDevice.getConfigVisualId(Native Method) at sun.awt.X11GraphicsDevice.makeDefaultConfiguration(X11GraphicsDevice.java:235) at sun.awt.X11GraphicsDevice.getDefaultConfiguration(X11GraphicsDevice.java:227) - locked <0x00000000f062a418> (a java.lang.Object) at javax.swing.RepaintManager.getDoubleBufferMaximumSize(RepaintManager.java:1153) at javax.swing.RepaintManager.getVolatileOffscreenBuffer(RepaintManager.java:1035) at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1482) at javax.swing.RepaintManager.paint(RepaintManager.java:1265) at javax.swing.JComponent.paint(JComponent.java:1042) at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39) at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79) at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116) at java.awt.Container.paint(Container.java:1973) at java.awt.Window.paint(Window.java:3912) at javax.swing.RepaintManager$4.run(RepaintManager.java:835) at javax.swing.RepaintManager$4.run(RepaintManager.java:807) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:807) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:782) at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:731) at javax.swing.RepaintManager.access$1300(RepaintManager.java:64) at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1720) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:726) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) Locked ownable synchronizers: - None "AWT-Shutdown" #22 prio=5 os_prio=0 tid=0x00007fa8b05eb000 nid=0x316b in Object.wait() [0x00007fa892f53000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000f0649ad8> (a java.lang.Object) at java.lang.Object.wait(Object.java:502) at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:295) - locked <0x00000000f0649ad8> (a java.lang.Object) at java.lang.Thread.run(Thread.java:745) Locked ownable synchronizers: - None "AWT-XAWT" #20 daemon prio=6 os_prio=0 tid=0x00007fa8b05c1000 nid=0x316a waiting for monitor entry [0x00007fa893054000] java.lang.Thread.State: BLOCKED (on object monitor) at sun.awt.X11GraphicsDevice.getDefaultConfiguration(X11GraphicsDevice.java:227) - waiting to lock <0x00000000f062a418> (a java.lang.Object) at sun.awt.X11.XWindowPeer.checkIfOnNewScreen(XWindowPeer.java:683) at sun.awt.X11.XDecoratedPeer.handleConfigureNotifyEvent(XDecoratedPeer.java:756) at sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1135) at sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1090) at sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:502) at sun.awt.X11.XToolkit.run(XToolkit.java:611) at sun.awt.X11.XToolkit.run(XToolkit.java:532) at java.lang.Thread.run(Thread.java:745) Locked ownable synchronizers: - <0x00000000f064a248> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) I noticed a comment from the name Denis Fokin (below) that points out that it is dual-monitor configuration related, and I am also running a dual-monitor setup. Could explain failure to reproduce by others? https://youtrack.jetbrains.com/issue/IDEA-122147 >From what I can see in source the "AWT-XAWT" thread takes the awt lock in this call frame at sun.awt.X11.XToolkit.run(XToolkit.java:611) and the "AWT-EventQueue-0" thread is trying to take the very same lock while lazily creating the DefaultConfiguration for the first time. The issue seems to be timing sensitive. I have not been trying to find a place to insert some extra delay to reproduce it every time. But I get it about 10-20% of the times when I start our awt/swing app. If that DefaultConfiguration could be created before AWT-XAWT gets around to dispatching events where it holds the awt lock I believe the issue would not occur. Maybe our code is doing something incorrectly at startup that would make sure that this DefaultConfiguration is not lazily created before the fact, and that explains why this bug has gone unreproducible such a long time by people who know what they're doing? I hope I havent made a fool of myself and this bug is fixed already, taking your time for no good, I know im not running the cutting jdk edge version. I just felt I'd take some time and figure out what actually happens when my app pops up with a gray empty window. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Thu Jul 30 16:41:00 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 30 Jul 2015 19:41:00 +0300 Subject: JDK-8015471 "Deadlock or infinit loop in XAWT on Ubuntu 12.04" In-Reply-To: References: Message-ID: <55BA539C.6010507@oracle.com> Hi Cristian, it looks like that I've already fixed this issue as [1] Could you please check if the problem is gone with 8u60? [1] https://bugs.openjdk.java.net/browse/JDK-8129116 Deadlock with multimonitor fullscreen windows. Thanks, Alexander. On 07/30/2015 05:23 PM, Christian wrote: > Sorry if you dont want bug talk here, I just feel that i need to send > some information somewhere. I'm talking about > > https://bugs.openjdk.java.net/browse/JDK-8015471 > > This exact issue happen to me quite frequently. I'm running the below > jdk version, but it has happened during 1.7.0 jdks also. The bug is > closed as not reproducable. > > java version "1.8.0_45" > Java(TM) SE Runtime Environment (build 1.8.0_45-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) > > By running jstack -l on the jvm I see these threads in deadlock with > each other. > > "AWT-EventQueue-0" #21 prio=6 os_prio=0 tid=0x00007fa8b05ec800 > nid=0x316c waiting on condition [0x00007fa892e4f000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000f064a248> (a > java.util.concurrent.locks.ReentrantLock$NonfairSync) > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) > at > java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) > at > java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) > at sun.awt.SunToolkit.awtLock(SunToolkit.java:253) > at sun.awt.X11GraphicsDevice.getConfigVisualId(Native Method) > at > sun.awt.X11GraphicsDevice.makeDefaultConfiguration(X11GraphicsDevice.java:235) > at > sun.awt.X11GraphicsDevice.getDefaultConfiguration(X11GraphicsDevice.java:227) > - locked <0x00000000f062a418> (a java.lang.Object) > at > javax.swing.RepaintManager.getDoubleBufferMaximumSize(RepaintManager.java:1153) > at > javax.swing.RepaintManager.getVolatileOffscreenBuffer(RepaintManager.java:1035) > at > javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1482) > at javax.swing.RepaintManager.paint(RepaintManager.java:1265) > at javax.swing.JComponent.paint(JComponent.java:1042) > at > java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39) > at > sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79) > at > sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116) > at java.awt.Container.paint(Container.java:1973) > at java.awt.Window.paint(Window.java:3912) > at javax.swing.RepaintManager$4.run(RepaintManager.java:835) > at javax.swing.RepaintManager$4.run(RepaintManager.java:807) > at java.security.AccessController.doPrivileged(Native Method) > at > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) > at > javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:807) > at > javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:782) > at > javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:731) > at javax.swing.RepaintManager.access$1300(RepaintManager.java:64) > at > javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1720) > at > java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756) > at java.awt.EventQueue.access$500(EventQueue.java:97) > at java.awt.EventQueue$3.run(EventQueue.java:709) > at java.awt.EventQueue$3.run(EventQueue.java:703) > at java.security.AccessController.doPrivileged(Native Method) > at > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:726) > at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > > Locked ownable synchronizers: > - None > > "AWT-Shutdown" #22 prio=5 os_prio=0 tid=0x00007fa8b05eb000 nid=0x316b > in Object.wait() [0x00007fa892f53000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000f0649ad8> (a java.lang.Object) > at java.lang.Object.wait(Object.java:502) > at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:295) > - locked <0x00000000f0649ad8> (a java.lang.Object) > at java.lang.Thread.run(Thread.java:745) > > Locked ownable synchronizers: > - None > > "AWT-XAWT" #20 daemon prio=6 os_prio=0 tid=0x00007fa8b05c1000 > nid=0x316a waiting for monitor entry [0x00007fa893054000] > java.lang.Thread.State: BLOCKED (on object monitor) > at > sun.awt.X11GraphicsDevice.getDefaultConfiguration(X11GraphicsDevice.java:227) > - waiting to lock <0x00000000f062a418> (a java.lang.Object) > at > sun.awt.X11.XWindowPeer.checkIfOnNewScreen(XWindowPeer.java:683) > at > sun.awt.X11.XDecoratedPeer.handleConfigureNotifyEvent(XDecoratedPeer.java:756) > at sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1135) > at sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1090) > at sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:502) > at sun.awt.X11.XToolkit.run(XToolkit.java:611) > at sun.awt.X11.XToolkit.run(XToolkit.java:532) > at java.lang.Thread.run(Thread.java:745) > > Locked ownable synchronizers: > - <0x00000000f064a248> (a > java.util.concurrent.locks.ReentrantLock$NonfairSync) > > > I noticed a comment from the name Denis Fokin (below) that points out > that it is dual-monitor configuration related, and I am also running a > dual-monitor setup. Could explain failure to reproduce by others? > > https://youtrack.jetbrains.com/issue/IDEA-122147 > > From what I can see in source the "AWT-XAWT" thread takes the awt lock > in this call frame > > at sun.awt.X11.XToolkit.run(XToolkit.java:611) > > and the "AWT-EventQueue-0" thread is trying to take the very same lock > while lazily creating the DefaultConfiguration for the first time. > > The issue seems to be timing sensitive. I have not been trying to find > a place to insert some extra delay to reproduce it every time. But I > get it about 10-20% of the times when I start our awt/swing app. > > If that DefaultConfiguration could be created before AWT-XAWT gets > around to dispatching events where it holds the awt lock I believe the > issue would not occur. > > Maybe our code is doing something incorrectly at startup that would > make sure that this DefaultConfiguration is not lazily created before > the fact, and that explains why this bug has gone unreproducible such > a long time by people who know what they're doing? > > I hope I havent made a fool of myself and this bug is fixed already, > taking your time for no good, I know im not running the cutting jdk > edge version. I just felt I'd take some time and figure out what > actually happens when my app pops up with a gray empty window. > > > > > > From semyon.sadetsky at oracle.com Fri Jul 31 07:30:12 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 31 Jul 2015 10:30:12 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55BA3AD7.1010504@oracle.com> References: <55B8F680.9000404@oracle.com> <55B9C8F7.2010705@oracle.com> <55BA3AD7.1010504@oracle.com> Message-ID: <55BB2404.6020306@oracle.com> JMC-4034 is not an OpenJDK project. Souldn't this test be copied to the client-libs test base? JDK-8132469 description contains manual steps executed using SwingSet2, right? --Semyon On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: > Hi, Semyon. > There are two tests which failed, see JMC-4034( jmc_plugintest/swt > case) and JDK-8132469(swingnode/fx case). > > On 30.07.15 9:49, Semyon Sadetsky wrote: >> Hi Sergey, >> >> You've marked the bug as noreg-sqe. I could not find the existing >> test that crashes during the bug scenario. Could add this info? >> >> --Semyon >> >> On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk9. >>> >>> In the fix 8068886[1] the new native resources deallocation code >>> assumes that we have a full control over the Cocoa NSApplication. >>> This is incorrect in case of embedding, when NSApplication is >>> controlled by swt or fx libraries. In the fix I add an additional >>> check that the necessary selector exists in the current NSApp. >>> >>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8132382/webrev.02 >>> >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Jul 31 08:52:50 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 31 Jul 2015 11:52:50 +0300 Subject: [9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity Message-ID: <55BB3762.1070102@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8011616 webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ WM sends the real window position in the configuration event but window peer does not set it to the target. Solution is: do set. --Semyon From alexandr.scherbatiy at oracle.com Fri Jul 31 10:22:21 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 31 Jul 2015 13:22:21 +0300 Subject: [9] Review request for 6544871: java/awt/event/KeyEvent/KeyTyped/CtrlASCII.html fails from jdk b09 on windows In-Reply-To: <55BA4925.7000109@oracle.com> References: <55BA22F7.7030105@oracle.com> <55BA4925.7000109@oracle.com> Message-ID: <55BB4C5D.9070700@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/30/2015 6:56 PM, Sergey Bylokhov wrote: > Looks fine. > > On 30.07.15 16:13, Yuri Nesterenko wrote: >> Colleagues, >> >> please review this small test-only fix for >> https://bugs.openjdk.java.net/browse/JDK-6544871 >> >> Webrev: >> http://cr.openjdk.java.net/~yan/6544871/webrev.00 >> >> As a result, the test should pass on Windows without >> stray Ctrl keypress left in the keyboard buffer. >> >> Thanks, >> -yan > > From chsu79 at gmail.com Fri Jul 31 12:27:33 2015 From: chsu79 at gmail.com (Christian) Date: Fri, 31 Jul 2015 14:27:33 +0200 Subject: JDK-8015471 "Deadlock or infinit loop in XAWT on Ubuntu 12.04" In-Reply-To: <55BA539C.6010507@oracle.com> References: <55BA539C.6010507@oracle.com> Message-ID: I tried to reproduce it, first by starting my app 20 times using this version. Five times I got a gray window. java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) Then the same test on this version, and success all 20 times! java version "1.8.0_60-ea" Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) Now it could be luck that it didnt happen, but I also see what you have done there, by releasing the awtLock in the XPeerWindow while getDefaultConfig goes for the other lock that deadlocked. Thanks for a nice fix! On Thu, Jul 30, 2015 at 6:41 PM, Alexander Zvegintsev < alexander.zvegintsev at oracle.com> wrote: > Hi Cristian, > > it looks like that I've already fixed this issue as [1] > Could you please check if the problem is gone with 8u60? > > [1] https://bugs.openjdk.java.net/browse/JDK-8129116 Deadlock with > multimonitor fullscreen windows. > > Thanks, > > Alexander. > > On 07/30/2015 05:23 PM, Christian wrote: > >> Sorry if you dont want bug talk here, I just feel that i need to send >> some information somewhere. I'm talking about >> >> https://bugs.openjdk.java.net/browse/JDK-8015471 >> >> This exact issue happen to me quite frequently. I'm running the below jdk >> version, but it has happened during 1.7.0 jdks also. The bug is closed as >> not reproducable. >> >> java version "1.8.0_45" >> Java(TM) SE Runtime Environment (build 1.8.0_45-b14) >> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) >> >> By running jstack -l on the jvm I see these threads in deadlock with each >> other. >> >> "AWT-EventQueue-0" #21 prio=6 os_prio=0 tid=0x00007fa8b05ec800 nid=0x316c >> waiting on condition [0x00007fa892e4f000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000000f064a248> (a >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) >> at >> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) >> at >> java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) >> at sun.awt.SunToolkit.awtLock(SunToolkit.java:253) >> at sun.awt.X11GraphicsDevice.getConfigVisualId(Native Method) >> at >> sun.awt.X11GraphicsDevice.makeDefaultConfiguration(X11GraphicsDevice.java:235) >> at >> sun.awt.X11GraphicsDevice.getDefaultConfiguration(X11GraphicsDevice.java:227) >> - locked <0x00000000f062a418> (a java.lang.Object) >> at >> javax.swing.RepaintManager.getDoubleBufferMaximumSize(RepaintManager.java:1153) >> at >> javax.swing.RepaintManager.getVolatileOffscreenBuffer(RepaintManager.java:1035) >> at >> javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1482) >> at javax.swing.RepaintManager.paint(RepaintManager.java:1265) >> at javax.swing.JComponent.paint(JComponent.java:1042) >> at >> java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39) >> at >> sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79) >> at >> sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116) >> at java.awt.Container.paint(Container.java:1973) >> at java.awt.Window.paint(Window.java:3912) >> at javax.swing.RepaintManager$4.run(RepaintManager.java:835) >> at javax.swing.RepaintManager$4.run(RepaintManager.java:807) >> at java.security.AccessController.doPrivileged(Native Method) >> at >> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) >> at >> javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:807) >> at >> javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:782) >> at >> javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:731) >> at javax.swing.RepaintManager.access$1300(RepaintManager.java:64) >> at >> javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1720) >> at >> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) >> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756) >> at java.awt.EventQueue.access$500(EventQueue.java:97) >> at java.awt.EventQueue$3.run(EventQueue.java:709) >> at java.awt.EventQueue$3.run(EventQueue.java:703) >> at java.security.AccessController.doPrivileged(Native Method) >> at >> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) >> at java.awt.EventQueue.dispatchEvent(EventQueue.java:726) >> at >> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) >> at >> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) >> at >> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >> >> Locked ownable synchronizers: >> - None >> >> "AWT-Shutdown" #22 prio=5 os_prio=0 tid=0x00007fa8b05eb000 nid=0x316b in >> Object.wait() [0x00007fa892f53000] >> java.lang.Thread.State: WAITING (on object monitor) >> at java.lang.Object.wait(Native Method) >> - waiting on <0x00000000f0649ad8> (a java.lang.Object) >> at java.lang.Object.wait(Object.java:502) >> at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:295) >> - locked <0x00000000f0649ad8> (a java.lang.Object) >> at java.lang.Thread.run(Thread.java:745) >> >> Locked ownable synchronizers: >> - None >> >> "AWT-XAWT" #20 daemon prio=6 os_prio=0 tid=0x00007fa8b05c1000 nid=0x316a >> waiting for monitor entry [0x00007fa893054000] >> java.lang.Thread.State: BLOCKED (on object monitor) >> at >> sun.awt.X11GraphicsDevice.getDefaultConfiguration(X11GraphicsDevice.java:227) >> - waiting to lock <0x00000000f062a418> (a java.lang.Object) >> at >> sun.awt.X11.XWindowPeer.checkIfOnNewScreen(XWindowPeer.java:683) >> at >> sun.awt.X11.XDecoratedPeer.handleConfigureNotifyEvent(XDecoratedPeer.java:756) >> at sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1135) >> at sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1090) >> at sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:502) >> at sun.awt.X11.XToolkit.run(XToolkit.java:611) >> at sun.awt.X11.XToolkit.run(XToolkit.java:532) >> at java.lang.Thread.run(Thread.java:745) >> >> Locked ownable synchronizers: >> - <0x00000000f064a248> (a >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >> >> >> I noticed a comment from the name Denis Fokin (below) that points out >> that it is dual-monitor configuration related, and I am also running a >> dual-monitor setup. Could explain failure to reproduce by others? >> >> https://youtrack.jetbrains.com/issue/IDEA-122147 >> >> From what I can see in source the "AWT-XAWT" thread takes the awt lock in >> this call frame >> >> at sun.awt.X11.XToolkit.run(XToolkit.java:611) >> >> and the "AWT-EventQueue-0" thread is trying to take the very same lock >> while lazily creating the DefaultConfiguration for the first time. >> >> The issue seems to be timing sensitive. I have not been trying to find a >> place to insert some extra delay to reproduce it every time. But I get it >> about 10-20% of the times when I start our awt/swing app. >> >> If that DefaultConfiguration could be created before AWT-XAWT gets around >> to dispatching events where it holds the awt lock I believe the issue would >> not occur. >> >> Maybe our code is doing something incorrectly at startup that would make >> sure that this DefaultConfiguration is not lazily created before the fact, >> and that explains why this bug has gone unreproducible such a long time by >> people who know what they're doing? >> >> I hope I havent made a fool of myself and this bug is fixed already, >> taking your time for no good, I know im not running the cutting jdk edge >> version. I just felt I'd take some time and figure out what actually >> happens when my app pops up with a gray empty window. >> >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jul 31 12:37:25 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 31 Jul 2015 15:37:25 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55BB2404.6020306@oracle.com> References: <55B8F680.9000404@oracle.com> <55B9C8F7.2010705@oracle.com> <55BA3AD7.1010504@oracle.com> <55BB2404.6020306@oracle.com> Message-ID: <55BB6C05.2040103@oracle.com> On 31.07.15 10:30, Semyon Sadetsky wrote: > JMC-4034 is not an OpenJDK project. Souldn't this test be copied to > the client-libs test base? > JDK-8132469 description contains manual steps executed using > SwingSet2, right? All sqe tests is not a part of openjdk project. These particular tests cannot be copied to our ws because they are depend from the external java libraries, which require some manual configuration. > > --Semyon > > > On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: >> Hi, Semyon. >> There are two tests which failed, see JMC-4034( jmc_plugintest/swt >> case) and JDK-8132469(swingnode/fx case). >> >> On 30.07.15 9:49, Semyon Sadetsky wrote: >>> Hi Sergey, >>> >>> You've marked the bug as noreg-sqe. I could not find the existing >>> test that crashes during the bug scenario. Could add this info? >>> >>> --Semyon >>> >>> On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review the fix for jdk9. >>>> >>>> In the fix 8068886[1] the new native resources deallocation code >>>> assumes that we have a full control over the Cocoa NSApplication. >>>> This is incorrect in case of embedding, when NSApplication is >>>> controlled by swt or fx libraries. In the fix I add an additional >>>> check that the necessary selector exists in the current NSApp. >>>> >>>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/8132382/webrev.02 >>>> >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Jul 31 13:07:54 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 31 Jul 2015 16:07:54 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55BB6C05.2040103@oracle.com> References: <55B8F680.9000404@oracle.com> <55B9C8F7.2010705@oracle.com> <55BA3AD7.1010504@oracle.com> <55BB2404.6020306@oracle.com> <55BB6C05.2040103@oracle.com> Message-ID: <55BB732A.2040707@oracle.com> Is it possible to reproduce the scenario using simple native application which embeds the Java VM? On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: > On 31.07.15 10:30, Semyon Sadetsky wrote: >> JMC-4034 is not an OpenJDK project. Souldn't this test be copied to >> the client-libs test base? >> JDK-8132469 description contains manual steps executed using >> SwingSet2, right? > All sqe tests is not a part of openjdk project. These particular tests > cannot be copied to our ws because they are depend from the external > java libraries, which require some manual configuration. > >> >> --Semyon >> >> >> On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: >>> Hi, Semyon. >>> There are two tests which failed, see JMC-4034( jmc_plugintest/swt >>> case) and JDK-8132469(swingnode/fx case). >>> >>> On 30.07.15 9:49, Semyon Sadetsky wrote: >>>> Hi Sergey, >>>> >>>> You've marked the bug as noreg-sqe. I could not find the existing >>>> test that crashes during the bug scenario. Could add this info? >>>> >>>> --Semyon >>>> >>>> On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: >>>>> Hello. >>>>> Please review the fix for jdk9. >>>>> >>>>> In the fix 8068886[1] the new native resources deallocation code >>>>> assumes that we have a full control over the Cocoa NSApplication. >>>>> This is incorrect in case of embedding, when NSApplication is >>>>> controlled by swt or fx libraries. In the fix I add an additional >>>>> check that the necessary selector exists in the current NSApp. >>>>> >>>>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/8132382/webrev.02 >>>>> >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jul 31 13:14:18 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 31 Jul 2015 16:14:18 +0300 Subject: [9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity In-Reply-To: <55BB3762.1070102@oracle.com> References: <55BB3762.1070102@oracle.com> Message-ID: <55BB74AA.2040407@oracle.com> Hi, Semyon. A few questions. - Why only location is fixed, an update of size if not necessary(if for some reason the size was changed by the system like location in this case)? - Note that we should update the target state before we post an event that the size is changed(we post them in XWindow.handleConfigureNotifyEvent). It seems that some of the peers has utility methods for this(like XDecoratedPeer.handleMoved). On 31.07.15 11:52, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > bug: https://bugs.openjdk.java.net/browse/JDK-8011616 > webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ > > WM sends the real window position in the configuration event but > window peer does not set it to the target. Solution is: do set. > > --Semyon -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jul 31 13:37:16 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 31 Jul 2015 16:37:16 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55BB732A.2040707@oracle.com> References: <55B8F680.9000404@oracle.com> <55B9C8F7.2010705@oracle.com> <55BA3AD7.1010504@oracle.com> <55BB2404.6020306@oracle.com> <55BB6C05.2040103@oracle.com> <55BB732A.2040707@oracle.com> Message-ID: <55BB7A0C.2000304@oracle.com> Yes, it is possible if this simple native application emulate initialization of these libraries. On 31.07.15 16:07, Semyon Sadetsky wrote: > Is it possible to reproduce the scenario using simple native > application which embeds the Java VM? > > On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: >> On 31.07.15 10:30, Semyon Sadetsky wrote: >>> JMC-4034 is not an OpenJDK project. Souldn't this test be copied to >>> the client-libs test base? >>> JDK-8132469 description contains manual steps executed using >>> SwingSet2, right? >> All sqe tests is not a part of openjdk project. These particular >> tests cannot be copied to our ws because they are depend from the >> external java libraries, which require some manual configuration. >> >>> >>> --Semyon >>> >>> >>> On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: >>>> Hi, Semyon. >>>> There are two tests which failed, see JMC-4034( jmc_plugintest/swt >>>> case) and JDK-8132469(swingnode/fx case). >>>> >>>> On 30.07.15 9:49, Semyon Sadetsky wrote: >>>>> Hi Sergey, >>>>> >>>>> You've marked the bug as noreg-sqe. I could not find the existing >>>>> test that crashes during the bug scenario. Could add this info? >>>>> >>>>> --Semyon >>>>> >>>>> On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: >>>>>> Hello. >>>>>> Please review the fix for jdk9. >>>>>> >>>>>> In the fix 8068886[1] the new native resources deallocation code >>>>>> assumes that we have a full control over the Cocoa NSApplication. >>>>>> This is incorrect in case of embedding, when NSApplication is >>>>>> controlled by swt or fx libraries. In the fix I add an additional >>>>>> check that the necessary selector exists in the current NSApp. >>>>>> >>>>>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 >>>>>> Webrev can be found at: >>>>>> http://cr.openjdk.java.net/~serb/8132382/webrev.02 >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Jul 31 13:51:42 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 31 Jul 2015 16:51:42 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55BB7A0C.2000304@oracle.com> References: <55B8F680.9000404@oracle.com> <55B9C8F7.2010705@oracle.com> <55BA3AD7.1010504@oracle.com> <55BB2404.6020306@oracle.com> <55BB6C05.2040103@oracle.com> <55BB732A.2040707@oracle.com> <55BB7A0C.2000304@oracle.com> Message-ID: <55BB7D6E.60307@oracle.com> There are plenty classes extending CFRetainedResource, TryIcon for example. Will disposing them cause the same issue inside the native app? On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: > Yes, it is possible if this simple native application emulate > initialization of these libraries. > > On 31.07.15 16:07, Semyon Sadetsky wrote: >> Is it possible to reproduce the scenario using simple native >> application which embeds the Java VM? >> >> On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: >>> On 31.07.15 10:30, Semyon Sadetsky wrote: >>>> JMC-4034 is not an OpenJDK project. Souldn't this test be copied to >>>> the client-libs test base? >>>> JDK-8132469 description contains manual steps executed using >>>> SwingSet2, right? >>> All sqe tests is not a part of openjdk project. These particular >>> tests cannot be copied to our ws because they are depend from the >>> external java libraries, which require some manual configuration. >>> >>>> >>>> --Semyon >>>> >>>> >>>> On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: >>>>> Hi, Semyon. >>>>> There are two tests which failed, see JMC-4034( jmc_plugintest/swt >>>>> case) and JDK-8132469(swingnode/fx case). >>>>> >>>>> On 30.07.15 9:49, Semyon Sadetsky wrote: >>>>>> Hi Sergey, >>>>>> >>>>>> You've marked the bug as noreg-sqe. I could not find the existing >>>>>> test that crashes during the bug scenario. Could add this info? >>>>>> >>>>>> --Semyon >>>>>> >>>>>> On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: >>>>>>> Hello. >>>>>>> Please review the fix for jdk9. >>>>>>> >>>>>>> In the fix 8068886[1] the new native resources deallocation code >>>>>>> assumes that we have a full control over the Cocoa >>>>>>> NSApplication. This is incorrect in case of embedding, when >>>>>>> NSApplication is controlled by swt or fx libraries. In the fix I >>>>>>> add an additional check that the necessary selector exists in >>>>>>> the current NSApp. >>>>>>> >>>>>>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 >>>>>>> Webrev can be found at: >>>>>>> http://cr.openjdk.java.net/~serb/8132382/webrev.02 >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jul 31 14:18:10 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 31 Jul 2015 17:18:10 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55BB7D6E.60307@oracle.com> References: <55B8F680.9000404@oracle.com> <55B9C8F7.2010705@oracle.com> <55BA3AD7.1010504@oracle.com> <55BB2404.6020306@oracle.com> <55BB6C05.2040103@oracle.com> <55BB732A.2040707@oracle.com> <55BB7A0C.2000304@oracle.com> <55BB7D6E.60307@oracle.com> Message-ID: <55BB83A2.4090507@oracle.com> On 31.07.15 16:51, Semyon Sadetsky wrote: > There are plenty classes extending CFRetainedResource, TryIcon for > example. Will disposing them cause the same issue inside the native app? The crash occurs when any of these subclasses will be disposed, in some cases app will crash immediately, in other cases the app will crash after the objects will be gc. > On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: >> Yes, it is possible if this simple native application emulate >> initialization of these libraries. >> >> On 31.07.15 16:07, Semyon Sadetsky wrote: >>> Is it possible to reproduce the scenario using simple native >>> application which embeds the Java VM? >>> >>> On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: >>>> On 31.07.15 10:30, Semyon Sadetsky wrote: >>>>> JMC-4034 is not an OpenJDK project. Souldn't this test be copied >>>>> to the client-libs test base? >>>>> JDK-8132469 description contains manual steps executed using >>>>> SwingSet2, right? >>>> All sqe tests is not a part of openjdk project. These particular >>>> tests cannot be copied to our ws because they are depend from the >>>> external java libraries, which require some manual configuration. >>>> >>>>> >>>>> --Semyon >>>>> >>>>> >>>>> On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: >>>>>> Hi, Semyon. >>>>>> There are two tests which failed, see JMC-4034( >>>>>> jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). >>>>>> >>>>>> On 30.07.15 9:49, Semyon Sadetsky wrote: >>>>>>> Hi Sergey, >>>>>>> >>>>>>> You've marked the bug as noreg-sqe. I could not find the >>>>>>> existing test that crashes during the bug scenario. Could add >>>>>>> this info? >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: >>>>>>>> Hello. >>>>>>>> Please review the fix for jdk9. >>>>>>>> >>>>>>>> In the fix 8068886[1] the new native resources deallocation >>>>>>>> code assumes that we have a full control over the Cocoa >>>>>>>> NSApplication. This is incorrect in case of embedding, when >>>>>>>> NSApplication is controlled by swt or fx libraries. In the fix >>>>>>>> I add an additional check that the necessary selector exists in >>>>>>>> the current NSApp. >>>>>>>> >>>>>>>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 >>>>>>>> Webrev can be found at: >>>>>>>> http://cr.openjdk.java.net/~serb/8132382/webrev.02 >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Jul 31 14:19:28 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 31 Jul 2015 17:19:28 +0300 Subject: [9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity In-Reply-To: <55BB74AA.2040407@oracle.com> References: <55BB3762.1070102@oracle.com> <55BB74AA.2040407@oracle.com> Message-ID: <55BB83F0.4050505@oracle.com> Hi Sergey, - size remains unchanged on other platforms as well. I'm not sure that there should be exception for window peer on Linux. Do you have any solid info on that? - the utility method was introduced because decorated window can be moved and it is utilized from several places. It is not the case for undecorated window. Not sure that container screen position makes any sense for its content size event. Is it specified somewhere? Or can you provide an example when it is necessary? --Semyon On 7/31/2015 4:14 PM, Sergey Bylokhov wrote: > Hi, Semyon. > A few questions. > - Why only location is fixed, an update of size if not necessary(if > for some reason the size was changed by the system like location in > this case)? > - Note that we should update the target state before we post an event > that the size is changed(we post them in > XWindow.handleConfigureNotifyEvent). It seems that some of the peers > has utility methods for this(like XDecoratedPeer.handleMoved). > > On 31.07.15 11:52, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> bug: https://bugs.openjdk.java.net/browse/JDK-8011616 >> webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ >> >> WM sends the real window position in the configuration event but >> window peer does not set it to the target. Solution is: do set. >> >> --Semyon > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Jul 31 14:29:05 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 31 Jul 2015 17:29:05 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55BB83A2.4090507@oracle.com> References: <55B8F680.9000404@oracle.com> <55B9C8F7.2010705@oracle.com> <55BA3AD7.1010504@oracle.com> <55BB2404.6020306@oracle.com> <55BB6C05.2040103@oracle.com> <55BB732A.2040707@oracle.com> <55BB7A0C.2000304@oracle.com> <55BB7D6E.60307@oracle.com> <55BB83A2.4090507@oracle.com> Message-ID: <55BB8631.2020105@oracle.com> So the test could use one of these java resources inside the native app without any external libraries only using JNI library, right? On 7/31/2015 5:18 PM, Sergey Bylokhov wrote: > On 31.07.15 16:51, Semyon Sadetsky wrote: >> There are plenty classes extending CFRetainedResource, TryIcon for >> example. Will disposing them cause the same issue inside the native app? > The crash occurs when any of these subclasses will be disposed, in > some cases app will crash immediately, in other cases the app will > crash after the objects will be gc. > >> On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: >>> Yes, it is possible if this simple native application emulate >>> initialization of these libraries. >>> >>> On 31.07.15 16:07, Semyon Sadetsky wrote: >>>> Is it possible to reproduce the scenario using simple native >>>> application which embeds the Java VM? >>>> >>>> On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: >>>>> On 31.07.15 10:30, Semyon Sadetsky wrote: >>>>>> JMC-4034 is not an OpenJDK project. Souldn't this test be copied >>>>>> to the client-libs test base? >>>>>> JDK-8132469 description contains manual steps executed using >>>>>> SwingSet2, right? >>>>> All sqe tests is not a part of openjdk project. These particular >>>>> tests cannot be copied to our ws because they are depend from the >>>>> external java libraries, which require some manual configuration. >>>>> >>>>>> >>>>>> --Semyon >>>>>> >>>>>> >>>>>> On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: >>>>>>> Hi, Semyon. >>>>>>> There are two tests which failed, see JMC-4034( >>>>>>> jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). >>>>>>> >>>>>>> On 30.07.15 9:49, Semyon Sadetsky wrote: >>>>>>>> Hi Sergey, >>>>>>>> >>>>>>>> You've marked the bug as noreg-sqe. I could not find the >>>>>>>> existing test that crashes during the bug scenario. Could add >>>>>>>> this info? >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: >>>>>>>>> Hello. >>>>>>>>> Please review the fix for jdk9. >>>>>>>>> >>>>>>>>> In the fix 8068886[1] the new native resources deallocation >>>>>>>>> code assumes that we have a full control over the Cocoa >>>>>>>>> NSApplication. This is incorrect in case of embedding, when >>>>>>>>> NSApplication is controlled by swt or fx libraries. In the fix >>>>>>>>> I add an additional check that the necessary selector exists >>>>>>>>> in the current NSApp. >>>>>>>>> >>>>>>>>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 >>>>>>>>> Webrev can be found at: >>>>>>>>> http://cr.openjdk.java.net/~serb/8132382/webrev.02 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jul 31 14:39:19 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 31 Jul 2015 17:39:19 +0300 Subject: [9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity In-Reply-To: <55BB83F0.4050505@oracle.com> References: <55BB3762.1070102@oracle.com> <55BB74AA.2040407@oracle.com> <55BB83F0.4050505@oracle.com> Message-ID: <55BB8897.9090305@oracle.com> On 31.07.15 17:19, Semyon Sadetsky wrote: > Hi Sergey, > > - size remains unchanged on other platforms as well. I'm not sure that > there should be exception for window peer on Linux. Do you have any > solid info on that? On OSX it is changed in LWWindowPeer.notifyReshape. On windows is changed in awt_Window.cpp. WmMove In general window manager can set a different size/location than we try to set, so we should take a correct values in the callback and update the target component, and after that post event that the bounds was changed. > - the utility method was introduced because decorated window can be > moved and it is utilized from several places. It is not the case for > undecorated window. It can be moved by the window manager. > Not sure that container screen position makes any sense for its > content size event. Is it specified somewhere? Or can you provide an > example when it is necessary? I am not sure. It needs to be checked. > > --Semyon > > On 7/31/2015 4:14 PM, Sergey Bylokhov wrote: >> Hi, Semyon. >> A few questions. >> - Why only location is fixed, an update of size if not necessary(if >> for some reason the size was changed by the system like location in >> this case)? >> - Note that we should update the target state before we post an >> event that the size is changed(we post them in >> XWindow.handleConfigureNotifyEvent). It seems that some of the peers >> has utility methods for this(like XDecoratedPeer.handleMoved). >> >> On 31.07.15 11:52, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8011616 >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ >>> >>> WM sends the real window position in the configuration event but >>> window peer does not set it to the target. Solution is: do set. >>> >>> --Semyon >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jul 31 14:55:53 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 31 Jul 2015 17:55:53 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55BB8631.2020105@oracle.com> References: <55B8F680.9000404@oracle.com> <55B9C8F7.2010705@oracle.com> <55BA3AD7.1010504@oracle.com> <55BB2404.6020306@oracle.com> <55BB6C05.2040103@oracle.com> <55BB732A.2040707@oracle.com> <55BB7A0C.2000304@oracle.com> <55BB7D6E.60307@oracle.com> <55BB83A2.4090507@oracle.com> <55BB8631.2020105@oracle.com> Message-ID: <55BB8C79.7050103@oracle.com> On 31.07.15 17:29, Semyon Sadetsky wrote: > So the test could use one of these java resources inside the native > app without any external libraries only using JNI library, right? Since we do not place a binary files to the ws, It will require an xcode and comandline tools. > > On 7/31/2015 5:18 PM, Sergey Bylokhov wrote: >> On 31.07.15 16:51, Semyon Sadetsky wrote: >>> There are plenty classes extending CFRetainedResource, TryIcon for >>> example. Will disposing them cause the same issue inside the native app? >> The crash occurs when any of these subclasses will be disposed, in >> some cases app will crash immediately, in other cases the app will >> crash after the objects will be gc. >> >>> On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: >>>> Yes, it is possible if this simple native application emulate >>>> initialization of these libraries. >>>> >>>> On 31.07.15 16:07, Semyon Sadetsky wrote: >>>>> Is it possible to reproduce the scenario using simple native >>>>> application which embeds the Java VM? >>>>> >>>>> On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: >>>>>> On 31.07.15 10:30, Semyon Sadetsky wrote: >>>>>>> JMC-4034 is not an OpenJDK project. Souldn't this test be copied >>>>>>> to the client-libs test base? >>>>>>> JDK-8132469 description contains manual steps executed using >>>>>>> SwingSet2, right? >>>>>> All sqe tests is not a part of openjdk project. These particular >>>>>> tests cannot be copied to our ws because they are depend from the >>>>>> external java libraries, which require some manual configuration. >>>>>> >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> >>>>>>> On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: >>>>>>>> Hi, Semyon. >>>>>>>> There are two tests which failed, see JMC-4034( >>>>>>>> jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). >>>>>>>> >>>>>>>> On 30.07.15 9:49, Semyon Sadetsky wrote: >>>>>>>>> Hi Sergey, >>>>>>>>> >>>>>>>>> You've marked the bug as noreg-sqe. I could not find the >>>>>>>>> existing test that crashes during the bug scenario. Could add >>>>>>>>> this info? >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: >>>>>>>>>> Hello. >>>>>>>>>> Please review the fix for jdk9. >>>>>>>>>> >>>>>>>>>> In the fix 8068886[1] the new native resources deallocation >>>>>>>>>> code assumes that we have a full control over the Cocoa >>>>>>>>>> NSApplication. This is incorrect in case of embedding, when >>>>>>>>>> NSApplication is controlled by swt or fx libraries. In the >>>>>>>>>> fix I add an additional check that the necessary selector >>>>>>>>>> exists in the current NSApp. >>>>>>>>>> >>>>>>>>>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 >>>>>>>>>> Webrev can be found at: >>>>>>>>>> http://cr.openjdk.java.net/~serb/8132382/webrev.02 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Jul 31 15:00:13 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 31 Jul 2015 18:00:13 +0300 Subject: [9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity In-Reply-To: <55BB8897.9090305@oracle.com> References: <55BB3762.1070102@oracle.com> <55BB74AA.2040407@oracle.com> <55BB83F0.4050505@oracle.com> <55BB8897.9090305@oracle.com> Message-ID: <55BB8D7D.70905@oracle.com> > On windows is changed in awt_Window.cpp. WmMove What I see there: (env)->SetIntField(target, AwtComponent::xID, rect.left); (env)->SetIntField(target, AwtComponent::yID, rect.top); Are you talking about size or screen position? The initial window size is preserved on Windows. On OSX it can be different if notifyReshape() is called upon window create. I don't see any extra issues related to the size currently. --Semyon > In general window manager can set a different size/location than we > try to set, so we should take a correct values in the callback and > update the target component, and after that post event that the bounds > was changed. > >> - the utility method was introduced because decorated window can be >> moved and it is utilized from several places. It is not the case for >> undecorated window. > It can be moved by the window manager. >> Not sure that container screen position makes any sense for its >> content size event. Is it specified somewhere? Or can you provide an >> example when it is necessary? > I am not sure. It needs to be checked. >> >> --Semyon >> >> On 7/31/2015 4:14 PM, Sergey Bylokhov wrote: >>> Hi, Semyon. >>> A few questions. >>> - Why only location is fixed, an update of size if not necessary(if >>> for some reason the size was changed by the system like location in >>> this case)? >>> - Note that we should update the target state before we post an >>> event that the size is changed(we post them in >>> XWindow.handleConfigureNotifyEvent). It seems that some of the peers >>> has utility methods for this(like XDecoratedPeer.handleMoved). >>> >>> On 31.07.15 11:52, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Please review fix for JDK9: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8011616 >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ >>>> >>>> WM sends the real window position in the configuration event but >>>> window peer does not set it to the target. Solution is: do set. >>>> >>>> --Semyon >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Jul 31 15:12:47 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 31 Jul 2015 18:12:47 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55BB8C79.7050103@oracle.com> References: <55B8F680.9000404@oracle.com> <55B9C8F7.2010705@oracle.com> <55BA3AD7.1010504@oracle.com> <55BB2404.6020306@oracle.com> <55BB6C05.2040103@oracle.com> <55BB732A.2040707@oracle.com> <55BB7A0C.2000304@oracle.com> <55BB7D6E.60307@oracle.com> <55BB83A2.4090507@oracle.com> <55BB8631.2020105@oracle.com> <55BB8C79.7050103@oracle.com> Message-ID: <55BB906F.1090408@oracle.com> On 7/31/2015 5:55 PM, Sergey Bylokhov wrote: > On 31.07.15 17:29, Semyon Sadetsky wrote: >> So the test could use one of these java resources inside the native >> app without any external libraries only using JNI library, right? > Since we do not place a binary files to the ws, It will require an > xcode and comandline tools. > Yes it's standard tools. And we have binary tests in WS, for example, in DnD test suite there are precompiled images for each platform. Functionality that is involved in native scenarios cannot be tested otherwise. >> >> On 7/31/2015 5:18 PM, Sergey Bylokhov wrote: >>> On 31.07.15 16:51, Semyon Sadetsky wrote: >>>> There are plenty classes extending CFRetainedResource, TryIcon for >>>> example. Will disposing them cause the same issue inside the native >>>> app? >>> The crash occurs when any of these subclasses will be disposed, in >>> some cases app will crash immediately, in other cases the app will >>> crash after the objects will be gc. >>> >>>> On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: >>>>> Yes, it is possible if this simple native application emulate >>>>> initialization of these libraries. >>>>> >>>>> On 31.07.15 16:07, Semyon Sadetsky wrote: >>>>>> Is it possible to reproduce the scenario using simple native >>>>>> application which embeds the Java VM? >>>>>> >>>>>> On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: >>>>>>> On 31.07.15 10:30, Semyon Sadetsky wrote: >>>>>>>> JMC-4034 is not an OpenJDK project. Souldn't this test be >>>>>>>> copied to the client-libs test base? >>>>>>>> JDK-8132469 description contains manual steps executed using >>>>>>>> SwingSet2, right? >>>>>>> All sqe tests is not a part of openjdk project. These particular >>>>>>> tests cannot be copied to our ws because they are depend from >>>>>>> the external java libraries, which require some manual >>>>>>> configuration. >>>>>>> >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> >>>>>>>> On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: >>>>>>>>> Hi, Semyon. >>>>>>>>> There are two tests which failed, see JMC-4034( >>>>>>>>> jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). >>>>>>>>> >>>>>>>>> On 30.07.15 9:49, Semyon Sadetsky wrote: >>>>>>>>>> Hi Sergey, >>>>>>>>>> >>>>>>>>>> You've marked the bug as noreg-sqe. I could not find the >>>>>>>>>> existing test that crashes during the bug scenario. Could add >>>>>>>>>> this info? >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: >>>>>>>>>>> Hello. >>>>>>>>>>> Please review the fix for jdk9. >>>>>>>>>>> >>>>>>>>>>> In the fix 8068886[1] the new native resources deallocation >>>>>>>>>>> code assumes that we have a full control over the Cocoa >>>>>>>>>>> NSApplication. This is incorrect in case of embedding, when >>>>>>>>>>> NSApplication is controlled by swt or fx libraries. In the >>>>>>>>>>> fix I add an additional check that the necessary selector >>>>>>>>>>> exists in the current NSApp. >>>>>>>>>>> >>>>>>>>>>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 >>>>>>>>>>> Webrev can be found at: >>>>>>>>>>> http://cr.openjdk.java.net/~serb/8132382/webrev.02 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jul 31 15:28:38 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 31 Jul 2015 18:28:38 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55BB906F.1090408@oracle.com> References: <55B8F680.9000404@oracle.com> <55B9C8F7.2010705@oracle.com> <55BA3AD7.1010504@oracle.com> <55BB2404.6020306@oracle.com> <55BB6C05.2040103@oracle.com> <55BB732A.2040707@oracle.com> <55BB7A0C.2000304@oracle.com> <55BB7D6E.60307@oracle.com> <55BB83A2.4090507@oracle.com> <55BB8631.2020105@oracle.com> <55BB8C79.7050103@oracle.com> <55BB906F.1090408@oracle.com> Message-ID: <55BB9426.3040709@oracle.com> On 31.07.15 18:12, Semyon Sadetsky wrote: > > > On 7/31/2015 5:55 PM, Sergey Bylokhov wrote: >> On 31.07.15 17:29, Semyon Sadetsky wrote: >>> So the test could use one of these java resources inside the native >>> app without any external libraries only using JNI library, right? >> Since we do not place a binary files to the ws, It will require an >> xcode and comandline tools. >> > > Yes it's standard tools. It is not standard and not installed by default, like on linux for example. > And we have binary tests in WS, for example, in DnD test suite there > are precompiled images for each platform. And all of them are closed like sqe tests. > Functionality that is involved in native scenarios cannot be tested > otherwise. But these scenarios already covered. > >>> >>> On 7/31/2015 5:18 PM, Sergey Bylokhov wrote: >>>> On 31.07.15 16:51, Semyon Sadetsky wrote: >>>>> There are plenty classes extending CFRetainedResource, TryIcon for >>>>> example. Will disposing them cause the same issue inside the >>>>> native app? >>>> The crash occurs when any of these subclasses will be disposed, in >>>> some cases app will crash immediately, in other cases the app will >>>> crash after the objects will be gc. >>>> >>>>> On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: >>>>>> Yes, it is possible if this simple native application emulate >>>>>> initialization of these libraries. >>>>>> >>>>>> On 31.07.15 16:07, Semyon Sadetsky wrote: >>>>>>> Is it possible to reproduce the scenario using simple native >>>>>>> application which embeds the Java VM? >>>>>>> >>>>>>> On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: >>>>>>>> On 31.07.15 10:30, Semyon Sadetsky wrote: >>>>>>>>> JMC-4034 is not an OpenJDK project. Souldn't this test be >>>>>>>>> copied to the client-libs test base? >>>>>>>>> JDK-8132469 description contains manual steps executed using >>>>>>>>> SwingSet2, right? >>>>>>>> All sqe tests is not a part of openjdk project. These >>>>>>>> particular tests cannot be copied to our ws because they are >>>>>>>> depend from the external java libraries, which require some >>>>>>>> manual configuration. >>>>>>>> >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: >>>>>>>>>> Hi, Semyon. >>>>>>>>>> There are two tests which failed, see JMC-4034( >>>>>>>>>> jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). >>>>>>>>>> >>>>>>>>>> On 30.07.15 9:49, Semyon Sadetsky wrote: >>>>>>>>>>> Hi Sergey, >>>>>>>>>>> >>>>>>>>>>> You've marked the bug as noreg-sqe. I could not find the >>>>>>>>>>> existing test that crashes during the bug scenario. Could >>>>>>>>>>> add this info? >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>> On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: >>>>>>>>>>>> Hello. >>>>>>>>>>>> Please review the fix for jdk9. >>>>>>>>>>>> >>>>>>>>>>>> In the fix 8068886[1] the new native resources deallocation >>>>>>>>>>>> code assumes that we have a full control over the Cocoa >>>>>>>>>>>> NSApplication. This is incorrect in case of embedding, when >>>>>>>>>>>> NSApplication is controlled by swt or fx libraries. In the >>>>>>>>>>>> fix I add an additional check that the necessary selector >>>>>>>>>>>> exists in the current NSApp. >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 >>>>>>>>>>>> Webrev can be found at: >>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8132382/webrev.02 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Best regards, Sergey. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jul 31 16:12:41 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 31 Jul 2015 19:12:41 +0300 Subject: [9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity In-Reply-To: <55BB8D7D.70905@oracle.com> References: <55BB3762.1070102@oracle.com> <55BB74AA.2040407@oracle.com> <55BB83F0.4050505@oracle.com> <55BB8897.9090305@oracle.com> <55BB8D7D.70905@oracle.com> Message-ID: <55BB9E79.8040800@oracle.com> On 31.07.15 18:00, Semyon Sadetsky wrote: > >> On windows is changed in awt_Window.cpp. WmMove > > What I see there: > > (env)->SetIntField(target, AwtComponent::xID, rect.left); > (env)->SetIntField(target, AwtComponent::yID, rect.top); > > Are you talking about size or screen position? Sorry the method name is AwtWIndow::WmSize in awt_Window.cpp, where we update the target and then post the event. > The initial window size is preserved on Windows. On OSX it can be > different if notifyReshape() is called upon window create. The window size can be change externally by the different reason, so we should always relies on the value which was reported by the system. > I don't see any extra issues related to the size currently. > > --Semyon > >> In general window manager can set a different size/location than we >> try to set, so we should take a correct values in the callback and >> update the target component, and after that post event that the >> bounds was changed. >> >>> - the utility method was introduced because decorated window can be >>> moved and it is utilized from several places. It is not the case for >>> undecorated window. >> It can be moved by the window manager. >>> Not sure that container screen position makes any sense for its >>> content size event. Is it specified somewhere? Or can you provide an >>> example when it is necessary? >> I am not sure. It needs to be checked. >>> >>> --Semyon >>> >>> On 7/31/2015 4:14 PM, Sergey Bylokhov wrote: >>>> Hi, Semyon. >>>> A few questions. >>>> - Why only location is fixed, an update of size if not >>>> necessary(if for some reason the size was changed by the system >>>> like location in this case)? >>>> - Note that we should update the target state before we post an >>>> event that the size is changed(we post them in >>>> XWindow.handleConfigureNotifyEvent). It seems that some of the >>>> peers has utility methods for this(like XDecoratedPeer.handleMoved). >>>> >>>> On 31.07.15 11:52, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Please review fix for JDK9: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8011616 >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ >>>>> >>>>> WM sends the real window position in the configuration event but >>>>> window peer does not set it to the target. Solution is: do set. >>>>> >>>>> --Semyon >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Jul 31 18:28:42 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 31 Jul 2015 21:28:42 +0300 Subject: [9] Review Request for 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity In-Reply-To: <55BB9E79.8040800@oracle.com> References: <55BB3762.1070102@oracle.com> <55BB74AA.2040407@oracle.com> <55BB83F0.4050505@oracle.com> <55BB8897.9090305@oracle.com> <55BB8D7D.70905@oracle.com> <55BB9E79.8040800@oracle.com> Message-ID: <55BBBE5A.1020102@oracle.com> You are right in windows size is limited to 65535 and I tested smaller value. In Linux WM will limit window size to entire of the screen. I will add size assignment as well. --Semyon On 7/31/2015 7:12 PM, Sergey Bylokhov wrote: > On 31.07.15 18:00, Semyon Sadetsky wrote: >> >>> On windows is changed in awt_Window.cpp. WmMove >> >> What I see there: >> >> (env)->SetIntField(target, AwtComponent::xID, rect.left); >> (env)->SetIntField(target, AwtComponent::yID, rect.top); >> >> Are you talking about size or screen position? > Sorry the method name is AwtWIndow::WmSize in awt_Window.cpp, where we > update the target and then post the event. > >> The initial window size is preserved on Windows. On OSX it can be >> different if notifyReshape() is called upon window create. > The window size can be change externally by the different reason, so > we should always relies on the value which was reported by the system. >> I don't see any extra issues related to the size currently. >> >> --Semyon >> >>> In general window manager can set a different size/location than we >>> try to set, so we should take a correct values in the callback and >>> update the target component, and after that post event that the >>> bounds was changed. >>> >>>> - the utility method was introduced because decorated window can be >>>> moved and it is utilized from several places. It is not the case >>>> for undecorated window. >>> It can be moved by the window manager. >>>> Not sure that container screen position makes any sense for its >>>> content size event. Is it specified somewhere? Or can you provide >>>> an example when it is necessary? >>> I am not sure. It needs to be checked. >>>> >>>> --Semyon >>>> >>>> On 7/31/2015 4:14 PM, Sergey Bylokhov wrote: >>>>> Hi, Semyon. >>>>> A few questions. >>>>> - Why only location is fixed, an update of size if not >>>>> necessary(if for some reason the size was changed by the system >>>>> like location in this case)? >>>>> - Note that we should update the target state before we post an >>>>> event that the size is changed(we post them in >>>>> XWindow.handleConfigureNotifyEvent). It seems that some of the >>>>> peers has utility methods for this(like XDecoratedPeer.handleMoved). >>>>> >>>>> On 31.07.15 11:52, Semyon Sadetsky wrote: >>>>>> Hello, >>>>>> >>>>>> Please review fix for JDK9: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8011616 >>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/ >>>>>> >>>>>> WM sends the real window position in the configuration event but >>>>>> window peer does not set it to the target. Solution is: do set. >>>>>> >>>>>> --Semyon >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Jul 31 18:34:56 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 31 Jul 2015 21:34:56 +0300 Subject: [9] Review Request: 8132382 [macosx] Crash during JMC execution In-Reply-To: <55BB9426.3040709@oracle.com> References: <55B8F680.9000404@oracle.com> <55B9C8F7.2010705@oracle.com> <55BA3AD7.1010504@oracle.com> <55BB2404.6020306@oracle.com> <55BB6C05.2040103@oracle.com> <55BB732A.2040707@oracle.com> <55BB7A0C.2000304@oracle.com> <55BB7D6E.60307@oracle.com> <55BB83A2.4090507@oracle.com> <55BB8631.2020105@oracle.com> <55BB8C79.7050103@oracle.com> <55BB906F.1090408@oracle.com> <55BB9426.3040709@oracle.com> Message-ID: <55BBBFD0.9050901@oracle.com> On 7/31/2015 6:28 PM, Sergey Bylokhov wrote: > On 31.07.15 18:12, Semyon Sadetsky wrote: >> >> >> On 7/31/2015 5:55 PM, Sergey Bylokhov wrote: >>> On 31.07.15 17:29, Semyon Sadetsky wrote: >>>> So the test could use one of these java resources inside the native >>>> app without any external libraries only using JNI library, right? >>> Since we do not place a binary files to the ws, It will require an >>> xcode and comandline tools. >>> >> >> Yes it's standard tools. > It is not standard and not installed by default, like on linux for > example. >> And we have binary tests in WS, for example, in DnD test suite there >> are precompiled images for each platform. > And all of them are closed like sqe tests. We are moving closed tests to open repo. >> Functionality that is involved in native scenarios cannot be tested >> otherwise. > But these scenarios already covered. Then what is the existing test suite name? >> >>>> >>>> On 7/31/2015 5:18 PM, Sergey Bylokhov wrote: >>>>> On 31.07.15 16:51, Semyon Sadetsky wrote: >>>>>> There are plenty classes extending CFRetainedResource, TryIcon >>>>>> for example. Will disposing them cause the same issue inside the >>>>>> native app? >>>>> The crash occurs when any of these subclasses will be disposed, in >>>>> some cases app will crash immediately, in other cases the app will >>>>> crash after the objects will be gc. >>>>> >>>>>> On 7/31/2015 4:37 PM, Sergey Bylokhov wrote: >>>>>>> Yes, it is possible if this simple native application emulate >>>>>>> initialization of these libraries. >>>>>>> >>>>>>> On 31.07.15 16:07, Semyon Sadetsky wrote: >>>>>>>> Is it possible to reproduce the scenario using simple native >>>>>>>> application which embeds the Java VM? >>>>>>>> >>>>>>>> On 7/31/2015 3:37 PM, Sergey Bylokhov wrote: >>>>>>>>> On 31.07.15 10:30, Semyon Sadetsky wrote: >>>>>>>>>> JMC-4034 is not an OpenJDK project. Souldn't this test be >>>>>>>>>> copied to the client-libs test base? >>>>>>>>>> JDK-8132469 description contains manual steps executed using >>>>>>>>>> SwingSet2, right? >>>>>>>>> All sqe tests is not a part of openjdk project. These >>>>>>>>> particular tests cannot be copied to our ws because they are >>>>>>>>> depend from the external java libraries, which require some >>>>>>>>> manual configuration. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/30/2015 5:55 PM, Sergey Bylokhov wrote: >>>>>>>>>>> Hi, Semyon. >>>>>>>>>>> There are two tests which failed, see JMC-4034( >>>>>>>>>>> jmc_plugintest/swt case) and JDK-8132469(swingnode/fx case). >>>>>>>>>>> >>>>>>>>>>> On 30.07.15 9:49, Semyon Sadetsky wrote: >>>>>>>>>>>> Hi Sergey, >>>>>>>>>>>> >>>>>>>>>>>> You've marked the bug as noreg-sqe. I could not find the >>>>>>>>>>>> existing test that crashes during the bug scenario. Could >>>>>>>>>>>> add this info? >>>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>>> On 7/29/2015 6:51 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>> Hello. >>>>>>>>>>>>> Please review the fix for jdk9. >>>>>>>>>>>>> >>>>>>>>>>>>> In the fix 8068886[1] the new native resources >>>>>>>>>>>>> deallocation code assumes that we have a full control over >>>>>>>>>>>>> the Cocoa NSApplication. This is incorrect in case of >>>>>>>>>>>>> embedding, when NSApplication is controlled by swt or fx >>>>>>>>>>>>> libraries. In the fix I add an additional check that the >>>>>>>>>>>>> necessary selector exists in the current NSApp. >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>>>>>>>> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe >>>>>>>>>>>>> >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 >>>>>>>>>>>>> Webrev can be found at: >>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8132382/webrev.02 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Best regards, Sergey. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: