From weijun.wang at oracle.com Thu Aug 2 06:41:33 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 02 Aug 2012 21:41:33 +0800 Subject: Code review request: 7184815 (was Re: OpenJDK krb5 ignore /etc/krb5.conf?) In-Reply-To: <500657BF.3020107@oracle.com> References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> <500602A2.9070803@oracle.com> <500657BF.3020107@oracle.com> Message-ID: <501A838D.40107@oracle.com> Ping again. On 07/18/2012 02:29 PM, Weijun Wang wrote: > 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 tobi at ultramixer.com Fri Aug 3 01:32:59 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 3 Aug 2012 10:32:59 +0200 Subject: [PATCH] Remove usage of private API In-Reply-To: References: Message-ID: <8B0AE5B6-D922-4958-8914-FCE39161DDC3@ultramixer.com> Hi Marco, did you have successfully submit your Java app to the AppStore? Best regards, -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com Am 30.07.2012 um 20:39 schrieb Marco Dinacci : > 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 jfinley at tech4learning.com Fri Aug 3 08:15:58 2012 From: jfinley at tech4learning.com (Jessica Finley) Date: Fri, 3 Aug 2012 09:15:58 -0600 Subject: JavaFX and Sandboxing Message-ID: <719A4A61-84EB-4B84-8670-2043655A3550@tech4learning.com> Hiya, It appears that JavaFX causes sandbox violations using Oracle's 1.7.0_5. I've written a test application that simply instantiates a JFXPanel and it causes the following violation: JavaAppLauncher(1716) deny sysctl-write Process: JavaAppLauncher [1716] Path: /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/MacOS/JavaAppLauncher Load Address: 0x101b86000 Identifier: com.test.JFXSandboxTest Version: 1.0 (4.0) Code Type: x86_64 (Native) Parent Process: launchd [144] Date/Time: 2012-08-03 08:52:47.933 -0600 OS Version: Mac OS X 10.8 (12A269) Report Version: 8 Thread 0: 0 libsystem_kernel.dylib 0x00007fff907385f2 __sysctl + 10 1 libglass.dylib 0x000000016a2a3481 -[GlassApplication runLoop:] + 2049 2 Foundation 0x00007fff90de68a7 __NSThreadPerformPerform + 225 3 CoreFoundation 0x00007fff971b4841 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 4 CoreFoundation 0x00007fff971b4165 __CFRunLoopDoSources0 + 245 5 CoreFoundation 0x00007fff971d74e5 __CFRunLoopRun + 789 6 CoreFoundation 0x00007fff971d6dd2 CFRunLoopRunSpecific + 290 7 HIToolbox 0x00007fff8fd27774 RunCurrentEventLoopInMode + 209 8 HIToolbox 0x00007fff8fd27512 ReceiveNextEventCommon + 356 9 HIToolbox 0x00007fff8fd273a3 BlockUntilNextEventMatchingListInMode + 62 10 AppKit 0x00007fff9661cfa3 _DPSNextEvent + 685 11 AppKit 0x00007fff9661c862 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 12 libosxapp.dylib 0x00000001625d282c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 13 AppKit 0x00007fff96613c03 -[NSApplication run] + 517 14 libosxapp.dylib 0x00000001625d274b +[NSApplicationAWT runAWTLoopWithApp:] + 156 15 liblwawt.dylib 0x0000000162531748 -[AWTStarter starter:] + 1587 16 Foundation 0x00007fff90de68a7 __NSThreadPerformPerform + 225 17 CoreFoundation 0x00007fff971b4841 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 18 CoreFoundation 0x00007fff971b4165 __CFRunLoopDoSources0 + 245 19 CoreFoundation 0x00007fff971d74e5 __CFRunLoopRun + 789 20 CoreFoundation 0x00007fff971d6dd2 CFRunLoopRunSpecific + 290 21 libjli.dylib 0x0000000101cf391c CreateExecutionEnvironment + 871 22 libjli.dylib 0x0000000101cee10c JLI_Launch + 1952 23 JavaAppLauncher 0x0000000101b889cb launch + 5035 24 JavaAppLauncher 0x0000000101b874f6 main + 102 25 JavaAppLauncher 0x0000000101b87484 start + 52 Binary Images: 0x101b86000 - 0x101b88ff7 com.test.JFXSandboxTest (4.0 - 1.0) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/MacOS/JavaAppLauncher 0x101ced000 - 0x101cf6fff com.oracle.java.7u05.jdk (1.0 - 1.7.0_05) <8F4E1D7E-D38A-377D-83D0-C12334A097A4> /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/MacOS/libjli.dylib 0x162524000 - 0x162590fff liblwawt.dylib (1) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/lwawt/liblwawt.dylib 0x1625d1000 - 0x1625d6fff libosxapp.dylib (1) <6B723FF5-4D8A-341E-A28B-D49F6D76CFA2> /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/libosxapp.dylib 0x16a2a0000 - 0x16a2d1fef libglass.dylib (0) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/libglass.dylib 0x7fff8fcc8000 - 0x7fff8fff7ff7 com.apple.HIToolbox (2.0) <49C4A53E-9239-3B9A-95DC-8C7B398E491D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x7fff90726000 - 0x7fff90741ff7 libsystem_kernel.dylib (2050.7.9) /usr/lib/system/libsystem_kernel.dylib 0x7fff90d54000 - 0x7fff910b0ff7 com.apple.Foundation (6.8 - 945) <0C972F73-0C07-3384-98F2-B176E0289494> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff964c6000 - 0x7fff970f0fff com.apple.AppKit (6.8 - 1187) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x7fff971a2000 - 0x7fff9738bfff com.apple.CoreFoundation (6.8 - 744) <47AEA7C7-EF9B-3FC6-AEBF-CE02FC650301> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation Does anyone else experience this problem? This seems like something that needs to be addressed, but I'm not sure if this is the correct venue in which to mention it. The test app and its source are available here: www.jmorganryan.com/JFXSandboxTest.zip Thanks, Jess From swpalmer at gmail.com Fri Aug 3 08:21:32 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 3 Aug 2012 11:21:32 -0400 Subject: JavaFX and Sandboxing In-Reply-To: <719A4A61-84EB-4B84-8670-2043655A3550@tech4learning.com> References: <719A4A61-84EB-4B84-8670-2043655A3550@tech4learning.com> Message-ID: On 2012-08-03, at 11:15 AM, Jessica Finley wrote: > Hiya, > > It appears that JavaFX causes sandbox violations using Oracle's 1.7.0_5. I've written a test application that simply instantiates a JFXPanel and it causes the following violation: > > JavaAppLauncher(1716) deny sysctl-write > > Process: JavaAppLauncher [1716] > Path: /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/MacOS/JavaAppLauncher > Load Address: 0x101b86000 > Identifier: com.test.JFXSandboxTest > Version: 1.0 (4.0) > Code Type: x86_64 (Native) > Parent Process: launchd [144] > > Date/Time: 2012-08-03 08:52:47.933 -0600 > OS Version: Mac OS X 10.8 (12A269) > Report Version: 8 > > Thread 0: > 0 libsystem_kernel.dylib 0x00007fff907385f2 __sysctl + 10 > 1 libglass.dylib 0x000000016a2a3481 -[GlassApplication runLoop:] + 2049 > 2 Foundation 0x00007fff90de68a7 __NSThreadPerformPerform + 225 > 3 CoreFoundation 0x00007fff971b4841 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 4 CoreFoundation 0x00007fff971b4165 __CFRunLoopDoSources0 + 245 > 5 CoreFoundation 0x00007fff971d74e5 __CFRunLoopRun + 789 > 6 CoreFoundation 0x00007fff971d6dd2 CFRunLoopRunSpecific + 290 > 7 HIToolbox 0x00007fff8fd27774 RunCurrentEventLoopInMode + 209 > 8 HIToolbox 0x00007fff8fd27512 ReceiveNextEventCommon + 356 > 9 HIToolbox 0x00007fff8fd273a3 BlockUntilNextEventMatchingListInMode + 62 > 10 AppKit 0x00007fff9661cfa3 _DPSNextEvent + 685 > 11 AppKit 0x00007fff9661c862 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 > 12 libosxapp.dylib 0x00000001625d282c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 > 13 AppKit 0x00007fff96613c03 -[NSApplication run] + 517 > 14 libosxapp.dylib 0x00000001625d274b +[NSApplicationAWT runAWTLoopWithApp:] + 156 > 15 liblwawt.dylib 0x0000000162531748 -[AWTStarter starter:] + 1587 > 16 Foundation 0x00007fff90de68a7 __NSThreadPerformPerform + 225 > 17 CoreFoundation 0x00007fff971b4841 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 18 CoreFoundation 0x00007fff971b4165 __CFRunLoopDoSources0 + 245 > 19 CoreFoundation 0x00007fff971d74e5 __CFRunLoopRun + 789 > 20 CoreFoundation 0x00007fff971d6dd2 CFRunLoopRunSpecific + 290 > 21 libjli.dylib 0x0000000101cf391c CreateExecutionEnvironment + 871 > 22 libjli.dylib 0x0000000101cee10c JLI_Launch + 1952 > 23 JavaAppLauncher 0x0000000101b889cb launch + 5035 > 24 JavaAppLauncher 0x0000000101b874f6 main + 102 > 25 JavaAppLauncher 0x0000000101b87484 start + 52 > > Binary Images: > 0x101b86000 - 0x101b88ff7 com.test.JFXSandboxTest (4.0 - 1.0) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/MacOS/JavaAppLauncher > 0x101ced000 - 0x101cf6fff com.oracle.java.7u05.jdk (1.0 - 1.7.0_05) <8F4E1D7E-D38A-377D-83D0-C12334A097A4> /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/MacOS/libjli.dylib > 0x162524000 - 0x162590fff liblwawt.dylib (1) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/lwawt/liblwawt.dylib > 0x1625d1000 - 0x1625d6fff libosxapp.dylib (1) <6B723FF5-4D8A-341E-A28B-D49F6D76CFA2> /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/libosxapp.dylib > 0x16a2a0000 - 0x16a2d1fef libglass.dylib (0) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/libglass.dylib > 0x7fff8fcc8000 - 0x7fff8fff7ff7 com.apple.HIToolbox (2.0) <49C4A53E-9239-3B9A-95DC-8C7B398E491D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox > 0x7fff90726000 - 0x7fff90741ff7 libsystem_kernel.dylib (2050.7.9) /usr/lib/system/libsystem_kernel.dylib > 0x7fff90d54000 - 0x7fff910b0ff7 com.apple.Foundation (6.8 - 945) <0C972F73-0C07-3384-98F2-B176E0289494> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation > 0x7fff964c6000 - 0x7fff970f0fff com.apple.AppKit (6.8 - 1187) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit > 0x7fff971a2000 - 0x7fff9738bfff com.apple.CoreFoundation (6.8 - 744) <47AEA7C7-EF9B-3FC6-AEBF-CE02FC650301> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > > > Does anyone else experience this problem? This seems like something that needs to be addressed, but I'm not sure if this is the correct venue in which to mention it. The test app and its source are available here: www.jmorganryan.com/JFXSandboxTest.zip > > Thanks, > Jess I haven't tried sandboxing any of my FX pas yet, but have you filed an issue for this at http://javafx-jira.kenai.com/ ? Scott P. From jfinley at tech4learning.com Fri Aug 3 08:37:55 2012 From: jfinley at tech4learning.com (Jessica Finley) Date: Fri, 3 Aug 2012 09:37:55 -0600 Subject: JavaFX and Sandboxing In-Reply-To: References: <719A4A61-84EB-4B84-8670-2043655A3550@tech4learning.com> Message-ID: <67CCD8C6-8E9A-409B-A869-C8DB5195D433@tech4learning.com> Thanks, I've submitted the issue: http://javafx-jira.kenai.com/browse/RT-23949 -Jess On Aug 3, 2012, at 9:21 AM, Scott Palmer wrote: > > On 2012-08-03, at 11:15 AM, Jessica Finley wrote: > >> Hiya, >> >> It appears that JavaFX causes sandbox violations using Oracle's 1.7.0_5. I've written a test application that simply instantiates a JFXPanel and it causes the following violation: >> >> JavaAppLauncher(1716) deny sysctl-write >> >> Process: JavaAppLauncher [1716] >> Path: /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/MacOS/JavaAppLauncher >> Load Address: 0x101b86000 >> Identifier: com.test.JFXSandboxTest >> Version: 1.0 (4.0) >> Code Type: x86_64 (Native) >> Parent Process: launchd [144] >> >> Date/Time: 2012-08-03 08:52:47.933 -0600 >> OS Version: Mac OS X 10.8 (12A269) >> Report Version: 8 >> >> Thread 0: >> 0 libsystem_kernel.dylib 0x00007fff907385f2 __sysctl + 10 >> 1 libglass.dylib 0x000000016a2a3481 -[GlassApplication runLoop:] + 2049 >> 2 Foundation 0x00007fff90de68a7 __NSThreadPerformPerform + 225 >> 3 CoreFoundation 0x00007fff971b4841 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >> 4 CoreFoundation 0x00007fff971b4165 __CFRunLoopDoSources0 + 245 >> 5 CoreFoundation 0x00007fff971d74e5 __CFRunLoopRun + 789 >> 6 CoreFoundation 0x00007fff971d6dd2 CFRunLoopRunSpecific + 290 >> 7 HIToolbox 0x00007fff8fd27774 RunCurrentEventLoopInMode + 209 >> 8 HIToolbox 0x00007fff8fd27512 ReceiveNextEventCommon + 356 >> 9 HIToolbox 0x00007fff8fd273a3 BlockUntilNextEventMatchingListInMode + 62 >> 10 AppKit 0x00007fff9661cfa3 _DPSNextEvent + 685 >> 11 AppKit 0x00007fff9661c862 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 >> 12 libosxapp.dylib 0x00000001625d282c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 >> 13 AppKit 0x00007fff96613c03 -[NSApplication run] + 517 >> 14 libosxapp.dylib 0x00000001625d274b +[NSApplicationAWT runAWTLoopWithApp:] + 156 >> 15 liblwawt.dylib 0x0000000162531748 -[AWTStarter starter:] + 1587 >> 16 Foundation 0x00007fff90de68a7 __NSThreadPerformPerform + 225 >> 17 CoreFoundation 0x00007fff971b4841 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >> 18 CoreFoundation 0x00007fff971b4165 __CFRunLoopDoSources0 + 245 >> 19 CoreFoundation 0x00007fff971d74e5 __CFRunLoopRun + 789 >> 20 CoreFoundation 0x00007fff971d6dd2 CFRunLoopRunSpecific + 290 >> 21 libjli.dylib 0x0000000101cf391c CreateExecutionEnvironment + 871 >> 22 libjli.dylib 0x0000000101cee10c JLI_Launch + 1952 >> 23 JavaAppLauncher 0x0000000101b889cb launch + 5035 >> 24 JavaAppLauncher 0x0000000101b874f6 main + 102 >> 25 JavaAppLauncher 0x0000000101b87484 start + 52 >> >> Binary Images: >> 0x101b86000 - 0x101b88ff7 com.test.JFXSandboxTest (4.0 - 1.0) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/MacOS/JavaAppLauncher >> 0x101ced000 - 0x101cf6fff com.oracle.java.7u05.jdk (1.0 - 1.7.0_05) <8F4E1D7E-D38A-377D-83D0-C12334A097A4> /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/MacOS/libjli.dylib >> 0x162524000 - 0x162590fff liblwawt.dylib (1) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/lwawt/liblwawt.dylib >> 0x1625d1000 - 0x1625d6fff libosxapp.dylib (1) <6B723FF5-4D8A-341E-A28B-D49F6D76CFA2> /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/libosxapp.dylib >> 0x16a2a0000 - 0x16a2d1fef libglass.dylib (0) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/libglass.dylib >> 0x7fff8fcc8000 - 0x7fff8fff7ff7 com.apple.HIToolbox (2.0) <49C4A53E-9239-3B9A-95DC-8C7B398E491D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox >> 0x7fff90726000 - 0x7fff90741ff7 libsystem_kernel.dylib (2050.7.9) /usr/lib/system/libsystem_kernel.dylib >> 0x7fff90d54000 - 0x7fff910b0ff7 com.apple.Foundation (6.8 - 945) <0C972F73-0C07-3384-98F2-B176E0289494> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation >> 0x7fff964c6000 - 0x7fff970f0fff com.apple.AppKit (6.8 - 1187) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit >> 0x7fff971a2000 - 0x7fff9738bfff com.apple.CoreFoundation (6.8 - 744) <47AEA7C7-EF9B-3FC6-AEBF-CE02FC650301> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation >> >> >> Does anyone else experience this problem? This seems like something that needs to be addressed, but I'm not sure if this is the correct venue in which to mention it. The test app and its source are available here: www.jmorganryan.com/JFXSandboxTest.zip >> >> Thanks, >> Jess > > > I haven't tried sandboxing any of my FX pas yet, but have you filed an issue for this at http://javafx-jira.kenai.com/ > ? > > Scott P. > From scott.kovatch at oracle.com Fri Aug 3 09:54:29 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 3 Aug 2012 09:54:29 -0700 Subject: JavaFX and Sandboxing In-Reply-To: <67CCD8C6-8E9A-409B-A869-C8DB5195D433@tech4learning.com> References: <719A4A61-84EB-4B84-8670-2043655A3550@tech4learning.com> <67CCD8C6-8E9A-409B-A869-C8DB5195D433@tech4learning.com> Message-ID: <60F4C3F4-54B9-4209-8905-1C4102557D82@oracle.com> I recently tried sandboxing with JavaFx and got the same violation, but I assumed it was in the networking code in the JDK. Looks like sandboxd doesn't like it when we set the name of the process: #0 0x00007fff92d3972c in sysctl () #1 0x00007fff92d38aad in setprogname () #2 0x0000000113203481 in -[GlassApplication runLoop:] () #3 0x00007fff939588a7 in __NSThreadPerformPerform () #4 0x00007fff93eea841 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ () #5 0x00007fff93eea165 in __CFRunLoopDoSources0 () #6 0x00007fff93f0d4e5 in __CFRunLoopRun () #7 0x00007fff93f0cdd2 in CFRunLoopRunSpecific () I don't see a workaround, either. Thanks for reporting it, though! -- Scott K. On Aug 3, 2012, at 8:37 AM, Jessica Finley wrote: > Thanks, I've submitted the issue: > http://javafx-jira.kenai.com/browse/RT-23949 > > -Jess > > On Aug 3, 2012, at 9:21 AM, Scott Palmer wrote: > >> >> On 2012-08-03, at 11:15 AM, Jessica Finley wrote: >> >>> Hiya, >>> >>> It appears that JavaFX causes sandbox violations using Oracle's 1.7.0_5. I've written a test application that simply instantiates a JFXPanel and it causes the following violation: >>> >>> JavaAppLauncher(1716) deny sysctl-write >>> >>> Process: JavaAppLauncher [1716] >>> Path: /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/MacOS/JavaAppLauncher >>> Load Address: 0x101b86000 >>> Identifier: com.test.JFXSandboxTest >>> Version: 1.0 (4.0) >>> Code Type: x86_64 (Native) >>> Parent Process: launchd [144] >>> >>> Date/Time: 2012-08-03 08:52:47.933 -0600 >>> OS Version: Mac OS X 10.8 (12A269) >>> Report Version: 8 >>> >>> Thread 0: >>> 0 libsystem_kernel.dylib 0x00007fff907385f2 __sysctl + 10 >>> 1 libglass.dylib 0x000000016a2a3481 -[GlassApplication runLoop:] + 2049 >>> 2 Foundation 0x00007fff90de68a7 __NSThreadPerformPerform + 225 >>> 3 CoreFoundation 0x00007fff971b4841 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >>> 4 CoreFoundation 0x00007fff971b4165 __CFRunLoopDoSources0 + 245 >>> 5 CoreFoundation 0x00007fff971d74e5 __CFRunLoopRun + 789 >>> 6 CoreFoundation 0x00007fff971d6dd2 CFRunLoopRunSpecific + 290 >>> 7 HIToolbox 0x00007fff8fd27774 RunCurrentEventLoopInMode + 209 >>> 8 HIToolbox 0x00007fff8fd27512 ReceiveNextEventCommon + 356 >>> 9 HIToolbox 0x00007fff8fd273a3 BlockUntilNextEventMatchingListInMode + 62 >>> 10 AppKit 0x00007fff9661cfa3 _DPSNextEvent + 685 >>> 11 AppKit 0x00007fff9661c862 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 >>> 12 libosxapp.dylib 0x00000001625d282c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 >>> 13 AppKit 0x00007fff96613c03 -[NSApplication run] + 517 >>> 14 libosxapp.dylib 0x00000001625d274b +[NSApplicationAWT runAWTLoopWithApp:] + 156 >>> 15 liblwawt.dylib 0x0000000162531748 -[AWTStarter starter:] + 1587 >>> 16 Foundation 0x00007fff90de68a7 __NSThreadPerformPerform + 225 >>> 17 CoreFoundation 0x00007fff971b4841 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >>> 18 CoreFoundation 0x00007fff971b4165 __CFRunLoopDoSources0 + 245 >>> 19 CoreFoundation 0x00007fff971d74e5 __CFRunLoopRun + 789 >>> 20 CoreFoundation 0x00007fff971d6dd2 CFRunLoopRunSpecific + 290 >>> 21 libjli.dylib 0x0000000101cf391c CreateExecutionEnvironment + 871 >>> 22 libjli.dylib 0x0000000101cee10c JLI_Launch + 1952 >>> 23 JavaAppLauncher 0x0000000101b889cb launch + 5035 >>> 24 JavaAppLauncher 0x0000000101b874f6 main + 102 >>> 25 JavaAppLauncher 0x0000000101b87484 start + 52 >>> >>> Binary Images: >>> 0x101b86000 - 0x101b88ff7 com.test.JFXSandboxTest (4.0 - 1.0) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/MacOS/JavaAppLauncher >>> 0x101ced000 - 0x101cf6fff com.oracle.java.7u05.jdk (1.0 - 1.7.0_05) <8F4E1D7E-D38A-377D-83D0-C12334A097A4> /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/MacOS/libjli.dylib >>> 0x162524000 - 0x162590fff liblwawt.dylib (1) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/lwawt/liblwawt.dylib >>> 0x1625d1000 - 0x1625d6fff libosxapp.dylib (1) <6B723FF5-4D8A-341E-A28B-D49F6D76CFA2> /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/libosxapp.dylib >>> 0x16a2a0000 - 0x16a2d1fef libglass.dylib (0) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/libglass.dylib >>> 0x7fff8fcc8000 - 0x7fff8fff7ff7 com.apple.HIToolbox (2.0) <49C4A53E-9239-3B9A-95DC-8C7B398E491D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox >>> 0x7fff90726000 - 0x7fff90741ff7 libsystem_kernel.dylib (2050.7.9) /usr/lib/system/libsystem_kernel.dylib >>> 0x7fff90d54000 - 0x7fff910b0ff7 com.apple.Foundation (6.8 - 945) <0C972F73-0C07-3384-98F2-B176E0289494> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation >>> 0x7fff964c6000 - 0x7fff970f0fff com.apple.AppKit (6.8 - 1187) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit >>> 0x7fff971a2000 - 0x7fff9738bfff com.apple.CoreFoundation (6.8 - 744) <47AEA7C7-EF9B-3FC6-AEBF-CE02FC650301> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation >>> >>> >>> Does anyone else experience this problem? This seems like something that needs to be addressed, but I'm not sure if this is the correct venue in which to mention it. The test app and its source are available here: www.jmorganryan.com/JFXSandboxTest.zip >>> >>> Thanks, >>> Jess >> >> >> I haven't tried sandboxing any of my FX pas yet, but have you filed an issue for this at http://javafx-jira.kenai.com/ >> ? >> >> Scott P. >> > > From jcpalmer at rochester.rr.com Fri Aug 3 10:49:04 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Fri, 3 Aug 2012 13:49:04 -0400 Subject: Using deployJava.js ? Message-ID: First, I assume deployJava.createWebStartLaunchButton() is going to work on OSX for Java 7. Am I correct? When can we test that an install occurs? 2nd, I am confused about what this OS X operating system change is. What is actually going to do the JRE install, the OS or the Java script? 3rd, ( a little off topic), I am in the process of building download webpages, & listing any browser caveats. Chome does not actually launch the jnlp, which is easy enough to describe a work around. Unfortunately, at page load of a file with deployJava.js a question overlay is brought up "Java needs your permission to run." I cannot find where responding negatively or just ignoring it has any effect. Is any code really running at page load? Do I need to un-install Java 7 (Windows) to make sure it always installs regardless of answer? What a pain that thing is. Thanks, Jeff Palmer From jcpalmer at rochester.rr.com Fri Aug 3 14:18:56 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Fri, 3 Aug 2012 17:18:56 -0400 Subject: Using deployJava.js ? In-Reply-To: References: Message-ID: <4A2139F0-2280-44E8-85CD-D6B82D968977@rochester.rr.com> Found after un-installing the Java 7 JRE, Chrome will move to a page to install Java no matter what. It did not go back to the return page when done. I have no idea what that permission to run is for. Forget about the Chrome part. Still interested in the first 2. Just looked, see MT launched. Is this operating system change already in it, or do I need to provide directions on getting it? Thanks, Jeff Palmer On Aug 3, 2012, at 1:49 PM, Jeff Palmer wrote: > First, I assume deployJava.createWebStartLaunchButton() is going to work on OSX for Java 7. Am I correct? When can we test that an install occurs? > > 2nd, I am confused about what this OS X operating system change is. What is actually going to do the JRE install, the OS or the Java script? > > 3rd, ( a little off topic), I am in the process of building download webpages, & listing any browser caveats. Chome does not actually launch the jnlp, which is easy enough to describe a work around. Unfortunately, at page load of a file with deployJava.js a question overlay is brought up "Java needs your permission to run." I cannot find where responding negatively or just ignoring it has any effect. Is any code really running at page load? Do I need to un-install Java 7 (Windows) to make sure it always installs regardless of answer? What a pain that thing is. > > Thanks, > > Jeff Palmer From swingler at apple.com Sun Aug 5 16:48:41 2012 From: swingler at apple.com (Mike Swingler) Date: Sun, 05 Aug 2012 16:48: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: > 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. The JavaRuntimeSupport.framework/Headers/JRSFont.h has API to configure a CGContextRef to render glyphs and runs onto integer aligned metrics, as well as get sizes, measurements, and fallback fonts. I'm actually quite surprised the OpenJDK has references to these internal SPI, since our Apple Java SE 6 has been converted over to use JRSFont.h for quite a long time. Regards, Mike Swingler Apple Inc. From swingler at apple.com Sun Aug 5 17:34:33 2012 From: swingler at apple.com (Mike Swingler) Date: Sun, 05 Aug 2012 17:34:33 -0700 Subject: Using JAWT CALayer with QT In-Reply-To: References: Message-ID: Does anyone know if there is a bug tracking the creation of an OS X-specifc jawt_md.h? I'm not seeing one in either the jdk8 or the jdk7u-* repositories, and this is a pretty crucial part of the JNI story to be leaning on Apple's deprecated JavaVM.framework. ~Mike On May 21, 2012, at 2:55 PM, Jessica Finley wrote: > Update for posterity: > > So, I changed the awt.version back to JAWT_VERSION_1_4 and referenced the instead of the JDK7 jawt_md.h (while continuing to link to the Java7 libs instead of the JavaVM framework) and it works! > > That seems odd to "mix and match" like that, but I suppose it makes sense. I need Apple's header to define some stuff for me, yet I need JDK 7's libraries to do the execution. > > Thanks, > Jess > > On May 21, 2012, at 1:41 PM, Jessica Finley wrote: > >> So, I've modified the project to not use the JavaVM framework, and to instead point to jdk1.7.0_06.jdk/Contents/Home/jre/include headers and associated libraries (libawt.dylib, libjawt.dylib). I left out the NativeDrawnCanvas.java and DrawingCanvas.m classes, since they use deprecated NSView based drawing. Additionally, I modified the awt.version in LayerCanvas.m to be >> awt.version = JAWT_VERSION_1_7 | JAWT_MACOSX_USE_CALAYER; // opt into the CALayer model >> >> Now, when I run the application, I no longer get the error ([java] JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM), but instead the canvas doesn't draw anything at all. I get no warnings about loading the resources for the layers or anything like that, so I'm assuming it's finding them (I made changes so instead of referencing the resources from the app bundle, they are referenced absolutely on the file system). >> >> Any ideas as to why nothing is being drawn at all? Let me know if you want my modified example project to take a look at. >> >> Has anyone gotten any sort of CALayer drawing working with Java 7? At this point, I'm not as much interested in QT specifics as much as just getting _something_ working. >> >> Thanks, >> Jess >> >> >> On May 17, 2012, at 3:55 PM, Jessica Finley wrote: >> >>> Hiya folks, >>> >>> It is my understanding that we are to use CALayer based embedding now instead of NSView based embedding. Can someone explain to me how to do so? Primarily, I am interested in playing a QT movie. I've been looking at the JAWTExample project located here: >>> >>> https://developer.apple.com/library/mac/#samplecode/JAWTExample/Introduction/Intro.html#//apple_ref/doc/uid/DTS10000683-Intro-DontLinkElementID_2 >>> >>> Which works beautifully in Java 6, but no so much in Java 7. When run in Java 7 (after some finagling to launch the jar outside of its app bundle so it will run in Java 7), I get the following error when trying to draw the included QT movie: >>> [java] JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM >>> >>> I'm not really sure why this doesn't work in Java 7, since it is using CALayer embedding, as it should? I think. >>> >>> Thanks! >>> -Jess >> > > From swingler at apple.com Sun Aug 5 17:53:34 2012 From: swingler at apple.com (Mike Swingler) Date: Sun, 05 Aug 2012 17:53:34 -0700 Subject: styled JTextPane In-Reply-To: <71D8F3E0-A444-4CDE-9011-2EDA7E45525D@gmail.com> References: <630D88F6-B8C0-4DB2-9A11-85AFF785F546@gmail.com> <71D8F3E0-A444-4CDE-9011-2EDA7E45525D@gmail.com> Message-ID: <0E700893-B21E-4BAD-8F21-466721BC8304@apple.com> On Apr 19, 2012, at 6:45 PM, Michael Hall wrote: > > As I indicated earlier this does appear to be a separate issue. > I'm not 100% sure again though that it is a bug. It is different from 1.6. > Test case.... > > import javax.swing.*; > import javax.swing.text.*; > > public class StyledTest extends JTextPane { > > private static final StyleContext sc = new StyleContext(); > private static final DefaultStyledDocument doc = new DefaultStyledDocument(sc); > static final Style mono = sc.addStyle("mono",null); > > public static void main(String[] args) { > JFrame f = new JFrame("StyledTest"); > f.setMinimumSize(new java.awt.Dimension(100,100)); > StyledTest st = new StyledTest(); > f.add(st); > f.pack(); > f.setVisible(true); > SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > doc.insertString(0,"AaBbCcDd\nEeFfGgHh",mono); > } > catch (BadLocationException blex) { > blex.printStackTrace(); > } > }}); > } > > public StyledTest() { > setStyledDocument(doc); > StyleConstants.setFontFamily(mono,"monospaced"); > } > } > > Run on 1.6 you get a smaller serifed font that could be monospaced. > Run on 1.7 you get a larger non-serified font that, well, still just might be monospaced. > Bug or incidental change? > Strictly as opinion probably biased to what I'm used to, assuming both are correctly monospaced output, I like the smaller serifed better, it tends to stand out as different a little better in my application. > Not a voting situation? The difference is between "Courier" (1.6) and "Menlo" (1.7), and both are monospaced. We (Apple's JDK team) decided to change the default to Menlo at the time we contributed our font code to the OpenJDK project because Menlo had become the platform standard monospaced font for other applications (like Xcode). Regards, Mike Swingler Apple Inc. From jost0x2c at gmail.com Mon Aug 6 00:45:56 2012 From: jost0x2c at gmail.com (jost) Date: Mon, 6 Aug 2012 09:45:56 +0200 Subject: Using JAWT CALayer with QT In-Reply-To: References: Message-ID: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181710 jost On Mon, Aug 6, 2012 at 2:34 AM, Mike Swingler wrote: > Does anyone know if there is a bug tracking the creation of an OS > X-specifc jawt_md.h? I'm not seeing one in either the jdk8 or the jdk7u-* > repositories, and this is a pretty crucial part of the JNI story to be > leaning on Apple's deprecated JavaVM.framework. > > ~Mike > > On May 21, 2012, at 2:55 PM, Jessica Finley > wrote: > > > Update for posterity: > > > > So, I changed the awt.version back to JAWT_VERSION_1_4 and referenced > the instead of the JDK7 jawt_md.h (while continuing to > link to the Java7 libs instead of the JavaVM framework) and it works! > > > > That seems odd to "mix and match" like that, but I suppose it makes > sense. I need Apple's header to define some stuff for me, yet I need JDK > 7's libraries to do the execution. > > > > Thanks, > > Jess > > > > On May 21, 2012, at 1:41 PM, Jessica Finley wrote: > > > >> So, I've modified the project to not use the JavaVM framework, and to > instead point to jdk1.7.0_06.jdk/Contents/Home/jre/include headers and > associated libraries (libawt.dylib, libjawt.dylib). I left out the > NativeDrawnCanvas.java and DrawingCanvas.m classes, since they use > deprecated NSView based drawing. Additionally, I modified the awt.version > in LayerCanvas.m to be > >> awt.version = JAWT_VERSION_1_7 | JAWT_MACOSX_USE_CALAYER; // opt into > the CALayer model > >> > >> Now, when I run the application, I no longer get the error ([java] > JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM), but > instead the canvas doesn't draw anything at all. I get no warnings about > loading the resources for the layers or anything like that, so I'm assuming > it's finding them (I made changes so instead of referencing the resources > from the app bundle, they are referenced absolutely on the file system). > >> > >> Any ideas as to why nothing is being drawn at all? Let me know if you > want my modified example project to take a look at. > >> > >> Has anyone gotten any sort of CALayer drawing working with Java 7? At > this point, I'm not as much interested in QT specifics as much as just > getting _something_ working. > >> > >> Thanks, > >> Jess > >> > >> > >> On May 17, 2012, at 3:55 PM, Jessica Finley wrote: > >> > >>> Hiya folks, > >>> > >>> It is my understanding that we are to use CALayer based embedding now > instead of NSView based embedding. Can someone explain to me how to do so? > Primarily, I am interested in playing a QT movie. I've been looking at > the JAWTExample project located here: > >>> > >>> > https://developer.apple.com/library/mac/#samplecode/JAWTExample/Introduction/Intro.html#//apple_ref/doc/uid/DTS10000683-Intro-DontLinkElementID_2 > >>> > >>> Which works beautifully in Java 6, but no so much in Java 7. When run > in Java 7 (after some finagling to launch the jar outside of its app bundle > so it will run in Java 7), I get the following error when trying to draw > the included QT movie: > >>> [java] JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM > >>> > >>> I'm not really sure why this doesn't work in Java 7, since it is using > CALayer embedding, as it should? I think. > >>> > >>> Thanks! > >>> -Jess > >> > > > > > > From sierkb at gmx.de Mon Aug 6 00:53:19 2012 From: sierkb at gmx.de (sierkb at gmx.de) Date: Mon, 6 Aug 2012 09:53:19 +0200 Subject: Bug: Typo, wrong Symlink path to JavaControlPanel.prefPane on Mac OS X port of JDK7 Update 6 Build 22 Message-ID: <04F3C8CA-F7AE-47DF-BCE3-F0D11C07941C@gmx.de> Bug Report (Bug ID: 7189314): ========== Synopsis: ------------- Typo, wrong Symlink path to JavaControlPanel.prefPane on Mac OS X port of JDK7 Update 6 Build 22 Full OS version: ---------------------- Mac OS X Lion 10.7.4 (11E53) Development Kit or Runtime version: -------------------------------------------------- $ /usr/libexec/java_home --exec java -version java version "1.7.0_06" Java(TM) SE Runtime Environment (build 1.7.0_06-b22) Java HotSpot(TM) 64-Bit Server VM (build 23.2-b09, mixed mode) Description: ---------------- The Symlink to the Preference Pane in /Library/PreferencePanes is set falsely by the installer. There is a typo in it which prevents the PreferencePane to be launched. ATTENTION: INCORRECT is (as time of writing): sudo ln -s /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/deploy/JavaControlPanel.prefpane /Library/PreferencePanes/JavaControlPanel.prefpane CORRECT would be: sudo ln -s /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/deploy/JavaControlPanel.prefPane /Library/PreferencePanes/JavaControlPanel.prefPane REMEMBER: Remember the lower "p" (incorrect) versus the upper "P" (correct) in the word "prefpane" (incorrect) versus "prefPane" (correct) of the phrase "JavaControlPanel.prefPane" This bug is part of the latest FCS-build of JDK7u6-b22 on http://jdk7.java.net/download.html http://www.java.net/download/jdk7u6/archive/b22/binaries/jdk-7u6-fcs-bin-b22-macosx-x86_64-01_aug_2012.dmg as well as part of the official public OTN-builds on http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1637583.html http://download.oracle.com/otn-pub/java/jdk/7u6-b22/jdk-7u6-macosx-x64.dmg Steps to Reproduce: ---------------------------- Install jdk-7u6-fcs-bin-b22-macosx-x86_64-01_aug_2012.dmg or jdk-7u6-macosx-x64.dmg $ ls -l /Library/PreferencePanes Expected Result: ----------------------- lrwxr-xr-x 1 root wheel 101 6 Aug 08:53 JavaControlPanel.prefPane -> /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/deploy/JavaControlPanel.prefPane Actual Result: ------------------- lrwxr-xr-x 1 root wheel 101 6 Aug 08:53 JavaControlPanel.prefpane -> /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/deploy/JavaControlPanel.prefpane Workaround: ------------------ $ sudo rm /Library/PreferencePanes/JavaControlPanel.prefpane $ sudo ln -s /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/deploy/JavaControlPanel.prefPane /Library/PreferencePanes/JavaControlPanel.prefPane From artem.ananiev at oracle.com Mon Aug 6 05:51:34 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 06 Aug 2012 16:51:34 +0400 Subject: JavaFX and Sandboxing In-Reply-To: <60F4C3F4-54B9-4209-8905-1C4102557D82@oracle.com> References: <719A4A61-84EB-4B84-8670-2043655A3550@tech4learning.com> <67CCD8C6-8E9A-409B-A869-C8DB5195D433@tech4learning.com> <60F4C3F4-54B9-4209-8905-1C4102557D82@oracle.com> Message-ID: <501FBDD6.4010609@oracle.com> Scott, Jessica, this stack below is different from what reported in RT-23949: initially reported one doesn't contain setprogname(). This call preceded by [NSProcessInfo setProcessName], which seems to be the right way for sandboxed applications. I'm not an OS X expert, so I can't say why we have both calls in JFX and whether it will be enough to leave the first one only. Thanks, Artem On 8/3/2012 8:54 PM, Scott Kovatch wrote: > I recently tried sandboxing with JavaFx and got the same violation, but I assumed it was in the networking code in the JDK. > > Looks like sandboxd doesn't like it when we set the name of the process: > > #0 0x00007fff92d3972c in sysctl () > #1 0x00007fff92d38aad in setprogname () > #2 0x0000000113203481 in -[GlassApplication runLoop:] () > #3 0x00007fff939588a7 in __NSThreadPerformPerform () > #4 0x00007fff93eea841 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ () > #5 0x00007fff93eea165 in __CFRunLoopDoSources0 () > #6 0x00007fff93f0d4e5 in __CFRunLoopRun () > #7 0x00007fff93f0cdd2 in CFRunLoopRunSpecific () > > I don't see a workaround, either. > > Thanks for reporting it, though! > > -- Scott K. > > On Aug 3, 2012, at 8:37 AM, Jessica Finley wrote: > >> Thanks, I've submitted the issue: >> http://javafx-jira.kenai.com/browse/RT-23949 >> >> -Jess >> >> On Aug 3, 2012, at 9:21 AM, Scott Palmer wrote: >> >>> >>> On 2012-08-03, at 11:15 AM, Jessica Finley wrote: >>> >>>> Hiya, >>>> >>>> It appears that JavaFX causes sandbox violations using Oracle's 1.7.0_5. I've written a test application that simply instantiates a JFXPanel and it causes the following violation: >>>> >>>> JavaAppLauncher(1716) deny sysctl-write >>>> >>>> Process: JavaAppLauncher [1716] >>>> Path: /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/MacOS/JavaAppLauncher >>>> Load Address: 0x101b86000 >>>> Identifier: com.test.JFXSandboxTest >>>> Version: 1.0 (4.0) >>>> Code Type: x86_64 (Native) >>>> Parent Process: launchd [144] >>>> >>>> Date/Time: 2012-08-03 08:52:47.933 -0600 >>>> OS Version: Mac OS X 10.8 (12A269) >>>> Report Version: 8 >>>> >>>> Thread 0: >>>> 0 libsystem_kernel.dylib 0x00007fff907385f2 __sysctl + 10 >>>> 1 libglass.dylib 0x000000016a2a3481 -[GlassApplication runLoop:] + 2049 >>>> 2 Foundation 0x00007fff90de68a7 __NSThreadPerformPerform + 225 >>>> 3 CoreFoundation 0x00007fff971b4841 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >>>> 4 CoreFoundation 0x00007fff971b4165 __CFRunLoopDoSources0 + 245 >>>> 5 CoreFoundation 0x00007fff971d74e5 __CFRunLoopRun + 789 >>>> 6 CoreFoundation 0x00007fff971d6dd2 CFRunLoopRunSpecific + 290 >>>> 7 HIToolbox 0x00007fff8fd27774 RunCurrentEventLoopInMode + 209 >>>> 8 HIToolbox 0x00007fff8fd27512 ReceiveNextEventCommon + 356 >>>> 9 HIToolbox 0x00007fff8fd273a3 BlockUntilNextEventMatchingListInMode + 62 >>>> 10 AppKit 0x00007fff9661cfa3 _DPSNextEvent + 685 >>>> 11 AppKit 0x00007fff9661c862 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 >>>> 12 libosxapp.dylib 0x00000001625d282c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 >>>> 13 AppKit 0x00007fff96613c03 -[NSApplication run] + 517 >>>> 14 libosxapp.dylib 0x00000001625d274b +[NSApplicationAWT runAWTLoopWithApp:] + 156 >>>> 15 liblwawt.dylib 0x0000000162531748 -[AWTStarter starter:] + 1587 >>>> 16 Foundation 0x00007fff90de68a7 __NSThreadPerformPerform + 225 >>>> 17 CoreFoundation 0x00007fff971b4841 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >>>> 18 CoreFoundation 0x00007fff971b4165 __CFRunLoopDoSources0 + 245 >>>> 19 CoreFoundation 0x00007fff971d74e5 __CFRunLoopRun + 789 >>>> 20 CoreFoundation 0x00007fff971d6dd2 CFRunLoopRunSpecific + 290 >>>> 21 libjli.dylib 0x0000000101cf391c CreateExecutionEnvironment + 871 >>>> 22 libjli.dylib 0x0000000101cee10c JLI_Launch + 1952 >>>> 23 JavaAppLauncher 0x0000000101b889cb launch + 5035 >>>> 24 JavaAppLauncher 0x0000000101b874f6 main + 102 >>>> 25 JavaAppLauncher 0x0000000101b87484 start + 52 >>>> >>>> Binary Images: >>>> 0x101b86000 - 0x101b88ff7 com.test.JFXSandboxTest (4.0 - 1.0) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/MacOS/JavaAppLauncher >>>> 0x101ced000 - 0x101cf6fff com.oracle.java.7u05.jdk (1.0 - 1.7.0_05)<8F4E1D7E-D38A-377D-83D0-C12334A097A4> /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/MacOS/libjli.dylib >>>> 0x162524000 - 0x162590fff liblwawt.dylib (1) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/lwawt/liblwawt.dylib >>>> 0x1625d1000 - 0x1625d6fff libosxapp.dylib (1)<6B723FF5-4D8A-341E-A28B-D49F6D76CFA2> /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/libosxapp.dylib >>>> 0x16a2a0000 - 0x16a2d1fef libglass.dylib (0) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/libglass.dylib >>>> 0x7fff8fcc8000 - 0x7fff8fff7ff7 com.apple.HIToolbox (2.0)<49C4A53E-9239-3B9A-95DC-8C7B398E491D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox >>>> 0x7fff90726000 - 0x7fff90741ff7 libsystem_kernel.dylib (2050.7.9) /usr/lib/system/libsystem_kernel.dylib >>>> 0x7fff90d54000 - 0x7fff910b0ff7 com.apple.Foundation (6.8 - 945)<0C972F73-0C07-3384-98F2-B176E0289494> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation >>>> 0x7fff964c6000 - 0x7fff970f0fff com.apple.AppKit (6.8 - 1187) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit >>>> 0x7fff971a2000 - 0x7fff9738bfff com.apple.CoreFoundation (6.8 - 744)<47AEA7C7-EF9B-3FC6-AEBF-CE02FC650301> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation >>>> >>>> >>>> Does anyone else experience this problem? This seems like something that needs to be addressed, but I'm not sure if this is the correct venue in which to mention it. The test app and its source are available here: www.jmorganryan.com/JFXSandboxTest.zip >>>> >>>> Thanks, >>>> Jess >>> >>> >>> I haven't tried sandboxing any of my FX pas yet, but have you filed an issue for this at http://javafx-jira.kenai.com/ >>> ? >>> >>> Scott P. >>> >> >> > From artem.ananiev at oracle.com Mon Aug 6 05:55:34 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 06 Aug 2012 16:55:34 +0400 Subject: Using JAWT CALayer with QT In-Reply-To: References: Message-ID: <501FBEC6.3070805@oracle.com> On 8/6/2012 11:45 AM, jost wrote: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181710 Thanks. Artem > jost > > On Mon, Aug 6, 2012 at 2:34 AM, Mike Swingler wrote: > >> Does anyone know if there is a bug tracking the creation of an OS >> X-specifc jawt_md.h? I'm not seeing one in either the jdk8 or the jdk7u-* >> repositories, and this is a pretty crucial part of the JNI story to be >> leaning on Apple's deprecated JavaVM.framework. >> >> ~Mike >> >> On May 21, 2012, at 2:55 PM, Jessica Finley >> wrote: >> >>> Update for posterity: >>> >>> So, I changed the awt.version back to JAWT_VERSION_1_4 and referenced >> the instead of the JDK7 jawt_md.h (while continuing to >> link to the Java7 libs instead of the JavaVM framework) and it works! >>> >>> That seems odd to "mix and match" like that, but I suppose it makes >> sense. I need Apple's header to define some stuff for me, yet I need JDK >> 7's libraries to do the execution. >>> >>> Thanks, >>> Jess >>> >>> On May 21, 2012, at 1:41 PM, Jessica Finley wrote: >>> >>>> So, I've modified the project to not use the JavaVM framework, and to >> instead point to jdk1.7.0_06.jdk/Contents/Home/jre/include headers and >> associated libraries (libawt.dylib, libjawt.dylib). I left out the >> NativeDrawnCanvas.java and DrawingCanvas.m classes, since they use >> deprecated NSView based drawing. Additionally, I modified the awt.version >> in LayerCanvas.m to be >>>> awt.version = JAWT_VERSION_1_7 | JAWT_MACOSX_USE_CALAYER; // opt into >> the CALayer model >>>> >>>> Now, when I run the application, I no longer get the error ([java] >> JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM), but >> instead the canvas doesn't draw anything at all. I get no warnings about >> loading the resources for the layers or anything like that, so I'm assuming >> it's finding them (I made changes so instead of referencing the resources >> from the app bundle, they are referenced absolutely on the file system). >>>> >>>> Any ideas as to why nothing is being drawn at all? Let me know if you >> want my modified example project to take a look at. >>>> >>>> Has anyone gotten any sort of CALayer drawing working with Java 7? At >> this point, I'm not as much interested in QT specifics as much as just >> getting _something_ working. >>>> >>>> Thanks, >>>> Jess >>>> >>>> >>>> On May 17, 2012, at 3:55 PM, Jessica Finley wrote: >>>> >>>>> Hiya folks, >>>>> >>>>> It is my understanding that we are to use CALayer based embedding now >> instead of NSView based embedding. Can someone explain to me how to do so? >> Primarily, I am interested in playing a QT movie. I've been looking at >> the JAWTExample project located here: >>>>> >>>>> >> https://developer.apple.com/library/mac/#samplecode/JAWTExample/Introduction/Intro.html#//apple_ref/doc/uid/DTS10000683-Intro-DontLinkElementID_2 >>>>> >>>>> Which works beautifully in Java 6, but no so much in Java 7. When run >> in Java 7 (after some finagling to launch the jar outside of its app bundle >> so it will run in Java 7), I get the following error when trying to draw >> the included QT movie: >>>>> [java] JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM >>>>> >>>>> I'm not really sure why this doesn't work in Java 7, since it is using >> CALayer embedding, as it should? I think. >>>>> >>>>> Thanks! >>>>> -Jess >>>> >>> >>> >> >> From scott.kovatch at oracle.com Mon Aug 6 08:25:17 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 6 Aug 2012 08:25:17 -0700 Subject: JavaFX and Sandboxing In-Reply-To: <501FBDD6.4010609@oracle.com> References: <719A4A61-84EB-4B84-8670-2043655A3550@tech4learning.com> <67CCD8C6-8E9A-409B-A869-C8DB5195D433@tech4learning.com> <60F4C3F4-54B9-4209-8905-1C4102557D82@oracle.com> <501FBDD6.4010609@oracle.com> Message-ID: <7CF0D7BB-4EEB-44D8-BDCC-AF7C53CF8955@oracle.com> Yes, the stack is different. Jessica's bug is against 7u5, so it would have to have Fx 2.1, I think. My test was with 7u6-b21, with the latest JavaFx. We should look into why we need to call setprogname or setProcessName if we are a bundled app. If the app is bundled the OS should take care of everything for us. -- Scott On Aug 6, 2012, at 5:51 AM, Artem Ananiev wrote: > Scott, Jessica, > > this stack below is different from what reported in RT-23949: initially reported one doesn't contain setprogname(). This call preceded by [NSProcessInfo setProcessName], which seems to be the right way for sandboxed applications. I'm not an OS X expert, so I can't say why we have both calls in JFX and whether it will be enough to leave the first one only. > > Thanks, > > Artem > > On 8/3/2012 8:54 PM, Scott Kovatch wrote: >> I recently tried sandboxing with JavaFx and got the same violation, but I assumed it was in the networking code in the JDK. >> >> Looks like sandboxd doesn't like it when we set the name of the process: >> >> #0 0x00007fff92d3972c in sysctl () >> #1 0x00007fff92d38aad in setprogname () >> #2 0x0000000113203481 in -[GlassApplication runLoop:] () >> #3 0x00007fff939588a7 in __NSThreadPerformPerform () >> #4 0x00007fff93eea841 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ () >> #5 0x00007fff93eea165 in __CFRunLoopDoSources0 () >> #6 0x00007fff93f0d4e5 in __CFRunLoopRun () >> #7 0x00007fff93f0cdd2 in CFRunLoopRunSpecific () >> >> I don't see a workaround, either. >> >> Thanks for reporting it, though! >> >> -- Scott K. >> >> On Aug 3, 2012, at 8:37 AM, Jessica Finley wrote: >> >>> Thanks, I've submitted the issue: >>> http://javafx-jira.kenai.com/browse/RT-23949 >>> >>> -Jess >>> >>> On Aug 3, 2012, at 9:21 AM, Scott Palmer wrote: >>> >>>> >>>> On 2012-08-03, at 11:15 AM, Jessica Finley wrote: >>>> >>>>> Hiya, >>>>> >>>>> It appears that JavaFX causes sandbox violations using Oracle's 1.7.0_5. I've written a test application that simply instantiates a JFXPanel and it causes the following violation: >>>>> >>>>> JavaAppLauncher(1716) deny sysctl-write >>>>> >>>>> Process: JavaAppLauncher [1716] >>>>> Path: /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/MacOS/JavaAppLauncher >>>>> Load Address: 0x101b86000 >>>>> Identifier: com.test.JFXSandboxTest >>>>> Version: 1.0 (4.0) >>>>> Code Type: x86_64 (Native) >>>>> Parent Process: launchd [144] >>>>> >>>>> Date/Time: 2012-08-03 08:52:47.933 -0600 >>>>> OS Version: Mac OS X 10.8 (12A269) >>>>> Report Version: 8 >>>>> >>>>> Thread 0: >>>>> 0 libsystem_kernel.dylib 0x00007fff907385f2 __sysctl + 10 >>>>> 1 libglass.dylib 0x000000016a2a3481 -[GlassApplication runLoop:] + 2049 >>>>> 2 Foundation 0x00007fff90de68a7 __NSThreadPerformPerform + 225 >>>>> 3 CoreFoundation 0x00007fff971b4841 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >>>>> 4 CoreFoundation 0x00007fff971b4165 __CFRunLoopDoSources0 + 245 >>>>> 5 CoreFoundation 0x00007fff971d74e5 __CFRunLoopRun + 789 >>>>> 6 CoreFoundation 0x00007fff971d6dd2 CFRunLoopRunSpecific + 290 >>>>> 7 HIToolbox 0x00007fff8fd27774 RunCurrentEventLoopInMode + 209 >>>>> 8 HIToolbox 0x00007fff8fd27512 ReceiveNextEventCommon + 356 >>>>> 9 HIToolbox 0x00007fff8fd273a3 BlockUntilNextEventMatchingListInMode + 62 >>>>> 10 AppKit 0x00007fff9661cfa3 _DPSNextEvent + 685 >>>>> 11 AppKit 0x00007fff9661c862 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 >>>>> 12 libosxapp.dylib 0x00000001625d282c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 >>>>> 13 AppKit 0x00007fff96613c03 -[NSApplication run] + 517 >>>>> 14 libosxapp.dylib 0x00000001625d274b +[NSApplicationAWT runAWTLoopWithApp:] + 156 >>>>> 15 liblwawt.dylib 0x0000000162531748 -[AWTStarter starter:] + 1587 >>>>> 16 Foundation 0x00007fff90de68a7 __NSThreadPerformPerform + 225 >>>>> 17 CoreFoundation 0x00007fff971b4841 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >>>>> 18 CoreFoundation 0x00007fff971b4165 __CFRunLoopDoSources0 + 245 >>>>> 19 CoreFoundation 0x00007fff971d74e5 __CFRunLoopRun + 789 >>>>> 20 CoreFoundation 0x00007fff971d6dd2 CFRunLoopRunSpecific + 290 >>>>> 21 libjli.dylib 0x0000000101cf391c CreateExecutionEnvironment + 871 >>>>> 22 libjli.dylib 0x0000000101cee10c JLI_Launch + 1952 >>>>> 23 JavaAppLauncher 0x0000000101b889cb launch + 5035 >>>>> 24 JavaAppLauncher 0x0000000101b874f6 main + 102 >>>>> 25 JavaAppLauncher 0x0000000101b87484 start + 52 >>>>> >>>>> Binary Images: >>>>> 0x101b86000 - 0x101b88ff7 com.test.JFXSandboxTest (4.0 - 1.0) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/MacOS/JavaAppLauncher >>>>> 0x101ced000 - 0x101cf6fff com.oracle.java.7u05.jdk (1.0 - 1.7.0_05)<8F4E1D7E-D38A-377D-83D0-C12334A097A4> /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/MacOS/libjli.dylib >>>>> 0x162524000 - 0x162590fff liblwawt.dylib (1) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/lwawt/liblwawt.dylib >>>>> 0x1625d1000 - 0x1625d6fff libosxapp.dylib (1)<6B723FF5-4D8A-341E-A28B-D49F6D76CFA2> /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/libosxapp.dylib >>>>> 0x16a2a0000 - 0x16a2d1fef libglass.dylib (0) /Users/jfinley/JDev/JavaFX/JFXSandboxTest/JFXSandboxTest/JFXSandboxTest.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/libglass.dylib >>>>> 0x7fff8fcc8000 - 0x7fff8fff7ff7 com.apple.HIToolbox (2.0)<49C4A53E-9239-3B9A-95DC-8C7B398E491D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox >>>>> 0x7fff90726000 - 0x7fff90741ff7 libsystem_kernel.dylib (2050.7.9) /usr/lib/system/libsystem_kernel.dylib >>>>> 0x7fff90d54000 - 0x7fff910b0ff7 com.apple.Foundation (6.8 - 945)<0C972F73-0C07-3384-98F2-B176E0289494> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation >>>>> 0x7fff964c6000 - 0x7fff970f0fff com.apple.AppKit (6.8 - 1187) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit >>>>> 0x7fff971a2000 - 0x7fff9738bfff com.apple.CoreFoundation (6.8 - 744)<47AEA7C7-EF9B-3FC6-AEBF-CE02FC650301> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation >>>>> >>>>> >>>>> Does anyone else experience this problem? This seems like something that needs to be addressed, but I'm not sure if this is the correct venue in which to mention it. The test app and its source are available here: www.jmorganryan.com/JFXSandboxTest.zip >>>>> >>>>> Thanks, >>>>> Jess >>>> >>>> >>>> I haven't tried sandboxing any of my FX pas yet, but have you filed an issue for this at http://javafx-jira.kenai.com/ >>>> ? >>>> >>>> Scott P. >>>> >>> >>> >> From scott.kovatch at oracle.com Mon Aug 6 22:36:27 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 6 Aug 2012 22:36:27 -0700 Subject: Bug: Typo, wrong Symlink path to JavaControlPanel.prefPane on Mac OS X port of JDK7 Update 6 Build 22 In-Reply-To: <04F3C8CA-F7AE-47DF-BCE3-F0D11C07941C@gmx.de> References: <04F3C8CA-F7AE-47DF-BCE3-F0D11C07941C@gmx.de> Message-ID: <65DBC76E-98F0-4EE9-A08D-D29EF2521477@oracle.com> Is your file system set up for case-sensitive HFS+? We (okay, I) haven't seen this locally -- that's the only difference I can think of. Thanks for reporting it! -- Scott K On Aug 6, 2012, at 12:53 AM, sierkb at gmx.de wrote: > Bug Report (Bug ID: 7189314): > ========== > > > Synopsis: > ------------- > Typo, wrong Symlink path to JavaControlPanel.prefPane on Mac OS X port of JDK7 Update 6 Build 22 From sierkb at gmx.de Tue Aug 7 02:02:33 2012 From: sierkb at gmx.de (sierkb at gmx.de) Date: Tue, 7 Aug 2012 11:02:33 +0200 Subject: Bug: Typo, wrong Symlink path to JavaControlPanel.prefPane on Mac OS X port of JDK7 Update 6 Build 22 In-Reply-To: <65DBC76E-98F0-4EE9-A08D-D29EF2521477@oracle.com> References: <04F3C8CA-F7AE-47DF-BCE3-F0D11C07941C@gmx.de> <65DBC76E-98F0-4EE9-A08D-D29EF2521477@oracle.com> Message-ID: Am 07.08.2012 um 07:36 schrieb Scott Kovatch: > Is your file system set up for case-sensitive HFS+? Yes. -- Sierk B From anthony.petrov at oracle.com Tue Aug 7 03:45:38 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 07 Aug 2012 14:45:38 +0400 Subject: Translucent/Shaped Windows In-Reply-To: <9A354066-3A8B-485C-A6E2-BB3DF2809A2F@blackboard.com> References: <9A354066-3A8B-485C-A6E2-BB3DF2809A2F@blackboard.com> Message-ID: <5020F1D2.1090505@oracle.com> Hi Doug, I'm a bit late on this. I just want to clarify one thing: On 7/17/2012 4:08 AM, Doug Zwick wrote: > 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) This is expected. Please note the difference between: PERPIXEL_TRANSPARENT and PERPIXEL_TRANSLUCENT These two are two different constants. The former covers setShape(), and the later - setBackground()/setWindowOpaque() translucency modes. They are independent. -- best regards, Anthony From alexandr.scherbatiy at oracle.com Tue Aug 7 04:17:40 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 07 Aug 2012 15:17:40 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. Message-ID: <5020F954.4090203@oracle.com> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ This is a regression after the fix 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In the case where a toolbar is created under a mouse and it is dragged over the initial window the mouse enter/exit events should not be generated for the components which are under the toolbar. The current fix is supposed to solve this regression and also to fix generation of mouse enter/exit events for all cases where a mouse is dragged from one window to another or a new window is created under a mouse (like it is implemented for toolbar). Let's see the following cases 1) Mouse is dragged from a window and back to the same window. The Mac OS X system generates a mouse exit event only the first time when a mouse is dragged from a window and does not generate mouse enter/exit events next times during one drag trace. 2) Mouse is dragged from one window to another. The Mac OS X system does not generate mouse enter/exit events for the second window. 3) Mouse is dragged from one window to another and released. In this case the Mac OS X system generates mouse enter event for the second window only after releasing the mouse. 4) Clicking on window creates a new window after that the new window is dragged (toolbar dragging). However the Java system generates mouse enter/exit events each time when a mouse is dragged over any window. To fix this the following methods are introduced: - Get topmost window under mouse - Synthesize mouse enter/exit events for all windows The dispatchMouseEvent method from the LWWindowPeer class is handled previous and next components and is able to generate mouse enter/exit events for them. However the the AWTView native class contains isMouseOver flag which value becomes inconsistent if we do not updated it. Because of this the fix generates the mouse enter/exit window events on the native side. Generating mouse enter/exit events always should be in order where mouse exit events are generated before the mouse enter events. The synthesizeMouseEnteredExitedEventsForAllWindows method tries to generate mouse enter/exit events for all windows during mouse drag or window creation/window bounds changing. However only those windows which isMouseOver flag is differ from the isTopMostWindowUnderMouse state are affected. This method also tries to generate both mouse enter and exit event for the same window but only one of them can be applicable because the isTopMostWindowUnderMouse state is not changed for these calls. So the window enter/exit events now are always generated from the native system and component enter/exit events are generated in the LWWindowPeer class. LWWindowPeer class now uses three links to components: current, last and topmostUnderMouse. All of them are necessary because in case when a mouse is dragged from one window to another the current component receives drag events and last and topmostUnderMouse links handle components mouse exit/enter events on the second window. Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Tue Aug 7 04:33:57 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 07 Aug 2012 15:33:57 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <5020F954.4090203@oracle.com> References: <5020F954.4090203@oracle.com> Message-ID: <5020FD25.7090702@oracle.com> Hi, Alexander. Probably all this stuff can be simplified? Can you try to change TrackingRect to TrackingArea with appropriate flags like NSTrackingEnabledDuringMouseDrag etc. 07.08.2012 15:17, Alexander Scherbatiy wrote: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 > webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ > > This is a regression after the fix 7154048 [macosx] At least drag > twice, the toolbar can be dragged to the left side. > > In the case where a toolbar is created under a mouse and it is dragged > over the initial window the mouse enter/exit events should not be > generated for the components which are under the toolbar. > > The current fix is supposed to solve this regression and also to fix > generation of mouse enter/exit events for all cases where a mouse is > dragged from one window to another or a new window is created under a > mouse (like it is implemented for toolbar). > > Let's see the following cases > 1) Mouse is dragged from a window and back to the same window. > The Mac OS X system generates a mouse exit event only the first time > when a mouse is dragged from a window and does not generate mouse > enter/exit events next times during one drag trace. > > 2) Mouse is dragged from one window to another. > The Mac OS X system does not generate mouse enter/exit events for > the second window. > > 3) Mouse is dragged from one window to another and released. > In this case the Mac OS X system generates mouse enter event for the > second window only after releasing the mouse. > > 4) Clicking on window creates a new window after that the new window > is dragged (toolbar dragging). > > However the Java system generates mouse enter/exit events each time > when a mouse is dragged over any window. > > To fix this the following methods are introduced: > - Get topmost window under mouse > - Synthesize mouse enter/exit events for all windows > > > The dispatchMouseEvent method from the LWWindowPeer class is handled > previous and next components and is able to generate mouse enter/exit > events for them. > However the the AWTView native class contains isMouseOver flag which > value becomes inconsistent if we do not updated it. Because of this > the fix generates the mouse enter/exit window events on the native side. > > Generating mouse enter/exit events always should be in order where > mouse exit events are generated before the mouse enter events. > > The synthesizeMouseEnteredExitedEventsForAllWindows method tries to > generate mouse enter/exit events for all windows during mouse drag or > window creation/window bounds changing. > However only those windows which isMouseOver flag is differ from the > isTopMostWindowUnderMouse state are affected. > This method also tries to generate both mouse enter and exit event for > the same window but only one of them can be applicable because the > isTopMostWindowUnderMouse state is not changed for these calls. > > So the window enter/exit events now are always generated from the > native system and component enter/exit events are generated in the > LWWindowPeer class. > > LWWindowPeer class now uses three links to components: current, last > and topmostUnderMouse. All of them are necessary because in case when > a mouse is dragged from one window to another the current component > receives drag events and last and topmostUnderMouse links handle > components mouse exit/enter events on the second window. > > Thanks, > Alexandr. > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 7 04:39:39 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 07 Aug 2012 15:39:39 +0400 Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) Message-ID: <5020FE7B.6020402@oracle.com> Hi Everyone, Please review the fix. When we translate calls from our swing menu components to awt peer we resets information about shortcut in the setLabel(). This happens because of ScreenMenuItem.setAccelerator() method call peers setLabel(..,..,..) directly and does not initialize ScreenMenuItem.shortcut property. But default implementation of ScreenMenuItem.setLabel() assumes that this field(shortcut) will be initialized. This works on jdk6 because it does not reset shortcut if null or empty shortcut is provided. As a solution we can use peers methods directly in both cases. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 Webrev can be found at: http://cr.openjdk.java.net/~serb/7186371/webrev.00 -- Best regards, Sergey. From pranav.bhat at oracle.com Tue Aug 7 05:39:51 2012 From: pranav.bhat at oracle.com (pranav bhat) Date: Tue, 07 Aug 2012 08:39:51 -0400 Subject: Bug: Typo, wrong Symlink path to JavaControlPanel.prefPane on Mac OS X port of JDK7 Update 6 Build 22 In-Reply-To: <65DBC76E-98F0-4EE9-A08D-D29EF2521477@oracle.com> References: <04F3C8CA-F7AE-47DF-BCE3-F0D11C07941C@gmx.de> <65DBC76E-98F0-4EE9-A08D-D29EF2521477@oracle.com> Message-ID: <50210C97.6090803@oracle.com> Agreed. I think this is HFS+ only issue. I haven't seen it locally either (or haven't been able to reproduce it) Thanks, - Pranav On 8/7/2012 1:36 AM, Scott Kovatch wrote: > Is your file system set up for case-sensitive HFS+? We (okay, I) haven't seen this locally -- that's the only difference I can think of. > > Thanks for reporting it! > > -- Scott K > > On Aug 6, 2012, at 12:53 AM, sierkb at gmx.de wrote: > >> Bug Report (Bug ID: 7189314): >> ========== >> >> >> Synopsis: >> ------------- >> Typo, wrong Symlink path to JavaControlPanel.prefPane on Mac OS X port of JDK7 Update 6 Build 22 From sierkb at gmx.de Tue Aug 7 07:03:28 2012 From: sierkb at gmx.de (sierkb at gmx.de) Date: Tue, 7 Aug 2012 16:03:28 +0200 Subject: Bug: Typo, wrong Symlink path to JavaControlPanel.prefPane on Mac OS X port of JDK7 Update 6 Build 22 In-Reply-To: <50210C97.6090803@oracle.com> References: <04F3C8CA-F7AE-47DF-BCE3-F0D11C07941C@gmx.de> <65DBC76E-98F0-4EE9-A08D-D29EF2521477@oracle.com> <50210C97.6090803@oracle.com> Message-ID: <426A4469-FEDD-46EB-9C70-679D3D20DD70@gmx.de> Hi Pranav! Am 07.08.2012 um 14:39 schrieb pranav bhat: > I think this is HFS+ only issue. I haven't seen it locally either (or haven't been able to reproduce it) The Unix world and Unix filesystem world in general usually is (or is used to be) case sensitive. There are not few users out there, who run their OSX installation as a Unix platform and therefore intentionally run it with HFS+ case sensitive instead of the Unix-untypical case-insensitivity Apple ships per default instead since years (maybe to be forgivingly and grateful to such typos like yours, but on the long run such faults/typos shouldn't be tolerated and forgiven too long). As a very Unix-close company you should be aware of such typos, it should be in your DNA to discover them (or let them discover) early enough through testing (as we can see in this case & very helpful for that: for instance preferring and using a _case sensitive_ HFS+ filesystem in favor to Apple's default case insensitive HFS+). :) Please fix it (soon), and all is well. For your convenience, here are the diffs to fix the relevant issue in the installer scripts (as far as I can discover them from the contents of the package installers): JDK 7 Update 06.pkg (JDK), Java 7 Update 06.pkg (JRE): jdk17006.pkg: ================= $ diff -u preinstall_plugin.script preinstall_plugin.script.new --- preinstall_plugin.script 2012-08-02 04:57:23.000000000 +0200 +++ preinstall_plugin.script.new 2012-08-07 15:14:24.000000000 +0200 @@ -4,7 +4,7 @@ MKDIR=`which mkdir` RM=/bin/rm # Remove the symlink before installation forcing ystem Preferences.app to refresh its cache -PREF_PANE_NAME=JavaControlPanel.prefpane +PREF_PANE_NAME=JavaControlPanel.prefPane PREF_PANE_DEST=/Library/PreferencePanes/ $ diff -u postinstall_plugin.script postinstall_plugin.script.new --- postinstall_plugin.script 2012-08-02 04:57:23.000000000 +0200 +++ postinstall_plugin.script.new 2012-08-07 15:14:10.000000000 +0200 @@ -2,8 +2,8 @@ LN=`which ln` CHOWN=`which chown` PLUGIN_FILEPATH=/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin -PREF_PANE_NAME=JavaControlPanel.prefpane -PREF_PANE_SRC=/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/deploy/JavaControlPanel.prefpane +PREF_PANE_NAME=JavaControlPanel.prefPane +PREF_PANE_SRC=/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/deploy/JavaControlPanel.prefPane PREF_PANE_DEST=/Library/PreferencePanes/ if [ ! -h "${PREF_PANE_DEST}/${PREF_PANE_NAME}" ]; then ${LN} -s "${PREF_PANE_SRC}" "${PREF_PANE_DEST}" javaappletplugin.pkg: ================ $ diff -u preinstall preinstall.new --- preinstall 2012-08-02 04:55:25.000000000 +0200 +++ preinstall.new 2012-08-07 14:58:47.000000000 +0200 @@ -4,7 +4,7 @@ MKDIR=`which mkdir` RM=/bin/rm # Remove the symlink before installation forcing ystem Preferences.app to refresh its cache -PREF_PANE_NAME=JavaControlPanel.prefpane +PREF_PANE_NAME=JavaControlPanel.prefPane PREF_PANE_DEST=/Library/PreferencePanes/ # Actually removes the symlink $ diff -u postinstall postinstall.new --- postinstall 2012-08-02 04:55:25.000000000 +0200 +++ postinstall.new 2012-08-07 14:58:27.000000000 +0200 @@ -2,8 +2,8 @@ LN=`which ln` CHOWN=`which chown` PLUGIN_FILEPATH=/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin -PREF_PANE_NAME=JavaControlPanel.prefpane -PREF_PANE_SRC=/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/deploy/JavaControlPanel.prefpane +PREF_PANE_NAME=JavaControlPanel.prefPane +PREF_PANE_SRC=/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/deploy/JavaControlPanel.prefPane PREF_PANE_DEST=/Library/PreferencePanes/ if [ ! -h "${PREF_PANE_DEST}/${PREF_PANE_NAME}" ]; then ${LN} -s "${PREF_PANE_SRC}" "${PREF_PANE_DEST}" Nevertheless: keep up the good work! Thanks in advance, sorry for the inconvenience & kindly regards, Sierk Bornemann From swingler at apple.com Tue Aug 7 07:47:10 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 07 Aug 2012 07:47:10 -0700 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <5020FD25.7090702@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> Message-ID: I noticed that, NSWindow's windowNumber is NSInteger, which is 32 bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a simple 32 bit int is probably not what you intended to do. Also, have you considered simply calling -[NSWindow setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then removing the calls that flip it on and off in -[AWTView mouseEntered:] and -[AWTView mouseExited"]? This would also require a change in Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), which has a comment that states it only turns on mouse moved events if the window is currently under the mouse. I would think that AppKit should be more than happy to send you mouse-over/enter/exited events as long as you say you want them. Was this approach tried and didn't work for some reason? Regards, Mike Swingler Apple Inc. On Aug 7, 2012, at 4:33 AM, Sergey Bylokhov wrote: > Hi, Alexander. > Probably all this stuff can be simplified? Can you try to change TrackingRect to TrackingArea with appropriate flags like NSTrackingEnabledDuringMouseDrag etc. > > 07.08.2012 15:17, Alexander Scherbatiy wrote: >> >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >> >> This is a regression after the fix 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. >> >> In the case where a toolbar is created under a mouse and it is dragged over the initial window the mouse enter/exit events should not be generated for the components which are under the toolbar. >> >> The current fix is supposed to solve this regression and also to fix generation of mouse enter/exit events for all cases where a mouse is dragged from one window to another or a new window is created under a mouse (like it is implemented for toolbar). >> >> Let's see the following cases >> 1) Mouse is dragged from a window and back to the same window. >> The Mac OS X system generates a mouse exit event only the first time when a mouse is dragged from a window and does not generate mouse enter/exit events next times during one drag trace. >> >> 2) Mouse is dragged from one window to another. >> The Mac OS X system does not generate mouse enter/exit events for the second window. >> >> 3) Mouse is dragged from one window to another and released. >> In this case the Mac OS X system generates mouse enter event for the second window only after releasing the mouse. >> >> 4) Clicking on window creates a new window after that the new window is dragged (toolbar dragging). >> >> However the Java system generates mouse enter/exit events each time when a mouse is dragged over any window. >> >> To fix this the following methods are introduced: >> - Get topmost window under mouse >> - Synthesize mouse enter/exit events for all windows >> >> >> The dispatchMouseEvent method from the LWWindowPeer class is handled previous and next components and is able to generate mouse enter/exit events for them. >> However the the AWTView native class contains isMouseOver flag which value becomes inconsistent if we do not updated it. Because of this the fix generates the mouse enter/exit window events on the native side. >> >> Generating mouse enter/exit events always should be in order where mouse exit events are generated before the mouse enter events. >> >> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to generate mouse enter/exit events for all windows during mouse drag or window creation/window bounds changing. >> However only those windows which isMouseOver flag is differ from the isTopMostWindowUnderMouse state are affected. >> This method also tries to generate both mouse enter and exit event for the same window but only one of them can be applicable because the isTopMostWindowUnderMouse state is not changed for these calls. >> >> So the window enter/exit events now are always generated from the native system and component enter/exit events are generated in the LWWindowPeer class. >> >> LWWindowPeer class now uses three links to components: current, last and topmostUnderMouse. All of them are necessary because in case when a mouse is dragged from one window to another the current component receives drag events and last and topmostUnderMouse links handle components mouse exit/enter events on the second window. >> >> Thanks, >> Alexandr. >> >> > > > -- > Best regards, Sergey. > From Abhinay.Reddyreddy at mathworks.com Tue Aug 7 08:16:12 2012 From: Abhinay.Reddyreddy at mathworks.com (Abhinay Reddyreddy) Date: Tue, 7 Aug 2012 15:16:12 +0000 Subject: [macosx] Scale value in Page Setup dialog. Message-ID: <353D880645CCDC429732D7A445F7F5BFE6A5B3@exmb-00-ah.ad.mathworks.com> Hi, I am using the following code to show a page setup dialog on mac os x. PrinterJob job = PrinterJob.getPrinterJob(); PageFormat pf = job.pageDialog(job.defaultPage()); The page setup dialog comes up with page orientation, paper size and "Scale %" options. I could not find any API to retrieve the scale value entered by the user. Could anyone let me know if there is an existing API to access the scale value. If there is none, Is there a way to remove or disable the scale option in this dialog. Should I report this as a bug ?? Thanks, Abhinay. From Doug.Zwick at blackboard.com Tue Aug 7 08:50:24 2012 From: Doug.Zwick at blackboard.com (Doug Zwick) Date: Tue, 7 Aug 2012 11:50:24 -0400 Subject: Translucent/Shaped Windows In-Reply-To: References: Message-ID: <685D6B74-7BC7-4465-A004-FAAC0F06CE5D@blackboard.com> Anthony Petrov wrote: > I'm a bit late on this. I just want to clarify one thing: > > On 7/17/2012 4:08 AM, Doug Zwick wrote: >> 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) > > This is expected. Please note the difference between: > > PERPIXEL_TRANSPARENT > and > PERPIXEL_TRANSLUCENT > > These two are two different constants. The former covers setShape(), and > the later - setBackground()/setWindowOpaque() translucency modes. They > are independent. Can you provide any guidance on whether Java 7 for OS X will support Window.setShape, or continue to use the alpha-based mechanism from Java 6? 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 anthony.petrov at oracle.com Tue Aug 7 08:57:59 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 07 Aug 2012 19:57:59 +0400 Subject: Translucent/Shaped Windows In-Reply-To: <685D6B74-7BC7-4465-A004-FAAC0F06CE5D@blackboard.com> References: <685D6B74-7BC7-4465-A004-FAAC0F06CE5D@blackboard.com> Message-ID: <50213B07.5040704@oracle.com> On 8/7/2012 7:50 PM, Doug Zwick wrote: > Anthony Petrov wrote: > >> I'm a bit late on this. I just want to clarify one thing: >> >> On 7/17/2012 4:08 AM, Doug Zwick wrote: >>> 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) >> This is expected. Please note the difference between: >> >> PERPIXEL_TRANSPARENT >> and >> PERPIXEL_TRANSLUCENT >> >> These two are two different constants. The former covers setShape(), and >> the later - setBackground()/setWindowOpaque() translucency modes. They >> are independent. > > Can you provide any guidance on whether Java 7 for OS X will support Window.setShape, or continue to use the alpha-based mechanism from Java 6? Sure. CR 7124244 covers support for setShape() on Mac OS, and AFAIK the fix has already been pushed to jdk7-dev repository, and is going to be integrated to 7u8. You may want to try early access builds of 7u8 when they are available to test it out. -- best regards, Anthony From harshman+javadev at gmail.com Tue Aug 7 22:30:04 2012 From: harshman+javadev at gmail.com (Chris Harshman) Date: Tue, 7 Aug 2012 22:30:04 -0700 Subject: [macosx] Scale value in Page Setup dialog. In-Reply-To: References: <353D880645CCDC429732D7A445F7F5BFE6A5B3@exmb-00-ah.ad.mathworks.com> Message-ID: On Tue, Aug 7, 2012 at 10:09 AM, Abhinay Reddyreddy < Abhinay.Reddyreddy at mathworks.com> wrote: > The problem is I am trying to use this page setup dialog in an > application. Since the scale value is pretty much "unaccessible", my > proposal is being rejected on the grounds that "we would be *advertising* functionality, > and customers will surely complain that the functionality does not work". > It would have been nice if there was a way to remove/disable that field > from the dialog. > > Do you think I should log this as a bug or a feature request ?? > Yes. :) It's a bug (IMHO) that the OS X interface element presented to the user has control (the 'scale' input text field) whose value is not passed back to the corresponding Java object. On the other hand, the PageFormat object doesn't *have* a 'scale' attribute (that I can see) to represent the value of that field, so I guess that would be a feature (and on operating systems that don't present a 'scale' control in the corresponding dialog, would presumably always return 100.0?). From paul_t100 at fastmail.fm Wed Aug 8 02:15:16 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 08 Aug 2012 10:15:16 +0100 Subject: How do I use Apple Extensions with Java 7 Message-ID: <50222E24.3060001@fastmail.fm> Apparently the apple extensions for java provided by Apple in Java 6 such as com.apple.eawt are available for Java 7 but where ? Have they been renamed, or do they exist with the same name but bundled with Java 7, or do we use with Java 6 ectera. Paul From leonid.romanov at oracle.com Tue Aug 7 23:20:28 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 8 Aug 2012 10:20:28 +0400 Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: <5020FE7B.6020402@oracle.com> References: <5020FE7B.6020402@oracle.com> Message-ID: <001201cd752d$e9476200$bbd62600$@oracle.com> Looks reasonable. -----Original Message----- From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] Sent: Tuesday, August 07, 2012 3:40 PM To: Leonid Romanov; Mike Swingler; awt-dev at openjdk.java.net; macosx-port-dev at openjdk.java.net Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) Hi Everyone, Please review the fix. When we translate calls from our swing menu components to awt peer we resets information about shortcut in the setLabel(). This happens because of ScreenMenuItem.setAccelerator() method call peers setLabel(..,..,..) directly and does not initialize ScreenMenuItem.shortcut property. But default implementation of ScreenMenuItem.setLabel() assumes that this field(shortcut) will be initialized. This works on jdk6 because it does not reset shortcut if null or empty shortcut is provided. As a solution we can use peers methods directly in both cases. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 Webrev can be found at: http://cr.openjdk.java.net/~serb/7186371/webrev.00 -- Best regards, Sergey. From mik3hall at gmail.com Wed Aug 8 03:33:51 2012 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 8 Aug 2012 05:33:51 -0500 Subject: How do I use Apple Extensions with Java 7 In-Reply-To: <50222E24.3060001@fastmail.fm> References: <50222E24.3060001@fastmail.fm> Message-ID: <130EC9B3-6260-4EFA-9F91-61F29439B7E9@gmail.com> On Aug 8, 2012, at 4:15 AM, Paul Taylor wrote: > Apparently the apple extensions for java provided by Apple in Java 6 such as com.apple.eawt are available for Java 7 but where ? > > Have they been renamed, or do they exist with the same name but bundled with Java 7, or do we use with Java 6 ectera. > > Paul > I think this was answered before. Available (currently same names) including source if you download the project. Maybe not Oracle documented? From paul_t100 at fastmail.fm Wed Aug 8 03:39:51 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 08 Aug 2012 11:39:51 +0100 Subject: How do I use Apple Extensions with Java 7 In-Reply-To: <130EC9B3-6260-4EFA-9F91-61F29439B7E9@gmail.com> References: <50222E24.3060001@fastmail.fm> <130EC9B3-6260-4EFA-9F91-61F29439B7E9@gmail.com> Message-ID: <502241F7.8060409@fastmail.fm> On 08/08/2012 11:33, Michael Hall wrote: > On Aug 8, 2012, at 4:15 AM, Paul Taylor wrote: > >> Apparently the apple extensions for java provided by Apple in Java 6 such as com.apple.eawt are available for Java 7 but where ? >> >> Have they been renamed, or do they exist with the same name but bundled with Java 7, or do we use with Java 6 ectera. >> >> Paul >> > I think this was answered before. Available (currently same names) including source if you download the project. > Maybe not Oracle documented? Thanks but I dont want the source code, or to build from source I want to know if I have the official oracle jdk1.7 preview installed (currently 1.7.0_06") do I need to install any other jars or is it included in the jdk1.7 , and why isn't it documented in the Java 1.7 javadocs ? Paul From mik3hall at gmail.com Wed Aug 8 03:41:17 2012 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 8 Aug 2012 05:41:17 -0500 Subject: How do I use Apple Extensions with Java 7 In-Reply-To: <502241F7.8060409@fastmail.fm> References: <50222E24.3060001@fastmail.fm> <130EC9B3-6260-4EFA-9F91-61F29439B7E9@gmail.com> <502241F7.8060409@fastmail.fm> Message-ID: <2C480597-79F4-4915-A47C-30F821A29DBE@gmail.com> On Aug 8, 2012, at 5:39 AM, Paul Taylor wrote: > On 08/08/2012 11:33, Michael Hall wrote: >> On Aug 8, 2012, at 4:15 AM, Paul Taylor wrote: >> >>> Apparently the apple extensions for java provided by Apple in Java 6 such as com.apple.eawt are available for Java 7 but where ? >>> >>> Have they been renamed, or do they exist with the same name but bundled with Java 7, or do we use with Java 6 ectera. >>> >>> Paul >>> >> I think this was answered before. Available (currently same names) including source if you download the project. >> Maybe not Oracle documented? > Thanks but I dont want the source code, or to build from source I want to know if I have the official oracle jdk1.7 preview installed (currently 1.7.0_06") do I need to install any other jars or is it included in the jdk1.7 , and why isn't it documented in the Java 1.7 javadocs ? > > Paul Paul, It's there runtime which is about all I can answer. Just works, same as always. From paul_t100 at fastmail.fm Wed Aug 8 09:16:12 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 08 Aug 2012 17:16:12 +0100 Subject: Apple Extensions are not documented in Java 7 API Docs Message-ID: <502290CC.4020200@fastmail.fm> Apple extensions (com.apple.eawt) are still supported in Java 7, but unless you are used to using in Java 6 with Apples JRE you wouldn't be aware they existed, can the javadocs be made available as part of the main javadocs please, even if you have to create an OSX version of the Javadocs. From Sergey.Bylokhov at oracle.com Wed Aug 8 09:32:12 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 08 Aug 2012 20:32:12 +0400 Subject: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders Message-ID: <5022948C.9090104@oracle.com> Hi Everyone, Please review the fix. We should support "apple.awt.fileDialogForDirectories" Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 Webrev can be found at: http://cr.openjdk.java.net/~serb/7161437/webrev.00/ Fix was contributed-by: Marco Dinacci Discussion here: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004295.html -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Aug 8 12:11:04 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 08 Aug 2012 23:11:04 +0400 Subject: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders In-Reply-To: <5022948C.9090104@oracle.com> References: <5022948C.9090104@oracle.com> Message-ID: <5022B9C8.8080501@oracle.com> The fix looks fine to me. Thanks Marco! -- best regards, Anthony On 8/8/2012 8:32 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > We should support "apple.awt.fileDialogForDirectories" > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7161437/webrev.00/ > > Fix was contributed-by: Marco Dinacci > Discussion here: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004295.html > > -- > Best regards, Sergey. > From niagarasoft20-macosxportdev at yahoo.com Wed Aug 8 17:41:24 2012 From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com) Date: Wed, 8 Aug 2012 17:41:24 -0700 (PDT) Subject: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders References: <5022948C.9090104@oracle.com> Message-ID: <1344472884.55337.YahooMailNeo@web126004.mail.ne1.yahoo.com> I was the one who filed this bug, and think it is fine.... Just so that you know, the behavior of this dialog is different than the default OS X directory chooser behavior in that directory choosers to not allow users to also select files. Also the default select button should read [Choose] and not [Open]. So in the CFileDialog.m file the private method : - (void)safeSaveOrLoad method should have ... [openPanel setCanChooseFiles:NO]; [openPanel setAllowsMultipleSelection:NO]; //CAN BE YES ALSO [openPanel setPrompt:@"Choose"]; //'Choose' should point to a localized string resource. This then I believe would follow the OS X HIG behavior .? If the user needs to choose files they can do it with a regular native awt.FileDialog with the diretories flag unset. Thanks again Marco! Regards, Mike >________________________________ > From: Sergey Bylokhov >To: "macosx-port-dev at openjdk.java.net" ; "awt-dev at openjdk.java.net" ; Anthony Petrov >Sent: Wednesday, August 8, 2012 12:32 PM >Subject: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders > >Hi Everyone, >Please review the fix. >We should support "apple.awt.fileDialogForDirectories" > >Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 >Webrev can be found at: http://cr.openjdk.java.net/~serb/7161437/webrev.00/ > >Fix was contributed-by: Marco Dinacci >Discussion here: >http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004295.html > >-- Best regards, Sergey. > > > > From weijun.wang at oracle.com Wed Aug 8 19:33:34 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 09 Aug 2012 10:33:34 +0800 Subject: Code review request: 7184815 (was Re: OpenJDK krb5 ignore /etc/krb5.conf?) In-Reply-To: <50231C1F.9060104@oracle.com> References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> <500602A2.9070803@oracle.com> <500657BF.3020107@oracle.com> <501A838D.40107@oracle.com> <50231C1F.9060104@oracle.com> Message-ID: <5023217E.5000308@oracle.com> On 08/09/2012 10:10 AM, Valerie (Yu-Ching) Peng wrote: > Max, > > The new ordering for reading the config files sounds reasonable. > However, I have questions on scenarios where the various config files > don't exist and the corresponding handling. > The new impl of getJavaFileName()/getNativeFileName() return file names > even when the file doesn't exist. > This will lead to an IOException when loadConfigFile(String) is called. > Is this intended? Yes. But this IOException will be ignored at the end of the private constructor. This is the also the old behavior. The main purpose is that even there is no (any kind of) krb5.conf there is still a chance to read config from DNS etc. > > Also, the toStringIndented(...) method removed several calls which > append the 'prefix' and made various adjustments. > Do you have sample output using the new impl? Reading through the code, > some don't look quite right. There are 2 major changes: 1. A string value does not starts from a newline 2. Vectors are inside square brackets. For example, for a very typical krb5.conf [libdefaults] default_realm = R [realms] R = { kdc = k1 kdc = k2 } the old toString is libdefaults = { default_realm = { R } } realms = { R = { kdc = { k1 k2 } } } and the new output is { libdefaults = { default_realm = R } realms = { R = { kdc = [k1,k2,] } } } Thanks Max > Thanks, > Valerie > > On 08/02/12 06:41, Weijun Wang wrote: >> Ping again. >> >> On 07/18/2012 02:29 PM, Weijun Wang wrote: >>> 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 Sergey.Bylokhov at oracle.com Thu Aug 9 00:46:11 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 09 Aug 2012 11:46:11 +0400 Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: References: <5020FE7B.6020402@oracle.com> Message-ID: <50236AC3.4090601@oracle.com> 09.08.2012 06:09, J.S. Ferguson wrote: > Seems to fix the menu visual problem, but now actions are firing twice when the accelerator is used as described in bug 7160951. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160951 Yes this bug on our radar. > > On Aug 7, 2012, at 4:39 AM, Sergey Bylokhov wrote: > >> Hi Everyone, >> Please review the fix. >> When we translate calls from our swing menu components to awt peer we resets information about shortcut in the setLabel(). >> This happens because of ScreenMenuItem.setAccelerator() method call peers setLabel(..,..,..) directly and does not initialize ScreenMenuItem.shortcut property. >> But default implementation of ScreenMenuItem.setLabel() assumes that this field(shortcut) will be initialized. >> >> This works on jdk6 because it does not reset shortcut if null or empty shortcut is provided. >> As a solution we can use peers methods directly in both cases. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 >> Webrev can be found at: http://cr.openjdk.java.net/~serb/7186371/webrev.00 >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From marco.dinacci at gmail.com Thu Aug 9 01:54:21 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Thu, 9 Aug 2012 09:54:21 +0100 Subject: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders In-Reply-To: <1344472884.55337.YahooMailNeo@web126004.mail.ne1.yahoo.com> References: <5022948C.9090104@oracle.com> <1344472884.55337.YahooMailNeo@web126004.mail.ne1.yahoo.com> Message-ID: Hi, > Just so that you know, the behavior of this dialog is different than the default OS X directory chooser behavior in that directory choosers to not allow users to also select files. True but unfortunately if you allow only for directory selection (by passing NO to setCanChooseFiles: when fCanChooseDirectories is YES) then there's no way to allow for both file and directory selection. The best would be to have control over both setCanChooseFiles and setCanChooseDirectories from Java but I guess that's part of the RFE. >Also the default select button should read [Choose] and not [Open]. So in the CFileDialog.m file the private method : The CFileDialog doesn't explicitly set the prompt string so I guess the behaviour depends on the OS version or on the localization. Setting it explicitly would override the default string and potentially confuse users. This test program on OSX Lion always displays "Open" no matter which combination of YES an NO I pass to setCanChooseFiles and setCanChooseDirectories. On which OS version do you see "Choose" ? #import "AppDelegate.h" @implementation AppDelegate @synthesize window = _window; - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { NSButton *button = [[[NSButton alloc] initWithFrame: NSMakeRect(10,10,120,40)] autorelease]; [[_window contentView] addSubview: button]; [button setTitle: @"Button"]; [button setTarget:self]; [button setAction:@selector(openDialog)]; } - (void)openDialog { NSOpenPanel* openDlg = [NSOpenPanel openPanel]; [openDlg setCanChooseFiles:YES]; [openDlg setCanChooseDirectories:YES]; [openDlg runModalForDirectory:nil file:nil]; } @end Best, Marco From Sergey.Bylokhov at oracle.com Thu Aug 9 02:26:09 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 09 Aug 2012 13:26:09 +0400 Subject: JMenuItem keyboard accelerator not showing when using the useScreenMenuBar property In-Reply-To: References: <722D0EED-4620-4CFB-B9C1-9E2250AAD1B6@oracle.com> Message-ID: <50238231.3000206@oracle.com> Hi Leonid, Marco. Please file the CR next time, when you realise that this is unknown bug(especially if this is regression). So such issues can be tracked and not missed. Thanks. 19.06.2012 18:40, Leonid Romanov wrote: > Yep, thanks! The thing is, this code hasn't changed since 7u4, so I need to find out why it works in 7u4. > > On 18.06.2012, at 19:54, Marco Dinacci wrote: > >> Hi Leonid, >> >> I think I've found the issue. In ScreenMenuItem.addNotify there's the >> following code: >> >> setAccelerator(fMenuItem.getAccelerator()); >> >> final String label = fMenuItem.getText(); >> if (label != null) { >> setLabel(label); >> } >> >> setLabel(label) in CMenuItem calls: >> >> setLabel(label, (char)0, KeyEvent.VK_UNDEFINED, 0); >> >> which resets any accelerator previously set with setAccelerator. >> >> If the call to setAccelerator(fMenuItem.getAccelerator()) is placed >> after setLabel(label) than the accelerator is set again and the >> shortcut is visible. I don't know if it's the best way to reset the >> accelerator in setLabel and then setting it back again but at least it >> works. >> >> Here's the test file I used: >> >> import java.awt.*; >> import java.awt.event.*; >> import javax.swing.*; >> >> public class MenuBug { >> >> public JMenuBar createMenuBar(final JFrame frame) { >> JMenuBar menuBar; >> JMenu menu, submenu; >> JMenuItem menuItem; >> >> menuBar = new JMenuBar(); >> >> menu = new JMenu("A Menu"); >> menu.setMnemonic(KeyEvent.VK_A); >> menuBar.add(menu); >> >> menuItem = new JMenuItem("menu item"); >> KeyStroke s = KeyStroke.getKeyStroke( >> KeyEvent.VK_T, ActionEvent.META_MASK); >> menuItem.setAccelerator(s); >> menu.add(menuItem); >> >> return menuBar; >> } >> >> private static void createAndShowGUI() { >> JFrame frame = new JFrame("MenuBug"); >> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> >> MenuBug demo = new MenuBug(); >> frame.setJMenuBar(demo.createMenuBar(frame)); >> >> frame.setVisible(true); >> } >> >> public static void main(String[] args) { >> javax.swing.SwingUtilities.invokeLater(new Runnable() { >> public void run() { >> createAndShowGUI(); >> } >> }); >> } >> } >> >> Best, >> Marco -- Best regards, Sergey. From artem.ananiev at oracle.com Thu Aug 9 03:59:52 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 09 Aug 2012 14:59:52 +0400 Subject: Apple Extensions are not documented in Java 7 API Docs In-Reply-To: <502290CC.4020200@fastmail.fm> References: <502290CC.4020200@fastmail.fm> Message-ID: <50239828.7090803@oracle.com> On 8/8/2012 8:16 PM, Paul Taylor wrote: > Apple extensions (com.apple.eawt) are still supported in Java 7, but > unless you are used to using in Java 6 with Apples JRE you wouldn't be > aware they existed, can the javadocs be made available as part of the > main javadocs please, even if you have to create an OSX version of the > Javadocs. Apple extensions are not a part of JDK specification, and I really doubt they will ever be. Applications should be ready to work without them at all. Thanks, Artem From mik3hall at gmail.com Thu Aug 9 04:04:36 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 9 Aug 2012 06:04:36 -0500 Subject: Apple Extensions are not documented in Java 7 API Docs In-Reply-To: <50239828.7090803@oracle.com> References: <502290CC.4020200@fastmail.fm> <50239828.7090803@oracle.com> Message-ID: <71CE9B6F-0CC5-42AE-9394-57871CBF3391@gmail.com> On Aug 9, 2012, at 5:59 AM, Artem Ananiev wrote: > > On 8/8/2012 8:16 PM, Paul Taylor wrote: >> Apple extensions (com.apple.eawt) are still supported in Java 7, but >> unless you are used to using in Java 6 with Apples JRE you wouldn't be >> aware they existed, can the javadocs be made available as part of the >> main javadocs please, even if you have to create an OSX version of the >> Javadocs. > > Apple extensions are not a part of JDK specification, and I really doubt they will ever be. Applications should be ready to work without them at all. > > Thanks, > > Artem Wouldn't there be some way to associate this package with the project in a contributed section or something? It was an original Apple contribution wasn't it? These classes sort of enable a java application to be a normally functioning Mac application, handle associated files, print events, etc. with much more goodness. Saying none of this this is supported seems a little worrying and a serious disadvantage to java applications. From hs at tagtraum.com Thu Aug 9 04:09:39 2012 From: hs at tagtraum.com (Hendrik Schreiber) Date: Thu, 9 Aug 2012 13:09:39 +0200 Subject: Apple Extensions are not documented in Java 7 API Docs In-Reply-To: <50239828.7090803@oracle.com> References: <502290CC.4020200@fastmail.fm> <50239828.7090803@oracle.com> Message-ID: <962523C1-9E60-4B83-B1D7-EF409FB50D36@tagtraum.com> On Aug 9, 2012, at 12:59 PM, Artem Ananiev wrote: > > Apple extensions are not a part of JDK specification, and I really doubt they will ever be. Applications should be ready to work without them at all. Yes, they are not part of the specs. But: It would be a huge mistake to remove them as they effectively allow developers to write halfway decent desktop apps. Making them unavailable would cripple the platform unecessarily. Thanks, -hendrik From artem.ananiev at oracle.com Thu Aug 9 06:23:25 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 09 Aug 2012 17:23:25 +0400 Subject: Apple Extensions are not documented in Java 7 API Docs In-Reply-To: <962523C1-9E60-4B83-B1D7-EF409FB50D36@tagtraum.com> References: <502290CC.4020200@fastmail.fm> <50239828.7090803@oracle.com> <962523C1-9E60-4B83-B1D7-EF409FB50D36@tagtraum.com> Message-ID: <5023B9CD.9020104@oracle.com> On 8/9/2012 3:09 PM, Hendrik Schreiber wrote: > On Aug 9, 2012, at 12:59 PM, Artem Ananiev wrote: >> >> Apple extensions are not a part of JDK specification, and I really doubt they will ever be. Applications should be ready to work without them at all. > > Yes, they are not part of the specs. > > But: It would be a huge mistake to remove them as they effectively allow developers to write halfway decent desktop apps. > Making them unavailable would cripple the platform unecessarily. I didn't say anything about confirmed plans to remove or keep them in JDK. I completely agree these classes allow Java applications behave and look more native. My statement was to make sure everybody understands official status of any piece of code that is not public API. Thanks, Artem > Thanks, > > -hendrik From niagarasoft20-macosxportdev at yahoo.com Thu Aug 9 06:29:21 2012 From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com) Date: Thu, 9 Aug 2012 06:29:21 -0700 (PDT) Subject: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders In-Reply-To: References: <5022948C.9090104@oracle.com> <1344472884.55337.YahooMailNeo@web126004.mail.ne1.yahoo.com> Message-ID: <1344518961.45115.YahooMailNeo@web126006.mail.ne1.yahoo.com> Marco, I don't know, but I'm just describing the same behaviors that was in the previous Apple Java implementations (i.e. choosing directories only + using [Choose] ) when setting the apple.awt.fileDialogForDirectoriessystem property flag. I should know because, about 2 years ago, I filed the same bug for Apple Java to be consistent with it's previous versions. It looks like they just hard coded the [Choose] button text because when I run it with different locales set, it always says [Choose]. Thanks again for all your hard work! Mike >________________________________ > From: Marco Dinacci >To: "niagarasoft20-macosxportdev at yahoo.com" >Cc: Sergey Bylokhov ; "macosx-port-dev at openjdk.java.net" ; "awt-dev at openjdk.java.net" ; Anthony Petrov >Sent: Thursday, August 9, 2012 4:54 AM >Subject: Re: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders > >Hi, > >> Just so that you know, the behavior of this dialog is different than the default OS X directory chooser behavior in that directory choosers to not allow users to also select files. > >True but unfortunately if you allow only for directory selection (by >passing NO to setCanChooseFiles: when fCanChooseDirectories is YES) >then there's no way to allow for both file and directory selection. >The best would be to have control over both setCanChooseFiles and >setCanChooseDirectories from Java but I guess that's part of the RFE. > >>Also the default select button should read [Choose] and not [Open]. So in the CFileDialog.m file the private method : > >The CFileDialog doesn't explicitly set the prompt string so I guess >the behaviour depends on the OS version or on the localization. >Setting it explicitly would override the default string and >potentially confuse users. This test program on OSX Lion always >displays "Open" no matter which combination of YES an NO I pass to >setCanChooseFiles and setCanChooseDirectories. On which OS version do >you see "Choose" ? > >#import "AppDelegate.h" > >@implementation AppDelegate > >@synthesize window = _window; > >- (void)applicationDidFinishLaunching:(NSNotification *)aNotification >{ >??? NSButton *button = [[[NSButton alloc] initWithFrame: >??? ??? ??? ??? ??? NSMakeRect(10,10,120,40)] autorelease]; >??? [[_window contentView] addSubview: button]; >??? [button setTitle: @"Button"]; >??? [button setTarget:self]; >??? [button setAction:@selector(openDialog)]; >} > >- (void)openDialog >{ >??? NSOpenPanel* openDlg = [NSOpenPanel openPanel]; >??? [openDlg setCanChooseFiles:YES]; >??? [openDlg setCanChooseDirectories:YES]; >??? [openDlg runModalForDirectory:nil file:nil]; >} > >@end > >Best, >Marco > > > From ahughes at redhat.com Thu Aug 9 09:13:53 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 9 Aug 2012 12:13:53 -0400 (EDT) Subject: Apple Extensions are not documented in Java 7 API Docs In-Reply-To: <5023B9CD.9020104@oracle.com> Message-ID: <106306194.2688599.1344528833135.JavaMail.root@redhat.com> ----- Original Message ----- > > On 8/9/2012 3:09 PM, Hendrik Schreiber wrote: > > On Aug 9, 2012, at 12:59 PM, Artem Ananiev wrote: > >> > >> Apple extensions are not a part of JDK specification, and I really > >> doubt they will ever be. Applications should be ready to work > >> without them at all. > > > > Yes, they are not part of the specs. > > > > But: It would be a huge mistake to remove them as they effectively > > allow developers to write halfway decent desktop apps. > > Making them unavailable would cripple the platform unecessarily. > > I didn't say anything about confirmed plans to remove or keep them in > JDK. I completely agree these classes allow Java applications behave > and > look more native. > > My statement was to make sure everybody understands official status > of > any piece of code that is not public API. > I don't see any reason these APIs couldn't be documented under "Non-core APIs" along with the others: http://www.oracle.com/technetwork/java/javase/documentation/api-jsp-136079.html Is this a case of the OpenJDK build not being patched to build these docs? Or are they just not on the Oracle website? > Thanks, > > Artem > > > Thanks, > > > > -hendrik > -- 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 weijun.wang at oracle.com Thu Aug 9 19:50:44 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 10 Aug 2012 10:50:44 +0800 Subject: Code review request: 7142426: [macosx] cannot build if the not-yet-build jdk is in PATH Message-ID: <50247704.8040308@oracle.com> The rungen script has not forced the use of java in $JAVA_HOME. Since I always put the to-be-built java at the top of $PATH, the script fails because that java exists but its runtime is still not fully built. Please take a look at my fix http://cr.openjdk.java.net/~weijun/7142426/webrev.00/ Also, I'm not sure where runjava is used. If it's really useless, we can remove the file, as well as the reference in jdk/make/java/jobjc/Makefile. The bug was closed by RE but I'll re-open it if you believe this is a real bug. Thanks Max From weijun.wang at oracle.com Thu Aug 9 20:51:13 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 10 Aug 2012 11:51:13 +0800 Subject: Code review request: 7184815 (was Re: OpenJDK krb5 ignore /etc/krb5.conf?) In-Reply-To: <5024453C.7050308@oracle.com> References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> <500602A2.9070803@oracle.com> <500657BF.3020107@oracle.com> <501A838D.40107@oracle.com> <50231C1F.9060104@oracle.com> <5023217E.5000308@oracle.com> <5024453C.7050308@oracle.com> Message-ID: <50248531.6080403@oracle.com> Webrev updated at http://cr.openjdk.java.net/~weijun/7184815/webrev.01/ Add comments before toString and inside toStringIndented. > With the new impl, the responsibility for doing indention when > printing out the String 'obj' is the caller's responsibility. Well, not really. The indentation is removed in the new impl because there is no more indentation now, i.e. the String is printed *inline*. Compare the old output: key = { value } to new output key = value The old impl looks like everything is a collection. In the new impl, String, Vector and Hashtable have completely different format and are easily distinguishable. Thanks Max On 08/10/2012 07:18 AM, Valerie (Yu-Ching) Peng wrote: > Max, > > Please find my comments in line. > > On 08/08/12 19:33, Weijun Wang wrote: >> >> On 08/09/2012 10:10 AM, Valerie (Yu-Ching) Peng wrote: >>> Max, >>> >>> The new ordering for reading the config files sounds reasonable. >>> However, I have questions on scenarios where the various config files >>> don't exist and the corresponding handling. >>> The new impl of getJavaFileName()/getNativeFileName() return file names >>> even when the file doesn't exist. >>> This will lead to an IOException when loadConfigFile(String) is called. >>> Is this intended? >> >> Yes. But this IOException will be ignored at the end of the private >> constructor. This is the also the old behavior. The main purpose is >> that even there is no (any kind of) krb5.conf there is still a chance >> to read config from DNS etc. > > Ok, after re-read the old impl, I agree that the current behavior seems > to match the old one. > >>> >>> Also, the toStringIndented(...) method removed several calls which >>> append the 'prefix' and made various adjustments. >>> Do you have sample output using the new impl? Reading through the code, >>> some don't look quite right. >> >> There are 2 major changes: >> >> 1. A string value does not starts from a newline >> 2. Vectors are inside square brackets. > > Hmm, now I see what your new code is doing. However, it's a bit obscure > and hard to understand as far as I am concerned. > With the new impl, the responsibility for doing indention when printing > out the String 'obj' is the caller's responsibility. > When given a String 'obj', the toStringIndented(...) ignores the given > prefix value, and only append the String 'obj' followed by a '\n'. Same > goes for the Vector 'obj', the prefix is not used at all. > Can you add additional comments to make this clear? I think it'd be good > to include the syntax of your new output, so it's clear that why prefix > is only used for Hashtable 'obj'. > > Thanks, > Valerie > >> >> For example, for a very typical krb5.conf >> >> [libdefaults] >> default_realm = R >> [realms] >> R = { >> kdc = k1 >> kdc = k2 >> } >> >> the old toString is >> >> libdefaults = { >> default_realm = { >> R >> } >> } >> realms = { >> R = { >> kdc = { >> k1 >> k2 >> } >> } >> } >> >> and the new output is >> >> { >> libdefaults = { >> default_realm = R >> } >> realms = { >> R = { >> kdc = [k1,k2,] >> } >> } >> } >> >> Thanks >> Max >> >> >>> Thanks, >>> Valerie >>> >>> On 08/02/12 06:41, Weijun Wang wrote: >>>> Ping again. >>>> >>>> On 07/18/2012 02:29 PM, Weijun Wang wrote: >>>>> 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 artem.ananiev at oracle.com Fri Aug 10 02:30:29 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 10 Aug 2012 13:30:29 +0400 Subject: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders In-Reply-To: <5022948C.9090104@oracle.com> References: <5022948C.9090104@oracle.com> Message-ID: <5024D4B5.2060000@oracle.com> Hi, Sergey, Marco, the fix looks fine. Thanks, Artem On 8/8/2012 8:32 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > We should support "apple.awt.fileDialogForDirectories" > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7161437/webrev.00/ > > Fix was contributed-by: Marco Dinacci > Discussion here: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004295.html > > -- > Best regards, Sergey. > From alexandr.scherbatiy at oracle.com Fri Aug 10 07:00:38 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 10 Aug 2012 18:00:38 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> Message-ID: <50251406.6060708@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ The comments are below: On 8/7/2012 6:47 PM, Mike Swingler wrote: > I noticed that, NSWindow's windowNumber is NSInteger, which is 32 bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a simple 32 bit int is probably not what you intended to do. fixed. > Also, have you considered simply calling -[NSWindow setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then removing the calls that flip it on and off in -[AWTView mouseEntered:] and -[AWTView mouseExited"]? This would also require a change in Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), which has a comment that states it only turns on mouse moved events if the window is currently under the mouse. I tried it. The result that I got is that a dragging mouse from one window to another does not generate mouse enter/exit events on the second window in case when tracking rect is used and the acceptsMouseMovedEvents flag is always set to YES. > I would think that AppKit should be more than happy to send you mouse-over/enter/exited events as long as you say you want them. Was this approach tried and didn't work for some reason? >> Hi, Alexander. >> Probably all this stuff can be simplified? Can you try to change TrackingRect to TrackingArea with appropriate flags like NSTrackingEnabledDuringMouseDrag etc. I changed the TrackingRect to TrackingArea in the updated fix. It now generates the mouse enter/exit events on the second window during drag. So it is not necessary to generates such events from our side. The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit events for component in case when a mouse is dragged from one window to another. Where the second window contains it's own components and the only way to know about tracking over them are drag events which receives the first window. I think that the LWWindowPeer class code can be simplified if we assume that window mouse enter/exit events are always come to the current window. So the component mouse enter/exit events can be tracked only in the current or topmost window. For this case I separated the global lastCommonMouseEventPeer which is necessary for the cursor manager and the local lastMouseEventPeer. According to the specification: The proper order of mouse-entered and mouse-exited events received by tracking-area objects in an application cannot be guaranteed. https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html So it seems it is not possible to have one lastMouseEventPeer instead of two: lastCommonMouseEventPeer and lastMouseEventPeer. And there are possible situations that we can receive mouse drag event between enter and exit. To handle this the isMouseOver flag is added to the LWWindowPeer class. So the component mouse enter/exit events are not generated if the window mouse exited event is received and window mouse entered is not. There is the test: test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java It shows that even using the TrackingArea some mouse enter/exit events are not generateed in the following cases: - window is created under the mouse - window changes it's bounds so it becomes under the mouse For this cases it still necessary to generate mouse enter/exit events from our side. I just moved the related code to one method synthesizeMouseEnteredExitedEventsForAllWindows. Thanks, Alexandr. >> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>> >>> This is a regression after the fix 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. >>> >>> In the case where a toolbar is created under a mouse and it is dragged over the initial window the mouse enter/exit events should not be generated for the components which are under the toolbar. >>> >>> The current fix is supposed to solve this regression and also to fix generation of mouse enter/exit events for all cases where a mouse is dragged from one window to another or a new window is created under a mouse (like it is implemented for toolbar). >>> >>> Let's see the following cases >>> 1) Mouse is dragged from a window and back to the same window. >>> The Mac OS X system generates a mouse exit event only the first time when a mouse is dragged from a window and does not generate mouse enter/exit events next times during one drag trace. >>> >>> 2) Mouse is dragged from one window to another. >>> The Mac OS X system does not generate mouse enter/exit events for the second window. >>> >>> 3) Mouse is dragged from one window to another and released. >>> In this case the Mac OS X system generates mouse enter event for the second window only after releasing the mouse. >>> >>> 4) Clicking on window creates a new window after that the new window is dragged (toolbar dragging). >>> >>> However the Java system generates mouse enter/exit events each time when a mouse is dragged over any window. >>> >>> To fix this the following methods are introduced: >>> - Get topmost window under mouse >>> - Synthesize mouse enter/exit events for all windows >>> >>> >>> The dispatchMouseEvent method from the LWWindowPeer class is handled previous and next components and is able to generate mouse enter/exit events for them. >>> However the the AWTView native class contains isMouseOver flag which value becomes inconsistent if we do not updated it. Because of this the fix generates the mouse enter/exit window events on the native side. >>> >>> Generating mouse enter/exit events always should be in order where mouse exit events are generated before the mouse enter events. >>> >>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to generate mouse enter/exit events for all windows during mouse drag or window creation/window bounds changing. >>> However only those windows which isMouseOver flag is differ from the isTopMostWindowUnderMouse state are affected. >>> This method also tries to generate both mouse enter and exit event for the same window but only one of them can be applicable because the isTopMostWindowUnderMouse state is not changed for these calls. >>> >>> So the window enter/exit events now are always generated from the native system and component enter/exit events are generated in the LWWindowPeer class. >>> >>> LWWindowPeer class now uses three links to components: current, last and topmostUnderMouse. All of them are necessary because in case when a mouse is dragged from one window to another the current component receives drag events and last and topmostUnderMouse links handle components mouse exit/enter events on the second window. >>> >>> Thanks, >>> Alexandr. >>> >>> >> >> -- >> Best regards, Sergey. >> From steve at weblite.ca Fri Aug 10 17:01:17 2012 From: steve at weblite.ca (Steve Hannah) Date: Fri, 10 Aug 2012 17:01:17 -0700 Subject: Strategies for debugging Sandbox Violations in Java Message-ID: Hello all, I'm in the process of sandbox-ifying a mac app with a bundled JRE. I'm currently trying to weed out all of the sandbox violations and I'm having some difficulty. I see the sandbox violations in console and I can see the kernel backtrace, but I'm having trouble walking this back to the parts of my Java application that are triggering this code. What strategies do you guys use for debugging sandbox violations in Java. Is it possible to get the Java stack trace for where a violation occurs? Thanks in advance for any tips. Steve From marco.dinacci at gmail.com Sat Aug 11 00:30:31 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Sat, 11 Aug 2012 08:30:31 +0100 Subject: Strategies for debugging Sandbox Violations in Java In-Reply-To: References: Message-ID: Hi, > I'm in the process of sandbox-ifying a mac app with a bundled JRE. I'm > currently trying to weed out all of the sandbox violations and I'm having > some difficulty. I see the sandbox violations in console and I can see the > kernel backtrace, but I'm having trouble walking this back to the parts of > my Java application that are triggering this code. most sandbox violations are triggered by attempts to read/write to the filesystem without user intervention (eg. without using an open/save dialog) and/or from places outside the container (eg. ~/Library/Containers/yourapp/...). A violation is also triggered by trying to execute an external process from Java (ex. using Runtime.exec()). If you look at the list of entitlements your application can have on the Apple site(*) you can think whether your application is performing an operation that would require enabling a specific entitlement, like connecting to a network, printing, interacting with a usb or bluetooth device, etc.. > What strategies do you > guys use for debugging sandbox violations in Java. Is it possible to get > the Java stack trace for where a violation occurs? The Kernighan strategy, careful thinking and judicious print statements :) I think about where my application is in possible violation and I add log statements which are redirected to a file in the application container directory. When this is not enough (ex. the problem may be in the jvm), or I want to see the values received by the native code, just gdb. I'd be also interested to hear other people's techniques. Best, Marco * http://developer.apple.com/library/mac/#documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/uid/TP40011195-CH4-SW1 From dkocher at sudo.ch Sun Aug 12 10:55:03 2012 From: dkocher at sudo.ch (David Kocher) Date: Sun, 12 Aug 2012 19:55:03 +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: Ping. 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 Alan.Bateman at oracle.com Sun Aug 12 12:24:31 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 12 Aug 2012 20:24:31 +0100 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: <502802EF.1070908@oracle.com> On 12/08/2012 18:55, David Kocher wrote: > Ping. > > 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 >> Have you done any testing with the latest jdk8 build to verify that it addresses the problem that you are seeing? -Alan. From artem.ananiev at oracle.com Mon Aug 13 06:26:23 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 13 Aug 2012 17:26:23 +0400 Subject: Apple Extensions are not documented in Java 7 API Docs In-Reply-To: <106306194.2688599.1344528833135.JavaMail.root@redhat.com> References: <106306194.2688599.1344528833135.JavaMail.root@redhat.com> Message-ID: <5029007F.9070705@oracle.com> On 8/9/2012 8:13 PM, Andrew Hughes wrote: > > > ----- Original Message ----- >> >> On 8/9/2012 3:09 PM, Hendrik Schreiber wrote: >>> On Aug 9, 2012, at 12:59 PM, Artem Ananiev wrote: >>>> >>>> Apple extensions are not a part of JDK specification, and I really >>>> doubt they will ever be. Applications should be ready to work >>>> without them at all. >>> >>> Yes, they are not part of the specs. >>> >>> But: It would be a huge mistake to remove them as they effectively >>> allow developers to write halfway decent desktop apps. >>> Making them unavailable would cripple the platform unecessarily. >> >> I didn't say anything about confirmed plans to remove or keep them in >> JDK. I completely agree these classes allow Java applications behave >> and >> look more native. >> >> My statement was to make sure everybody understands official status >> of >> any piece of code that is not public API. >> > > I don't see any reason these APIs couldn't be documented under "Non-core APIs" > along with the others: http://www.oracle.com/technetwork/java/javase/documentation/api-jsp-136079.html The reason is that it's not API, i.e. something we (AWT team) commit to support in the future. To commit, we should at least make sure API can be implemented in JDK7, which is very different from Apple's JDK6, where they could potentially use private Mac OS X functions. Thanks, Artem > Is this a case of the OpenJDK build not being patched to build these docs? > Or are they just not on the Oracle website? > >> Thanks, >> >> Artem >> >>> Thanks, >>> >>> -hendrik >> > From paul_t100 at fastmail.fm Mon Aug 13 06:31:45 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Mon, 13 Aug 2012 14:31:45 +0100 Subject: Apple Extensions are not documented in Java 7 API Docs In-Reply-To: <5029007F.9070705@oracle.com> References: <106306194.2688599.1344528833135.JavaMail.root@redhat.com> <5029007F.9070705@oracle.com> Message-ID: <502901C1.3020208@fastmail.fm> On 13/08/2012 14:26, Artem Ananiev wrote: > > On 8/9/2012 8:13 PM, Andrew Hughes wrote: >> >> >> ----- Original Message ----- >>> >>> On 8/9/2012 3:09 PM, Hendrik Schreiber wrote: >>>> On Aug 9, 2012, at 12:59 PM, Artem Ananiev wrote: >>>>> >>>>> Apple extensions are not a part of JDK specification, and I really >>>>> doubt they will ever be. Applications should be ready to work >>>>> without them at all. >>>> >>>> Yes, they are not part of the specs. >>>> >>>> But: It would be a huge mistake to remove them as they effectively >>>> allow developers to write halfway decent desktop apps. >>>> Making them unavailable would cripple the platform unecessarily. >>> >>> I didn't say anything about confirmed plans to remove or keep them in >>> JDK. I completely agree these classes allow Java applications behave >>> and >>> look more native. >>> >>> My statement was to make sure everybody understands official status >>> of >>> any piece of code that is not public API. >>> >> >> I don't see any reason these APIs couldn't be documented under >> "Non-core APIs" >> along with the others: >> http://www.oracle.com/technetwork/java/javase/documentation/api-jsp-136079.html > > The reason is that it's not API, i.e. something we (AWT team) commit > to support in the future. To commit, we should at least make sure API > can be implemented in JDK7, which is very different from Apple's JDK6, > where they could potentially use private Mac OS X functions. > > Thanks, > > Artem You really should aim to incorporate support for these features (however it is done) because Apple is only addressing shortfalls in Java Swing because of its Windows centric approach. Seeing that Apple have made these extensions available to the Oracle 7 build they must been keen for you to a good job. It cannot be right to not document these features because they are deprecated features that shouldnt be used in new projects, they are the only way to create quality Apple applications at the moment. Paul From swingler at apple.com Mon Aug 13 07:23:28 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 13 Aug 2012 07:23:28 -0700 Subject: Apple Extensions are not documented in Java 7 API Docs In-Reply-To: <5029007F.9070705@oracle.com> References: <106306194.2688599.1344528833135.JavaMail.root@redhat.com> <5029007F.9070705@oracle.com> Message-ID: <83F4ACBD-6C13-47D9-B299-E2EFAAA7068C@apple.com> On Aug 13, 2012, at 6:26 AM, Artem Ananiev wrote: > On 8/9/2012 8:13 PM, Andrew Hughes wrote: >> >> ----- Original Message ----- >>> >>> On 8/9/2012 3:09 PM, Hendrik Schreiber wrote: >>>> On Aug 9, 2012, at 12:59 PM, Artem Ananiev wrote: >>>>> >>>>> Apple extensions are not a part of JDK specification, and I really >>>>> doubt they will ever be. Applications should be ready to work >>>>> without them at all. >>>> >>>> Yes, they are not part of the specs. >>>> >>>> But: It would be a huge mistake to remove them as they effectively >>>> allow developers to write halfway decent desktop apps. >>>> Making them unavailable would cripple the platform unecessarily. >>> >>> I didn't say anything about confirmed plans to remove or keep them in >>> JDK. I completely agree these classes allow Java applications behave >>> and >>> look more native. >>> >>> My statement was to make sure everybody understands official status >>> of >>> any piece of code that is not public API. >>> >> >> I don't see any reason these APIs couldn't be documented under "Non-core APIs" >> along with the others: http://www.oracle.com/technetwork/java/javase/documentation/api-jsp-136079.html > > The reason is that it's not API, i.e. something we (AWT team) commit to support in the future. To commit, we should at least make sure API can be implemented in JDK7, which is very different from Apple's JDK6, where they could potentially use private Mac OS X functions. These can be perfectly well supported and documented as non-core API, as Andrew suggests. OpenJDK 7 currently has the all the sources to the complete eAWT, and they are implemented in terms of public Apple framework API. I think the best course of action is for the eAWT to be clearly documented, with pieces of it being marked as deprecated as there are replacements available in actual core APIs. Regards, Mike Swingler Apple Inc. From Sergey.Bylokhov at oracle.com Mon Aug 13 07:40:03 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 13 Aug 2012 18:40:03 +0400 Subject: [7u8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders Message-ID: <502911C3.6030805@oracle.com> Hi Everyone, Please review the fix. This is a direct back port from jdk 8 to jdk 7u8. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 Webrev can be found at: http://cr.openjdk.java.net/~serb/7161437/webrev.00/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b41845694f39 Fix was contributed-by: Marco Dinacci Discussion here: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004295.html -- Best regards, Sergey. From neugens.limasoftware at gmail.com Mon Aug 13 07:40:33 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 13 Aug 2012 16:40:33 +0200 Subject: Apple Extensions are not documented in Java 7 API Docs In-Reply-To: <502901C1.3020208@fastmail.fm> References: <106306194.2688599.1344528833135.JavaMail.root@redhat.com> <5029007F.9070705@oracle.com> <502901C1.3020208@fastmail.fm> Message-ID: 2012/8/13 Paul Taylor : > You really should aim to incorporate support for these features (however it > is done) because Apple is only addressing shortfalls in Java Swing because > of its Windows centric approach. Seeing that Apple have made these > extensions available to the Oracle 7 build they must been keen for you to a > good job. It cannot be right to not document these features because they > are deprecated features that shouldnt be used in new projects, they are the > only way to create quality Apple applications at the moment. > > Paul Artem already provided you with a rationale why this is not going to be supported, which is particularly valid since the mac port project is part of the official OpenJDK repository. Note that the fact that is not an official library, doesn't mean it's not there. You can surely find a way to keep using those extensions, the Mac guys can even help you with that, but the standard word of warning that if you use this extensions your programs may break any time is to be expected. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From anthony.petrov at oracle.com Mon Aug 13 08:15:01 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 13 Aug 2012 19:15:01 +0400 Subject: [7u8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders In-Reply-To: <502911C3.6030805@oracle.com> References: <502911C3.6030805@oracle.com> Message-ID: <502919F5.2070508@oracle.com> Looks fine. -- best regards, Anthony On 08/13/12 18:40, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > This is a direct back port from jdk 8 to jdk 7u8. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7161437/webrev.00/ > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b41845694f39 > > Fix was contributed-by: Marco Dinacci > Discussion here: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004295.html > From Sergey.Bylokhov at oracle.com Mon Aug 13 08:26:59 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 13 Aug 2012 19:26:59 +0400 Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: <001201cd752d$e9476200$bbd62600$@oracle.com> References: <5020FE7B.6020402@oracle.com> <001201cd752d$e9476200$bbd62600$@oracle.com> Message-ID: <50291CC3.8010002@oracle.com> Thanks Leonid. Does anybody has a chance to review it? 08.08.2012 10:20, Leonid Romanov wrote: > Looks reasonable. > > -----Original Message----- > From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] > Sent: Tuesday, August 07, 2012 3:40 PM > To: Leonid Romanov; Mike Swingler; awt-dev at openjdk.java.net; macosx-port-dev at openjdk.java.net > Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) > > Hi Everyone, > Please review the fix. > When we translate calls from our swing menu components to awt peer we > resets information about shortcut in the setLabel(). > This happens because of ScreenMenuItem.setAccelerator() method call > peers setLabel(..,..,..) directly and does not initialize > ScreenMenuItem.shortcut property. > But default implementation of ScreenMenuItem.setLabel() assumes that > this field(shortcut) will be initialized. > > This works on jdk6 because it does not reset shortcut if null or empty > shortcut is provided. > As a solution we can use peers methods directly in both cases. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7186371/webrev.00 > -- Best regards, Sergey. From paul_t100 at fastmail.fm Mon Aug 13 09:02:03 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Mon, 13 Aug 2012 17:02:03 +0100 Subject: Apple Extensions are not documented in Java 7 API Docs In-Reply-To: References: <106306194.2688599.1344528833135.JavaMail.root@redhat.com> <5029007F.9070705@oracle.com> <502901C1.3020208@fastmail.fm> Message-ID: <502924FB.7080103@fastmail.fm> On 13/08/2012 15:40, Mario Torre wrote: > 2012/8/13 Paul Taylor : > >> You really should aim to incorporate support for these features (however it >> is done) because Apple is only addressing shortfalls in Java Swing because >> of its Windows centric approach. Seeing that Apple have made these >> extensions available to the Oracle 7 build they must been keen for you to a >> good job. It cannot be right to not document these features because they >> are deprecated features that shouldnt be used in new projects, they are the >> only way to create quality Apple applications at the moment. >> >> Paul > Artem already provided you with a rationale why this is not going > to be supported, which is particularly valid since the mac port project > is part of the official OpenJDK repository. > > Note that the fact that is not an official library, doesn't mean it's > not there. You can surely find a way to keep using those extensions, > the Mac guys can even help you with that, but the standard word of > warning that if you use this extensions your programs may break any > time is to be expected. > > Cheers, > Mario You seem to be missing the point bigtime here. Its not an official library, but it is shipped as part of the jdk, Im not downloading it from a 3rd party. So as it is being delivered why is it not documented ? Going forward surely it is a good thing for Java to be able to support the desktop on different oses as good as possible, why would you want to break this, do you develop OSX desktop applications yourself Paul From ekrichardson at gmail.com Mon Aug 13 10:32:40 2012 From: ekrichardson at gmail.com (Eric Richardson) Date: Mon, 13 Aug 2012 10:32:40 -0700 Subject: Apple Extensions are not documented in Java 7 API Docs In-Reply-To: <502924FB.7080103@fastmail.fm> References: <106306194.2688599.1344528833135.JavaMail.root@redhat.com> <5029007F.9070705@oracle.com> <502901C1.3020208@fastmail.fm> <502924FB.7080103@fastmail.fm> Message-ID: This may be totally off base but is there any reason *not* to change the OpenJDK build to include some javadoc generation for this additional API? On Mon, Aug 13, 2012 at 9:02 AM, Paul Taylor wrote: > On 13/08/2012 15:40, Mario Torre wrote: >> >> 2012/8/13 Paul Taylor : >> >>> You really should aim to incorporate support for these features (however >>> it >>> is done) because Apple is only addressing shortfalls in Java Swing >>> because >>> of its Windows centric approach. Seeing that Apple have made these >>> extensions available to the Oracle 7 build they must been keen for you to >>> a >>> good job. It cannot be right to not document these features because they >>> are deprecated features that shouldnt be used in new projects, they are >>> the >>> only way to create quality Apple applications at the moment. >>> >>> Paul >> >> Artem already provided you with a rationale why this is not going >> to be supported, which is particularly valid since the mac port project >> is part of the official OpenJDK repository. >> >> Note that the fact that is not an official library, doesn't mean it's >> not there. You can surely find a way to keep using those extensions, >> the Mac guys can even help you with that, but the standard word of >> warning that if you use this extensions your programs may break any >> time is to be expected. >> >> Cheers, >> Mario > > You seem to be missing the point bigtime here. > > Its not an official library, but it is shipped as part of the jdk, Im not > downloading it from a 3rd party. So as it is being delivered why is it not > documented ? > > Going forward surely it is a good thing for Java to be able to support the > desktop on different oses as good as possible, why would you want to break > this, do you develop OSX desktop applications yourself > > Paul From leonid.romanov at oracle.com Tue Aug 14 07:12:01 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 14 Aug 2012 18:12:01 +0400 Subject: [8] Review request for 2226249: [macosx] Java processes on Mac should not use default Apple icon Message-ID: <83532F56-ED5B-49D9-ACBD-D1900A8591CD@oracle.com> Hi, This is a forward port of the fix that went into 7u6. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2226249 Webrev: http://cr.openjdk.java.net/~leonidr/2226249/webrev.00/ Thanks, Leonid. From anthony.petrov at oracle.com Tue Aug 14 07:26:45 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 14 Aug 2012 18:26:45 +0400 Subject: [8] Review request for 2226249: [macosx] Java processes on Mac should not use default Apple icon In-Reply-To: <83532F56-ED5B-49D9-ACBD-D1900A8591CD@oracle.com> References: <83532F56-ED5B-49D9-ACBD-D1900A8591CD@oracle.com> Message-ID: <502A6025.8060708@oracle.com> Hi Leonid, I do understand that the OS will install an icon from the bundle automatically if it is present, however, the following piece of code still looks strange since the bundleIcon is never used: > 268 NSString* bundleIcon = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleIconFile"]; > 269 if (bundleIcon == nil) { > 270 NSData* iconData; > 271 iconData = [[NSData alloc] initWithBytesNoCopy: sAWTIconData length: sizeof(sAWTIconData) freeWhenDone: NO]; > 272 iconImage = [[NSImage alloc] initWithData: iconData]; > 273 [iconData release]; > 274 } How about adding a short comment stating why it is unused in this code block? Otherwise the fix looks fine. -- best regards, Anthony On 8/14/2012 6:12 PM, Leonid Romanov wrote: > Hi, > This is a forward port of the fix that went into 7u6. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2226249 > Webrev: http://cr.openjdk.java.net/~leonidr/2226249/webrev.00/ > > Thanks, > Leonid. > > From Sergey.Bylokhov at oracle.com Tue Aug 14 07:30:07 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 14 Aug 2012 18:30:07 +0400 Subject: [8] Review request for 7172187 [macosx] JAWT native CALayer not positioned over Canvas Message-ID: <502A60EF.1060307@oracle.com> Hi Everyone, Please review the fix. Description of main changes: CPlatformComponent.java: -Unused peer and target references were removed. -Wrong return value for nativeSetBounds() was changed from long to void. AWTSurfaceLayers.m: -layer.bounds was replaced by layer.frame, because layer.bounds doesn't honour x and y position of the layer. -Wrong position inversion was removed. Also related fields were marked as volatile, if they were used in the different threads + javadoc cleanup. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172187 Webrev can be found at: http://cr.openjdk.java.net/~serb/7172187/webrev.00 -- Best regards, Sergey. From artem.ananiev at oracle.com Tue Aug 14 07:39:11 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 14 Aug 2012 18:39:11 +0400 Subject: [8] Review request for 7172187 [macosx] JAWT native CALayer not positioned over Canvas In-Reply-To: <502A60EF.1060307@oracle.com> References: <502A60EF.1060307@oracle.com> Message-ID: <502A630F.3020306@oracle.com> Looks fine. Thanks, Artem On 8/14/2012 6:30 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > Description of main changes: > > CPlatformComponent.java: > -Unused peer and target references were removed. > -Wrong return value for nativeSetBounds() was changed from long to > void. > AWTSurfaceLayers.m: > -layer.bounds was replaced by layer.frame, because layer.bounds > doesn't honour x and y position of the layer. > -Wrong position inversion was removed. > Also related fields were marked as volatile, if they were used in the > different threads + javadoc cleanup. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172187 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7172187/webrev.00 > > -- > Best regards, Sergey. > From anthony.petrov at oracle.com Tue Aug 14 07:40:47 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 14 Aug 2012 18:40:47 +0400 Subject: [8] Review request for 7172187 [macosx] JAWT native CALayer not positioned over Canvas In-Reply-To: <502A630F.3020306@oracle.com> References: <502A60EF.1060307@oracle.com> <502A630F.3020306@oracle.com> Message-ID: <502A636F.7040500@oracle.com> +1. -- best regards, Anthony On 8/14/2012 6:39 PM, Artem Ananiev wrote: > > Looks fine. > > Thanks, > > Artem > > On 8/14/2012 6:30 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> Please review the fix. >> Description of main changes: >> >> CPlatformComponent.java: >> -Unused peer and target references were removed. >> -Wrong return value for nativeSetBounds() was changed from long to >> void. >> AWTSurfaceLayers.m: >> -layer.bounds was replaced by layer.frame, because layer.bounds >> doesn't honour x and y position of the layer. >> -Wrong position inversion was removed. >> Also related fields were marked as volatile, if they were used in the >> different threads + javadoc cleanup. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172187 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7172187/webrev.00 >> >> -- >> Best regards, Sergey. >> From ahughes at redhat.com Tue Aug 14 16:49:50 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 14 Aug 2012 19:49:50 -0400 (EDT) Subject: Apple Extensions are not documented in Java 7 API Docs In-Reply-To: Message-ID: <837865950.4958934.1344988190323.JavaMail.root@redhat.com> ----- Original Message ----- > This may be totally off base but is there any reason *not* to change > the OpenJDK build to include some javadoc generation for this > additional API? > I did a bit of digging... :-D It already lists the packages in make/docs/NON_CORE_PKGS.gmk: ifeq ($(PLATFORM), macosx) APPLE_EXT_PKGS = com.apple.concurrent \ com.apple.eawt \ com.apple.eawt.event \ com.apple.eio endif but there is no rule in make/docs/Makefile to build them, nor is src/macosx/classes listed in ALL_SOURCE_DIRS. Something like the following: diff --git a/make/docs/Makefile b/make/docs/Makefile --- a/make/docs/Makefile +++ b/make/docs/Makefile @@ -86,6 +86,7 @@ $(GENSRCDIR) \ $(SHARE_SRC)/../solaris/classes \ $(SHARE_SRC)/../windows/classes \ + $(SHARE_SRC)/../macosx/classes \ $(SHARE_SRC)/doc/stub # List of directories that actually exist @@ -1098,6 +1099,56 @@ ############################################################# # +# appleextdocs +# + +ALL_OTHER_TARGETS += appleextdocs + +APPLE_EXT_DOCDIR := $(JRE_API_DOCSDIR)/apple +APPLE_EXT2COREAPI := ../../../$(JDKJRE2COREAPI) +APPLE_EXT_DOCTITLE := Apple Ext API +APPLE_EXT_WINDOWTITLE := Apple Ext API +APPLE_EXT_HEADER := Apple Ext API +APPLE_EXT_BOTTOM := $(call CommonBottom,$(APPLE_EXT_FIRST_COPYRIGHT_YEAR)) +# APPLE_EXT_PKGS is located in NON_CORE_PKGS.gmk + +APPLE_EXT_INDEX_HTML = $(APPLE_EXT_DOCDIR)/index.html +APPLE_EXT_OPTIONS_FILE = $(DOCSTMPDIR)/appleext.options +APPLE_EXT_PACKAGES_FILE = $(DOCSTMPDIR)/appleext.packages + +appleextdocs: $(APPLE_EXT_INDEX_HTML) + +# Set relative location to core api document root +$(APPLE_EXT_INDEX_HTML): GET2DOCSDIR=$(APPLE_EXT2COREAPI)/.. + +# Run javadoc if the index file is out of date or missing +$(APPLE_EXT_INDEX_HTML): $(APPLE_EXT_OPTIONS_FILE) $(APPLE_EXT_PACKAGES_FILE) + $(prep-javadoc) + $(call JavadocSummary,$(APPLE_EXT_OPTIONS_FILE),$(APPLE_EXT_PACKAGES_FILE)) + $(JAVADOC_CMD) $(JAVADOC_VM_MEMORY_FLAGS) -d $(@D) \ + @$(APPLE_EXT_OPTIONS_FILE) @$(APPLE_EXT_PACKAGES_FILE) + +# Create file with javadoc options in it +$(APPLE_EXT_OPTIONS_FILE): + $(prep-target) + @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ + $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ + $(call OptionPair,-encoding,ascii) ; \ + $(call OptionOnly,-nodeprecatedlist) ; \ + $(call OptionPair,-doctitle,$(APPLE_EXT_DOCTITLE)) ; \ + $(call OptionPair,-windowtitle,$(APPLE_EXT_WINDOWTITLE) $(DRAFT_WINTITLE));\ + $(call OptionPair,-header,$(APPLE_EXT_HEADER)$(DRAFT_HEADER)) ; \ + $(call OptionPair,-bottom,$(APPLE_EXT_BOTTOM)$(DRAFT_BOTTOM)) ; \ + $(call OptionTrip,-linkoffline,$(APPLE_EXT2COREAPI),$(COREAPI_DOCSDIR)/); \ + ) >> $@ + +# Create a file with the package names in it +$(APPLE_EXT_PACKAGES_FILE): $(DIRECTORY_CACHE) $(call PackageDependencies,$(APPLE_EXT_PKGS)) + $(prep-target) + $(call PackageFilter,$(APPLE_EXT_PKGS)) + +############################################################# +# allows the documentation to be built (rule just copied from the one above and the names altered). With the above patch, and a few additional modifications to build and find the MacOSX classes on GNU/Linux, I was able to build the documentation for those classes. Beware; javadoc prints out quite a few warnings! > On Mon, Aug 13, 2012 at 9:02 AM, Paul Taylor > wrote: > > On 13/08/2012 15:40, Mario Torre wrote: > >> > >> 2012/8/13 Paul Taylor : > >> > >>> You really should aim to incorporate support for these features > >>> (however > >>> it > >>> is done) because Apple is only addressing shortfalls in Java > >>> Swing > >>> because > >>> of its Windows centric approach. Seeing that Apple have made > >>> these > >>> extensions available to the Oracle 7 build they must been keen > >>> for you to > >>> a > >>> good job. It cannot be right to not document these features > >>> because they > >>> are deprecated features that shouldnt be used in new projects, > >>> they are > >>> the > >>> only way to create quality Apple applications at the moment. > >>> > >>> Paul > >> > >> Artem already provided you with a rationale why this is not going > >> to be supported, which is particularly valid since the mac port > >> project > >> is part of the official OpenJDK repository. > >> > >> Note that the fact that is not an official library, doesn't mean > >> it's > >> not there. You can surely find a way to keep using those > >> extensions, > >> the Mac guys can even help you with that, but the standard word of > >> warning that if you use this extensions your programs may break > >> any > >> time is to be expected. > >> > >> Cheers, > >> Mario > > > > You seem to be missing the point bigtime here. > > > > Its not an official library, but it is shipped as part of the jdk, > > Im not > > downloading it from a 3rd party. So as it is being delivered why is > > it not > > documented ? > > > > Going forward surely it is a good thing for Java to be able to > > support the > > desktop on different oses as good as possible, why would you want > > to break > > this, do you develop OSX desktop applications yourself > > > > Paul > -- 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 paul_t100 at fastmail.fm Thu Aug 16 01:40:13 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 16 Aug 2012 09:40:13 +0100 Subject: JFileChooser not seeing network mounted files on 1.7.0_06 on Mac Message-ID: <502CB1ED.9070507@fastmail.fm> Using build 1.7.0_06-b22 my JFileChooser doesn't seem able to find my NAS, although mounted and shown under Shared in my Finder Is this is a known issue or am I doing something dumb Paul From anthony.petrov at oracle.com Thu Aug 16 05:43:51 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 16 Aug 2012 16:43:51 +0400 Subject: JFileChooser not seeing network mounted files on 1.7.0_06 on Mac In-Reply-To: <502CB1ED.9070507@fastmail.fm> References: <502CB1ED.9070507@fastmail.fm> Message-ID: <502CEB07.40708@oracle.com> I don't recall such an issue. BTW, is the NAS accessible via java.io.File API? In any case, please file a bug report at http://bugs.sun.com/ -- best regards, Anthony On 08/16/12 12:40, Paul Taylor wrote: > Using build 1.7.0_06-b22 my JFileChooser doesn't seem able to find my > NAS, although mounted and shown under Shared in my Finder > > Is this is a known issue or am I doing something dumb > > Paul From leonid.romanov at oracle.com Fri Aug 17 10:59:38 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 17 Aug 2012 21:59:38 +0400 Subject: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components Message-ID: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> Hi, Please review a fix for CR 7124375: [macosx] Focus isn't transfered as expected between components. The main issue addressed by this fix is that information about current focused window and focus owner isn't shared among LWKeyboardFocusManagerPeer instances. Also, while the current KeyboardFocusManager code makes it look like each KeyboardFocusManager instance needs its own peer instance, the reality is different because both WKeyboardFocusManagerPeer and XKeyboardManagerPeer doesn't have non static fields. In other words, all the WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. Therefore, there is no need in in multiple peer instances, one singleton peer shared among all the KeyboardFocusManager instances is enough. This fix addresses that issue as well by explicitly turning KeyboardManagerPeer implementations into singletons for the sake of cleaner code. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.00/ Thanks, Leonid. From mik3hall at gmail.com Sat Aug 18 05:45:55 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 18 Aug 2012 07:45:55 -0500 Subject: AppConverter Message-ID: <078492EC-20B8-4E9A-ADB5-C3D6E4B623C3@gmail.com> Description: Drag you Apple java applications to the AppConverter application and it will generate the appbundler [1] build.xml file and create the openjdk application. This should handle most if not all of the necessary work to convert an Apple Java application to an openjdk one. If your application is complicated some manual changes may be required after creating the openjdk one. If you let me know about any of those I can determine if they can be handled more automatically as well. [1] http://java.net/projects/appbundler/ Mentioned this on the app bundler list I suppose I should indicate it elsewhere as well. Also note I have made my signature a little more ornate indicating some of what else I've been up to with Java 7 on OS X. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From mik3hall at gmail.com Sat Aug 18 05:59:43 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 18 Aug 2012 07:59:43 -0500 Subject: AppConverter In-Reply-To: <078492EC-20B8-4E9A-ADB5-C3D6E4B623C3@gmail.com> References: <078492EC-20B8-4E9A-ADB5-C3D6E4B623C3@gmail.com> Message-ID: On Aug 18, 2012, at 7:45 AM, Michael Hall wrote: > Description: Drag you Apple java applications to the AppConverter application and it will generate the appbundler [1] build.xml file and create the openjdk application. The page URL for AppConverter is included in the new shameless plug signature but I suppose a direct download link for AppConverter would be good if you might be interested in just a quick look at the thing itself. http://www195.pair.com/mik3hall/AppConverter.dmg Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter On Aug 18, 2012, at 7:45 AM, Michael Hall wrote: > Description: Drag you Apple java applications to the AppConverter application and it will generate the appbundler [1] build.xml file and create the openjdk application. > > This should handle most if not all of the necessary work to convert an Apple Java application to an openjdk one. If your application is complicated some manual changes may be required after creating the openjdk one. If you let me know about any of those I can determine if they can be handled more automatically as well. > > [1] http://java.net/projects/appbundler/ > > Mentioned this on the app bundler list I suppose I should indicate it elsewhere as well. Also note I have made my signature a little more ornate indicating some of what else I've been up to with Java 7 on OS X. > > Michael Hall > > trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz > > HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe > > AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter > > > > From swpalmer at gmail.com Sun Aug 19 13:26:48 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 19 Aug 2012 16:26:48 -0400 Subject: JVM Crash with 7u6 b24 Message-ID: <82AA6451-C3ED-446A-9E6A-0EEC8FA7CAC4@gmail.com> Just had a hard crash clicking in the project list in NetBeans. I'm running 7u6 (release) on Mountain Lion. Does anyone on this list want a copy of the crash report? It's hard to classify the bug for the Oracle bug database - I've submitted a bug, but I don't know how to reproduce it. Scott P. From alexander.zuev at oracle.com Sun Aug 19 14:52:36 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 20 Aug 2012 01:52:36 +0400 Subject: JVM Crash with 7u6 b24 In-Reply-To: <82AA6451-C3ED-446A-9E6A-0EEC8FA7CAC4@gmail.com> References: <82AA6451-C3ED-446A-9E6A-0EEC8FA7CAC4@gmail.com> Message-ID: <1A5810E6-71E7-48CB-ABB4-484126EA3170@oracle.com> Scott, Could you please send me the crash log plus some basic details on how exactly you got that crash, like NetBeans version, was this happened once or it is a repeatable failure in some circumstances. I will appreciate any info that could help me pinpoint the crash reason. With best regards, Alexander Zuev 20.08.2012, ? 0:26, Scott Palmer ???????(?): > Just had a hard crash clicking in the project list in NetBeans. I'm running 7u6 (release) on Mountain Lion. > Does anyone on this list want a copy of the crash report? It's hard to classify the bug for the Oracle bug database - I've submitted a bug, but I don't know how to reproduce it. > > Scott P. > From henri.gomez at gmail.com Mon Aug 20 00:23:03 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 20 Aug 2012 09:23:03 +0200 Subject: JRE/JDK for OSX and Java Preferences Message-ID: Hi to all, When I do a diff between JDK and JRE, I see CommandLine is not set in JVMCapabilities : @@ -9,7 +9,7 @@ CFBundleGetInfoString OpenJDK (1.7.0) CFBundleIdentifier - net.java.openjdk.jre + net.java.openjdk.jdk CFBundleInfoDictionaryVersion 7.0 CFBundleName @@ -24,6 +24,10 @@ 1.7.0-b24-20120813 JavaVM + JVMCapabilities + + CommandLine + JVMMinimumFrameworkVersion 13.2.9 JVMMinimumSystemVersion Questions : - Is it why Apple Java Preferences didn't show JRE in list of available Java env ? - Any reasons why CommandLine Capability is not set for JRE since JRE works perfectly from Command Line ? Cheers From Sergey.Bylokhov at oracle.com Mon Aug 20 02:55:34 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 20 Aug 2012 13:55:34 +0400 Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: <50291CC3.8010002@oracle.com> References: <5020FE7B.6020402@oracle.com> <001201cd752d$e9476200$bbd62600$@oracle.com> <50291CC3.8010002@oracle.com> Message-ID: <50320996.3010500@oracle.com> Does anybody has a chance to review it? Thanks. 13.08.2012 19:26, Sergey Bylokhov wrote: > Thanks Leonid. > > Does anybody has a chance to review it? > > 08.08.2012 10:20, Leonid Romanov wrote: >> Looks reasonable. >> >> -----Original Message----- >> From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] >> Sent: Tuesday, August 07, 2012 3:40 PM >> To: Leonid Romanov; Mike Swingler; awt-dev at openjdk.java.net; >> macosx-port-dev at openjdk.java.net >> Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts >> not displayed (7u6 regression) >> >> Hi Everyone, >> Please review the fix. >> When we translate calls from our swing menu components to awt peer we >> resets information about shortcut in the setLabel(). >> This happens because of ScreenMenuItem.setAccelerator() method call >> peers setLabel(..,..,..) directly and does not initialize >> ScreenMenuItem.shortcut property. >> But default implementation of ScreenMenuItem.setLabel() assumes that >> this field(shortcut) will be initialized. >> >> This works on jdk6 because it does not reset shortcut if null or empty >> shortcut is provided. >> As a solution we can use peers methods directly in both cases. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7186371/webrev.00 >> > > -- Best regards, Sergey. From artem.ananiev at oracle.com Mon Aug 20 03:13:49 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 20 Aug 2012 14:13:49 +0400 Subject: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components In-Reply-To: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> References: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> Message-ID: <50320DDD.8080906@oracle.com> Hi, Leonid, I don't see anything obviously wrong with the fix, however it must be reviewed by at least one more person. Thanks, Artem On 8/17/2012 9:59 PM, Leonid Romanov wrote: > Hi, > Please review a fix for CR 7124375: [macosx] Focus isn't transfered as > expected between components. > The main issue addressed by this fix is that information about current > focused window and focus owner isn't shared among > LWKeyboardFocusManagerPeer instances. Also, while the current > KeyboardFocusManager code makes it look like each KeyboardFocusManager > instance needs its own peer instance, the reality is different because > both WKeyboardFocusManagerPeer and XKeyboardManagerPeer doesn't have non > static fields. In other words, all the > WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. > Therefore, there is no need in in multiple peer instances, one singleton > peer shared among all the KeyboardFocusManager instances is enough. This > fix addresses that issue as well by explicitly turning > KeyboardManagerPeer implementations into singletons for the sake of > cleaner code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 > Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.00/ > > Thanks, > Leonid. > From Sergey.Bylokhov at oracle.com Mon Aug 20 03:29:17 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 20 Aug 2012 14:29:17 +0400 Subject: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components In-Reply-To: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> References: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> Message-ID: <5032117D.6030005@oracle.com> A few question - Is it ok that previously we have lwkfm per appcontext but not now? - javadoc for KeyboardFocusManagerPeerProvider.getKeyboardFocusManagerPeer() is not accurate - synchronisation model was changed for LW and X kfmp from internal object to synchronisation on this, but on windows there is no synchronisation this is expected? 17.08.2012 21:59, Leonid Romanov wrote: > Hi, > Please review a fix for CR 7124375: [macosx] Focus isn't transfered as expected between components. > The main issue addressed by this fix is that information about current focused window and focus owner isn't shared among LWKeyboardFocusManagerPeer instances. Also, while the current KeyboardFocusManager code makes it look like each KeyboardFocusManager instance needs its own peer instance, the reality is different because both WKeyboardFocusManagerPeer and XKeyboardManagerPeer doesn't have non static fields. In other words, all the WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. Therefore, there is no need in in multiple peer instances, one singleton peer shared among all the KeyboardFocusManager instances is enough. This fix addresses that issue as well by explicitly turning KeyboardManagerPeer implementations into singletons for the sake of cleaner code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 > Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.00/ > > Thanks, > Leonid. > -- Best regards, Sergey. From leonid.romanov at oracle.com Mon Aug 20 04:40:20 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 20 Aug 2012 15:40:20 +0400 Subject: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components In-Reply-To: <5032117D.6030005@oracle.com> References: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> <5032117D.6030005@oracle.com> Message-ID: <000101cd7ec8$9551d6e0$bff584a0$@oracle.com> Hi, - One have lwkfm per appcontex is the cause of this CR. I believe it is not necessary. However, after my fix has been pushed in 8, I'll ask Yuri to run all the focus tests, including deployment tests to make sure that nothing has been broken. - Thanks, I'll change javadoc - On Windows, thread-safety is ensured in the native code (unlike X and OS X, Windows implementation stores current focused window/focus owner in the native) -----Original Message----- From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] Sent: Monday, August 20, 2012 2:29 PM To: Leonid Romanov Cc: awt-dev at openjdk.java.net; macosx-port-dev-request at openjdk.java.net Subject: Re: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components A few question - Is it ok that previously we have lwkfm per appcontext but not now? - javadoc for KeyboardFocusManagerPeerProvider.getKeyboardFocusManagerPeer() is not accurate - synchronisation model was changed for LW and X kfmp from internal object to synchronisation on this, but on windows there is no synchronisation this is expected? 17.08.2012 21:59, Leonid Romanov wrote: > Hi, > Please review a fix for CR 7124375: [macosx] Focus isn't transfered as expected between components. > The main issue addressed by this fix is that information about current focused window and focus owner isn't shared among LWKeyboardFocusManagerPeer instances. Also, while the current KeyboardFocusManager code makes it look like each KeyboardFocusManager instance needs its own peer instance, the reality is different because both WKeyboardFocusManagerPeer and XKeyboardManagerPeer doesn't have non static fields. In other words, all the WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. Therefore, there is no need in in multiple peer instances, one singleton peer shared among all the KeyboardFocusManager instances is enough. This fix addresses that issue as well by explicitly turning KeyboardManagerPeer implementations into singletons for the sake of cleaner code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 > Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.00/ > > Thanks, > Leonid. > -- Best regards, Sergey. From joe.mcglynn at oracle.com Mon Aug 20 06:44:08 2012 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Mon, 20 Aug 2012 06:44:08 -0700 Subject: JRE/JDK for OSX and Java Preferences In-Reply-To: References: Message-ID: <08D2B737-4660-42CA-8E05-FF3A59D71370@oracle.com> I believe the thinking was that it would typically be developers running java from the command line, and they may well want to have multiple versions (JDKs) installed at the same time, and thus the ability to execute the target with a specific version of Java. You can only have a single JRE installed at any time on OS X. -- On Aug 20, 2012, at 12:23 AM, Henri Gomez wrote: > - Any reasons why CommandLine Capability is not set for JRE since JRE > works perfectly from Command Line ? From swingler at apple.com Mon Aug 20 07:43:16 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 20 Aug 2012 07:43:16 -0700 Subject: JRE/JDK for OSX and Java Preferences In-Reply-To: <08D2B737-4660-42CA-8E05-FF3A59D71370@oracle.com> References: <08D2B737-4660-42CA-8E05-FF3A59D71370@oracle.com> Message-ID: <61803C11-35BD-459B-89A8-346F8A53476C@apple.com> Also, a JRE does not contain the full range of command-line tools in /usr/bin is in a classic JDK. Regards, Mike Swingler Apple Inc. On Aug 20, 2012, at 6:44 AM, Joe McGlynn wrote: > I believe the thinking was that it would typically be developers running java from the command line, and they may well want to have multiple versions (JDKs) installed at the same time, and thus the ability to execute the target with a specific version of Java. You can only have a single JRE installed at any time on OS X. > > > > -- > > > On Aug 20, 2012, at 12:23 AM, Henri Gomez wrote: > >> - Any reasons why CommandLine Capability is not set for JRE since JRE >> works perfectly from Command Line ? > From henri.gomez at gmail.com Mon Aug 20 08:36:37 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 20 Aug 2012 17:36:37 +0200 Subject: JRE/JDK for OSX and Java Preferences In-Reply-To: <61803C11-35BD-459B-89A8-346F8A53476C@apple.com> References: <08D2B737-4660-42CA-8E05-FF3A59D71370@oracle.com> <61803C11-35BD-459B-89A8-346F8A53476C@apple.com> Message-ID: > Also, a JRE does not contain the full range of command-line tools in /usr/bin is in a classic JDK. Yep. So excluding JRE's from Java Preferences was not a mistake. Thanks guys From anton.tarasov at oracle.com Tue Aug 21 01:46:30 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 21 Aug 2012 12:46:30 +0400 Subject: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components In-Reply-To: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> References: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> Message-ID: <50334AE6.3030700@oracle.com> The changes look ok to me. Thanks, Anton. On 17.08.2012 21:59, Leonid Romanov wrote: > Hi, > Please review a fix for CR 7124375: [macosx] Focus isn't transfered as expected between components. > The main issue addressed by this fix is that information about current focused window and focus owner isn't shared among LWKeyboardFocusManagerPeer instances. Also, while the current KeyboardFocusManager code makes it look like each KeyboardFocusManager instance needs its own peer instance, the reality is different because both WKeyboardFocusManagerPeer and XKeyboardManagerPeer doesn't have non static fields. In other words, all the WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. Therefore, there is no need in in multiple peer instances, one singleton peer shared among all the KeyboardFocusManager instances is enough. This fix addresses that issue as well by explicitly turning KeyboardManagerPeer implementations into singletons for the sake of cleaner code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 > Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.00/ > > Thanks, > Leonid. > From Sergey.Bylokhov at oracle.com Tue Aug 21 02:27:39 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 21 Aug 2012 13:27:39 +0400 Subject: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components In-Reply-To: <000101cd7ec8$9551d6e0$bff584a0$@oracle.com> References: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> <5032117D.6030005@oracle.com> <000101cd7ec8$9551d6e0$bff584a0$@oracle.com> Message-ID: <5033548B.2060001@oracle.com> Thanks. Fix looks good. 20.08.2012 15:40, Leonid Romanov wrote: > Hi, > - One have lwkfm per appcontex is the cause of this CR. I believe it is not > necessary. However, after my fix has been pushed in 8, I'll ask Yuri to run > all the focus tests, including deployment tests to make sure that nothing > has been broken. > - Thanks, I'll change javadoc > - On Windows, thread-safety is ensured in the native code (unlike X and OS > X, Windows implementation stores current focused window/focus owner in the > native) > > -----Original Message----- > From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] > Sent: Monday, August 20, 2012 2:29 PM > To: Leonid Romanov > Cc: awt-dev at openjdk.java.net; macosx-port-dev-request at openjdk.java.net > Subject: Re: [8] Review request for CR 7124375: [macosx] Focus isn't > transfered as expected between components > > A few question > - Is it ok that previously we have lwkfm per appcontext but not now? > - javadoc for > KeyboardFocusManagerPeerProvider.getKeyboardFocusManagerPeer() is not > accurate > - synchronisation model was changed for LW and X kfmp from internal > object to synchronisation on this, but on windows there is no > synchronisation this is expected? > > 17.08.2012 21:59, Leonid Romanov wrote: >> Hi, >> Please review a fix for CR 7124375: [macosx] Focus isn't transfered as > expected between components. >> The main issue addressed by this fix is that information about current > focused window and focus owner isn't shared among LWKeyboardFocusManagerPeer > instances. Also, while the current KeyboardFocusManager code makes it look > like each KeyboardFocusManager instance needs its own peer instance, the > reality is different because both WKeyboardFocusManagerPeer and > XKeyboardManagerPeer doesn't have non static fields. In other words, all the > WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. Therefore, > there is no need in in multiple peer instances, one singleton peer shared > among all the KeyboardFocusManager instances is enough. This fix addresses > that issue as well by explicitly turning KeyboardManagerPeer implementations > into singletons for the sake of cleaner code. >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 >> Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.00/ >> >> Thanks, >> Leonid. >> > -- Best regards, Sergey. From steve at weblite.ca Tue Aug 21 12:17:18 2012 From: steve at weblite.ca (Steve Hannah) Date: Tue, 21 Aug 2012 12:17:18 -0700 Subject: Signing bundled JRE Message-ID: I just tried submitting my Java app to the app store last night and received an error message saying that my nested app bundle Java SE 7 is not signed. If, however, I sign the nested bundle, my app will no longer open. I get a Console log message saying that the application exited with Code: 2. I am using the Oracle JDK 1.7.0_08 preview B03 and the appbundler ANT task from Marco's fork. Can anyone offer any advice on how to proceed? (I've spent several hours looking through the docs and trying different variations with the codesign tool... but am rather stuck at this point). Thanks in advance for any help. Steve From tobi at ultramixer.com Tue Aug 21 13:05:55 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 21 Aug 2012 22:05:55 +0200 Subject: Signing bundled JRE In-Reply-To: References: Message-ID: Hi, the problem is that codesign replaces the symlinks in the OpenJDK... Tobi Am 21.08.2012 um 21:17 schrieb Steve Hannah : > I just tried submitting my Java app to the app store last night and > received an error message saying that my nested app bundle Java SE 7 is not > signed. If, however, I sign the nested bundle, my app will no longer open. > I get a Console log message saying that the application exited with Code: > 2. > > I am using the Oracle JDK 1.7.0_08 preview B03 and the appbundler ANT task > from Marco's fork. > > Can anyone offer any advice on how to proceed? (I've spent several hours > looking through the docs and trying different variations with the codesign > tool... but am rather stuck at this point). > > Thanks in advance for any help. > > Steve From swpalmer at gmail.com Tue Aug 21 13:59:24 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 21 Aug 2012 16:59:24 -0400 Subject: Signing bundled JRE In-Reply-To: References: Message-ID: *Oracle* JDK 1.7.0_08 *preview* ?? Are you allowed to bundle that? I didn't think the preview releases were redistributable. If you used OpenJDK it might be a different story. Scott P. On 2012-08-21, at 4:05 PM, Tobias Bley wrote: > Hi, > > the problem is that codesign replaces the symlinks in the OpenJDK... > > > Tobi > > > Am 21.08.2012 um 21:17 schrieb Steve Hannah : > >> I just tried submitting my Java app to the app store last night and >> received an error message saying that my nested app bundle Java SE 7 is not >> signed. If, however, I sign the nested bundle, my app will no longer open. >> I get a Console log message saying that the application exited with Code: >> 2. >> >> I am using the Oracle JDK 1.7.0_08 preview B03 and the appbundler ANT task >> from Marco's fork. >> >> Can anyone offer any advice on how to proceed? (I've spent several hours >> looking through the docs and trying different variations with the codesign >> tool... but am rather stuck at this point). >> >> Thanks in advance for any help. >> >> Steve > From dalibor.topic at oracle.com Tue Aug 21 14:12:19 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 21 Aug 2012 23:12:19 +0200 Subject: Signing bundled JRE In-Reply-To: References: Message-ID: <5033F9B3.8060400@oracle.com> On 8/21/12 9:17 PM, Steve Hannah wrote: > I am using the Oracle JDK 1.7.0_08 preview B03 and the appbundler ANT task > from Marco's fork. If you're referring to the binaries from the developer preview download on java.net, then unfortunately I must point out the license those are available under are for preview/internal use only. See: http://jdk7.java.net/license.html for details. Oracle JDK 7u6 was just released last week, so that is a much better choice. See http://www.oracle.com/technetwork/java/javase/terms/license/index.html the exact license grants & restrictions. If you for some reason absolutely must live on the sharp, bleeding edge of 7u8, which is still in an early stage of development, I'd suggest that you create your own OpenJDK 7u8 build from source. See https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port for instructions, and http://openjdk.java.net/legal/ for the licensing details. 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 marco.dinacci at gmail.com Tue Aug 21 16:00:10 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Wed, 22 Aug 2012 00:00:10 +0100 Subject: Signing bundled JRE In-Reply-To: References: Message-ID: Hi Steve, > I just tried submitting my Java app to the app store last night and > received an error message saying that my nested app bundle Java SE 7 is not > signed. If, however, I sign the nested bundle, my app will no longer open. > I get a Console log message saying that the application exited with Code: > 2. I encountered this problem too, I forgot to add it to my guide.... If you sign all the files in the bundle it won't work as codesign doesn't follow the symlinks. First sign your bundle: codesign --verbose -f -s "$SIGNATURE_APP" --entitlements $ENTITLEMENTS $YOUR_APP.app Then sign all the libraries: find $YOUR_APP/Contents/ -type f \( -name "*.jar" -or -name "*.dylib" \) -exec codesign --verbose -f -s "$SIGNATURE_APP" --entitlements $ENTITLEMENTS {} \; Finally you can create the package: productbuild --component YOUR_APP.app /Applications --sign "$SIGNATURE_INST" YOUR_APP.pkg You can test if the package work with this command: sudo installer -store -pkg $YOUR_APP.pkg -target / You can also verify all libraries have been signed find YOUR_APP/Contents/ -type f \( -name "*.jar" -or -name "*.dylib" \) -exec codesign --verbose --verify {} \; Best, Marco From steve at weblite.ca Tue Aug 21 16:31:56 2012 From: steve at weblite.ca (Steve Hannah) Date: Tue, 21 Aug 2012 16:31:56 -0700 Subject: Signing bundled JRE In-Reply-To: References: Message-ID: Thanks for all the response. As it turns out I think I may be able to get by without codesigning the embedded JRE. The error that comes up seems to have been more of a guideline. Thanks particularly to you, Marco for your great instructions on the process. I did find, though, that if I first sign the internal dylibs and jar files before I sign the bundle, then I will end up with an invalid application: codesign --verbose --verify /Applications/myapp.app /Applications/myapp.app: a sealed resource is missing or invalid In architecture: i386 I presume this is because the signing process modifies the internal libraries of the bundle after the bundle has already been signed. My signing script ended up something like the following: # First sign all of the jar files and dylib files find "$APP_PATH/Contents" -type f \( -name "*.jar" -or -name "*.dylib" \) -exec codesign --verbose=4 -f -s "$CERT" --entitlements "$ENTITLEMENTS_PATH" {} \; # Verify that they were all signed properly find "$APP_PATH/Contents" -type f \( -name "*.jar" -or -name "*.dylib" \) -exec codesign --verbose=4 --verify {} \; # Re-sign all of the jar files and dylibs inside of the bundled JDK so that they match the bundle id (net.java.openjdk.jdk) find "$APP_PATH/Contents/Plugins/1.7.0u6.jdk/Contents" -type f \( -name "*.jar" -or -name "*.dylib" \) -exec codesign --verbose=4 -i "net.java.openjdk.jdk" -f -s "$CERT" --entitlements "$ENTITLEMENTS_PATH"{} \; # Verify that all of the JDK libs were signed properly find "$APP_PATH/Contents/Plugins/1.7.0u6.jdk/Contents" -type f \( -name "*.jar" -or -name "*.dylib" \) -exec codesign --verbose=4 --verify {} \; # REMOVED: Signing the JDK bundle just breaks everything... #codesign --verbose=4 -f -s "$CERT" --entitlements "$ENTITLEMENTS_PATH" "$APP_PATH/Contents/Plugins/1.7.0u6.jdk" # Finally we sign the whole application bundle codesign --verbose=4 -f -s "$CERT" --entitlements "$ENTITLEMENTS_PATH" "$APP_PATH" This at least got me past the evil "Invalid Binary" errors upon uploading, even though it still warns me that the embedded application bundle Java 7 SE is not signed. Thanks again Steve On Tue, Aug 21, 2012 at 4:00 PM, Marco Dinacci wrote: > Hi Steve, > > > I just tried submitting my Java app to the app store last night and > > received an error message saying that my nested app bundle Java SE 7 is > not > > signed. If, however, I sign the nested bundle, my app will no longer > open. > > I get a Console log message saying that the application exited with > Code: > > 2. > > I encountered this problem too, I forgot to add it to my guide.... > If you sign all the files in the bundle it won't work as codesign > doesn't follow the symlinks. > > First sign your bundle: > codesign --verbose -f -s "$SIGNATURE_APP" --entitlements $ENTITLEMENTS > $YOUR_APP.app > > Then sign all the libraries: > find $YOUR_APP/Contents/ -type f \( -name "*.jar" -or -name "*.dylib" > \) -exec codesign --verbose -f -s "$SIGNATURE_APP" --entitlements > $ENTITLEMENTS {} \; > > Finally you can create the package: > productbuild --component YOUR_APP.app /Applications --sign > "$SIGNATURE_INST" YOUR_APP.pkg > > You can test if the package work with this command: > > sudo installer -store -pkg $YOUR_APP.pkg -target / > > You can also verify all libraries have been signed > find YOUR_APP/Contents/ -type f \( -name "*.jar" -or -name "*.dylib" > \) -exec codesign --verbose --verify {} \; > > > Best, > Marco > -- Steve Hannah Web Lite Solutions Corp. From greg.x.brown at oracle.com Wed Aug 22 05:44:47 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Wed, 22 Aug 2012 08:44:47 -0400 Subject: Signing bundled JRE In-Reply-To: References: Message-ID: <69BAFD45-7A79-4EB3-BEBE-0BF520A0F1DE@oracle.com> > I just tried submitting my Java app to the app store last night and > received an error message saying that my nested app bundle Java SE 7 is not > signed. If, however, I sign the nested bundle, my app will no longer open. > I get a Console log message saying that the application exited with Code: > 2. > > I am using the Oracle JDK 1.7.0_08 preview B03 and the appbundler ANT task > from Marco's fork. I'm not sure what the forked version is doing now, but I believe we resolved this issue in AppBundler itself: http://java.net/projects/appbundler The launcher stub no longer relies on the symlink, so you should be able to sign the app without breaking it. Let me know if you run into any problems. From marco.dinacci at gmail.com Wed Aug 22 06:28:13 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Wed, 22 Aug 2012 14:28:13 +0100 Subject: Signing bundled JRE In-Reply-To: References: Message-ID: Hi Steve, > Thanks for all the response. As it turns out I think I may be able to get > by without codesigning the embedded JRE. The error that comes up seems to > have been more of a guideline. Apple documentation says: You should sign every executable in your product, including applications, tools, hidden helper tools, utilities and so forth. Signing an application bundle covers its resources, but not its subcomponents such as tools and sub-bundles. Each of these must be signed independently. So I think you have to sign all the libraries too. After my first submission I got an e-mail back from Apple with a bunch of Invalid Signature errors referring to every single dylib in the bundle... I've a couple more suggestions regarding your error message. Check that you include libfreetype.6.dylib which is *not* included in a prepackaged jvm and that you patch libfontmanager.dylib with install_name_tool (sudo install_name_tool -change /usr/X11/libfreetype.6.dylib @rpath/libfreetype.dylib libfontmanager.dylib). Second, if you zip the resulting .app, be sure to use the option --symlinks or -y otherwise the zip utility will copy and compress libjli.dylib in Contents/MacOS instead of respecting the symlink. Best, Marco From steve at weblite.ca Wed Aug 22 09:23:27 2012 From: steve at weblite.ca (Steve Hannah) Date: Wed, 22 Aug 2012 09:23:27 -0700 Subject: Signing bundled JRE In-Reply-To: <69BAFD45-7A79-4EB3-BEBE-0BF520A0F1DE@oracle.com> References: <69BAFD45-7A79-4EB3-BEBE-0BF520A0F1DE@oracle.com> Message-ID: On Wed, Aug 22, 2012 at 5:44 AM, Greg Brown wrote: > > > I'm not sure what the forked version is doing now, but I believe we > resolved this issue in AppBundler itself: > > http://java.net/projects/appbundler > > The launcher stub no longer relies on the symlink, so you should be able > to sign the app without breaking it. Let me know if you run into any > problems. > > > Good to know. I was using Marco's fork of AppBundler so that I could use the tag. I'll try out the main version later today to see if it fixes the issue. Best regards Steve From steve at weblite.ca Wed Aug 22 09:27:40 2012 From: steve at weblite.ca (Steve Hannah) Date: Wed, 22 Aug 2012 09:27:40 -0700 Subject: Signing bundled JRE In-Reply-To: References: Message-ID: On Wed, Aug 22, 2012 at 6:28 AM, Marco Dinacci wrote: > > So I think you have to sign all the libraries too. After my first > submission I got an e-mail back from Apple with a bunch of Invalid > Signature errors referring to every single dylib in the bundle... > Agreed. I do sign all of the dylib and jar files, I just found that I have to sign those *before* I sign the app bundle. If I sign them after signing the app bundle, then the act of signing the subcomponents invalidates the signature of the bundle. > > I've a couple more suggestions regarding your error message. Check > that you include libfreetype.6.dylib which is *not* included in a > prepackaged jvm and that you patch libfontmanager.dylib with > install_name_tool (sudo install_name_tool -change > /usr/X11/libfreetype.6.dylib @rpath/libfreetype.dylib > libfontmanager.dylib). > Done. I used the instructions on your blog to get past this obstacle. > > Second, if you zip the resulting .app, be sure to use the option > --symlinks or -y otherwise the zip utility will copy and compress > libjli.dylib in Contents/MacOS instead of respecting the symlink. > > Good point. I wasn't zipping it, but this is good to keep in mind for the inevitable future when I'll zip a signed app only to find out that it is broken :) -Steve > > Best, > Marco > -- Steve Hannah Web Lite Solutions Corp. From marco.dinacci at gmail.com Wed Aug 22 09:51:22 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Wed, 22 Aug 2012 17:51:22 +0100 Subject: Signing bundled JRE In-Reply-To: References: <69BAFD45-7A79-4EB3-BEBE-0BF520A0F1DE@oracle.com> Message-ID: Hi, > Good to know. I was using Marco's fork of AppBundler so that I could use > the tag. I'll try out the main version later today to see > if it fixes the issue. Steve, I just merged the latest changes in the original AppBundler in my fork. Greg, any interest in merging my changes back to the original AppBundler code ? I'd rather focus on my app than maintaining forks if possible but the lack of some features in the original AppBundler (especially the inability to register document types) make it impossible to use for real life applications. You can see all the changes here: https://bitbucket.org/sreilly/appbundler/changesets Best, Marco From greg.x.brown at oracle.com Wed Aug 22 10:02:22 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Wed, 22 Aug 2012 13:02:22 -0400 Subject: Signing bundled JRE In-Reply-To: References: <69BAFD45-7A79-4EB3-BEBE-0BF520A0F1DE@oracle.com> Message-ID: > Greg, any interest in merging my changes back to the original > AppBundler code ? Definitely interested, though I'm not sure what the legal implications are (i.e. I'm not sure if we are allowed to accept patches or not). > the lack of some features in the original AppBundler > (especially the inability to register document types) make it > impossible to use for real life applications Are you referring to this issue? http://java.net/jira/browse/APPBUNDLER-1 From marco.dinacci at gmail.com Wed Aug 22 10:14:24 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Wed, 22 Aug 2012 18:14:24 +0100 Subject: Signing bundled JRE In-Reply-To: References: <69BAFD45-7A79-4EB3-BEBE-0BF520A0F1DE@oracle.com> Message-ID: Hi, > Definitely interested, though I'm not sure what the legal implications are (i.e. I'm not sure if we are allowed to accept patches or not). If you're allowed to accept them, feel free to grab them from the repo or ask me for a patch. AppBundler is GPLv2, so my changes follows the same license. > Are you referring to this issue? > > http://java.net/jira/browse/APPBUNDLER-1 yes. Best, Marco From Sergey.Bylokhov at oracle.com Thu Aug 23 02:56:33 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 Aug 2012 13:56:33 +0400 Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: <50320996.3010500@oracle.com> References: <5020FE7B.6020402@oracle.com> <001201cd752d$e9476200$bbd62600$@oracle.com> <50291CC3.8010002@oracle.com> <50320996.3010500@oracle.com> Message-ID: <5035FE51.5050103@oracle.com> There are no volunteers? 20.08.2012 13:55, Sergey Bylokhov wrote: > Does anybody has a chance to review it? > Thanks. > > 13.08.2012 19:26, Sergey Bylokhov wrote: >> Thanks Leonid. >> >> Does anybody has a chance to review it? >> >> 08.08.2012 10:20, Leonid Romanov wrote: >>> Looks reasonable. >>> >>> -----Original Message----- >>> From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] >>> Sent: Tuesday, August 07, 2012 3:40 PM >>> To: Leonid Romanov; Mike Swingler; awt-dev at openjdk.java.net; >>> macosx-port-dev at openjdk.java.net >>> Subject: [8] Review request for 7186371: [macosx] Main menu >>> shortcuts not displayed (7u6 regression) >>> >>> Hi Everyone, >>> Please review the fix. >>> When we translate calls from our swing menu components to awt peer we >>> resets information about shortcut in the setLabel(). >>> This happens because of ScreenMenuItem.setAccelerator() method call >>> peers setLabel(..,..,..) directly and does not initialize >>> ScreenMenuItem.shortcut property. >>> But default implementation of ScreenMenuItem.setLabel() assumes that >>> this field(shortcut) will be initialized. >>> >>> This works on jdk6 because it does not reset shortcut if null or empty >>> shortcut is provided. >>> As a solution we can use peers methods directly in both cases. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7186371/webrev.00 >>> >> >> > > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Aug 23 04:40:42 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 23 Aug 2012 15:40:42 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <50251406.6060708@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> Message-ID: <503616BA.6050007@oracle.com> Could someone review the fix? Thanks, Alexandr. On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ > > The comments are below: > > On 8/7/2012 6:47 PM, Mike Swingler wrote: >> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >> simple 32 bit int is probably not what you intended to do. > fixed. >> Also, have you considered simply calling -[NSWindow >> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then >> removing the calls that flip it on and off in -[AWTView >> mouseEntered:] and -[AWTView mouseExited"]? This would also require a >> change in >> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >> which has a comment that states it only turns on mouse moved events >> if the window is currently under the mouse. > I tried it. The result that I got is that a dragging mouse from > one window to another does not generate mouse enter/exit events on the > second window in case when tracking rect is used and the > acceptsMouseMovedEvents flag is always set to YES. > >> I would think that AppKit should be more than happy to send you >> mouse-over/enter/exited events as long as you say you want them. Was >> this approach tried and didn't work for some reason? >>> Hi, Alexander. >>> Probably all this stuff can be simplified? Can you try to change >>> TrackingRect to TrackingArea with appropriate flags like >>> NSTrackingEnabledDuringMouseDrag etc. > I changed the TrackingRect to TrackingArea in the updated fix. It > now generates the mouse enter/exit events on the second window during > drag. > So it is not necessary to generates such events from our side. > > The getTopmostWindowUnderMouse is necessary to handle mouse > enter/exit events for component in case when a mouse is dragged from > one window to another. > Where the second window contains it's own components and the only > way to know about tracking over them are drag events which receives > the first window. > > I think that the LWWindowPeer class code can be simplified if we > assume that window mouse enter/exit events are always come to the > current window. > So the component mouse enter/exit events can be tracked only in the > current or topmost window. > For this case I separated the global lastCommonMouseEventPeer which > is necessary for the cursor manager and the local lastMouseEventPeer. > > According to the specification: The proper order of mouse-entered > and mouse-exited events received by tracking-area objects in an > application cannot be guaranteed. > > https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html > So it seems it is not possible to have one lastMouseEventPeer > instead of two: lastCommonMouseEventPeer and lastMouseEventPeer. > > And there are possible situations that we can receive mouse drag > event between enter and exit. > To handle this the isMouseOver flag is added to the LWWindowPeer > class. So the component mouse enter/exit events are not generated if > the window mouse exited event is received and window mouse entered is > not. > > There is the test: > test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java > It shows that even using the TrackingArea some mouse enter/exit > events are not generateed in the following cases: > - window is created under the mouse > - window changes it's bounds so it becomes under the mouse > > For this cases it still necessary to generate mouse enter/exit > events from our side. > I just moved the related code to one method > synthesizeMouseEnteredExitedEventsForAllWindows. > > Thanks, > Alexandr. > >>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>> >>>> This is a regression after the fix 7154048 [macosx] At least drag >>>> twice, the toolbar can be dragged to the left side. >>>> >>>> In the case where a toolbar is created under a mouse and it is >>>> dragged over the initial window the mouse enter/exit events should >>>> not be generated for the components which are under the toolbar. >>>> >>>> The current fix is supposed to solve this regression and also to >>>> fix generation of mouse enter/exit events for all cases where a >>>> mouse is dragged from one window to another or a new window is >>>> created under a mouse (like it is implemented for toolbar). >>>> >>>> Let's see the following cases >>>> 1) Mouse is dragged from a window and back to the same window. >>>> The Mac OS X system generates a mouse exit event only the first >>>> time when a mouse is dragged from a window and does not generate >>>> mouse enter/exit events next times during one drag trace. >>>> >>>> 2) Mouse is dragged from one window to another. >>>> The Mac OS X system does not generate mouse enter/exit events for >>>> the second window. >>>> >>>> 3) Mouse is dragged from one window to another and released. >>>> In this case the Mac OS X system generates mouse enter event for >>>> the second window only after releasing the mouse. >>>> >>>> 4) Clicking on window creates a new window after that the new >>>> window is dragged (toolbar dragging). >>>> >>>> However the Java system generates mouse enter/exit events each time >>>> when a mouse is dragged over any window. >>>> >>>> To fix this the following methods are introduced: >>>> - Get topmost window under mouse >>>> - Synthesize mouse enter/exit events for all windows >>>> >>>> >>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>> handled previous and next components and is able to generate mouse >>>> enter/exit events for them. >>>> However the the AWTView native class contains isMouseOver flag >>>> which value becomes inconsistent if we do not updated it. Because >>>> of this the fix generates the mouse enter/exit window events on the >>>> native side. >>>> >>>> Generating mouse enter/exit events always should be in order where >>>> mouse exit events are generated before the mouse enter events. >>>> >>>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to >>>> generate mouse enter/exit events for all windows during mouse drag >>>> or window creation/window bounds changing. >>>> However only those windows which isMouseOver flag is differ from >>>> the isTopMostWindowUnderMouse state are affected. >>>> This method also tries to generate both mouse enter and exit event >>>> for the same window but only one of them can be applicable because >>>> the isTopMostWindowUnderMouse state is not changed for these calls. >>>> >>>> So the window enter/exit events now are always generated from the >>>> native system and component enter/exit events are generated in the >>>> LWWindowPeer class. >>>> >>>> LWWindowPeer class now uses three links to components: current, >>>> last and topmostUnderMouse. All of them are necessary because in >>>> case when a mouse is dragged from one window to another the current >>>> component receives drag events and last and topmostUnderMouse links >>>> handle components mouse exit/enter events on the second window. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>> >>> -- >>> Best regards, Sergey. >>> > From henri.gomez at gmail.com Thu Aug 23 05:48:46 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 23 Aug 2012 14:48:46 +0200 Subject: Linker report unsupported file format for OpenJDK 8 and derivated Message-ID: Hi to all, I notice a strange error report on building OSX versions of OpenJDK 8, Lambda and Jigsaw. It seems fdlibm is built in 64bits mode : /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -m64 But linker expect an universal mode (-arch i386 -arch x86_64) and linker get lost somewhere with .o files. I'll be more than happy to see universal mode (32/64bits) back in OpenJDK 8 OSX, but here it seems there is a mix of mode and if build is done for strict 64bits, linker should follow. --- STATS: LIBRARY=fdlibm, PRODUCT=java, OPTIMIZATION_LEVEL=NONE Rebuilding /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/libfdlibm.x86_64.a because of /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/.files_compiled /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -nostdlib -r -arch i386 -arch x86_64 -o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/libfdlibm.x86_64.a /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_standard.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_rem_pio2.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_cos.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_sin.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_tan.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_acos.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_asin.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_atan2.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_atanh.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_cosh.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_exp.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_fmod.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_hypot.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_log.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_log10.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_pow.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_rem_pio2.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_remainder.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_scalb.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_sinh.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_sqrt.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_acos.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_asin.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_atan2.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_atanh.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_cosh.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_exp.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_fmod.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_hypot.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_log.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_log10.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_pow.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_remainder.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_scalb.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_sinh.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_sqrt.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_atan.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_cbrt.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_ceil.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_copysign.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_cos.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_expm1.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_fabs.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_finite.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_floor.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_frexp.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_ilogb.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_isnan.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_ldexp.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_lib_version.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_log1p.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_logb.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_matherr.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_modf.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_nextafter.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_rint.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_scalbn.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_signgam.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_significand.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_sin.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_tan.o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_tanh.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_standard.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_standard.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_rem_pio2.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_rem_pio2.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_cos.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_cos.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_sin.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_sin.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_tan.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_tan.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_acos.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_acos.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_asin.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_asin.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_atan2.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_atan2.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_atanh.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_atanh.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_cosh.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_cosh.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_exp.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_exp.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_fmod.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_fmod.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_hypot.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_hypot.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_log.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_log.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_log10.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_log10.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_pow.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_pow.o ld: warning: ignoring file /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_rem_pio2.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_rem_pio2.o From anthony.petrov at oracle.com Thu Aug 23 05:51:00 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 23 Aug 2012 16:51:00 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503616BA.6050007@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> Message-ID: <50362734.5060600@oracle.com> Hi Alexandr, 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate through app's windows only once and send both Exited and Entered events where needed? 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no longer requires a window pointer as an argument. 3. Here's a major concern: the LWWindowPeer (and other LW* classes) should never import C* classes. Instead you should've added a new method to the PlatformWindow interface, and used it from LWWindowPeer. The CPlatformWindow should've implemented this method, and called an appropriate native method from there. In this case, however, you actually need a static method, so it'd better be part of the LWToolkit interface, and implemented in the LWCToolkit class instead. -- best regards, Anthony On 08/23/12 15:40, Alexander Scherbatiy wrote: > > Could someone review the fix? > > Thanks, > Alexandr. > > On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >> >> The comments are below: >> >> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>> simple 32 bit int is probably not what you intended to do. >> fixed. >>> Also, have you considered simply calling -[NSWindow >>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then >>> removing the calls that flip it on and off in -[AWTView >>> mouseEntered:] and -[AWTView mouseExited"]? This would also require a >>> change in >>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>> which has a comment that states it only turns on mouse moved events >>> if the window is currently under the mouse. >> I tried it. The result that I got is that a dragging mouse from one >> window to another does not generate mouse enter/exit events on the >> second window in case when tracking rect is used and the >> acceptsMouseMovedEvents flag is always set to YES. >> >>> I would think that AppKit should be more than happy to send you >>> mouse-over/enter/exited events as long as you say you want them. Was >>> this approach tried and didn't work for some reason? >>>> Hi, Alexander. >>>> Probably all this stuff can be simplified? Can you try to change >>>> TrackingRect to TrackingArea with appropriate flags like >>>> NSTrackingEnabledDuringMouseDrag etc. >> I changed the TrackingRect to TrackingArea in the updated fix. It now >> generates the mouse enter/exit events on the second window during drag. >> So it is not necessary to generates such events from our side. >> >> The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit >> events for component in case when a mouse is dragged from one window >> to another. >> Where the second window contains it's own components and the only way >> to know about tracking over them are drag events which receives the >> first window. >> >> I think that the LWWindowPeer class code can be simplified if we >> assume that window mouse enter/exit events are always come to the >> current window. >> So the component mouse enter/exit events can be tracked only in the >> current or topmost window. >> For this case I separated the global lastCommonMouseEventPeer which is >> necessary for the cursor manager and the local lastMouseEventPeer. >> >> According to the specification: The proper order of mouse-entered and >> mouse-exited events received by tracking-area objects in an >> application cannot be guaranteed. >> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >> >> So it seems it is not possible to have one lastMouseEventPeer instead >> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >> >> And there are possible situations that we can receive mouse drag event >> between enter and exit. >> To handle this the isMouseOver flag is added to the LWWindowPeer >> class. So the component mouse enter/exit events are not generated if >> the window mouse exited event is received and window mouse entered is >> not. >> >> There is the test: >> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >> It shows that even using the TrackingArea some mouse enter/exit events >> are not generateed in the following cases: >> - window is created under the mouse >> - window changes it's bounds so it becomes under the mouse >> >> For this cases it still necessary to generate mouse enter/exit events >> from our side. >> I just moved the related code to one method >> synthesizeMouseEnteredExitedEventsForAllWindows. >> >> Thanks, >> Alexandr. >> >>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>> >>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>> twice, the toolbar can be dragged to the left side. >>>>> >>>>> In the case where a toolbar is created under a mouse and it is >>>>> dragged over the initial window the mouse enter/exit events should >>>>> not be generated for the components which are under the toolbar. >>>>> >>>>> The current fix is supposed to solve this regression and also to >>>>> fix generation of mouse enter/exit events for all cases where a >>>>> mouse is dragged from one window to another or a new window is >>>>> created under a mouse (like it is implemented for toolbar). >>>>> >>>>> Let's see the following cases >>>>> 1) Mouse is dragged from a window and back to the same window. >>>>> The Mac OS X system generates a mouse exit event only the first >>>>> time when a mouse is dragged from a window and does not generate >>>>> mouse enter/exit events next times during one drag trace. >>>>> >>>>> 2) Mouse is dragged from one window to another. >>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>> the second window. >>>>> >>>>> 3) Mouse is dragged from one window to another and released. >>>>> In this case the Mac OS X system generates mouse enter event for >>>>> the second window only after releasing the mouse. >>>>> >>>>> 4) Clicking on window creates a new window after that the new >>>>> window is dragged (toolbar dragging). >>>>> >>>>> However the Java system generates mouse enter/exit events each time >>>>> when a mouse is dragged over any window. >>>>> >>>>> To fix this the following methods are introduced: >>>>> - Get topmost window under mouse >>>>> - Synthesize mouse enter/exit events for all windows >>>>> >>>>> >>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>> handled previous and next components and is able to generate mouse >>>>> enter/exit events for them. >>>>> However the the AWTView native class contains isMouseOver flag >>>>> which value becomes inconsistent if we do not updated it. Because >>>>> of this the fix generates the mouse enter/exit window events on the >>>>> native side. >>>>> >>>>> Generating mouse enter/exit events always should be in order where >>>>> mouse exit events are generated before the mouse enter events. >>>>> >>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to >>>>> generate mouse enter/exit events for all windows during mouse drag >>>>> or window creation/window bounds changing. >>>>> However only those windows which isMouseOver flag is differ from >>>>> the isTopMostWindowUnderMouse state are affected. >>>>> This method also tries to generate both mouse enter and exit event >>>>> for the same window but only one of them can be applicable because >>>>> the isTopMostWindowUnderMouse state is not changed for these calls. >>>>> >>>>> So the window enter/exit events now are always generated from the >>>>> native system and component enter/exit events are generated in the >>>>> LWWindowPeer class. >>>>> >>>>> LWWindowPeer class now uses three links to components: current, >>>>> last and topmostUnderMouse. All of them are necessary because in >>>>> case when a mouse is dragged from one window to another the current >>>>> component receives drag events and last and topmostUnderMouse links >>>>> handle components mouse exit/enter events on the second window. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >> > From david.holmes at oracle.com Thu Aug 23 18:03:57 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Aug 2012 11:03:57 +1000 Subject: Linker report unsupported file format for OpenJDK 8 and derivated In-Reply-To: References: Message-ID: <5036D2FD.2060107@oracle.com> Hi Henri, On 23/08/2012 10:48 PM, Henri Gomez wrote: > Hi to all, > > I notice a strange error report on building OSX versions of OpenJDK 8, > Lambda and Jigsaw. > > It seems fdlibm is built in 64bits mode : > > /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc > -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses > -pipe -m64 > > But linker expect an universal mode (-arch i386 -arch x86_64) and > linker get lost somewhere with .o files. > > I'll be more than happy to see universal mode (32/64bits) back in > OpenJDK 8 OSX, but here it seems there is a mix of mode and if build > is done for strict 64bits, linker should follow. Wasn't this issue (or a similar one) previously reported and "simply" a case where the current JDK build process does not support cross-compiling a 32-bit JDK on a 64-bit host? Have you tried using the new build system (which does support 32-bit builds on 64-bit hosts)? David > --- > > STATS: LIBRARY=fdlibm, PRODUCT=java, OPTIMIZATION_LEVEL=NONE > Rebuilding /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/libfdlibm.x86_64.a > because of /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/.files_compiled > /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -nostdlib > -r -arch i386 -arch x86_64 -o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/libfdlibm.x86_64.a > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_standard.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_rem_pio2.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_cos.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_sin.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_tan.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_acos.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_asin.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_atan2.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_atanh.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_cosh.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_exp.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_fmod.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_hypot.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_log.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_log10.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_pow.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_rem_pio2.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_remainder.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_scalb.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_sinh.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_sqrt.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_acos.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_asin.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_atan2.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_atanh.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_cosh.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_exp.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_fmod.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_hypot.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_log.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_log10.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_pow.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_remainder.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_scalb.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_sinh.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/w_sqrt.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_atan.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_cbrt.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_ceil.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_copysign.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_cos.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_expm1.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_fabs.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_finite.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_floor.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_frexp.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_ilogb.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_isnan.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_ldexp.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_lib_version.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_log1p.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_logb.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_matherr.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_modf.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_nextafter.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_rint.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_scalbn.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_signgam.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_significand.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_sin.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_tan.o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/s_tanh.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_standard.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_standard.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_rem_pio2.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_rem_pio2.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_cos.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_cos.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_sin.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_sin.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_tan.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/k_tan.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_acos.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_acos.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_asin.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_asin.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_atan2.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_atan2.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_atanh.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_atanh.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_cosh.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_cosh.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_exp.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_exp.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_fmod.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_fmod.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_hypot.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_hypot.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_log.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_log.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_log10.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_log10.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_pow.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_pow.o > ld: warning: ignoring file > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_rem_pio2.o, > file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 > 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not > the architecture being linked (i386): > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/fdlibm/obj64/e_rem_pio2.o From philip.race at oracle.com Thu Aug 23 18:20:26 2012 From: philip.race at oracle.com (Phil Race) Date: Thu, 23 Aug 2012 18:20:26 -0700 Subject: Linker report unsupported file format for OpenJDK 8 and derivated In-Reply-To: <5036D2FD.2060107@oracle.com> References: <5036D2FD.2060107@oracle.com> Message-ID: <5036D6DA.5030501@oracle.com> On 8/23/12 6:03 PM, David Holmes wrote: > > Wasn't this issue (or a similar one) previously reported and "simply" > a case where the current JDK build process does not support > cross-compiling a 32-bit JDK on a 64-bit host? As a general statement, this is not correct. 64 Bit windows builds 32 bit JDK for windows just fine 64 bit Solaris (all there is really on SPARC), builds a 32 bit JDK just fine. Same should be true for Linux as far as I know. -phil. From david.holmes at oracle.com Thu Aug 23 19:10:55 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Aug 2012 12:10:55 +1000 Subject: Linker report unsupported file format for OpenJDK 8 and derivated In-Reply-To: <5036D6DA.5030501@oracle.com> References: <5036D2FD.2060107@oracle.com> <5036D6DA.5030501@oracle.com> Message-ID: <5036E2AF.2030207@oracle.com> On 24/08/2012 11:20 AM, Phil Race wrote: > On 8/23/12 6:03 PM, David Holmes wrote: >> >> Wasn't this issue (or a similar one) previously reported and "simply" >> a case where the current JDK build process does not support >> cross-compiling a 32-bit JDK on a 64-bit host? > > > As a general statement, this is not correct. > 64 Bit windows builds 32 bit JDK for windows just fine Correct, it has worked on windows for a long time. > 64 bit Solaris (all there is really on SPARC), builds a 32 bit JDK just > fine. Ok. But some of the issues on Linux do not seem obviously linux specific. > Same should be true for Linux as far as I know. No Linux is broken. There are a few places where the compiler is invoked without -m32 or -m64 and so defaults to building the native format ie 64-bit on 64-bit. See 7171653 for a problem with the sizers utility, and 7153072 in general. David ----- > -phil. > > From philip.race at oracle.com Thu Aug 23 20:29:05 2012 From: philip.race at oracle.com (Phil Race) Date: Thu, 23 Aug 2012 20:29:05 -0700 Subject: Linker report unsupported file format for OpenJDK 8 and derivated In-Reply-To: <5036E2AF.2030207@oracle.com> References: <5036D2FD.2060107@oracle.com> <5036D6DA.5030501@oracle.com> <5036E2AF.2030207@oracle.com> Message-ID: <5036F501.7050405@oracle.com> On 8/23/12 7:10 PM, David Holmes wrote: > On 24/08/2012 11:20 AM, Phil Race wrote: >> On 8/23/12 6:03 PM, David Holmes wrote: >>> >>> Wasn't this issue (or a similar one) previously reported and "simply" >>> a case where the current JDK build process does not support >>> cross-compiling a 32-bit JDK on a 64-bit host? >> >> >> As a general statement, this is not correct. >> 64 Bit windows builds 32 bit JDK for windows just fine > > Correct, it has worked on windows for a long time. > >> 64 bit Solaris (all there is really on SPARC), builds a 32 bit JDK just >> fine. > > Ok. But some of the issues on Linux do not seem obviously linux specific. SInce RE build this way I am fairly sure it must work (more than) adequately. > >> Same should be true for Linux as far as I know. > > No Linux is broken. There are a few places where the compiler is > invoked without -m32 or -m64 and so defaults to building the native > format ie 64-bit on 64-bit. See 7171653 for a problem with the sizers > utility, and 7153072 in general. > OK, I did say "as far as I know". I only claimed what I know to be the case ... -phil. > David > ----- > >> -phil. >> >> From philip.race at oracle.com Thu Aug 23 20:41:53 2012 From: philip.race at oracle.com (Phil Race) Date: Thu, 23 Aug 2012 20:41:53 -0700 Subject: Linker report unsupported file format for OpenJDK 8 and derivated In-Reply-To: <5036F501.7050405@oracle.com> References: <5036D2FD.2060107@oracle.com> <5036D6DA.5030501@oracle.com> <5036E2AF.2030207@oracle.com> <5036F501.7050405@oracle.com> Message-ID: <5036F801.6090802@oracle.com> PS >>> Same should be true for Linux as far as I know. >> >> No Linux is broken. There are a few places where the compiler is >> invoked without -m32 or -m64 and so defaults to building the native >> format ie 64-bit on 64-bit. See 7171653 for a problem with the sizers >> utility, and 7153072 in general. >> > OK, I did say "as far as I know". I only claimed what I know to be the > case ... > Actually I did know about 7171653 but I thought it was fixed ~ 2 months ago sometime after Gary and I discussed it. -phil. From david.holmes at oracle.com Thu Aug 23 20:51:16 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Aug 2012 13:51:16 +1000 Subject: Linker report unsupported file format for OpenJDK 8 and derivated In-Reply-To: <5036F801.6090802@oracle.com> References: <5036D2FD.2060107@oracle.com> <5036D6DA.5030501@oracle.com> <5036E2AF.2030207@oracle.com> <5036F501.7050405@oracle.com> <5036F801.6090802@oracle.com> Message-ID: <5036FA34.7020506@oracle.com> On 24/08/2012 1:41 PM, Phil Race wrote: > PS >>>> Same should be true for Linux as far as I know. >>> >>> No Linux is broken. There are a few places where the compiler is >>> invoked without -m32 or -m64 and so defaults to building the native >>> format ie 64-bit on 64-bit. See 7171653 for a problem with the sizers >>> utility, and 7153072 in general. >>> >> OK, I did say "as far as I know". I only claimed what I know to be the >> case ... >> > > Actually I did know about 7171653 but I thought it was fixed ~ 2 months ago > sometime after Gary and I discussed it. Yes I fixed it :) I threw it in there because it was an issue you would have been familiar with. (sparcv9 already special-cased it). The general problem hasn't been fixed because the new build already handles it. Anyway, there are problems with the Linux build that have been inherited by the OSX build due to their sharing of files/settings. Cheers, David From henri.gomez at gmail.com Fri Aug 24 02:07:33 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 24 Aug 2012 11:07:33 +0200 Subject: Linker report unsupported file format for OpenJDK 8 and derivated In-Reply-To: <5036FA34.7020506@oracle.com> References: <5036D2FD.2060107@oracle.com> <5036D6DA.5030501@oracle.com> <5036E2AF.2030207@oracle.com> <5036F501.7050405@oracle.com> <5036F801.6090802@oracle.com> <5036FA34.7020506@oracle.com> Message-ID: > Yes I fixed it :) I threw it in there because it was an issue you would have > been familiar with. (sparcv9 already special-cased it). The general problem > hasn't been fixed because the new build already handles it. For OSX, I'm still using the old one for OpenJDK7 and various OpenJDK8 (lambda, jigsaw). Do you means that we should all switch to new build system since old build may be partially buggy ? > Anyway, there are problems with the Linux build that have been inherited by > the OSX build due to their sharing of files/settings. New or old builds for Linux/OSX ? From paul_t100 at fastmail.fm Fri Aug 24 03:17:34 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 24 Aug 2012 11:17:34 +0100 Subject: JFileChooser not seeing network mounted files on 1.7.0_06 on Mac In-Reply-To: <502CEB07.40708@oracle.com> References: <502CB1ED.9070507@fastmail.fm> <502CEB07.40708@oracle.com> Message-ID: <503754BE.9000009@fastmail.fm> On 16/08/2012 13:43, Anthony Petrov wrote: > I don't recall such an issue. BTW, is the NAS accessible via > java.io.File API? > > In any case, please file a bug report at http://bugs.sun.com/ > > -- > best regards, > Anthony Actually I may get getting confused here they are they if I select Harddrive from the top option and then /Volumes folder. But is much harder to find this folder then from native applications, i.e if i start iTunes and select File/Add to Library... I get a dialog that contains a Favourites coliumn and looks very much like a Finder Window. In another project i used Quaqua File Chooser and that wasn't far off the iTUnes dialog but don't know if supported on Java 7. But then I relunctanctly tried using a java.awt.FileDialog instead of a JFileChooser and they look pretty much the same, i.e nothing like an iTunes dialog , I though the FIleDIalog would have all the functionality of a native file dialog ? Paul From anthony.petrov at oracle.com Fri Aug 24 03:50:44 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 24 Aug 2012 14:50:44 +0400 Subject: JFileChooser not seeing network mounted files on 1.7.0_06 on Mac In-Reply-To: <503754BE.9000009@fastmail.fm> References: <502CB1ED.9070507@fastmail.fm> <502CEB07.40708@oracle.com> <503754BE.9000009@fastmail.fm> Message-ID: <50375C84.8030009@oracle.com> On 8/24/2012 2:17 PM, Paul Taylor wrote: > On 16/08/2012 13:43, Anthony Petrov wrote: >> I don't recall such an issue. BTW, is the NAS accessible via >> java.io.File API? >> >> In any case, please file a bug report at http://bugs.sun.com/ >> > Actually I may get getting confused here they are they if I select > Harddrive from the top option and then /Volumes folder. But is much > harder to find this folder then from native applications, i.e if i start > iTunes and select File/Add to Library... I get a dialog that contains a > Favourites coliumn and looks very much like a Finder Window. In another > project i used Quaqua File Chooser and that wasn't far off the iTUnes > dialog but don't know if supported on Java 7. But then I relunctanctly > tried using a java.awt.FileDialog instead of a JFileChooser and they > look pretty much the same, i.e nothing like an iTunes dialog , I though > the FIleDIalog would have all the functionality of a native file dialog ? Well, j.a.FileDialog *is* a native file chooser dialog after all. Maybe it's just missing a couple additional calls/styles that would enable more native features. Have you filed a bug/RFE yet? -- best regards, Anthony From paul_t100 at fastmail.fm Fri Aug 24 04:02:02 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 24 Aug 2012 12:02:02 +0100 Subject: JFileChooser not seeing network mounted files on 1.7.0_06 on Mac In-Reply-To: <50375C84.8030009@oracle.com> References: <502CB1ED.9070507@fastmail.fm> <502CEB07.40708@oracle.com> <503754BE.9000009@fastmail.fm> <50375C84.8030009@oracle.com> Message-ID: <50375F2A.1080304@fastmail.fm> On 24/08/2012 11:50, Anthony Petrov wrote: > On 8/24/2012 2:17 PM, Paul Taylor wrote: >> On 16/08/2012 13:43, Anthony Petrov wrote: >>> I don't recall such an issue. BTW, is the NAS accessible via >>> java.io.File API? >>> >>> In any case, please file a bug report at http://bugs.sun.com/ >>> >> Actually I may get getting confused here they are they if I select >> Harddrive from the top option and then /Volumes folder. But is much >> harder to find this folder then from native applications, i.e if i >> start iTunes and select File/Add to Library... I get a dialog that >> contains a Favourites coliumn and looks very much like a Finder >> Window. In another project i used Quaqua File Chooser and that wasn't >> far off the iTUnes dialog but don't know if supported on Java 7. But >> then I relunctanctly tried using a java.awt.FileDialog instead of a >> JFileChooser and they look pretty much the same, i.e nothing like an >> iTunes dialog , I though the FIleDIalog would have all the >> functionality of a native file dialog ? > > Well, j.a.FileDialog *is* a native file chooser dialog after all. > Maybe it's just missing a couple additional calls/styles that would > enable more native features. > No, because I'm really not clear if I'm doing something wrong here, and surely having a file dialog that has the functionality of the dialogs used by another applications is a long standing existing issue. The other thing Im confused about (in a good way) is that both FileDialog and JFileCHooser do seem to correct icons, i,e the applications folder contains a little blue A on the folder, whereas this post http://nadeausoftware.com/node/89#UsingtheJFileChoosertogetMacfileandfoldericons indicated JFileChooser does not. Paul From mik3hall at gmail.com Fri Aug 24 04:09:59 2012 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 24 Aug 2012 06:09:59 -0500 Subject: jdk based applications Message-ID: <2FF97125-C481-48B4-9066-510CB8BAF942@gmail.com> Is the only way to have a normal jdk based desktop application to embed the jdk? I would assume there wouldn't be anything to prevent an application runtime exec'ing java to use the jdk? I haven't tested yet but figure that would give you the default 'command line' jvm which would be the jdk one if I understand correctly what I've seen. Currently I had a (non-embedded) application dependency for tools.jar. So I did a /usr/libexec/java_home runtime exec to locate the jdk and the jar. But the application actually has other jdk dependencies. Are there actually different jdk distribution restrictions to be concerned with so that there is this much separation between the two? Or why do we seem to be ending up with the rather arbitrary rule that you can't have non-embedded jdk based applications? Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From paul_t100 at fastmail.fm Fri Aug 24 04:29:21 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 24 Aug 2012 12:29:21 +0100 Subject: JFileChooser not seeing network mounted files on 1.7.0_06 on Mac In-Reply-To: <50375F2A.1080304@fastmail.fm> References: <502CB1ED.9070507@fastmail.fm> <502CEB07.40708@oracle.com> <503754BE.9000009@fastmail.fm> <50375C84.8030009@oracle.com> <50375F2A.1080304@fastmail.fm> Message-ID: <50376591.5040109@fastmail.fm> On 24/08/2012 12:02, Paul Taylor wrote: > On 24/08/2012 11:50, Anthony Petrov wrote: >> On 8/24/2012 2:17 PM, Paul Taylor wrote: >>> On 16/08/2012 13:43, Anthony Petrov wrote: >>>> I don't recall such an issue. BTW, is the NAS accessible via >>>> java.io.File API? >>>> >>>> In any case, please file a bug report at http://bugs.sun.com/ >>>> >>> Actually I may get getting confused here they are they if I select >>> Harddrive from the top option and then /Volumes folder. But is much >>> harder to find this folder then from native applications, i.e if i >>> start iTunes and select File/Add to Library... I get a dialog that >>> contains a Favourites coliumn and looks very much like a Finder >>> Window. In another project i used Quaqua File Chooser and that >>> wasn't far off the iTUnes dialog but don't know if supported on Java >>> 7. But then I relunctanctly tried using a java.awt.FileDialog >>> instead of a JFileChooser and they look pretty much the same, i.e >>> nothing like an iTunes dialog , I though the FIleDIalog would have >>> all the functionality of a native file dialog ? >> >> Well, j.a.FileDialog *is* a native file chooser dialog after all. >> Maybe it's just missing a couple additional calls/styles that would >> enable more native features. >> > No, because I'm really not clear if I'm doing something wrong here, > and surely having a file dialog that has the functionality of the > dialogs used by another applications is a long standing existing issue. > > The other thing Im confused about (in a good way) is that both > FileDialog and JFileCHooser do seem to correct icons, i,e the > applications folder contains a little blue A on the folder, whereas > this post > http://nadeausoftware.com/node/89#UsingtheJFileChoosertogetMacfileandfoldericons > indicated JFileChooser does not. > > Paul > Sorry I did have something wrong, a messup in my source control, so my latets code wasn't being run. Now when using FIleDIalog it does display a native dialog , but I want to be able to select folders not files, but it is not letting me, Ive tried using System.setProperty("apple.awt.fileDialogForDirectories", "true"); but seems to have no effect, is this option still supported ? Paul From david.holmes at oracle.com Fri Aug 24 04:32:14 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Aug 2012 21:32:14 +1000 Subject: Linker report unsupported file format for OpenJDK 8 and derivated In-Reply-To: References: <5036D2FD.2060107@oracle.com> <5036D6DA.5030501@oracle.com> <5036E2AF.2030207@oracle.com> <5036F501.7050405@oracle.com> <5036F801.6090802@oracle.com> <5036FA34.7020506@oracle.com> Message-ID: <5037663E.6080505@oracle.com> On 24/08/2012 7:07 PM, Henri Gomez wrote: >> Yes I fixed it :) I threw it in there because it was an issue you would have >> been familiar with. (sparcv9 already special-cased it). The general problem >> hasn't been fixed because the new build already handles it. > > For OSX, I'm still using the old one for OpenJDK7 and various OpenJDK8 > (lambda, jigsaw). > > Do you means that we should all switch to new build system since old > build may be partially buggy ? > >> Anyway, there are problems with the Linux build that have been inherited by >> the OSX build due to their sharing of files/settings. > > New or old builds for Linux/OSX ? The legacy build does not support building 32-bit on a 64-bit host on Linux. As OSX was primarily copied from linux I believe it will have the same problems. The new build does support building 32-bit on 64-bit (--with-data-model=32 if I recall correctly). I assume this works for OSX but I have never done such a build. David From anthony.petrov at oracle.com Fri Aug 24 04:32:46 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 24 Aug 2012 15:32:46 +0400 Subject: JFileChooser not seeing network mounted files on 1.7.0_06 on Mac In-Reply-To: <50376591.5040109@fastmail.fm> References: <502CB1ED.9070507@fastmail.fm> <502CEB07.40708@oracle.com> <503754BE.9000009@fastmail.fm> <50375C84.8030009@oracle.com> <50375F2A.1080304@fastmail.fm> <50376591.5040109@fastmail.fm> Message-ID: <5037665E.4090309@oracle.com> On 8/24/2012 3:29 PM, Paul Taylor wrote: >>> Well, j.a.FileDialog *is* a native file chooser dialog after all. >>> Maybe it's just missing a couple additional calls/styles that would >>> enable more native features. >>> >> No, because I'm really not clear if I'm doing something wrong here, >> and surely having a file dialog that has the functionality of the >> dialogs used by another applications is a long standing existing issue. >> >> The other thing Im confused about (in a good way) is that both >> FileDialog and JFileCHooser do seem to correct icons, i,e the >> applications folder contains a little blue A on the folder, whereas >> this post >> http://nadeausoftware.com/node/89#UsingtheJFileChoosertogetMacfileandfoldericons >> indicated JFileChooser does not. >> >> Paul >> > Sorry I did have something wrong, a messup in my source control, so my > latets code wasn't being run. > Now when using FIleDIalog it does display a native dialog , but I want > to be able to select folders not files, but it is not letting me, Ive > tried using > > System.setProperty("apple.awt.fileDialogForDirectories", "true"); > > but seems to have no effect, is this option still supported ? This is fixed for 7u8 under CR 7161437. -- best regards, Anthony From paul_t100 at fastmail.fm Fri Aug 24 04:47:50 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 24 Aug 2012 12:47:50 +0100 Subject: JFileChooser not seeing network mounted files on 1.7.0_06 on Mac In-Reply-To: <5037665E.4090309@oracle.com> References: <502CB1ED.9070507@fastmail.fm> <502CEB07.40708@oracle.com> <503754BE.9000009@fastmail.fm> <50375C84.8030009@oracle.com> <50375F2A.1080304@fastmail.fm> <50376591.5040109@fastmail.fm> <5037665E.4090309@oracle.com> Message-ID: <503769E6.2020200@fastmail.fm> On 24/08/2012 12:32, Anthony Petrov wrote: > On 8/24/2012 3:29 PM, Paul Taylor wrote: >>>> Well, j.a.FileDialog *is* a native file chooser dialog after all. >>>> Maybe it's just missing a couple additional calls/styles that would >>>> enable more native features. >>>> >>> No, because I'm really not clear if I'm doing something wrong here, >>> and surely having a file dialog that has the functionality of the >>> dialogs used by another applications is a long standing existing issue. >>> >>> The other thing Im confused about (in a good way) is that both >>> FileDialog and JFileCHooser do seem to correct icons, i,e the >>> applications folder contains a little blue A on the folder, whereas >>> this post >>> http://nadeausoftware.com/node/89#UsingtheJFileChoosertogetMacfileandfoldericons >>> indicated JFileChooser does not. >>> >>> Paul >>> >> Sorry I did have something wrong, a messup in my source control, so >> my latets code wasn't being run. >> Now when using FIleDIalog it does display a native dialog , but I >> want to be able to select folders not files, but it is not letting >> me, Ive tried using >> >> System.setProperty("apple.awt.fileDialogForDirectories", "true"); >> >> but seems to have no effect, is this option still supported ? > > This is fixed for 7u8 under CR 7161437. > > -- > best regards, > Anthony > Thats good news , but I am in fact using 1.7.0_08-ea, is there later version of 7u8 or am I using the fix wrong Im doing System.setProperty("apple.awt.fileDialogForDirectories", "true"); FileDialog chooser = new FileDialog(MainWindow.frame); chooser.setMode(FileDialog.LOAD); chooser.setVisible(true); String folderSelected = chooser.getDirectory(); System.setProperty("apple.awt.fileDialogForDirectories", "false"); File folder = new File(folderSelected) ; if(folder.exists() && folder.isDirectory()) { //DO something } Paul From anthony.petrov at oracle.com Fri Aug 24 04:52:00 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 24 Aug 2012 15:52:00 +0400 Subject: JFileChooser not seeing network mounted files on 1.7.0_06 on Mac In-Reply-To: <503769E6.2020200@fastmail.fm> References: <502CB1ED.9070507@fastmail.fm> <502CEB07.40708@oracle.com> <503754BE.9000009@fastmail.fm> <50375C84.8030009@oracle.com> <50375F2A.1080304@fastmail.fm> <50376591.5040109@fastmail.fm> <5037665E.4090309@oracle.com> <503769E6.2020200@fastmail.fm> Message-ID: <50376AE0.9080102@oracle.com> On 8/24/2012 3:47 PM, Paul Taylor wrote: >>> System.setProperty("apple.awt.fileDialogForDirectories", "true"); >>> >>> but seems to have no effect, is this option still supported ? >> >> This is fixed for 7u8 under CR 7161437. >> > Thats good news , but I am in fact using 1.7.0_08-ea, is there later > version of 7u8 or am I using the fix wrong Im doing > > System.setProperty("apple.awt.fileDialogForDirectories", "true"); > FileDialog chooser = new FileDialog(MainWindow.frame); > chooser.setMode(FileDialog.LOAD); > chooser.setVisible(true); > String folderSelected = chooser.getDirectory(); > System.setProperty("apple.awt.fileDialogForDirectories", "false"); > File folder = new File(folderSelected) ; > if(folder.exists() && folder.isDirectory()) > { > //DO something > } > The fix hasn't made it to the master repository yet. It is expected to appear in either 7u8b03 or 7u8b04. Maybe, in the worst case, in b05. Please check what build you're using with `java -version` and stay tuned. -- best regards, Anthony From henri.gomez at gmail.com Fri Aug 24 04:55:44 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 24 Aug 2012 13:55:44 +0200 Subject: Linker report unsupported file format for OpenJDK 8 and derivated In-Reply-To: <5037663E.6080505@oracle.com> References: <5036D2FD.2060107@oracle.com> <5036D6DA.5030501@oracle.com> <5036E2AF.2030207@oracle.com> <5036F501.7050405@oracle.com> <5036F801.6090802@oracle.com> <5036FA34.7020506@oracle.com> <5037663E.6080505@oracle.com> Message-ID: > The legacy build does not support building 32-bit on a 64-bit host on Linux. > As OSX was primarily copied from linux I believe it will have the same > problems. > > The new build does support building 32-bit on 64-bit (--with-data-model=32 > if I recall correctly). New Build Infra ? Now its --with-target-bits=32 (even if documentation refer to --with-host-bits) >I assume this works for OSX but I have never done > such a build. Just discussed about in on related ml and there is also some problems, like lack of jigsaw support and unstable state for OSX. So for now, I'll stick with old (current) build system. From paul_t100 at fastmail.fm Fri Aug 24 05:50:55 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 24 Aug 2012 13:50:55 +0100 Subject: Does apple.awt.brushMetalLook have any effect with Java 7 Message-ID: <503778AF.3010308@fastmail.fm> Does apple.awt.brushMetalLook have any effect with Java 7 , it doesnt seem to. Im trying to get a brushed metal look for the top part of my application where i put my toolbar on Paul From marco.dinacci at gmail.com Fri Aug 24 06:10:38 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 24 Aug 2012 14:10:38 +0100 Subject: Does apple.awt.brushMetalLook have any effect with Java 7 In-Reply-To: <503778AF.3010308@fastmail.fm> References: <503778AF.3010308@fastmail.fm> Message-ID: Hi Paul, > Does apple.awt.brushMetalLook have any effect with Java 7 , it doesnt seem > to. IIRC a fix has been committed in the repo last month. I use it so I'm sure it works. Probably the fix is not included in the jvm you're using. Best, Marco From paul_t100 at fastmail.fm Fri Aug 24 06:15:26 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 24 Aug 2012 14:15:26 +0100 Subject: Does apple.awt.brushMetalLook have any effect with Java 7 In-Reply-To: References: <503778AF.3010308@fastmail.fm> Message-ID: <50377E6E.6010105@fastmail.fm> On 24/08/2012 14:10, Marco Dinacci wrote: > Hi Paul, > >> Does apple.awt.brushMetalLook have any effect with Java 7 , it doesnt seem >> to. > IIRC a fix has been committed in the repo last month. I use it so I'm > sure it works. > Probably the fix is not included in the jvm you're using. > > > Best, > Marco > Could you check your java version, give me code sample of how you make use o it please Paul From marco.dinacci at gmail.com Fri Aug 24 06:25:02 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 24 Aug 2012 14:25:02 +0100 Subject: Does apple.awt.brushMetalLook have any effect with Java 7 In-Reply-To: <50377E6E.6010105@fastmail.fm> References: <503778AF.3010308@fastmail.fm> <50377E6E.6010105@fastmail.fm> Message-ID: Hi, > Could you check your java version, give me code sample of how you make use o > it please I compile my own jvm from the latest source code. For an example, just use the ToolbarDemo http://docs.oracle.com/javase/tutorial/uiswing/examples/components/ToolBarDemoProject/src/components/ToolBarDemo.java and add: frame.getRootPane().putClientProperty("apple.awt.brushMetalLook", true); before displaying the window. Best, Marco From paul_t100 at fastmail.fm Fri Aug 24 06:34:40 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 24 Aug 2012 14:34:40 +0100 Subject: Does apple.awt.brushMetalLook have any effect with Java 7 In-Reply-To: References: <503778AF.3010308@fastmail.fm> <50377E6E.6010105@fastmail.fm> Message-ID: <503782F0.5090800@fastmail.fm> On 24/08/2012 14:25, Marco Dinacci wrote: > Hi, > >> Could you check your java version, give me code sample of how you make use o >> it please > I compile my own jvm from the latest source code. > > For an example, just use the ToolbarDemo > http://docs.oracle.com/javase/tutorial/uiswing/examples/components/ToolBarDemoProject/src/components/ToolBarDemo.java > > and add: > > frame.getRootPane().putClientProperty("apple.awt.brushMetalLook", true); > Ah, thats works pefectly I was just setting the System property before. Sorry, Ive fiddled about with mac look and feel over the years and used various additional libs such as Quaqua and ExplodingPixels, sometimes hard to keep track of what is in the core and what is not. Paul From paul_t100 at fastmail.fm Fri Aug 24 06:43:46 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 24 Aug 2012 14:43:46 +0100 Subject: On Java 7 when using brushed metal look is there a way to make all the root pane exhibiting the brushed metal effect to be draggable rather than just the title bar ? Message-ID: <50378512.7050100@fastmail.fm> On Java 7 when using brushed metal look is there a way to make all the root pane exhibiting the brushed metal effect to be draggable rather than just the title bar ? Paul From paul_t100 at fastmail.fm Fri Aug 24 06:46:32 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 24 Aug 2012 14:46:32 +0100 Subject: Improve display of toolbar icons on OSX Message-ID: <503785B8.5090107@fastmail.fm> How can make toolbar buttons (based on png images) blend into the toolbar rather than have the ugly square border around them Paul From alexandr.scherbatiy at oracle.com Fri Aug 24 06:53:39 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 24 Aug 2012 17:53:39 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <50362734.5060600@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> Message-ID: <50378763.60508@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ The comments are below: On 8/23/2012 4:51 PM, Anthony Petrov wrote: > Hi Alexandr, > > 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate > through app's windows only once and send both Exited and Entered > events where needed? Now, when we do not care about the order of the mouse enter/exit events generation it is possible to do. I have updated the code. > > 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no > longer requires a window pointer as an argument. Fixed. > > 3. Here's a major concern: the LWWindowPeer (and other LW* classes) > should never import C* classes. Instead you should've added a new > method to the PlatformWindow interface, and used it from LWWindowPeer. > The CPlatformWindow should've implemented this method, and called an > appropriate native method from there. In this case, however, you > actually need a static method, so it'd better be part of the LWToolkit > interface, and implemented in the LWCToolkit class instead. I see. It seems that the getTopmostWindowUnderMouse method implementation is different for the CPlatformWindow and for the CPlatformEmbeddedFrame. So I added the getTopmostPlatformWindowUnderMouse method to the PlatformWindow interface. Thanks, Alexandr. > > -- > best regards, > Anthony > > On 08/23/12 15:40, Alexander Scherbatiy wrote: >> >> Could someone review the fix? >> >> Thanks, >> Alexandr. >> >> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>> >>> The comments are below: >>> >>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>> simple 32 bit int is probably not what you intended to do. >>> fixed. >>>> Also, have you considered simply calling -[NSWindow >>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then >>>> removing the calls that flip it on and off in -[AWTView >>>> mouseEntered:] and -[AWTView mouseExited"]? This would also require a >>>> change in >>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>> which has a comment that states it only turns on mouse moved events >>>> if the window is currently under the mouse. >>> I tried it. The result that I got is that a dragging mouse from one >>> window to another does not generate mouse enter/exit events on the >>> second window in case when tracking rect is used and the >>> acceptsMouseMovedEvents flag is always set to YES. >>> >>>> I would think that AppKit should be more than happy to send you >>>> mouse-over/enter/exited events as long as you say you want them. Was >>>> this approach tried and didn't work for some reason? >>>>> Hi, Alexander. >>>>> Probably all this stuff can be simplified? Can you try to change >>>>> TrackingRect to TrackingArea with appropriate flags like >>>>> NSTrackingEnabledDuringMouseDrag etc. >>> I changed the TrackingRect to TrackingArea in the updated fix. It now >>> generates the mouse enter/exit events on the second window during drag. >>> So it is not necessary to generates such events from our side. >>> >>> The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit >>> events for component in case when a mouse is dragged from one window >>> to another. >>> Where the second window contains it's own components and the only way >>> to know about tracking over them are drag events which receives the >>> first window. >>> >>> I think that the LWWindowPeer class code can be simplified if we >>> assume that window mouse enter/exit events are always come to the >>> current window. >>> So the component mouse enter/exit events can be tracked only in the >>> current or topmost window. >>> For this case I separated the global lastCommonMouseEventPeer which is >>> necessary for the cursor manager and the local lastMouseEventPeer. >>> >>> According to the specification: The proper order of mouse-entered and >>> mouse-exited events received by tracking-area objects in an >>> application cannot be guaranteed. >>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>> >>> >>> So it seems it is not possible to have one lastMouseEventPeer instead >>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>> >>> And there are possible situations that we can receive mouse drag event >>> between enter and exit. >>> To handle this the isMouseOver flag is added to the LWWindowPeer >>> class. So the component mouse enter/exit events are not generated if >>> the window mouse exited event is received and window mouse entered is >>> not. >>> >>> There is the test: >>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>> It shows that even using the TrackingArea some mouse enter/exit events >>> are not generateed in the following cases: >>> - window is created under the mouse >>> - window changes it's bounds so it becomes under the mouse >>> >>> For this cases it still necessary to generate mouse enter/exit events >>> from our side. >>> I just moved the related code to one method >>> synthesizeMouseEnteredExitedEventsForAllWindows. >>> >>> Thanks, >>> Alexandr. >>> >>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>> >>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>> twice, the toolbar can be dragged to the left side. >>>>>> >>>>>> In the case where a toolbar is created under a mouse and it is >>>>>> dragged over the initial window the mouse enter/exit events should >>>>>> not be generated for the components which are under the toolbar. >>>>>> >>>>>> The current fix is supposed to solve this regression and also to >>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>> mouse is dragged from one window to another or a new window is >>>>>> created under a mouse (like it is implemented for toolbar). >>>>>> >>>>>> Let's see the following cases >>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>> time when a mouse is dragged from a window and does not generate >>>>>> mouse enter/exit events next times during one drag trace. >>>>>> >>>>>> 2) Mouse is dragged from one window to another. >>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>> the second window. >>>>>> >>>>>> 3) Mouse is dragged from one window to another and released. >>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>> the second window only after releasing the mouse. >>>>>> >>>>>> 4) Clicking on window creates a new window after that the new >>>>>> window is dragged (toolbar dragging). >>>>>> >>>>>> However the Java system generates mouse enter/exit events each time >>>>>> when a mouse is dragged over any window. >>>>>> >>>>>> To fix this the following methods are introduced: >>>>>> - Get topmost window under mouse >>>>>> - Synthesize mouse enter/exit events for all windows >>>>>> >>>>>> >>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>> handled previous and next components and is able to generate mouse >>>>>> enter/exit events for them. >>>>>> However the the AWTView native class contains isMouseOver flag >>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>> of this the fix generates the mouse enter/exit window events on the >>>>>> native side. >>>>>> >>>>>> Generating mouse enter/exit events always should be in order where >>>>>> mouse exit events are generated before the mouse enter events. >>>>>> >>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to >>>>>> generate mouse enter/exit events for all windows during mouse drag >>>>>> or window creation/window bounds changing. >>>>>> However only those windows which isMouseOver flag is differ from >>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>> This method also tries to generate both mouse enter and exit event >>>>>> for the same window but only one of them can be applicable because >>>>>> the isTopMostWindowUnderMouse state is not changed for these calls. >>>>>> >>>>>> So the window enter/exit events now are always generated from the >>>>>> native system and component enter/exit events are generated in the >>>>>> LWWindowPeer class. >>>>>> >>>>>> LWWindowPeer class now uses three links to components: current, >>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>> case when a mouse is dragged from one window to another the current >>>>>> component receives drag events and last and topmostUnderMouse links >>>>>> handle components mouse exit/enter events on the second window. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>> >> From anthony.petrov at oracle.com Fri Aug 24 08:00:22 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 24 Aug 2012 19:00:22 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <50378763.60508@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> Message-ID: <50379706.1000106@oracle.com> Hi Alexandr, src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java > 66 public static native CPlatformWindow nativeGetTopmostPlatformWindowUnderMouse(); This method must probably be private. Still, I don't see why getTopmostPlatformWindowUnderMouse() must return null when it's invoked on an embedded frame, and why the implementation should even be different at all. The mouse is a global system entity. There's either some window under the mouse, or there's not. I would still think of LWToolkit.getPlatformWindowUnderMouse(), and its implementation in LWCToolkit. Also, the logic in LWWindowPeer lines 722-743 seems to be overly complicated (as well as the whole dispatchMouseEvent() method). E.g., if the LWWindowPeer manages an embedded frame, we get topmostWindowPeer == this at line 730, and thus always go through the 'true' branch of if() at line 733, even though actually the mouse pointer can be located over some other window at the moment (e.g. over a popup window opened by an applet). Overall, it's really difficult to understand what is going on there. I've spent half an hour reading the code and am still not sure if I get it right. Why does LWWindowPeer even care about the EXITED/ENTERED events for components? Shouldn't this code belong to LWComponentPeer? Or even the shared code? How do Swing components in regular Swing apps get the ENTERED/EXITED events then? Why can't we use the same approach for LWAWT? -- best regards, Anthony On 8/24/2012 5:53 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ > The comments are below: > > On 8/23/2012 4:51 PM, Anthony Petrov wrote: >> Hi Alexandr, >> >> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate >> through app's windows only once and send both Exited and Entered >> events where needed? > Now, when we do not care about the order of the mouse enter/exit > events generation it is possible to do. I have updated the code. >> >> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >> longer requires a window pointer as an argument. > Fixed. >> >> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >> should never import C* classes. Instead you should've added a new >> method to the PlatformWindow interface, and used it from LWWindowPeer. >> The CPlatformWindow should've implemented this method, and called an >> appropriate native method from there. In this case, however, you >> actually need a static method, so it'd better be part of the LWToolkit >> interface, and implemented in the LWCToolkit class instead. > I see. It seems that the getTopmostWindowUnderMouse method > implementation is different for the CPlatformWindow and for the > CPlatformEmbeddedFrame. > So I added the getTopmostPlatformWindowUnderMouse method to the > PlatformWindow interface. > > Thanks, > Alexandr. > >> >> -- >> best regards, >> Anthony >> >> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>> >>> Could someone review the fix? >>> >>> Thanks, >>> Alexandr. >>> >>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>> >>>> The comments are below: >>>> >>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>> simple 32 bit int is probably not what you intended to do. >>>> fixed. >>>>> Also, have you considered simply calling -[NSWindow >>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then >>>>> removing the calls that flip it on and off in -[AWTView >>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also require a >>>>> change in >>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>> which has a comment that states it only turns on mouse moved events >>>>> if the window is currently under the mouse. >>>> I tried it. The result that I got is that a dragging mouse from one >>>> window to another does not generate mouse enter/exit events on the >>>> second window in case when tracking rect is used and the >>>> acceptsMouseMovedEvents flag is always set to YES. >>>> >>>>> I would think that AppKit should be more than happy to send you >>>>> mouse-over/enter/exited events as long as you say you want them. Was >>>>> this approach tried and didn't work for some reason? >>>>>> Hi, Alexander. >>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>> I changed the TrackingRect to TrackingArea in the updated fix. It now >>>> generates the mouse enter/exit events on the second window during drag. >>>> So it is not necessary to generates such events from our side. >>>> >>>> The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit >>>> events for component in case when a mouse is dragged from one window >>>> to another. >>>> Where the second window contains it's own components and the only way >>>> to know about tracking over them are drag events which receives the >>>> first window. >>>> >>>> I think that the LWWindowPeer class code can be simplified if we >>>> assume that window mouse enter/exit events are always come to the >>>> current window. >>>> So the component mouse enter/exit events can be tracked only in the >>>> current or topmost window. >>>> For this case I separated the global lastCommonMouseEventPeer which is >>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>> >>>> According to the specification: The proper order of mouse-entered and >>>> mouse-exited events received by tracking-area objects in an >>>> application cannot be guaranteed. >>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>> >>>> >>>> So it seems it is not possible to have one lastMouseEventPeer instead >>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>> >>>> And there are possible situations that we can receive mouse drag event >>>> between enter and exit. >>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>> class. So the component mouse enter/exit events are not generated if >>>> the window mouse exited event is received and window mouse entered is >>>> not. >>>> >>>> There is the test: >>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>> It shows that even using the TrackingArea some mouse enter/exit events >>>> are not generateed in the following cases: >>>> - window is created under the mouse >>>> - window changes it's bounds so it becomes under the mouse >>>> >>>> For this cases it still necessary to generate mouse enter/exit events >>>> from our side. >>>> I just moved the related code to one method >>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>> >>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>> >>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>> dragged over the initial window the mouse enter/exit events should >>>>>>> not be generated for the components which are under the toolbar. >>>>>>> >>>>>>> The current fix is supposed to solve this regression and also to >>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>> mouse is dragged from one window to another or a new window is >>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>> >>>>>>> Let's see the following cases >>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>> >>>>>>> 2) Mouse is dragged from one window to another. >>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>> the second window. >>>>>>> >>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>> the second window only after releasing the mouse. >>>>>>> >>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>> window is dragged (toolbar dragging). >>>>>>> >>>>>>> However the Java system generates mouse enter/exit events each time >>>>>>> when a mouse is dragged over any window. >>>>>>> >>>>>>> To fix this the following methods are introduced: >>>>>>> - Get topmost window under mouse >>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>> >>>>>>> >>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>> handled previous and next components and is able to generate mouse >>>>>>> enter/exit events for them. >>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>> of this the fix generates the mouse enter/exit window events on the >>>>>>> native side. >>>>>>> >>>>>>> Generating mouse enter/exit events always should be in order where >>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>> >>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to >>>>>>> generate mouse enter/exit events for all windows during mouse drag >>>>>>> or window creation/window bounds changing. >>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>> This method also tries to generate both mouse enter and exit event >>>>>>> for the same window but only one of them can be applicable because >>>>>>> the isTopMostWindowUnderMouse state is not changed for these calls. >>>>>>> >>>>>>> So the window enter/exit events now are always generated from the >>>>>>> native system and component enter/exit events are generated in the >>>>>>> LWWindowPeer class. >>>>>>> >>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>> case when a mouse is dragged from one window to another the current >>>>>>> component receives drag events and last and topmostUnderMouse links >>>>>>> handle components mouse exit/enter events on the second window. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>> >>> > From Sergey.Bylokhov at oracle.com Fri Aug 24 13:49:24 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 25 Aug 2012 00:49:24 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <50378763.60508@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> Message-ID: <5037E8D4.1000901@oracle.com> Hi Alexander. In the fix NSTrackingArea has NSTrackingCursorUpdate option but i did not see cursorUpdate: method. Probably we can get some useful information from it? 24.08.2012 17:53, Alexander Scherbatiy ?????: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ > The comments are below: > > On 8/23/2012 4:51 PM, Anthony Petrov wrote: >> Hi Alexandr, >> >> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate >> through app's windows only once and send both Exited and Entered >> events where needed? > Now, when we do not care about the order of the mouse enter/exit > events generation it is possible to do. I have updated the code. >> >> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >> longer requires a window pointer as an argument. > Fixed. >> >> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >> should never import C* classes. Instead you should've added a new >> method to the PlatformWindow interface, and used it from >> LWWindowPeer. The CPlatformWindow should've implemented this method, >> and called an appropriate native method from there. In this case, >> however, you actually need a static method, so it'd better be part of >> the LWToolkit interface, and implemented in the LWCToolkit class >> instead. > I see. It seems that the getTopmostWindowUnderMouse method > implementation is different for the CPlatformWindow and for the > CPlatformEmbeddedFrame. > So I added the getTopmostPlatformWindowUnderMouse method to the > PlatformWindow interface. > > Thanks, > Alexandr. > >> >> -- >> best regards, >> Anthony >> >> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>> >>> Could someone review the fix? >>> >>> Thanks, >>> Alexandr. >>> >>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>> >>>> The comments are below: >>>> >>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>> simple 32 bit int is probably not what you intended to do. >>>> fixed. >>>>> Also, have you considered simply calling -[NSWindow >>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then >>>>> removing the calls that flip it on and off in -[AWTView >>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also require a >>>>> change in >>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>> which has a comment that states it only turns on mouse moved events >>>>> if the window is currently under the mouse. >>>> I tried it. The result that I got is that a dragging mouse from one >>>> window to another does not generate mouse enter/exit events on the >>>> second window in case when tracking rect is used and the >>>> acceptsMouseMovedEvents flag is always set to YES. >>>> >>>>> I would think that AppKit should be more than happy to send you >>>>> mouse-over/enter/exited events as long as you say you want them. Was >>>>> this approach tried and didn't work for some reason? >>>>>> Hi, Alexander. >>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>> I changed the TrackingRect to TrackingArea in the updated fix. It now >>>> generates the mouse enter/exit events on the second window during >>>> drag. >>>> So it is not necessary to generates such events from our side. >>>> >>>> The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit >>>> events for component in case when a mouse is dragged from one window >>>> to another. >>>> Where the second window contains it's own components and the only way >>>> to know about tracking over them are drag events which receives the >>>> first window. >>>> >>>> I think that the LWWindowPeer class code can be simplified if we >>>> assume that window mouse enter/exit events are always come to the >>>> current window. >>>> So the component mouse enter/exit events can be tracked only in the >>>> current or topmost window. >>>> For this case I separated the global lastCommonMouseEventPeer which is >>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>> >>>> According to the specification: The proper order of mouse-entered and >>>> mouse-exited events received by tracking-area objects in an >>>> application cannot be guaranteed. >>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>> >>>> >>>> So it seems it is not possible to have one lastMouseEventPeer instead >>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>> >>>> And there are possible situations that we can receive mouse drag event >>>> between enter and exit. >>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>> class. So the component mouse enter/exit events are not generated if >>>> the window mouse exited event is received and window mouse entered is >>>> not. >>>> >>>> There is the test: >>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>> It shows that even using the TrackingArea some mouse enter/exit events >>>> are not generateed in the following cases: >>>> - window is created under the mouse >>>> - window changes it's bounds so it becomes under the mouse >>>> >>>> For this cases it still necessary to generate mouse enter/exit events >>>> from our side. >>>> I just moved the related code to one method >>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>> >>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>> >>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>> dragged over the initial window the mouse enter/exit events should >>>>>>> not be generated for the components which are under the toolbar. >>>>>>> >>>>>>> The current fix is supposed to solve this regression and also to >>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>> mouse is dragged from one window to another or a new window is >>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>> >>>>>>> Let's see the following cases >>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>> >>>>>>> 2) Mouse is dragged from one window to another. >>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>> the second window. >>>>>>> >>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>> the second window only after releasing the mouse. >>>>>>> >>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>> window is dragged (toolbar dragging). >>>>>>> >>>>>>> However the Java system generates mouse enter/exit events each time >>>>>>> when a mouse is dragged over any window. >>>>>>> >>>>>>> To fix this the following methods are introduced: >>>>>>> - Get topmost window under mouse >>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>> >>>>>>> >>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>> handled previous and next components and is able to generate mouse >>>>>>> enter/exit events for them. >>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>> of this the fix generates the mouse enter/exit window events on the >>>>>>> native side. >>>>>>> >>>>>>> Generating mouse enter/exit events always should be in order where >>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>> >>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to >>>>>>> generate mouse enter/exit events for all windows during mouse drag >>>>>>> or window creation/window bounds changing. >>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>> This method also tries to generate both mouse enter and exit event >>>>>>> for the same window but only one of them can be applicable because >>>>>>> the isTopMostWindowUnderMouse state is not changed for these calls. >>>>>>> >>>>>>> So the window enter/exit events now are always generated from the >>>>>>> native system and component enter/exit events are generated in the >>>>>>> LWWindowPeer class. >>>>>>> >>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>> case when a mouse is dragged from one window to another the current >>>>>>> component receives drag events and last and topmostUnderMouse links >>>>>>> handle components mouse exit/enter events on the second window. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>> >>> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Aug 24 14:28:06 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 25 Aug 2012 01:28:06 +0400 Subject: On Java 7 when using brushed metal look is there a way to make all the root pane exhibiting the brushed metal effect to be draggable rather than just the title bar ? In-Reply-To: <50378512.7050100@fastmail.fm> References: <50378512.7050100@fastmail.fm> Message-ID: <5037F1E6.4020105@oracle.com> Hi Paul. Can you try: getRootPane().putClientProperty("apple.awt.draggableWindowBackground", Boolean.TRUE); if it does not work, file the new bug please: http://bugs.sun.com/ 24.08.2012 17:43, Paul Taylor wrote: > On Java 7 when using brushed metal look is there a way to make all the > root pane exhibiting the brushed metal effect to be draggable rather > than just the title bar ? > > Paul -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Aug 24 14:35:56 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 25 Aug 2012 01:35:56 +0400 Subject: Improve display of toolbar icons on OSX In-Reply-To: <503785B8.5090107@fastmail.fm> References: <503785B8.5090107@fastmail.fm> Message-ID: <5037F3BC.8060205@oracle.com> Hi, Paul. Please check your test on jdk7u8b04 http://jdk7.java.net/download.html If it does not work please file the new bug(don't forget to attach your test): http://bugs.sun.com Thanks. 24.08.2012 17:46, Paul Taylor wrote: > How can make toolbar buttons (based on png images) blend into the > toolbar rather than have the ugly square border around them > > Paul -- Best regards, Sergey. From paul_t100 at fastmail.fm Fri Aug 24 14:51:56 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 24 Aug 2012 22:51:56 +0100 Subject: On Java 7 when using brushed metal look is there a way to make all the root pane exhibiting the brushed metal effect to be draggable rather than just the title bar ? In-Reply-To: <5037F1E6.4020105@oracle.com> References: <50378512.7050100@fastmail.fm> <5037F1E6.4020105@oracle.com> Message-ID: <5037F77C.2010702@fastmail.fm> On 24/08/2012 22:28, Sergey Bylokhov wrote: > getRootPane().putClientProperty("apple.awt.draggableWindowBackground", > Boolean.TRUE); It works ! Great, thanks. Paul From paul_t100 at fastmail.fm Fri Aug 24 15:00:15 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 24 Aug 2012 23:00:15 +0100 Subject: Improve display of toolbar icons on OSX In-Reply-To: <5037F3BC.8060205@oracle.com> References: <503785B8.5090107@fastmail.fm> <5037F3BC.8060205@oracle.com> Message-ID: <5037F96F.1030808@fastmail.fm> On 24/08/2012 22:35, Sergey Bylokhov wrote: > Hi, Paul. > Please check your test on jdk7u8b04 http://jdk7.java.net/download.html > If it does not work please file the new bug(don't forget to attach > your test): > http://bugs.sun.com > > Thanks. > > 24.08.2012 17:46, Paul Taylor wrote: >> How can make toolbar buttons (based on png images) blend into the >> toolbar rather than have the ugly square border around them >> >> Paul > > Okay, will do. But is there any special property I should set for toolbar icons i.e putClientProperty("JButton.buttonType", "bevel") or just add them to toolbar vanilla Paul From paul_t100 at fastmail.fm Sat Aug 25 01:58:37 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sat, 25 Aug 2012 09:58:37 +0100 Subject: Improve display of toolbar icons on OSX In-Reply-To: <5037F96F.1030808@fastmail.fm> References: <503785B8.5090107@fastmail.fm> <5037F3BC.8060205@oracle.com> <5037F96F.1030808@fastmail.fm> Message-ID: <503893BD.9040604@fastmail.fm> On 24/08/2012 23:00, Paul Taylor wrote: > On 24/08/2012 22:35, Sergey Bylokhov wrote: >> Hi, Paul. >> Please check your test on jdk7u8b04 http://jdk7.java.net/download.html >> If it does not work please file the new bug(don't forget to attach >> your test): >> http://bugs.sun.com >> >> Thanks. >> >> 24.08.2012 17:46, Paul Taylor wrote: >>> How can make toolbar buttons (based on png images) blend into the >>> toolbar rather than have the ugly square border around them >>> >>> Paul >> >> > Okay, will do. > But is there any special property I should set for toolbar icons i.e > putClientProperty("JButton.buttonType", "bevel") or just add them to > toolbar vanilla > > Paul > > > Cannot see any difference, but to be honest I don't know if there is a bug as such, this is how it is looking http://www.jthink.net/jaikoz/scratch/icons.png but these png icons are transparent so I would hope just to see the image and not the added white background square Im no expert on MacOS Style guidelines but this seems to be how image based icons are displayed. Paul From paul_t100 at fastmail.fm Sat Aug 25 02:00:46 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sat, 25 Aug 2012 10:00:46 +0100 Subject: JFileChooser not seeing network mounted files on 1.7.0_06 on Mac In-Reply-To: <50376AE0.9080102@oracle.com> References: <502CB1ED.9070507@fastmail.fm> <502CEB07.40708@oracle.com> <503754BE.9000009@fastmail.fm> <50375C84.8030009@oracle.com> <50375F2A.1080304@fastmail.fm> <50376591.5040109@fastmail.fm> <5037665E.4090309@oracle.com> <503769E6.2020200@fastmail.fm> <50376AE0.9080102@oracle.com> Message-ID: <5038943E.2010601@fastmail.fm> On 24/08/2012 12:52, Anthony Petrov wrote: > On 8/24/2012 3:47 PM, Paul Taylor wrote: >>>> System.setProperty("apple.awt.fileDialogForDirectories", "true"); >>>> >>>> but seems to have no effect, is this option still supported ? >>> >>> This is fixed for 7u8 under CR 7161437. >>> >> Thats good news , but I am in fact using 1.7.0_08-ea, is there later >> version of 7u8 or am I using the fix wrong Im doing >> >> System.setProperty("apple.awt.fileDialogForDirectories", >> "true"); >> FileDialog chooser = new FileDialog(MainWindow.frame); >> chooser.setMode(FileDialog.LOAD); >> chooser.setVisible(true); >> String folderSelected = chooser.getDirectory(); >> System.setProperty("apple.awt.fileDialogForDirectories", >> "false"); >> File folder = new File(folderSelected) ; >> if(folder.exists() && folder.isDirectory()) >> { >> //DO something >> } >> > > The fix hasn't made it to the master repository yet. It is expected to > appear in either 7u8b03 or 7u8b04. Maybe, in the worst case, in b05. > Please check what build you're using with `java -version` and stay tuned. > > -- > best regards, > Anthony > Didn't make it to b04 it seems :( Paul From alexandr.scherbatiy at oracle.com Mon Aug 27 04:29:36 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 27 Aug 2012 15:29:36 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <5037E8D4.1000901@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> <5037E8D4.1000901@oracle.com> Message-ID: <503B5A20.9010604@oracle.com> On 8/25/2012 12:49 AM, Sergey Bylokhov wrote: > Hi Alexander. > In the fix NSTrackingArea has NSTrackingCursorUpdate option but i did > not see cursorUpdate: method. Probably we can get some useful > information from it? Now all necessary information about the cursor updating is tracked in the resetCursorRects method according to the "Mouse-Tracking and Cursor-Update Events" doc: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/MouseTrackingEvents/MouseTrackingEvents.html I tried to add the cursorUpdate method and in the case when a Frame is pro-grammatically moved out of the mouse cursor this method is not invoked (probably as expected). It means that the cursorUpdate method can't be used for the mouse exit event generation in this case. Such behavior is checked by the test: test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java Thanks, Alexandr. > > 24.08.2012 17:53, Alexander Scherbatiy ?????: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ >> The comments are below: >> >> On 8/23/2012 4:51 PM, Anthony Petrov wrote: >>> Hi Alexandr, >>> >>> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we >>> iterate through app's windows only once and send both Exited and >>> Entered events where needed? >> Now, when we do not care about the order of the mouse enter/exit >> events generation it is possible to do. I have updated the code. >>> >>> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >>> longer requires a window pointer as an argument. >> Fixed. >>> >>> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >>> should never import C* classes. Instead you should've added a new >>> method to the PlatformWindow interface, and used it from >>> LWWindowPeer. The CPlatformWindow should've implemented this method, >>> and called an appropriate native method from there. In this case, >>> however, you actually need a static method, so it'd better be part >>> of the LWToolkit interface, and implemented in the LWCToolkit class >>> instead. >> I see. It seems that the getTopmostWindowUnderMouse method >> implementation is different for the CPlatformWindow and for the >> CPlatformEmbeddedFrame. >> So I added the getTopmostPlatformWindowUnderMouse method to the >> PlatformWindow interface. >> >> Thanks, >> Alexandr. >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>>> >>>> Could someone review the fix? >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>>> >>>>> The comments are below: >>>>> >>>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>>> simple 32 bit int is probably not what you intended to do. >>>>> fixed. >>>>>> Also, have you considered simply calling -[NSWindow >>>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and >>>>>> then >>>>>> removing the calls that flip it on and off in -[AWTView >>>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also >>>>>> require a >>>>>> change in >>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>>> which has a comment that states it only turns on mouse moved events >>>>>> if the window is currently under the mouse. >>>>> I tried it. The result that I got is that a dragging mouse from one >>>>> window to another does not generate mouse enter/exit events on the >>>>> second window in case when tracking rect is used and the >>>>> acceptsMouseMovedEvents flag is always set to YES. >>>>> >>>>>> I would think that AppKit should be more than happy to send you >>>>>> mouse-over/enter/exited events as long as you say you want them. Was >>>>>> this approach tried and didn't work for some reason? >>>>>>> Hi, Alexander. >>>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>>> I changed the TrackingRect to TrackingArea in the updated fix. It now >>>>> generates the mouse enter/exit events on the second window during >>>>> drag. >>>>> So it is not necessary to generates such events from our side. >>>>> >>>>> The getTopmostWindowUnderMouse is necessary to handle mouse >>>>> enter/exit >>>>> events for component in case when a mouse is dragged from one window >>>>> to another. >>>>> Where the second window contains it's own components and the only way >>>>> to know about tracking over them are drag events which receives the >>>>> first window. >>>>> >>>>> I think that the LWWindowPeer class code can be simplified if we >>>>> assume that window mouse enter/exit events are always come to the >>>>> current window. >>>>> So the component mouse enter/exit events can be tracked only in the >>>>> current or topmost window. >>>>> For this case I separated the global lastCommonMouseEventPeer >>>>> which is >>>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>>> >>>>> According to the specification: The proper order of mouse-entered and >>>>> mouse-exited events received by tracking-area objects in an >>>>> application cannot be guaranteed. >>>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>>> >>>>> >>>>> So it seems it is not possible to have one lastMouseEventPeer instead >>>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>>> >>>>> And there are possible situations that we can receive mouse drag >>>>> event >>>>> between enter and exit. >>>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>>> class. So the component mouse enter/exit events are not generated if >>>>> the window mouse exited event is received and window mouse entered is >>>>> not. >>>>> >>>>> There is the test: >>>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>>> It shows that even using the TrackingArea some mouse enter/exit >>>>> events >>>>> are not generateed in the following cases: >>>>> - window is created under the mouse >>>>> - window changes it's bounds so it becomes under the mouse >>>>> >>>>> For this cases it still necessary to generate mouse enter/exit events >>>>> from our side. >>>>> I just moved the related code to one method >>>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>>> >>>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>>> >>>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>>> dragged over the initial window the mouse enter/exit events should >>>>>>>> not be generated for the components which are under the toolbar. >>>>>>>> >>>>>>>> The current fix is supposed to solve this regression and also to >>>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>>> mouse is dragged from one window to another or a new window is >>>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>>> >>>>>>>> Let's see the following cases >>>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>>> >>>>>>>> 2) Mouse is dragged from one window to another. >>>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>>> the second window. >>>>>>>> >>>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>>> the second window only after releasing the mouse. >>>>>>>> >>>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>>> window is dragged (toolbar dragging). >>>>>>>> >>>>>>>> However the Java system generates mouse enter/exit events each >>>>>>>> time >>>>>>>> when a mouse is dragged over any window. >>>>>>>> >>>>>>>> To fix this the following methods are introduced: >>>>>>>> - Get topmost window under mouse >>>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>>> >>>>>>>> >>>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>>> handled previous and next components and is able to generate mouse >>>>>>>> enter/exit events for them. >>>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>>> of this the fix generates the mouse enter/exit window events on >>>>>>>> the >>>>>>>> native side. >>>>>>>> >>>>>>>> Generating mouse enter/exit events always should be in order where >>>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>>> >>>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method >>>>>>>> tries to >>>>>>>> generate mouse enter/exit events for all windows during mouse drag >>>>>>>> or window creation/window bounds changing. >>>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>>> This method also tries to generate both mouse enter and exit event >>>>>>>> for the same window but only one of them can be applicable because >>>>>>>> the isTopMostWindowUnderMouse state is not changed for these >>>>>>>> calls. >>>>>>>> >>>>>>>> So the window enter/exit events now are always generated from the >>>>>>>> native system and component enter/exit events are generated in the >>>>>>>> LWWindowPeer class. >>>>>>>> >>>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>>> case when a mouse is dragged from one window to another the >>>>>>>> current >>>>>>>> component receives drag events and last and topmostUnderMouse >>>>>>>> links >>>>>>>> handle components mouse exit/enter events on the second window. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>> >>>> >> > > From Sergey.Bylokhov at oracle.com Mon Aug 27 05:43:24 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 27 Aug 2012 16:43:24 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503B5A20.9010604@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> <5037E8D4.1000901@oracle.com> <503B5A20.9010604@oracle.com> Message-ID: <503B6B6C.6050605@oracle.com> Hi, Alexander. So NSTrackingCursorUpdate option is not necessary? 27.08.2012 15:29, Alexander Scherbatiy wrote: > On 8/25/2012 12:49 AM, Sergey Bylokhov wrote: >> Hi Alexander. >> In the fix NSTrackingArea has NSTrackingCursorUpdate option but i did >> not see cursorUpdate: method. Probably we can get some useful >> information from it? > Now all necessary information about the cursor updating is > tracked in the resetCursorRects method according to the > "Mouse-Tracking and Cursor-Update Events" doc: > https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/MouseTrackingEvents/MouseTrackingEvents.html > > I tried to add the cursorUpdate method and in the case when a Frame > is pro-grammatically moved out of the mouse cursor this method is not > invoked (probably as expected). > It means that the cursorUpdate method can't be used for the mouse > exit event generation in this case. > Such behavior is checked by the test: > test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java > > Thanks, > Alexandr. > >> >> 24.08.2012 17:53, Alexander Scherbatiy ?????: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ >>> The comments are below: >>> >>> On 8/23/2012 4:51 PM, Anthony Petrov wrote: >>>> Hi Alexandr, >>>> >>>> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we >>>> iterate through app's windows only once and send both Exited and >>>> Entered events where needed? >>> Now, when we do not care about the order of the mouse enter/exit >>> events generation it is possible to do. I have updated the code. >>>> >>>> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >>>> longer requires a window pointer as an argument. >>> Fixed. >>>> >>>> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >>>> should never import C* classes. Instead you should've added a new >>>> method to the PlatformWindow interface, and used it from >>>> LWWindowPeer. The CPlatformWindow should've implemented this >>>> method, and called an appropriate native method from there. In this >>>> case, however, you actually need a static method, so it'd better be >>>> part of the LWToolkit interface, and implemented in the LWCToolkit >>>> class instead. >>> I see. It seems that the getTopmostWindowUnderMouse method >>> implementation is different for the CPlatformWindow and for the >>> CPlatformEmbeddedFrame. >>> So I added the getTopmostPlatformWindowUnderMouse method to the >>> PlatformWindow interface. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>>>> >>>>> Could someone review the fix? >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>>>> >>>>>> The comments are below: >>>>>> >>>>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>>>> simple 32 bit int is probably not what you intended to do. >>>>>> fixed. >>>>>>> Also, have you considered simply calling -[NSWindow >>>>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and >>>>>>> then >>>>>>> removing the calls that flip it on and off in -[AWTView >>>>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also >>>>>>> require a >>>>>>> change in >>>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>>>> which has a comment that states it only turns on mouse moved events >>>>>>> if the window is currently under the mouse. >>>>>> I tried it. The result that I got is that a dragging mouse from one >>>>>> window to another does not generate mouse enter/exit events on the >>>>>> second window in case when tracking rect is used and the >>>>>> acceptsMouseMovedEvents flag is always set to YES. >>>>>> >>>>>>> I would think that AppKit should be more than happy to send you >>>>>>> mouse-over/enter/exited events as long as you say you want them. >>>>>>> Was >>>>>>> this approach tried and didn't work for some reason? >>>>>>>> Hi, Alexander. >>>>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>>>> I changed the TrackingRect to TrackingArea in the updated fix. It >>>>>> now >>>>>> generates the mouse enter/exit events on the second window during >>>>>> drag. >>>>>> So it is not necessary to generates such events from our side. >>>>>> >>>>>> The getTopmostWindowUnderMouse is necessary to handle mouse >>>>>> enter/exit >>>>>> events for component in case when a mouse is dragged from one window >>>>>> to another. >>>>>> Where the second window contains it's own components and the only >>>>>> way >>>>>> to know about tracking over them are drag events which receives the >>>>>> first window. >>>>>> >>>>>> I think that the LWWindowPeer class code can be simplified if we >>>>>> assume that window mouse enter/exit events are always come to the >>>>>> current window. >>>>>> So the component mouse enter/exit events can be tracked only in the >>>>>> current or topmost window. >>>>>> For this case I separated the global lastCommonMouseEventPeer >>>>>> which is >>>>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>>>> >>>>>> According to the specification: The proper order of mouse-entered >>>>>> and >>>>>> mouse-exited events received by tracking-area objects in an >>>>>> application cannot be guaranteed. >>>>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>>>> >>>>>> >>>>>> So it seems it is not possible to have one lastMouseEventPeer >>>>>> instead >>>>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>>>> >>>>>> And there are possible situations that we can receive mouse drag >>>>>> event >>>>>> between enter and exit. >>>>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>>>> class. So the component mouse enter/exit events are not generated if >>>>>> the window mouse exited event is received and window mouse >>>>>> entered is >>>>>> not. >>>>>> >>>>>> There is the test: >>>>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>>>> It shows that even using the TrackingArea some mouse enter/exit >>>>>> events >>>>>> are not generateed in the following cases: >>>>>> - window is created under the mouse >>>>>> - window changes it's bounds so it becomes under the mouse >>>>>> >>>>>> For this cases it still necessary to generate mouse enter/exit >>>>>> events >>>>>> from our side. >>>>>> I just moved the related code to one method >>>>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>>>> >>>>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>>>> >>>>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>>>> dragged over the initial window the mouse enter/exit events >>>>>>>>> should >>>>>>>>> not be generated for the components which are under the toolbar. >>>>>>>>> >>>>>>>>> The current fix is supposed to solve this regression and also to >>>>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>>>> mouse is dragged from one window to another or a new window is >>>>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>>>> >>>>>>>>> Let's see the following cases >>>>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>>>> >>>>>>>>> 2) Mouse is dragged from one window to another. >>>>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>>>> the second window. >>>>>>>>> >>>>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>>>> the second window only after releasing the mouse. >>>>>>>>> >>>>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>>>> window is dragged (toolbar dragging). >>>>>>>>> >>>>>>>>> However the Java system generates mouse enter/exit events each >>>>>>>>> time >>>>>>>>> when a mouse is dragged over any window. >>>>>>>>> >>>>>>>>> To fix this the following methods are introduced: >>>>>>>>> - Get topmost window under mouse >>>>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>>>> >>>>>>>>> >>>>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>>>> handled previous and next components and is able to generate >>>>>>>>> mouse >>>>>>>>> enter/exit events for them. >>>>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>>>> of this the fix generates the mouse enter/exit window events >>>>>>>>> on the >>>>>>>>> native side. >>>>>>>>> >>>>>>>>> Generating mouse enter/exit events always should be in order >>>>>>>>> where >>>>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>>>> >>>>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method >>>>>>>>> tries to >>>>>>>>> generate mouse enter/exit events for all windows during mouse >>>>>>>>> drag >>>>>>>>> or window creation/window bounds changing. >>>>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>>>> This method also tries to generate both mouse enter and exit >>>>>>>>> event >>>>>>>>> for the same window but only one of them can be applicable >>>>>>>>> because >>>>>>>>> the isTopMostWindowUnderMouse state is not changed for these >>>>>>>>> calls. >>>>>>>>> >>>>>>>>> So the window enter/exit events now are always generated from the >>>>>>>>> native system and component enter/exit events are generated in >>>>>>>>> the >>>>>>>>> LWWindowPeer class. >>>>>>>>> >>>>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>>>> case when a mouse is dragged from one window to another the >>>>>>>>> current >>>>>>>>> component receives drag events and last and topmostUnderMouse >>>>>>>>> links >>>>>>>>> handle components mouse exit/enter events on the second window. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>> >>>>> >>> >> >> > -- Best regards, Sergey. From joe.mcglynn at oracle.com Mon Aug 27 06:02:04 2012 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Mon, 27 Aug 2012 06:02:04 -0700 Subject: jdk based applications In-Reply-To: <2FF97125-C481-48B4-9066-510CB8BAF942@gmail.com> References: <2FF97125-C481-48B4-9066-510CB8BAF942@gmail.com> Message-ID: <8762B678-00F2-4C60-8B72-9EDCB859B655@oracle.com> Of course, the recommended way is to use the "JavaFX Ant Packager" tasks (regardless of whether your app is FX-based or not). http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm#BCGIBBCI We're in the process of making improvements to this tool, so feedback is welcomed. -- On Aug 24, 2012, at 4:09 AM, Michael Hall wrote: > Is the only way to have a normal jdk based desktop application to embed the jdk? > I would assume there wouldn't be anything to prevent an application runtime exec'ing java to use the jdk? I haven't tested yet but figure that would give you the default 'command line' jvm which would be the jdk one if I understand correctly what I've seen. > Currently I had a (non-embedded) application dependency for tools.jar. So I did a /usr/libexec/java_home runtime exec to locate the jdk and the jar. > But the application actually has other jdk dependencies. > Are there actually different jdk distribution restrictions to be concerned with so that there is this much separation between the two? Or why do we seem to be ending up with the rather arbitrary rule that you can't have non-embedded jdk based applications? > > Michael Hall > > trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz > > HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe > > AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter > > > > From alexandr.scherbatiy at oracle.com Tue Aug 28 04:17:43 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 28 Aug 2012 15:17:43 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <50379706.1000106@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> <50379706.1000106@oracle.com> Message-ID: <503CA8D7.90506@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.05/ The comments are below: - NSTrackingCursorUpdate option is removed from the rolloverTrackingArea On 8/24/2012 7:00 PM, Anthony Petrov wrote: > src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java >> 66 public static native CPlatformWindow >> nativeGetTopmostPlatformWindowUnderMouse(); > > This method must probably be private. Fixed. > > Still, I don't see why getTopmostPlatformWindowUnderMouse() must > return null when it's invoked on an embedded frame, and why the > implementation should even be different at all. The mouse is a global > system entity. There's either some window under the mouse, or there's > not. I would still think of LWToolkit.getPlatformWindowUnderMouse(), > and its implementation in LWCToolkit. Dmitry, who is a responsible person for the CPlatformEmbeddedFrame, said that the implementation of the getPlatformWindowUnderMouse() method could be different for applets. So the getPlatformWindowUnderMouse() method implementation will be filled as a separated issue and fixed by Dmitry. > > Also, the logic in LWWindowPeer lines 722-743 seems to be overly > complicated (as well as the whole dispatchMouseEvent() method). E.g., > if the LWWindowPeer manages an embedded frame, we get > topmostWindowPeer == this at line 730, and thus always go through the > 'true' branch of if() at line 733, even though actually the mouse > pointer can be located over some other window at the moment (e.g. over > a popup window opened by an applet). I updated the topmostWindowPeer variable creation so it now can have only the topmost window under mouse value or null and added a comment that the (topmostWindowPeer == null ) condition should be removed after the getPlatformWindowUnderMouse() method implementation in the CPlatformEmbeddedFrame class. For now the (topmostWindowPeer == null ) condition allows to track the mouse enter/exit components events as it was before the fix. > > Overall, it's really difficult to understand what is going on there. > I've spent half an hour reading the code and am still not sure if I > get it right. Why does LWWindowPeer even care about the EXITED/ENTERED > events for components? Shouldn't this code belong to LWComponentPeer? > Or even the shared code? How do Swing components in regular Swing apps > get the ENTERED/EXITED events then? Why can't we use the same approach > for LWAWT? Swing controls have Container in a parent class hierarchy. The Container class has the LightweightDispatcher dispatcher which allows to track mouse moving from one component to another and generate necessary mouse enter/exit events. AWT controls have Component class as a parent and do not have the dispatcher. So moving/dragging a mouse from one AWT control to another does not generate necessary mouse events. The aim of the fix is not redesigning current architecture. It just adds checking a case where a mouse is dragged from one window to another and so the first window which gets the mouse drag events is not the real window for which component enter/exit events should be generated. Thanks, Alexandr. > > -- > best regards, > Anthony > > On 8/24/2012 5:53 PM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ >> The comments are below: >> >> On 8/23/2012 4:51 PM, Anthony Petrov wrote: >>> Hi Alexandr, >>> >>> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we >>> iterate through app's windows only once and send both Exited and >>> Entered events where needed? >> Now, when we do not care about the order of the mouse enter/exit >> events generation it is possible to do. I have updated the code. >>> >>> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >>> longer requires a window pointer as an argument. >> Fixed. >>> >>> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >>> should never import C* classes. Instead you should've added a new >>> method to the PlatformWindow interface, and used it from >>> LWWindowPeer. The CPlatformWindow should've implemented this method, >>> and called an appropriate native method from there. In this case, >>> however, you actually need a static method, so it'd better be part >>> of the LWToolkit interface, and implemented in the LWCToolkit class >>> instead. >> I see. It seems that the getTopmostWindowUnderMouse method >> implementation is different for the CPlatformWindow and for the >> CPlatformEmbeddedFrame. >> So I added the getTopmostPlatformWindowUnderMouse method to the >> PlatformWindow interface. >> >> Thanks, >> Alexandr. >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>>> >>>> Could someone review the fix? >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>>> >>>>> The comments are below: >>>>> >>>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>>> simple 32 bit int is probably not what you intended to do. >>>>> fixed. >>>>>> Also, have you considered simply calling -[NSWindow >>>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and >>>>>> then >>>>>> removing the calls that flip it on and off in -[AWTView >>>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also >>>>>> require a >>>>>> change in >>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>>> which has a comment that states it only turns on mouse moved events >>>>>> if the window is currently under the mouse. >>>>> I tried it. The result that I got is that a dragging mouse from one >>>>> window to another does not generate mouse enter/exit events on the >>>>> second window in case when tracking rect is used and the >>>>> acceptsMouseMovedEvents flag is always set to YES. >>>>> >>>>>> I would think that AppKit should be more than happy to send you >>>>>> mouse-over/enter/exited events as long as you say you want them. Was >>>>>> this approach tried and didn't work for some reason? >>>>>>> Hi, Alexander. >>>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>>> I changed the TrackingRect to TrackingArea in the updated fix. It now >>>>> generates the mouse enter/exit events on the second window during >>>>> drag. >>>>> So it is not necessary to generates such events from our side. >>>>> >>>>> The getTopmostWindowUnderMouse is necessary to handle mouse >>>>> enter/exit >>>>> events for component in case when a mouse is dragged from one window >>>>> to another. >>>>> Where the second window contains it's own components and the only way >>>>> to know about tracking over them are drag events which receives the >>>>> first window. >>>>> >>>>> I think that the LWWindowPeer class code can be simplified if we >>>>> assume that window mouse enter/exit events are always come to the >>>>> current window. >>>>> So the component mouse enter/exit events can be tracked only in the >>>>> current or topmost window. >>>>> For this case I separated the global lastCommonMouseEventPeer >>>>> which is >>>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>>> >>>>> According to the specification: The proper order of mouse-entered and >>>>> mouse-exited events received by tracking-area objects in an >>>>> application cannot be guaranteed. >>>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>>> >>>>> >>>>> So it seems it is not possible to have one lastMouseEventPeer instead >>>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>>> >>>>> And there are possible situations that we can receive mouse drag >>>>> event >>>>> between enter and exit. >>>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>>> class. So the component mouse enter/exit events are not generated if >>>>> the window mouse exited event is received and window mouse entered is >>>>> not. >>>>> >>>>> There is the test: >>>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>>> It shows that even using the TrackingArea some mouse enter/exit >>>>> events >>>>> are not generateed in the following cases: >>>>> - window is created under the mouse >>>>> - window changes it's bounds so it becomes under the mouse >>>>> >>>>> For this cases it still necessary to generate mouse enter/exit events >>>>> from our side. >>>>> I just moved the related code to one method >>>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>>> >>>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>>> >>>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>>> dragged over the initial window the mouse enter/exit events should >>>>>>>> not be generated for the components which are under the toolbar. >>>>>>>> >>>>>>>> The current fix is supposed to solve this regression and also to >>>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>>> mouse is dragged from one window to another or a new window is >>>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>>> >>>>>>>> Let's see the following cases >>>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>>> >>>>>>>> 2) Mouse is dragged from one window to another. >>>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>>> the second window. >>>>>>>> >>>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>>> the second window only after releasing the mouse. >>>>>>>> >>>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>>> window is dragged (toolbar dragging). >>>>>>>> >>>>>>>> However the Java system generates mouse enter/exit events each >>>>>>>> time >>>>>>>> when a mouse is dragged over any window. >>>>>>>> >>>>>>>> To fix this the following methods are introduced: >>>>>>>> - Get topmost window under mouse >>>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>>> >>>>>>>> >>>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>>> handled previous and next components and is able to generate mouse >>>>>>>> enter/exit events for them. >>>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>>> of this the fix generates the mouse enter/exit window events on >>>>>>>> the >>>>>>>> native side. >>>>>>>> >>>>>>>> Generating mouse enter/exit events always should be in order where >>>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>>> >>>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method >>>>>>>> tries to >>>>>>>> generate mouse enter/exit events for all windows during mouse drag >>>>>>>> or window creation/window bounds changing. >>>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>>> This method also tries to generate both mouse enter and exit event >>>>>>>> for the same window but only one of them can be applicable because >>>>>>>> the isTopMostWindowUnderMouse state is not changed for these >>>>>>>> calls. >>>>>>>> >>>>>>>> So the window enter/exit events now are always generated from the >>>>>>>> native system and component enter/exit events are generated in the >>>>>>>> LWWindowPeer class. >>>>>>>> >>>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>>> case when a mouse is dragged from one window to another the >>>>>>>> current >>>>>>>> component receives drag events and last and topmostUnderMouse >>>>>>>> links >>>>>>>> handle components mouse exit/enter events on the second window. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>> >>>> >> From alexandr.scherbatiy at oracle.com Tue Aug 28 05:57:13 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 28 Aug 2012 16:57:13 +0400 Subject: [7u8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. Message-ID: <503CC029.20302@oracle.com> Hello, Please review the fix for the JDK 7u8: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev7.00/ This is a regression after the fix 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In the case where a toolbar is created under a mouse and it is dragged over the initial window the mouse enter/exit events should not be generated for the components which are under the toolbar. The disabling component mouse enter/exit events generation during drag leads that it does not work in the case where a mouse is dragged over the current window. The full fix that checks that a current window is a topmost window under mouse requires some changes (using tracking area instead of tracking rectangle and so on) is a quite complicated and it seems that it is risky to include it to the JDK 7u8. Current fix just changes the condition for the component mouse enter/exit events generation to the initial state how it was before the 7154048 fix. This allows to generate components mouse enter/exit events, but the following test will fail: java/awt/Mouse/EnterExitEvents/DragWindowTest.java However this test did not work before the 7154048 fix so it is not a regression. Thanks, Alexandr. From anthony.petrov at oracle.com Tue Aug 28 06:06:43 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 28 Aug 2012 17:06:43 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503CA8D7.90506@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> <50379706.1000106@oracle.com> <503CA8D7.90506@oracle.com> Message-ID: <503CC263.9020103@oracle.com> Hi Alexander, Thanks for the clarifications. The code now looks clearer. I'm fine with the fix. -- best regards, Anthony On 8/28/2012 3:17 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/7171045/webrev.05/ > The comments are below: > - NSTrackingCursorUpdate option is removed from the rolloverTrackingArea > > On 8/24/2012 7:00 PM, Anthony Petrov wrote: >> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java >>> 66 public static native CPlatformWindow >>> nativeGetTopmostPlatformWindowUnderMouse(); >> >> This method must probably be private. > Fixed. > >> >> Still, I don't see why getTopmostPlatformWindowUnderMouse() must >> return null when it's invoked on an embedded frame, and why the >> implementation should even be different at all. The mouse is a global >> system entity. There's either some window under the mouse, or there's >> not. I would still think of LWToolkit.getPlatformWindowUnderMouse(), >> and its implementation in LWCToolkit. > > Dmitry, who is a responsible person for the CPlatformEmbeddedFrame, > said that the implementation of the getPlatformWindowUnderMouse() method > could be different for applets. > So the getPlatformWindowUnderMouse() method implementation will be > filled as a separated issue and fixed by Dmitry. > >> >> Also, the logic in LWWindowPeer lines 722-743 seems to be overly >> complicated (as well as the whole dispatchMouseEvent() method). E.g., >> if the LWWindowPeer manages an embedded frame, we get >> topmostWindowPeer == this at line 730, and thus always go through the >> 'true' branch of if() at line 733, even though actually the mouse >> pointer can be located over some other window at the moment (e.g. over >> a popup window opened by an applet). > I updated the topmostWindowPeer variable creation so it now can have > only the topmost window under mouse value or null and added a comment > that the (topmostWindowPeer == null ) > condition should be removed after the getPlatformWindowUnderMouse() > method implementation in the CPlatformEmbeddedFrame class. > For now the (topmostWindowPeer == null ) condition allows to track > the mouse enter/exit components events as it was before the fix. >> >> Overall, it's really difficult to understand what is going on there. >> I've spent half an hour reading the code and am still not sure if I >> get it right. Why does LWWindowPeer even care about the EXITED/ENTERED >> events for components? Shouldn't this code belong to LWComponentPeer? >> Or even the shared code? How do Swing components in regular Swing apps >> get the ENTERED/EXITED events then? Why can't we use the same approach >> for LWAWT? > Swing controls have Container in a parent class hierarchy. The > Container class has the LightweightDispatcher dispatcher which allows to > track mouse moving from one component to another and generate necessary > mouse enter/exit events. > AWT controls have Component class as a parent and do not have the > dispatcher. So moving/dragging a mouse from one AWT control to another > does not generate necessary mouse events. > > The aim of the fix is not redesigning current architecture. It just > adds checking a case where a mouse is dragged from one window to another > and so the first window which gets the mouse drag events is not the real > window for which component enter/exit events should be generated. > > Thanks, > Alexandr. > >> >> -- >> best regards, >> Anthony >> >> On 8/24/2012 5:53 PM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ >>> The comments are below: >>> >>> On 8/23/2012 4:51 PM, Anthony Petrov wrote: >>>> Hi Alexandr, >>>> >>>> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we >>>> iterate through app's windows only once and send both Exited and >>>> Entered events where needed? >>> Now, when we do not care about the order of the mouse enter/exit >>> events generation it is possible to do. I have updated the code. >>>> >>>> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >>>> longer requires a window pointer as an argument. >>> Fixed. >>>> >>>> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >>>> should never import C* classes. Instead you should've added a new >>>> method to the PlatformWindow interface, and used it from >>>> LWWindowPeer. The CPlatformWindow should've implemented this method, >>>> and called an appropriate native method from there. In this case, >>>> however, you actually need a static method, so it'd better be part >>>> of the LWToolkit interface, and implemented in the LWCToolkit class >>>> instead. >>> I see. It seems that the getTopmostWindowUnderMouse method >>> implementation is different for the CPlatformWindow and for the >>> CPlatformEmbeddedFrame. >>> So I added the getTopmostPlatformWindowUnderMouse method to the >>> PlatformWindow interface. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>>>> >>>>> Could someone review the fix? >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>>>> >>>>>> The comments are below: >>>>>> >>>>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>>>> simple 32 bit int is probably not what you intended to do. >>>>>> fixed. >>>>>>> Also, have you considered simply calling -[NSWindow >>>>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and >>>>>>> then >>>>>>> removing the calls that flip it on and off in -[AWTView >>>>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also >>>>>>> require a >>>>>>> change in >>>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>>>> which has a comment that states it only turns on mouse moved events >>>>>>> if the window is currently under the mouse. >>>>>> I tried it. The result that I got is that a dragging mouse from one >>>>>> window to another does not generate mouse enter/exit events on the >>>>>> second window in case when tracking rect is used and the >>>>>> acceptsMouseMovedEvents flag is always set to YES. >>>>>> >>>>>>> I would think that AppKit should be more than happy to send you >>>>>>> mouse-over/enter/exited events as long as you say you want them. Was >>>>>>> this approach tried and didn't work for some reason? >>>>>>>> Hi, Alexander. >>>>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>>>> I changed the TrackingRect to TrackingArea in the updated fix. It now >>>>>> generates the mouse enter/exit events on the second window during >>>>>> drag. >>>>>> So it is not necessary to generates such events from our side. >>>>>> >>>>>> The getTopmostWindowUnderMouse is necessary to handle mouse >>>>>> enter/exit >>>>>> events for component in case when a mouse is dragged from one window >>>>>> to another. >>>>>> Where the second window contains it's own components and the only way >>>>>> to know about tracking over them are drag events which receives the >>>>>> first window. >>>>>> >>>>>> I think that the LWWindowPeer class code can be simplified if we >>>>>> assume that window mouse enter/exit events are always come to the >>>>>> current window. >>>>>> So the component mouse enter/exit events can be tracked only in the >>>>>> current or topmost window. >>>>>> For this case I separated the global lastCommonMouseEventPeer >>>>>> which is >>>>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>>>> >>>>>> According to the specification: The proper order of mouse-entered and >>>>>> mouse-exited events received by tracking-area objects in an >>>>>> application cannot be guaranteed. >>>>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>>>> >>>>>> >>>>>> So it seems it is not possible to have one lastMouseEventPeer instead >>>>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>>>> >>>>>> And there are possible situations that we can receive mouse drag >>>>>> event >>>>>> between enter and exit. >>>>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>>>> class. So the component mouse enter/exit events are not generated if >>>>>> the window mouse exited event is received and window mouse entered is >>>>>> not. >>>>>> >>>>>> There is the test: >>>>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>>>> It shows that even using the TrackingArea some mouse enter/exit >>>>>> events >>>>>> are not generateed in the following cases: >>>>>> - window is created under the mouse >>>>>> - window changes it's bounds so it becomes under the mouse >>>>>> >>>>>> For this cases it still necessary to generate mouse enter/exit events >>>>>> from our side. >>>>>> I just moved the related code to one method >>>>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>>>> >>>>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>>>> >>>>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>>>> dragged over the initial window the mouse enter/exit events should >>>>>>>>> not be generated for the components which are under the toolbar. >>>>>>>>> >>>>>>>>> The current fix is supposed to solve this regression and also to >>>>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>>>> mouse is dragged from one window to another or a new window is >>>>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>>>> >>>>>>>>> Let's see the following cases >>>>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>>>> >>>>>>>>> 2) Mouse is dragged from one window to another. >>>>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>>>> the second window. >>>>>>>>> >>>>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>>>> the second window only after releasing the mouse. >>>>>>>>> >>>>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>>>> window is dragged (toolbar dragging). >>>>>>>>> >>>>>>>>> However the Java system generates mouse enter/exit events each >>>>>>>>> time >>>>>>>>> when a mouse is dragged over any window. >>>>>>>>> >>>>>>>>> To fix this the following methods are introduced: >>>>>>>>> - Get topmost window under mouse >>>>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>>>> >>>>>>>>> >>>>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>>>> handled previous and next components and is able to generate mouse >>>>>>>>> enter/exit events for them. >>>>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>>>> of this the fix generates the mouse enter/exit window events on >>>>>>>>> the >>>>>>>>> native side. >>>>>>>>> >>>>>>>>> Generating mouse enter/exit events always should be in order where >>>>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>>>> >>>>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method >>>>>>>>> tries to >>>>>>>>> generate mouse enter/exit events for all windows during mouse drag >>>>>>>>> or window creation/window bounds changing. >>>>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>>>> This method also tries to generate both mouse enter and exit event >>>>>>>>> for the same window but only one of them can be applicable because >>>>>>>>> the isTopMostWindowUnderMouse state is not changed for these >>>>>>>>> calls. >>>>>>>>> >>>>>>>>> So the window enter/exit events now are always generated from the >>>>>>>>> native system and component enter/exit events are generated in the >>>>>>>>> LWWindowPeer class. >>>>>>>>> >>>>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>>>> case when a mouse is dragged from one window to another the >>>>>>>>> current >>>>>>>>> component receives drag events and last and topmostUnderMouse >>>>>>>>> links >>>>>>>>> handle components mouse exit/enter events on the second window. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>> >>>>> >>> > From Sergey.Bylokhov at oracle.com Tue Aug 28 06:57:46 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 28 Aug 2012 17:57:46 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503CA8D7.90506@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> <50379706.1000106@oracle.com> <503CA8D7.90506@oracle.com> Message-ID: <503CCE5A.5080204@oracle.com> Hi Alexander. Fix looks good. 28.08.2012 15:17, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/7171045/webrev.05/ > The comments are below: > - NSTrackingCursorUpdate option is removed from the > rolloverTrackingArea > > On 8/24/2012 7:00 PM, Anthony Petrov wrote: >> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java >>> 66 public static native CPlatformWindow >>> nativeGetTopmostPlatformWindowUnderMouse(); >> >> This method must probably be private. > Fixed. > >> >> Still, I don't see why getTopmostPlatformWindowUnderMouse() must >> return null when it's invoked on an embedded frame, and why the >> implementation should even be different at all. The mouse is a global >> system entity. There's either some window under the mouse, or there's >> not. I would still think of LWToolkit.getPlatformWindowUnderMouse(), >> and its implementation in LWCToolkit. > > Dmitry, who is a responsible person for the > CPlatformEmbeddedFrame, said that the implementation of the > getPlatformWindowUnderMouse() method could be different for applets. > So the getPlatformWindowUnderMouse() method implementation will > be filled as a separated issue and fixed by Dmitry. > >> >> Also, the logic in LWWindowPeer lines 722-743 seems to be overly >> complicated (as well as the whole dispatchMouseEvent() method). E.g., >> if the LWWindowPeer manages an embedded frame, we get >> topmostWindowPeer == this at line 730, and thus always go through the >> 'true' branch of if() at line 733, even though actually the mouse >> pointer can be located over some other window at the moment (e.g. >> over a popup window opened by an applet). > I updated the topmostWindowPeer variable creation so it now can > have only the topmost window under mouse value or null and added a > comment that the (topmostWindowPeer == null ) > condition should be removed after the > getPlatformWindowUnderMouse() method implementation in the > CPlatformEmbeddedFrame class. > For now the (topmostWindowPeer == null ) condition allows to track > the mouse enter/exit components events as it was before the fix. >> >> Overall, it's really difficult to understand what is going on there. >> I've spent half an hour reading the code and am still not sure if I >> get it right. Why does LWWindowPeer even care about the >> EXITED/ENTERED events for components? Shouldn't this code belong to >> LWComponentPeer? Or even the shared code? How do Swing components in >> regular Swing apps get the ENTERED/EXITED events then? Why can't we >> use the same approach for LWAWT? > Swing controls have Container in a parent class hierarchy. The > Container class has the LightweightDispatcher dispatcher which allows > to track mouse moving from one component to another and generate > necessary mouse enter/exit events. > AWT controls have Component class as a parent and do not have the > dispatcher. So moving/dragging a mouse from one AWT control to another > does not generate necessary mouse events. > > The aim of the fix is not redesigning current architecture. It just > adds checking a case where a mouse is dragged from one window to > another and so the first window which gets the mouse drag events is > not the real window for which component enter/exit events should be > generated. > > Thanks, > Alexandr. > >> >> -- >> best regards, >> Anthony >> >> On 8/24/2012 5:53 PM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ >>> The comments are below: >>> >>> On 8/23/2012 4:51 PM, Anthony Petrov wrote: >>>> Hi Alexandr, >>>> >>>> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we >>>> iterate through app's windows only once and send both Exited and >>>> Entered events where needed? >>> Now, when we do not care about the order of the mouse enter/exit >>> events generation it is possible to do. I have updated the code. >>>> >>>> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >>>> longer requires a window pointer as an argument. >>> Fixed. >>>> >>>> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >>>> should never import C* classes. Instead you should've added a new >>>> method to the PlatformWindow interface, and used it from >>>> LWWindowPeer. The CPlatformWindow should've implemented this >>>> method, and called an appropriate native method from there. In this >>>> case, however, you actually need a static method, so it'd better be >>>> part of the LWToolkit interface, and implemented in the LWCToolkit >>>> class instead. >>> I see. It seems that the getTopmostWindowUnderMouse method >>> implementation is different for the CPlatformWindow and for the >>> CPlatformEmbeddedFrame. >>> So I added the getTopmostPlatformWindowUnderMouse method to the >>> PlatformWindow interface. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>>>> >>>>> Could someone review the fix? >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>>>> >>>>>> The comments are below: >>>>>> >>>>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>>>> simple 32 bit int is probably not what you intended to do. >>>>>> fixed. >>>>>>> Also, have you considered simply calling -[NSWindow >>>>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and >>>>>>> then >>>>>>> removing the calls that flip it on and off in -[AWTView >>>>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also >>>>>>> require a >>>>>>> change in >>>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>>>> which has a comment that states it only turns on mouse moved events >>>>>>> if the window is currently under the mouse. >>>>>> I tried it. The result that I got is that a dragging mouse from one >>>>>> window to another does not generate mouse enter/exit events on the >>>>>> second window in case when tracking rect is used and the >>>>>> acceptsMouseMovedEvents flag is always set to YES. >>>>>> >>>>>>> I would think that AppKit should be more than happy to send you >>>>>>> mouse-over/enter/exited events as long as you say you want them. >>>>>>> Was >>>>>>> this approach tried and didn't work for some reason? >>>>>>>> Hi, Alexander. >>>>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>>>> I changed the TrackingRect to TrackingArea in the updated fix. It >>>>>> now >>>>>> generates the mouse enter/exit events on the second window during >>>>>> drag. >>>>>> So it is not necessary to generates such events from our side. >>>>>> >>>>>> The getTopmostWindowUnderMouse is necessary to handle mouse >>>>>> enter/exit >>>>>> events for component in case when a mouse is dragged from one window >>>>>> to another. >>>>>> Where the second window contains it's own components and the only >>>>>> way >>>>>> to know about tracking over them are drag events which receives the >>>>>> first window. >>>>>> >>>>>> I think that the LWWindowPeer class code can be simplified if we >>>>>> assume that window mouse enter/exit events are always come to the >>>>>> current window. >>>>>> So the component mouse enter/exit events can be tracked only in the >>>>>> current or topmost window. >>>>>> For this case I separated the global lastCommonMouseEventPeer >>>>>> which is >>>>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>>>> >>>>>> According to the specification: The proper order of mouse-entered >>>>>> and >>>>>> mouse-exited events received by tracking-area objects in an >>>>>> application cannot be guaranteed. >>>>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>>>> >>>>>> >>>>>> So it seems it is not possible to have one lastMouseEventPeer >>>>>> instead >>>>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>>>> >>>>>> And there are possible situations that we can receive mouse drag >>>>>> event >>>>>> between enter and exit. >>>>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>>>> class. So the component mouse enter/exit events are not generated if >>>>>> the window mouse exited event is received and window mouse >>>>>> entered is >>>>>> not. >>>>>> >>>>>> There is the test: >>>>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>>>> It shows that even using the TrackingArea some mouse enter/exit >>>>>> events >>>>>> are not generateed in the following cases: >>>>>> - window is created under the mouse >>>>>> - window changes it's bounds so it becomes under the mouse >>>>>> >>>>>> For this cases it still necessary to generate mouse enter/exit >>>>>> events >>>>>> from our side. >>>>>> I just moved the related code to one method >>>>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>>>> >>>>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>>>> >>>>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>>>> dragged over the initial window the mouse enter/exit events >>>>>>>>> should >>>>>>>>> not be generated for the components which are under the toolbar. >>>>>>>>> >>>>>>>>> The current fix is supposed to solve this regression and also to >>>>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>>>> mouse is dragged from one window to another or a new window is >>>>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>>>> >>>>>>>>> Let's see the following cases >>>>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>>>> >>>>>>>>> 2) Mouse is dragged from one window to another. >>>>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>>>> the second window. >>>>>>>>> >>>>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>>>> the second window only after releasing the mouse. >>>>>>>>> >>>>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>>>> window is dragged (toolbar dragging). >>>>>>>>> >>>>>>>>> However the Java system generates mouse enter/exit events each >>>>>>>>> time >>>>>>>>> when a mouse is dragged over any window. >>>>>>>>> >>>>>>>>> To fix this the following methods are introduced: >>>>>>>>> - Get topmost window under mouse >>>>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>>>> >>>>>>>>> >>>>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>>>> handled previous and next components and is able to generate >>>>>>>>> mouse >>>>>>>>> enter/exit events for them. >>>>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>>>> of this the fix generates the mouse enter/exit window events >>>>>>>>> on the >>>>>>>>> native side. >>>>>>>>> >>>>>>>>> Generating mouse enter/exit events always should be in order >>>>>>>>> where >>>>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>>>> >>>>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method >>>>>>>>> tries to >>>>>>>>> generate mouse enter/exit events for all windows during mouse >>>>>>>>> drag >>>>>>>>> or window creation/window bounds changing. >>>>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>>>> This method also tries to generate both mouse enter and exit >>>>>>>>> event >>>>>>>>> for the same window but only one of them can be applicable >>>>>>>>> because >>>>>>>>> the isTopMostWindowUnderMouse state is not changed for these >>>>>>>>> calls. >>>>>>>>> >>>>>>>>> So the window enter/exit events now are always generated from the >>>>>>>>> native system and component enter/exit events are generated in >>>>>>>>> the >>>>>>>>> LWWindowPeer class. >>>>>>>>> >>>>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>>>> case when a mouse is dragged from one window to another the >>>>>>>>> current >>>>>>>>> component receives drag events and last and topmostUnderMouse >>>>>>>>> links >>>>>>>>> handle components mouse exit/enter events on the second window. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>> >>>>> >>> > -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Aug 28 09:37:53 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 28 Aug 2012 20:37:53 +0400 Subject: [7u8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503CC029.20302@oracle.com> References: <503CC029.20302@oracle.com> Message-ID: <503CF3E1.3040308@oracle.com> Hi Alexander, 1. Does the closed/javax/swing/plaf/basic/BasicToolBarUI/4331392/bug4331392.java test (mentioned in 7154048) pass with this fix? 2. What is the plan for DragWindowTest.java? We should either remove it with this fix, or file a CR and remove '@' from the '@run' jtreg tag so that it wouldn't fail for the time being. -- best regards, Anthony On 8/28/2012 4:57 PM, Alexander Scherbatiy wrote: > Hello, > > Please review the fix for the JDK 7u8: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 > webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev7.00/ > > This is a regression after the fix 7154048 [macosx] At least drag twice, > the toolbar can be dragged to the left side. > > In the case where a toolbar is created under a mouse and it is dragged > over the initial window the mouse enter/exit events should not be > generated for the components which are under the toolbar. > The disabling component mouse enter/exit events generation during drag > leads that it does not work in the case where a mouse is dragged over > the current window. > > The full fix that checks that a current window is a topmost window under > mouse requires some changes (using tracking area instead of tracking > rectangle and so on) is a quite complicated and it seems that it is > risky to include it to the JDK 7u8. > > Current fix just changes the condition for the component mouse > enter/exit events generation to the initial state how it was before the > 7154048 fix. > > This allows to generate components mouse enter/exit events, but the > following test will fail: > java/awt/Mouse/EnterExitEvents/DragWindowTest.java > However this test did not work before the 7154048 fix so it is not a > regression. > > > Thanks, > Alexandr. > From alexandr.scherbatiy at oracle.com Wed Aug 29 02:59:20 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 29 Aug 2012 13:59:20 +0400 Subject: [7u8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503CF3E1.3040308@oracle.com> References: <503CC029.20302@oracle.com> <503CF3E1.3040308@oracle.com> Message-ID: <503DE7F8.2000401@oracle.com> Could you review the updated fix for the JDK 7u8 where the failed test is removed: http://cr.openjdk.java.net/~alexsch/7171045/webrev7.02/ On 8/28/2012 8:37 PM, Anthony Petrov wrote: > Hi Alexander, > > 1. Does the > closed/javax/swing/plaf/basic/BasicToolBarUI/4331392/bug4331392.java > test (mentioned in 7154048) pass with this fix? Yes, the test passes. The fix reverted back changes after the 7154048 fix. http://cr.openjdk.java.net/~alexsch/7154048/webrev7.00/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html > > 2. What is the plan for DragWindowTest.java? We should either remove > it with this fix, or file a CR and remove '@' from the '@run' jtreg > tag so that it wouldn't fail for the time being. I removed the failed DragWindowTest.java from the JDK 7u repository in the updated fix. But it still presents in the JDK 8 repository and passes with the fixed 7154048 and 7171045 issues. Thanks, Alexandr. > > -- > best regards, > Anthony > > On 8/28/2012 4:57 PM, Alexander Scherbatiy wrote: >> Hello, >> >> Please review the fix for the JDK 7u8: >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev7.00/ >> >> This is a regression after the fix 7154048 [macosx] At least drag >> twice, the toolbar can be dragged to the left side. >> >> In the case where a toolbar is created under a mouse and it is >> dragged over the initial window the mouse enter/exit events should >> not be generated for the components which are under the toolbar. >> The disabling component mouse enter/exit events generation during >> drag leads that it does not work in the case where a mouse is dragged >> over the current window. >> >> The full fix that checks that a current window is a topmost window >> under mouse requires some changes (using tracking area instead of >> tracking rectangle and so on) is a quite complicated and it seems >> that it is risky to include it to the JDK 7u8. >> >> Current fix just changes the condition for the component mouse >> enter/exit events generation to the initial state how it was before >> the 7154048 fix. >> >> This allows to generate components mouse enter/exit events, but the >> following test will fail: >> java/awt/Mouse/EnterExitEvents/DragWindowTest.java >> However this test did not work before the 7154048 fix so it is not a >> regression. >> >> >> Thanks, >> Alexandr. >> From anthony.petrov at oracle.com Wed Aug 29 03:03:44 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 29 Aug 2012 14:03:44 +0400 Subject: [7u8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503DE7F8.2000401@oracle.com> References: <503CC029.20302@oracle.com> <503CF3E1.3040308@oracle.com> <503DE7F8.2000401@oracle.com> Message-ID: <503DE900.1070807@oracle.com> Looks fine. Thanks. -- best regards, Anthony On 8/29/2012 1:59 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix for the JDK 7u8 where the failed test > is removed: > http://cr.openjdk.java.net/~alexsch/7171045/webrev7.02/ > > On 8/28/2012 8:37 PM, Anthony Petrov wrote: >> Hi Alexander, >> >> 1. Does the >> closed/javax/swing/plaf/basic/BasicToolBarUI/4331392/bug4331392.java >> test (mentioned in 7154048) pass with this fix? > Yes, the test passes. The fix reverted back changes after the > 7154048 fix. > > http://cr.openjdk.java.net/~alexsch/7154048/webrev7.00/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html > >> >> 2. What is the plan for DragWindowTest.java? We should either remove >> it with this fix, or file a CR and remove '@' from the '@run' jtreg >> tag so that it wouldn't fail for the time being. > I removed the failed DragWindowTest.java from the JDK 7u repository > in the updated fix. But it still presents in the JDK 8 repository and > passes with the fixed 7154048 and 7171045 issues. > > Thanks, > Alexandr. > >> >> -- >> best regards, >> Anthony >> >> On 8/28/2012 4:57 PM, Alexander Scherbatiy wrote: >>> Hello, >>> >>> Please review the fix for the JDK 7u8: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev7.00/ >>> >>> This is a regression after the fix 7154048 [macosx] At least drag >>> twice, the toolbar can be dragged to the left side. >>> >>> In the case where a toolbar is created under a mouse and it is >>> dragged over the initial window the mouse enter/exit events should >>> not be generated for the components which are under the toolbar. >>> The disabling component mouse enter/exit events generation during >>> drag leads that it does not work in the case where a mouse is dragged >>> over the current window. >>> >>> The full fix that checks that a current window is a topmost window >>> under mouse requires some changes (using tracking area instead of >>> tracking rectangle and so on) is a quite complicated and it seems >>> that it is risky to include it to the JDK 7u8. >>> >>> Current fix just changes the condition for the component mouse >>> enter/exit events generation to the initial state how it was before >>> the 7154048 fix. >>> >>> This allows to generate components mouse enter/exit events, but the >>> following test will fail: >>> java/awt/Mouse/EnterExitEvents/DragWindowTest.java >>> However this test did not work before the 7154048 fix so it is not a >>> regression. >>> >>> >>> Thanks, >>> Alexandr. >>> > From earle.nietzel at gmail.com Wed Aug 29 16:45:46 2012 From: earle.nietzel at gmail.com (Earle Nietzel) Date: Wed, 29 Aug 2012 19:45:46 -0400 Subject: No subject Message-ID: Seeing the following Warning multiple times every few seconds. Aug 29, 2012 7:09:26 PM sun.rmi.transport.tcp.TCPTransport$AcceptLoop executeAcceptLoop WARNING: RMI TCP Accept-1099: accept loop for ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=1099] throws java.net.SocketException: Invalid argument at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398) at java.net.ServerSocket.implAccept(ServerSocket.java:522) at java.net.ServerSocket.accept(ServerSocket.java:490) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359) at java.lang.Thread.run(Thread.java:722) OSX 10.8.1 java version "1.7.0_06" Java(TM) SE Runtime Environment (build 1.7.0_06-b24) Java HotSpot(TM) 64-Bit Server VM (build 23.2-b09, mixed mode) The closest thread I found seems to be this one: http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-December/000229.html No issues when using JAVA 6 JDK's. These warnings appear constantly when working with ActiveMQ 5.4.0, 5.6.0. Forgive for me if this post seems irrelevant to this list :) Earle From kurchi.subhra.hazra at oracle.com Wed Aug 29 16:55:52 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 29 Aug 2012 16:55:52 -0700 Subject: In-Reply-To: References: Message-ID: <503EAC08.5040508@oracle.com> Forwarding this to the networking mailing list. Do you know of any way to reproduce the problem, like a small test case that we(I) could try? Thanks, Kurchi On 8/29/2012 4:45 PM, Earle Nietzel wrote: > Seeing the following Warning multiple times every few seconds. > > Aug 29, 2012 7:09:26 PM sun.rmi.transport.tcp.TCPTransport$AcceptLoop > executeAcceptLoop > WARNING: RMI TCP Accept-1099: accept loop for > ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=1099] throws > java.net.SocketException: Invalid argument > at java.net.PlainSocketImpl.socketAccept(Native Method) > at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398) > at java.net.ServerSocket.implAccept(ServerSocket.java:522) > at java.net.ServerSocket.accept(ServerSocket.java:490) > at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387) > at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359) > at java.lang.Thread.run(Thread.java:722) > > > OSX 10.8.1 > > java version "1.7.0_06" > Java(TM) SE Runtime Environment (build 1.7.0_06-b24) > Java HotSpot(TM) 64-Bit Server VM (build 23.2-b09, mixed mode) > > The closest thread I found seems to be this one: > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-December/000229.html > > No issues when using JAVA 6 JDK's. > > These warnings appear constantly when working with ActiveMQ 5.4.0, 5.6.0. > > Forgive for me if this post seems irrelevant to this list :) > > Earle -- -Kurchi From earle.nietzel at gmail.com Wed Aug 29 21:23:53 2012 From: earle.nietzel at gmail.com (Earle Nietzel) Date: Thu, 30 Aug 2012 00:23:53 -0400 Subject: In-Reply-To: References: <45596056-1434-4A73-86EB-26B44D03205D@gmail.com> Message-ID: Hi Greg, Thanks for the info, though, I am wired on this mac and have the wifi turned off. Earle On Wed, Aug 29, 2012 at 10:28 PM, Gregg Wonderly wrote: > Also, if the socket is being asynchronously closed, it might be related to > the "Lion WiFi Constantly Dropping" problem that some people are reporting > as still not fixed. > > View the full discussion for Wifi Constantly Dropping in Lion > > Gregg Wonderly > > On Aug 29, 2012, at 9:25 PM, Gregg Wonderly wrote: > > In many cases, doesn't this come from using a valid (not -1) fd/socket > number, but which has been closed? Is the connection being closed > asynchronously from some other code or the remote end? > > Gregg Wonderly > > On Aug 29, 2012, at 6:45 PM, Earle Nietzel wrote: > > Seeing the following Warning multiple times every few seconds. > > Aug 29, 2012 7:09:26 PM sun.rmi.transport.tcp.TCPTransport$AcceptLoop > executeAcceptLoop > WARNING: RMI TCP Accept-1099: accept loop for > ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=1099] throws > java.net.SocketException: Invalid argument > at java.net.PlainSocketImpl.socketAccept(Native Method) > at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398) > at java.net.ServerSocket.implAccept(ServerSocket.java:522) > at java.net.ServerSocket.accept(ServerSocket.java:490) > at > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387) > at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359) > at java.lang.Thread.run(Thread.java:722) > > > OSX 10.8.1 > > java version "1.7.0_06" > Java(TM) SE Runtime Environment (build 1.7.0_06-b24) > Java HotSpot(TM) 64-Bit Server VM (build 23.2-b09, mixed mode) > > The closest thread I found seems to be this one: > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-December/000229.html > > No issues when using JAVA 6 JDK's. > > These warnings appear constantly when working with ActiveMQ 5.4.0, 5.6.0. > > Forgive for me if this post seems irrelevant to this list :) > > Earle > > > From earle.nietzel at gmail.com Wed Aug 29 21:39:41 2012 From: earle.nietzel at gmail.com (Earle Nietzel) Date: Thu, 30 Aug 2012 00:39:41 -0400 Subject: RMI TCP Accept Loop throws java.net.SocketException: Invalid argument in Native method Message-ID: I can reproduce regularly with using ActiveMQ 5.4.0 (also tried 5.6.0) on Mac only. When using multicast discovery the app won't start without -XX:+UseVMInterruptibleIO. If I remove the multicast discovery and opt for tcp or nio then don't need to use -XX:+UseVMInterruptibleIO. but in either case I am seeing these RMI warnings. I will come up with a easy way to reproduce it and post. Earle On Thu, Aug 30, 2012 at 12:23 AM, Earle Nietzel wrote: > Hi Greg, > > Thanks for the info, though, I am wired on this mac and have the wifi > turned off. > > Earle > > On Wed, Aug 29, 2012 at 10:28 PM, Gregg Wonderly wrote: >> Also, if the socket is being asynchronously closed, it might be related to >> the "Lion WiFi Constantly Dropping" problem that some people are reporting >> as still not fixed. >> >> View the full discussion for Wifi Constantly Dropping in Lion >> >> Gregg Wonderly >> >> On Aug 29, 2012, at 9:25 PM, Gregg Wonderly wrote: >> >> In many cases, doesn't this come from using a valid (not -1) fd/socket >> number, but which has been closed? Is the connection being closed >> asynchronously from some other code or the remote end? >> >> Gregg Wonderly >> >> On Aug 29, 2012, at 6:45 PM, Earle Nietzel wrote: >> >> Seeing the following Warning multiple times every few seconds. >> >> Aug 29, 2012 7:09:26 PM sun.rmi.transport.tcp.TCPTransport$AcceptLoop >> executeAcceptLoop >> WARNING: RMI TCP Accept-1099: accept loop for >> ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=1099] throws >> java.net.SocketException: Invalid argument >> at java.net.PlainSocketImpl.socketAccept(Native Method) >> at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398) >> at java.net.ServerSocket.implAccept(ServerSocket.java:522) >> at java.net.ServerSocket.accept(ServerSocket.java:490) >> at >> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387) >> at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359) >> at java.lang.Thread.run(Thread.java:722) >> >> >> OSX 10.8.1 >> >> java version "1.7.0_06" >> Java(TM) SE Runtime Environment (build 1.7.0_06-b24) >> Java HotSpot(TM) 64-Bit Server VM (build 23.2-b09, mixed mode) >> >> The closest thread I found seems to be this one: >> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-December/000229.html >> >> No issues when using JAVA 6 JDK's. >> >> These warnings appear constantly when working with ActiveMQ 5.4.0, 5.6.0. >> >> Forgive for me if this post seems irrelevant to this list :) >> >> Earle >> >> >> From Alan.Bateman at oracle.com Thu Aug 30 02:37:11 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Aug 2012 10:37:11 +0100 Subject: RMI TCP Accept Loop throws java.net.SocketException: Invalid argument in Native method In-Reply-To: References: Message-ID: <503F3447.8040607@oracle.com> On 30/08/2012 05:39, Earle Nietzel wrote: > I can reproduce regularly with using ActiveMQ 5.4.0 (also tried 5.6.0) > on Mac only. > > When using multicast discovery the app won't start without > -XX:+UseVMInterruptibleIO. > > If I remove the multicast discovery and opt for tcp or nio then don't > need to use -XX:+UseVMInterruptibleIO. > > but in either case I am seeing these RMI warnings. > > I will come up with a easy way to reproduce it and post. > > Earle > This is interesting because UseVMInterruptibleIO was Solaris specific (and so is news to me that legacy interruptible I/O was implemented on Mac). As background, we have been trying to eliminate this for many years. The UseVMInterruptibleIO option was added in jdk6 to allow developers on Solaris to disable it and check that their applications still ran, then in jdk7 the default value of the option was changed to disabled it by default. The original plan was to completely remove it at some point too. -Alan. From private at claudio.ch Thu Aug 30 12:35:54 2012 From: private at claudio.ch (Claudio Nieder) Date: Thu, 30 Aug 2012 21:35:54 +0200 Subject: OSX Java application using awt always switches MacBook to discrete graphics. Bug or feature? Message-ID: <531D358C-AF0A-4737-8C72-709203A96FD9@claudio.ch> Hi, I notice that all my Java applications which use AWT libraries in any form switches my MacBook Pro Retina to the (more battery consuming) discrete graphics mode, even when drawing very simple things. The following small program is enough to trigger the switch though it does not even open a window or draw anything. import java.awt.GraphicsEnvironment; public class Sleep { public static final void main(final String[] args) throws InterruptedException { final GraphicsEnvironment b=GraphicsEnvironment.getLocalGraphicsEnvironment(); Thread.sleep(Long.MAX_VALUE); } } Is this "bad behavior by design" or shall I file a bug report? I observe this with JDK 7u8-b04 on OS X 10.8.1 $ java -version java version "1.7.0_08-ea" Java(TM) SE Runtime Environment (build 1.7.0_08-ea-b04) Java HotSpot(TM) 64-Bit Server VM (build 23.4-b01, mixed mode) $ uname -a Darwin Claudios-MacBook-Pro.local 12.1.0 Darwin Kernel Version 12.1.0: Tue Aug 14 13:29:55 PDT 2012; root:xnu-2050.9.2~1/RELEASE_X86_64 x86_64 claudio -- Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch From scott.kovatch at oracle.com Fri Aug 31 10:45:18 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 31 Aug 2012 10:45:18 -0700 Subject: Review: Remove private API from graphics code Message-ID: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> http://cr.openjdk.java.net/~skovatch/7187834/webrev.00/ This is based on the patch submitted by Marco Dinacci. I had to modify it a bit to get it to compile against 7u-dev, but nothing major. The changes in ImageSurfaceData.h were needed as a result of my use of Xcode 4.4.1 on Mountain Lion. I ran the Java2Demo and don't see any problems. I paid close attention to the Images tab, since it looks like this code is heavily used by it. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From philip.race at oracle.com Fri Aug 31 11:16:27 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 31 Aug 2012 11:16:27 -0700 Subject: Review: Remove private API from graphics code In-Reply-To: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> References: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> Message-ID: <5040FF7B.4030106@oracle.com> Scott, These files were added by Bino to support printing. Quartz isn't used except for printing in JDK 7, so as I understand it, testing on-screen in Java2Demo should not exercise this code. I'm surprised that you saw it being exercised. Did you do any printing testing ? The matrix inversion seems unlikely to be applied to any non-invertible matrices, so that's fine, but I wonder if you have lost precision here due to floating point inaccuracies ? If you originally had a simple scale or identity, rotated it, and then applied the inverse to unrotate it, do you really end up with exactly the same results. The more you do this the more inaccuracies creep in, which may be part of the reason for the original approach. I find it a little hard to believe that there isn't a direct public way to restore a transform. The changes for mountain lion are safe for snow leopard I presume? I believe the builds still happen on snow leopard. Also this should have been sent to 2d-dev, not awt-dev. These files, APIs, and printing are all 2D, not awt. -phil. I am not sure why they are not used but it On 8/31/2012 10:45 AM, Scott Kovatch wrote: > http://cr.openjdk.java.net/~skovatch/7187834/webrev.00/ > > This is based on the patch submitted by Marco Dinacci. I had to modify it a bit to get it to compile against 7u-dev, but nothing major. > > The changes in ImageSurfaceData.h were needed as a result of my use of Xcode 4.4.1 on Mountain Lion. > > I ran the Java2Demo and don't see any problems. I paid close attention to the Images tab, since it looks like this code is heavily used by it. > > -- Scott K. > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > > From philip.race at oracle.com Fri Aug 31 11:50:34 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 31 Aug 2012 11:50:34 -0700 Subject: Review: Remove private API from graphics code In-Reply-To: <5040FF7B.4030106@oracle.com> References: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> <5040FF7B.4030106@oracle.com> Message-ID: <5041077A.7080002@oracle.com> The recommendation is to restore the graphics state rather than inverting :- https://developer.apple.com/library/mac/#documentation/graphicsimaging/conceptual/drawingwithquartz2d/dq_affine/dq_affine.html "Quartz also provides an affine transform function that inverts a matrix, |CGAffineTransformInvert|. Inversion is generally used to provide reverse transformation of points within transformed objects. Inversion can be useful when you need to recover a value that has been transformed by a matrix: Invert the matrix, and multiply the value by the inverted matrix, and the result is the original value. You usually don?t need to invert transforms because you can reverse the effects of transforming the CTM by saving and restoring the graphics state." -phil. On 8/31/2012 11:16 AM, Phil Race wrote: > Scott, > > These files were added by Bino to support printing. Quartz isn't used > except for printing in JDK 7, so as I understand it, testing on-screen in > Java2Demo should not exercise this code. I'm surprised that you saw > it being exercised. Did you do any printing testing ? > > The matrix inversion seems unlikely to be applied to any non-invertible > matrices, so that's fine, but I wonder if you have lost precision here > due to floating point inaccuracies ? > > If you originally had a simple scale or identity, rotated it, and then > applied the inverse to unrotate it, do you really end up with exactly > the same results. The more you do this the more inaccuracies creep in, > which may be part of the reason for the original approach. > I find it a little hard to believe that there isn't a direct public > way to > restore a transform. > > The changes for mountain lion are safe for snow leopard I presume? > I believe the builds still happen on snow leopard. > > Also this should have been sent to 2d-dev, not awt-dev. > These files, APIs, and printing are all 2D, not awt. > > -phil. > > I am not sure why they are not used but it > On 8/31/2012 10:45 AM, Scott Kovatch wrote: >> http://cr.openjdk.java.net/~skovatch/7187834/webrev.00/ >> >> This is based on the patch submitted by Marco Dinacci. I had to >> modify it a bit to get it to compile against 7u-dev, but nothing major. >> >> The changes in ImageSurfaceData.h were needed as a result of my use >> of Xcode 4.4.1 on Mountain Lion. >> >> I ran the Java2Demo and don't see any problems. I paid close >> attention to the Images tab, since it looks like this code is heavily >> used by it. >> >> -- Scott K. >> >> ---------------------------------------- >> Scott Kovatch >> scott.kovatch at oracle.com >> Santa Clara/Pleasanton, CA >> >> > From scott.kovatch at oracle.com Fri Aug 31 11:57:39 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 31 Aug 2012 11:57:39 -0700 Subject: Review: Remove private API from graphics code In-Reply-To: <5040FF7B.4030106@oracle.com> References: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> <5040FF7B.4030106@oracle.com> Message-ID: <37D89CC9-5CB7-46CC-AFBA-7A7E0643A917@oracle.com> On Aug 31, 2012, at 11:16 AM, Phil Race wrote: > Scott, > > These files were added by Bino to support printing. Quartz isn't used > except for printing in JDK 7, so as I understand it, testing on-screen in > Java2Demo should not exercise this code. I'm surprised that you saw > it being exercised. Did you do any printing testing ? I tried printing from the 2d demo, and now I'm not so sure about the changes. I printed one image and it was inverted. :-\ > The matrix inversion seems unlikely to be applied to any non-invertible > matrices, so that's fine, but I wonder if you have lost precision here > due to floating point inaccuracies ? I have to admit that I didn't go that deep into the code, since the main purpose of the changes were to get rid of the private API so we could submit something to the OS X app store. > If you originally had a simple scale or identity, rotated it, and then > applied the inverse to unrotate it, do you really end up with exactly > the same results. The more you do this the more inaccuracies creep in, > which may be part of the reason for the original approach. > I find it a little hard to believe that there isn't a direct public way to > restore a transform. I was surprised by that, too, but for what it's worth CGContextSave/RestoreGState save and restore the current transform. I didn't dig deeply enough to see if they could/should be used instead. > The changes for mountain lion are safe for snow leopard I presume? > I believe the builds still happen on snow leopard. I would think so, yes. I'm replacing private API with long-available public API. The core JDK builds on Lion due to the need for APIs that arrived in 10.7.3. > Also this should have been sent to 2d-dev, not awt-dev. > These files, APIs, and printing are all 2D, not awt. Okay. I didn't realize Quartz was only being used in printing, though in retrospect that makes sense now. I see you moved the bug already. -- Scott K. From paul_t100 at fastmail.fm Fri Aug 31 12:52:21 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 31 Aug 2012 20:52:21 +0100 Subject: JFileChooser not seeing network mounted files on 1.7.0_06 on Mac In-Reply-To: <50376AE0.9080102@oracle.com> References: <502CB1ED.9070507@fastmail.fm> <502CEB07.40708@oracle.com> <503754BE.9000009@fastmail.fm> <50375C84.8030009@oracle.com> <50375F2A.1080304@fastmail.fm> <50376591.5040109@fastmail.fm> <5037665E.4090309@oracle.com> <503769E6.2020200@fastmail.fm> <50376AE0.9080102@oracle.com> Message-ID: <504115F5.5090501@fastmail.fm> On 24/08/2012 12:52, Anthony Petrov wrote: > On 8/24/2012 3:47 PM, Paul Taylor wrote: >>>> System.setProperty("apple.awt.fileDialogForDirectories", "true"); >>>> >>>> but seems to have no effect, is this option still supported ? >>> >>> This is fixed for 7u8 under CR 7161437. >>> >> Thats good news , but I am in fact using 1.7.0_08-ea, is there later >> version of 7u8 or am I using the fix wrong Im doing >> >> System.setProperty("apple.awt.fileDialogForDirectories", >> "true"); >> FileDialog chooser = new FileDialog(MainWindow.frame); >> chooser.setMode(FileDialog.LOAD); >> chooser.setVisible(true); >> String folderSelected = chooser.getDirectory(); >> System.setProperty("apple.awt.fileDialogForDirectories", >> "false"); >> File folder = new File(folderSelected) ; >> if(folder.exists() && folder.isDirectory()) >> { >> //DO something >> } >> > > The fix hasn't made it to the master repository yet. It is expected to > appear in either 7u8b03 or 7u8b04. Maybe, in the worst case, in b05. > Please check what build you're using with `java -version` and stay tuned. > > -- > best regards, > Anthony > Doesn't seem to have made it build 5 either, http://download.java.net/jdk7u8/changes/jdk7u8-b05.html problematic for me I cannot release my product until this problem is resolved.