From alexander.zuev at oracle.com Mon Jul 2 05:00:21 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 02 Jul 2012 16:00:21 +0400 Subject: [7u6] Please review my fix for 7178079: REGRESSION: Some AWT Drag-n-Drop tests fail since JDK 7u6 b13 Message-ID: <4FF18D55.8070106@oracle.com> Hello, please review my fix for 7178079: REGRESSION: Some AWT Drag-n-Drop tests fail since JDK 7u6 b13 CR description can be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7178079 Webrev with the proposed change can be seen here: http://cr.openjdk.java.net/~kizune/7178079/webrev.00 Looks like there are couple of regression tests affected by my fix for 7171163 - this change will make that part of the fix non-crossplatform and affecting mac os only. With best regards, Alex From anthony.petrov at oracle.com Mon Jul 2 06:28:45 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 02 Jul 2012 17:28:45 +0400 Subject: [7u6] Please review my fix for 7178079: REGRESSION: Some AWT Drag-n-Drop tests fail since JDK 7u6 b13 In-Reply-To: <4FF18D55.8070106@oracle.com> References: <4FF18D55.8070106@oracle.com> Message-ID: <4FF1A20D.1030206@oracle.com> Yes, I recall I worried about this DISPATCH_SYNC when I reviewed your original fix. The code looks fine to me. -- best regards, Anthony On 07/02/12 16:00, Alexander Zuev wrote: > Hello, > > please review my fix for 7178079: REGRESSION: Some AWT Drag-n-Drop tests > fail since JDK 7u6 b13 > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7178079 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7178079/webrev.00 > > Looks like there are couple of regression tests affected by my fix for > 7171163 - this change will make that part of the fix non-crossplatform > and affecting mac os only. > > With best regards, > Alex From Sergey.Bylokhov at oracle.com Mon Jul 2 06:46:36 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 02 Jul 2012 17:46:36 +0400 Subject: [8] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar Message-ID: <4FF1A63C.3050508@oracle.com> Hi Everyone, Please review the fix. 1 When the property "apple.awt.brushMetalLook" is set we draw our panels and toolbars with composite=SRc and alpha=0. 2 Changes in JViewport are needed, because copyArea does not handle correctly content with alpha!=1.0. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124513/webrev.00/ Also note that this CR depends from CR 7124244. -- Best regards, Sergey. From jason.uh at oracle.com Mon Jul 2 07:18:25 2012 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 02 Jul 2012 07:18:25 -0700 Subject: [8] Review request for 7162111 change tests run in headless mode [macosx] In-Reply-To: <4FE86576.8020407@oracle.com> References: <4FE5154C.2090703@oracle.com> <4FE57019.9090905@oracle.com> <4FE86576.8020407@oracle.com> Message-ID: <4FF1ADB1.9020508@oracle.com> Anthony and Alan, Thanks for your comments. I've reverted the changes to CommonSetup.sh so that XToolkit is no longer forced. Tests still pass. Please see the new webrev: http://cr.openjdk.java.net/~juh/7162111/webrev.01/ Thanks, Jason On 06/25/2012 06:19 AM, Anthony Petrov wrote: > Hi Alan and Jason, > > On 06/23/12 11:28, Alan Bateman wrote: >> On 23/06/2012 02:01, Jason Uh wrote: >>> This fix was for regression tests failing on Mac OS X on remotely >>> executed environments. The changed tests now run in headless mode and >>> have been taken off the Problem List. >>> >>> Webrev: http://cr.openjdk.java.net/~juh/7162111/webrev.00/ >>> The CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162111 >>> >>> Note that test/demo/jvmti/mtrace/TraceJFrame.java was not fixed here >>> because headless mode is not supported for JFrame. A separate CR will >>> be created for this. >>> >> It's good to see these tests changed to run headless and will make the >> test execution much more reliable. Aside from the mtrace demo there are >> a couple of other tests that periodically hang initializing AWT, at >> least when running via ssh and then depending on whether someone is >> logged in and other configuration settings. Some of the shell tests for >> serialization come to mind (BTW: no problem doing that via a separate >> bug, just mentioning that there are other tests that are problems too). >> >> One question, and this may be a question for Artem or others, is that in >> CommonSetup.sh you set AWT_TOOLKIT=XToolkit. Is that right? > > I don't think we need to force XToolkit on the Mac. We don't quite > support it on that platform actually. The normal headless CToolkit > should work just fine. Could you please revert the changes to > CommonSetup.sh and verify if the tests pass? > > -- > best regards, > Anthony From anthony.petrov at oracle.com Mon Jul 2 07:33:52 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 02 Jul 2012 18:33:52 +0400 Subject: [8] Review request for 7162111 change tests run in headless mode [macosx] In-Reply-To: <4FF1ADB1.9020508@oracle.com> References: <4FE5154C.2090703@oracle.com> <4FE57019.9090905@oracle.com> <4FE86576.8020407@oracle.com> <4FF1ADB1.9020508@oracle.com> Message-ID: <4FF1B150.80406@oracle.com> Looks fine to me. -- best regards, Anthony On 07/02/12 18:18, Jason Uh wrote: > Anthony and Alan, > > Thanks for your comments. I've reverted the changes to CommonSetup.sh so > that XToolkit is no longer forced. Tests still pass. > > Please see the new webrev: > http://cr.openjdk.java.net/~juh/7162111/webrev.01/ > > Thanks, > Jason > > On 06/25/2012 06:19 AM, Anthony Petrov wrote: >> Hi Alan and Jason, >> >> On 06/23/12 11:28, Alan Bateman wrote: >>> On 23/06/2012 02:01, Jason Uh wrote: >>>> This fix was for regression tests failing on Mac OS X on remotely >>>> executed environments. The changed tests now run in headless mode and >>>> have been taken off the Problem List. >>>> >>>> Webrev: http://cr.openjdk.java.net/~juh/7162111/webrev.00/ >>>> The CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162111 >>>> >>>> Note that test/demo/jvmti/mtrace/TraceJFrame.java was not fixed here >>>> because headless mode is not supported for JFrame. A separate CR will >>>> be created for this. >>>> >>> It's good to see these tests changed to run headless and will make the >>> test execution much more reliable. Aside from the mtrace demo there are >>> a couple of other tests that periodically hang initializing AWT, at >>> least when running via ssh and then depending on whether someone is >>> logged in and other configuration settings. Some of the shell tests for >>> serialization come to mind (BTW: no problem doing that via a separate >>> bug, just mentioning that there are other tests that are problems too). >>> >>> One question, and this may be a question for Artem or others, is that in >>> CommonSetup.sh you set AWT_TOOLKIT=XToolkit. Is that right? >> >> I don't think we need to force XToolkit on the Mac. We don't quite >> support it on that platform actually. The normal headless CToolkit >> should work just fine. Could you please revert the changes to >> CommonSetup.sh and verify if the tests pass? >> >> -- >> best regards, >> Anthony From artem.ananiev at oracle.com Mon Jul 2 11:11:27 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 02 Jul 2012 22:11:27 +0400 Subject: [8] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar In-Reply-To: <4FF1A63C.3050508@oracle.com> References: <4FF1A63C.3050508@oracle.com> Message-ID: <4FF1E44F.2020705@oracle.com> Hi, Sergey, a few comments: 1. AquaUtils: "textured".equals() should be replaced with "textured".equalsIgnoreCase() 2. CPlatformWindow: "!isOpaque() && !peer.isTextured()" - should it be replaced with "!isOpaque() || peer.isTextured()"? Otherwise LWWindowPeer and CPlatformWindow will get out of sync: textured LWP will be "isTranslucent() == true", while textured CPW will not be filled with clearColor in CPW.setOpaque(false). Thanks, Artem On 7/2/2012 5:46 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > 1 When the property "apple.awt.brushMetalLook" is set we draw our panels > and toolbars with composite=SRc and alpha=0. > 2 Changes in JViewport are needed, because copyArea does not handle > correctly content with alpha!=1.0. > > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124513/webrev.00/ > > Also note that this CR depends from CR 7124244. > > -- > Best regards, Sergey. > From artem.ananiev at oracle.com Mon Jul 2 12:03:20 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 02 Jul 2012 23:03:20 +0400 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FED9EC8.3080508@oracle.com> References: <4FCCD91B.30503@oracle.com> <4FD895F1.3040605@oracle.com> <4FE8407C.7060103@oracle.com> <4FE880D0.3080108@oracle.com> <4FEC7ABC.8070302@oracle.com> <4FED9EC8.3080508@oracle.com> Message-ID: <4FF1F078.2090409@oracle.com> On 6/29/2012 4:25 PM, Anthony Petrov wrote: > Hi Sergey, > > The fix looks good. +1. > Btw, if you set a shape to a frame, will the Frame.printAll() use the > shape correctly? E.g. an ellipse-shaped window must be printed as an > ellipse. The parts laying outside of the shape shouldn't be printed. It's a separate issue. Sergey, could you file a new bug, please? Thanks, Artem > -- > best regards, > Anthony > > On 6/28/2012 7:39 PM, Sergey Bylokhov wrote: >> Hi Artem, Anthony. >> Updated webrev. >> http://cr.openjdk.java.net/~serb/7124244/webrev.04/ >> - CPlatformEmbeddedFrame now use correct backbuffer. >> - For simplification, creation of the backbuffer was reverted back. >> >> 25.06.2012 19:16, Artem Ananiev wrote: >>> Hi, Sergey, >>> >>> a few minor comments: >>> >>> 1. CPlatformWindow.java: invalidateShadow() in native is ready to be >>> called on any thread, so what's the reason behind invokeLater() here? >>> >>> 2. RepaintManager.java: the new field should better be named >>> "volatileBufferType". >>> >>> 3. LWComponentPeer.applyShape() is a peer method, which accepts >>> user-supplied object (right now it's constructed from Shape in AWT >>> internal code, but nothing prevents users from calling this method >>> directly), so it should be stored as a copy, not as a reference. >>> >>> Thanks, >>> >>> Artem >>> >>> On 6/25/2012 2:42 PM, Sergey Bylokhov wrote: >>>> Hi, Artem, Anthony. >>>> New version of the fix: >>>> http://cr.openjdk.java.net/~serb/7124244/webrev.01 >>>> >>>> 13.06.2012 06:30, Artem Ananiev wrote: >>>>> Hi, Sergey, >>>>> >>>>> a few minor comments: >>>>> >>>>> 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in >>>>> CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are >>>>> corresponding checks just above. >>>> done. >>>>> >>>>> 2. invalidateShadow() is not used in sun.lwawt, so it can be just a >>>>> method in CPlatformWindow. BTW, do you have any ideas, why CGLayer >>>>> holds a reference to LWWindowPeer, not to CPlatformWindow? >>>> done. >>>>> >>>>> 3. As we don't expect isSwingBackbufferTranslucencySupported() to >>>>> return different values, it would be fine to call it only once to >>>>> avoid possible perf regressions. >>>> done. >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: >>>>>> Hi Everyone, >>>>>> Please review the fix. >>>>>> >>>>>> Shaped window was implemented as a translucent window with >>>>>> constrained >>>>>> graphics. Now translucent window doesn't use separate >>>>>> BufferedImage as a >>>>>> back buffer. Also alpha value for the swing back buffer was >>>>>> enabled(Shared code changed). >>>>>> Note that shaped windows are affected by this bugs: >>>>>> http://monaco.us.oracle.com/detail.jsf?cr=7124236 >>>>>> - Shadows disappear. >>>>>> - Transparent areas aren't transparent to mouse clicks. >>>>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 >>>>>> - Opacity does not work for non opaque windows. >>>>>> >>>>>> Any suggestions are welcome. >>>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 >>>>>> Webrev can be found at: >>>>>> http://cr.openjdk.java.net/~serb/7124244/webrev.00 >>>>>> >>>> >>>> >> >> From Sergey.Bylokhov at oracle.com Mon Jul 2 12:46:37 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 02 Jul 2012 23:46:37 +0400 Subject: [8] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar In-Reply-To: <4FF1E44F.2020705@oracle.com> References: <4FF1A63C.3050508@oracle.com> <4FF1E44F.2020705@oracle.com> Message-ID: <4FF1FA9D.10806@oracle.com> Hi, Artem. Thanks for review. See comments inline: 02.07.2012 22:11, Artem Ananiev wrote: > Hi, Sergey, > > a few comments: > > 1. AquaUtils: "textured".equals() should be replaced with > "textured".equalsIgnoreCase() Well I can change it, but the same logic was used in CPlatformWindow for "textured","unified","hud". I think it would be good to leave it as is or change them all. > > 2. CPlatformWindow: "!isOpaque() && !peer.isTextured()" - should it be > replaced with "!isOpaque() || peer.isTextured()"? Otherwise > LWWindowPeer and CPlatformWindow will get out of sync: textured LWP > will be "isTranslucent() == true", while textured CPW will not be > filled with clearColor in CPW.setOpaque(false). Yes. We set background color to clearColor for the non opaque window, because otherwise nswindow background is visible through opengl content. But in case of textured window this is exactly what we expect. > > Thanks, > > Artem > > On 7/2/2012 5:46 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> Please review the fix. >> 1 When the property "apple.awt.brushMetalLook" is set we draw our panels >> and toolbars with composite=SRc and alpha=0. >> 2 Changes in JViewport are needed, because copyArea does not handle >> correctly content with alpha!=1.0. >> >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7124513/webrev.00/ >> >> Also note that this CR depends from CR 7124244. >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From dkocher at sudo.ch Mon Jul 2 13:13:34 2012 From: dkocher at sudo.ch (David Kocher) Date: Mon, 2 Jul 2012 22:13:34 +0200 Subject: Maintenance of issues In-Reply-To: References: Message-ID: <06E7EED5-B02A-4061-BDF3-8DB68ECD7ECD@sudo.ch> Asked differently then, is it even worth posting comments to JIRA? -- David On 25.06.2012, at 09:20, David Kocher wrote: > Contrary to the activity on this list and references to bugs.sun.com, I see no significant activity in the bug tracker [1] I follow. Do the issues listed there get updated and is this even relevant anymore or has everything moved to bugs.sun.com? > > -- David > >> http://java.net/jira/browse/MACOSX_PORT > From anthony.petrov at oracle.com Mon Jul 2 13:31:41 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 03 Jul 2012 00:31:41 +0400 Subject: Maintenance of issues In-Reply-To: <06E7EED5-B02A-4061-BDF3-8DB68ECD7ECD@sudo.ch> References: <06E7EED5-B02A-4061-BDF3-8DB68ECD7ECD@sudo.ch> Message-ID: <4FF2052D.6040403@oracle.com> We don't use this JIRA project to track Mac port issues anymore. Please post comments/file bugs on http://bugs.sun.com. -- best regards, Anthony On 7/3/2012 12:13 AM, David Kocher wrote: > Asked differently then, is it even worth posting comments to JIRA? > > -- David > > On 25.06.2012, at 09:20, David Kocher wrote: > >> Contrary to the activity on this list and references to bugs.sun.com, I see no significant activity in the bug tracker [1] I follow. Do the issues listed there get updated and is this even relevant anymore or has everything moved to bugs.sun.com? >> >> -- David >> >>> http://java.net/jira/browse/MACOSX_PORT > From philip.race at oracle.com Mon Jul 2 14:02:26 2012 From: philip.race at oracle.com (Phil Race) Date: Mon, 02 Jul 2012 14:02:26 -0700 Subject: Maintenance of issues In-Reply-To: <4FF2052D.6040403@oracle.com> References: <06E7EED5-B02A-4061-BDF3-8DB68ECD7ECD@sudo.ch> <4FF2052D.6040403@oracle.com> Message-ID: <4FF20C62.7000904@oracle.com> Adding to this .. I believe that at the time we transitioned all unresolved bugs were shadowed at bugs.sun.com, and that many of those are also since fixed .. Who can make changes to 1) edit that main page, but we should post a comment there that this is now "historic" data, for reference only, 2) Prevent creation of new bugs in that JIRA instance ? One issue with posting comments on bugs at bugs.sun.com is that the comments do not become part of the bug database, and aren't (any more) notified via email to the RE, so they are sadly mostly wasted. Only people who navigate to that bug page on bugs.sun.com will ever see them. -phil. On 7/2/2012 1:31 PM, Anthony Petrov wrote: > We don't use this JIRA project to track Mac port issues anymore. > Please post comments/file bugs on http://bugs.sun.com. > > -- > best regards, > Anthony > > On 7/3/2012 12:13 AM, David Kocher wrote: >> Asked differently then, is it even worth posting comments to JIRA? >> >> -- David >> >> On 25.06.2012, at 09:20, David Kocher wrote: >> >>> Contrary to the activity on this list and references to >>> bugs.sun.com, I see no significant activity in the bug tracker [1] I >>> follow. Do the issues listed there get updated and is this even >>> relevant anymore or has everything moved to bugs.sun.com? >>> >>> -- David >>> >>>> http://java.net/jira/browse/MACOSX_PORT >> From Sergey.Bylokhov at oracle.com Tue Jul 3 03:22:00 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 03 Jul 2012 14:22:00 +0400 Subject: [7u6] Please review my fix for 7178079: REGRESSION: Some AWT Drag-n-Drop tests fail since JDK 7u6 b13 In-Reply-To: <4FF18D55.8070106@oracle.com> References: <4FF18D55.8070106@oracle.com> Message-ID: <4FF2C7C8.60405@oracle.com> Hi, Alexander. Fix looks good. 02.07.2012 16:00, Alexander Zuev wrote: > Hello, > > please review my fix for 7178079: REGRESSION: Some AWT Drag-n-Drop > tests fail since JDK 7u6 b13 > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7178079 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7178079/webrev.00 > > Looks like there are couple of regression tests affected by my fix > for 7171163 - this change will make that part of the fix > non-crossplatform and affecting mac os only. > > With best regards, > Alex -- Best regards, Sergey. From jost0x2c at gmail.com Tue Jul 3 06:50:51 2012 From: jost0x2c at gmail.com (--- ---) Date: Tue, 3 Jul 2012 15:50:51 +0200 Subject: jawt_md.h deprecated? Message-ID: Hi, it appears the mac specific version of jawt_md.h (NSView, CALayer) is not distributed with the latest (1.7.0_06-ea-b16) build from oracle, it only contains the one with the X11-dependent parts. The only option I see for using CALayer-based embedding is including the jawt_md.h that is distributed with JavaVM.framework from apple but this is deprecated. Does anyone know if there a supported way of using CALayer-based embedding or will it be removed from a future version and is no longer supported? -jost From swingler at apple.com Tue Jul 3 08:23:20 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 03 Jul 2012 08:23:20 -0700 Subject: jawt_md.h deprecated? In-Reply-To: References: Message-ID: On Jul 3, 2012, at 6:50 AM, --- --- wrote: > Hi, > it appears the mac specific version of jawt_md.h (NSView, CALayer) is not > distributed with the latest (1.7.0_06-ea-b16) build from oracle, it only > contains the one with the X11-dependent parts. The only option I see for > using CALayer-based embedding is including the jawt_md.h that is > distributed with JavaVM.framework from apple but this is deprecated. Does > anyone know if there a supported way of using CALayer-based embedding or > will it be removed from a future version and is no longer supported? > > -jost The jawt_md.h in OpenJDK needs to contain only the CALayer interface, since the OpenJDK OS X AWT does not support either the X11 or the NSView interface. Regards, Mike Swingler Apple Inc. From jost0x2c at gmail.com Tue Jul 3 09:02:35 2012 From: jost0x2c at gmail.com (jost) Date: Tue, 3 Jul 2012 18:02:35 +0200 Subject: jawt_md.h deprecated? Message-ID: On Tue, Jul 3, 2012 at 5:23 PM, Mike Swingler wrote: > On Jul 3, 2012, at 6:50 AM, --- --- wrote: > > > Hi, > > it appears the mac specific version of jawt_md.h (NSView, CALayer) is not > > distributed with the latest (1.7.0_06-ea-b16) build from oracle, it only > > contains the one with the X11-dependent parts. The only option I see for > > using CALayer-based embedding is including the jawt_md.h that is > > distributed with JavaVM.framework from apple but this is deprecated. Does > > anyone know if there a supported way of using CALayer-based embedding or > > will it be removed from a future version and is no longer supported? > > > > -jost > > The jawt_md.h in OpenJDK needs to contain only the CALayer interface, > since the OpenJDK OS X AWT does not support either the X11 or the NSView > interface. > I tried with CALayer linked against the jdk and it seems to work, so I guess its safe to assume CALayer support is (and will continue?) to be there and jawt_md.h just needs to be ported from JavaVM.framework to openjdk, removing the NSView parts? Should I file a bug report about that? From scott.kovatch at oracle.com Tue Jul 3 11:42:33 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 3 Jul 2012 11:42:33 -0700 Subject: jawt_md.h deprecated? In-Reply-To: References: Message-ID: <2483FFB3-52A7-4E13-B646-359D6565CBE3@oracle.com> On Jul 3, 2012, at 9:02 AM, jost wrote: > On Tue, Jul 3, 2012 at 5:23 PM, Mike Swingler wrote: > >> On Jul 3, 2012, at 6:50 AM, --- --- wrote: >> >>> Hi, >>> it appears the mac specific version of jawt_md.h (NSView, CALayer) is not >>> distributed with the latest (1.7.0_06-ea-b16) build from oracle, it only >>> contains the one with the X11-dependent parts. The only option I see for >>> using CALayer-based embedding is including the jawt_md.h that is >>> distributed with JavaVM.framework from apple but this is deprecated. Does >>> anyone know if there a supported way of using CALayer-based embedding or >>> will it be removed from a future version and is no longer supported? >>> >>> -jost >> >> The jawt_md.h in OpenJDK needs to contain only the CALayer interface, >> since the OpenJDK OS X AWT does not support either the X11 or the NSView >> interface. >> > > I tried with CALayer linked against the jdk and it seems to work, so I > guess its safe to assume CALayer support is (and will continue?) to be > there and jawt_md.h just needs to be ported from JavaVM.framework to > openjdk, removing the NSView parts? Should I file a bug report about that? Yes, please. It sounds like the jawt_md.h we are shipping now is just out of date. I don't see us changing the CALayer support anytime soon. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From Sergey.Bylokhov at oracle.com Wed Jul 4 01:32:46 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 04 Jul 2012 12:32:46 +0400 Subject: [8] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar In-Reply-To: <4FF1A63C.3050508@oracle.com> References: <4FF1A63C.3050508@oracle.com> Message-ID: <4FF3FFAE.5050209@oracle.com> Hi Everyone. Does anybody has a chance to review the fix? One more reviewer needed. 02.07.2012 17:46, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > 1 When the property "apple.awt.brushMetalLook" is set we draw our > panels and toolbars with composite=SRc and alpha=0. > 2 Changes in JViewport are needed, because copyArea does not handle > correctly content with alpha!=1.0. > > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124513/webrev.00/ > > Also note that this CR depends from CR 7124244. > -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Jul 4 02:20:30 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 04 Jul 2012 13:20:30 +0400 Subject: [8] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar In-Reply-To: <4FF1A63C.3050508@oracle.com> References: <4FF1A63C.3050508@oracle.com> Message-ID: <4FF40ADE.7010104@oracle.com> Hi Sergey, src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java > // If the target is a dialog, popup or tooltip we want it to ignore the brushed metal look. > if (isPopup) { > - styleBits = SET(styleBits, TEXTURED, true); > + styleBits = SET(styleBits, TEXTURED, false); Given the change, does the comment above if() still apply to this code? Also, this comment seems to imply we want to ignore the user's TEXTURED bit for these kinds of windows. What is the reason you change this logic? Will this be a regression for some use cases? src/macosx/classes/sun/lwawt/LWWindowPeer.java > 455 public final boolean isTranslucent() { > 456 synchronized (getStateLock()) { > 457 return !isOpaque || isShaped()|| isTextured(); It is unclear why textured windows must be considered translucent. Could you add a comment explaining that, or yet better, not do this change at all? After all, we can always insert explicit checks for isTextured() in places where it is really necessary. Otherwise I suggest to rename the isTranslucent() to something else, because textured doesn't really mean translucent. I'm not an expert in Swing/laf code, so I didn't review those parts. -- best regards, Anthony On 7/2/2012 5:46 PM, Sergey Bylokhov wrote: > > Hi Everyone, > Please review the fix. > 1 When the property "apple.awt.brushMetalLook" is set we draw our panels > and toolbars with composite=SRc and alpha=0. > 2 Changes in JViewport are needed, because copyArea does not handle > correctly content with alpha!=1.0. > > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124513/webrev.00/ > > Also note that this CR depends from CR 7124244. > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Wed Jul 4 03:07:30 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 04 Jul 2012 14:07:30 +0400 Subject: [8] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar In-Reply-To: <4FF40ADE.7010104@oracle.com> References: <4FF1A63C.3050508@oracle.com> <4FF40ADE.7010104@oracle.com> Message-ID: <4FF415E2.6080605@oracle.com> Hi,Anthony. Thanks for review. See my comments inline. 04.07.2012 13:20, Anthony Petrov wrote: > Hi Sergey, > > src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java >> // If the target is a dialog, popup or tooltip we want it to >> ignore the brushed metal look. >> if (isPopup) { >> - styleBits = SET(styleBits, TEXTURED, true); >> + styleBits = SET(styleBits, TEXTURED, false); > > Given the change, does the comment above if() still apply to this code? Well I just change the code according the comments. This code means that we ignore this property if it was set. styleBits = SET(styleBits, TEXTURED, false); > Also, this comment seems to imply we want to ignore the user's > TEXTURED bit for these kinds of windows. What is the reason you change > this logic? Will this be a regression for some use cases? > > > src/macosx/classes/sun/lwawt/LWWindowPeer.java >> 455 public final boolean isTranslucent() { >> 456 synchronized (getStateLock()) { >> 457 return !isOpaque || isShaped()|| isTextured(); > > It is unclear why textured windows must be considered translucent. Because textured window is a special case of translucent window. The difference is only in nswindow background. So when we set texture property our peer became fully translucent. It doesn't fill background, create non opaque backbuffers and layer etc. > Could you add a comment explaining that, or yet better, not do this > change at all? After all, we can always insert explicit checks for > isTextured() in places where it is really necessary. Otherwise I > suggest to rename the isTranslucent() to something else, because > textured doesn't really mean translucent. > > I'm not an expert in Swing/laf code, so I didn't review those parts. > > -- > best regards, > Anthony > > On 7/2/2012 5:46 PM, Sergey Bylokhov wrote: >> >> Hi Everyone, >> Please review the fix. >> 1 When the property "apple.awt.brushMetalLook" is set we draw our >> panels and toolbars with composite=SRc and alpha=0. >> 2 Changes in JViewport are needed, because copyArea does not handle >> correctly content with alpha!=1.0. >> >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7124513/webrev.00/ >> >> Also note that this CR depends from CR 7124244. >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Jul 4 03:14:04 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 04 Jul 2012 14:14:04 +0400 Subject: [8] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar In-Reply-To: <4FF415E2.6080605@oracle.com> References: <4FF1A63C.3050508@oracle.com> <4FF40ADE.7010104@oracle.com> <4FF415E2.6080605@oracle.com> Message-ID: <4FF4176C.7090109@oracle.com> On 7/4/2012 2:07 PM, Sergey Bylokhov wrote: >> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java >>> // If the target is a dialog, popup or tooltip we want it to >>> ignore the brushed metal look. >>> if (isPopup) { >>> - styleBits = SET(styleBits, TEXTURED, true); >>> + styleBits = SET(styleBits, TEXTURED, false); >> >> Given the change, does the comment above if() still apply to this code? > Well I just change the code according the comments. This code means that > we ignore this property if it was set. > styleBits = SET(styleBits, TEXTURED, false); Thanks for clarifying that. >> src/macosx/classes/sun/lwawt/LWWindowPeer.java >>> 455 public final boolean isTranslucent() { >>> 456 synchronized (getStateLock()) { >>> 457 return !isOpaque || isShaped()|| isTextured(); >> >> It is unclear why textured windows must be considered translucent. > Because textured window is a special case of translucent window. The > difference is only in nswindow background. So when we set texture > property our peer became fully translucent. It doesn't fill background, > create non opaque backbuffers and layer etc. Got it. Please add a comment to the code right above the line 457 with the explanation. Also, please insert a space in front of the last || operator for consistency. -- best regards, Anthony >> Could you add a comment explaining that, or yet better, not do this >> change at all? After all, we can always insert explicit checks for >> isTextured() in places where it is really necessary. Otherwise I >> suggest to rename the isTranslucent() to something else, because >> textured doesn't really mean translucent. >> >> I'm not an expert in Swing/laf code, so I didn't review those parts. >> >> -- >> best regards, >> Anthony >> >> On 7/2/2012 5:46 PM, Sergey Bylokhov wrote: >>> >>> Hi Everyone, >>> Please review the fix. >>> 1 When the property "apple.awt.brushMetalLook" is set we draw our >>> panels and toolbars with composite=SRc and alpha=0. >>> 2 Changes in JViewport are needed, because copyArea does not handle >>> correctly content with alpha!=1.0. >>> >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7124513/webrev.00/ >>> >>> Also note that this CR depends from CR 7124244. >>> >>> -- >>> Best regards, Sergey. >>> > > From Sergey.Bylokhov at oracle.com Wed Jul 4 03:51:48 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 04 Jul 2012 14:51:48 +0400 Subject: [8] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar In-Reply-To: <4FF4176C.7090109@oracle.com> References: <4FF1A63C.3050508@oracle.com> <4FF40ADE.7010104@oracle.com> <4FF415E2.6080605@oracle.com> <4FF4176C.7090109@oracle.com> Message-ID: <4FF42044.9000804@oracle.com> Hi, Anthony. Please check new version: http://cr.openjdk.java.net/~serb/7124513/webrev.01/ 04.07.2012 14:14, Anthony Petrov wrote: > On 7/4/2012 2:07 PM, Sergey Bylokhov wrote: >>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java >>>> // If the target is a dialog, popup or tooltip we want it >>>> to ignore the brushed metal look. >>>> if (isPopup) { >>>> - styleBits = SET(styleBits, TEXTURED, true); >>>> + styleBits = SET(styleBits, TEXTURED, false); >>> >>> Given the change, does the comment above if() still apply to this code? >> Well I just change the code according the comments. This code means >> that we ignore this property if it was set. >> styleBits = SET(styleBits, TEXTURED, false); > > Thanks for clarifying that. > > >>> src/macosx/classes/sun/lwawt/LWWindowPeer.java >>>> 455 public final boolean isTranslucent() { >>>> 456 synchronized (getStateLock()) { >>>> 457 return !isOpaque || isShaped()|| isTextured(); >>> >>> It is unclear why textured windows must be considered translucent. >> Because textured window is a special case of translucent window. The >> difference is only in nswindow background. So when we set texture >> property our peer became fully translucent. It doesn't fill >> background, create non opaque backbuffers and layer etc. > > Got it. Please add a comment to the code right above the line 457 with > the explanation. Also, please insert a space in front of the last || > operator for consistency. > > -- > best regards, > Anthony > >>> Could you add a comment explaining that, or yet better, not do this >>> change at all? After all, we can always insert explicit checks for >>> isTextured() in places where it is really necessary. Otherwise I >>> suggest to rename the isTranslucent() to something else, because >>> textured doesn't really mean translucent. >>> >>> I'm not an expert in Swing/laf code, so I didn't review those parts. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 7/2/2012 5:46 PM, Sergey Bylokhov wrote: >>>> >>>> Hi Everyone, >>>> Please review the fix. >>>> 1 When the property "apple.awt.brushMetalLook" is set we draw our >>>> panels and toolbars with composite=SRc and alpha=0. >>>> 2 Changes in JViewport are needed, because copyArea does not handle >>>> correctly content with alpha!=1.0. >>>> >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/7124513/webrev.00/ >>>> >>>> Also note that this CR depends from CR 7124244. >>>> >>>> -- >>>> Best regards, Sergey. >>>> >> >> -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Jul 4 04:24:29 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 04 Jul 2012 15:24:29 +0400 Subject: [8] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar In-Reply-To: <4FF42044.9000804@oracle.com> References: <4FF1A63C.3050508@oracle.com> <4FF40ADE.7010104@oracle.com> <4FF415E2.6080605@oracle.com> <4FF4176C.7090109@oracle.com> <4FF42044.9000804@oracle.com> Message-ID: <4FF427ED.7020107@oracle.com> Thanks. The fix looks fine to me. -- best regards, Anthony On 7/4/2012 2:51 PM, Sergey Bylokhov wrote: > Hi, Anthony. > Please check new version: > http://cr.openjdk.java.net/~serb/7124513/webrev.01/ > > 04.07.2012 14:14, Anthony Petrov wrote: >> On 7/4/2012 2:07 PM, Sergey Bylokhov wrote: >>>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java >>>>> // If the target is a dialog, popup or tooltip we want it >>>>> to ignore the brushed metal look. >>>>> if (isPopup) { >>>>> - styleBits = SET(styleBits, TEXTURED, true); >>>>> + styleBits = SET(styleBits, TEXTURED, false); >>>> >>>> Given the change, does the comment above if() still apply to this code? >>> Well I just change the code according the comments. This code means >>> that we ignore this property if it was set. >>> styleBits = SET(styleBits, TEXTURED, false); >> >> Thanks for clarifying that. >> >> >>>> src/macosx/classes/sun/lwawt/LWWindowPeer.java >>>>> 455 public final boolean isTranslucent() { >>>>> 456 synchronized (getStateLock()) { >>>>> 457 return !isOpaque || isShaped()|| isTextured(); >>>> >>>> It is unclear why textured windows must be considered translucent. >>> Because textured window is a special case of translucent window. The >>> difference is only in nswindow background. So when we set texture >>> property our peer became fully translucent. It doesn't fill >>> background, create non opaque backbuffers and layer etc. >> >> Got it. Please add a comment to the code right above the line 457 with >> the explanation. Also, please insert a space in front of the last || >> operator for consistency. >> >> -- >> best regards, >> Anthony >> >>>> Could you add a comment explaining that, or yet better, not do this >>>> change at all? After all, we can always insert explicit checks for >>>> isTextured() in places where it is really necessary. Otherwise I >>>> suggest to rename the isTranslucent() to something else, because >>>> textured doesn't really mean translucent. >>>> >>>> I'm not an expert in Swing/laf code, so I didn't review those parts. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 7/2/2012 5:46 PM, Sergey Bylokhov wrote: >>>>> >>>>> Hi Everyone, >>>>> Please review the fix. >>>>> 1 When the property "apple.awt.brushMetalLook" is set we draw our >>>>> panels and toolbars with composite=SRc and alpha=0. >>>>> 2 Changes in JViewport are needed, because copyArea does not handle >>>>> correctly content with alpha!=1.0. >>>>> >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/7124513/webrev.00/ >>>>> >>>>> Also note that this CR depends from CR 7124244. >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>> >>> > > From jost0x2c at gmail.com Wed Jul 4 04:26:42 2012 From: jost0x2c at gmail.com (jost) Date: Wed, 4 Jul 2012 13:26:42 +0200 Subject: jawt_md.h deprecated? In-Reply-To: <2483FFB3-52A7-4E13-B646-359D6565CBE3@oracle.com> References: <2483FFB3-52A7-4E13-B646-359D6565CBE3@oracle.com> Message-ID: On Tue, Jul 3, 2012 at 8:42 PM, Scott Kovatch wrote: > > On Jul 3, 2012, at 9:02 AM, jost wrote: > > > On Tue, Jul 3, 2012 at 5:23 PM, Mike Swingler > wrote: > > > >> On Jul 3, 2012, at 6:50 AM, --- --- wrote: > >> > >>> Hi, > >>> it appears the mac specific version of jawt_md.h (NSView, CALayer) is > not > >>> distributed with the latest (1.7.0_06-ea-b16) build from oracle, it > only > >>> contains the one with the X11-dependent parts. The only option I see > for > >>> using CALayer-based embedding is including the jawt_md.h that is > >>> distributed with JavaVM.framework from apple but this is deprecated. > Does > >>> anyone know if there a supported way of using CALayer-based embedding > or > >>> will it be removed from a future version and is no longer supported? > >>> > >>> -jost > >> > >> The jawt_md.h in OpenJDK needs to contain only the CALayer interface, > >> since the OpenJDK OS X AWT does not support either the X11 or the NSView > >> interface. > >> > > > > I tried with CALayer linked against the jdk and it seems to work, so I > > guess its safe to assume CALayer support is (and will continue?) to be > > there and jawt_md.h just needs to be ported from JavaVM.framework to > > openjdk, removing the NSView parts? Should I file a bug report about > that? > > Yes, please. It sounds like the jawt_md.h we are shipping now is just out > of date. I don't see us changing the CALayer support anytime soon. > > -- Scott K. > Filed as bug 7181710: "We have determined that this report is a new bug and entered the bug into our internal bug tracking system under Bug Id: 7181710. You can monitor this bug on the Java Bug Database at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181710. It may take a day or two before your bug shows up in this external database." From anthony.petrov at oracle.com Wed Jul 4 07:54:25 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 04 Jul 2012 18:54:25 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 Message-ID: <4FF45921.707@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7177173 at: http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ The bug synopsis may sound misleading: the original problem with applying the extended state after showing a frame has been resolved a while back with another fix. The only issue currently left is that the state is reset when a frame is disposed/hidden, which prevents apps from tracking the last known state of a window. With this fix we avoid canceling/reapplying the maximized state to windows on each showing/hiding operation. Instead we track the state in the CPlatformWindow instance, and apply it on showing of the window if the state differs from what shared code expects. The behavior now matches that of Apple JDK (including handling of the ICONIFIED state). -- best regards, Anthony From Sergey.Bylokhov at oracle.com Wed Jul 4 08:07:53 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 04 Jul 2012 19:07:53 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF45921.707@oracle.com> References: <4FF45921.707@oracle.com> Message-ID: <4FF45C49.6070508@oracle.com> Hi, Anthony. Why there are two different methods for isZoomed? 481 final boolean isZoomed =*this.normalBounds == null*; But in the method we use another code. 471 private boolean isZoomed() { 472 return zoomed ||*this.normalBounds != null*; 473 } Probably it can be unified? 04.07.2012 18:54, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7177173 > at: > > http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ > > The bug synopsis may sound misleading: the original problem with > applying the extended state after showing a frame has been resolved a > while back with another fix. The only issue currently left is that the > state is reset when a frame is disposed/hidden, which prevents apps > from tracking the last known state of a window. > > With this fix we avoid canceling/reapplying the maximized state to > windows on each showing/hiding operation. Instead we track the state > in the CPlatformWindow instance, and apply it on showing of the window > if the state differs from what shared code expects. The behavior now > matches that of Apple JDK (including handling of the ICONIFIED state). > > -- > best regards, > Anthony -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Jul 4 08:15:42 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 04 Jul 2012 19:15:42 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF45C49.6070508@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> Message-ID: <4FF45E1E.6030801@oracle.com> Hi Sergey, Thanks for the review. On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: > Why there are two different methods for isZoomed? > > 481 final boolean isZoomed = *this.normalBounds == null*; Here we determine a new state that needs to be set to an undecorated window. This is what isZoomed() will return after the zoom() method returns. > But in the method we use another code. > > 471 private boolean isZoomed() { > 472 return zoomed || *this.normalBounds != null*; > 473 } This is a method that returns the current zoomed state for any window regardless whether it is decorated or not. > Probably it can be unified? No. These are completely different operations. We might change the first line to "final boolean isZoomed = !isZoomed();", but the current code looks a lot clearer to me. -- best regards, Anthony > > > 04.07.2012 18:54, Anthony Petrov wrote: >> Hello, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7177173 >> at: >> >> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >> >> The bug synopsis may sound misleading: the original problem with >> applying the extended state after showing a frame has been resolved a >> while back with another fix. The only issue currently left is that the >> state is reset when a frame is disposed/hidden, which prevents apps >> from tracking the last known state of a window. >> >> With this fix we avoid canceling/reapplying the maximized state to >> windows on each showing/hiding operation. Instead we track the state >> in the CPlatformWindow instance, and apply it on showing of the window >> if the state differs from what shared code expects. The behavior now >> matches that of Apple JDK (including handling of the ICONIFIED state). >> >> -- >> best regards, >> Anthony > > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Wed Jul 4 08:26:54 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 04 Jul 2012 19:26:54 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF45E1E.6030801@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> <4FF45E1E.6030801@oracle.com> Message-ID: <4FF460BE.1040901@oracle.com> Hi,Anthony. I just point to the same name "isZoomed", which contains different state: first is "true" for this.normalBounds == null and the second "true" for this.normalBounds != null. This is strange. I believe that correct code should be isZoomed = isZoomed();? 04.07.2012 19:15, Anthony Petrov wrote: > Hi Sergey, > > Thanks for the review. > > On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: >> Why there are two different methods for isZoomed? >> >> 481 final boolean isZoomed = *this.normalBounds == null*; > > Here we determine a new state that needs to be set to an undecorated > window. This is what isZoomed() will return after the zoom() method > returns. > >> But in the method we use another code. >> >> 471 private boolean isZoomed() { >> 472 return zoomed || *this.normalBounds != null*; >> 473 } > > This is a method that returns the current zoomed state for any window > regardless whether it is decorated or not. > >> Probably it can be unified? > > No. These are completely different operations. We might change the > first line to "final boolean isZoomed = !isZoomed();", but the current > code looks a lot clearer to me. > > -- > best regards, > Anthony > > >> >> >> 04.07.2012 18:54, Anthony Petrov wrote: >>> Hello, >>> >>> Please review a fix for >>> http://bugs.sun.com/view_bug.do?bug_id=7177173 at: >>> >>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >>> >>> The bug synopsis may sound misleading: the original problem with >>> applying the extended state after showing a frame has been resolved >>> a while back with another fix. The only issue currently left is that >>> the state is reset when a frame is disposed/hidden, which prevents >>> apps from tracking the last known state of a window. >>> >>> With this fix we avoid canceling/reapplying the maximized state to >>> windows on each showing/hiding operation. Instead we track the state >>> in the CPlatformWindow instance, and apply it on showing of the >>> window if the state differs from what shared code expects. The >>> behavior now matches that of Apple JDK (including handling of the >>> ICONIFIED state). >>> >>> -- >>> best regards, >>> Anthony >> >> >> -- >> Best regards, Sergey. -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Jul 4 08:30:12 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 04 Jul 2012 19:30:12 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF460BE.1040901@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> <4FF45E1E.6030801@oracle.com> <4FF460BE.1040901@oracle.com> Message-ID: <4FF46184.20508@oracle.com> Hi Sergey, Please find an updated webrev at: http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.2/ I renamed the local variable from isZoomed to doZoom. -- best regards, Anthony On 7/4/2012 7:26 PM, Sergey Bylokhov wrote: > Hi,Anthony. > I just point to the same name "isZoomed", which contains different state: > first is "true" for this.normalBounds == null and the second "true" for > this.normalBounds != null. > This is strange. > I believe that correct code should be isZoomed = isZoomed();? > > 04.07.2012 19:15, Anthony Petrov wrote: >> Hi Sergey, >> >> Thanks for the review. >> >> On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: >>> Why there are two different methods for isZoomed? >>> >>> 481 final boolean isZoomed = *this.normalBounds == null*; >> >> Here we determine a new state that needs to be set to an undecorated >> window. This is what isZoomed() will return after the zoom() method >> returns. >> >>> But in the method we use another code. >>> >>> 471 private boolean isZoomed() { >>> 472 return zoomed || *this.normalBounds != null*; >>> 473 } >> >> This is a method that returns the current zoomed state for any window >> regardless whether it is decorated or not. >> >>> Probably it can be unified? >> >> No. These are completely different operations. We might change the >> first line to "final boolean isZoomed = !isZoomed();", but the current >> code looks a lot clearer to me. >> >> -- >> best regards, >> Anthony >> >> >>> >>> >>> 04.07.2012 18:54, Anthony Petrov wrote: >>>> Hello, >>>> >>>> Please review a fix for >>>> http://bugs.sun.com/view_bug.do?bug_id=7177173 at: >>>> >>>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >>>> >>>> The bug synopsis may sound misleading: the original problem with >>>> applying the extended state after showing a frame has been resolved >>>> a while back with another fix. The only issue currently left is that >>>> the state is reset when a frame is disposed/hidden, which prevents >>>> apps from tracking the last known state of a window. >>>> >>>> With this fix we avoid canceling/reapplying the maximized state to >>>> windows on each showing/hiding operation. Instead we track the state >>>> in the CPlatformWindow instance, and apply it on showing of the >>>> window if the state differs from what shared code expects. The >>>> behavior now matches that of Apple JDK (including handling of the >>>> ICONIFIED state). >>>> >>>> -- >>>> best regards, >>>> Anthony >>> >>> >>> -- >>> Best regards, Sergey. > > From dkocher at sudo.ch Wed Jul 4 09:40:30 2012 From: dkocher at sudo.ch (David Kocher) Date: Wed, 4 Jul 2012 18:40:30 +0200 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> Message-ID: Is there a corresponding ticket in bugs.sun.com that allows to track this issue? -- David On 27.06.2012, at 09:28, David Kocher wrote: > I welcome this issue is getting some serious attention then. When will this be backported to 7u? > > -- David > > On 24.06.2012, at 18:58, Xueming Shen wrote: > >> >> Yes, I believe the issue described in MACOSX_PORT-165 is the >> same issue this patch is trying to solve. >> >> Btw, it appears there are typos in the note(2), my mini keyboard obviously >> is too sticky:-) >> >> (2) normalize the resulting file name from macosx fs APIs from nfd->nfc before passing >> back to java.io.File (File.list() and canonicalize()), so we deal with nfc file name >> (as "usual") for java.io classes/APIs. >> >> -sherman >> >> On 6/24/12 7:50 AM, David Kocher wrote: >>> Will this address issue MACOSX_PORT-165 [1]? >>> >>> [1] http://java.net/jira/browse/MACOSX_PORT-165 >>> >>> -- David >>> >>> On 22.06.2012, at 19:01, Xueming Shen wrote: >>> >>>> Hi >>>> >>>> Here is the proposed change to support Unicode nfd/nfc and case insensitive >>>> file path on MacOSX file system. >>>> >>>> 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X >>>> 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] >>>> >>>> While these two bug reports are only against java.io, we have the same issue in javax.nio.file. >>>> Here is the webrev >>>> >>>> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ >>>> >>>> Here is the brief summary of the changes >>>> >>>> java.io.File: >>>> (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means >>>> we are now passing nfc/composite characters directly into macosx file system APIs >>>> without normalize them to nfd. It appears macosx fs APIs do take nfc, though it uses >>>> nfd. >>>> >>>> (2) normalize the resulting file name from macosx fs APIs from nfd->nfd before passing >>>> back to java.io.File (File.list() and canonicalize()), so we deal with nfdc file name >>>> (as "usual") for java.io classes/APIs. >>>> >>>> (3) fs.compare()/hashCode() was updated to be case insensitive >>>> >>>> (4) hasCode() was updated to use the new String.hash32(). >>>> >>>> java.nio.file: >>>> >>>> (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An alternative is to >>>> update those BsdFile... classes directly to address the macosx specific issues. But given >>>> there might be developers over there might work on open jdk BSD port and have dependency >>>> on these classes, it might be desirable to have another separate layer of MacOSXFile... >>>> classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider and >>>> MacOSXFileSystem. >>>> >>>> (6) the "main" changes are in MacOSXFileSystem, in which the corresponding methods >>>> were added to handle, case insensitive and nfd<=>nfc normalization, including the >>>> pathmatcher. >>>> >>>> (7) compare is now are case-insensitive >>>> >>>> (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and maxosx. >>>> >>>> >>>> Though lots of files have been touched, but the line of changes are actually relatively >>>> small. >>>> >>>> The proposed change only deals with the default case-sensitiveness seting, which is >>>> case insensitive. On MaxOSX, you actually can configure the HFS+ file system or the >>>> mounted vol to be case-sensitive. A possible approach is to have some extra FileStore >>>> attributes, such as a isCaseSensitive and to use case sensitive compare/equal on >>>> such fs, but this can be dealt with separately later. >>>> >>>> Thanks, >>>> -Sherman >>>> >> >> > From weijun.wang at oracle.com Thu Jul 5 01:34:28 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 05 Jul 2012 16:34:28 +0800 Subject: OpenJDK krb5 ignore /etc/krb5.conf? Message-ID: <4FF55194.5050403@oracle.com> Hi Scott On Mac since Lion, sun.security.krb5.Config tries to locate the config info in this order: 1. java.security.krb5.conf system property 2. ${jre}/lib/security/krb5.conf 3. SCDynamicStoreConfig The main difference from other platforms is that it will not try config files, say, /Library/Preferences/edu.mit.Kerberos or /etc/krb5.conf. On the other hand, even /usr/bin/kinit comes with Lion reads the config file (if there is no SCDynamicStoreConfig setting). Is there a special reason for the current Java behavior? I do notice that the Apple 6u33 already does this. Thanks Max From Sergey.Bylokhov at oracle.com Thu Jul 5 02:29:42 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 05 Jul 2012 13:29:42 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF46184.20508@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> <4FF45E1E.6030801@oracle.com> <4FF460BE.1040901@oracle.com> <4FF46184.20508@oracle.com> Message-ID: <4FF55E86.9080200@oracle.com> Hi, Anthony. Fix looks good. 04.07.2012 19:30, Anthony Petrov wrote: > Hi Sergey, > > Please find an updated webrev at: > > http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.2/ > > I renamed the local variable from isZoomed to doZoom. > > -- > best regards, > Anthony > > On 7/4/2012 7:26 PM, Sergey Bylokhov wrote: >> Hi,Anthony. >> I just point to the same name "isZoomed", which contains different >> state: >> first is "true" for this.normalBounds == null and the second "true" >> for this.normalBounds != null. >> This is strange. >> I believe that correct code should be isZoomed = isZoomed();? >> >> 04.07.2012 19:15, Anthony Petrov wrote: >>> Hi Sergey, >>> >>> Thanks for the review. >>> >>> On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: >>>> Why there are two different methods for isZoomed? >>>> >>>> 481 final boolean isZoomed = *this.normalBounds == null*; >>> >>> Here we determine a new state that needs to be set to an undecorated >>> window. This is what isZoomed() will return after the zoom() method >>> returns. >>> >>>> But in the method we use another code. >>>> >>>> 471 private boolean isZoomed() { >>>> 472 return zoomed || *this.normalBounds != null*; >>>> 473 } >>> >>> This is a method that returns the current zoomed state for any >>> window regardless whether it is decorated or not. >>> >>>> Probably it can be unified? >>> >>> No. These are completely different operations. We might change the >>> first line to "final boolean isZoomed = !isZoomed();", but the >>> current code looks a lot clearer to me. >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>>> >>>> >>>> 04.07.2012 18:54, Anthony Petrov wrote: >>>>> Hello, >>>>> >>>>> Please review a fix for >>>>> http://bugs.sun.com/view_bug.do?bug_id=7177173 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >>>>> >>>>> The bug synopsis may sound misleading: the original problem with >>>>> applying the extended state after showing a frame has been >>>>> resolved a while back with another fix. The only issue currently >>>>> left is that the state is reset when a frame is disposed/hidden, >>>>> which prevents apps from tracking the last known state of a window. >>>>> >>>>> With this fix we avoid canceling/reapplying the maximized state to >>>>> windows on each showing/hiding operation. Instead we track the >>>>> state in the CPlatformWindow instance, and apply it on showing of >>>>> the window if the state differs from what shared code expects. The >>>>> behavior now matches that of Apple JDK (including handling of the >>>>> ICONIFIED state). >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>> >>>> >>>> -- >>>> Best regards, Sergey. >> >> -- Best regards, Sergey. From artem.ananiev at oracle.com Thu Jul 5 03:46:01 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 05 Jul 2012 14:46:01 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF46184.20508@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> <4FF45E1E.6030801@oracle.com> <4FF460BE.1040901@oracle.com> <4FF46184.20508@oracle.com> Message-ID: <4FF57069.60406@oracle.com> That's not the clearest code I've ever seen... Is it possible to refactor it to make easier to review and support? For example, replace zoom() with two separate methods, maximize() and restore(), or zoom() and unzoom(), or whatever. Each of those two methods would be no-op, if the window is already in the required state. isZoomed() method is not that trivial as well. In each of the two methods, I would have isUndecorated() condition, and based on the result, check for "isZoomed" or "normalBounds" field... Something like that. I would also enhance the test to include both decorated and undecorated frames. Thanks, Artem On 7/4/2012 7:30 PM, Anthony Petrov wrote: > Hi Sergey, > > Please find an updated webrev at: > > http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.2/ > > I renamed the local variable from isZoomed to doZoom. > > -- > best regards, > Anthony > > On 7/4/2012 7:26 PM, Sergey Bylokhov wrote: >> Hi,Anthony. >> I just point to the same name "isZoomed", which contains different state: >> first is "true" for this.normalBounds == null and the second "true" >> for this.normalBounds != null. >> This is strange. >> I believe that correct code should be isZoomed = isZoomed();? >> >> 04.07.2012 19:15, Anthony Petrov wrote: >>> Hi Sergey, >>> >>> Thanks for the review. >>> >>> On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: >>>> Why there are two different methods for isZoomed? >>>> >>>> 481 final boolean isZoomed = *this.normalBounds == null*; >>> >>> Here we determine a new state that needs to be set to an undecorated >>> window. This is what isZoomed() will return after the zoom() method >>> returns. >>> >>>> But in the method we use another code. >>>> >>>> 471 private boolean isZoomed() { >>>> 472 return zoomed || *this.normalBounds != null*; >>>> 473 } >>> >>> This is a method that returns the current zoomed state for any window >>> regardless whether it is decorated or not. >>> >>>> Probably it can be unified? >>> >>> No. These are completely different operations. We might change the >>> first line to "final boolean isZoomed = !isZoomed();", but the >>> current code looks a lot clearer to me. >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>>> >>>> >>>> 04.07.2012 18:54, Anthony Petrov wrote: >>>>> Hello, >>>>> >>>>> Please review a fix for >>>>> http://bugs.sun.com/view_bug.do?bug_id=7177173 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >>>>> >>>>> The bug synopsis may sound misleading: the original problem with >>>>> applying the extended state after showing a frame has been resolved >>>>> a while back with another fix. The only issue currently left is >>>>> that the state is reset when a frame is disposed/hidden, which >>>>> prevents apps from tracking the last known state of a window. >>>>> >>>>> With this fix we avoid canceling/reapplying the maximized state to >>>>> windows on each showing/hiding operation. Instead we track the >>>>> state in the CPlatformWindow instance, and apply it on showing of >>>>> the window if the state differs from what shared code expects. The >>>>> behavior now matches that of Apple JDK (including handling of the >>>>> ICONIFIED state). >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>> >>>> >>>> -- >>>> Best regards, Sergey. >> >> From anthony.petrov at oracle.com Thu Jul 5 07:08:20 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 05 Jul 2012 18:08:20 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF57069.60406@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> <4FF45E1E.6030801@oracle.com> <4FF460BE.1040901@oracle.com> <4FF46184.20508@oracle.com> <4FF57069.60406@oracle.com> Message-ID: <4FF59FD4.6010506@oracle.com> Hi Artem, Thanks for the review. Please find an updated webrev at: http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.3/ All suggestions have been applied. -- best regards, Anthony On 07/05/12 14:46, Artem Ananiev wrote: > > That's not the clearest code I've ever seen... Is it possible to > refactor it to make easier to review and support? For example, replace > zoom() with two separate methods, maximize() and restore(), or zoom() > and unzoom(), or whatever. Each of those two methods would be no-op, if > the window is already in the required state. > > isZoomed() method is not that trivial as well. In each of the two > methods, I would have isUndecorated() condition, and based on the > result, check for "isZoomed" or "normalBounds" field... Something like > that. > > I would also enhance the test to include both decorated and undecorated > frames. > > Thanks, > > Artem > > On 7/4/2012 7:30 PM, Anthony Petrov wrote: >> Hi Sergey, >> >> Please find an updated webrev at: >> >> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.2/ >> >> I renamed the local variable from isZoomed to doZoom. >> >> -- >> best regards, >> Anthony >> >> On 7/4/2012 7:26 PM, Sergey Bylokhov wrote: >>> Hi,Anthony. >>> I just point to the same name "isZoomed", which contains different >>> state: >>> first is "true" for this.normalBounds == null and the second "true" >>> for this.normalBounds != null. >>> This is strange. >>> I believe that correct code should be isZoomed = isZoomed();? >>> >>> 04.07.2012 19:15, Anthony Petrov wrote: >>>> Hi Sergey, >>>> >>>> Thanks for the review. >>>> >>>> On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: >>>>> Why there are two different methods for isZoomed? >>>>> >>>>> 481 final boolean isZoomed = *this.normalBounds == null*; >>>> >>>> Here we determine a new state that needs to be set to an undecorated >>>> window. This is what isZoomed() will return after the zoom() method >>>> returns. >>>> >>>>> But in the method we use another code. >>>>> >>>>> 471 private boolean isZoomed() { >>>>> 472 return zoomed || *this.normalBounds != null*; >>>>> 473 } >>>> >>>> This is a method that returns the current zoomed state for any window >>>> regardless whether it is decorated or not. >>>> >>>>> Probably it can be unified? >>>> >>>> No. These are completely different operations. We might change the >>>> first line to "final boolean isZoomed = !isZoomed();", but the >>>> current code looks a lot clearer to me. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> >>>>> >>>>> >>>>> 04.07.2012 18:54, Anthony Petrov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a fix for >>>>>> http://bugs.sun.com/view_bug.do?bug_id=7177173 at: >>>>>> >>>>>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >>>>>> >>>>>> The bug synopsis may sound misleading: the original problem with >>>>>> applying the extended state after showing a frame has been resolved >>>>>> a while back with another fix. The only issue currently left is >>>>>> that the state is reset when a frame is disposed/hidden, which >>>>>> prevents apps from tracking the last known state of a window. >>>>>> >>>>>> With this fix we avoid canceling/reapplying the maximized state to >>>>>> windows on each showing/hiding operation. Instead we track the >>>>>> state in the CPlatformWindow instance, and apply it on showing of >>>>>> the window if the state differs from what shared code expects. The >>>>>> behavior now matches that of Apple JDK (including handling of the >>>>>> ICONIFIED state). >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>> >>> From artem.ananiev at oracle.com Thu Jul 5 08:04:32 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 05 Jul 2012 19:04:32 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF59FD4.6010506@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> <4FF45E1E.6030801@oracle.com> <4FF460BE.1040901@oracle.com> <4FF46184.20508@oracle.com> <4FF57069.60406@oracle.com> <4FF59FD4.6010506@oracle.com> Message-ID: <4FF5AD00.5040202@oracle.com> On 7/5/2012 6:08 PM, Anthony Petrov wrote: > Hi Artem, > > Thanks for the review. Please find an updated webrev at: > > http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.3/ > > All suggestions have been applied. That's much clearer! Thanks, it now looks fine. Artem > -- > best regards, > Anthony > > On 07/05/12 14:46, Artem Ananiev wrote: >> >> That's not the clearest code I've ever seen... Is it possible to >> refactor it to make easier to review and support? For example, replace >> zoom() with two separate methods, maximize() and restore(), or zoom() >> and unzoom(), or whatever. Each of those two methods would be no-op, if >> the window is already in the required state. >> >> isZoomed() method is not that trivial as well. In each of the two >> methods, I would have isUndecorated() condition, and based on the >> result, check for "isZoomed" or "normalBounds" field... Something like >> that. >> >> I would also enhance the test to include both decorated and undecorated >> frames. >> >> Thanks, >> >> Artem >> >> On 7/4/2012 7:30 PM, Anthony Petrov wrote: >>> Hi Sergey, >>> >>> Please find an updated webrev at: >>> >>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.2/ >>> >>> I renamed the local variable from isZoomed to doZoom. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 7/4/2012 7:26 PM, Sergey Bylokhov wrote: >>>> Hi,Anthony. >>>> I just point to the same name "isZoomed", which contains different >>>> state: >>>> first is "true" for this.normalBounds == null and the second "true" >>>> for this.normalBounds != null. >>>> This is strange. >>>> I believe that correct code should be isZoomed = isZoomed();? >>>> >>>> 04.07.2012 19:15, Anthony Petrov wrote: >>>>> Hi Sergey, >>>>> >>>>> Thanks for the review. >>>>> >>>>> On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: >>>>>> Why there are two different methods for isZoomed? >>>>>> >>>>>> 481 final boolean isZoomed = *this.normalBounds == null*; >>>>> >>>>> Here we determine a new state that needs to be set to an undecorated >>>>> window. This is what isZoomed() will return after the zoom() method >>>>> returns. >>>>> >>>>>> But in the method we use another code. >>>>>> >>>>>> 471 private boolean isZoomed() { >>>>>> 472 return zoomed || *this.normalBounds != null*; >>>>>> 473 } >>>>> >>>>> This is a method that returns the current zoomed state for any window >>>>> regardless whether it is decorated or not. >>>>> >>>>>> Probably it can be unified? >>>>> >>>>> No. These are completely different operations. We might change the >>>>> first line to "final boolean isZoomed = !isZoomed();", but the >>>>> current code looks a lot clearer to me. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> >>>>>> >>>>>> >>>>>> 04.07.2012 18:54, Anthony Petrov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review a fix for >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7177173 at: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >>>>>>> >>>>>>> The bug synopsis may sound misleading: the original problem with >>>>>>> applying the extended state after showing a frame has been resolved >>>>>>> a while back with another fix. The only issue currently left is >>>>>>> that the state is reset when a frame is disposed/hidden, which >>>>>>> prevents apps from tracking the last known state of a window. >>>>>>> >>>>>>> With this fix we avoid canceling/reapplying the maximized state to >>>>>>> windows on each showing/hiding operation. Instead we track the >>>>>>> state in the CPlatformWindow instance, and apply it on showing of >>>>>>> the window if the state differs from what shared code expects. The >>>>>>> behavior now matches that of Apple JDK (including handling of the >>>>>>> ICONIFIED state). >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>> >>>> From anthony.petrov at oracle.com Fri Jul 6 04:23:49 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 06 Jul 2012 15:23:49 +0400 Subject: [7u6] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 Message-ID: <4FF6CAC5.5080108@oracle.com> Hi Sergey, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7177173 at: http://cr.openjdk.java.net/~anthony/7u6-17-MaximizedBoth-7177173.0/ This is a 100% direct back-port of the same fix from JDK 8. -- best regards, Anthony From Sergey.Bylokhov at oracle.com Fri Jul 6 04:30:20 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 06 Jul 2012 15:30:20 +0400 Subject: [7u6] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF6CAC5.5080108@oracle.com> References: <4FF6CAC5.5080108@oracle.com> Message-ID: <4FF6CC4C.7000806@oracle.com> Hi, Anthony. Fix looks good. 06.07.2012 15:23, Anthony Petrov wrote: > Hi Sergey, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7177173 > at: > > http://cr.openjdk.java.net/~anthony/7u6-17-MaximizedBoth-7177173.0/ > > This is a 100% direct back-port of the same fix from JDK 8. > > -- > best regards, > Anthony -- Best regards, Sergey. From jcpalmer at rochester.rr.com Sat Jul 7 10:49:02 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Sat, 7 Jul 2012 13:49:02 -0400 Subject: Bug ID: 7182370 - Properties for Retina Display Enhancement Message-ID: Have submitted an enhancement bug to OpenJDK Java, based on some messages on the Java list. There is two parts, one for turning hi res on for JRE based implementations. The second for detection by all implementations. Am reprinting since bug system is a poor mechanism for discussion. Replying solely to the OpenJDK list is probably a good idea. Here is what I submitted: Description ---------------- When using the JRE version of Java 7, there needs to be a way to enable high resolution mode for retina displays. Am hearing reports things look good except for redrawing previously built images. This applies to applets as well, but does not apply to bundled Java apps. How it might be implemented may differ between JWS and applets though. If this took the form of a system property, then they also could be specified in a jnlp as jvm args. Suggest something like: java2d.mac.setRetina=true / false - - - - - - An additional property like: java2d.mac.isRetinaHighRes might be good as well, If there can be no way of detecting whether if a retina display is there & enabled. Both JRE & bundled apps could use this. Bundled apps also require the enabled part. Unlike JRE, even though bundled apps can enabled it, I think the user could turn it off. Justification ---------------- There is no way to turn on staying inside Java. If there is a JNI way to do it, there is the side effect of requiring all-permissions. On detection front, several experiments have failed to produce production quality side-effects of detection. Severity ----------- Some progress is possible without resolving this bug. From Sergey.Bylokhov at oracle.com Mon Jul 9 06:28:58 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 09 Jul 2012 17:28:58 +0400 Subject: [7u6] Review request for 7124244: [macosx] Shaped windows support Message-ID: <4FFADC9A.8090405@oracle.com> Hi Everyone, Please review the fix. This is a direct backport from JDK 8 to 7u6. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.04/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f1a90ee31b38 -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Jul 9 06:33:45 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 09 Jul 2012 17:33:45 +0400 Subject: [7u6] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar Message-ID: <4FFADDB9.905@oracle.com> Hi Everyone, Please review the fix. This is a direct backport from JDK 8 to 7u6. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124513/webrev.01 jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/80c592c9458e -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Jul 10 03:27:07 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 10 Jul 2012 14:27:07 +0400 Subject: [7u6] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FFADC9A.8090405@oracle.com> References: <4FFADC9A.8090405@oracle.com> Message-ID: <4FFC037B.3070702@oracle.com> Looks fine. -- best regards, Anthony On 7/9/2012 5:28 PM, Sergey Bylokhov wrote: > > Hi Everyone, > Please review the fix. This is a direct backport from JDK 8 to 7u6. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.04/ > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f1a90ee31b38 > > -- > Best regards, Sergey. > From anthony.petrov at oracle.com Tue Jul 10 03:29:14 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 10 Jul 2012 14:29:14 +0400 Subject: [7u6] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar In-Reply-To: <4FFADDB9.905@oracle.com> References: <4FFADDB9.905@oracle.com> Message-ID: <4FFC03FA.9010608@oracle.com> Looks good. -- best regards, Anthony On 7/9/2012 5:33 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. This is a direct backport from JDK 8 to 7u6. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124513/webrev.01 > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/80c592c9458e > From Alan.Bateman at oracle.com Wed Jul 11 00:51:13 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Jul 2012 08:51:13 +0100 Subject: [8] Review request for 7162111 change tests run in headless mode [macosx] In-Reply-To: <4FF1ADB1.9020508@oracle.com> References: <4FE5154C.2090703@oracle.com> <4FE57019.9090905@oracle.com> <4FE86576.8020407@oracle.com> <4FF1ADB1.9020508@oracle.com> Message-ID: <4FFD3071.2030302@oracle.com> On 02/07/2012 15:18, Jason Uh wrote: > Anthony and Alan, > > Thanks for your comments. I've reverted the changes to CommonSetup.sh > so that XToolkit is no longer forced. Tests still pass. > > Please see the new webrev: > http://cr.openjdk.java.net/~juh/7162111/webrev.01/ > > Thanks, > Jason This looks okay to me too. Do you have a sponsor for this? Also do you plan to get other tests working on the Mac in headless mode too? There are several serialization tests, at least one JMX tests and a couple of other random tests in a few of the core areas that run into the same issue. -Alan. From leonid.romanov at oracle.com Wed Jul 11 06:46:07 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 11 Jul 2012 17:46:07 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode Message-ID: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> Hi, Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ Thanks, Leonid. From anthony.petrov at oracle.com Wed Jul 11 06:56:49 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 11 Jul 2012 17:56:49 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> Message-ID: <4FFD8621.3060706@oracle.com> Hi Leonid, Since GraphicsEnvironment is a shared class, I'm concerned with removing the check for "sun.awt.HeadlessGraphicsEnvironment" to determine whether we should run in headless mode. Can we keep this check in place, and also add the new one that checks the toolkit name? -- best regards, Anthony On 7/11/2012 5:46 PM, Leonid Romanov wrote: > Hi, > Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 > Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ > > Thanks, > Leonid. > From leonid.romanov at oracle.com Wed Jul 11 07:29:24 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 11 Jul 2012 18:29:24 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <4FFD8621.3060706@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFD8621.3060706@oracle.com> Message-ID: Hi, This had been my concern as well, but then I found this: http://cr.openjdk.java.net/~anthony/x-5-forceHeadless.0/src/share/classes/java/awt/GraphicsEnvironment.java.sdiff.html Looks like you added this check as part of the fix for http://java.net/jira/browse/MACOSX_PORT-774 Which means that this check is only useful for OS X, and therefore it's OK to replace it with another. On 11.07.2012, at 17:56, Anthony Petrov wrote: > Hi Leonid, > > Since GraphicsEnvironment is a shared class, I'm concerned with removing the check for "sun.awt.HeadlessGraphicsEnvironment" to determine whether we should run in headless mode. Can we keep this check in place, and also add the new one that checks the toolkit name? > > -- > best regards, > Anthony > > On 7/11/2012 5:46 PM, Leonid Romanov wrote: >> Hi, >> Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >> Thanks, >> Leonid. From anthony.petrov at oracle.com Wed Jul 11 07:34:36 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 11 Jul 2012 18:34:36 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFD8621.3060706@oracle.com> Message-ID: <4FFD8EFC.9030004@oracle.com> Indeed. Thanks for reminding about that. In this case I'm fine with your fix. -- best regards, Anthony On 7/11/2012 6:29 PM, Leonid Romanov wrote: > Hi, > This had been my concern as well, but then I found this: > http://cr.openjdk.java.net/~anthony/x-5-forceHeadless.0/src/share/classes/java/awt/GraphicsEnvironment.java.sdiff.html > > Looks like you added this check as part of the fix for http://java.net/jira/browse/MACOSX_PORT-774 > Which means that this check is only useful for OS X, and therefore it's OK to replace it with another. > > > On 11.07.2012, at 17:56, Anthony Petrov wrote: > >> Hi Leonid, >> >> Since GraphicsEnvironment is a shared class, I'm concerned with removing the check for "sun.awt.HeadlessGraphicsEnvironment" to determine whether we should run in headless mode. Can we keep this check in place, and also add the new one that checks the toolkit name? >> >> -- >> best regards, >> Anthony >> >> On 7/11/2012 5:46 PM, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>> Thanks, >>> Leonid. > From david.holmes at oracle.com Wed Jul 11 18:15:31 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Jul 2012 11:15:31 +1000 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> Message-ID: <4FFE2533.7020302@oracle.com> On 11/07/2012 11:46 PM, Leonid Romanov wrote: > Hi, > Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. sun.awt.HToolkit was introduced for use by SE-Embedded's reduced headless JRE. How did the OSX port end up using it ??? Headless handling on OSX should be like regular headless on Linux, Solaris. David > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 > Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ > > Thanks, > Leonid. > From leonid.romanov at oracle.com Thu Jul 12 01:58:56 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 12 Jul 2012 12:58:56 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <4FFE2533.7020302@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> Message-ID: <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> Perhaps Anthony might be able to answer your question: he has tinkered a lot with headless related stuff. David, are you implying that in the current form my fix is no-go? On 12.07.2012, at 5:15, David Holmes wrote: > On 11/07/2012 11:46 PM, Leonid Romanov wrote: >> Hi, >> Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. > > sun.awt.HToolkit was introduced for use by SE-Embedded's reduced headless JRE. How did the OSX port end up using it ??? > > Headless handling on OSX should be like regular headless on Linux, Solaris. > > David > >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >> >> Thanks, >> Leonid. >> From david.holmes at oracle.com Thu Jul 12 02:37:04 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Jul 2012 19:37:04 +1000 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> Message-ID: <4FFE9AC0.8010204@oracle.com> On 12/07/2012 6:58 PM, Leonid Romanov wrote: > Perhaps Anthony might be able to answer your question: he has tinkered a lot with headless related stuff. > David, are you implying that in the current form my fix is no-go? Not my place to do that. I'm just wondering how the HToolkit got involved with OSX, and why OSX headless is handled differently to Solaris/linux (which don't use HToolkit). David > On 12.07.2012, at 5:15, David Holmes wrote: > >> On 11/07/2012 11:46 PM, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. >> >> sun.awt.HToolkit was introduced for use by SE-Embedded's reduced headless JRE. How did the OSX port end up using it ??? >> >> Headless handling on OSX should be like regular headless on Linux, Solaris. >> >> David >> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>> >>> Thanks, >>> Leonid. >>> > From anthony.petrov at oracle.com Thu Jul 12 05:33:22 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 12 Jul 2012 16:33:22 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> Message-ID: <4FFEC412.2060200@oracle.com> The logic is all in src/solaris/native/java/lang/java_props_macosx.c. The getPreferredToolkit() returns the HToolkit constant when the headless mode is needed on the Mac. And the GetJavaProperties() will then choose the sun.awt.HToolkit as the toolkit. Interesting. But it all seems to work fine in headless mode on the Mac, right? Leonid, did you run headless regression tests with your fix, btw? -- best regards, Anthony On 07/12/12 12:58, Leonid Romanov wrote: > Perhaps Anthony might be able to answer your question: he has tinkered a lot with headless related stuff. > David, are you implying that in the current form my fix is no-go? > > On 12.07.2012, at 5:15, David Holmes wrote: > >> On 11/07/2012 11:46 PM, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. >> >> sun.awt.HToolkit was introduced for use by SE-Embedded's reduced headless JRE. How did the OSX port end up using it ??? >> >> Headless handling on OSX should be like regular headless on Linux, Solaris. >> >> David >> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>> >>> Thanks, >>> Leonid. >>> > From harshman+javadev at gmail.com Thu Jul 12 06:52:39 2012 From: harshman+javadev at gmail.com (Chris Harshman) Date: Thu, 12 Jul 2012 06:52:39 -0700 Subject: [Semi-OT] Oracle 10g OS X Message-ID: Oracle Database 10g Release 2 (10.2.0.4.0) was at one time available for OS X , but it's since been removed from OTN. Is there any (cost effective ;)) way of obtaining a copy of that software? I have a dev database I need to work with, deployment platform is Java-on-OSX (well, Java anywhere, but we're specifically developing for / texting on OS X) and while down the road it won't matter where the database is, for dev and demo purposes it would be *really* handy to have it running locally, natively. We've tried using Oracle 11gon the Oracle-provided Solaris 11 virtual machine( VirtualBox), but that arrangement is barely usable (it overwhelmed my poor Late 2010 MacBook Air 1.86GHz Core 2 Duo (128GB SSD, 4GB RAM)... We're not too late in the process to punt and go with a Derby, PostgreSQL, or MySQL solution (all of which are either 100% Java or are natively available on the Mac), but the initial preference was Oracle, so if we can accommodate that (there are a couple of other devs, and we're all on Macintoshes), that'd be "most excellent." :) Thanks! From dalibor.topic at oracle.com Thu Jul 12 07:12:35 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 12 Jul 2012 16:12:35 +0200 Subject: [Semi-OT] Oracle 10g OS X In-Reply-To: References: Message-ID: <4FFEDB53.6030707@oracle.com> On 7/12/12 3:52 PM, Chris Harshman wrote: > Oracle Database 10g Release 2 (10.2.0.4.0) was at one time available for OS > X , but > it's since been removed from > OTN. > Is there any (cost effective ;)) way of obtaining a copy of that software? Fully off topic here ;), but you should try the Oracle forums at https://forums.oracle.com/forums/main.jspa?categoryID=84 cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From leonid.romanov at oracle.com Thu Jul 12 01:58:56 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 12 Jul 2012 12:58:56 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <4FFE2533.7020302@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> Message-ID: <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> Perhaps Anthony might be able to answer your question: he has tinkered a lot with headless related stuff. David, are you implying that in the current form my fix is no-go? On 12.07.2012, at 5:15, David Holmes wrote: > On 11/07/2012 11:46 PM, Leonid Romanov wrote: >> Hi, >> Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. > > sun.awt.HToolkit was introduced for use by SE-Embedded's reduced headless JRE. How did the OSX port end up using it ??? > > Headless handling on OSX should be like regular headless on Linux, Solaris. > > David > >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >> >> Thanks, >> Leonid. >> From david.holmes at oracle.com Thu Jul 12 14:26:13 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Jul 2012 07:26:13 +1000 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <4FFEC412.2060200@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> Message-ID: <4FFF40F5.7090508@oracle.com> On 12/07/2012 10:33 PM, Anthony Petrov wrote: > The logic is all in src/solaris/native/java/lang/java_props_macosx.c. > The getPreferredToolkit() returns the HToolkit constant when the > headless mode is needed on the Mac. And the GetJavaProperties() will > then choose the sun.awt.HToolkit as the toolkit. Interesting. Interesting indeed. But my concerns remain. HToolkit was not intended for general use. OSX seems to be handling headless mode in a completely different way to Solaris/linux. Of course it may be that on OSX you run into the same conditions when headless that required the introduction of HToolkit. But somebody should have made a very conscious decision to do that. > But it all seems to work fine in headless mode on the Mac, right? You mean apart from this bug? ;-) I see a few bugs involving headless on OSX. Cheers, David > Leonid, did you run headless regression tests with your fix, btw? > > -- > best regards, > Anthony > > On 07/12/12 12:58, Leonid Romanov wrote: >> Perhaps Anthony might be able to answer your question: he has tinkered >> a lot with headless related stuff. >> David, are you implying that in the current form my fix is no-go? >> >> On 12.07.2012, at 5:15, David Holmes wrote: >> >>> On 11/07/2012 11:46 PM, Leonid Romanov wrote: >>>> Hi, >>>> Please review a fix for 7181027: [macosx] Unable to use headless >>>> mode. The problem here is that for headless mode >>>> "java.awt.graphicsenv" system property should be >>>> CGraphicsEnvironment because the way GraphicsEnvironment.createGE() >>>> method works: it first instantiates GraphicsEnvironment instance and >>>> then wraps it with HeadlessGraphicsEnvironment if in headless mode. >>>> This means twe can't use java.awt.graphicsenv property to determine >>>> whether we are in headless mode or not. So, I've replaced it with a >>>> toolkit check: if it's HToolkit, then we are in headless. >>> >>> sun.awt.HToolkit was introduced for use by SE-Embedded's reduced >>> headless JRE. How did the OSX port end up using it ??? >>> >>> Headless handling on OSX should be like regular headless on Linux, >>> Solaris. >>> >>> David >>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>>> >>>> Thanks, >>>> Leonid. >>>> >> From anthony.petrov at oracle.com Fri Jul 13 05:58:28 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 13 Jul 2012 16:58:28 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <4FFF40F5.7090508@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> <4FFF40F5.7090508@oracle.com> Message-ID: <50001B74.5070105@oracle.com> I dug into the code history a little. The following Mike's changeset is "to blame" for using HToolkit in headless mode on the Mac: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf I've looked through the LWCToolkit.m which implements native methods specific to the real, headful Mac toolkit, and actually all of the code seems to be related to headful behavior only. Note that in the headless mode the awt_LoadLibrary.c will still load the correct lwawt dynamic native library, so all the necessary steps to initialize the app from Mac OS X perspective will be performed anyway, and all the native methods required by CFontManager and other C* classes will be available also. So basically I don't really see a problem with using the HToolkit class for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will wrap the real toolkit instance into a HeadlessToolkit class anyway, so code that relies on instanceof checks against a toolkit instance should not be affected by this choice in any way. David, do you see any specific issues with using HToolkit on a desktop (Mac) system? -- best regards, Anthony On 7/13/2012 1:26 AM, David Holmes wrote: > On 12/07/2012 10:33 PM, Anthony Petrov wrote: >> The logic is all in src/solaris/native/java/lang/java_props_macosx.c. >> The getPreferredToolkit() returns the HToolkit constant when the >> headless mode is needed on the Mac. And the GetJavaProperties() will >> then choose the sun.awt.HToolkit as the toolkit. Interesting. > > Interesting indeed. But my concerns remain. HToolkit was not intended > for general use. OSX seems to be handling headless mode in a completely > different way to Solaris/linux. > > Of course it may be that on OSX you run into the same conditions when > headless that required the introduction of HToolkit. But somebody should > have made a very conscious decision to do that. > >> But it all seems to work fine in headless mode on the Mac, right? > > You mean apart from this bug? ;-) I see a few bugs involving headless on > OSX. > > Cheers, > David > >> Leonid, did you run headless regression tests with your fix, btw? >> >> -- >> best regards, >> Anthony >> >> On 07/12/12 12:58, Leonid Romanov wrote: >>> Perhaps Anthony might be able to answer your question: he has tinkered >>> a lot with headless related stuff. >>> David, are you implying that in the current form my fix is no-go? >>> >>> On 12.07.2012, at 5:15, David Holmes wrote: >>> >>>> On 11/07/2012 11:46 PM, Leonid Romanov wrote: >>>>> Hi, >>>>> Please review a fix for 7181027: [macosx] Unable to use headless >>>>> mode. The problem here is that for headless mode >>>>> "java.awt.graphicsenv" system property should be >>>>> CGraphicsEnvironment because the way GraphicsEnvironment.createGE() >>>>> method works: it first instantiates GraphicsEnvironment instance and >>>>> then wraps it with HeadlessGraphicsEnvironment if in headless mode. >>>>> This means twe can't use java.awt.graphicsenv property to determine >>>>> whether we are in headless mode or not. So, I've replaced it with a >>>>> toolkit check: if it's HToolkit, then we are in headless. >>>> >>>> sun.awt.HToolkit was introduced for use by SE-Embedded's reduced >>>> headless JRE. How did the OSX port end up using it ??? >>>> >>>> Headless handling on OSX should be like regular headless on Linux, >>>> Solaris. >>>> >>>> David >>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>>>> >>>>> Thanks, >>>>> Leonid. >>>>> >>> From david.holmes at oracle.com Fri Jul 13 06:09:59 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Jul 2012 23:09:59 +1000 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <50001B74.5070105@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> <4FFF40F5.7090508@oracle.com> <50001B74.5070105@oracle.com> Message-ID: <50001E27.2090601@oracle.com> On 13/07/2012 10:58 PM, Anthony Petrov wrote: > I dug into the code history a little. The following Mike's changeset is > "to blame" for using HToolkit in headless mode on the Mac: > > http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf > > I've looked through the LWCToolkit.m which implements native methods > specific to the real, headful Mac toolkit, and actually all of the code > seems to be related to headful behavior only. > > Note that in the headless mode the awt_LoadLibrary.c will still load the > correct lwawt dynamic native library, so all the necessary steps to > initialize the app from Mac OS X perspective will be performed anyway, > and all the native methods required by CFontManager and other C* classes > will be available also. > > So basically I don't really see a problem with using the HToolkit class > for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will > wrap the real toolkit instance into a HeadlessToolkit class anyway, so > code that relies on instanceof checks against a toolkit instance should > not be affected by this choice in any way. > > David, do you see any specific issues with using HToolkit on a desktop > (Mac) system? No. I'm just wary of it. I'm curious what would have been done if this HToolkit class had not existed? David ----- > -- > best regards, > Anthony > > On 7/13/2012 1:26 AM, David Holmes wrote: >> On 12/07/2012 10:33 PM, Anthony Petrov wrote: >>> The logic is all in src/solaris/native/java/lang/java_props_macosx.c. >>> The getPreferredToolkit() returns the HToolkit constant when the >>> headless mode is needed on the Mac. And the GetJavaProperties() will >>> then choose the sun.awt.HToolkit as the toolkit. Interesting. >> >> Interesting indeed. But my concerns remain. HToolkit was not intended >> for general use. OSX seems to be handling headless mode in a >> completely different way to Solaris/linux. >> >> Of course it may be that on OSX you run into the same conditions when >> headless that required the introduction of HToolkit. But somebody >> should have made a very conscious decision to do that. >> >>> But it all seems to work fine in headless mode on the Mac, right? >> >> You mean apart from this bug? ;-) I see a few bugs involving headless >> on OSX. >> >> Cheers, >> David >> >>> Leonid, did you run headless regression tests with your fix, btw? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 07/12/12 12:58, Leonid Romanov wrote: >>>> Perhaps Anthony might be able to answer your question: he has tinkered >>>> a lot with headless related stuff. >>>> David, are you implying that in the current form my fix is no-go? >>>> >>>> On 12.07.2012, at 5:15, David Holmes wrote: >>>> >>>>> On 11/07/2012 11:46 PM, Leonid Romanov wrote: >>>>>> Hi, >>>>>> Please review a fix for 7181027: [macosx] Unable to use headless >>>>>> mode. The problem here is that for headless mode >>>>>> "java.awt.graphicsenv" system property should be >>>>>> CGraphicsEnvironment because the way GraphicsEnvironment.createGE() >>>>>> method works: it first instantiates GraphicsEnvironment instance and >>>>>> then wraps it with HeadlessGraphicsEnvironment if in headless mode. >>>>>> This means twe can't use java.awt.graphicsenv property to determine >>>>>> whether we are in headless mode or not. So, I've replaced it with a >>>>>> toolkit check: if it's HToolkit, then we are in headless. >>>>> >>>>> sun.awt.HToolkit was introduced for use by SE-Embedded's reduced >>>>> headless JRE. How did the OSX port end up using it ??? >>>>> >>>>> Headless handling on OSX should be like regular headless on Linux, >>>>> Solaris. >>>>> >>>>> David >>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Leonid. >>>>>> >>>> From anthony.petrov at oracle.com Fri Jul 13 06:22:34 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 13 Jul 2012 17:22:34 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <50001E27.2090601@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> <4FFF40F5.7090508@oracle.com> <50001B74.5070105@oracle.com> <50001E27.2090601@oracle.com> Message-ID: <5000211A.7010903@oracle.com> On 7/13/2012 5:09 PM, David Holmes wrote: > On 13/07/2012 10:58 PM, Anthony Petrov wrote: >> I dug into the code history a little. The following Mike's changeset is >> "to blame" for using HToolkit in headless mode on the Mac: >> >> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf >> >> I've looked through the LWCToolkit.m which implements native methods >> specific to the real, headful Mac toolkit, and actually all of the code >> seems to be related to headful behavior only. >> >> Note that in the headless mode the awt_LoadLibrary.c will still load the >> correct lwawt dynamic native library, so all the necessary steps to >> initialize the app from Mac OS X perspective will be performed anyway, >> and all the native methods required by CFontManager and other C* classes >> will be available also. >> >> So basically I don't really see a problem with using the HToolkit class >> for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will >> wrap the real toolkit instance into a HeadlessToolkit class anyway, so >> code that relies on instanceof checks against a toolkit instance should >> not be affected by this choice in any way. >> >> David, do you see any specific issues with using HToolkit on a desktop >> (Mac) system? > > No. I'm just wary of it. I'm curious what would have been done if this > HToolkit class had not existed? Either it would have been introduced, or the LWCToolkit/LWToolkit classes would have been made "more headless-aware," so to speak. I think Mike could shed some light on his decision. Anyway, to conclude the reviewing thread, given that we don't (currently) see any problems with using HToolkit on the Mac, and the fact that it's already been used in headless mode on the Mac for a while, I'm fine with the fix proposed by Leonid. -- best regards, Anthony > > David > ----- > >> -- >> best regards, >> Anthony >> >> On 7/13/2012 1:26 AM, David Holmes wrote: >>> On 12/07/2012 10:33 PM, Anthony Petrov wrote: >>>> The logic is all in src/solaris/native/java/lang/java_props_macosx.c. >>>> The getPreferredToolkit() returns the HToolkit constant when the >>>> headless mode is needed on the Mac. And the GetJavaProperties() will >>>> then choose the sun.awt.HToolkit as the toolkit. Interesting. >>> >>> Interesting indeed. But my concerns remain. HToolkit was not intended >>> for general use. OSX seems to be handling headless mode in a >>> completely different way to Solaris/linux. >>> >>> Of course it may be that on OSX you run into the same conditions when >>> headless that required the introduction of HToolkit. But somebody >>> should have made a very conscious decision to do that. >>> >>>> But it all seems to work fine in headless mode on the Mac, right? >>> >>> You mean apart from this bug? ;-) I see a few bugs involving headless >>> on OSX. >>> >>> Cheers, >>> David >>> >>>> Leonid, did you run headless regression tests with your fix, btw? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 07/12/12 12:58, Leonid Romanov wrote: >>>>> Perhaps Anthony might be able to answer your question: he has tinkered >>>>> a lot with headless related stuff. >>>>> David, are you implying that in the current form my fix is no-go? >>>>> >>>>> On 12.07.2012, at 5:15, David Holmes wrote: >>>>> >>>>>> On 11/07/2012 11:46 PM, Leonid Romanov wrote: >>>>>>> Hi, >>>>>>> Please review a fix for 7181027: [macosx] Unable to use headless >>>>>>> mode. The problem here is that for headless mode >>>>>>> "java.awt.graphicsenv" system property should be >>>>>>> CGraphicsEnvironment because the way GraphicsEnvironment.createGE() >>>>>>> method works: it first instantiates GraphicsEnvironment instance and >>>>>>> then wraps it with HeadlessGraphicsEnvironment if in headless mode. >>>>>>> This means twe can't use java.awt.graphicsenv property to determine >>>>>>> whether we are in headless mode or not. So, I've replaced it with a >>>>>>> toolkit check: if it's HToolkit, then we are in headless. >>>>>> >>>>>> sun.awt.HToolkit was introduced for use by SE-Embedded's reduced >>>>>> headless JRE. How did the OSX port end up using it ??? >>>>>> >>>>>> Headless handling on OSX should be like regular headless on Linux, >>>>>> Solaris. >>>>>> >>>>>> David >>>>>> >>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Leonid. >>>>>>> >>>>> From swingler at apple.com Fri Jul 13 07:23:15 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 13 Jul 2012 07:23:15 -0700 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <5000211A.7010903@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> <4FFF40F5.7090508@oracle.com> <50001B74.5070105@oracle.com> <50001E27.2090601@oracle.com> <5000211A.7010903@oracle.com> Message-ID: <6228EDFA-1B87-4758-A11C-9E45A9B0C272@apple.com> On Jul 13, 2012, at 6:22 AM, Anthony Petrov wrote: > On 7/13/2012 5:09 PM, David Holmes wrote: > >> On 13/07/2012 10:58 PM, Anthony Petrov wrote: >> >>> I dug into the code history a little. The following Mike's changeset is >>> "to blame" for using HToolkit in headless mode on the Mac: >>> >>> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf >>> >>> I've looked through the LWCToolkit.m which implements native methods >>> specific to the real, headful Mac toolkit, and actually all of the code >>> seems to be related to headful behavior only. >>> >>> Note that in the headless mode the awt_LoadLibrary.c will still load the >>> correct lwawt dynamic native library, so all the necessary steps to >>> initialize the app from Mac OS X perspective will be performed anyway, >>> and all the native methods required by CFontManager and other C* classes >>> will be available also. >>> >>> So basically I don't really see a problem with using the HToolkit class >>> for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will >>> wrap the real toolkit instance into a HeadlessToolkit class anyway, so >>> code that relies on instanceof checks against a toolkit instance should >>> not be affected by this choice in any way. >>> >>> David, do you see any specific issues with using HToolkit on a desktop >>> (Mac) system? >> >> No. I'm just wary of it. I'm curious what would have been done if this HToolkit class had not existed? > > Either it would have been introduced, or the LWCToolkit/LWToolkit classes would have been made "more headless-aware," so to speak. I think Mike could shed some light on his decision. I was looking for a way to ensure that once the choice to be headless was made, there would be no way to undo it. We've had problems in Java SE 6 and prior where the old CToolkit was "mostly headless", but could still try to make contact to the window server for somethings (edge cases in fonts, IIRC). This would "mostly work" for a while under an SSH session, but would die some hours later after Mach bootstrap session expired, and lead to diagnosing some fairly frustrating bugs. With HToolkit, the boot comes down immediately about what you can and cannot do - and the implementation looked simple enough, I didn't see much risk. It was there, it worked, I went with it. > Anyway, to conclude the reviewing thread, given that we don't (currently) see any problems with using HToolkit on the Mac, and the fact that it's already been used in headless mode on the Mac for a while, I'm fine with the fix proposed by Leonid. I personally don't see why HToolkit couldn't be used unilaterally for headless mode on all platforms. Wouldn't any breakage show an improper layering violation that should not have been allowed to occur in the first place? Regards, Mike Swingler Apple Inc. From david.holmes at oracle.com Fri Jul 13 17:40:46 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 14 Jul 2012 10:40:46 +1000 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <6228EDFA-1B87-4758-A11C-9E45A9B0C272@apple.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> <4FFF40F5.7090508@oracle.com> <50001B74.5070105@oracle.com> <50001E27.2090601@oracle.com> <5000211A.7010903@oracle.com> <6228EDFA-1B87-4758-A11C-9E45A9B0C272@apple.com> Message-ID: <5000C00E.3030209@oracle.com> On 14/07/2012 12:23 AM, Mike Swingler wrote: > On Jul 13, 2012, at 6:22 AM, Anthony Petrov wrote: >> On 7/13/2012 5:09 PM, David Holmes wrote: >>> On 13/07/2012 10:58 PM, Anthony Petrov wrote: >>> >>>> I dug into the code history a little. The following Mike's changeset is >>>> "to blame" for using HToolkit in headless mode on the Mac: >>>> >>>> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf >>>> >>>> I've looked through the LWCToolkit.m which implements native methods >>>> specific to the real, headful Mac toolkit, and actually all of the code >>>> seems to be related to headful behavior only. >>>> >>>> Note that in the headless mode the awt_LoadLibrary.c will still load the >>>> correct lwawt dynamic native library, so all the necessary steps to >>>> initialize the app from Mac OS X perspective will be performed anyway, >>>> and all the native methods required by CFontManager and other C* classes >>>> will be available also. >>>> >>>> So basically I don't really see a problem with using the HToolkit class >>>> for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will >>>> wrap the real toolkit instance into a HeadlessToolkit class anyway, so >>>> code that relies on instanceof checks against a toolkit instance should >>>> not be affected by this choice in any way. >>>> >>>> David, do you see any specific issues with using HToolkit on a desktop >>>> (Mac) system? >>> >>> No. I'm just wary of it. I'm curious what would have been done if this HToolkit class had not existed? >> >> Either it would have been introduced, or the LWCToolkit/LWToolkit classes would have been made "more headless-aware," so to speak. I think Mike could shed some light on his decision. > > I was looking for a way to ensure that once the choice to be headless was made, there would be no way to undo it. We've had problems in Java SE 6 and prior where the old CToolkit was "mostly headless", but could still try to make contact to the window server for somethings (edge cases in fonts, IIRC). This would "mostly work" for a while under an SSH session, but would die some hours later after Mach bootstrap session expired, and lead to diagnosing some fairly frustrating bugs. > > With HToolkit, the boot comes down immediately about what you can and cannot do - and the implementation looked simple enough, I didn't see much risk. It was there, it worked, I went with it. > >> Anyway, to conclude the reviewing thread, given that we don't (currently) see any problems with using HToolkit on the Mac, and the fact that it's already been used in headless mode on the Mac for a while, I'm fine with the fix proposed by Leonid. > > I personally don't see why HToolkit couldn't be used unilaterally for headless mode on all platforms. Wouldn't any breakage show an improper layering violation that should not have been allowed to occur in the first place? It was introduced for platforms with absolutely zero "graphics" related capabilities - not even libraries installed let alone hardware. The pre-existing "headless" toolkits still required some of this support for, as I recall, printing/font related things - which must still be supported even in headless mode. As long as this is passing the full set of TCK/JCK tests then it is usable. David ----- > Regards, > Mike Swingler > Apple Inc. > From swingler at apple.com Sat Jul 14 06:52:28 2012 From: swingler at apple.com (Mike Swingler) Date: Sat, 14 Jul 2012 06:52:28 -0700 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <5000C00E.3030209@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> <4FFF40F5.7090508@oracle.com> <50001B74.5070105@oracle.com> <50001E27.2090601@oracle.com> <5000211A.7010903@oracle.com> <6228EDFA-1B87-4758-A11C-9E45A9B0C272@apple.com> <5000C00E.3030209@oracle.com> Message-ID: <54F9A10C-BFAE-4429-B7A0-035CDA1AF327@apple.com> On Jul 13, 2012, at 5:40 PM, David Holmes wrote: > On 14/07/2012 12:23 AM, Mike Swingler wrote: >> On Jul 13, 2012, at 6:22 AM, Anthony Petrov wrote: >>> On 7/13/2012 5:09 PM, David Holmes wrote: >>>> On 13/07/2012 10:58 PM, Anthony Petrov wrote: >>>> >>>>> I dug into the code history a little. The following Mike's changeset is >>>>> "to blame" for using HToolkit in headless mode on the Mac: >>>>> >>>>> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf >>>>> >>>>> I've looked through the LWCToolkit.m which implements native methods >>>>> specific to the real, headful Mac toolkit, and actually all of the code >>>>> seems to be related to headful behavior only. >>>>> >>>>> Note that in the headless mode the awt_LoadLibrary.c will still load the >>>>> correct lwawt dynamic native library, so all the necessary steps to >>>>> initialize the app from Mac OS X perspective will be performed anyway, >>>>> and all the native methods required by CFontManager and other C* classes >>>>> will be available also. >>>>> >>>>> So basically I don't really see a problem with using the HToolkit class >>>>> for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will >>>>> wrap the real toolkit instance into a HeadlessToolkit class anyway, so >>>>> code that relies on instanceof checks against a toolkit instance should >>>>> not be affected by this choice in any way. >>>>> >>>>> David, do you see any specific issues with using HToolkit on a desktop >>>>> (Mac) system? >>>> >>>> No. I'm just wary of it. I'm curious what would have been done if this HToolkit class had not existed? >>> >>> Either it would have been introduced, or the LWCToolkit/LWToolkit classes would have been made "more headless-aware," so to speak. I think Mike could shed some light on his decision. >> >> I was looking for a way to ensure that once the choice to be headless was made, there would be no way to undo it. We've had problems in Java SE 6 and prior where the old CToolkit was "mostly headless", but could still try to make contact to the window server for somethings (edge cases in fonts, IIRC). This would "mostly work" for a while under an SSH session, but would die some hours later after Mach bootstrap session expired, and lead to diagnosing some fairly frustrating bugs. >> >> With HToolkit, the boot comes down immediately about what you can and cannot do - and the implementation looked simple enough, I didn't see much risk. It was there, it worked, I went with it. >> >>> Anyway, to conclude the reviewing thread, given that we don't (currently) see any problems with using HToolkit on the Mac, and the fact that it's already been used in headless mode on the Mac for a while, I'm fine with the fix proposed by Leonid. >> >> I personally don't see why HToolkit couldn't be used unilaterally for headless mode on all platforms. Wouldn't any breakage show an improper layering violation that should not have been allowed to occur in the first place? > > It was introduced for platforms with absolutely zero "graphics" related capabilities - not even libraries installed let alone hardware. The pre-existing "headless" toolkits still required some of this support for, as I recall, printing/font related things - which must still be supported even in headless mode. As long as this is passing the full set of TCK/JCK tests then it is usable. In OS X, it is unsafe to communicate with any Cocoa code in a headless/server environment, so this is actually a good match for our usage. Any font usage or printing done in this mode would have to fall back to only font files and CUPS sockets, and not rely on the CoreText/CoreGraphics API. Trying to add font or printing in a server context might be a reason to sub-class or extend HToolkit - but I imagine some of that implementation would be common with the XToolkit, and that would be an interesting design discussion how to tease all that apart and recombine it in a modular way that would allow CToolkit to delegate to it without introducing a dependency on X11. Regards, Mike Swingler Apple Inc. From Doug.Zwick at blackboard.com Mon Jul 16 17:08:10 2012 From: Doug.Zwick at blackboard.com (Doug Zwick) Date: Mon, 16 Jul 2012 20:08:10 -0400 Subject: Translucent/Shaped Windows Message-ID: <9A354066-3A8B-485C-A6E2-BB3DF2809A2F@blackboard.com> What is the current status of the Translucent/Shaped Windows API in the OS X port? I am updating some code using the old Java 1.6 temporary API to use the final 1.7 API, and the window is not passing mouse clicks through properly (the Apple 1.6 JRE did pass clicks through). I am running with 1.7.0_05. I did notice that calls to Window.setShape throw an exception: java.lang.UnsupportedOperationException: PERPIXEL_TRANSPARENT translucency is not supported. However, GraphicsDevice.isWindowTranslucencySupported(PERPIXEL_TRANSLUCENT) returned true. The Apple J2SE 6 implementation did much the same thing. I believe Apple's JVM passed clicks through based on the painted alpha, rather than using the window shape, and that the Java 1.7.0_05 likely does not do this. Another difference is that the J2SE 7 API dropped the AWTUtilities.setWindowOpaque(boolean) method, and handles this automatically when the Window instance setBackground method is invoked with a non-opaque colour. I have set the background of the Window to new Color(0, 0, 0, 0), so I don't believe that this is the issue. Is this something that is still in progress, or am I missing something? This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. From weijun.wang at oracle.com Mon Jul 16 20:32:40 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 17 Jul 2012 11:32:40 +0800 Subject: OpenJDK krb5 ignore /etc/krb5.conf? In-Reply-To: <4FF55194.5050403@oracle.com> References: <4FF55194.5050403@oracle.com> Message-ID: <5004DCD8.6080805@oracle.com> Ping again. On 07/05/2012 04:34 PM, Weijun Wang wrote: > Hi Scott > > On Mac since Lion, sun.security.krb5.Config tries to locate the config > info in this order: > > 1. java.security.krb5.conf system property > 2. ${jre}/lib/security/krb5.conf > 3. SCDynamicStoreConfig > > The main difference from other platforms is that it will not try config > files, say, /Library/Preferences/edu.mit.Kerberos or /etc/krb5.conf. > > On the other hand, even /usr/bin/kinit comes with Lion reads the config > file (if there is no SCDynamicStoreConfig setting). > > Is there a special reason for the current Java behavior? I do notice > that the Apple 6u33 already does this. > > Thanks > Max From alexandr.scherbatiy at oracle.com Tue Jul 17 07:34:00 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 17 Jul 2012 18:34:00 +0400 Subject: [8] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 Message-ID: <500577D8.9050609@oracle.com> Hi, Please review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.00/ There are 2 fixed problems: - GraphicsDevice can have display mode which has non zero refresh rate. In this case the getBestModeForParameters method from the CGraphicsDevice.m class should return appropriate display mode even if the requested refresh rate is zero. - The original DisplayMode should be restored after exiting from the Full Screen mode. Thanks, Alexandr. From swingler at apple.com Tue Jul 17 07:35:02 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 17 Jul 2012 07:35:02 -0700 Subject: OpenJDK krb5 ignore /etc/krb5.conf? In-Reply-To: <5004DCD8.6080805@oracle.com> References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> Message-ID: On Jul 16, 2012, at 8:32 PM, Weijun Wang wrote: > Ping again. > > On 07/05/2012 04:34 PM, Weijun Wang wrote: >> Hi Scott >> >> On Mac since Lion, sun.security.krb5.Config tries to locate the config >> info in this order: >> >> 1. java.security.krb5.conf system property >> 2. ${jre}/lib/security/krb5.conf >> 3. SCDynamicStoreConfig >> >> The main difference from other platforms is that it will not try config >> files, say, /Library/Preferences/edu.mit.Kerberos or /etc/krb5.conf. >> >> On the other hand, even /usr/bin/kinit comes with Lion reads the config >> file (if there is no SCDynamicStoreConfig setting). >> >> Is there a special reason for the current Java behavior? I do notice >> that the Apple 6u33 already does this. No special reason I can think of, beyond simply swapping the implementation to read from the SCDynamicStoreConfig. Java SE 6 had previously had been relying on the system to write out a /Library/Preferences/edu.mit.Kerberos file, but that went away with OS X 10.7, so we didn't see much point in reading the file, since little else on the system would be paying attention to it either for the purposes of SSO. It seems perfectly reasonable that if there are no SCDynamicStoreConfig entries, falling back to reading the legacy config files may be a valid option. I'm actually somewhat surprised that they are consulted by kinit. Regards, Mike Swingler Apple Inc. From alexander.zuev at oracle.com Tue Jul 17 09:27:59 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 17 Jul 2012 20:27:59 +0400 Subject: [7u6] Please review my fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) Message-ID: <5005928F.3040500@oracle.com> Hello, please review my fix 7177144: [macosx] Drag and drop not working (regression in 7u6) CR description can be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 Webrev with the proposed change can be seen here: http://cr.openjdk.java.net/~kizune/7177144/webrev.00 This fix affects all platforms but due to the fix nature it shouldn't cause any regressions. The idea of the fix is to prevent Drag and Drop events from coalescing because it may cause hangup due to the synchronous nature of this type of events. With best regards, Alex From oleg.pekhovskiy at oracle.com Tue Jul 17 09:34:00 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Tue, 17 Jul 2012 20:34:00 +0400 Subject: [7u6] Please review my fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <5005928F.3040500@oracle.com> References: <5005928F.3040500@oracle.com> Message-ID: <500593F8.8040800@oracle.com> looks fine. Maybe 'cache' would be better than 'queue' in this context: // Do not queue SunDropTargetEvent, they should not coalesce Thanks, Oleg 7/17/2012 8:27 PM, Alexander Zuev wrote: > Hello, > > please review my fix 7177144: [macosx] Drag and drop not working > (regression in 7u6) > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7177144/webrev.00 > > This fix affects all platforms but due to the fix nature it > shouldn't cause any regressions. The idea of the fix is to prevent > Drag and Drop events from coalescing because it may cause hangup due > to the synchronous nature of this type of events. > > With best regards, > Alex From victor.dyakov at oracle.com Tue Jul 17 09:42:57 2012 From: victor.dyakov at oracle.com (Victor Dyakov) Date: Tue, 17 Jul 2012 20:42:57 +0400 Subject: [7u6] Please review my fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <5005928F.3040500@oracle.com> References: <5005928F.3040500@oracle.com> Message-ID: <50059611.70400@oracle.com> This is HIGH Priority P1 issue. Could you please review it ASAP (but carefully) Thanks, Victor On 17.07.2012 20:27, Alexander Zuev wrote: > Hello, > > please review my fix 7177144: [macosx] Drag and drop not working > (regression in 7u6) > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7177144/webrev.00 > > This fix affects all platforms but due to the fix nature it > shouldn't cause any regressions. The idea of the fix is to prevent > Drag and Drop events from coalescing because it may cause hangup due > to the synchronous nature of this type of events. > > With best regards, > Alex From alexander.zuev at oracle.com Tue Jul 17 09:48:14 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 17 Jul 2012 20:48:14 +0400 Subject: [8] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 In-Reply-To: <500577D8.9050609@oracle.com> References: <500577D8.9050609@oracle.com> Message-ID: <5005974E.3010908@oracle.com> Alexander, couple of notes: - where is the code that throws IllegalArgumentException in case of no matching display mode found? - similar way we have to add check that throws an exception when someone tries to set display mode when it's not allowed. - the check for dcSupported here: ! if (originalMode != null) { ! if (dcSupported) { ! setDisplayMode(originalMode); ! } ! originalMode = null; } + } is not needed - later we check for it when we assign originalMode so if originalMode is set to non-null value then resolution change is allowed. With best regards, Alex On 7/17/12 18:34, Alexander Scherbatiy wrote: > > Hi, > > Please review the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 > webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.00/ > > > There are 2 fixed problems: > - GraphicsDevice can have display mode which has non zero refresh rate. > In this case the getBestModeForParameters method from the > CGraphicsDevice.m class should > return appropriate display mode even if the requested refresh rate > is zero. > > - The original DisplayMode should be restored after exiting from the > Full Screen mode. > > > Thanks, > Alexandr. > From Doug.Zwick at blackboard.com Tue Jul 17 14:53:22 2012 From: Doug.Zwick at blackboard.com (Doug Zwick) Date: Tue, 17 Jul 2012 17:53:22 -0400 Subject: Translucent/Shaped Windows In-Reply-To: References: Message-ID: > What is the current status of the Translucent/Shaped Windows API in the OS X port? I am updating some code using the old Java 1.6 temporary API to use the final 1.7 API, and the window is not passing mouse clicks through properly (the Apple 1.6 JRE did pass clicks through). I am running with 1.7.0_05. I did notice that calls to Window.setShape throw an exception: > > java.lang.UnsupportedOperationException: PERPIXEL_TRANSPARENT translucency is not supported. > > However, GraphicsDevice.isWindowTranslucencySupported(PERPIXEL_TRANSLUCENT) returned true. The Apple J2SE 6 implementation did much the same thing. I believe Apple's JVM passed clicks through based on the painted alpha, rather than using the window shape, and that the Java 1.7.0_05 likely does not do this. Another difference is that the J2SE 7 API dropped the AWTUtilities.setWindowOpaque(boolean) method, and handles this automatically when the Window instance setBackground method is invoked with a non-opaque colour. I have set the background of the Window to new Color(0, 0, 0, 0), so I don't believe that this is the issue. I can confirm that the code works correctly (the shaped window passes clicks through as expected) on Windows under Java 1.7.0_05. The problem still exists in the current Mac EA for update 6 (1.7.0_06-ea-b19). Should I enter a bug report? Is bugs.sun.com still the right place, or is there an Oracle or OpenJDK bug database these days? I think there are two bugs here -- that the transparent window does not pass clicks, and that Window.setShape throws when isWindowTranslucencySupported says it should work. Do you have a preference on how I enter them? This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. From weijun.wang at oracle.com Tue Jul 17 17:26:10 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 18 Jul 2012 08:26:10 +0800 Subject: OpenJDK krb5 ignore /etc/krb5.conf? In-Reply-To: References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> Message-ID: <500602A2.9070803@oracle.com> I'm not familiar with how Mac does it, but normally there are two ways a Kerberos authentication is performed, through the initial login and through kinit. The former is integrated into the system (a pam module?) and I guess in this case the config is inside SCDynamicStoreConfig. For the latter, the Kerberos clients are regarded as standalone tools and a /etc/krb5.conf is needed. Java works in both ways, if there is already a credentials cache it will happily use it. On the other hand, it also includes the Krb5LoginModule that does all the login itself. Therefore, it should read both styles of config on a Mac. I've filed a new bug, It will appear soon at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184815 Thanks Max On 07/17/2012 10:35 PM, Mike Swingler wrote: > On Jul 16, 2012, at 8:32 PM, Weijun Wang wrote: > >> Ping again. >> >> On 07/05/2012 04:34 PM, Weijun Wang wrote: >>> Hi Scott >>> >>> On Mac since Lion, sun.security.krb5.Config tries to locate the config >>> info in this order: >>> >>> 1. java.security.krb5.conf system property >>> 2. ${jre}/lib/security/krb5.conf >>> 3. SCDynamicStoreConfig >>> >>> The main difference from other platforms is that it will not try config >>> files, say, /Library/Preferences/edu.mit.Kerberos or /etc/krb5.conf. >>> >>> On the other hand, even /usr/bin/kinit comes with Lion reads the config >>> file (if there is no SCDynamicStoreConfig setting). >>> >>> Is there a special reason for the current Java behavior? I do notice >>> that the Apple 6u33 already does this. > > No special reason I can think of, beyond simply swapping the implementation to read from the SCDynamicStoreConfig. Java SE 6 had previously had been relying on the system to write out a /Library/Preferences/edu.mit.Kerberos file, but that went away with OS X 10.7, so we didn't see much point in reading the file, since little else on the system would be paying attention to it either for the purposes of SSO. > > It seems perfectly reasonable that if there are no SCDynamicStoreConfig entries, falling back to reading the legacy config files may be a valid option. I'm actually somewhat surprised that they are consulted by kinit. > > Regards, > Mike Swingler > Apple Inc. > From weijun.wang at oracle.com Tue Jul 17 23:29:19 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 18 Jul 2012 14:29:19 +0800 Subject: code review request: 7184815 (was Re: OpenJDK krb5 ignore /etc/krb5.conf?) In-Reply-To: <500602A2.9070803@oracle.com> References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> <500602A2.9070803@oracle.com> Message-ID: <500657BF.3020107@oracle.com> 7184815: [macosx] Need to read Kerberos config in files Please take a review: http://cr.openjdk.java.net/~weijun/7184815/webrev.00/ I break the config setting to Java setting and native setting, and insert the reading of SCDynamicStoreConfig between the two. This should preserve the 6u behavior and add a fallback to legacy config files. No new regression test, because of SCDynamicStoreConfig and system config files, will ask SQE to create a manual test. Thanks Max On 07/18/2012 08:26 AM, Weijun Wang wrote: > I'm not familiar with how Mac does it, but normally there are two ways a > Kerberos authentication is performed, through the initial login and > through kinit. The former is integrated into the system (a pam module?) > and I guess in this case the config is inside SCDynamicStoreConfig. For > the latter, the Kerberos clients are regarded as standalone tools and a > /etc/krb5.conf is needed. > > Java works in both ways, if there is already a credentials cache it will > happily use it. On the other hand, it also includes the Krb5LoginModule > that does all the login itself. Therefore, it should read both styles of > config on a Mac. > > I've filed a new bug, It will appear soon at > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184815 > > Thanks > Max > > > On 07/17/2012 10:35 PM, Mike Swingler wrote: >> On Jul 16, 2012, at 8:32 PM, Weijun Wang wrote: >> >>> Ping again. >>> >>> On 07/05/2012 04:34 PM, Weijun Wang wrote: >>>> Hi Scott >>>> >>>> On Mac since Lion, sun.security.krb5.Config tries to locate the config >>>> info in this order: >>>> >>>> 1. java.security.krb5.conf system property >>>> 2. ${jre}/lib/security/krb5.conf >>>> 3. SCDynamicStoreConfig >>>> >>>> The main difference from other platforms is that it will not try config >>>> files, say, /Library/Preferences/edu.mit.Kerberos or /etc/krb5.conf. >>>> >>>> On the other hand, even /usr/bin/kinit comes with Lion reads the config >>>> file (if there is no SCDynamicStoreConfig setting). >>>> >>>> Is there a special reason for the current Java behavior? I do notice >>>> that the Apple 6u33 already does this. >> >> No special reason I can think of, beyond simply swapping the >> implementation to read from the SCDynamicStoreConfig. Java SE 6 had >> previously had been relying on the system to write out a >> /Library/Preferences/edu.mit.Kerberos file, but that went away with OS >> X 10.7, so we didn't see much point in reading the file, since little >> else on the system would be paying attention to it either for the >> purposes of SSO. >> >> It seems perfectly reasonable that if there are no >> SCDynamicStoreConfig entries, falling back to reading the legacy >> config files may be a valid option. I'm actually somewhat surprised >> that they are consulted by kinit. >> >> Regards, >> Mike Swingler >> Apple Inc. >> > From alexandr.scherbatiy at oracle.com Wed Jul 18 03:53:46 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 18 Jul 2012 14:53:46 +0400 Subject: [8] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 In-Reply-To: <5005974E.3010908@oracle.com> References: <500577D8.9050609@oracle.com> <5005974E.3010908@oracle.com> Message-ID: <500695BA.4010309@oracle.com> Could you review the updated version of the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.02/ - IllegalArgumentException now is thrown in case if matching display mode is not found - Extra display change support is removed Thanks, Alexandr. On 7/17/2012 8:48 PM, Alexander Zuev wrote: > Alexander, > > couple of notes: > > - where is the code that throws IllegalArgumentException in case of > no matching display mode found? > - similar way we have to add check that throws an exception when > someone tries to set display mode > when it's not allowed. > - the check for dcSupported here: > ! if (originalMode != null) { > ! if (dcSupported) { > ! setDisplayMode(originalMode); > ! } > ! originalMode = null; > } > + } > > is not needed - later we check for it when we assign originalMode so > if originalMode is set to non-null value then > resolution change is allowed. > > With best regards, > Alex > > > On 7/17/12 18:34, Alexander Scherbatiy wrote: >> >> Hi, >> >> Please review the fix: >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 >> webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.00/ >> >> >> There are 2 fixed problems: >> - GraphicsDevice can have display mode which has non zero refresh rate. >> In this case the getBestModeForParameters method from the >> CGraphicsDevice.m class should >> return appropriate display mode even if the requested refresh rate >> is zero. >> >> - The original DisplayMode should be restored after exiting from the >> Full Screen mode. >> >> >> Thanks, >> Alexandr. >> > > From andrew.brygin at oracle.com Wed Jul 18 04:26:26 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Wed, 18 Jul 2012 15:26:26 +0400 Subject: [8] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 In-Reply-To: <500695BA.4010309@oracle.com> References: <500577D8.9050609@oracle.com> <5005974E.3010908@oracle.com> <500695BA.4010309@oracle.com> Message-ID: <50069D62.2040402@oracle.com> Hello Alexandr, the fix looks fine to me. Thanks, Andrew On 18.07.2012 14:53, Alexander Scherbatiy wrote: > > > Could you review the updated version of the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 > webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.02/ > > - IllegalArgumentException now is thrown in case if matching display > mode is not found > - Extra display change support is removed > > Thanks, > Alexandr. > > > On 7/17/2012 8:48 PM, Alexander Zuev wrote: >> Alexander, >> >> couple of notes: >> >> - where is the code that throws IllegalArgumentException in case of >> no matching display mode found? >> - similar way we have to add check that throws an exception when >> someone tries to set display mode >> when it's not allowed. >> - the check for dcSupported here: >> ! if (originalMode != null) { >> ! if (dcSupported) { >> ! setDisplayMode(originalMode); >> ! } >> ! originalMode = null; >> } >> + } >> >> is not needed - later we check for it when we assign originalMode so >> if originalMode is set to non-null value then >> resolution change is allowed. >> >> With best regards, >> Alex >> >> >> On 7/17/12 18:34, Alexander Scherbatiy wrote: >>> >>> Hi, >>> >>> Please review the fix: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 >>> webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.00/ >>> >>> >>> There are 2 fixed problems: >>> - GraphicsDevice can have display mode which has non zero refresh rate. >>> In this case the getBestModeForParameters method from the >>> CGraphicsDevice.m class should >>> return appropriate display mode even if the requested refresh rate >>> is zero. >>> >>> - The original DisplayMode should be restored after exiting from the >>> Full Screen mode. >>> >>> >>> Thanks, >>> Alexandr. >>> >> >> > From alexander.zuev at oracle.com Wed Jul 18 05:14:33 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 18 Jul 2012 16:14:33 +0400 Subject: [8] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 In-Reply-To: <500695BA.4010309@oracle.com> References: <500577D8.9050609@oracle.com> <5005974E.3010908@oracle.com> <500695BA.4010309@oracle.com> Message-ID: <5006A8A9.4030501@oracle.com> Looks good to me. On 7/18/12 14:53, Alexander Scherbatiy wrote: > > > Could you review the updated version of the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 > webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.02/ > > - IllegalArgumentException now is thrown in case if matching display > mode is not found > - Extra display change support is removed > > Thanks, > Alexandr. > > > On 7/17/2012 8:48 PM, Alexander Zuev wrote: >> Alexander, >> >> couple of notes: >> >> - where is the code that throws IllegalArgumentException in case of >> no matching display mode found? >> - similar way we have to add check that throws an exception when >> someone tries to set display mode >> when it's not allowed. >> - the check for dcSupported here: >> ! if (originalMode != null) { >> ! if (dcSupported) { >> ! setDisplayMode(originalMode); >> ! } >> ! originalMode = null; >> } >> + } >> >> is not needed - later we check for it when we assign originalMode so >> if originalMode is set to non-null value then >> resolution change is allowed. >> >> With best regards, >> Alex >> >> >> On 7/17/12 18:34, Alexander Scherbatiy wrote: >>> >>> Hi, >>> >>> Please review the fix: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 >>> webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.00/ >>> >>> >>> There are 2 fixed problems: >>> - GraphicsDevice can have display mode which has non zero refresh rate. >>> In this case the getBestModeForParameters method from the >>> CGraphicsDevice.m class should >>> return appropriate display mode even if the requested refresh rate >>> is zero. >>> >>> - The original DisplayMode should be restored after exiting from the >>> Full Screen mode. >>> >>> >>> Thanks, >>> Alexandr. >>> >> >> > From alexandr.scherbatiy at oracle.com Wed Jul 18 05:31:16 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 18 Jul 2012 16:31:16 +0400 Subject: [7u6] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 Message-ID: <5006AC94.3010706@oracle.com> Please review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev7u6.00/ This is a backported fix from the JDK 8 to JDK 7u6. There are 3 fixed problems: - GraphicsDevice can have display mode which has non zero refresh rate. In this case the getBestModeForParameters method from the CGraphicsDevice.m class should return appropriate display mode even if the requested refresh rate is zero. - The original DisplayMode should be restored after exiting from the Full Screen mode. - IllegalArgumentException should be thrown in case if matching display mode is not found Thanks, Alexandr. From andrew.brygin at oracle.com Wed Jul 18 06:12:22 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Wed, 18 Jul 2012 17:12:22 +0400 Subject: [7u6] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 In-Reply-To: <5006AC94.3010706@oracle.com> References: <5006AC94.3010706@oracle.com> Message-ID: <5006B636.3050003@oracle.com> Hello Alexander, the fix looks fine to me. Thanks, Andrew On 18.07.2012 16:31, Alexander Scherbatiy wrote: > > Please review the fix: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 > webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev7u6.00/ > > > This is a backported fix from the JDK 8 to JDK 7u6. > > There are 3 fixed problems: > - GraphicsDevice can have display mode which has non zero refresh rate. > In this case the getBestModeForParameters method from the > CGraphicsDevice.m class should > return appropriate display mode even if the requested refresh rate > is zero. > > - The original DisplayMode should be restored after exiting from the > Full Screen mode. > > - IllegalArgumentException should be thrown in case if matching > display mode is not found > > > Thanks, > Alexandr. > From alexander.zuev at oracle.com Wed Jul 18 06:42:07 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 18 Jul 2012 17:42:07 +0400 Subject: [7u6] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 In-Reply-To: <5006AC94.3010706@oracle.com> References: <5006AC94.3010706@oracle.com> Message-ID: <5006BD2F.9050203@oracle.com> Looks fine to me. On 7/18/12 16:31, Alexander Scherbatiy wrote: > > Please review the fix: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 > webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev7u6.00/ > > > This is a backported fix from the JDK 8 to JDK 7u6. > > There are 3 fixed problems: > - GraphicsDevice can have display mode which has non zero refresh rate. > In this case the getBestModeForParameters method from the > CGraphicsDevice.m class should > return appropriate display mode even if the requested refresh rate > is zero. > > - The original DisplayMode should be restored after exiting from the > Full Screen mode. > > - IllegalArgumentException should be thrown in case if matching > display mode is not found > > > Thanks, > Alexandr. > From artem.ananiev at oracle.com Thu Jul 19 05:18:12 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 19 Jul 2012 16:18:12 +0400 Subject: [7u6] Please review my fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <5005928F.3040500@oracle.com> References: <5005928F.3040500@oracle.com> Message-ID: <5007FB04.7040802@oracle.com> Hi, Alex, you put the check to EventQueue.cacheEQItem(), which doesn't look right. coalesceEvent() is the correct place, isn't it? Thanks, Artem On 7/17/2012 8:27 PM, Alexander Zuev wrote: > Hello, > > please review my fix 7177144: [macosx] Drag and drop not working > (regression in 7u6) > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7177144/webrev.00 > > This fix affects all platforms but due to the fix nature it shouldn't > cause any regressions. The idea of the fix is to prevent Drag and Drop > events from coalescing because it may cause hangup due to the > synchronous nature of this type of events. > > With best regards, > Alex From alexander.zuev at oracle.com Thu Jul 19 06:05:56 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 19 Jul 2012 17:05:56 +0400 Subject: [7u6] Please review my fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <5007FB04.7040802@oracle.com> References: <5005928F.3040500@oracle.com> <5007FB04.7040802@oracle.com> Message-ID: <50080634.8040607@oracle.com> Artem, you are right. Kind of. We have to check in both places so you can find my updated webrev at http://cr.openjdk.java.net/~kizune/7177144/webrev.01 With best regards, Alex On 7/19/12 16:18, Artem Ananiev wrote: > Hi, Alex, > > you put the check to EventQueue.cacheEQItem(), which doesn't look > right. coalesceEvent() is the correct place, isn't it? > > Thanks, > > Artem > > On 7/17/2012 8:27 PM, Alexander Zuev wrote: >> Hello, >> >> please review my fix 7177144: [macosx] Drag and drop not working >> (regression in 7u6) >> CR description can be found here: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 >> >> Webrev with the proposed change can be seen here: >> http://cr.openjdk.java.net/~kizune/7177144/webrev.00 >> >> This fix affects all platforms but due to the fix nature it shouldn't >> cause any regressions. The idea of the fix is to prevent Drag and Drop >> events from coalescing because it may cause hangup due to the >> synchronous nature of this type of events. >> >> With best regards, >> Alex From oleg.pekhovskiy at oracle.com Thu Jul 19 06:04:02 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 19 Jul 2012 17:04:02 +0400 Subject: [7u6] Please review my fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <50080634.8040607@oracle.com> References: <5005928F.3040500@oracle.com> <5007FB04.7040802@oracle.com> <50080634.8040607@oracle.com> Message-ID: <500805C2.2000108@oracle.com> Looks fine. Oleg. 7/19/2012 5:05 PM, Alexander Zuev wrote: > Artem, > > you are right. Kind of. We have to check in both places so you can > find my updated webrev at > http://cr.openjdk.java.net/~kizune/7177144/webrev.01 > > With best regards, > Alex > > On 7/19/12 16:18, Artem Ananiev wrote: >> Hi, Alex, >> >> you put the check to EventQueue.cacheEQItem(), which doesn't look >> right. coalesceEvent() is the correct place, isn't it? >> >> Thanks, >> >> Artem >> >> On 7/17/2012 8:27 PM, Alexander Zuev wrote: >>> Hello, >>> >>> please review my fix 7177144: [macosx] Drag and drop not working >>> (regression in 7u6) >>> CR description can be found here: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 >>> >>> Webrev with the proposed change can be seen here: >>> http://cr.openjdk.java.net/~kizune/7177144/webrev.00 >>> >>> This fix affects all platforms but due to the fix nature it shouldn't >>> cause any regressions. The idea of the fix is to prevent Drag and Drop >>> events from coalescing because it may cause hangup due to the >>> synchronous nature of this type of events. >>> >>> With best regards, >>> Alex > > From artem.ananiev at oracle.com Thu Jul 19 06:30:47 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 19 Jul 2012 17:30:47 +0400 Subject: [7u6] Please review my fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <50080634.8040607@oracle.com> References: <5005928F.3040500@oracle.com> <5007FB04.7040802@oracle.com> <50080634.8040607@oracle.com> Message-ID: <50080C07.1050807@oracle.com> The fix now looks fine. Thanks, Artem On 7/19/2012 5:05 PM, Alexander Zuev wrote: > Artem, > > you are right. Kind of. We have to check in both places so you can find > my updated webrev at > http://cr.openjdk.java.net/~kizune/7177144/webrev.01 > > With best regards, > Alex > > On 7/19/12 16:18, Artem Ananiev wrote: >> Hi, Alex, >> >> you put the check to EventQueue.cacheEQItem(), which doesn't look >> right. coalesceEvent() is the correct place, isn't it? >> >> Thanks, >> >> Artem >> >> On 7/17/2012 8:27 PM, Alexander Zuev wrote: >>> Hello, >>> >>> please review my fix 7177144: [macosx] Drag and drop not working >>> (regression in 7u6) >>> CR description can be found here: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 >>> >>> Webrev with the proposed change can be seen here: >>> http://cr.openjdk.java.net/~kizune/7177144/webrev.00 >>> >>> This fix affects all platforms but due to the fix nature it shouldn't >>> cause any regressions. The idea of the fix is to prevent Drag and Drop >>> events from coalescing because it may cause hangup due to the >>> synchronous nature of this type of events. >>> >>> With best regards, >>> Alex > > From Sergey.Bylokhov at oracle.com Thu Jul 19 06:30:35 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 19 Jul 2012 17:30:35 +0400 Subject: [7u6] Please review my fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <50080634.8040607@oracle.com> References: <5005928F.3040500@oracle.com> <5007FB04.7040802@oracle.com> <50080634.8040607@oracle.com> Message-ID: <50080BFB.80600@oracle.com> 19.07.2012 17:05, Alexander Zuev wrote: > Artem, > > you are right. Kind of. We have to check in both places so you can > find my updated webrev at > http://cr.openjdk.java.net/~kizune/7177144/webrev.01 Probably we can move new code to coalesceEvent and just never call coalesceMouseEvent??? Or just move this code to postEvent()? > > With best regards, > Alex > > On 7/19/12 16:18, Artem Ananiev wrote: >> Hi, Alex, >> >> you put the check to EventQueue.cacheEQItem(), which doesn't look >> right. coalesceEvent() is the correct place, isn't it? >> >> Thanks, >> >> Artem >> >> On 7/17/2012 8:27 PM, Alexander Zuev wrote: >>> Hello, >>> >>> please review my fix 7177144: [macosx] Drag and drop not working >>> (regression in 7u6) >>> CR description can be found here: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 >>> >>> Webrev with the proposed change can be seen here: >>> http://cr.openjdk.java.net/~kizune/7177144/webrev.00 >>> >>> This fix affects all platforms but due to the fix nature it shouldn't >>> cause any regressions. The idea of the fix is to prevent Drag and Drop >>> events from coalescing because it may cause hangup due to the >>> synchronous nature of this type of events. >>> >>> With best regards, >>> Alex > > -- Best regards, Sergey. From artem.ananiev at oracle.com Thu Jul 19 06:39:29 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 19 Jul 2012 17:39:29 +0400 Subject: Translucent/Shaped Windows In-Reply-To: References: Message-ID: <50080E11.8060303@oracle.com> Hi, Doug, thanks for digging this up. We've already have a number of bugs related to java.awt.Window shapes support on Mac, so please don't file new ones before making sure they are not duplicates. Whether the fixes will be integrated to 7u6 or postponed until 7u8 is an open question. 7u6 development is in the final phase, and only critical fixes are accepted. Could you wait until 7u6 is released and check if your problems are still there, please? Another thing you could check is to try JDK8. The fix for 7124244 should be there in a few weeks. Thanks, Artem On 7/18/2012 1:53 AM, Doug Zwick wrote: >> What is the current status of the Translucent/Shaped Windows API in >> the OS X port? I am updating some code using the old Java 1.6 >> temporary API to use the final 1.7 API, and the window is not >> passing mouse clicks through properly (the Apple 1.6 JRE did pass >> clicks through). I am running with 1.7.0_05. I did notice that >> calls to Window.setShape throw an exception: >> >> java.lang.UnsupportedOperationException: PERPIXEL_TRANSPARENT >> translucency is not supported. >> >> However, >> GraphicsDevice.isWindowTranslucencySupported(PERPIXEL_TRANSLUCENT) >> returned true. The Apple J2SE 6 implementation did much the same >> thing. I believe Apple's JVM passed clicks through based on the >> painted alpha, rather than using the window shape, and that the >> Java 1.7.0_05 likely does not do this. Another difference is that >> the J2SE 7 API dropped the AWTUtilities.setWindowOpaque(boolean) >> method, and handles this automatically when the Window instance >> setBackground method is invoked with a non-opaque colour. I have >> set the background of the Window to new Color(0, 0, 0, 0), so I >> don't believe that this is the issue. > > I can confirm that the code works correctly (the shaped window passes > clicks through as expected) on Windows under Java 1.7.0_05. The > problem still exists in the current Mac EA for update 6 > (1.7.0_06-ea-b19). Should I enter a bug report? Is bugs.sun.com still > the right place, or is there an Oracle or OpenJDK bug database these > days? I think there are two bugs here -- that the transparent window > does not pass clicks, and that Window.setShape throws when > isWindowTranslucencySupported says it should work. Do you have a > preference on how I enter them? > > This email and any attachments may contain confidential and > proprietary information of Blackboard that is for the sole use of the > intended recipient. If you are not the intended recipient, > disclosure, copying, re-distribution or other use of any of this > information is strictly prohibited. Please immediately notify the > sender and delete this transmission if you received this email in > error. From alexander.zuev at oracle.com Thu Jul 19 06:40:00 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 19 Jul 2012 17:40:00 +0400 Subject: [7u6] Please review my fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <50080BFB.80600@oracle.com> References: <5005928F.3040500@oracle.com> <5007FB04.7040802@oracle.com> <50080634.8040607@oracle.com> <50080BFB.80600@oracle.com> Message-ID: <50080E30.4030305@oracle.com> On 7/19/12 17:30, Sergey Bylokhov wrote: > Probably we can move new code to coalesceEvent and just never call > coalesceMouseEvent??? Or just move this code to postEvent()? I will rethink the fix for jdk8 but for 7u6 i'll go with the fix as it is now. From Doug.Zwick at blackboard.com Thu Jul 19 09:03:30 2012 From: Doug.Zwick at blackboard.com (Doug Zwick) Date: Thu, 19 Jul 2012 12:03:30 -0400 Subject: Translucent/Shaped Windows In-Reply-To: <50080E11.8060303@oracle.com> References: <50080E11.8060303@oracle.com> Message-ID: <49BA5064-C1B8-4353-8760-6AC879DBC199@blackboard.com> On 2012-07-19, at 7:39 AM, Artem Ananiev wrote: > thanks for digging this up. We've already have a number of bugs related > to java.awt.Window shapes support on Mac, so please don't file new ones > before making sure they are not duplicates. I searched for "Window.setShape", "setShape", "PERPIXEL_TRANSLUCENT", "translucency" and "translucent" keywords (and-ed with "Mac"). I found nothing, so I entered 7185105. I don't know why the bugs.sun.com search engine did not match 7124244. > Whether the fixes will be integrated to 7u6 or postponed until 7u8 is an > open question. 7u6 development is in the final phase, and only critical > fixes are accepted. Could you wait until 7u6 is released and check if > your problems are still there, please? > > Another thing you could check is to try JDK8. The fix for 7124244 should > be there in a few weeks. Thanks. I'll be off on another project by then, but I've left a note on our bug for our QA folks. This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. From jcpalmer at rochester.rr.com Fri Jul 20 08:42:32 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Fri, 20 Jul 2012 11:42:32 -0400 Subject: Please close bug 7168761; not a problem for a while; EOM Message-ID: <42F617FB-FA8E-44F2-99E1-1408C62B9401@rochester.rr.com> From jason.uh at oracle.com Fri Jul 20 17:05:24 2012 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 20 Jul 2012 17:05:24 -0700 Subject: [7u8] Request for review 7162111: change tests run in headless mode [macosx] Message-ID: <5009F244.9040609@oracle.com> This fix was for regression tests failing on Mac OS X on remotely executed environments. The changed tests now run in headless mode and have been taken off the Problem List. This is a backport of a recently reviewed changeset for JDK8, plus a few more tests that had been previously fixed for JDK8. Webrev: http://cr.openjdk.java.net/~juh/7162111/jdk7u-dev/webrev.00/ CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162111 [ For your reference, the previously reviewed JDK8 changeset: http://cr.openjdk.java.net/~juh/7162111/webrev.01/ ] Thanks, Jason From dkocher at sudo.ch Mon Jul 23 00:55:52 2012 From: dkocher at sudo.ch (David Kocher) Date: Mon, 23 Jul 2012 09:55:52 +0200 Subject: Maintenance of issues In-Reply-To: <4FF20C62.7000904@oracle.com> References: <06E7EED5-B02A-4061-BDF3-8DB68ECD7ECD@sudo.ch> <4FF2052D.6040403@oracle.com> <4FF20C62.7000904@oracle.com> Message-ID: <1DADA36A-FF77-49F3-BEBA-035251E9D8D6@sudo.ch> Any update on this migration path? Someone responsible should really link the JIRA issues to the bugs.sun.com bugtracker because bugs just can't be found there. People still report and comment issues on JIRA with no feedback. -- David On 02.07.2012, at 23:02, Phil Race wrote: > > Adding to this .. > I believe that at the time we transitioned all unresolved bugs > were shadowed at bugs.sun.com, and that many of those are also since fixed .. > > Who can make changes to > 1) edit that main page, but we should post a comment there that > this is now "historic" data, for reference only, > > 2) Prevent creation of new bugs in that JIRA instance ? > > One issue with posting comments on bugs at bugs.sun.com is that > the comments do not become part of the bug database, and aren't (any more) > notified via email to the RE, so they are sadly mostly wasted. Only people > who navigate to that bug page on bugs.sun.com will ever see them. > > -phil. > > On 7/2/2012 1:31 PM, Anthony Petrov wrote: >> We don't use this JIRA project to track Mac port issues anymore. Please post comments/file bugs on http://bugs.sun.com. >> >> -- >> best regards, >> Anthony >> >> On 7/3/2012 12:13 AM, David Kocher wrote: >>> Asked differently then, is it even worth posting comments to JIRA? >>> >>> -- David >>> >>> On 25.06.2012, at 09:20, David Kocher wrote: >>> >>>> Contrary to the activity on this list and references to bugs.sun.com, I see no significant activity in the bug tracker [1] I follow. Do the issues listed there get updated and is this even relevant anymore or has everything moved to bugs.sun.com? >>>> >>>> -- David >>>> >>>>> http://java.net/jira/browse/MACOSX_PORT >>> > From dkocher at sudo.ch Mon Jul 23 00:56:04 2012 From: dkocher at sudo.ch (David Kocher) Date: Mon, 23 Jul 2012 09:56:04 +0200 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> Message-ID: I really would appreciate an answer here and a possible resolution to backport this fix. Others are having the same issue [1] and are posting to the non maintained JIRA issue tracker. -- David [1] http://java.net/jira/browse/MACOSX_PORT-165 On 04.07.2012, at 18:40, David Kocher wrote: > Is there a corresponding ticket in bugs.sun.com that allows to track this issue? > > -- David > > On 27.06.2012, at 09:28, David Kocher wrote: > >> I welcome this issue is getting some serious attention then. When will this be backported to 7u? >> >> -- David >> >> On 24.06.2012, at 18:58, Xueming Shen wrote: >> >>> >>> Yes, I believe the issue described in MACOSX_PORT-165 is the >>> same issue this patch is trying to solve. >>> >>> Btw, it appears there are typos in the note(2), my mini keyboard obviously >>> is too sticky:-) >>> >>> (2) normalize the resulting file name from macosx fs APIs from nfd->nfc before passing >>> back to java.io.File (File.list() and canonicalize()), so we deal with nfc file name >>> (as "usual") for java.io classes/APIs. >>> >>> -sherman >>> >>> On 6/24/12 7:50 AM, David Kocher wrote: >>>> Will this address issue MACOSX_PORT-165 [1]? >>>> >>>> [1] http://java.net/jira/browse/MACOSX_PORT-165 >>>> >>>> -- David >>>> >>>> On 22.06.2012, at 19:01, Xueming Shen wrote: >>>> >>>>> Hi >>>>> >>>>> Here is the proposed change to support Unicode nfd/nfc and case insensitive >>>>> file path on MacOSX file system. >>>>> >>>>> 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X >>>>> 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] >>>>> >>>>> While these two bug reports are only against java.io, we have the same issue in javax.nio.file. >>>>> Here is the webrev >>>>> >>>>> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ >>>>> >>>>> Here is the brief summary of the changes >>>>> >>>>> java.io.File: >>>>> (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means >>>>> we are now passing nfc/composite characters directly into macosx file system APIs >>>>> without normalize them to nfd. It appears macosx fs APIs do take nfc, though it uses >>>>> nfd. >>>>> >>>>> (2) normalize the resulting file name from macosx fs APIs from nfd->nfd before passing >>>>> back to java.io.File (File.list() and canonicalize()), so we deal with nfdc file name >>>>> (as "usual") for java.io classes/APIs. >>>>> >>>>> (3) fs.compare()/hashCode() was updated to be case insensitive >>>>> >>>>> (4) hasCode() was updated to use the new String.hash32(). >>>>> >>>>> java.nio.file: >>>>> >>>>> (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An alternative is to >>>>> update those BsdFile... classes directly to address the macosx specific issues. But given >>>>> there might be developers over there might work on open jdk BSD port and have dependency >>>>> on these classes, it might be desirable to have another separate layer of MacOSXFile... >>>>> classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider and >>>>> MacOSXFileSystem. >>>>> >>>>> (6) the "main" changes are in MacOSXFileSystem, in which the corresponding methods >>>>> were added to handle, case insensitive and nfd<=>nfc normalization, including the >>>>> pathmatcher. >>>>> >>>>> (7) compare is now are case-insensitive >>>>> >>>>> (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and maxosx. >>>>> >>>>> >>>>> Though lots of files have been touched, but the line of changes are actually relatively >>>>> small. >>>>> >>>>> The proposed change only deals with the default case-sensitiveness seting, which is >>>>> case insensitive. On MaxOSX, you actually can configure the HFS+ file system or the >>>>> mounted vol to be case-sensitive. A possible approach is to have some extra FileStore >>>>> attributes, such as a isCaseSensitive and to use case sensitive compare/equal on >>>>> such fs, but this can be dealt with separately later. >>>>> >>>>> Thanks, >>>>> -Sherman >>>>> >>> >>> >> > From alexander.zuev at oracle.com Mon Jul 23 02:09:54 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 23 Jul 2012 13:09:54 +0400 Subject: [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) Message-ID: <500D14E2.6010107@oracle.com> Hello, please review my fix 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) CR description can be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 Webrev with the proposed change can be seen here: http://cr.openjdk.java.net/~kizune/7184951/webrev.00 The problem here lays somewhere deep in the Toolkit life cycle on Mac OS X - at the time we initialize datatransfer the Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later when we trying to use it it returns HeadlessToolkit. That's definitely wrong but at this stage it's too risky to fiddle with the life cycle itself so this is a hotfix that deals with the fallout of the actual error. The fix for jdk8 should be different. With best regards, Alex From artem.ananiev at oracle.com Mon Jul 23 03:41:33 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 23 Jul 2012 14:41:33 +0400 Subject: [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) In-Reply-To: <500D14E2.6010107@oracle.com> References: <500D14E2.6010107@oracle.com> Message-ID: <500D2A5D.4020602@oracle.com> Hi, Alex, (cross-posting to awt-dev) I see several other native methods in CDataTransferer, e.g. formatForIndex(). Could you confirm, they cannot be called in the headless mode, so there is no need to protect them with headless check, please? Could you also file a SubCR against JDK8 with the idea we discussed offline: create a new CHeadlessDataTransferer class to use in the headless mode instead of CDataTransferer + headless checks, please? Thanks, Artem On 7/23/2012 1:09 PM, Alexander Zuev wrote: > Hello, > > please review my fix 7184951: [macosx] Exception at > java.awt.datatransfer on headless mode (only in GUI session) > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7184951/webrev.00 > > The problem here lays somewhere deep in the Toolkit life cycle on > Mac OS X - at the time we initialize datatransfer the > Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later > when we trying to use it it returns HeadlessToolkit. That's definitely > wrong but at this stage it's too risky to fiddle with the life cycle > itself so this is a hotfix that deals with the fallout of the actual > error. The fix for jdk8 should be different. > > With best regards, > Alex From alexander.zuev at oracle.com Mon Jul 23 03:53:09 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 23 Jul 2012 14:53:09 +0400 Subject: [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) In-Reply-To: <500D2A5D.4020602@oracle.com> References: <500D14E2.6010107@oracle.com> <500D2A5D.4020602@oracle.com> Message-ID: <500D2D15.9070404@oracle.com> Artem, these native methods should not be called according to the logic of the class so we shouldn't safeguard them. I will create the sub-cr against the jdk8. WBR, Alex On 7/23/12 14:41, Artem Ananiev wrote: > Hi, Alex, > > (cross-posting to awt-dev) > > I see several other native methods in CDataTransferer, e.g. > formatForIndex(). Could you confirm, they cannot be called in the > headless mode, so there is no need to protect them with headless > check, please? > > Could you also file a SubCR against JDK8 with the idea we discussed > offline: create a new CHeadlessDataTransferer class to use in the > headless mode instead of CDataTransferer + headless checks, please? > > Thanks, > > Artem > > On 7/23/2012 1:09 PM, Alexander Zuev wrote: >> Hello, >> >> please review my fix 7184951: [macosx] Exception at >> java.awt.datatransfer on headless mode (only in GUI session) >> CR description can be found here: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 >> >> Webrev with the proposed change can be seen here: >> http://cr.openjdk.java.net/~kizune/7184951/webrev.00 >> >> The problem here lays somewhere deep in the Toolkit life cycle on >> Mac OS X - at the time we initialize datatransfer the >> Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later >> when we trying to use it it returns HeadlessToolkit. That's definitely >> wrong but at this stage it's too risky to fiddle with the life cycle >> itself so this is a hotfix that deals with the fallout of the actual >> error. The fix for jdk8 should be different. >> >> With best regards, >> Alex From artem.ananiev at oracle.com Mon Jul 23 06:19:45 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 23 Jul 2012 17:19:45 +0400 Subject: [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) In-Reply-To: <500D2D15.9070404@oracle.com> References: <500D14E2.6010107@oracle.com> <500D2A5D.4020602@oracle.com> <500D2D15.9070404@oracle.com> Message-ID: <500D4F71.6080902@oracle.com> On 7/23/2012 2:53 PM, Alexander Zuev wrote: > Artem, > > these native methods should not be called according to the logic of the > class so we shouldn't safeguard them. Could you elaborate on that, please? > I will create the sub-cr against the jdk8. Thanks! Artem > WBR, > Alex > > > > On 7/23/12 14:41, Artem Ananiev wrote: >> Hi, Alex, >> >> (cross-posting to awt-dev) >> >> I see several other native methods in CDataTransferer, e.g. >> formatForIndex(). Could you confirm, they cannot be called in the >> headless mode, so there is no need to protect them with headless >> check, please? >> >> Could you also file a SubCR against JDK8 with the idea we discussed >> offline: create a new CHeadlessDataTransferer class to use in the >> headless mode instead of CDataTransferer + headless checks, please? >> >> Thanks, >> >> Artem >> >> On 7/23/2012 1:09 PM, Alexander Zuev wrote: >>> Hello, >>> >>> please review my fix 7184951: [macosx] Exception at >>> java.awt.datatransfer on headless mode (only in GUI session) >>> CR description can be found here: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 >>> >>> Webrev with the proposed change can be seen here: >>> http://cr.openjdk.java.net/~kizune/7184951/webrev.00 >>> >>> The problem here lays somewhere deep in the Toolkit life cycle on >>> Mac OS X - at the time we initialize datatransfer the >>> Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later >>> when we trying to use it it returns HeadlessToolkit. That's definitely >>> wrong but at this stage it's too risky to fiddle with the life cycle >>> itself so this is a hotfix that deals with the fallout of the actual >>> error. The fix for jdk8 should be different. >>> >>> With best regards, >>> Alex > > From alexander.zuev at oracle.com Mon Jul 23 06:28:10 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 23 Jul 2012 17:28:10 +0400 Subject: [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) In-Reply-To: <500D4F71.6080902@oracle.com> References: <500D14E2.6010107@oracle.com> <500D2A5D.4020602@oracle.com> <500D2D15.9070404@oracle.com> <500D4F71.6080902@oracle.com> Message-ID: <500D516A.1060001@oracle.com> On 7/23/12 17:19, Artem Ananiev wrote: > > On 7/23/2012 2:53 PM, Alexander Zuev wrote: >> Artem, >> >> these native methods should not be called according to the logic of the >> class so we shouldn't safeguard them. > > Could you elaborate on that, please? Sure. The only native method that is not related to drag and drop functionality (which can not be instantiated in headless mode anyways) is private native String formatForIndex(long index); It is being called from the protected method getNativeForFormat(long format) which, in turn, being called by the drag-related methods or from public getters that check the index to be in the valid borders. Since we do not register any native-backed flavors in the set this native method will not be called in headless mode. > >> I will create the sub-cr against the jdk8. > > Thanks! > > Artem > >> WBR, >> Alex >> >> >> >> On 7/23/12 14:41, Artem Ananiev wrote: >>> Hi, Alex, >>> >>> (cross-posting to awt-dev) >>> >>> I see several other native methods in CDataTransferer, e.g. >>> formatForIndex(). Could you confirm, they cannot be called in the >>> headless mode, so there is no need to protect them with headless >>> check, please? >>> >>> Could you also file a SubCR against JDK8 with the idea we discussed >>> offline: create a new CHeadlessDataTransferer class to use in the >>> headless mode instead of CDataTransferer + headless checks, please? >>> >>> Thanks, >>> >>> Artem >>> >>> On 7/23/2012 1:09 PM, Alexander Zuev wrote: >>>> Hello, >>>> >>>> please review my fix 7184951: [macosx] Exception at >>>> java.awt.datatransfer on headless mode (only in GUI session) >>>> CR description can be found here: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 >>>> >>>> Webrev with the proposed change can be seen here: >>>> http://cr.openjdk.java.net/~kizune/7184951/webrev.00 >>>> >>>> The problem here lays somewhere deep in the Toolkit life cycle on >>>> Mac OS X - at the time we initialize datatransfer the >>>> Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later >>>> when we trying to use it it returns HeadlessToolkit. That's definitely >>>> wrong but at this stage it's too risky to fiddle with the life cycle >>>> itself so this is a hotfix that deals with the fallout of the actual >>>> error. The fix for jdk8 should be different. >>>> >>>> With best regards, >>>> Alex >> >> From Sergey.Bylokhov at oracle.com Mon Jul 23 07:53:12 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Jul 2012 18:53:12 +0400 Subject: [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) In-Reply-To: <500D516A.1060001@oracle.com> References: <500D14E2.6010107@oracle.com> <500D2A5D.4020602@oracle.com> <500D2D15.9070404@oracle.com> <500D4F71.6080902@oracle.com> <500D516A.1060001@oracle.com> Message-ID: <500D6558.3000301@oracle.com> Hi, Alexander. Fix looks good 23.07.2012 17:28, Alexander Zuev wrote: > On 7/23/12 17:19, Artem Ananiev wrote: >> >> On 7/23/2012 2:53 PM, Alexander Zuev wrote: >>> Artem, >>> >>> these native methods should not be called according to the logic of the >>> class so we shouldn't safeguard them. >> >> Could you elaborate on that, please? > Sure. The only native method that is not related to drag and drop > functionality > (which can not be instantiated in headless mode anyways) is private > native String formatForIndex(long index); > It is being called from the protected method getNativeForFormat(long > format) which, in turn, being called > by the drag-related methods or from public getters that check the > index to be in the valid borders. > Since we do not register any native-backed flavors in the set this > native method will not be called in headless mode. >> >>> I will create the sub-cr against the jdk8. >> >> Thanks! >> >> Artem >> >>> WBR, >>> Alex >>> >>> >>> >>> On 7/23/12 14:41, Artem Ananiev wrote: >>>> Hi, Alex, >>>> >>>> (cross-posting to awt-dev) >>>> >>>> I see several other native methods in CDataTransferer, e.g. >>>> formatForIndex(). Could you confirm, they cannot be called in the >>>> headless mode, so there is no need to protect them with headless >>>> check, please? >>>> >>>> Could you also file a SubCR against JDK8 with the idea we discussed >>>> offline: create a new CHeadlessDataTransferer class to use in the >>>> headless mode instead of CDataTransferer + headless checks, please? >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 7/23/2012 1:09 PM, Alexander Zuev wrote: >>>>> Hello, >>>>> >>>>> please review my fix 7184951: [macosx] Exception at >>>>> java.awt.datatransfer on headless mode (only in GUI session) >>>>> CR description can be found here: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 >>>>> >>>>> Webrev with the proposed change can be seen here: >>>>> http://cr.openjdk.java.net/~kizune/7184951/webrev.00 >>>>> >>>>> The problem here lays somewhere deep in the Toolkit life cycle on >>>>> Mac OS X - at the time we initialize datatransfer the >>>>> Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later >>>>> when we trying to use it it returns HeadlessToolkit. That's >>>>> definitely >>>>> wrong but at this stage it's too risky to fiddle with the life cycle >>>>> itself so this is a hotfix that deals with the fallout of the actual >>>>> error. The fix for jdk8 should be different. >>>>> >>>>> With best regards, >>>>> Alex >>> >>> > > -- Best regards, Sergey. From artem.ananiev at oracle.com Mon Jul 23 08:27:45 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 23 Jul 2012 19:27:45 +0400 Subject: [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) In-Reply-To: <500D516A.1060001@oracle.com> References: <500D14E2.6010107@oracle.com> <500D2A5D.4020602@oracle.com> <500D2D15.9070404@oracle.com> <500D4F71.6080902@oracle.com> <500D516A.1060001@oracle.com> Message-ID: <500D6D71.5070709@oracle.com> On 7/23/2012 5:28 PM, Alexander Zuev wrote: > On 7/23/12 17:19, Artem Ananiev wrote: >> >> On 7/23/2012 2:53 PM, Alexander Zuev wrote: >>> Artem, >>> >>> these native methods should not be called according to the logic of the >>> class so we shouldn't safeguard them. >> >> Could you elaborate on that, please? > Sure. The only native method that is not related to drag and drop > functionality > (which can not be instantiated in headless mode anyways) is private > native String formatForIndex(long index); > It is being called from the protected method getNativeForFormat(long > format) which, in turn, being called > by the drag-related methods or from public getters that check the index > to be in the valid borders. > Since we do not register any native-backed flavors in the set this > native method will not be called in headless mode. OK, fine. Thanks for the confirmation. Looks good. Artem >>> I will create the sub-cr against the jdk8. >> >> Thanks! >> >> Artem >> >>> WBR, >>> Alex >>> >>> >>> >>> On 7/23/12 14:41, Artem Ananiev wrote: >>>> Hi, Alex, >>>> >>>> (cross-posting to awt-dev) >>>> >>>> I see several other native methods in CDataTransferer, e.g. >>>> formatForIndex(). Could you confirm, they cannot be called in the >>>> headless mode, so there is no need to protect them with headless >>>> check, please? >>>> >>>> Could you also file a SubCR against JDK8 with the idea we discussed >>>> offline: create a new CHeadlessDataTransferer class to use in the >>>> headless mode instead of CDataTransferer + headless checks, please? >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 7/23/2012 1:09 PM, Alexander Zuev wrote: >>>>> Hello, >>>>> >>>>> please review my fix 7184951: [macosx] Exception at >>>>> java.awt.datatransfer on headless mode (only in GUI session) >>>>> CR description can be found here: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 >>>>> >>>>> Webrev with the proposed change can be seen here: >>>>> http://cr.openjdk.java.net/~kizune/7184951/webrev.00 >>>>> >>>>> The problem here lays somewhere deep in the Toolkit life cycle on >>>>> Mac OS X - at the time we initialize datatransfer the >>>>> Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later >>>>> when we trying to use it it returns HeadlessToolkit. That's definitely >>>>> wrong but at this stage it's too risky to fiddle with the life cycle >>>>> itself so this is a hotfix that deals with the fallout of the actual >>>>> error. The fix for jdk8 should be different. >>>>> >>>>> With best regards, >>>>> Alex >>> >>> > > From xueming.shen at oracle.com Mon Jul 23 15:27:34 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 23 Jul 2012 15:27:34 -0700 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> Message-ID: <500DCFD6.1050807@oracle.com> The fix for jdk8 is now in the TL repository, should be in the "next" promotion jdk8 very soon. The plan is for this change to be baked in jdk8 for a while before backport to a 7ux release. -Sherman On 07/23/2012 12:56 AM, David Kocher wrote: > I really would appreciate an answer here and a possible resolution to backport this fix. Others are having the same issue [1] and are posting to the non maintained JIRA issue tracker. > > -- David > > > [1] http://java.net/jira/browse/MACOSX_PORT-165 > > On 04.07.2012, at 18:40, David Kocher wrote: > >> Is there a corresponding ticket in bugs.sun.com that allows to track this issue? >> >> -- David >> >> On 27.06.2012, at 09:28, David Kocher wrote: >> >>> I welcome this issue is getting some serious attention then. When will this be backported to 7u? >>> >>> -- David >>> >>> On 24.06.2012, at 18:58, Xueming Shen wrote: >>> >>>> Yes, I believe the issue described in MACOSX_PORT-165 is the >>>> same issue this patch is trying to solve. >>>> >>>> Btw, it appears there are typos in the note(2), my mini keyboard obviously >>>> is too sticky:-) >>>> >>>> (2) normalize the resulting file name from macosx fs APIs from nfd->nfc before passing >>>> back to java.io.File (File.list() and canonicalize()), so we deal with nfc file name >>>> (as "usual") for java.io classes/APIs. >>>> >>>> -sherman >>>> >>>> On 6/24/12 7:50 AM, David Kocher wrote: >>>>> Will this address issue MACOSX_PORT-165 [1]? >>>>> >>>>> [1] http://java.net/jira/browse/MACOSX_PORT-165 >>>>> >>>>> -- David >>>>> >>>>> On 22.06.2012, at 19:01, Xueming Shen wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> Here is the proposed change to support Unicode nfd/nfc and case insensitive >>>>>> file path on MacOSX file system. >>>>>> >>>>>> 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X >>>>>> 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] >>>>>> >>>>>> While these two bug reports are only against java.io, we have the same issue in javax.nio.file. >>>>>> Here is the webrev >>>>>> >>>>>> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ >>>>>> >>>>>> Here is the brief summary of the changes >>>>>> >>>>>> java.io.File: >>>>>> (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means >>>>>> we are now passing nfc/composite characters directly into macosx file system APIs >>>>>> without normalize them to nfd. It appears macosx fs APIs do take nfc, though it uses >>>>>> nfd. >>>>>> >>>>>> (2) normalize the resulting file name from macosx fs APIs from nfd->nfd before passing >>>>>> back to java.io.File (File.list() and canonicalize()), so we deal with nfdc file name >>>>>> (as "usual") for java.io classes/APIs. >>>>>> >>>>>> (3) fs.compare()/hashCode() was updated to be case insensitive >>>>>> >>>>>> (4) hasCode() was updated to use the new String.hash32(). >>>>>> >>>>>> java.nio.file: >>>>>> >>>>>> (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An alternative is to >>>>>> update those BsdFile... classes directly to address the macosx specific issues. But given >>>>>> there might be developers over there might work on open jdk BSD port and have dependency >>>>>> on these classes, it might be desirable to have another separate layer of MacOSXFile... >>>>>> classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider and >>>>>> MacOSXFileSystem. >>>>>> >>>>>> (6) the "main" changes are in MacOSXFileSystem, in which the corresponding methods >>>>>> were added to handle, case insensitive and nfd<=>nfc normalization, including the >>>>>> pathmatcher. >>>>>> >>>>>> (7) compare is now are case-insensitive >>>>>> >>>>>> (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and maxosx. >>>>>> >>>>>> >>>>>> Though lots of files have been touched, but the line of changes are actually relatively >>>>>> small. >>>>>> >>>>>> The proposed change only deals with the default case-sensitiveness seting, which is >>>>>> case insensitive. On MaxOSX, you actually can configure the HFS+ file system or the >>>>>> mounted vol to be case-sensitive. A possible approach is to have some extra FileStore >>>>>> attributes, such as a isCaseSensitive and to use case sensitive compare/equal on >>>>>> such fs, but this can be dealt with separately later. >>>>>> >>>>>> Thanks, >>>>>> -Sherman >>>>>> >>>> From jcpalmer at rochester.rr.com Tue Jul 24 17:02:22 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Tue, 24 Jul 2012 20:02:22 -0400 Subject: JRE update not working after b16 Message-ID: <51A0CDFD-F95E-45EF-AA83-6B72263BADC8@rochester.rr.com> Thought I would mention, that I have not gotten a request to update since b16. Could be that some processing is just being left out, but if not than there is a bug. http://jdk7.java.net/macportpreview/ shows b20 is the current one. I have the automatic checking checked in the control panel. It is show date of last check is today. From roger.lewis at oracle.com Tue Jul 24 17:51:44 2012 From: roger.lewis at oracle.com (Roger Lewis) Date: Tue, 24 Jul 2012 17:51:44 -0700 Subject: JRE update not working after b16 In-Reply-To: <51A0CDFD-F95E-45EF-AA83-6B72263BADC8@rochester.rr.com> References: <51A0CDFD-F95E-45EF-AA83-6B72263BADC8@rochester.rr.com> Message-ID: <500F4320.1060103@oracle.com> Thanks. We will look into it. The current release set for AU is 1.7.0_06-ea-b19, so checking for an update should update the runtime to b19. -Roger On 7/24/12 5:02 PM, Jeff Palmer wrote: > Thought I would mention, that I have not gotten a request to update since b16. Could be that some processing is just being left out, but if not than there is a bug. http://jdk7.java.net/macportpreview/ shows b20 is the current one. I have the automatic checking checked in the control panel. It is show date of last check is today. From roger.lewis at oracle.com Wed Jul 25 12:57:33 2012 From: roger.lewis at oracle.com (Roger Lewis) Date: Wed, 25 Jul 2012 12:57:33 -0700 Subject: JRE update not working after b16 In-Reply-To: <500F4320.1060103@oracle.com> References: <51A0CDFD-F95E-45EF-AA83-6B72263BADC8@rochester.rr.com> <500F4320.1060103@oracle.com> Message-ID: <50104FAD.9050505@oracle.com> Hi Jeff, The cause has been determined to be a change in the format of the AU version detection. This change was made in build 18. A fix is being tested in the AU file that may allow those with b17 and lower AU to the latest release. Once we know the outcome of that test, I will let you know. In the meantime you can manually download and install b20. Or, you can wait and verify the fix, if and when it is released. Additionally, we have updated the current AU release to b20, so it is now inline with the current release on java.net. Thanks again for letting us know, Roger On 7/24/12 5:51 PM, Roger Lewis wrote: > Thanks. We will look into it. The current release set for AU is > 1.7.0_06-ea-b19, so checking for an update should update the runtime > to b19. > > -Roger > > On 7/24/12 5:02 PM, Jeff Palmer wrote: >> Thought I would mention, that I have not gotten a request to update >> since b16. Could be that some processing is just being left out, but >> if not than there is a bug. http://jdk7.java.net/macportpreview/ >> shows b20 is the current one. I have the automatic checking checked >> in the control panel. It is show date of last check is today. From dkocher at sudo.ch Thu Jul 26 07:26:57 2012 From: dkocher at sudo.ch (David Kocher) Date: Thu, 26 Jul 2012 16:26:57 +0200 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <500DCFD6.1050807@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> <500DCFD6.1050807@oracle.com> Message-ID: <3B05C10D-26BF-4C7C-8A05-062CA5D0F6BB@sudo.ch> I (and certainly others not even aware of the issue) would welcome if the backport could be given higher priority as this is a show stopper bug to bundle applications with a current jre7 runtime. -- David On 24.07.2012, at 00:27, Xueming Shen wrote: > > The fix for jdk8 is now in the TL repository, should be in the "next" promotion jdk8 > very soon. The plan is for this change to be baked in jdk8 for a while before backport > to a 7ux release. > > -Sherman > > On 07/23/2012 12:56 AM, David Kocher wrote: >> I really would appreciate an answer here and a possible resolution to backport this fix. Others are having the same issue [1] and are posting to the non maintained JIRA issue tracker. >> >> -- David >> >> >> [1] http://java.net/jira/browse/MACOSX_PORT-165 >> >> On 04.07.2012, at 18:40, David Kocher wrote: >> >>> Is there a corresponding ticket in bugs.sun.com that allows to track this issue? >>> >>> -- David >>> >>> On 27.06.2012, at 09:28, David Kocher wrote: >>> >>>> I welcome this issue is getting some serious attention then. When will this be backported to 7u? >>>> >>>> -- David >>>> >>>> On 24.06.2012, at 18:58, Xueming Shen wrote: >>>> >>>>> Yes, I believe the issue described in MACOSX_PORT-165 is the >>>>> same issue this patch is trying to solve. >>>>> >>>>> Btw, it appears there are typos in the note(2), my mini keyboard obviously >>>>> is too sticky:-) >>>>> >>>>> (2) normalize the resulting file name from macosx fs APIs from nfd->nfc before passing >>>>> back to java.io.File (File.list() and canonicalize()), so we deal with nfc file name >>>>> (as "usual") for java.io classes/APIs. >>>>> >>>>> -sherman >>>>> >>>>> On 6/24/12 7:50 AM, David Kocher wrote: >>>>>> Will this address issue MACOSX_PORT-165 [1]? >>>>>> >>>>>> [1] http://java.net/jira/browse/MACOSX_PORT-165 >>>>>> >>>>>> -- David >>>>>> >>>>>> On 22.06.2012, at 19:01, Xueming Shen wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> Here is the proposed change to support Unicode nfd/nfc and case insensitive >>>>>>> file path on MacOSX file system. >>>>>>> >>>>>>> 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X >>>>>>> 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] >>>>>>> >>>>>>> While these two bug reports are only against java.io, we have the same issue in javax.nio.file. >>>>>>> Here is the webrev >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ >>>>>>> >>>>>>> Here is the brief summary of the changes >>>>>>> >>>>>>> java.io.File: >>>>>>> (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means >>>>>>> we are now passing nfc/composite characters directly into macosx file system APIs >>>>>>> without normalize them to nfd. It appears macosx fs APIs do take nfc, though it uses >>>>>>> nfd. >>>>>>> >>>>>>> (2) normalize the resulting file name from macosx fs APIs from nfd->nfd before passing >>>>>>> back to java.io.File (File.list() and canonicalize()), so we deal with nfdc file name >>>>>>> (as "usual") for java.io classes/APIs. >>>>>>> >>>>>>> (3) fs.compare()/hashCode() was updated to be case insensitive >>>>>>> >>>>>>> (4) hasCode() was updated to use the new String.hash32(). >>>>>>> >>>>>>> java.nio.file: >>>>>>> >>>>>>> (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An alternative is to >>>>>>> update those BsdFile... classes directly to address the macosx specific issues. But given >>>>>>> there might be developers over there might work on open jdk BSD port and have dependency >>>>>>> on these classes, it might be desirable to have another separate layer of MacOSXFile... >>>>>>> classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider and >>>>>>> MacOSXFileSystem. >>>>>>> >>>>>>> (6) the "main" changes are in MacOSXFileSystem, in which the corresponding methods >>>>>>> were added to handle, case insensitive and nfd<=>nfc normalization, including the >>>>>>> pathmatcher. >>>>>>> >>>>>>> (7) compare is now are case-insensitive >>>>>>> >>>>>>> (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and maxosx. >>>>>>> >>>>>>> >>>>>>> Though lots of files have been touched, but the line of changes are actually relatively >>>>>>> small. >>>>>>> >>>>>>> The proposed change only deals with the default case-sensitiveness seting, which is >>>>>>> case insensitive. On MaxOSX, you actually can configure the HFS+ file system or the >>>>>>> mounted vol to be case-sensitive. A possible approach is to have some extra FileStore >>>>>>> attributes, such as a isCaseSensitive and to use case sensitive compare/equal on >>>>>>> such fs, but this can be dealt with separately later. >>>>>>> >>>>>>> Thanks, >>>>>>> -Sherman >>>>>>> >>>>> > From mik3hall at gmail.com Sun Jul 29 18:05:38 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 29 Jul 2012 20:05:38 -0500 Subject: trz update - nio.2 MacFileSystemProvider added kqueue WatchService Message-ID: I have added an implementation of a kqueue based WatchService implementation to my OS X specific nio.2 code. At this time this code will run a slightly modified version of the openjdk WatchService Basic test code. (See known_issues.txt for more info). This provides a platform specific non-polling native solution to replace the generic polling WatchService currently being provided in Java 7 for OS X. I intend to provide one more WatchService based on FSEvents for OS X. See [1[ for mention of kqueue vs. fsevents use. Example usage to run the modified WatchService Basic test with the kqueue WatchService java -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider -cp lib/macnio2.jar Basic This adds a WatchService to the currently supported Mac nio.2 file attributes. Included there are attributes for? o Finder o Launch Services o Cocoa NSFileManager o xattr These provide access to platform specific file meta information not available otherwise with java. Download - http://www195.pair.com/mik3hall/trz.zip [1] https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/FSEvents_ProgGuide/KernelQueues/KernelQueues.html#//apple_ref/doc/uid/TP40005289-CH5-SW2 From marco.dinacci at gmail.com Mon Jul 30 06:55:56 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Mon, 30 Jul 2012 14:55:56 +0100 Subject: [PATCH] Remove usage of private API Message-ID: Hi, my app bundling the OpenJDK just got rejected on the Apple Store because it uses some private API. It turns out there are a few files in jdk/src/macosx/native/sun/awt/ that use CGPointApplyInverseAffineTransform and CGContextSetCTM, which are private functions. The following patch attempts to replace those API calls with public ones. It's my first venture into CoreGraphics, hopefully I got it right. I've also found a private string (CTIntegerMetrics) used in CoreTextSupport.m and CTextPipe.m. I don't know any fix for this as it seems the functionality is not exposed via any public API. Please advise whether I should open a bug or not. Best, Marco # HG changeset patch # User Marco Dinacci # Date 1343648968 -3600 # Node ID d873b027d78564ad237f98a0cb5a327c5c740354 # Parent 2ebb564fd0a1267491b6a13bf7ff35b9894ebdba Replaced CGContextSetCTM and CGPointApplyInverseAffineTransform with public API calls. diff -r 2ebb564fd0a1 -r d873b027d785 src/macosx/native/sun/awt/ImageSurfaceData.m --- a/src/macosx/native/sun/awt/ImageSurfaceData.m Thu Jun 28 10:13:16 2012 +0100 +++ b/src/macosx/native/sun/awt/ImageSurfaceData.m Mon Jul 30 12:49:28 2012 +0100 @@ -48,20 +48,16 @@ #endif // same value as defined in Sun's own code #define XOR_ALPHA_CUTOFF 128 // for vImage framework headers #include - -// private Quartz routines needed here -CG_EXTERN void CGContextSetCTM(CGContextRef ref, CGAffineTransform tx); - static ContextInfo sDefaultContextInfo[sun_java2d_OSXOffScreenSurfaceData_TYPE_3BYTE_RGB+1] = { {YES, YES, 8, 4, 0, kCGImageAlphaPremultipliedFirst | kCGBitmapByteOrder32Host, NULL}, // TYPE_CUSTOM // special case {YES, YES, 8, 4, 0, kCGImageAlphaNoneSkipFirst | kCGBitmapByteOrder32Host, NULL}, // TYPE_INT_RGB {YES, YES, 8, 4, 0, kCGImageAlphaPremultipliedFirst | kCGBitmapByteOrder32Host, NULL}, // TYPE_INT_ARGB {YES, YES, 8, 4, 0, kCGImageAlphaPremultipliedFirst | kCGBitmapByteOrder32Host, NULL}, // TYPE_INT_ARGB_PRE {YES, YES, 8, 4, 0, kCGImageAlphaNoneSkipFirst | kCGBitmapByteOrder32Host, NULL}, // TYPE_INT_BGR {YES, NO, 8, 4, 0, kCGImageAlphaNoneSkipFirst | kCGBitmapByteOrder32Host, NULL}, // TYPE_3BYTE_BGR // use the default ARGB_PRE context synce we have to sync by hand anyway @@ -937,17 +933,16 @@ PRINT("createContext") if (qsdo->cgRef == NULL) { fprintf(stderr, "ERROR: (qsdo->cgRef == NULL) in createContext!\n"); } // intitalize the context to match the Java coordinate system // BG, since the context is created above, we can just concat - //CGContextSetCTM(qsdo->cgRef, CGAffineTransformMake(1, 0, 0, -1, 0, isdo->height)); CGContextConcatCTM(qsdo->cgRef, CGAffineTransformMake(1, 0, 0, -1, 0, isdo->height)); CGContextSaveGState(qsdo->cgRef); // this will make sure we don't go pass device context settings CGContextSaveGState(qsdo->cgRef); // this will put user settings on top, used by LazyStateManagement code qsdo->newContext = YES; } IMAGE_SURFACE_INLINE void holdJavaPixels(JNIEnv* env, ImageSDOps* isdo) @@ -1109,17 +1104,17 @@ PRINT("syncFromJavaPixels") if (qsdo->cgRef == NULL) { createContext(env, isdo); } if (qsdo->cgRef != NULL) { CGContextSaveGState(qsdo->cgRef); - CGContextSetCTM(qsdo->cgRef, CGAffineTransformMake(1, 0, 0, 1, 0, 0)); + CGContextConcatCTM(qsdo->cgRef, CGAffineTransformMake(1, 0, 0, 1, 0, 0)); CGContextSetBlendMode(qsdo->cgRef, kCGBlendModeCopy); CGContextSetAlpha(qsdo->cgRef, 1.0f); CGContextDrawImage(qsdo->cgRef, CGRectMake(0, 0, width, height), javaImg); CGContextFlush(qsdo->cgRef); CGContextRestoreGState(qsdo->cgRef); CGImageRelease(javaImg); } else diff -r 2ebb564fd0a1 -r d873b027d785 src/macosx/native/sun/awt/QuartzRenderer.m --- a/src/macosx/native/sun/awt/QuartzRenderer.m Thu Jun 28 10:13:16 2012 +0100 +++ b/src/macosx/native/sun/awt/QuartzRenderer.m Mon Jul 30 12:49:28 2012 +0100 @@ -45,19 +45,16 @@ // Copied the following from Math.java #define PI 3.14159265358979323846f #define BATCHED_POINTS_SIZE 1024 // same value as defined in Sun's own code #define XOR_ALPHA_CUTOFF 128 -// private Quartz routines needed here -CG_EXTERN void CGContextSetCTM(CGContextRef ref, CGAffineTransform tx); - static CGFloat gRoundRectCtrlpts[10][12] = { {0.0f, 0.0f, 0.0f, 0.5f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f}, {0.0f, 0.0f, 1.0f, -0.5f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f}, {0.0f, 0.0f, 1.0f, 0.0f, 0.0f, 0.0f, 1.0f, 0.0f, 0.0f, 0.5f, 1.0f, 0.0f}, {1.0f, -0.5f, 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f}, {1.0f, 0.0f, 1.0f, 0.0f, 1.0f, 0.0f, 1.0f, 0.0f, 1.0f, 0.0f, 1.0f, -0.5f}, @@ -532,31 +529,33 @@ QUARTZ_RENDERER_INLINE void doImageCG(JN { a = -1.0f; tx += dw; } makeSureImageIsCreated(isdo); CGAffineTransform ctm = CGContextGetCTM(cgRef); - CGContextConcatCTM(cgRef, CGAffineTransformMake(a, b, c, d, tx, ty)); + CGAffineTransform newTm = CGAffineTransformMake(a, b, c, d, tx, ty); + CGContextConcatCTM(cgRef, newTm); jint alphaInfo = isdo->contextInfo.alphaInfo & kCGBitmapAlphaInfoMask; if ((sx == 0) && (sy == 0) && (sw == w) && (sh == h)) // no subimages allowed here { CGContextDrawImage(cgRef, CGRectMake(0, 0, dw, dh), isdo->imgRef); } else // handle subimages { CGImageRef subImg = CGImageCreateWithImageInRect(isdo->imgRef, CGRectMake(sx, sy, sw, sh)); CGContextDrawImage(cgRef, CGRectMake(0.0f, 0.0f, dw, dh), subImg); CGImageRelease(subImg); } - CGContextSetCTM(cgRef, ctm); + CGAffineTransform inverse = CGAffineTransformInvert(newTm); + CGContextConcatCTM(cgRef, inverse); UnlockImage(env, isdo); } QUARTZ_RENDERER_INLINE void doImage(JNIEnv *env, QuartzSDOps *qsdo, jobject imageSurfaceData, jboolean fliph, jboolean flipv, jint w, jint h, jint sx, jint sy, jint sw, jint sh, jint dx, jint dy, jint dw, jint dh) { if ((w > 0) && (h > 0) && (sw > 0) && (sh > 0) && (dw > 0) && (dh > 0)) { diff -r 2ebb564fd0a1 -r d873b027d785 src/macosx/native/sun/awt/QuartzSurfaceData.m --- a/src/macosx/native/sun/awt/QuartzSurfaceData.m Thu Jun 28 10:13:16 2012 +0100 +++ b/src/macosx/native/sun/awt/QuartzSurfaceData.m Mon Jul 30 12:49:28 2012 +0100 @@ -35,29 +35,23 @@ #import "sun_lwawt_macosx_CPrinterSurfaceData.h" #import "ImageSurfaceData.h" #import #import #import "ThreadUtilities.h" -// private Quartz routines needed here -CG_EXTERN void CGContextSetCTM(CGContextRef ref, CGAffineTransform tx); - //#define DEBUG #if defined DEBUG #define PRINT(msg) {fprintf(stderr, "%s\n", msg);} #else #define PRINT(msg) {} #endif -// from CGAffineTransformPrivate.h -extern CGPoint CGPointApplyInverseAffineTransform(CGPoint point, CGAffineTransform t); - #define kOffset (0.5f) BOOL gAdjustForJavaDrawing; #pragma mark #pragma mark --- Color Cache --- // Creating and deleting CGColorRefs can be expensive, therefore we have a color cache. @@ -603,17 +597,21 @@ PRINT(" SetUpCGContext") (qsdo->graphicsStateInfo.ctm.c != ctm.c) || (qsdo->graphicsStateInfo.ctm.d != ctm.d)) { qsdo->graphicsStateInfo.ctm = ctm; // In CG affine xforms y' = bx+dy+ty // We need to flip both y coefficeints to flip the offset point into the java coordinate system. ctm.b = -ctm.b; ctm.d = -ctm.d; ctm.tx = 0.0f; ctm.ty = 0.0f; CGPoint offsets = {kOffset, kOffset}; - offsets = CGPointApplyInverseAffineTransform(offsets, ctm); + + + CGAffineTransform inverse = CGAffineTransformInvert(ctm); + offsets = CGPointApplyAffineTransform(offsets, inverse); + //offsets = CGPointApplyInverseAffineTransform(offsets, ctm); qsdo->graphicsStateInfo.offsetX = offsets.x; qsdo->graphicsStateInfo.offsetY = offsets.y; } } else { qsdo->graphicsStateInfo.offsetX = 0.0f; qsdo->graphicsStateInfo.offsetY = 0.0f; exporting patch: From scott.kovatch at oracle.com Mon Jul 30 09:23:41 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 30 Jul 2012 09:23:41 -0700 Subject: [PATCH] Remove usage of private API In-Reply-To: References: Message-ID: On Jul 30, 2012, at 6:55 AM, Marco Dinacci wrote: > Hi, > > my app bundling the OpenJDK just got rejected on the Apple Store > because it uses some private API. It turns out there are a few files > in jdk/src/macosx/native/sun/awt/ that use > CGPointApplyInverseAffineTransform and CGContextSetCTM, which are > private functions. Did you get a full list of the APIs that was causing the rejection? The patch is greatly appreciated, but if there are others we can start hunting them down now and save everyone a lot of time. > The following patch attempts to replace those API calls with public > ones. It's my first venture into CoreGraphics, hopefully I got it > right. > > I've also found a private string (CTIntegerMetrics) used in > CoreTextSupport.m and CTextPipe.m. I don't know any fix for this as it > seems the functionality is not exposed via any public API. > > Please advise whether I should open a bug or not. Yes, you should open a bug for these, as being able to submit a Java-based app to the OS X app store is something we want to support. Be sure to include your patch, along with information as to which branch you based your changes on. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From marco.dinacci at gmail.com Mon Jul 30 09:49:31 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Mon, 30 Jul 2012 17:49:31 +0100 Subject: [PATCH] Remove usage of private API In-Reply-To: References: Message-ID: Hi, > Did you get a full list of the APIs that was causing the rejection? the only one that was mentioned in the report was: CGPointApplyInverseAffineTransform. In the same file that uses this call I then discovered CGContextSetCTM which is used in two different files. > Yes, you should open a bug for these, as being able to submit a Java-based app to the OS X app store is something we want to support. Be sure to include your patch, along with information as to which branch you based your changes on. > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7187834. Best, Marco From scott.kovatch at oracle.com Mon Jul 30 11:06:15 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 30 Jul 2012 11:06:15 -0700 Subject: [PATCH] Remove usage of private API In-Reply-To: References: Message-ID: On Jul 30, 2012, at 9:49 AM, Marco Dinacci wrote: > Hi, > >> Did you get a full list of the APIs that was causing the rejection? > > the only one that was mentioned in the report was: > CGPointApplyInverseAffineTransform. > In the same file that uses this call I then discovered CGContextSetCTM > which is used in two different files. One other question for you? which JRE did you use when submitting your application? I'm trying to determine if you had any of the JavaFX libraries -- 7u4 doesn't bundle JavaFx, but 7u6 does. If you did then that's one less thing for us to check. Otherwise, we will need to scan the native parts of JavaFx to make sure we don't have this problem again later. Thanks, Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From marco.dinacci at gmail.com Mon Jul 30 11:39:15 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Mon, 30 Jul 2012 19:39:15 +0100 Subject: [PATCH] Remove usage of private API In-Reply-To: References: Message-ID: Hi, > One other question for you? which JRE did you use when submitting your application? > I'm trying to determine if you had any of the JavaFX libraries -- 7u4 doesn't bundle JavaFx, but 7u6 does. If you did then that's one less thing for us to check. Otherwise, we will need to scan the native parts of JavaFx to make sure we don't have this problem again later. I didn't bundle any JavaFX library for sure. We maintain our own 7u repo that at the time of submission was based on changeset 3ce621d9b988 (jdk7u6-b14). Best, Marco From ahughes at redhat.com Mon Jul 30 12:46:29 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Mon, 30 Jul 2012 15:46:29 -0400 (EDT) Subject: [PATCH] Remove usage of private API In-Reply-To: Message-ID: <1102943505.5483888.1343677589310.JavaMail.root@redhat.com> ----- Original Message ----- > > On Jul 30, 2012, at 9:49 AM, Marco Dinacci > wrote: > > > Hi, > > > >> Did you get a full list of the APIs that was causing the > >> rejection? > > > > the only one that was mentioned in the report was: > > CGPointApplyInverseAffineTransform. > > In the same file that uses this call I then discovered > > CGContextSetCTM > > which is used in two different files. > > > One other question for you? which JRE did you use when submitting > your application? > > I'm trying to determine if you had any of the JavaFX libraries -- 7u4 > doesn't bundle JavaFx, but 7u6 does. If you did then that's one less > thing for us to check. Otherwise, we will need to scan the native > parts of JavaFx to make sure we don't have this problem again later. > Correct me if I'm wrong, but you seem to be suggesting that a user could bundle the binaries supplied by Oracle, which contain JavaFX. IANAL, but my understanding was that this wouldn't be permitted by the license, which doesn't allow redistribution (distros can no longer package it for instance). > Thanks, > Scott K. > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From scott.kovatch at oracle.com Mon Jul 30 13:14:22 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 30 Jul 2012 13:14:22 -0700 Subject: [PATCH] Remove usage of private API In-Reply-To: <1102943505.5483888.1343677589310.JavaMail.root@redhat.com> References: <1102943505.5483888.1343677589310.JavaMail.root@redhat.com> Message-ID: On Jul 30, 2012, at 12:46 PM, Andrew Hughes wrote: > ----- Original Message ----- >> >> On Jul 30, 2012, at 9:49 AM, Marco Dinacci >> wrote: >> >>> Hi, >>> >>>> Did you get a full list of the APIs that was causing the >>>> rejection? >>> >>> the only one that was mentioned in the report was: >>> CGPointApplyInverseAffineTransform. >>> In the same file that uses this call I then discovered >>> CGContextSetCTM >>> which is used in two different files. >> >> >> One other question for you? which JRE did you use when submitting >> your application? >> >> I'm trying to determine if you had any of the JavaFX libraries -- 7u4 >> doesn't bundle JavaFx, but 7u6 does. If you did then that's one less >> thing for us to check. Otherwise, we will need to scan the native >> parts of JavaFx to make sure we don't have this problem again later. >> > > Correct me if I'm wrong, but you seem to be suggesting that a user could > bundle the binaries supplied by Oracle, which contain JavaFX. IANAL, but > my understanding was that this wouldn't be permitted by the license, which > doesn't allow redistribution (distros can no longer package it for instance). 7u6 isn't out yet, but the intention is that because JavaFx will be part of the JRE distribution you can redistribute that with your application. License agreements may need updating to officially support that. Note that we're not talking about an OpenJDK distribution -- this is an Oracle-branded 7u6 JRE. -- Scott K. From swpalmer at gmail.com Mon Jul 30 13:32:22 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 30 Jul 2012 16:32:22 -0400 Subject: [PATCH] Remove usage of private API In-Reply-To: References: <1102943505.5483888.1343677589310.JavaMail.root@redhat.com> Message-ID: On 2012-07-30, at 4:14 PM, Scott Kovatch wrote: > > On Jul 30, 2012, at 12:46 PM, Andrew Hughes wrote: > >> ----- Original Message ----- >>> >>> On Jul 30, 2012, at 9:49 AM, Marco Dinacci >>> wrote: >>> >>>> Hi, >>>> >>>>> Did you get a full list of the APIs that was causing the >>>>> rejection? >>>> >>>> the only one that was mentioned in the report was: >>>> CGPointApplyInverseAffineTransform. >>>> In the same file that uses this call I then discovered >>>> CGContextSetCTM >>>> which is used in two different files. >>> >>> >>> One other question for you? which JRE did you use when submitting >>> your application? >>> >>> I'm trying to determine if you had any of the JavaFX libraries -- 7u4 >>> doesn't bundle JavaFx, but 7u6 does. If you did then that's one less >>> thing for us to check. Otherwise, we will need to scan the native >>> parts of JavaFx to make sure we don't have this problem again later. >>> >> >> Correct me if I'm wrong, but you seem to be suggesting that a user could >> bundle the binaries supplied by Oracle, which contain JavaFX. IANAL, but >> my understanding was that this wouldn't be permitted by the license, which >> doesn't allow redistribution (distros can no longer package it for instance). > > 7u6 isn't out yet, but the intention is that because JavaFx will be part of the JRE distribution you can redistribute that with your application. License agreements may need updating to officially support that. > > Note that we're not talking about an OpenJDK distribution -- this is an Oracle-branded 7u6 JRE. > > -- Scott K. Oracle JavaFX became redistributable with version 2.1. Prior to that there was a MP3 codec or something that could not be redistributed. I believe the current JavaFX 2.1 license already indicates that it can be bundled with your application. Scott P. From ahughes at redhat.com Mon Jul 30 14:30:31 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Mon, 30 Jul 2012 17:30:31 -0400 (EDT) Subject: [PATCH] Remove usage of private API In-Reply-To: Message-ID: <1184123906.5530083.1343683831383.JavaMail.root@redhat.com> ----- Original Message ----- > > On 2012-07-30, at 4:14 PM, Scott Kovatch > wrote: > > > > > On Jul 30, 2012, at 12:46 PM, Andrew Hughes > > wrote: > > > >> ----- Original Message ----- > >>> > >>> On Jul 30, 2012, at 9:49 AM, Marco Dinacci > >>> > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>>> Did you get a full list of the APIs that was causing the > >>>>> rejection? > >>>> > >>>> the only one that was mentioned in the report was: > >>>> CGPointApplyInverseAffineTransform. > >>>> In the same file that uses this call I then discovered > >>>> CGContextSetCTM > >>>> which is used in two different files. > >>> > >>> > >>> One other question for you? which JRE did you use when submitting > >>> your application? > >>> > >>> I'm trying to determine if you had any of the JavaFX libraries -- > >>> 7u4 > >>> doesn't bundle JavaFx, but 7u6 does. If you did then that's one > >>> less > >>> thing for us to check. Otherwise, we will need to scan the native > >>> parts of JavaFx to make sure we don't have this problem again > >>> later. > >>> > >> > >> Correct me if I'm wrong, but you seem to be suggesting that a user > >> could > >> bundle the binaries supplied by Oracle, which contain JavaFX. > >> IANAL, but > >> my understanding was that this wouldn't be permitted by the > >> license, which > >> doesn't allow redistribution (distros can no longer package it for > >> instance). > > > > 7u6 isn't out yet, but the intention is that because JavaFx will be > > part of the JRE distribution you can redistribute that with your > > application. License agreements may need updating to officially > > support that. > > > > Note that we're not talking about an OpenJDK distribution -- this > > is an Oracle-branded 7u6 JRE. > > > > -- Scott K. > > Oracle JavaFX became redistributable with version 2.1. Prior to that > there was a MP3 codec or something that could not be redistributed. > I believe the current JavaFX 2.1 license already indicates that it > can be bundled with your application. > JavaFX maybe, but the whole JDK too? Anyway, it sounds like Marco is using an OpenJDK build, not proprietary Oracle binaries. > Scott P. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From James.Gunning at csiro.au Mon Jul 30 15:14:02 2012 From: James.Gunning at csiro.au (James.Gunning at csiro.au) Date: Tue, 31 Jul 2012 08:14:02 +1000 Subject: Running a standard build with X11 front end Message-ID: <4D838DE1C9383B4286C5FA0318CB8FF42BE74821D2@exvic-mbx05.nexus.csiro.au> Hi All, I'm new to the list and very ignorant. Also, I *like* running java with an X11 front end (all my real work is done in X). Can any of the standard newer builds linked from https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port be run with X11 front-end on a standard OSX box? Can anyone tell me how? Or do I need to do my own build (anybody got instructions lying about?) Thanks for any help. Best wishes, James. From alexander.zuev at oracle.com Mon Jul 30 16:16:57 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 31 Jul 2012 03:16:57 +0400 Subject: Running a standard build with X11 front end In-Reply-To: <4D838DE1C9383B4286C5FA0318CB8FF42BE74821D2@exvic-mbx05.nexus.csiro.au> References: <4D838DE1C9383B4286C5FA0318CB8FF42BE74821D2@exvic-mbx05.nexus.csiro.au> Message-ID: <501715E9.1020906@oracle.com> James, you don't need to make your own build. You can use existing build with the X11 front end on Mac simply by passing parameter -Dawt.toolkit=XToolkit to java. However be ready that application might work much slower and some functionality might not work as expected. XToolkit on Mac is not a supported option you can use it on your own risk. Unless it is absolutely necessary i suggest to use default toolkit. With best regards, Alexander On 07/31/2012 02:14, James.Gunning at csiro.au wrote: > Hi All, > I'm new to the list and very ignorant. Also, I *like* running java with an X11 front end (all my real work is done in X). > Can any of the standard newer builds linked from > https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port > be run with X11 front-end on a standard OSX box? Can anyone tell me how? > Or do I need to do my own build (anybody got instructions lying about?) > Thanks for any help. > Best wishes, > James. From Sergey.Bylokhov at oracle.com Mon Jul 30 16:59:59 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 31 Jul 2012 03:59:59 +0400 Subject: Running a standard build with X11 front end In-Reply-To: <501715E9.1020906@oracle.com> References: <4D838DE1C9383B4286C5FA0318CB8FF42BE74821D2@exvic-mbx05.nexus.csiro.au> <501715E9.1020906@oracle.com> Message-ID: <50171FFF.2060606@oracle.com> FYI: On a few latest builds "*-Dawt.toolkit=sun.awt.X11.XToolkit*" option was broken, but you can use*AWT_TOOLKIT* env. http://docs.oracle.com/javase/1.5.0/docs/guide/awt/1.5/xawt.html 31.07.2012 03:16, Alexander Zuev wrote: > James, > > you don't need to make your own build. You can use existing build > with the X11 front end > on Mac simply by passing parameter -Dawt.toolkit=XToolkit to java. > However be ready that application might work much slower and some > functionality might not work as expected. XToolkit on Mac is not a > supported option > you can use it on your own risk. Unless it is absolutely necessary i > suggest to use default toolkit. > > With best regards, > Alexander > > On 07/31/2012 02:14, James.Gunning at csiro.au wrote: >> Hi All, >> I'm new to the list and very ignorant. Also, I *like* running >> java with an X11 front end (all my real work is done in X). >> Can any of the standard newer builds linked from >> https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port >> be run with X11 front-end on a standard OSX box? Can anyone tell me how? >> Or do I need to do my own build (anybody got instructions lying about?) >> Thanks for any help. >> Best wishes, >> James. > > -- Best regards, Sergey. From swpalmer at gmail.com Mon Jul 30 17:57:18 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 30 Jul 2012 20:57:18 -0400 Subject: [PATCH] Remove usage of private API In-Reply-To: <1184123906.5530083.1343683831383.JavaMail.root@redhat.com> References: <1184123906.5530083.1343683831383.JavaMail.root@redhat.com> Message-ID: <233F636A-A24D-4252-8DB6-7FA4466D0BD7@gmail.com> On 2012-07-30, at 5:30 PM, Andrew Hughes wrote: > ----- Original Message ----- >> >> On 2012-07-30, at 4:14 PM, Scott Kovatch >> wrote: >> >>> >>> On Jul 30, 2012, at 12:46 PM, Andrew Hughes >>> wrote: >>> >>>> ----- Original Message ----- >>>>> >>>>> On Jul 30, 2012, at 9:49 AM, Marco Dinacci >>>>> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>>> Did you get a full list of the APIs that was causing the >>>>>>> rejection? >>>>>> >>>>>> the only one that was mentioned in the report was: >>>>>> CGPointApplyInverseAffineTransform. >>>>>> In the same file that uses this call I then discovered >>>>>> CGContextSetCTM >>>>>> which is used in two different files. >>>>> >>>>> >>>>> One other question for you? which JRE did you use when submitting >>>>> your application? >>>>> >>>>> I'm trying to determine if you had any of the JavaFX libraries -- >>>>> 7u4 >>>>> doesn't bundle JavaFx, but 7u6 does. If you did then that's one >>>>> less >>>>> thing for us to check. Otherwise, we will need to scan the native >>>>> parts of JavaFx to make sure we don't have this problem again >>>>> later. >>>>> >>>> >>>> Correct me if I'm wrong, but you seem to be suggesting that a user >>>> could >>>> bundle the binaries supplied by Oracle, which contain JavaFX. >>>> IANAL, but >>>> my understanding was that this wouldn't be permitted by the >>>> license, which >>>> doesn't allow redistribution (distros can no longer package it for >>>> instance). >>> >>> 7u6 isn't out yet, but the intention is that because JavaFx will be >>> part of the JRE distribution you can redistribute that with your >>> application. License agreements may need updating to officially >>> support that. >>> >>> Note that we're not talking about an OpenJDK distribution -- this >>> is an Oracle-branded 7u6 JRE. >>> >>> -- Scott K. >> >> Oracle JavaFX became redistributable with version 2.1. Prior to that >> there was a MP3 codec or something that could not be redistributed. >> I believe the current JavaFX 2.1 license already indicates that it >> can be bundled with your application. >> > > JavaFX maybe, but the whole JDK too? The JRE has always been redistributable. The JDK hasn't as far as I know. That probably applies to JavaFX as well. The SDK isn't redistributable, but the runtime is. Read the license and the documentation files that come with the JDK. They say what parts are redistributable and what you aren't allowed to exclude etc. Scott P. From ahughes at redhat.com Tue Jul 31 03:06:40 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 31 Jul 2012 06:06:40 -0400 (EDT) Subject: [PATCH] Remove usage of private API In-Reply-To: <233F636A-A24D-4252-8DB6-7FA4466D0BD7@gmail.com> Message-ID: <1199042374.5903662.1343729200192.JavaMail.root@redhat.com> ----- Original Message ----- > > On 2012-07-30, at 5:30 PM, Andrew Hughes wrote: > > > ----- Original Message ----- > >> > >> On 2012-07-30, at 4:14 PM, Scott Kovatch > >> > >> wrote: > >> > >>> > >>> On Jul 30, 2012, at 12:46 PM, Andrew Hughes > >>> wrote: > >>> > >>>> ----- Original Message ----- > >>>>> > >>>>> On Jul 30, 2012, at 9:49 AM, Marco Dinacci > >>>>> > >>>>> wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>>> Did you get a full list of the APIs that was causing the > >>>>>>> rejection? > >>>>>> > >>>>>> the only one that was mentioned in the report was: > >>>>>> CGPointApplyInverseAffineTransform. > >>>>>> In the same file that uses this call I then discovered > >>>>>> CGContextSetCTM > >>>>>> which is used in two different files. > >>>>> > >>>>> > >>>>> One other question for you? which JRE did you use when > >>>>> submitting > >>>>> your application? > >>>>> > >>>>> I'm trying to determine if you had any of the JavaFX libraries > >>>>> -- > >>>>> 7u4 > >>>>> doesn't bundle JavaFx, but 7u6 does. If you did then that's one > >>>>> less > >>>>> thing for us to check. Otherwise, we will need to scan the > >>>>> native > >>>>> parts of JavaFx to make sure we don't have this problem again > >>>>> later. > >>>>> > >>>> > >>>> Correct me if I'm wrong, but you seem to be suggesting that a > >>>> user > >>>> could > >>>> bundle the binaries supplied by Oracle, which contain JavaFX. > >>>> IANAL, but > >>>> my understanding was that this wouldn't be permitted by the > >>>> license, which > >>>> doesn't allow redistribution (distros can no longer package it > >>>> for > >>>> instance). > >>> > >>> 7u6 isn't out yet, but the intention is that because JavaFx will > >>> be > >>> part of the JRE distribution you can redistribute that with your > >>> application. License agreements may need updating to officially > >>> support that. > >>> > >>> Note that we're not talking about an OpenJDK distribution -- this > >>> is an Oracle-branded 7u6 JRE. > >>> > >>> -- Scott K. > >> > >> Oracle JavaFX became redistributable with version 2.1. Prior to > >> that > >> there was a MP3 codec or something that could not be > >> redistributed. > >> I believe the current JavaFX 2.1 license already indicates that it > >> can be bundled with your application. > >> > > > > JavaFX maybe, but the whole JDK too? > > > The JRE has always been redistributable. The JDK hasn't as far as I > know. That probably applies to JavaFX as well. The SDK isn't > redistributable, but the runtime is. Read the license and the > documentation files that come with the JDK. They say what parts are > redistributable and what you aren't allowed to exclude etc. > Well, I know that the dropping of the DLJ (http://dlc.sun.com/dlj/DLJ-FAQ.html) has led to distros not being able to include the JDK any more. I don't know about the JRE; it's not a use case I've had to deal with. The licensing of OpenJDK is simpler (largely GPL) and FOSS, so, personally, I stick to that. > Scott P. > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07