From rkennke at redhat.com Fri Jan 2 13:59:25 2015 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 02 Jan 2015 14:59:25 +0100 Subject: [PATCH] Refactor X11FontManager Message-ID: <1420207165.14848.7.camel@localhost> Hello, I am currently working on a port of AWT/Java2D to DirectFB (using Caciocavallo [1] as a porting layer). I hit one obstacle that is the X11FontManager. I want to use fontconfig to work with fonts, but can't use anything X11. I refactored X11FontManager and related classes and native code to avoid calling anything X11 specific. Basically I created a superclass of X11FontManager called FcFontManager that does all the fontconfig related stuff, and use that in my backend. The changes should not affect the X11 implementation. Can you please review the changes here: http://cr.openjdk.java.net/~rkennke/refactor-x11fm/webrev.00/ I would like to push this into jdk9-client if you think it's ok. Best regards, Roman [1] http://openjdk.java.net/projects/caciocavallo/ From david.dehaven at oracle.com Sat Jan 10 04:45:32 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 9 Jan 2015 20:45:32 -0800 Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework Message-ID: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com> Please review the open source changes for 8043340. The goal here is to get jdk8u to build on Mac OS X 10.9+ systems where Xcode 5+ and Xcode 4 are co-installed, a configuration which is becoming more and more commonplace as more developers are focusing on JDK 9 now (which needs Xcode 5 installed), not to mention new systems ship with 10.10 which only supports the Xcode 5/6 command line tools. It's too much of a hassle to maintain separate systems for building jdk8u and JPRT isn't suitable for frequent changes so something must be done to address this. The jdk changes are similar to those done for JDK9, though I removed the changes for building with Xcode 5 (JDK-8043591) since we do not support building JDK 8 with clang. The hotspot changes are almost identical, the lack of SYSROOT_CFLAGS necessitated changing the logic in saproc.make a bit. It still builds with or without spec.gmk, though without it you will either need to define SDKPATH or have a sane Xcode 4 installation. For the top level build system: - most of the logic of sanitizing the Xcode build environment is in toolchain.m4 - the LIPO variable was removed since it was completely unused - OTOOL was moved to after the Xcode sanitizing so it can be picked up from DEVELOPER_DIR if needed - MACOSX_UNIVERSAL is now being set to false by default and ALT_MACOSX_UNIVERSAL was added to hotspot-spec.gmk.in so the hotspot build is in sync with the jdk build (this was a bug, IMHO) That last change removed any need to run lipo (only done in hotspot), so the fact that /usr/bin/lipo is broken with Xcode 4 is a non-issue. There is a weird case where some early versions of the Xcode 5 command line tools installed /usr/bin/{gcc|g++} as a symlink to {clang|clang++}, that case is handled by putting $DEVELOPER_DIR/usr/bin on the path so autoconf picks up the actual gcc executable. JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8043340 Webrevs: http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/top http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/hotspot http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/jdk JPRT runs are being kicked off. I'll have one run from hotspot directly. I'll post results here. -DrD- From erik.joelsson at oracle.com Mon Jan 12 10:35:56 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 Jan 2015 11:35:56 +0100 Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com> References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com> Message-ID: <54B3A38C.10909@oracle.com> Hello, These changes look ok to me. With these changes, configure will unconditionally fail if trying to use XCode 5. I know we don't officially support using XCode 5 for JDK 8, but aren't people working around it with some patches? How hard would it be to make it at least build? /Erik On 2015-01-10 05:45, David DeHaven wrote: > Please review the open source changes for 8043340. The goal here is to get jdk8u to build on Mac OS X 10.9+ systems where Xcode 5+ and Xcode 4 are co-installed, a configuration which is becoming more and more commonplace as more developers are focusing on JDK 9 now (which needs Xcode 5 installed), not to mention new systems ship with 10.10 which only supports the Xcode 5/6 command line tools. It's too much of a hassle to maintain separate systems for building jdk8u and JPRT isn't suitable for frequent changes so something must be done to address this. > > The jdk changes are similar to those done for JDK9, though I removed the changes for building with Xcode 5 (JDK-8043591) since we do not support building JDK 8 with clang. > > The hotspot changes are almost identical, the lack of SYSROOT_CFLAGS necessitated changing the logic in saproc.make a bit. It still builds with or without spec.gmk, though without it you will either need to define SDKPATH or have a sane Xcode 4 installation. > > For the top level build system: > - most of the logic of sanitizing the Xcode build environment is in toolchain.m4 > - the LIPO variable was removed since it was completely unused > - OTOOL was moved to after the Xcode sanitizing so it can be picked up from DEVELOPER_DIR if needed > - MACOSX_UNIVERSAL is now being set to false by default and ALT_MACOSX_UNIVERSAL was added to hotspot-spec.gmk.in so the hotspot build is in sync with the jdk build (this was a bug, IMHO) > > That last change removed any need to run lipo (only done in hotspot), so the fact that /usr/bin/lipo is broken with Xcode 4 is a non-issue. > > There is a weird case where some early versions of the Xcode 5 command line tools installed /usr/bin/{gcc|g++} as a symlink to {clang|clang++}, that case is handled by putting $DEVELOPER_DIR/usr/bin on the path so autoconf picks up the actual gcc executable. > > JBS Issue: > https://bugs.openjdk.java.net/browse/JDK-8043340 > > Webrevs: > http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/top > http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/hotspot > http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/jdk > > JPRT runs are being kicked off. I'll have one run from hotspot directly. I'll post results here. > > -DrD- > From alexander.zvegintsev at oracle.com Mon Jan 12 11:59:48 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 12 Jan 2015 14:59:48 +0300 Subject: [9] Request for review 8068305: [TEST_BUG] Test java/awt/Mixing/HWDisappear.java fails with GTKL&F Message-ID: <54B3B734.8050406@oracle.com> Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8068305/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8068305 Unlike the other look and feels, GTK needs to click twice to press a button: the first click dismisses the menu, the second actually clicks on a component. This is a correct behaviour, native apps acts in same way. -- Thanks, Alexander. From alexander.zvegintsev at oracle.com Mon Jan 12 12:24:36 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 12 Jan 2015 15:24:36 +0300 Subject: [9] Request for review 8068305: [TEST_BUG] Test java/awt/Mixing/HWDisappear.java fails with GTKL&F In-Reply-To: <54B3B734.8050406@oracle.com> References: <54B3B734.8050406@oracle.com> Message-ID: <54B3BD04.9050501@oracle.com> Please see the updated version, http://cr.openjdk.java.net/~azvegint/jdk/9/8068305/01/ Second click make the original issue[1] check useless, so I decided to make it Metal L&F only. [1] https://bugs.openjdk.java.net/browse/JDK-6769511 Thanks, Alexander. On 01/12/2015 02:59 PM, Alexander Zvegintsev wrote: > Hello, > > please review the fix > http://cr.openjdk.java.net/~azvegint/jdk/9/8068305/00/ > for the issue > https://bugs.openjdk.java.net/browse/JDK-8068305 > > Unlike the other look and feels, GTK needs to click twice to press a > button: > the first click dismisses the menu, the second actually clicks on a > component. > > This is a correct behaviour, native apps acts in same way. > From denis.fokin at gmail.com Mon Jan 12 12:37:23 2015 From: denis.fokin at gmail.com (Denis Fokin) Date: Mon, 12 Jan 2015 15:37:23 +0300 Subject: Fix some bug dependancy Message-ID: Hi AWT team, I found some inconsistence in the jdk bug tracker. Could anyone close JDK-8054112 not because it is not an issue but because it is a duplicate of JDK-8054211. Additionally, it would be good to mention JDK-8042693 in JDK-8054211 because it contains another way to reproduce the issue. Thank you, Denis From Sergey.Bylokhov at oracle.com Mon Jan 12 12:53:18 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 12 Jan 2015 15:53:18 +0300 Subject: Fix some bug dependancy In-Reply-To: References: Message-ID: <54B3C3BE.2000005@oracle.com> Hi, Denis. On 12.01.2015 15:37, Denis Fokin wrote: > Hi AWT team, > > I found some inconsistence in the jdk bug tracker. > > Could anyone close JDK-8054112 not because it is not an issue but because it is a duplicate of JDK-8054211. These two look similar, I reopened the 8054112 to investigate it deeper. > Additionally, it would be good to mention JDK-8042693 in JDK-8054211 because it contains another way to reproduce the issue. 8042693 is different and related to our own assertion. > > Thank you, > Denis -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Jan 12 14:00:09 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 12 Jan 2015 17:00:09 +0300 Subject: [9] Request for review 8068305: [TEST_BUG] Test java/awt/Mixing/HWDisappear.java fails with GTKL&F In-Reply-To: <54B3BD04.9050501@oracle.com> References: <54B3B734.8050406@oracle.com> <54B3BD04.9050501@oracle.com> Message-ID: <54B3D369.7040400@oracle.com> Hi, Alexander. The fix looks good. On 12.01.2015 15:24, Alexander Zvegintsev wrote: > Please see the updated version, > http://cr.openjdk.java.net/~azvegint/jdk/9/8068305/01/ > > Second click make the original issue[1] check useless, so I decided to > make it Metal L&F only. > > [1] https://bugs.openjdk.java.net/browse/JDK-6769511 > > Thanks, > > Alexander. > > On 01/12/2015 02:59 PM, Alexander Zvegintsev wrote: >> Hello, >> >> please review the fix >> http://cr.openjdk.java.net/~azvegint/jdk/9/8068305/00/ >> for the issue >> https://bugs.openjdk.java.net/browse/JDK-8068305 >> >> Unlike the other look and feels, GTK needs to click twice to press a >> button: >> the first click dismisses the menu, the second actually clicks on a >> component. >> >> This is a correct behaviour, native apps acts in same way. >> > -- Best regards, Sergey. From denis.fokin at gmail.com Mon Jan 12 14:11:14 2015 From: denis.fokin at gmail.com (Denis Fokin) Date: Mon, 12 Jan 2015 17:11:14 +0300 Subject: Fix some bug dependancy In-Reply-To: <54B3C3BE.2000005@oracle.com> References: <54B3C3BE.2000005@oracle.com> Message-ID: <8A65D8C5-80D8-4D77-AE59-8B990BEE472F@gmail.com> Thank you! > On 12 Jan 2015, at 15:53, Sergey Bylokhov wrote: > > Hi, Denis. > On 12.01.2015 15:37, Denis Fokin wrote: >> Hi AWT team, >> >> I found some inconsistence in the jdk bug tracker. >> >> Could anyone close JDK-8054112 not because it is not an issue but because it is a duplicate of JDK-8054211. > These two look similar, I reopened the 8054112 to investigate it deeper. >> Additionally, it would be good to mention JDK-8042693 in JDK-8054211 because it contains another way to reproduce the issue. > 8042693 is different and related to our own assertion. Indeed. Just to be clear what we talked about https://bugs.openjdk.java.net/browse/JDK-8042693?focusedCommentId=13495574&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13495574 >> >> Thank you, >> Denis > > > -- > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.dehaven at oracle.com Mon Jan 12 15:28:34 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 12 Jan 2015 07:28:34 -0800 Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <54B3A38C.10909@oracle.com> References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com> <54B3A38C.10909@oracle.com> Message-ID: <8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com> It won't build at all with Xcode 5, there is no gcc compiler and the clang changes were never backported to jdk8u. -DrD- > Hello, > > These changes look ok to me. > > With these changes, configure will unconditionally fail if trying to use XCode 5. I know we don't officially support using XCode 5 for JDK 8, but aren't people working around it with some patches? How hard would it be to make it at least build? > > /Erik > > On 2015-01-10 05:45, David DeHaven wrote: >> Please review the open source changes for 8043340. The goal here is to get jdk8u to build on Mac OS X 10.9+ systems where Xcode 5+ and Xcode 4 are co-installed, a configuration which is becoming more and more commonplace as more developers are focusing on JDK 9 now (which needs Xcode 5 installed), not to mention new systems ship with 10.10 which only supports the Xcode 5/6 command line tools. It's too much of a hassle to maintain separate systems for building jdk8u and JPRT isn't suitable for frequent changes so something must be done to address this. >> >> The jdk changes are similar to those done for JDK9, though I removed the changes for building with Xcode 5 (JDK-8043591) since we do not support building JDK 8 with clang. >> >> The hotspot changes are almost identical, the lack of SYSROOT_CFLAGS necessitated changing the logic in saproc.make a bit. It still builds with or without spec.gmk, though without it you will either need to define SDKPATH or have a sane Xcode 4 installation. >> >> For the top level build system: >> - most of the logic of sanitizing the Xcode build environment is in toolchain.m4 >> - the LIPO variable was removed since it was completely unused >> - OTOOL was moved to after the Xcode sanitizing so it can be picked up from DEVELOPER_DIR if needed >> - MACOSX_UNIVERSAL is now being set to false by default and ALT_MACOSX_UNIVERSAL was added to hotspot-spec.gmk.in so the hotspot build is in sync with the jdk build (this was a bug, IMHO) >> >> That last change removed any need to run lipo (only done in hotspot), so the fact that /usr/bin/lipo is broken with Xcode 4 is a non-issue. >> >> There is a weird case where some early versions of the Xcode 5 command line tools installed /usr/bin/{gcc|g++} as a symlink to {clang|clang++}, that case is handled by putting $DEVELOPER_DIR/usr/bin on the path so autoconf picks up the actual gcc executable. >> >> JBS Issue: >> https://bugs.openjdk.java.net/browse/JDK-8043340 >> >> Webrevs: >> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/top >> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/hotspot >> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/jdk >> >> JPRT runs are being kicked off. I'll have one run from hotspot directly. I'll post results here. >> >> -DrD- >> > From david.dehaven at oracle.com Mon Jan 12 16:25:21 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 12 Jan 2015 08:25:21 -0800 Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com> References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com> <54B3A38C.10909@oracle.com> <8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com> Message-ID: <08C63261-D594-404E-892B-BDE2898B505A@oracle.com> Or rather, the point of this exercise is to eliminate the hacks to get it to build with Xcode 5 (I'm not sure if anyone was truly successful with that). It's far better to just build with Xcode 4.6.3, and with these changes you don't even need to pre-sanitize your Xcode environment. A proper build setup would have Xcode 5 or 6 installed in /Applications/Xcode.app (generally MAS managed) and Xcode 4.6.3 (still available for download on ADC) somewhere NOT directly in /Applications (the Mac App Store has a nasty habit of "upgrading" it when it sees it there). I keep mine in /Applications/old along with a copy of Xcode 5.1.1 for test purposes. The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path. I'm kind of bummed I didn't get to show my really nasty hack for working around the broken lipo stub tool, it was so horrible it could be considered artwork! :) -DrD- > It won't build at all with Xcode 5, there is no gcc compiler and the clang changes were never backported to jdk8u. > > -DrD- > >> Hello, >> >> These changes look ok to me. >> >> With these changes, configure will unconditionally fail if trying to use XCode 5. I know we don't officially support using XCode 5 for JDK 8, but aren't people working around it with some patches? How hard would it be to make it at least build? >> >> /Erik >> >> On 2015-01-10 05:45, David DeHaven wrote: >>> Please review the open source changes for 8043340. The goal here is to get jdk8u to build on Mac OS X 10.9+ systems where Xcode 5+ and Xcode 4 are co-installed, a configuration which is becoming more and more commonplace as more developers are focusing on JDK 9 now (which needs Xcode 5 installed), not to mention new systems ship with 10.10 which only supports the Xcode 5/6 command line tools. It's too much of a hassle to maintain separate systems for building jdk8u and JPRT isn't suitable for frequent changes so something must be done to address this. >>> >>> The jdk changes are similar to those done for JDK9, though I removed the changes for building with Xcode 5 (JDK-8043591) since we do not support building JDK 8 with clang. >>> >>> The hotspot changes are almost identical, the lack of SYSROOT_CFLAGS necessitated changing the logic in saproc.make a bit. It still builds with or without spec.gmk, though without it you will either need to define SDKPATH or have a sane Xcode 4 installation. >>> >>> For the top level build system: >>> - most of the logic of sanitizing the Xcode build environment is in toolchain.m4 >>> - the LIPO variable was removed since it was completely unused >>> - OTOOL was moved to after the Xcode sanitizing so it can be picked up from DEVELOPER_DIR if needed >>> - MACOSX_UNIVERSAL is now being set to false by default and ALT_MACOSX_UNIVERSAL was added to hotspot-spec.gmk.in so the hotspot build is in sync with the jdk build (this was a bug, IMHO) >>> >>> That last change removed any need to run lipo (only done in hotspot), so the fact that /usr/bin/lipo is broken with Xcode 4 is a non-issue. >>> >>> There is a weird case where some early versions of the Xcode 5 command line tools installed /usr/bin/{gcc|g++} as a symlink to {clang|clang++}, that case is handled by putting $DEVELOPER_DIR/usr/bin on the path so autoconf picks up the actual gcc executable. >>> >>> JBS Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8043340 >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/top >>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/hotspot >>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/jdk >>> >>> JPRT runs are being kicked off. I'll have one run from hotspot directly. I'll post results here. >>> >>> -DrD- >>> >> > From erik.joelsson at oracle.com Mon Jan 12 16:30:08 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 Jan 2015 17:30:08 +0100 Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <08C63261-D594-404E-892B-BDE2898B505A@oracle.com> References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com> <54B3A38C.10909@oracle.com> <8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com> <08C63261-D594-404E-892B-BDE2898B505A@oracle.com> Message-ID: <54B3F690.5090309@oracle.com> I'm happy with that answer. Thanks! /Erik On 2015-01-12 17:25, David DeHaven wrote: > Or rather, the point of this exercise is to eliminate the hacks to get it to build with Xcode 5 (I'm not sure if anyone was truly successful with that). It's far better to just build with Xcode 4.6.3, and with these changes you don't even need to pre-sanitize your Xcode environment. > > A proper build setup would have Xcode 5 or 6 installed in /Applications/Xcode.app (generally MAS managed) and Xcode 4.6.3 (still available for download on ADC) somewhere NOT directly in /Applications (the Mac App Store has a nasty habit of "upgrading" it when it sees it there). I keep mine in /Applications/old along with a copy of Xcode 5.1.1 for test purposes. > > The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path. > > > I'm kind of bummed I didn't get to show my really nasty hack for working around the broken lipo stub tool, it was so horrible it could be considered artwork! :) > > -DrD- > >> It won't build at all with Xcode 5, there is no gcc compiler and the clang changes were never backported to jdk8u. >> >> -DrD- >> >>> Hello, >>> >>> These changes look ok to me. >>> >>> With these changes, configure will unconditionally fail if trying to use XCode 5. I know we don't officially support using XCode 5 for JDK 8, but aren't people working around it with some patches? How hard would it be to make it at least build? >>> >>> /Erik >>> >>> On 2015-01-10 05:45, David DeHaven wrote: >>>> Please review the open source changes for 8043340. The goal here is to get jdk8u to build on Mac OS X 10.9+ systems where Xcode 5+ and Xcode 4 are co-installed, a configuration which is becoming more and more commonplace as more developers are focusing on JDK 9 now (which needs Xcode 5 installed), not to mention new systems ship with 10.10 which only supports the Xcode 5/6 command line tools. It's too much of a hassle to maintain separate systems for building jdk8u and JPRT isn't suitable for frequent changes so something must be done to address this. >>>> >>>> The jdk changes are similar to those done for JDK9, though I removed the changes for building with Xcode 5 (JDK-8043591) since we do not support building JDK 8 with clang. >>>> >>>> The hotspot changes are almost identical, the lack of SYSROOT_CFLAGS necessitated changing the logic in saproc.make a bit. It still builds with or without spec.gmk, though without it you will either need to define SDKPATH or have a sane Xcode 4 installation. >>>> >>>> For the top level build system: >>>> - most of the logic of sanitizing the Xcode build environment is in toolchain.m4 >>>> - the LIPO variable was removed since it was completely unused >>>> - OTOOL was moved to after the Xcode sanitizing so it can be picked up from DEVELOPER_DIR if needed >>>> - MACOSX_UNIVERSAL is now being set to false by default and ALT_MACOSX_UNIVERSAL was added to hotspot-spec.gmk.in so the hotspot build is in sync with the jdk build (this was a bug, IMHO) >>>> >>>> That last change removed any need to run lipo (only done in hotspot), so the fact that /usr/bin/lipo is broken with Xcode 4 is a non-issue. >>>> >>>> There is a weird case where some early versions of the Xcode 5 command line tools installed /usr/bin/{gcc|g++} as a symlink to {clang|clang++}, that case is handled by putting $DEVELOPER_DIR/usr/bin on the path so autoconf picks up the actual gcc executable. >>>> >>>> JBS Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8043340 >>>> >>>> Webrevs: >>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/top >>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/hotspot >>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/jdk >>>> >>>> JPRT runs are being kicked off. I'll have one run from hotspot directly. I'll post results here. >>>> >>>> -DrD- >>>> From david.dehaven at oracle.com Mon Jan 12 17:05:28 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 12 Jan 2015 09:05:28 -0800 Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <08C63261-D594-404E-892B-BDE2898B505A@oracle.com> References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com> <54B3A38C.10909@oracle.com> <8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com> <08C63261-D594-404E-892B-BDE2898B505A@oracle.com> Message-ID: > The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path. Ugh. I broke something along the way, this doesn't *quite* work. xcrun complains with "xcrun: error: missing DEVELOPER_DIR path:" I think I'm exporting an empty DEVELOPER_DIR. I shall fix and update. -DrD- From Sergey.Bylokhov at oracle.com Mon Jan 12 17:16:47 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 12 Jan 2015 20:16:47 +0300 Subject: [9] Review Request: 6475361 Attempting to remove help menu from java.awt.MenuBar throws NullPointerException Message-ID: <54B4017F.6050402@oracle.com> Hello. Please review a fix for jdk 9. All problems mentioned in the CR were fixed: - Menu.isHelpMenu will be changed to false when a menu is removed from the MenuBar. - MenuBar.helpMenu will be changed to null when a menu is removed from the MenuBar. - MenuBar.setHelpMenu now handle null w/o NPE. (Initially this code behaved in the same way, but long long time ago in 1996 this "m.parent" code was added outside of null check) Bug: https://bugs.openjdk.java.net/browse/JDK-6475361 Webrev can be found at: http://cr.openjdk.java.net/~serb/6475361/webrev.00 -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Jan 12 20:29:16 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 12 Jan 2015 23:29:16 +0300 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module Message-ID: <54B42E9C.8010905@oracle.com> Hello. Please review a fix for jdk 9. In the fix a sun.datatransfer and a java.awt.datatransfer packages were moved to the separate module java.datatransfer. But sun.awt.datatransfer still located in java.desktop. I tested full jdk(all modules included) on osx using a jck, and it works without problems, at least no new issues were found. But datatransfer area is quite unstable after a bunch of the latest fixes. I still cannot replace java.desktop in modules.xml, because of some another dependencies(See comments in the bug) Bug: https://bugs.openjdk.java.net/browse/JDK-8056298 Webrev can be found at: http://cr.openjdk.java.net/~serb/8056298/webrev.01/jdk/webrev.01 http://cr.openjdk.java.net/~serb/8056298/webrev.01/root/webrev.01 -- Best regards, Sergey. From Alan.Bateman at oracle.com Mon Jan 12 20:42:16 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Jan 2015 20:42:16 +0000 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B42E9C.8010905@oracle.com> References: <54B42E9C.8010905@oracle.com> Message-ID: <54B431A8.5020904@oracle.com> On 12/01/2015 20:29, Sergey Bylokhov wrote: > Hello. > Please review a fix for jdk 9. > In the fix a sun.datatransfer and a java.awt.datatransfer packages > were moved to the separate module java.datatransfer. > But sun.awt.datatransfer still located in java.desktop. I tested full > jdk(all modules included) on osx using a jck, and it works without > problems, at least no new issues were found. But datatransfer area is > quite unstable after a bunch of the latest fixes. > I still cannot replace java.desktop in modules.xml, because of some > another dependencies(See comments in the bug) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8056298 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8056298/webrev.01/jdk/webrev.01 > http://cr.openjdk.java.net/~serb/8056298/webrev.01/root/webrev.01 > Thanks for doing this. I think it looks okay except for modules.xml where it looks like there may be a few issues. 1. You've updated the definition of java.corba to depend on java.datatransfer but I don't think this is needed (is there code in java.corba that uses this API?). 2. Same thing needs to be checked in java.xml.bind, jdk.jconsole and jdk.runtime where it's not clear to me that code in these modules uses this API. 2. The update to java.activation to depend on java.datatransfer looks right but shouldn't you drop the dependency on java.desktop? I don't have any other comments except to mention that java.xml.soap has been subsumed into java.xml.ws. Those changes are in jdk9/dev and it looks like jdk9/client might be a bit out of date. -Alan From Sergey.Bylokhov at oracle.com Mon Jan 12 20:50:21 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 12 Jan 2015 23:50:21 +0300 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B431A8.5020904@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> Message-ID: <54B4338D.9020008@oracle.com> On 12.01.2015 23:42, Alan Bateman wrote: > On 12/01/2015 20:29, Sergey Bylokhov wrote: >> Hello. >> Please review a fix for jdk 9. >> In the fix a sun.datatransfer and a java.awt.datatransfer packages >> were moved to the separate module java.datatransfer. >> But sun.awt.datatransfer still located in java.desktop. I tested full >> jdk(all modules included) on osx using a jck, and it works without >> problems, at least no new issues were found. But datatransfer area is >> quite unstable after a bunch of the latest fixes. >> I still cannot replace java.desktop in modules.xml, because of some >> another dependencies(See comments in the bug) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8056298 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8056298/webrev.01/jdk/webrev.01 >> http://cr.openjdk.java.net/~serb/8056298/webrev.01/root/webrev.01 >> > Thanks for doing this. I think it looks okay except for modules.xml > where it looks like there may be a few issues. > > 1. You've updated the definition of java.corba to depend on > java.datatransfer but I don't think this is needed (is there code in > java.corba that uses this API?). > > 2. Same thing needs to be checked in java.xml.bind, jdk.jconsole and > jdk.runtime where it's not clear to me that code in these modules uses > this API. You are right, that's seems unnecessary, i will double check and resend a new version. > > 2. The update to java.activation to depend on java.datatransfer looks > right but shouldn't you drop the dependency on java.desktop? java.activation depends on java.beans also > > I don't have any other comments except to mention that java.xml.soap > has been subsumed into java.xml.ws. Those changes are in jdk9/dev and > it looks like jdk9/client might be a bit out of date. I think that a pit before integration to the master will be a good thing, so I'll wait nearest dev2client synchronization > > -Alan > -- Best regards, Sergey. From Alan.Bateman at oracle.com Mon Jan 12 20:54:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Jan 2015 20:54:19 +0000 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B4338D.9020008@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B4338D.9020008@oracle.com> Message-ID: <54B4347B.5080806@oracle.com> On 12/01/2015 20:50, Sergey Bylokhov wrote: > On 12.01.2015 23:42, Alan Bateman wrote: >> On 12/01/2015 20:29, Sergey Bylokhov wrote: >>> Hello. >>> Please review a fix for jdk 9. >>> In the fix a sun.datatransfer and a java.awt.datatransfer packages >>> were moved to the separate module java.datatransfer. >>> But sun.awt.datatransfer still located in java.desktop. I tested >>> full jdk(all modules included) on osx using a jck, and it works >>> without problems, at least no new issues were found. But >>> datatransfer area is quite unstable after a bunch of the latest fixes. >>> I still cannot replace java.desktop in modules.xml, because of some >>> another dependencies(See comments in the bug) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056298 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8056298/webrev.01/jdk/webrev.01 >>> http://cr.openjdk.java.net/~serb/8056298/webrev.01/root/webrev.01 >>> >> Thanks for doing this. I think it looks okay except for modules.xml >> where it looks like there may be a few issues. >> >> 1. You've updated the definition of java.corba to depend on >> java.datatransfer but I don't think this is needed (is there code in >> java.corba that uses this API?). >> >> 2. Same thing needs to be checked in java.xml.bind, jdk.jconsole and >> jdk.runtime where it's not clear to me that code in these modules >> uses this API. > You are right, that's seems unnecessary, i will double check and > resend a new version. >> >> 2. The update to java.activation to depend on java.datatransfer looks >> right but shouldn't you drop the dependency on java.desktop? > java.activation depends on java.beans also Ah yes, I'd forgotten about that. We have JDK-8047773 to track addressing that dependency. -Alan. From alexandr.scherbatiy at oracle.com Tue Jan 13 09:32:37 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 13 Jan 2015 12:32:37 +0300 Subject: [9] Request for review 8068305: [TEST_BUG] Test java/awt/Mixing/HWDisappear.java fails with GTKL&F In-Reply-To: <54B3BD04.9050501@oracle.com> References: <54B3B734.8050406@oracle.com> <54B3BD04.9050501@oracle.com> Message-ID: <54B4E635.2070902@oracle.com> The fix looks good to me. Thanks, Alexandr. On 1/12/2015 3:24 PM, Alexander Zvegintsev wrote: > Please see the updated version, > http://cr.openjdk.java.net/~azvegint/jdk/9/8068305/01/ > > Second click make the original issue[1] check useless, so I decided to > make it Metal L&F only. > > [1] https://bugs.openjdk.java.net/browse/JDK-6769511 > > Thanks, > > Alexander. > > On 01/12/2015 02:59 PM, Alexander Zvegintsev wrote: >> Hello, >> >> please review the fix >> http://cr.openjdk.java.net/~azvegint/jdk/9/8068305/00/ >> for the issue >> https://bugs.openjdk.java.net/browse/JDK-8068305 >> >> Unlike the other look and feels, GTK needs to click twice to press a >> button: >> the first click dismisses the menu, the second actually clicks on a >> component. >> >> This is a correct behaviour, native apps acts in same way. >> > From alexander.zvegintsev at oracle.com Tue Jan 13 09:58:07 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 13 Jan 2015 12:58:07 +0300 Subject: [9] Review Request: 6475361 Attempting to remove help menu from java.awt.MenuBar throws NullPointerException In-Reply-To: <54B4017F.6050402@oracle.com> References: <54B4017F.6050402@oracle.com> Message-ID: <54B4EC2F.7030104@oracle.com> Hello Sergey, the fix looks good to me. Thanks, Alexander. On 01/12/2015 08:16 PM, Sergey Bylokhov wrote: > Hello. > Please review a fix for jdk 9. > All problems mentioned in the CR were fixed: > - Menu.isHelpMenu will be changed to false when a menu is removed > from the MenuBar. > - MenuBar.helpMenu will be changed to null when a menu is removed > from the MenuBar. > - MenuBar.setHelpMenu now handle null w/o NPE. (Initially this code > behaved in the same way, but long long time ago in 1996 this > "m.parent" code was added outside of null check) > > Bug: https://bugs.openjdk.java.net/browse/JDK-6475361 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/6475361/webrev.00 > From Sergey.Bylokhov at oracle.com Tue Jan 13 11:40:34 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 13 Jan 2015 14:40:34 +0300 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B431A8.5020904@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> Message-ID: <54B50432.5060300@oracle.com> Hi, Alan. On 12.01.2015 23:42, Alan Bateman wrote: > Thanks for doing this. I think it looks okay except for modules.xml > where it looks like there may be a few issues. > > 1. You've updated the definition of java.corba to depend on > java.datatransfer but I don't think this is needed (is there code in > java.corba that uses this API?). > > 2. Same thing needs to be checked in java.xml.bind, jdk.jconsole and > jdk.runtime where it's not clear to me that code in these modules uses > this API. java.datatransfer was removed everywhere except: 1. java.xml.bind jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java:53: error: cannot access Transferable public abstract class StreamingDataHandler extends DataHandler implements Closeable { 2. java.xml.soap jaxws/src/java.xml.soap/share/classes/com/sun/xml/internal/messaging/saaj/soap/FastInfosetDataContentHandler.java:53: error: cannot find symbol public DataFlavor[] getTransferDataFlavors() { // throws Exceptio 3. java.xml.ws jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/developer/StreamingDataHandler.java:51: error: cannot access Transferable public abstract class StreamingDataHandler extends com.sun.xml.internal.org.jvnet.staxex.StreamingDataHandler { The new versions: http://cr.openjdk.java.net/~serb/8056298/webrev.02/jdk http://cr.openjdk.java.net/~serb/8056298/webrev.02/root Bug: https://bugs.openjdk.java.net/browse/JDK-8056298 > > 2. The update to java.activation to depend on java.datatransfer looks > right but shouldn't you drop the dependency on java.desktop? > > I don't have any other comments except to mention that java.xml.soap > has been subsumed into java.xml.ws. Those changes are in jdk9/dev and > it looks like jdk9/client might be a bit out of date. > > -Alan > -- Best regards, Sergey. From erik.joelsson at oracle.com Tue Jan 13 12:57:20 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 13 Jan 2015 13:57:20 +0100 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B50432.5060300@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> Message-ID: <54B51630.1000108@oracle.com> The makefile change looks good to me. /Erik On 2015-01-13 12:40, Sergey Bylokhov wrote: > Hi, Alan. > On 12.01.2015 23:42, Alan Bateman wrote: >> Thanks for doing this. I think it looks okay except for modules.xml >> where it looks like there may be a few issues. >> >> 1. You've updated the definition of java.corba to depend on >> java.datatransfer but I don't think this is needed (is there code in >> java.corba that uses this API?). >> >> 2. Same thing needs to be checked in java.xml.bind, jdk.jconsole and >> jdk.runtime where it's not clear to me that code in these modules >> uses this API. > > java.datatransfer was removed everywhere except: > > 1. java.xml.bind > jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java:53: > error: cannot access Transferable > public abstract class StreamingDataHandler extends DataHandler > implements Closeable { > > 2. java.xml.soap > jaxws/src/java.xml.soap/share/classes/com/sun/xml/internal/messaging/saaj/soap/FastInfosetDataContentHandler.java:53: > error: cannot find symbol > public DataFlavor[] getTransferDataFlavors() { // throws Exceptio > > 3. java.xml.ws > jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/developer/StreamingDataHandler.java:51: > error: cannot access Transferable > public abstract class StreamingDataHandler extends > com.sun.xml.internal.org.jvnet.staxex.StreamingDataHandler { > > The new versions: > http://cr.openjdk.java.net/~serb/8056298/webrev.02/jdk > http://cr.openjdk.java.net/~serb/8056298/webrev.02/root > > Bug: https://bugs.openjdk.java.net/browse/JDK-8056298 > >> >> 2. The update to java.activation to depend on java.datatransfer looks >> right but shouldn't you drop the dependency on java.desktop? >> >> I don't have any other comments except to mention that java.xml.soap >> has been subsumed into java.xml.ws. Those changes are in jdk9/dev and >> it looks like jdk9/client might be a bit out of date. >> >> -Alan >> > > From rkennke at redhat.com Tue Jan 13 13:14:18 2015 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 13 Jan 2015 14:14:18 +0100 Subject: [PATCH] Refactor X11FontManager In-Reply-To: <1420207165.14848.7.camel@localhost> References: <1420207165.14848.7.camel@localhost> Message-ID: <1421154858.6838.41.camel@localhost> Ping? Any opinions? Regards, Roman Am Freitag, den 02.01.2015 um 14:59 +0100 schrieb Roman Kennke: > Hello, > > I am currently working on a port of AWT/Java2D to DirectFB (using > Caciocavallo [1] as a porting layer). > > I hit one obstacle that is the X11FontManager. I want to use fontconfig > to work with fonts, but can't use anything X11. > > I refactored X11FontManager and related classes and native code to avoid > calling anything X11 specific. Basically I created a superclass of > X11FontManager called FcFontManager that does all the fontconfig related > stuff, and use that in my backend. The changes should not affect the X11 > implementation. > > Can you please review the changes here: > > http://cr.openjdk.java.net/~rkennke/refactor-x11fm/webrev.00/ > > I would like to push this into jdk9-client if you think it's ok. > > Best regards, > Roman > > [1] http://openjdk.java.net/projects/caciocavallo/ > From Alan.Bateman at oracle.com Tue Jan 13 13:15:09 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Jan 2015 13:15:09 +0000 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B50432.5060300@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> Message-ID: <54B51A5D.2090708@oracle.com> On 13/01/2015 11:40, Sergey Bylokhov wrote: > : > > The new versions: > http://cr.openjdk.java.net/~serb/8056298/webrev.02/jdk > http://cr.openjdk.java.net/~serb/8056298/webrev.02/root > > Bug: https://bugs.openjdk.java.net/browse/JDK-8056298 Thanks for the update. The only thing that isn't clear to me is the java.activation dependency on java.desktop where I assume the re-exports="true" should be removed (because the dependency on java.beans.Beans is not in any of the method signatures). -Alan From Sergey.Bylokhov at oracle.com Tue Jan 13 13:52:28 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 13 Jan 2015 16:52:28 +0300 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B51A5D.2090708@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com> Message-ID: <54B5231C.4090809@oracle.com> On 13.01.2015 16:15, Alan Bateman wrote: > On 13/01/2015 11:40, Sergey Bylokhov wrote: >> : >> >> The new versions: >> http://cr.openjdk.java.net/~serb/8056298/webrev.02/jdk >> http://cr.openjdk.java.net/~serb/8056298/webrev.02/root >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8056298 > Thanks for the update. The only thing that isn't clear to me is the > java.activation dependency on java.desktop where I assume the > re-exports="true" should be removed (because the dependency on > java.beans.Beans is not in any of the method signatures). Yes it is unnecessary. The new versions: http://cr.openjdk.java.net/~serb/8056298/webrev.03/jdk http://cr.openjdk.java.net/~serb/8056298/webrev.03/root > > -Alan > > > -- Best regards, Sergey. From anton.tarasov at oracle.com Tue Jan 13 13:54:06 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 13 Jan 2015 16:54:06 +0300 Subject: [9] Review Request: 6475361 Attempting to remove help menu from java.awt.MenuBar throws NullPointerException In-Reply-To: <54B4017F.6050402@oracle.com> References: <54B4017F.6050402@oracle.com> Message-ID: <54B5237E.80407@oracle.com> Hi Sergey, Looks fine to me. Regards, Anton. On 12.01.2015 20:16, Sergey Bylokhov wrote: > Hello. > Please review a fix for jdk 9. > All problems mentioned in the CR were fixed: > - Menu.isHelpMenu will be changed to false when a menu is removed from the MenuBar. > - MenuBar.helpMenu will be changed to null when a menu is removed from the MenuBar. > - MenuBar.setHelpMenu now handle null w/o NPE. (Initially this code behaved in the same way, but > long long time ago in 1996 this "m.parent" code was added outside of null check) > > Bug: https://bugs.openjdk.java.net/browse/JDK-6475361 > Webrev can be found at: http://cr.openjdk.java.net/~serb/6475361/webrev.00 > From Alan.Bateman at oracle.com Tue Jan 13 14:05:23 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Jan 2015 14:05:23 +0000 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B5231C.4090809@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com> <54B5231C.4090809@oracle.com> Message-ID: <54B52623.5010700@oracle.com> On 13/01/2015 13:52, Sergey Bylokhov wrote: > Yes it is unnecessary. The new versions: > http://cr.openjdk.java.net/~serb/8056298/webrev.03/jdk > http://cr.openjdk.java.net/~serb/8056298/webrev.03/root This looks good to (and I assume that "make verify-images" passes). -Alan. From Sergey.Bylokhov at oracle.com Tue Jan 13 14:17:03 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 13 Jan 2015 17:17:03 +0300 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B52623.5010700@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com> <54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com> Message-ID: <54B528DF.8020507@oracle.com> On 13.01.2015 17:05, Alan Bateman wrote: > On 13/01/2015 13:52, Sergey Bylokhov wrote: >> Yes it is unnecessary. The new versions: >> http://cr.openjdk.java.net/~serb/8056298/webrev.03/jdk >> http://cr.openjdk.java.net/~serb/8056298/webrev.03/root > This looks good to (and I assume that "make verify-images" passes). Did you mean "make verify-modules"? I was under impression that it was added to the image target, seems not. I will check that. > > -Alan. -- Best regards, Sergey. From Alan.Bateman at oracle.com Tue Jan 13 14:23:03 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Jan 2015 14:23:03 +0000 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B528DF.8020507@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com> <54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com> <54B528DF.8020507@oracle.com> Message-ID: <54B52A47.8030501@oracle.com> On 13/01/2015 14:17, Sergey Bylokhov wrote: > On 13.01.2015 17:05, Alan Bateman wrote: >> On 13/01/2015 13:52, Sergey Bylokhov wrote: >>> Yes it is unnecessary. The new versions: >>> http://cr.openjdk.java.net/~serb/8056298/webrev.03/jdk >>> http://cr.openjdk.java.net/~serb/8056298/webrev.03/root >> This looks good to (and I assume that "make verify-images" passes). > Did you mean "make verify-modules"? I was under impression that it was > added to the image target, seems not. I will check that. Typo in my mail, I meant verify-modules. They are currently issues with verify-modules and boot cycle builds so I think verify-modules is currently disabled (at least in jdk9/dev). Erik is working on this via JDK-8067479. -Alan. From Sergey.Bylokhov at oracle.com Tue Jan 13 15:45:49 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 13 Jan 2015 18:45:49 +0300 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B52A47.8030501@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com> <54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com> <54B528DF.8020507@oracle.com> <54B52A47.8030501@oracle.com> Message-ID: <54B53DAD.80407@oracle.com> On 13.01.2015 17:23, Alan Bateman wrote: > Typo in my mail, I meant verify-modules. > > They are currently issues with verify-modules and boot cycle builds so > I think verify-modules is currently disabled (at least in jdk9/dev). > Erik is working on this via JDK-8067479. The new versions: http://cr.openjdk.java.net/~serb/8056298/webrev.04/jdk http://cr.openjdk.java.net/~serb/8056298/webrev.04/root - sun.reflect.misc and sun.security.util were exported to java.datatransfer. - jdk.hotspot.agent now depends on java.datatransfer "make verify-modules" was completed w/o issues. -- Best regards, Sergey. From mandy.chung at oracle.com Tue Jan 13 17:26:59 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Jan 2015 09:26:59 -0800 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B53DAD.80407@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com> <54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com> <54B528DF.8020507@oracle.com> <54B52A47.8030501@oracle.com> <54B53DAD.80407@oracle.com> Message-ID: <54B55563.50203@oracle.com> On 1/13/15 7:45 AM, Sergey Bylokhov wrote: > On 13.01.2015 17:23, Alan Bateman wrote: >> Typo in my mail, I meant verify-modules. >> >> They are currently issues with verify-modules and boot cycle builds >> so I think verify-modules is currently disabled (at least in >> jdk9/dev). Erik is working on this via JDK-8067479. > The new versions: > http://cr.openjdk.java.net/~serb/8056298/webrev.04/jdk > http://cr.openjdk.java.net/~serb/8056298/webrev.04/root > - sun.reflect.misc and sun.security.util were exported to > java.datatransfer. > - jdk.hotspot.agent now depends on java.datatransfer > "make verify-modules" was completed w/o issues. > Thanks for doing this. java.activation, java.xml.ws, jdk.hotspot.agent uses java.awt.datatransfer. I don't find java.xml.bind using it. $ jdeps -p java.awt.datatransfer $BUILD_OUTPUTDIR/jdk/modules/* The result shows that java.activation, java.xml.ws, jdk.hotspot.agent uses java.awt.datatransfer (there is a bug in jdeps that didn't show the module name correctly - will file a bug and fix it). How do you find java.xml.bind depend on java.datatransfer? You can run this from your build: $ jdk/bin/jdeps -s jdk/modules/java.xml.bind/ About the qualified exports from java.base: java.awt.datatransfer.DataFlavor uses sun.security.util.SecurityConstants.GET_CLASSLOADER_PERMISSION I suggest to remove this dependency by creating the instance when security manager is on: new RuntimePermission("getClassLoader") Mandy From Sergey.Bylokhov at oracle.com Tue Jan 13 17:34:07 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 13 Jan 2015 20:34:07 +0300 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B55563.50203@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com> <54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com> <54B528DF.8020507@oracle.com> <54B52A47.8030501@oracle.com> <54B53DAD.80407@oracle.com> <54B55563.50203@oracle.com> Message-ID: <54B5570F.7050900@oracle.com> On 13.01.2015 20:26, Mandy Chung wrote: > On 1/13/15 7:45 AM, Sergey Bylokhov wrote: >> On 13.01.2015 17:23, Alan Bateman wrote: >>> Typo in my mail, I meant verify-modules. >>> >>> They are currently issues with verify-modules and boot cycle builds >>> so I think verify-modules is currently disabled (at least in >>> jdk9/dev). Erik is working on this via JDK-8067479. >> The new versions: >> http://cr.openjdk.java.net/~serb/8056298/webrev.04/jdk >> http://cr.openjdk.java.net/~serb/8056298/webrev.04/root >> - sun.reflect.misc and sun.security.util were exported to >> java.datatransfer. >> - jdk.hotspot.agent now depends on java.datatransfer >> "make verify-modules" was completed w/o issues. >> > Thanks for doing this. java.activation, java.xml.ws, jdk.hotspot.agent > uses java.awt.datatransfer. I don't find java.xml.bind using it. > > $ jdeps -p java.awt.datatransfer $BUILD_OUTPUTDIR/jdk/modules/* > > The result shows that java.activation, java.xml.ws, jdk.hotspot.agent > uses java.awt.datatransfer (there is a bug in jdeps that didn't show > the module name correctly - will file a bug and fix it). > > How do you find java.xml.bind depend on java.datatransfer? You can > run this from your build: > $ jdk/bin/jdeps -s jdk/modules/java.xml.bind/ it does not compile w/o it: java.xml.bind: jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java:53: error: cannot access Transferable public abstract class StreamingDataHandler extends DataHandler implements Closeable { > > About the qualified exports from java.base: > > java.awt.datatransfer.DataFlavor uses > sun.security.util.SecurityConstants.GET_CLASSLOADER_PERMISSION > > I suggest to remove this dependency by creating the instance > when security manager is on: > new RuntimePermission("getClassLoader") is it necessary? I prefer to use current solution as more readable. > > Mandy > -- Best regards, Sergey. From mandy.chung at oracle.com Tue Jan 13 18:26:07 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Jan 2015 10:26:07 -0800 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B5570F.7050900@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com> <54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com> <54B528DF.8020507@oracle.com> <54B52A47.8030501@oracle.com> <54B53DAD.80407@oracle.com> <54B55563.50203@oracle.com> <54B5570F.7050900@oracle.com> Message-ID: <54B5633F.7010403@oracle.com> On 1/13/15 9:34 AM, Sergey Bylokhov wrote: > On 13.01.2015 20:26, Mandy Chung wrote: >> On 1/13/15 7:45 AM, Sergey Bylokhov wrote: >>> On 13.01.2015 17:23, Alan Bateman wrote: >>>> Typo in my mail, I meant verify-modules. >>>> >>>> They are currently issues with verify-modules and boot cycle builds >>>> so I think verify-modules is currently disabled (at least in >>>> jdk9/dev). Erik is working on this via JDK-8067479. >>> The new versions: >>> http://cr.openjdk.java.net/~serb/8056298/webrev.04/jdk >>> http://cr.openjdk.java.net/~serb/8056298/webrev.04/root >>> - sun.reflect.misc and sun.security.util were exported to >>> java.datatransfer. >>> - jdk.hotspot.agent now depends on java.datatransfer >>> "make verify-modules" was completed w/o issues. >>> >> Thanks for doing this. java.activation, java.xml.ws, jdk.hotspot.agent >> uses java.awt.datatransfer. I don't find java.xml.bind using it. >> >> $ jdeps -p java.awt.datatransfer $BUILD_OUTPUTDIR/jdk/modules/* >> >> The result shows that java.activation, java.xml.ws, jdk.hotspot.agent >> uses java.awt.datatransfer (there is a bug in jdeps that didn't show >> the module name correctly - will file a bug and fix it). >> >> How do you find java.xml.bind depend on java.datatransfer? You can >> run this from your build: >> $ jdk/bin/jdeps -s jdk/modules/java.xml.bind/ > it does not compile w/o it: > java.xml.bind: > jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java:53: > error: cannot access Transferable > public abstract class StreamingDataHandler extends DataHandler > implements Closeable { > I see. java.xml.bind -> java.desktop is temporarily needed until the module system is in replace unless the build adds the re-exported module (i.e. java.datatransfer) to the sourcepath to compile java.xml.bind. That change is fine. >> >> About the qualified exports from java.base: >> >> java.awt.datatransfer.DataFlavor uses >> sun.security.util.SecurityConstants.GET_CLASSLOADER_PERMISSION >> >> I suggest to remove this dependency by creating the instance >> when security manager is on: >> new RuntimePermission("getClassLoader") > is it necessary? I prefer to use current solution as more readable. I'd like to keep the qualified exports to the ones which are absolutely needed. Sharing common code is good while this "getClassLoader" permission is part of the specification and allowing desktop to access the entire sun.security.util package is more than it needs (java.datatransfer only depends on this static instance). The cost of creating a Permission object is low and only when security manager is on. I would recommend to replace the dependency on SecurityConstants. Mandy From Alan.Bateman at oracle.com Tue Jan 13 18:51:24 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Jan 2015 18:51:24 +0000 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B53DAD.80407@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com> <54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com> <54B528DF.8020507@oracle.com> <54B52A47.8030501@oracle.com> <54B53DAD.80407@oracle.com> Message-ID: <54B5692C.2000507@oracle.com> On 13/01/2015 15:45, Sergey Bylokhov wrote: > On 13.01.2015 17:23, Alan Bateman wrote: >> Typo in my mail, I meant verify-modules. >> >> They are currently issues with verify-modules and boot cycle builds >> so I think verify-modules is currently disabled (at least in >> jdk9/dev). Erik is working on this via JDK-8067479. > The new versions: > http://cr.openjdk.java.net/~serb/8056298/webrev.04/jdk > http://cr.openjdk.java.net/~serb/8056298/webrev.04/root > - sun.reflect.misc and sun.security.util were exported to > java.datatransfer. > - jdk.hotspot.agent now depends on java.datatransfer > "make verify-modules" was completed w/o issues. > I think this looks okay. I see Mandy's comment about dropping the dependency on sun.security.util and that would be good to do (but can be another patch if you want). -Alan From Sergey.Bylokhov at oracle.com Tue Jan 13 19:30:45 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 13 Jan 2015 22:30:45 +0300 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B5692C.2000507@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com> <54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com> <54B528DF.8020507@oracle.com> <54B52A47.8030501@oracle.com> <54B53DAD.80407@oracle.com> <54B5692C.2000507@oracle.com> Message-ID: <54B57265.3060307@oracle.com> On 13.01.2015 21:51, Alan Bateman wrote: > I think this looks okay. I see Mandy's comment about dropping the > dependency on sun.security.util and that would be good to do (but can > be another patch if you want). ok. The new versions: http://cr.openjdk.java.net/~serb/8056298/webrev.05/jdk http://cr.openjdk.java.net/~serb/8056298/webrev.05/root GET_CLASSLOADER_PERMISSION was removed. -- Best regards, Sergey. From mandy.chung at oracle.com Tue Jan 13 19:43:26 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Jan 2015 11:43:26 -0800 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B57265.3060307@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com> <54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com> <54B528DF.8020507@oracle.com> <54B52A47.8030501@oracle.com> <54B53DAD.80407@oracle.com> <54B5692C.2000507@oracle.com> <54B57265.3060307@oracle.com> Message-ID: <54B5755E.5010104@oracle.com> On 1/13/2015 11:30 AM, Sergey Bylokhov wrote: > On 13.01.2015 21:51, Alan Bateman wrote: >> I think this looks okay. I see Mandy's comment about dropping the >> dependency on sun.security.util and that would be good to do (but can >> be another patch if you want). > ok. The new versions: > http://cr.openjdk.java.net/~serb/8056298/webrev.05/jdk > http://cr.openjdk.java.net/~serb/8056298/webrev.05/root > GET_CLASSLOADER_PERMISSION was removed. > Looks good. Thanks for removing that dependency. Mandy From david.dehaven at oracle.com Wed Jan 14 03:09:06 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 13 Jan 2015 19:09:06 -0800 Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com> <54B3A38C.10909@oracle.com> <8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com> <08C63261-D594-404E-892B-BDE2898B505A@oracle.com> Message-ID: <4DC9B291-D302-428C-A5F7-177066C65991@oracle.com> >> The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path. > > Ugh. I broke something along the way, this doesn't *quite* work. > > xcrun complains with "xcrun: error: missing DEVELOPER_DIR path:" > > I think I'm exporting an empty DEVELOPER_DIR. I shall fix and update. TL;DR: Please review round 2: http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v1/ (I removed generated-configure.sh to reduce the review size, it will be re-generated prior to pushing) I've tested the following configuration scenarios (output from a shell script I cobbled together..) field values: XC6 - Xcode 6 installed in /Applications/Xcode.app XC4 - Xcode 4 installed in some other dir (empty) - Argument not passed to configure Result meanings: DEV_DIR set - configure succeeded, DEVELOPER_DIR was properly exported in spec.gmk DEV_DIR NOT set - configure succeeded, DEVELOPER_DIR was not needed (XC4 must be selected to achieve this) Configure failed - Configure properly failed when it detected Xcode > 4 "Selected" Xcode means version reported by xcode-select -p | Xcode selected | --with-xcode-path | DEVELOPER_DIR | result | ----------------------------------------------------------------------------- | XC4 | | | DEV_DIR NOT set | ----------------------------------------------------------------------------- | XC4 | | XC4 | DEV_DIR set | ----------------------------------------------------------------------------- | XC4 | | XC6 | Configure failed | ----------------------------------------------------------------------------- | XC4 | XC4 | | DEV_DIR set | ----------------------------------------------------------------------------- | XC4 | XC4 | XC4 | DEV_DIR set | ----------------------------------------------------------------------------- | XC4 | XC4 | XC6 | DEV_DIR set | ----------------------------------------------------------------------------- | XC4 | XC6 | | Configure failed | ----------------------------------------------------------------------------- | XC4 | XC6 | XC4 | Configure failed | ----------------------------------------------------------------------------- | XC4 | XC6 | XC6 | Configure failed | ----------------------------------------------------------------------------- | XC6 | | | Configure failed | ----------------------------------------------------------------------------- | XC6 | | XC4 | DEV_DIR set | ----------------------------------------------------------------------------- | XC6 | | XC6 | Configure failed | ----------------------------------------------------------------------------- | XC6 | XC4 | | DEV_DIR set | ----------------------------------------------------------------------------- | XC6 | XC4 | XC4 | DEV_DIR set | ----------------------------------------------------------------------------- | XC6 | XC4 | XC6 | DEV_DIR set | ----------------------------------------------------------------------------- | XC6 | XC6 | | Configure failed | ----------------------------------------------------------------------------- | XC6 | XC6 | XC4 | Configure failed | ----------------------------------------------------------------------------- | XC6 | XC6 | XC6 | Configure failed | ----------------------------------------------------------------------------- All the results are as expected. Please note that --with-xcode-path overrides DEVELOPER_DIR, since that could be set in the environment. (yeah, I went a little OCD on this...) -DrD- From erik.joelsson at oracle.com Wed Jan 14 08:33:28 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 14 Jan 2015 09:33:28 +0100 Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <4DC9B291-D302-428C-A5F7-177066C65991@oracle.com> References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com> <54B3A38C.10909@oracle.com> <8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com> <08C63261-D594-404E-892B-BDE2898B505A@oracle.com> <4DC9B291-D302-428C-A5F7-177066C65991@oracle.com> Message-ID: <54B629D8.8070700@oracle.com> Hello, This looks good to me. Thanks for the detailed table! /Erik On 2015-01-14 04:09, David DeHaven wrote: >>> The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path. >> Ugh. I broke something along the way, this doesn't *quite* work. >> >> xcrun complains with "xcrun: error: missing DEVELOPER_DIR path:" >> >> I think I'm exporting an empty DEVELOPER_DIR. I shall fix and update. > TL;DR: Please review round 2: > http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v1/ > > (I removed generated-configure.sh to reduce the review size, it will be re-generated prior to pushing) > > > I've tested the following configuration scenarios (output from a shell script I cobbled together..) > > field values: > XC6 - Xcode 6 installed in /Applications/Xcode.app > XC4 - Xcode 4 installed in some other dir > (empty) - Argument not passed to configure > > Result meanings: > DEV_DIR set - configure succeeded, DEVELOPER_DIR was properly exported in spec.gmk > DEV_DIR NOT set - configure succeeded, DEVELOPER_DIR was not needed (XC4 must be selected to achieve this) > Configure failed - Configure properly failed when it detected Xcode > 4 > > "Selected" Xcode means version reported by xcode-select -p > > > | Xcode selected | --with-xcode-path | DEVELOPER_DIR | result | > ----------------------------------------------------------------------------- > | XC4 | | | DEV_DIR NOT set | > ----------------------------------------------------------------------------- > | XC4 | | XC4 | DEV_DIR set | > ----------------------------------------------------------------------------- > | XC4 | | XC6 | Configure failed | > ----------------------------------------------------------------------------- > | XC4 | XC4 | | DEV_DIR set | > ----------------------------------------------------------------------------- > | XC4 | XC4 | XC4 | DEV_DIR set | > ----------------------------------------------------------------------------- > | XC4 | XC4 | XC6 | DEV_DIR set | > ----------------------------------------------------------------------------- > | XC4 | XC6 | | Configure failed | > ----------------------------------------------------------------------------- > | XC4 | XC6 | XC4 | Configure failed | > ----------------------------------------------------------------------------- > | XC4 | XC6 | XC6 | Configure failed | > ----------------------------------------------------------------------------- > | XC6 | | | Configure failed | > ----------------------------------------------------------------------------- > | XC6 | | XC4 | DEV_DIR set | > ----------------------------------------------------------------------------- > | XC6 | | XC6 | Configure failed | > ----------------------------------------------------------------------------- > | XC6 | XC4 | | DEV_DIR set | > ----------------------------------------------------------------------------- > | XC6 | XC4 | XC4 | DEV_DIR set | > ----------------------------------------------------------------------------- > | XC6 | XC4 | XC6 | DEV_DIR set | > ----------------------------------------------------------------------------- > | XC6 | XC6 | | Configure failed | > ----------------------------------------------------------------------------- > | XC6 | XC6 | XC4 | Configure failed | > ----------------------------------------------------------------------------- > | XC6 | XC6 | XC6 | Configure failed | > ----------------------------------------------------------------------------- > > All the results are as expected. Please note that --with-xcode-path overrides DEVELOPER_DIR, since that could be set in the environment. > > (yeah, I went a little OCD on this...) > > -DrD- > From alexander.zvegintsev at oracle.com Wed Jan 14 13:44:24 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 14 Jan 2015 16:44:24 +0300 Subject: [9] review request for 8061636: Fix for JDK-7079254 changes behavior of MouseListener, MouseMotionListener Message-ID: <54B672B8.5060707@oracle.com> Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8061636/00 for the issue https://bugs.openjdk.java.net/browse/JDK-8061636 7079254 fix[1] introduced a regression in MouseListener, MouseMotionListener behaviour. So this fix contains: rollback of 7079254 memory leak fix based on WeakReference [1] https://bugs.openjdk.java.net/browse/JDK-7079254 -- Thanks, Alexander. From Sergey.Bylokhov at oracle.com Wed Jan 14 14:37:13 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 14 Jan 2015 17:37:13 +0300 Subject: [9] review request for 8061636: Fix for JDK-7079254 changes behavior of MouseListener, MouseMotionListener In-Reply-To: <54B672B8.5060707@oracle.com> References: <54B672B8.5060707@oracle.com> Message-ID: <54B67F19.8010202@oracle.com> Hi, Alexander. Looks fine. I assume that the LWDispatcherMemoryLeakTest.java was passed successfully. On 14.01.2015 16:44, Alexander Zvegintsev wrote: > Hello, > > please review the fix > http://cr.openjdk.java.net/~azvegint/jdk/9/8061636/00 > for the issue > https://bugs.openjdk.java.net/browse/JDK-8061636 > > 7079254 fix[1] introduced a regression in MouseListener, > MouseMotionListener behaviour. > > So this fix contains: > rollback of 7079254 > memory leak fix based on WeakReference > > [1] https://bugs.openjdk.java.net/browse/JDK-7079254 > -- Best regards, Sergey. From david.dehaven at oracle.com Wed Jan 14 20:23:50 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 14 Jan 2015 12:23:50 -0800 Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <54B629D8.8070700@oracle.com> References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com> <54B3A38C.10909@oracle.com> <8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com> <08C63261-D594-404E-892B-BDE2898B505A@oracle.com> <4DC9B291-D302-428C-A5F7-177066C65991@oracle.com> <54B629D8.8070700@oracle.com> Message-ID: Can someone from hotspot-dev please look at the hotspot changes? -DrD- > Hello, > > This looks good to me. Thanks for the detailed table! > > /Erik > > On 2015-01-14 04:09, David DeHaven wrote: >>>> The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path. >>> Ugh. I broke something along the way, this doesn't *quite* work. >>> >>> xcrun complains with "xcrun: error: missing DEVELOPER_DIR path:" >>> >>> I think I'm exporting an empty DEVELOPER_DIR. I shall fix and update. >> TL;DR: Please review round 2: >> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v1/ >> >> (I removed generated-configure.sh to reduce the review size, it will be re-generated prior to pushing) >> >> >> I've tested the following configuration scenarios (output from a shell script I cobbled together..) >> >> field values: >> XC6 - Xcode 6 installed in /Applications/Xcode.app >> XC4 - Xcode 4 installed in some other dir >> (empty) - Argument not passed to configure >> >> Result meanings: >> DEV_DIR set - configure succeeded, DEVELOPER_DIR was properly exported in spec.gmk >> DEV_DIR NOT set - configure succeeded, DEVELOPER_DIR was not needed (XC4 must be selected to achieve this) >> Configure failed - Configure properly failed when it detected Xcode > 4 >> >> "Selected" Xcode means version reported by xcode-select -p >> >> >> | Xcode selected | --with-xcode-path | DEVELOPER_DIR | result | >> ----------------------------------------------------------------------------- >> | XC4 | | | DEV_DIR NOT set | >> ----------------------------------------------------------------------------- >> | XC4 | | XC4 | DEV_DIR set | >> ----------------------------------------------------------------------------- >> | XC4 | | XC6 | Configure failed | >> ----------------------------------------------------------------------------- >> | XC4 | XC4 | | DEV_DIR set | >> ----------------------------------------------------------------------------- >> | XC4 | XC4 | XC4 | DEV_DIR set | >> ----------------------------------------------------------------------------- >> | XC4 | XC4 | XC6 | DEV_DIR set | >> ----------------------------------------------------------------------------- >> | XC4 | XC6 | | Configure failed | >> ----------------------------------------------------------------------------- >> | XC4 | XC6 | XC4 | Configure failed | >> ----------------------------------------------------------------------------- >> | XC4 | XC6 | XC6 | Configure failed | >> ----------------------------------------------------------------------------- >> | XC6 | | | Configure failed | >> ----------------------------------------------------------------------------- >> | XC6 | | XC4 | DEV_DIR set | >> ----------------------------------------------------------------------------- >> | XC6 | | XC6 | Configure failed | >> ----------------------------------------------------------------------------- >> | XC6 | XC4 | | DEV_DIR set | >> ----------------------------------------------------------------------------- >> | XC6 | XC4 | XC4 | DEV_DIR set | >> ----------------------------------------------------------------------------- >> | XC6 | XC4 | XC6 | DEV_DIR set | >> ----------------------------------------------------------------------------- >> | XC6 | XC6 | | Configure failed | >> ----------------------------------------------------------------------------- >> | XC6 | XC6 | XC4 | Configure failed | >> ----------------------------------------------------------------------------- >> | XC6 | XC6 | XC6 | Configure failed | >> ----------------------------------------------------------------------------- >> >> All the results are as expected. Please note that --with-xcode-path overrides DEVELOPER_DIR, since that could be set in the environment. >> >> (yeah, I went a little OCD on this...) >> >> -DrD- >> > From david.holmes at oracle.com Thu Jan 15 05:58:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Jan 2015 15:58:25 +1000 Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com> <54B3A38C.10909@oracle.com> <8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com> <08C63261-D594-404E-892B-BDE2898B505A@oracle.com> <4DC9B291-D302-428C-A5F7-177066C65991@oracle.com> <54B629D8.8070700@oracle.com> Message-ID: <54B75701.1080507@oracle.com> On 15/01/2015 6:23 AM, David DeHaven wrote: > > Can someone from hotspot-dev please look at the hotspot changes? Looks okay to me. Thanks, David H. > -DrD- > >> Hello, >> >> This looks good to me. Thanks for the detailed table! >> >> /Erik >> >> On 2015-01-14 04:09, David DeHaven wrote: >>>>> The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path. >>>> Ugh. I broke something along the way, this doesn't *quite* work. >>>> >>>> xcrun complains with "xcrun: error: missing DEVELOPER_DIR path:" >>>> >>>> I think I'm exporting an empty DEVELOPER_DIR. I shall fix and update. >>> TL;DR: Please review round 2: >>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v1/ >>> >>> (I removed generated-configure.sh to reduce the review size, it will be re-generated prior to pushing) >>> >>> >>> I've tested the following configuration scenarios (output from a shell script I cobbled together..) >>> >>> field values: >>> XC6 - Xcode 6 installed in /Applications/Xcode.app >>> XC4 - Xcode 4 installed in some other dir >>> (empty) - Argument not passed to configure >>> >>> Result meanings: >>> DEV_DIR set - configure succeeded, DEVELOPER_DIR was properly exported in spec.gmk >>> DEV_DIR NOT set - configure succeeded, DEVELOPER_DIR was not needed (XC4 must be selected to achieve this) >>> Configure failed - Configure properly failed when it detected Xcode > 4 >>> >>> "Selected" Xcode means version reported by xcode-select -p >>> >>> >>> | Xcode selected | --with-xcode-path | DEVELOPER_DIR | result | >>> ----------------------------------------------------------------------------- >>> | XC4 | | | DEV_DIR NOT set | >>> ----------------------------------------------------------------------------- >>> | XC4 | | XC4 | DEV_DIR set | >>> ----------------------------------------------------------------------------- >>> | XC4 | | XC6 | Configure failed | >>> ----------------------------------------------------------------------------- >>> | XC4 | XC4 | | DEV_DIR set | >>> ----------------------------------------------------------------------------- >>> | XC4 | XC4 | XC4 | DEV_DIR set | >>> ----------------------------------------------------------------------------- >>> | XC4 | XC4 | XC6 | DEV_DIR set | >>> ----------------------------------------------------------------------------- >>> | XC4 | XC6 | | Configure failed | >>> ----------------------------------------------------------------------------- >>> | XC4 | XC6 | XC4 | Configure failed | >>> ----------------------------------------------------------------------------- >>> | XC4 | XC6 | XC6 | Configure failed | >>> ----------------------------------------------------------------------------- >>> | XC6 | | | Configure failed | >>> ----------------------------------------------------------------------------- >>> | XC6 | | XC4 | DEV_DIR set | >>> ----------------------------------------------------------------------------- >>> | XC6 | | XC6 | Configure failed | >>> ----------------------------------------------------------------------------- >>> | XC6 | XC4 | | DEV_DIR set | >>> ----------------------------------------------------------------------------- >>> | XC6 | XC4 | XC4 | DEV_DIR set | >>> ----------------------------------------------------------------------------- >>> | XC6 | XC4 | XC6 | DEV_DIR set | >>> ----------------------------------------------------------------------------- >>> | XC6 | XC6 | | Configure failed | >>> ----------------------------------------------------------------------------- >>> | XC6 | XC6 | XC4 | Configure failed | >>> ----------------------------------------------------------------------------- >>> | XC6 | XC6 | XC6 | Configure failed | >>> ----------------------------------------------------------------------------- >>> >>> All the results are as expected. Please note that --with-xcode-path overrides DEVELOPER_DIR, since that could be set in the environment. >>> >>> (yeah, I went a little OCD on this...) >>> >>> -DrD- >>> >> > From alexandr.scherbatiy at oracle.com Fri Jan 16 09:46:09 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 16 Jan 2015 12:46:09 +0300 Subject: [9] review request for 8061636: Fix for JDK-7079254 changes behavior of MouseListener, MouseMotionListener In-Reply-To: <54B672B8.5060707@oracle.com> References: <54B672B8.5060707@oracle.com> Message-ID: <54B8DDE1.8050101@oracle.com> The fix looks good to me. Thanks, Alexandr. On 1/14/2015 4:44 PM, Alexander Zvegintsev wrote: > Hello, > > please review the fix > http://cr.openjdk.java.net/~azvegint/jdk/9/8061636/00 > for the issue > https://bugs.openjdk.java.net/browse/JDK-8061636 > > 7079254 fix[1] introduced a regression in MouseListener, > MouseMotionListener behaviour. > > So this fix contains: > rollback of 7079254 > memory leak fix based on WeakReference > > [1] https://bugs.openjdk.java.net/browse/JDK-7079254 > From mikhail.cherkasov at oracle.com Fri Jan 16 14:18:32 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Fri, 16 Jan 2015 17:18:32 +0300 Subject: Review Request for 8065709: Deadlock in awt/logging apparently introduced by 8019623 Message-ID: <54B91DB8.2070904@oracle.com> Hi all, JBS: https://bugs.openjdk.java.net/browse/JDK-8065709 Webrev: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.00/ AppContext creation is guarder by getAppContextLockand, but during AppContext creation we also call EventQueue initialization, during EQ initialization logger initialization happens it acquires "javaAwtAccess". if "javaAwtAccess" is acquired by other it can lead to deadlock: T1 T2 start AppContext creation acquire javaAwtAccess acquire getAppContextLock init EQ call getAppContext init Logger waiting for getAppContextLock waiting for javaAwtAccess I applied the fix suggested in jbs comments by Petr. I replaced eager logger initialization in EQ with lazy, so we won't invoke Logger during EQ initialization as result no deadlock. Thanks, Mikhail. From alexandr.scherbatiy at oracle.com Fri Jan 16 15:14:59 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 16 Jan 2015 18:14:59 +0300 Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module In-Reply-To: <54B5755E.5010104@oracle.com> References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com> <54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com> <54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com> <54B528DF.8020507@oracle.com> <54B52A47.8030501@oracle.com> <54B53DAD.80407@oracle.com> <54B5692C.2000507@oracle.com> <54B57265.3060307@oracle.com> <54B5755E.5010104@oracle.com> Message-ID: <54B92AF3.10503@oracle.com> The jdk part of the fix looks good. Thanks, Alexandr. On 1/13/2015 10:43 PM, Mandy Chung wrote: > > On 1/13/2015 11:30 AM, Sergey Bylokhov wrote: >> On 13.01.2015 21:51, Alan Bateman wrote: >>> I think this looks okay. I see Mandy's comment about dropping the >>> dependency on sun.security.util and that would be good to do (but >>> can be another patch if you want). >> ok. The new versions: >> http://cr.openjdk.java.net/~serb/8056298/webrev.05/jdk >> http://cr.openjdk.java.net/~serb/8056298/webrev.05/root >> GET_CLASSLOADER_PERMISSION was removed. >> > > Looks good. Thanks for removing that dependency. > > Mandy From anton.tarasov at oracle.com Mon Jan 19 14:59:08 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 19 Jan 2015 17:59:08 +0300 Subject: Review Request for 8065709: Deadlock in awt/logging apparently introduced by 8019623 In-Reply-To: <54B91DB8.2070904@oracle.com> References: <54B91DB8.2070904@oracle.com> Message-ID: <54BD1BBC.3000400@oracle.com> Hi Mikhail, It seems the problem is not limited to EventQueue only. Even if you solve it for EventQueue, the EventQueue ctor may cause a chain of calls where some other AWT class is first accessed and initialized. What if it contains the same getLogger() call in a static block? If you agree with this, then there should be a generic solution for the deadlock. What comes to my mind is the following. The deadlock happens due to a reverse lock taking order. Can we change it? In LogManager.getUserContext() it seems like the javaAwtAccess lock scope can be narrowed down. Namely, we can move the javaAwtAccess.getAppletContext() line out of it. In which case the method implementation should be additionally synchronized. For instance, we can use the getAppContextLock for the whole body of the method. Is the method implemented somewhere else except the AppContext class? Will it work from your point of view? (Probably, I didn't take into account all the details.) Regards, Anton. On 16.01.2015 17:18, mikhail cherkasov wrote: > Hi all, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8065709 > Webrev: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.00/ > > AppContext creation is guarder by getAppContextLockand, but during AppContext creation > we also call EventQueue initialization, during EQ initialization logger initialization happens > it acquires "javaAwtAccess". if "javaAwtAccess" is acquired by other it can lead to deadlock: > > > T1 T2 > start AppContext creation > acquire javaAwtAccess > acquire getAppContextLock > init EQ call getAppContext > init Logger waiting for getAppContextLock > waiting for javaAwtAccess > > > I applied the fix suggested in jbs comments by Petr. > I replaced eager logger initialization in EQ with lazy, so we won't invoke Logger > during EQ initialization as result no deadlock. > > Thanks, > Mikhail. > From mikhail.cherkasov at oracle.com Mon Jan 19 16:15:45 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Mon, 19 Jan 2015 19:15:45 +0300 Subject: Review Request for 8065709: Deadlock in awt/logging apparently introduced by 8019623 In-Reply-To: <54BD1BBC.3000400@oracle.com> References: <54B91DB8.2070904@oracle.com> <54BD1BBC.3000400@oracle.com> Message-ID: <54BD2DB1.4040002@oracle.com> On 1/19/2015 5:59 PM, Anton V. Tarasov wrote: > Hi Mikhail, > > It seems the problem is not limited to EventQueue only. Even if you > solve it for EventQueue, the EventQueue ctor may cause a chain of > calls where some other AWT class is first accessed and initialized. > What if it contains the same getLogger() call in a static block? it can, but currently EventQueue doesn't do such things. > > If you agree with this, then there should be a generic solution for > the deadlock. > > What comes to my mind is the following. The deadlock happens due to a > reverse lock taking order. Can we change it? > > In LogManager.getUserContext() it seems like the javaAwtAccess lock > scope can be narrowed down. Namely, we can move the > javaAwtAccess.getAppletContext() line out of it. it's already done: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a > In which case the method implementation should be additionally > synchronized. For instance, we can use the getAppContextLock for the > whole body of the method. Is the method implemented somewhere else > except the AppContext class? > > Will it work from your point of view? (Probably, I didn't take into > account all the details.) All this tricky synchronizations was done on purpose, I believe it was done for performance sake. So I want to make as less changes as possible, it's better to still miss couple cases then introduce a new big issue in the last public update. Anyway, this fix plus http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a should cover all cases, the only possible if EQ ctor will lead to javaAwtAccess, but it doesn't. > > Regards, > Anton. > > On 16.01.2015 17:18, mikhail cherkasov wrote: >> Hi all, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8065709 >> Webrev: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.00/ >> >> AppContext creation is guarder by getAppContextLockand, but during >> AppContext creation >> we also call EventQueue initialization, during EQ initialization >> logger initialization happens >> it acquires "javaAwtAccess". if "javaAwtAccess" is acquired by other >> it can lead to deadlock: >> >> >> T1 T2 >> start AppContext creation >> acquire >> javaAwtAccess >> acquire getAppContextLock >> init EQ call getAppContext >> init Logger waiting for >> getAppContextLock >> waiting for javaAwtAccess >> >> >> I applied the fix suggested in jbs comments by Petr. >> I replaced eager logger initialization in EQ with lazy, so we won't >> invoke Logger >> during EQ initialization as result no deadlock. >> >> Thanks, >> Mikhail. >> > From anton.tarasov at oracle.com Mon Jan 19 19:38:07 2015 From: anton.tarasov at oracle.com (Anton Tarasov) Date: Mon, 19 Jan 2015 22:38:07 +0300 Subject: Review Request for 8065709: Deadlock in awt/logging apparently introduced by 8019623 In-Reply-To: <54BD2DB1.4040002@oracle.com> References: <54B91DB8.2070904@oracle.com> <54BD1BBC.3000400@oracle.com> <54BD2DB1.4040002@oracle.com> Message-ID: <54BD5D1F.3010402@oracle.com> On 19/01/15 19:15, mikhail cherkasov wrote: > On 1/19/2015 5:59 PM, Anton V. Tarasov wrote: >> Hi Mikhail, >> >> It seems the problem is not limited to EventQueue only. Even if you >> solve it for EventQueue, the EventQueue ctor may cause a chain of >> calls where some other AWT class is first accessed and initialized. >> What if it contains the same getLogger() call in a static block? > it can, but currently EventQueue doesn't do such things. I guess that it's nearly impossible to guarantee that AppContext ctor will never ever call anything containing uninitialized loggers. >> >> If you agree with this, then there should be a generic solution for >> the deadlock. >> >> What comes to my mind is the following. The deadlock happens due to a >> reverse lock taking order. Can we change it? >> >> In LogManager.getUserContext() it seems like the javaAwtAccess lock >> scope can be narrowed down. Namely, we can move the >> javaAwtAccess.getAppletContext() line out of it. > it's already done: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a Oh, thanks, I didn't read all the discussion the first time. Well, I see there's another deadlock involving the sun.util.logging.PlatformLogger class... >> In which case the method implementation should be additionally >> synchronized. For instance, we can use the getAppContextLock for the >> whole body of the method. Is the method implemented somewhere else >> except the AppContext class? >> >> Will it work from your point of view? (Probably, I didn't take into >> account all the details.) > All this tricky synchronizations was done on purpose, I believe it was > done for performance sake. > So I want to make as less changes as possible, it's better to still > miss couple cases then introduce a > new big issue in the last public update. Anyway, this fix plus > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a > should cover all cases, the only possible if EQ ctor will lead to > javaAwtAccess, but it doesn't. Ok, I'm fine with the fix (it looks harmless). However, I can't say I like it because it introduses new lock and breaks consistency (in all the other cases we get loggers directly)... I'd look for any better solution in an appropriate time slot. Reagards, Anton. >> >> Regards, >> Anton. >> >> On 16.01.2015 17:18, mikhail cherkasov wrote: >>> Hi all, >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8065709 >>> Webrev: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.00/ >>> >>> AppContext creation is guarder by getAppContextLockand, but during >>> AppContext creation >>> we also call EventQueue initialization, during EQ initialization >>> logger initialization happens >>> it acquires "javaAwtAccess". if "javaAwtAccess" is acquired by >>> other it can lead to deadlock: >>> >>> >>> T1 T2 >>> start AppContext creation >>> acquire >>> javaAwtAccess >>> acquire getAppContextLock >>> init EQ call getAppContext >>> init Logger waiting for >>> getAppContextLock >>> waiting for javaAwtAccess >>> >>> >>> I applied the fix suggested in jbs comments by Petr. >>> I replaced eager logger initialization in EQ with lazy, so we won't >>> invoke Logger >>> during EQ initialization as result no deadlock. >>> >>> Thanks, >>> Mikhail. >>> >> > From mikhail.cherkasov at oracle.com Tue Jan 20 14:26:16 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Tue, 20 Jan 2015 17:26:16 +0300 Subject: Review Request for 8065709: Deadlock in awt/logging apparently introduced by 8019623 In-Reply-To: <54BD5D1F.3010402@oracle.com> References: <54B91DB8.2070904@oracle.com> <54BD1BBC.3000400@oracle.com> <54BD2DB1.4040002@oracle.com> <54BD5D1F.3010402@oracle.com> Message-ID: <54BE6588.7010202@oracle.com> Hi Anton, please check new version: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.01/src/share/classes/java/awt/EventQueue.java.udiff.html I applied changes advised by your in offline, the synchronization and second check for null was removed. PlatformLogger.getLogger is already synchronized and can be treated as sync block and second check. Thanks, Mikhail. On 1/19/2015 10:38 PM, Anton Tarasov wrote: > > On 19/01/15 19:15, mikhail cherkasov wrote: >> On 1/19/2015 5:59 PM, Anton V. Tarasov wrote: >>> Hi Mikhail, >>> >>> It seems the problem is not limited to EventQueue only. Even if you >>> solve it for EventQueue, the EventQueue ctor may cause a chain of >>> calls where some other AWT class is first accessed and initialized. >>> What if it contains the same getLogger() call in a static block? >> it can, but currently EventQueue doesn't do such things. > > I guess that it's nearly impossible to guarantee that AppContext ctor > will never ever call anything containing uninitialized loggers. > >>> >>> If you agree with this, then there should be a generic solution for >>> the deadlock. >>> >>> What comes to my mind is the following. The deadlock happens due to >>> a reverse lock taking order. Can we change it? >>> >>> In LogManager.getUserContext() it seems like the javaAwtAccess lock >>> scope can be narrowed down. Namely, we can move the >>> javaAwtAccess.getAppletContext() line out of it. >> it's already done: >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a > > Oh, thanks, I didn't read all the discussion the first time. Well, I > see there's another deadlock involving the > sun.util.logging.PlatformLogger class... > >>> In which case the method implementation should be additionally >>> synchronized. For instance, we can use the getAppContextLock for the >>> whole body of the method. Is the method implemented somewhere else >>> except the AppContext class? >>> >>> Will it work from your point of view? (Probably, I didn't take into >>> account all the details.) >> All this tricky synchronizations was done on purpose, I believe it >> was done for performance sake. >> So I want to make as less changes as possible, it's better to still >> miss couple cases then introduce a >> new big issue in the last public update. Anyway, this fix plus >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >> should cover all cases, the only possible if EQ ctor will lead to >> javaAwtAccess, but it doesn't. > > Ok, I'm fine with the fix (it looks harmless). However, I can't say I > like it because it introduses new lock and breaks consistency (in all > the other cases we get loggers directly)... > > I'd look for any better solution in an appropriate time slot. > > Reagards, > Anton. > >>> >>> Regards, >>> Anton. >>> >>> On 16.01.2015 17:18, mikhail cherkasov wrote: >>>> Hi all, >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8065709 >>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.00/ >>>> >>>> AppContext creation is guarder by getAppContextLockand, but during >>>> AppContext creation >>>> we also call EventQueue initialization, during EQ initialization >>>> logger initialization happens >>>> it acquires "javaAwtAccess". if "javaAwtAccess" is acquired by >>>> other it can lead to deadlock: >>>> >>>> >>>> T1 T2 >>>> start AppContext creation >>>> acquire >>>> javaAwtAccess >>>> acquire getAppContextLock >>>> init EQ call getAppContext >>>> init Logger waiting for >>>> getAppContextLock >>>> waiting for javaAwtAccess >>>> >>>> >>>> I applied the fix suggested in jbs comments by Petr. >>>> I replaced eager logger initialization in EQ with lazy, so we won't >>>> invoke Logger >>>> during EQ initialization as result no deadlock. >>>> >>>> Thanks, >>>> Mikhail. >>>> >>> >> > From anton.nashatyrev at oracle.com Tue Jan 20 15:42:55 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Tue, 20 Jan 2015 18:42:55 +0300 Subject: [9] Review request for 8068283: Mac OS Incompatibility between JDK 6 and 8 regarding input method handling Message-ID: <54BE777F.4020501@oracle.com> Hello Alexander, Anton could you please review the following fix: fix: http://cr.openjdk.java.net/~anashaty/8068283/9/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8068283 Problem: No ways for keyboard shortcuts like + Char on Mac OS Fix: Change the fix approach for the bug JDK-7144063 which has changed the behavior of the original Apple JDK port. Thanks! Anton. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zuev at oracle.com Tue Jan 20 15:46:00 2015 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 20 Jan 2015 18:46:00 +0300 Subject: [9] Review request for 8068283: Mac OS Incompatibility between JDK 6 and 8 regarding input method handling In-Reply-To: <54BE777F.4020501@oracle.com> References: <54BE777F.4020501@oracle.com> Message-ID: <54BE7838.1070309@oracle.com> Looks good to me. /Alex On 20/01/15 18:42, Anton Nashatyrev wrote: > Hello Alexander, Anton > > could you please review the following fix: > > fix: http://cr.openjdk.java.net/~anashaty/8068283/9/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8068283 > > Problem: No ways for keyboard shortcuts like + Char on Mac OS > > Fix: Change the fix approach for the bug JDK-7144063 > which has changed > the behavior of the original Apple JDK port. > > Thanks! > Anton. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.tarasov at oracle.com Tue Jan 20 16:08:06 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 20 Jan 2015 19:08:06 +0300 Subject: Review Request for 8065709: Deadlock in awt/logging apparently introduced by 8019623 In-Reply-To: <54BE6588.7010202@oracle.com> References: <54B91DB8.2070904@oracle.com> <54BD1BBC.3000400@oracle.com> <54BD2DB1.4040002@oracle.com> <54BD5D1F.3010402@oracle.com> <54BE6588.7010202@oracle.com> Message-ID: <54BE7D66.3030004@oracle.com> Hi Mikhail, Ok, you removed the new lock at least. Looks better now (no more comments from me). Thank you! Regards, Anton. On 20.01.2015 17:26, mikhail cherkasov wrote: > Hi Anton, > > please check new version: > http://cr.openjdk.java.net/~mcherkas/8065709/webrev.01/src/share/classes/java/awt/EventQueue.java.udiff.html > I applied changes advised by your in offline, the synchronization and second check for null was > removed. > PlatformLogger.getLogger is already synchronized and can be treated as sync block and second check. > > Thanks, > Mikhail. > > On 1/19/2015 10:38 PM, Anton Tarasov wrote: >> >> On 19/01/15 19:15, mikhail cherkasov wrote: >>> On 1/19/2015 5:59 PM, Anton V. Tarasov wrote: >>>> Hi Mikhail, >>>> >>>> It seems the problem is not limited to EventQueue only. Even if you solve it for EventQueue, >>>> the EventQueue ctor may cause a chain of calls where some other AWT class is first accessed and >>>> initialized. What if it contains the same getLogger() call in a static block? >>> it can, but currently EventQueue doesn't do such things. >> >> I guess that it's nearly impossible to guarantee that AppContext ctor will never ever call >> anything containing uninitialized loggers. >> >>>> >>>> If you agree with this, then there should be a generic solution for the deadlock. >>>> >>>> What comes to my mind is the following. The deadlock happens due to a reverse lock taking >>>> order. Can we change it? >>>> >>>> In LogManager.getUserContext() it seems like the javaAwtAccess lock scope can be narrowed down. >>>> Namely, we can move the javaAwtAccess.getAppletContext() line out of it. >>> it's already done: >>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >> >> Oh, thanks, I didn't read all the discussion the first time. Well, I see there's another deadlock >> involving the sun.util.logging.PlatformLogger class... >> >>>> In which case the method implementation should be additionally synchronized. For instance, we >>>> can use the getAppContextLock for the whole body of the method. Is the method implemented >>>> somewhere else except the AppContext class? >>>> >>>> Will it work from your point of view? (Probably, I didn't take into account all the details.) >>> All this tricky synchronizations was done on purpose, I believe it was done for performance sake. >>> So I want to make as less changes as possible, it's better to still miss couple cases then >>> introduce a >>> new big issue in the last public update. Anyway, this fix plus >>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >>> should cover all cases, the only possible if EQ ctor will lead to javaAwtAccess, but it doesn't. >> >> Ok, I'm fine with the fix (it looks harmless). However, I can't say I like it because it >> introduses new lock and breaks consistency (in all the other cases we get loggers directly)... >> >> I'd look for any better solution in an appropriate time slot. >> >> Reagards, >> Anton. >> >>>> >>>> Regards, >>>> Anton. >>>> >>>> On 16.01.2015 17:18, mikhail cherkasov wrote: >>>>> Hi all, >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8065709 >>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.00/ >>>>> >>>>> AppContext creation is guarder by getAppContextLockand, but during AppContext creation >>>>> we also call EventQueue initialization, during EQ initialization logger initialization happens >>>>> it acquires "javaAwtAccess". if "javaAwtAccess" is acquired by other it can lead to deadlock: >>>>> >>>>> >>>>> T1 T2 >>>>> start AppContext creation >>>>> acquire javaAwtAccess >>>>> acquire getAppContextLock >>>>> init EQ call getAppContext >>>>> init Logger waiting for getAppContextLock >>>>> waiting for javaAwtAccess >>>>> >>>>> >>>>> I applied the fix suggested in jbs comments by Petr. >>>>> I replaced eager logger initialization in EQ with lazy, so we won't invoke Logger >>>>> during EQ initialization as result no deadlock. >>>>> >>>>> Thanks, >>>>> Mikhail. >>>>> >>>> >>> >> > From anton.tarasov at oracle.com Tue Jan 20 16:11:03 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 20 Jan 2015 19:11:03 +0300 Subject: [9] Review request for 8068283: Mac OS Incompatibility between JDK 6 and 8 regarding input method handling In-Reply-To: <54BE777F.4020501@oracle.com> References: <54BE777F.4020501@oracle.com> Message-ID: <54BE7E17.30604@oracle.com> Looks fine! Thanks, Anton. On 20.01.2015 18:42, Anton Nashatyrev wrote: > Hello Alexander, Anton > > could you please review the following fix: > > fix: http://cr.openjdk.java.net/~anashaty/8068283/9/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8068283 > > Problem: No ways for keyboard shortcuts like + Char on Mac OS > > Fix: Change the fix approach for the bug JDK-7144063 > which has changed the behavior of the original > Apple JDK port. > > Thanks! > Anton. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Jan 20 17:09:11 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 20 Jan 2015 20:09:11 +0300 Subject: [9] Review request for 8068283: Mac OS Incompatibility between JDK 6 and 8 regarding input method handling In-Reply-To: <54BE777F.4020501@oracle.com> References: <54BE777F.4020501@oracle.com> Message-ID: <54BE8BB7.8090504@oracle.com> As this bug became so critical I suggest to test all supported l&f in the test. On 20.01.2015 18:42, Anton Nashatyrev wrote: > Hello Alexander, Anton > > could you please review the following fix: > > fix: http://cr.openjdk.java.net/~anashaty/8068283/9/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8068283 > > Problem: No ways for keyboard shortcuts like + Char on Mac OS > > Fix: Change the fix approach for the bug JDK-7144063 > which has changed > the behavior of the original Apple JDK port. > > Thanks! > Anton. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Jan 20 17:14:53 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 20 Jan 2015 20:14:53 +0300 Subject: Review Request for 8065709: Deadlock in awt/logging apparently introduced by 8019623 In-Reply-To: <54BE7D66.3030004@oracle.com> References: <54B91DB8.2070904@oracle.com> <54BD1BBC.3000400@oracle.com> <54BD2DB1.4040002@oracle.com> <54BD5D1F.3010402@oracle.com> <54BE6588.7010202@oracle.com> <54BE7D66.3030004@oracle.com> Message-ID: <54BE8D0D.8030209@oracle.com> On 20.01.2015 19:08, Anton V. Tarasov wrote: > Hi Mikhail, > > Ok, you removed the new lock at least. Looks better now (no more > comments from me). Thank you! Personally I prefered to remove this logging, but this version looks fine also. > > Regards, > Anton. > > On 20.01.2015 17:26, mikhail cherkasov wrote: >> Hi Anton, >> >> please check new version: >> http://cr.openjdk.java.net/~mcherkas/8065709/webrev.01/src/share/classes/java/awt/EventQueue.java.udiff.html >> I applied changes advised by your in offline, the synchronization and >> second check for null was removed. >> PlatformLogger.getLogger is already synchronized and can be treated >> as sync block and second check. >> >> Thanks, >> Mikhail. >> >> On 1/19/2015 10:38 PM, Anton Tarasov wrote: >>> >>> On 19/01/15 19:15, mikhail cherkasov wrote: >>>> On 1/19/2015 5:59 PM, Anton V. Tarasov wrote: >>>>> Hi Mikhail, >>>>> >>>>> It seems the problem is not limited to EventQueue only. Even if >>>>> you solve it for EventQueue, the EventQueue ctor may cause a chain >>>>> of calls where some other AWT class is first accessed and >>>>> initialized. What if it contains the same getLogger() call in a >>>>> static block? >>>> it can, but currently EventQueue doesn't do such things. >>> >>> I guess that it's nearly impossible to guarantee that AppContext >>> ctor will never ever call anything containing uninitialized loggers. >>> >>>>> >>>>> If you agree with this, then there should be a generic solution >>>>> for the deadlock. >>>>> >>>>> What comes to my mind is the following. The deadlock happens due >>>>> to a reverse lock taking order. Can we change it? >>>>> >>>>> In LogManager.getUserContext() it seems like the javaAwtAccess >>>>> lock scope can be narrowed down. Namely, we can move the >>>>> javaAwtAccess.getAppletContext() line out of it. >>>> it's already done: >>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >>> >>> Oh, thanks, I didn't read all the discussion the first time. Well, I >>> see there's another deadlock involving the >>> sun.util.logging.PlatformLogger class... >>> >>>>> In which case the method implementation should be additionally >>>>> synchronized. For instance, we can use the getAppContextLock for >>>>> the whole body of the method. Is the method implemented somewhere >>>>> else except the AppContext class? >>>>> >>>>> Will it work from your point of view? (Probably, I didn't take >>>>> into account all the details.) >>>> All this tricky synchronizations was done on purpose, I believe it >>>> was done for performance sake. >>>> So I want to make as less changes as possible, it's better to still >>>> miss couple cases then introduce a >>>> new big issue in the last public update. Anyway, this fix plus >>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >>>> should cover all cases, the only possible if EQ ctor will lead to >>>> javaAwtAccess, but it doesn't. >>> >>> Ok, I'm fine with the fix (it looks harmless). However, I can't say >>> I like it because it introduses new lock and breaks consistency (in >>> all the other cases we get loggers directly)... >>> >>> I'd look for any better solution in an appropriate time slot. >>> >>> Reagards, >>> Anton. >>> >>>>> >>>>> Regards, >>>>> Anton. >>>>> >>>>> On 16.01.2015 17:18, mikhail cherkasov wrote: >>>>>> Hi all, >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8065709 >>>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.00/ >>>>>> >>>>>> AppContext creation is guarder by getAppContextLockand, but >>>>>> during AppContext creation >>>>>> we also call EventQueue initialization, during EQ initialization >>>>>> logger initialization happens >>>>>> it acquires "javaAwtAccess". if "javaAwtAccess" is acquired by >>>>>> other it can lead to deadlock: >>>>>> >>>>>> >>>>>> T1 T2 >>>>>> start AppContext creation >>>>>> acquire javaAwtAccess >>>>>> acquire getAppContextLock >>>>>> init EQ call getAppContext >>>>>> init Logger waiting for >>>>>> getAppContextLock >>>>>> waiting for javaAwtAccess >>>>>> >>>>>> >>>>>> I applied the fix suggested in jbs comments by Petr. >>>>>> I replaced eager logger initialization in EQ with lazy, so we >>>>>> won't invoke Logger >>>>>> during EQ initialization as result no deadlock. >>>>>> >>>>>> Thanks, >>>>>> Mikhail. >>>>>> >>>>> >>>> >>> >> > -- Best regards, Sergey. From anton.nashatyrev at oracle.com Wed Jan 21 11:02:08 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Wed, 21 Jan 2015 14:02:08 +0300 Subject: [9] Review request for 8068283: Mac OS Incompatibility between JDK 6 and 8 regarding input method handling In-Reply-To: <54BE8BB7.8090504@oracle.com> References: <54BE777F.4020501@oracle.com> <54BE8BB7.8090504@oracle.com> Message-ID: <54BF8730.10104@oracle.com> Hi Sergey, this is completely AWT bug and I'm using Swing components for testing only. This fix gives the _possibility_ to handle +Char accelerator on Mac with any text component (filer uses it's own component and LaF). So I don't think there is too much sense to check all available JDK LaFs in this concrete fix. Thanks! Anton. P.S. Sorry, I've already pushed the fix before receiving your comment On 20.01.2015 20:09, Sergey Bylokhov wrote: > As this bug became so critical I suggest to test all supported l&f in > the test. > > On 20.01.2015 18:42, Anton Nashatyrev wrote: >> Hello Alexander, Anton >> >> could you please review the following fix: >> >> fix: http://cr.openjdk.java.net/~anashaty/8068283/9/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8068283 >> >> Problem: No ways for keyboard shortcuts like + Char on Mac OS >> >> Fix: Change the fix approach for the bug JDK-7144063 >> which has changed >> the behavior of the original Apple JDK port. >> >> Thanks! >> Anton. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Wed Jan 21 14:30:15 2015 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 21 Jan 2015 06:30:15 -0800 (PST) Subject: [9] Review request for 8068283: Mac OS Incompatibility between JDK 6 and 8 regarding input method handling Message-ID: <33202362-218a-47d0-9fd6-65621b86f4af@default> Hi, Anton . > > this is completely AWT bug and I'm using Swing components for testing only. This fix gives the _possibility_ to handle +Char accelerator on Mac with any text component (filer > uses it's own component and LaF). So I don't think there is too much sense to check all available JDK LaFs in this concrete fix. This bug wasn't found by our tests, which means that we didn't test this functionality. As this error was such serious it would be quite good to check this functionality with all l&f. Probably something does not work on Nimbus, etc... > > Thanks! > Anton. > > P.S. Sorry, I've already pushed the fix before receiving your comment > > On 20.01.2015 20:09, Sergey Bylokhov wrote: > > As this bug became so critical I suggest to test all supported l&f in the test. > > On 20.01.2015 18:42, Anton Nashatyrev wrote: > Hello Alexander, Anton > > could you please review the following fix: > > fix: http://cr.openjdk.java.net/~anashaty/8068283/9/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8068283 > > Problem: No ways for keyboard shortcuts like + Char on Mac OS > > Fix: Change the fix approach for the bug JDK-7144063 which has changed the behavior of the original Apple JDK port. > > Thanks! > Anton. > > > -- Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.nashatyrev at oracle.com Wed Jan 21 16:01:11 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Wed, 21 Jan 2015 19:01:11 +0300 Subject: [9] Review request for 8068283: Mac OS Incompatibility between JDK 6 and 8 regarding input method handling In-Reply-To: <33202362-218a-47d0-9fd6-65621b86f4af@default> References: <33202362-218a-47d0-9fd6-65621b86f4af@default> Message-ID: <54BFCD47.1080703@oracle.com> Hi Sergey, actually this bug was detected by one of our tests (some Alt combinations worked some didn't) (see JDK-7144063 ) but has been fixed in a way that all Alt combinations stopped working. Regarding the test - I'm not completely sure what do you want it to test, the Swing text components still works in a bit strange way on Mac: e.g. when pressing Alt-T both the action is executed and the cross symbol is appended to the text. Testing all Alt combinations is also not feasible since it's layout dependent - some of them should start input method and the action shouldn't be executed. The aim of this fix is to make awt sending KeyEvents instead of InputEvents when it is possible on Mac Thanks! Anton. On 21.01.2015 17:30, Sergey Bylokhov wrote: > Hi, Anton. > > > > this is completely AWT bug and I'm using Swing components for > testing only. This fix gives the _possibility_ to handle +Char > accelerator on Mac with any text component (filer > uses it's own > component and LaF). So I don't think there is too much sense to check > all available JDK LaFs in this concrete fix. > > This bug wasn't found by our tests, which means that we didn't test > this functionality. As this error was such serious it would be quite > good to check this functionality with all l&f. Probably something does > not work on Nimbus, etc... > > > > > Thanks! > > Anton. > > > > P.S. Sorry, I've already pushed the fix before receiving your comment > > > > On 20.01.2015 20:09, Sergey Bylokhov wrote: > > > > > As this bug became so critical I suggest to test all supported > l&f in the test. > > > > On 20.01.2015 18:42, Anton Nashatyrev wrote: > > > > Hello Alexander, Anton > > > > could you please review the following fix: > > > > fix: > http://cr.openjdk.java.net/~anashaty/8068283/9/webrev.00/ > > > bug: https://bugs.openjdk.java.net/browse/JDK-8068283 > > > > Problem: No ways for keyboard shortcuts like + > Char on Mac OS > > > > Fix: Change the fix approach for the bug JDK-7144063 > which has > changed the behavior of the original Apple JDK port. > > > > Thanks! > > Anton. > > > > > > > > > > -- > Best regards, Sergey. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Wed Jan 21 17:12:51 2015 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 21 Jan 2015 09:12:51 -0800 (PST) Subject: [9] Review Request: 7185221 [macosx] Regtest should not throw exception if a suitable display mode found Message-ID: Hello. Please review the fix for jdk 9. The test modify a supported list of DisplayModes and try to check that IllegalArgumentException will be thrown. But the problem occurs, when the test tries to change a supported DisplayMode which refresh rate is unknown. This happens because we match any refresh rate to a REFRESH_RATE_UNKNOWN. Bug: https://bugs.openjdk.java.net/browse/JDK-7185221 Webrev can be found at: http://cr.openjdk.java.net/~serb/7185221/webrev.00/webrev Diff: http://cr.openjdk.java.net/~serb/7185221/webrev.00/diff -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Wed Jan 21 17:47:04 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 21 Jan 2015 20:47:04 +0300 Subject: [9] Review Request: 7185221 [macosx] Regtest should not throw exception if a suitable display mode found In-Reply-To: References: Message-ID: <54BFE618.7080308@oracle.com> Hello Sergey, the fix looks good to me. -- Thanks, Alexander. On 21.01.2015 20:12, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > The test modify a supported list of DisplayModes and try to check that IllegalArgumentException will be thrown. But the problem occurs, when the test tries to change a supported DisplayMode which refresh rate is unknown. This happens because we match any refresh rate to a REFRESH_RATE_UNKNOWN. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7185221 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7185221/webrev.00/webrev > Diff: http://cr.openjdk.java.net/~serb/7185221/webrev.00/diff > From mikhail.cherkasov at oracle.com Thu Jan 22 10:42:45 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 22 Jan 2015 13:42:45 +0300 Subject: Review Request for 8065709: Deadlock in awt/logging apparently introduced by 8019623 In-Reply-To: <54BE8D0D.8030209@oracle.com> References: <54B91DB8.2070904@oracle.com> <54BD1BBC.3000400@oracle.com> <54BD2DB1.4040002@oracle.com> <54BD5D1F.3010402@oracle.com> <54BE6588.7010202@oracle.com> <54BE7D66.3030004@oracle.com> <54BE8D0D.8030209@oracle.com> Message-ID: <54C0D425.9000407@oracle.com> Hi Anton, Sergey, Anton advised today to implement eager initialization of EQ's logger instead of lazy initialization of EQ's logger. So now it will be initialized out of any AppContext's lock and I thinks it's definitely better solution because no ugly getLogger methods, less changes and now we know when and where logger will be initialized. Could you please review a new version: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.03/ ? Thanks, Mikhail. On 1/20/2015 8:14 PM, Sergey Bylokhov wrote: > On 20.01.2015 19:08, Anton V. Tarasov wrote: >> Hi Mikhail, >> >> Ok, you removed the new lock at least. Looks better now (no more >> comments from me). Thank you! > Personally I prefered to remove this logging, but this version looks > fine also. >> >> Regards, >> Anton. >> >> On 20.01.2015 17:26, mikhail cherkasov wrote: >>> Hi Anton, >>> >>> please check new version: >>> http://cr.openjdk.java.net/~mcherkas/8065709/webrev.01/src/share/classes/java/awt/EventQueue.java.udiff.html >>> I applied changes advised by your in offline, the synchronization >>> and second check for null was removed. >>> PlatformLogger.getLogger is already synchronized and can be treated >>> as sync block and second check. >>> >>> Thanks, >>> Mikhail. >>> >>> On 1/19/2015 10:38 PM, Anton Tarasov wrote: >>>> >>>> On 19/01/15 19:15, mikhail cherkasov wrote: >>>>> On 1/19/2015 5:59 PM, Anton V. Tarasov wrote: >>>>>> Hi Mikhail, >>>>>> >>>>>> It seems the problem is not limited to EventQueue only. Even if >>>>>> you solve it for EventQueue, the EventQueue ctor may cause a >>>>>> chain of calls where some other AWT class is first accessed and >>>>>> initialized. What if it contains the same getLogger() call in a >>>>>> static block? >>>>> it can, but currently EventQueue doesn't do such things. >>>> >>>> I guess that it's nearly impossible to guarantee that AppContext >>>> ctor will never ever call anything containing uninitialized loggers. >>>> >>>>>> >>>>>> If you agree with this, then there should be a generic solution >>>>>> for the deadlock. >>>>>> >>>>>> What comes to my mind is the following. The deadlock happens due >>>>>> to a reverse lock taking order. Can we change it? >>>>>> >>>>>> In LogManager.getUserContext() it seems like the javaAwtAccess >>>>>> lock scope can be narrowed down. Namely, we can move the >>>>>> javaAwtAccess.getAppletContext() line out of it. >>>>> it's already done: >>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >>>> >>>> Oh, thanks, I didn't read all the discussion the first time. Well, >>>> I see there's another deadlock involving the >>>> sun.util.logging.PlatformLogger class... >>>> >>>>>> In which case the method implementation should be additionally >>>>>> synchronized. For instance, we can use the getAppContextLock for >>>>>> the whole body of the method. Is the method implemented somewhere >>>>>> else except the AppContext class? >>>>>> >>>>>> Will it work from your point of view? (Probably, I didn't take >>>>>> into account all the details.) >>>>> All this tricky synchronizations was done on purpose, I believe it >>>>> was done for performance sake. >>>>> So I want to make as less changes as possible, it's better to >>>>> still miss couple cases then introduce a >>>>> new big issue in the last public update. Anyway, this fix plus >>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >>>>> should cover all cases, the only possible if EQ ctor will lead to >>>>> javaAwtAccess, but it doesn't. >>>> >>>> Ok, I'm fine with the fix (it looks harmless). However, I can't say >>>> I like it because it introduses new lock and breaks consistency (in >>>> all the other cases we get loggers directly)... >>>> >>>> I'd look for any better solution in an appropriate time slot. >>>> >>>> Reagards, >>>> Anton. >>>> >>>>>> >>>>>> Regards, >>>>>> Anton. >>>>>> >>>>>> On 16.01.2015 17:18, mikhail cherkasov wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8065709 >>>>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.00/ >>>>>>> >>>>>>> AppContext creation is guarder by getAppContextLockand, but >>>>>>> during AppContext creation >>>>>>> we also call EventQueue initialization, during EQ initialization >>>>>>> logger initialization happens >>>>>>> it acquires "javaAwtAccess". if "javaAwtAccess" is acquired by >>>>>>> other it can lead to deadlock: >>>>>>> >>>>>>> >>>>>>> T1 T2 >>>>>>> start AppContext creation >>>>>>> acquire javaAwtAccess >>>>>>> acquire getAppContextLock >>>>>>> init EQ call getAppContext >>>>>>> init Logger waiting for >>>>>>> getAppContextLock >>>>>>> waiting for javaAwtAccess >>>>>>> >>>>>>> >>>>>>> I applied the fix suggested in jbs comments by Petr. >>>>>>> I replaced eager logger initialization in EQ with lazy, so we >>>>>>> won't invoke Logger >>>>>>> during EQ initialization as result no deadlock. >>>>>>> >>>>>>> Thanks, >>>>>>> Mikhail. >>>>>>> >>>>>> >>>>> >>>> >>> >> > > From anton.tarasov at oracle.com Thu Jan 22 11:27:39 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 22 Jan 2015 14:27:39 +0300 Subject: Review Request for 8065709: Deadlock in awt/logging apparently introduced by 8019623 In-Reply-To: <54C0D425.9000407@oracle.com> References: <54B91DB8.2070904@oracle.com> <54BD1BBC.3000400@oracle.com> <54BD2DB1.4040002@oracle.com> <54BD5D1F.3010402@oracle.com> <54BE6588.7010202@oracle.com> <54BE7D66.3030004@oracle.com> <54BE8D0D.8030209@oracle.com> <54C0D425.9000407@oracle.com> Message-ID: <54C0DEAB.8040509@oracle.com> Hi Mikhail, This definetly looks better! Trying to think of any possible pitfalls: - EQ static initializer should not do anything connected with AppContext. Ok. - There should not be any thread access issues with the EQ static fields. Ok, they are all final. - Unsafe.getUnsafe() may throw SecurityException when its caller class is out of the system domain. Ok, AppContext is a system class. So, I personally can't see anything bad about the fix. Regards, Anton. On 22.01.2015 13:42, mikhail cherkasov wrote: > Hi Anton, Sergey, > > Anton advised today to implement eager initialization of EQ's logger instead of lazy > initialization of EQ's logger. > So now it will be initialized out of any AppContext's lock and I thinks it's definitely better > solution because > no ugly getLogger methods, less changes and now we know when and where logger will be initialized. > > Could you please review a new version: > http://cr.openjdk.java.net/~mcherkas/8065709/webrev.03/ ? > > Thanks, > Mikhail. > > > On 1/20/2015 8:14 PM, Sergey Bylokhov wrote: >> On 20.01.2015 19:08, Anton V. Tarasov wrote: >>> Hi Mikhail, >>> >>> Ok, you removed the new lock at least. Looks better now (no more comments from me). Thank you! >> Personally I prefered to remove this logging, but this version looks fine also. >>> >>> Regards, >>> Anton. >>> >>> On 20.01.2015 17:26, mikhail cherkasov wrote: >>>> Hi Anton, >>>> >>>> please check new version: >>>> http://cr.openjdk.java.net/~mcherkas/8065709/webrev.01/src/share/classes/java/awt/EventQueue.java.udiff.html >>>> I applied changes advised by your in offline, the synchronization and second check for null was >>>> removed. >>>> PlatformLogger.getLogger is already synchronized and can be treated as sync block and second >>>> check. >>>> >>>> Thanks, >>>> Mikhail. >>>> >>>> On 1/19/2015 10:38 PM, Anton Tarasov wrote: >>>>> >>>>> On 19/01/15 19:15, mikhail cherkasov wrote: >>>>>> On 1/19/2015 5:59 PM, Anton V. Tarasov wrote: >>>>>>> Hi Mikhail, >>>>>>> >>>>>>> It seems the problem is not limited to EventQueue only. Even if you solve it for EventQueue, >>>>>>> the EventQueue ctor may cause a chain of calls where some other AWT class is first accessed >>>>>>> and initialized. What if it contains the same getLogger() call in a static block? >>>>>> it can, but currently EventQueue doesn't do such things. >>>>> >>>>> I guess that it's nearly impossible to guarantee that AppContext ctor will never ever call >>>>> anything containing uninitialized loggers. >>>>> >>>>>>> >>>>>>> If you agree with this, then there should be a generic solution for the deadlock. >>>>>>> >>>>>>> What comes to my mind is the following. The deadlock happens due to a reverse lock taking >>>>>>> order. Can we change it? >>>>>>> >>>>>>> In LogManager.getUserContext() it seems like the javaAwtAccess lock scope can be narrowed >>>>>>> down. Namely, we can move the javaAwtAccess.getAppletContext() line out of it. >>>>>> it's already done: >>>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >>>>> >>>>> Oh, thanks, I didn't read all the discussion the first time. Well, I see there's another >>>>> deadlock involving the sun.util.logging.PlatformLogger class... >>>>> >>>>>>> In which case the method implementation should be additionally synchronized. For instance, >>>>>>> we can use the getAppContextLock for the whole body of the method. Is the method implemented >>>>>>> somewhere else except the AppContext class? >>>>>>> >>>>>>> Will it work from your point of view? (Probably, I didn't take into account all the details.) >>>>>> All this tricky synchronizations was done on purpose, I believe it was done for performance >>>>>> sake. >>>>>> So I want to make as less changes as possible, it's better to still miss couple cases then >>>>>> introduce a >>>>>> new big issue in the last public update. Anyway, this fix plus >>>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >>>>>> should cover all cases, the only possible if EQ ctor will lead to javaAwtAccess, but it doesn't. >>>>> >>>>> Ok, I'm fine with the fix (it looks harmless). However, I can't say I like it because it >>>>> introduses new lock and breaks consistency (in all the other cases we get loggers directly)... >>>>> >>>>> I'd look for any better solution in an appropriate time slot. >>>>> >>>>> Reagards, >>>>> Anton. >>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Anton. >>>>>>> >>>>>>> On 16.01.2015 17:18, mikhail cherkasov wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8065709 >>>>>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.00/ >>>>>>>> >>>>>>>> AppContext creation is guarder by getAppContextLockand, but during AppContext creation >>>>>>>> we also call EventQueue initialization, during EQ initialization logger initialization happens >>>>>>>> it acquires "javaAwtAccess". if "javaAwtAccess" is acquired by other it can lead to deadlock: >>>>>>>> >>>>>>>> >>>>>>>> T1 T2 >>>>>>>> start AppContext creation >>>>>>>> acquire javaAwtAccess >>>>>>>> acquire getAppContextLock >>>>>>>> init EQ call getAppContext >>>>>>>> init Logger waiting for getAppContextLock >>>>>>>> waiting for javaAwtAccess >>>>>>>> >>>>>>>> >>>>>>>> I applied the fix suggested in jbs comments by Petr. >>>>>>>> I replaced eager logger initialization in EQ with lazy, so we won't invoke Logger >>>>>>>> during EQ initialization as result no deadlock. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Mikhail. >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > From Sergey.Bylokhov at oracle.com Thu Jan 22 13:23:36 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 22 Jan 2015 16:23:36 +0300 Subject: Review Request for 8065709: Deadlock in awt/logging apparently introduced by 8019623 In-Reply-To: <54C0D425.9000407@oracle.com> References: <54B91DB8.2070904@oracle.com> <54BD1BBC.3000400@oracle.com> <54BD2DB1.4040002@oracle.com> <54BD5D1F.3010402@oracle.com> <54BE6588.7010202@oracle.com> <54BE7D66.3030004@oracle.com> <54BE8D0D.8030209@oracle.com> <54C0D425.9000407@oracle.com> Message-ID: <54C0F9D8.7010109@oracle.com> On 22.01.2015 13:42, mikhail cherkasov wrote: > Hi Anton, Sergey, > > Anton advised today to implement eager initialization of EQ's logger > instead of lazy initialization of EQ's logger. > So now it will be initialized out of any AppContext's lock and I > thinks it's definitely better solution because > no ugly getLogger methods, less changes and now we know when and where > logger will be initialized. > > Could you please review a new version: > http://cr.openjdk.java.net/~mcherkas/8065709/webrev.03/ ? No, no , no. I completely disagree on this solution. Besides that it not readable, it also contains an unobvious restrictions on EventQueue class. Lazy initialization is better, moreover we have such requests already: https://bugs.openjdk.java.net/browse/JDK-6880089 > > Thanks, > Mikhail. > > > On 1/20/2015 8:14 PM, Sergey Bylokhov wrote: >> On 20.01.2015 19:08, Anton V. Tarasov wrote: >>> Hi Mikhail, >>> >>> Ok, you removed the new lock at least. Looks better now (no more >>> comments from me). Thank you! >> Personally I prefered to remove this logging, but this version looks >> fine also. >>> >>> Regards, >>> Anton. >>> >>> On 20.01.2015 17:26, mikhail cherkasov wrote: >>>> Hi Anton, >>>> >>>> please check new version: >>>> http://cr.openjdk.java.net/~mcherkas/8065709/webrev.01/src/share/classes/java/awt/EventQueue.java.udiff.html >>>> I applied changes advised by your in offline, the synchronization >>>> and second check for null was removed. >>>> PlatformLogger.getLogger is already synchronized and can be treated >>>> as sync block and second check. >>>> >>>> Thanks, >>>> Mikhail. >>>> >>>> On 1/19/2015 10:38 PM, Anton Tarasov wrote: >>>>> >>>>> On 19/01/15 19:15, mikhail cherkasov wrote: >>>>>> On 1/19/2015 5:59 PM, Anton V. Tarasov wrote: >>>>>>> Hi Mikhail, >>>>>>> >>>>>>> It seems the problem is not limited to EventQueue only. Even if >>>>>>> you solve it for EventQueue, the EventQueue ctor may cause a >>>>>>> chain of calls where some other AWT class is first accessed and >>>>>>> initialized. What if it contains the same getLogger() call in a >>>>>>> static block? >>>>>> it can, but currently EventQueue doesn't do such things. >>>>> >>>>> I guess that it's nearly impossible to guarantee that AppContext >>>>> ctor will never ever call anything containing uninitialized loggers. >>>>> >>>>>>> >>>>>>> If you agree with this, then there should be a generic solution >>>>>>> for the deadlock. >>>>>>> >>>>>>> What comes to my mind is the following. The deadlock happens due >>>>>>> to a reverse lock taking order. Can we change it? >>>>>>> >>>>>>> In LogManager.getUserContext() it seems like the javaAwtAccess >>>>>>> lock scope can be narrowed down. Namely, we can move the >>>>>>> javaAwtAccess.getAppletContext() line out of it. >>>>>> it's already done: >>>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >>>>> >>>>> Oh, thanks, I didn't read all the discussion the first time. Well, >>>>> I see there's another deadlock involving the >>>>> sun.util.logging.PlatformLogger class... >>>>> >>>>>>> In which case the method implementation should be additionally >>>>>>> synchronized. For instance, we can use the getAppContextLock for >>>>>>> the whole body of the method. Is the method implemented >>>>>>> somewhere else except the AppContext class? >>>>>>> >>>>>>> Will it work from your point of view? (Probably, I didn't take >>>>>>> into account all the details.) >>>>>> All this tricky synchronizations was done on purpose, I believe >>>>>> it was done for performance sake. >>>>>> So I want to make as less changes as possible, it's better to >>>>>> still miss couple cases then introduce a >>>>>> new big issue in the last public update. Anyway, this fix plus >>>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >>>>>> should cover all cases, the only possible if EQ ctor will lead to >>>>>> javaAwtAccess, but it doesn't. >>>>> >>>>> Ok, I'm fine with the fix (it looks harmless). However, I can't >>>>> say I like it because it introduses new lock and breaks >>>>> consistency (in all the other cases we get loggers directly)... >>>>> >>>>> I'd look for any better solution in an appropriate time slot. >>>>> >>>>> Reagards, >>>>> Anton. >>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Anton. >>>>>>> >>>>>>> On 16.01.2015 17:18, mikhail cherkasov wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8065709 >>>>>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.00/ >>>>>>>> >>>>>>>> AppContext creation is guarder by getAppContextLockand, but >>>>>>>> during AppContext creation >>>>>>>> we also call EventQueue initialization, during EQ >>>>>>>> initialization logger initialization happens >>>>>>>> it acquires "javaAwtAccess". if "javaAwtAccess" is acquired by >>>>>>>> other it can lead to deadlock: >>>>>>>> >>>>>>>> >>>>>>>> T1 T2 >>>>>>>> start AppContext creation >>>>>>>> acquire javaAwtAccess >>>>>>>> acquire getAppContextLock >>>>>>>> init EQ call getAppContext >>>>>>>> init Logger waiting for getAppContextLock >>>>>>>> waiting for javaAwtAccess >>>>>>>> >>>>>>>> >>>>>>>> I applied the fix suggested in jbs comments by Petr. >>>>>>>> I replaced eager logger initialization in EQ with lazy, so we >>>>>>>> won't invoke Logger >>>>>>>> during EQ initialization as result no deadlock. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Mikhail. >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > -- Best regards, Sergey. From mikhail.cherkasov at oracle.com Thu Jan 22 13:27:40 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 22 Jan 2015 16:27:40 +0300 Subject: Review Request for 8065709: Deadlock in awt/logging apparently introduced by 8019623 In-Reply-To: <54C0F9D8.7010109@oracle.com> References: <54B91DB8.2070904@oracle.com> <54BD1BBC.3000400@oracle.com> <54BD2DB1.4040002@oracle.com> <54BD5D1F.3010402@oracle.com> <54BE6588.7010202@oracle.com> <54BE7D66.3030004@oracle.com> <54BE8D0D.8030209@oracle.com> <54C0D425.9000407@oracle.com> <54C0F9D8.7010109@oracle.com> Message-ID: <54C0FACC.2060209@oracle.com> Ok, the "lazy" version will be pushed. Thank you . On 1/22/2015 4:23 PM, Sergey Bylokhov wrote: > On 22.01.2015 13:42, mikhail cherkasov wrote: >> Hi Anton, Sergey, >> >> Anton advised today to implement eager initialization of EQ's logger >> instead of lazy initialization of EQ's logger. >> So now it will be initialized out of any AppContext's lock and I >> thinks it's definitely better solution because >> no ugly getLogger methods, less changes and now we know when and >> where logger will be initialized. >> >> Could you please review a new version: >> http://cr.openjdk.java.net/~mcherkas/8065709/webrev.03/ ? > No, no , no. I completely disagree on this solution. Besides that it > not readable, it also contains an unobvious restrictions on > EventQueue class. > Lazy initialization is better, moreover we have such requests already: > https://bugs.openjdk.java.net/browse/JDK-6880089 >> >> Thanks, >> Mikhail. >> >> >> On 1/20/2015 8:14 PM, Sergey Bylokhov wrote: >>> On 20.01.2015 19:08, Anton V. Tarasov wrote: >>>> Hi Mikhail, >>>> >>>> Ok, you removed the new lock at least. Looks better now (no more >>>> comments from me). Thank you! >>> Personally I prefered to remove this logging, but this version looks >>> fine also. >>>> >>>> Regards, >>>> Anton. >>>> >>>> On 20.01.2015 17:26, mikhail cherkasov wrote: >>>>> Hi Anton, >>>>> >>>>> please check new version: >>>>> http://cr.openjdk.java.net/~mcherkas/8065709/webrev.01/src/share/classes/java/awt/EventQueue.java.udiff.html >>>>> I applied changes advised by your in offline, the synchronization >>>>> and second check for null was removed. >>>>> PlatformLogger.getLogger is already synchronized and can be >>>>> treated as sync block and second check. >>>>> >>>>> Thanks, >>>>> Mikhail. >>>>> >>>>> On 1/19/2015 10:38 PM, Anton Tarasov wrote: >>>>>> >>>>>> On 19/01/15 19:15, mikhail cherkasov wrote: >>>>>>> On 1/19/2015 5:59 PM, Anton V. Tarasov wrote: >>>>>>>> Hi Mikhail, >>>>>>>> >>>>>>>> It seems the problem is not limited to EventQueue only. Even if >>>>>>>> you solve it for EventQueue, the EventQueue ctor may cause a >>>>>>>> chain of calls where some other AWT class is first accessed and >>>>>>>> initialized. What if it contains the same getLogger() call in a >>>>>>>> static block? >>>>>>> it can, but currently EventQueue doesn't do such things. >>>>>> >>>>>> I guess that it's nearly impossible to guarantee that AppContext >>>>>> ctor will never ever call anything containing uninitialized loggers. >>>>>> >>>>>>>> >>>>>>>> If you agree with this, then there should be a generic solution >>>>>>>> for the deadlock. >>>>>>>> >>>>>>>> What comes to my mind is the following. The deadlock happens >>>>>>>> due to a reverse lock taking order. Can we change it? >>>>>>>> >>>>>>>> In LogManager.getUserContext() it seems like the javaAwtAccess >>>>>>>> lock scope can be narrowed down. Namely, we can move the >>>>>>>> javaAwtAccess.getAppletContext() line out of it. >>>>>>> it's already done: >>>>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >>>>>> >>>>>> Oh, thanks, I didn't read all the discussion the first time. >>>>>> Well, I see there's another deadlock involving the >>>>>> sun.util.logging.PlatformLogger class... >>>>>> >>>>>>>> In which case the method implementation should be additionally >>>>>>>> synchronized. For instance, we can use the getAppContextLock >>>>>>>> for the whole body of the method. Is the method implemented >>>>>>>> somewhere else except the AppContext class? >>>>>>>> >>>>>>>> Will it work from your point of view? (Probably, I didn't take >>>>>>>> into account all the details.) >>>>>>> All this tricky synchronizations was done on purpose, I believe >>>>>>> it was done for performance sake. >>>>>>> So I want to make as less changes as possible, it's better to >>>>>>> still miss couple cases then introduce a >>>>>>> new big issue in the last public update. Anyway, this fix plus >>>>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >>>>>>> should cover all cases, the only possible if EQ ctor will lead >>>>>>> to javaAwtAccess, but it doesn't. >>>>>> >>>>>> Ok, I'm fine with the fix (it looks harmless). However, I can't >>>>>> say I like it because it introduses new lock and breaks >>>>>> consistency (in all the other cases we get loggers directly)... >>>>>> >>>>>> I'd look for any better solution in an appropriate time slot. >>>>>> >>>>>> Reagards, >>>>>> Anton. >>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Anton. >>>>>>>> >>>>>>>> On 16.01.2015 17:18, mikhail cherkasov wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8065709 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.00/ >>>>>>>>> >>>>>>>>> AppContext creation is guarder by getAppContextLockand, but >>>>>>>>> during AppContext creation >>>>>>>>> we also call EventQueue initialization, during EQ >>>>>>>>> initialization logger initialization happens >>>>>>>>> it acquires "javaAwtAccess". if "javaAwtAccess" is acquired >>>>>>>>> by other it can lead to deadlock: >>>>>>>>> >>>>>>>>> >>>>>>>>> T1 T2 >>>>>>>>> start AppContext creation >>>>>>>>> acquire javaAwtAccess >>>>>>>>> acquire getAppContextLock >>>>>>>>> init EQ call getAppContext >>>>>>>>> init Logger waiting for getAppContextLock >>>>>>>>> waiting for javaAwtAccess >>>>>>>>> >>>>>>>>> >>>>>>>>> I applied the fix suggested in jbs comments by Petr. >>>>>>>>> I replaced eager logger initialization in EQ with lazy, so we >>>>>>>>> won't invoke Logger >>>>>>>>> during EQ initialization as result no deadlock. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Mikhail. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > > From alexandr.scherbatiy at oracle.com Thu Jan 22 14:49:42 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 22 Jan 2015 17:49:42 +0300 Subject: Review request for 8029339 Custom MultiResolution image support on HiDPI displays Message-ID: <54C10E06.6090407@oracle.com> 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 sergey.bylokhov at oracle.com Thu Jan 22 17:11:51 2015 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 22 Jan 2015 09:11:51 -0800 (PST) Subject: Review Request: 8069015 Re-examine Solaris/Linux java.desktop dependency on java.logging Message-ID: <59c6b893-bdc3-4361-93ec-032e2013dd75@default> Hello. Please review the fix for jdk 9. Additional information about the problem in https://bugs.openjdk.java.net/browse/JDK-6879044 "There are many classes using java.util.logging to log messages to enhance the diagnosability. java.util.logging is a good candidate to be separated out as a module. We need to eliminate the dependency of logging from certain core classes for JDK modularization." In the fix XEmbeddedFrame was changed to use Platformlogger and unused XAWTFormatter was removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8069015 Webrev can be found at: http://cr.openjdk.java.net/~serb/8069015/webrev.00 -- Best regards, Sergey. From anton.tarasov at oracle.com Fri Jan 23 07:24:23 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 23 Jan 2015 10:24:23 +0300 Subject: Review Request for 8065709: Deadlock in awt/logging apparently introduced by 8019623 In-Reply-To: <54C0F9D8.7010109@oracle.com> References: <54B91DB8.2070904@oracle.com> <54BD1BBC.3000400@oracle.com> <54BD2DB1.4040002@oracle.com> <54BD5D1F.3010402@oracle.com> <54BE6588.7010202@oracle.com> <54BE7D66.3030004@oracle.com> <54BE8D0D.8030209@oracle.com> <54C0D425.9000407@oracle.com> <54C0F9D8.7010109@oracle.com> Message-ID: <54C1F727.4070509@oracle.com> On 22.01.2015 16:23, Sergey Bylokhov wrote: > On 22.01.2015 13:42, mikhail cherkasov wrote: >> Hi Anton, Sergey, >> >> Anton advised today to implement eager initialization of EQ's logger instead of lazy >> initialization of EQ's logger. >> So now it will be initialized out of any AppContext's lock and I thinks it's definitely better >> solution because >> no ugly getLogger methods, less changes and now we know when and where logger will be initialized. >> >> Could you please review a new version: >> http://cr.openjdk.java.net/~mcherkas/8065709/webrev.03/ ? > No, no , no. I completely disagree on this solution. Besides that it not readable, it also > contains an unobvious restrictions on EventQueue class. As for me, this - Unsafe.getUnsafe().ensureClassInitialized(EventQueue.class) - is self-documenting, perfectly readable line of code. But Ok, let it be a matter of teste. Yes it puts some constraints on EQ, but they look quite natural (I hope no one will think of putting threaded code into the EQ's static block). > Lazy initialization is better, moreover we have such requests already: > https://bugs.openjdk.java.net/browse/JDK-6880089 Well, I'm ok with having the loggers statically or lazyly initialized, but consistent accross the classes. (By the way, the latter approach, at least as it's suggested in 6880089, will bring an extra function call into every log message, regardless of whether the log is enabled or not.) Regards, Anton. P.S. I don't insist on implementing the 3rd version of the fix. Leaving it at Mikhail's descretion. Thanks. >> >> Thanks, >> Mikhail. >> >> >> On 1/20/2015 8:14 PM, Sergey Bylokhov wrote: >>> On 20.01.2015 19:08, Anton V. Tarasov wrote: >>>> Hi Mikhail, >>>> >>>> Ok, you removed the new lock at least. Looks better now (no more comments from me). Thank you! >>> Personally I prefered to remove this logging, but this version looks fine also. >>>> >>>> Regards, >>>> Anton. >>>> >>>> On 20.01.2015 17:26, mikhail cherkasov wrote: >>>>> Hi Anton, >>>>> >>>>> please check new version: >>>>> http://cr.openjdk.java.net/~mcherkas/8065709/webrev.01/src/share/classes/java/awt/EventQueue.java.udiff.html >>>>> I applied changes advised by your in offline, the synchronization and second check for null >>>>> was removed. >>>>> PlatformLogger.getLogger is already synchronized and can be treated as sync block and second >>>>> check. >>>>> >>>>> Thanks, >>>>> Mikhail. >>>>> >>>>> On 1/19/2015 10:38 PM, Anton Tarasov wrote: >>>>>> >>>>>> On 19/01/15 19:15, mikhail cherkasov wrote: >>>>>>> On 1/19/2015 5:59 PM, Anton V. Tarasov wrote: >>>>>>>> Hi Mikhail, >>>>>>>> >>>>>>>> It seems the problem is not limited to EventQueue only. Even if you solve it for >>>>>>>> EventQueue, the EventQueue ctor may cause a chain of calls where some other AWT class is >>>>>>>> first accessed and initialized. What if it contains the same getLogger() call in a static >>>>>>>> block? >>>>>>> it can, but currently EventQueue doesn't do such things. >>>>>> >>>>>> I guess that it's nearly impossible to guarantee that AppContext ctor will never ever call >>>>>> anything containing uninitialized loggers. >>>>>> >>>>>>>> >>>>>>>> If you agree with this, then there should be a generic solution for the deadlock. >>>>>>>> >>>>>>>> What comes to my mind is the following. The deadlock happens due to a reverse lock taking >>>>>>>> order. Can we change it? >>>>>>>> >>>>>>>> In LogManager.getUserContext() it seems like the javaAwtAccess lock scope can be narrowed >>>>>>>> down. Namely, we can move the javaAwtAccess.getAppletContext() line out of it. >>>>>>> it's already done: >>>>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >>>>>> >>>>>> Oh, thanks, I didn't read all the discussion the first time. Well, I see there's another >>>>>> deadlock involving the sun.util.logging.PlatformLogger class... >>>>>> >>>>>>>> In which case the method implementation should be additionally synchronized. For instance, >>>>>>>> we can use the getAppContextLock for the whole body of the method. Is the method >>>>>>>> implemented somewhere else except the AppContext class? >>>>>>>> >>>>>>>> Will it work from your point of view? (Probably, I didn't take into account all the details.) >>>>>>> All this tricky synchronizations was done on purpose, I believe it was done for performance >>>>>>> sake. >>>>>>> So I want to make as less changes as possible, it's better to still miss couple cases then >>>>>>> introduce a >>>>>>> new big issue in the last public update. Anyway, this fix plus >>>>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a >>>>>>> should cover all cases, the only possible if EQ ctor will lead to javaAwtAccess, but it >>>>>>> doesn't. >>>>>> >>>>>> Ok, I'm fine with the fix (it looks harmless). However, I can't say I like it because it >>>>>> introduses new lock and breaks consistency (in all the other cases we get loggers directly)... >>>>>> >>>>>> I'd look for any better solution in an appropriate time slot. >>>>>> >>>>>> Reagards, >>>>>> Anton. >>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Anton. >>>>>>>> >>>>>>>> On 16.01.2015 17:18, mikhail cherkasov wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8065709 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.00/ >>>>>>>>> >>>>>>>>> AppContext creation is guarder by getAppContextLockand, but during AppContext creation >>>>>>>>> we also call EventQueue initialization, during EQ initialization logger initialization >>>>>>>>> happens >>>>>>>>> it acquires "javaAwtAccess". if "javaAwtAccess" is acquired by other it can lead to >>>>>>>>> deadlock: >>>>>>>>> >>>>>>>>> >>>>>>>>> T1 T2 >>>>>>>>> start AppContext creation >>>>>>>>> acquire javaAwtAccess >>>>>>>>> acquire getAppContextLock >>>>>>>>> init EQ call getAppContext >>>>>>>>> init Logger waiting for getAppContextLock >>>>>>>>> waiting for javaAwtAccess >>>>>>>>> >>>>>>>>> >>>>>>>>> I applied the fix suggested in jbs comments by Petr. >>>>>>>>> I replaced eager logger initialization in EQ with lazy, so we won't invoke Logger >>>>>>>>> during EQ initialization as result no deadlock. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Mikhail. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > > From anton.tarasov at oracle.com Fri Jan 23 08:45:18 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 23 Jan 2015 11:45:18 +0300 Subject: [9] Review Request: 7185221 [macosx] Regtest should not throw exception if a suitable display mode found In-Reply-To: References: Message-ID: <54C20A1E.2000005@oracle.com> Looks fine to me. Regards, Anton. On 21.01.2015 20:12, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > The test modify a supported list of DisplayModes and try to check that IllegalArgumentException will be thrown. But the problem occurs, when the test tries to change a supported DisplayMode which refresh rate is unknown. This happens because we match any refresh rate to a REFRESH_RATE_UNKNOWN. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7185221 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7185221/webrev.00/webrev > Diff: http://cr.openjdk.java.net/~serb/7185221/webrev.00/diff > From anton.tarasov at oracle.com Fri Jan 23 10:03:46 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 23 Jan 2015 13:03:46 +0300 Subject: Review Request: 8069015 Re-examine Solaris/Linux java.desktop dependency on java.logging In-Reply-To: <59c6b893-bdc3-4361-93ec-032e2013dd75@default> References: <59c6b893-bdc3-4361-93ec-032e2013dd75@default> Message-ID: <54C21C82.7000105@oracle.com> Looks fine ot me. Regards Anton. On 22.01.2015 20:11, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > Additional information about the problem in https://bugs.openjdk.java.net/browse/JDK-6879044 > "There are many classes using java.util.logging to log messages to enhance the diagnosability. java.util.logging is a good candidate to be separated out as a module. We need to eliminate the dependency of logging from certain core classes for JDK modularization." > > In the fix XEmbeddedFrame was changed to use Platformlogger and unused XAWTFormatter was removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8069015 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8069015/webrev.00 > From alexander.zvegintsev at oracle.com Fri Jan 23 10:53:15 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 23 Jan 2015 13:53:15 +0300 Subject: Review Request: 8069015 Re-examine Solaris/Linux java.desktop dependency on java.logging In-Reply-To: <59c6b893-bdc3-4361-93ec-032e2013dd75@default> References: <59c6b893-bdc3-4361-93ec-032e2013dd75@default> Message-ID: <54C2281B.4040803@oracle.com> Hello Sergey, the fix looks fine to me. Thanks, Alexander. On 01/22/2015 08:11 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > Additional information about the problem in https://bugs.openjdk.java.net/browse/JDK-6879044 > "There are many classes using java.util.logging to log messages to enhance the diagnosability. java.util.logging is a good candidate to be separated out as a module. We need to eliminate the dependency of logging from certain core classes for JDK modularization." > > In the fix XEmbeddedFrame was changed to use Platformlogger and unused XAWTFormatter was removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8069015 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8069015/webrev.00 > From dmitry.markov at oracle.com Fri Jan 23 12:00:23 2015 From: dmitry.markov at oracle.com (dmitry markov) Date: Fri, 23 Jan 2015 15:00:23 +0300 Subject: [9] Review request for 8064934: Incorrect Exception message from java.awt.Desktop.open() Message-ID: <54C237D7.5070204@oracle.com> Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8064934 webrev: http://cr.openjdk.java.net/~dmarkov/8064934/jdk9/webrev.00/ Problem description: in Java_sun_awt_windows_WDesktopPeer_ShellExecute() we pass to FormatMessage() the error code returned by ShellExecute() function. This is not correct, since error codes returned by ShellExecute() are not covered by System Error Codes. As a result we get incorrect error message from java.awt.Desktop.open(). Fix: we have to pass to FormatMessage() the error code returned by GetLastError() function instead of code returned by ShellExecute(). Thanks, Dmitry From alexander.zvegintsev at oracle.com Fri Jan 23 12:27:33 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 23 Jan 2015 15:27:33 +0300 Subject: [9] Review request for 8064934: Incorrect Exception message from java.awt.Desktop.open() In-Reply-To: <54C237D7.5070204@oracle.com> References: <54C237D7.5070204@oracle.com> Message-ID: <54C23E35.6030100@oracle.com> Hello Dmitry, the fix looks fine to me. Thanks, Alexander. On 01/23/2015 03:00 PM, dmitry markov wrote: > Hello, > > Could you review the fix for jdk9, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8064934 > webrev: http://cr.openjdk.java.net/~dmarkov/8064934/jdk9/webrev.00/ > > Problem description: in > Java_sun_awt_windows_WDesktopPeer_ShellExecute() we pass to > FormatMessage() the error code returned by ShellExecute() function. > This is not correct, since error codes returned by ShellExecute() are > not covered by System Error Codes. As a result we get incorrect error > message from java.awt.Desktop.open(). > Fix: we have to pass to FormatMessage() the error code returned by > GetLastError() function instead of code returned by ShellExecute(). > > Thanks, > Dmitry From Sergey.Bylokhov at oracle.com Fri Jan 23 13:23:45 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 23 Jan 2015 16:23:45 +0300 Subject: [9] Review request for 8064934: Incorrect Exception message from java.awt.Desktop.open() In-Reply-To: <54C23E35.6030100@oracle.com> References: <54C237D7.5070204@oracle.com> <54C23E35.6030100@oracle.com> Message-ID: <54C24B61.7050308@oracle.com> +1 On 23.01.2015 15:27, Alexander Zvegintsev wrote: > Hello Dmitry, > > the fix looks fine to me. > > Thanks, > > Alexander. > > On 01/23/2015 03:00 PM, dmitry markov wrote: >> Hello, >> >> Could you review the fix for jdk9, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8064934 >> webrev: http://cr.openjdk.java.net/~dmarkov/8064934/jdk9/webrev.00/ >> >> Problem description: in >> Java_sun_awt_windows_WDesktopPeer_ShellExecute() we pass to >> FormatMessage() the error code returned by ShellExecute() function. >> This is not correct, since error codes returned by ShellExecute() are >> not covered by System Error Codes. As a result we get incorrect error >> message from java.awt.Desktop.open(). >> Fix: we have to pass to FormatMessage() the error code returned by >> GetLastError() function instead of code returned by ShellExecute(). >> >> Thanks, >> Dmitry > -- Best regards, Sergey. From Roger.Riggs at Oracle.com Fri Jan 23 14:48:07 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 23 Jan 2015 09:48:07 -0500 Subject: jdk/test/java/awt/Color vs color directory name Message-ID: <54C25F27.4090208@Oracle.com> Hi, Is it intentional that both of these directories exist? jdk/test/java/awt/color jdk/test/java/awt/Color On Windows without case sensitive file names, the directory contents are merged. its been that way since 2010 so it must not be an issue but looks odd. Thanks, Roger From alexander.zvegintsev at oracle.com Fri Jan 23 16:44:57 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 23 Jan 2015 19:44:57 +0300 Subject: [9] Review request for 8071483: Possible case-folding collision for color/Color subdirectories of jdk/test/java/awt/ (was: Re: jdk/test/java/awt/Color vs color directory name) In-Reply-To: <54C25F27.4090208@Oracle.com> References: <54C25F27.4090208@Oracle.com> Message-ID: <54C27A89.3030009@oracle.com> Hello Roger, I think it is unintentional. jdk/test/java/awt/color tests were added a few months ago (JDK-8039271 [1],JDK-8058969[2]): I've created an issue JDK-8071483 [3]. I also want convert this thread to a review request, here is the fix: http://cr.openjdk.java.net/~azvegint/jdk/9/8071483/00/ (just moved tests from color to Color) [1] https://bugs.openjdk.java.net/browse/JDK-8039271 [2] https://bugs.openjdk.java.net/browse/JDK-8058969 [3] https://bugs.openjdk.java.net/browse/JDK-8071483 Thanks, Alexander. On 01/23/2015 05:48 PM, Roger Riggs wrote: > Hi, > > Is it intentional that both of these directories exist? > jdk/test/java/awt/color > jdk/test/java/awt/Color > > On Windows without case sensitive file names, the directory contents > are merged. > its been that way since 2010 so it must not be an issue but looks odd. > > Thanks, Roger > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Fri Jan 23 16:57:10 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 23 Jan 2015 11:57:10 -0500 Subject: [9] Review request for 8071483: Possible case-folding collision for color/Color subdirectories of jdk/test/java/awt/ In-Reply-To: <54C27A89.3030009@oracle.com> References: <54C25F27.4090208@Oracle.com> <54C27A89.3030009@oracle.com> Message-ID: <54C27D66.1000508@Oracle.com> Hi Alexander, ok, thanks for fixing it. It looks fine. Reviewed. Roger On 1/23/2015 11:44 AM, Alexander Zvegintsev wrote: > Hello Roger, > > I think it is unintentional. jdk/test/java/awt/color tests were added > a few months ago (JDK-8039271 [1],JDK-8058969[2]): > > I've created an issue JDK-8071483 [3]. > > I also want convert this thread to a review request, here is the fix: > http://cr.openjdk.java.net/~azvegint/jdk/9/8071483/00/ (just moved > tests from color to Color) > > [1] https://bugs.openjdk.java.net/browse/JDK-8039271 > [2] https://bugs.openjdk.java.net/browse/JDK-8058969 > [3] https://bugs.openjdk.java.net/browse/JDK-8071483 > Thanks, > > Alexander. > On 01/23/2015 05:48 PM, Roger Riggs wrote: >> Hi, >> >> Is it intentional that both of these directories exist? >> jdk/test/java/awt/color >> jdk/test/java/awt/Color >> >> On Windows without case sensitive file names, the directory contents >> are merged. >> its been that way since 2010 so it must not be an issue but looks odd. >> >> Thanks, Roger >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jan 23 17:04:50 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 23 Jan 2015 20:04:50 +0300 Subject: [9] Review request for 8071483: Possible case-folding collision for color/Color subdirectories of jdk/test/java/awt/ In-Reply-To: <54C27A89.3030009@oracle.com> References: <54C25F27.4090208@Oracle.com> <54C27A89.3030009@oracle.com> Message-ID: <54C27F32.3090601@oracle.com> Hi, Alexander. Thanks for fixing this. Looks fine. On 23.01.2015 19:44, Alexander Zvegintsev wrote: > Hello Roger, > > I think it is unintentional. jdk/test/java/awt/color tests were added > a few months ago (JDK-8039271 [1],JDK-8058969[2]): > > I've created an issue JDK-8071483 [3]. > > I also want convert this thread to a review request, here is the fix: > http://cr.openjdk.java.net/~azvegint/jdk/9/8071483/00/ (just moved > tests from color to Color) > > [1] https://bugs.openjdk.java.net/browse/JDK-8039271 > [2] https://bugs.openjdk.java.net/browse/JDK-8058969 > [3] https://bugs.openjdk.java.net/browse/JDK-8071483 > Thanks, > > Alexander. > On 01/23/2015 05:48 PM, Roger Riggs wrote: >> Hi, >> >> Is it intentional that both of these directories exist? >> jdk/test/java/awt/color >> jdk/test/java/awt/Color >> >> On Windows without case sensitive file names, the directory contents >> are merged. >> its been that way since 2010 so it must not be an issue but looks odd. >> >> Thanks, Roger >> >> >> > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pooja.chopra at oracle.com Tue Jan 27 10:37:39 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Tue, 27 Jan 2015 16:07:39 +0530 Subject: [9] Review Request: JDK-8071532 Fix for java/awt/print/PrinterJob/ImagePrinting/NullClipARGB.java fails with PrinterException: No print service found Message-ID: <54C76A73.7060706@oracle.com> |Hello, | || |Please review a fix ||for| |the issue: | || |8071532| |[TEST_BUG] ||java/awt/print/PrinterJob/ImagePrinting/NullClipARGB.java fails with PrinterException: No print service found ||| || | Test bug fix. | || |https://bugs.openjdk.java.net/browse/JDK-8071532 ||| || |The webrev is:||http://cr.openjdk.java.net/~kshefov/8071532/webrev.01 ||| || |Thanks | |Pooja| -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jan 29 09:17:36 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 29 Jan 2015 12:17:36 +0300 Subject: [9] Review Request: JDK-8071532 Fix for java/awt/print/PrinterJob/ImagePrinting/NullClipARGB.java fails with PrinterException: No print service found In-Reply-To: <54C76A73.7060706@oracle.com> References: <54C76A73.7060706@oracle.com> Message-ID: <54C9FAB0.5060705@oracle.com> The fix looks good to me. Thanks, Alexandr. On 1/27/2015 1:37 PM, pooja chopra wrote: > |Hello, | > || > |Please review a fix ||for| |the issue: | > || > |8071532| |[TEST_BUG] > ||java/awt/print/PrinterJob/ImagePrinting/NullClipARGB.java fails with > PrinterException: No print service found > ||| > || > | > Test bug fix. > | > || > |https://bugs.openjdk.java.net/browse/JDK-8071532 > > ||| > || > |The webrev is:||http://cr.openjdk.java.net/~kshefov/8071532/webrev.01 > > ||| > || > |Thanks | > |Pooja| From srinivasan.raghavan at oracle.com Fri Jan 30 10:38:36 2015 From: srinivasan.raghavan at oracle.com (Srinivasan Raghavan) Date: Fri, 30 Jan 2015 02:38:36 -0800 (PST) Subject: Reg : Open JDK Author status Message-ID: <0d298c59-ab50-4422-835a-b1b90bfa63f5@default> Hello This is to request for an OpenJDK login and Author status . The commits and the bugs fixed in JDK 9 regression test suite are listed below. Kindly oblige this request Email : srinivasan.raghavan at oracle.com Srinivasan Raghavan: http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=srinivasan.raghavan%40oracle.com 1. http://hg.openjdk.java.net/jdk9/client/jdk/rev/18c0f5323646 2. http://hg.openjdk.java.net/jdk9/client/jdk/rev/b66ccf78284a Regards Srinivasan Raghavan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Fri Jan 30 10:44:24 2015 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Fri, 30 Jan 2015 10:44:24 +0000 Subject: Reg : Open JDK Author status In-Reply-To: <0d298c59-ab50-4422-835a-b1b90bfa63f5@default> References: <0d298c59-ab50-4422-835a-b1b90bfa63f5@default> Message-ID: <54CB6088.6070103@oracle.com> Hi Srinivasan. You need to follow this process for author request : http://openjdk.java.net/projects/#project-author Since these are jdk9 contributions, email Mark Reinhold who is the Project Lead. regards, Sean. On 30/01/2015 10:38, Srinivasan Raghavan wrote: > > Hello > > This is to request for an OpenJDK login and Author status . The > commits and the bugs fixed in JDK 9 regression test suite are listed > below. Kindly oblige this request > > Email : srinivasan.raghavan at oracle.com > > Srinivasan Raghavan: > http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=srinivasan.raghavan%40oracle.com > > 1. http://hg.openjdk.java.net/jdk9/client/jdk/rev/18c0f5323646 > > 2. http://hg.openjdk.java.net/jdk9/client/jdk/rev/b66ccf78284a > > Regards > > Srinivasan Raghavan > -------------- next part -------------- An HTML attachment was scrubbed... URL: