From mik3hall at gmail.com Tue Nov 1 03:40:35 2011 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 1 Nov 2011 05:40:35 -0500 Subject: MacOS FutureTask.get race (sort of) In-Reply-To: References: Message-ID: On Oct 31, 2011, at 10:07 AM, Jason Schroeder wrote: > I hope mentioning the race contained in this example is appropriate. I can > only force this bug to appear with the MacOS jvm. > > How can I be of useful assistance? > > // $ java -version > // java version "1.6.0_27" > // Java(TM) SE Runtime Environment (build 1.6.0_27-b07-393-11M3511) > // Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06-393, mixed mode) > // I think the JVM you show is the current Apple one not openjdk isn't it? Do we bug report race conditions, if I'm understanding your use correctly is sort of an interesting question. I just got this... Thread 16 Crashed: Java: AWT-EventQueue-0 0 libSystem.B.dylib 0x91b1ac5a __kill + 10 1 libSystem.B.dylib 0x91b1ac4c kill$UNIX2003 + 32 2 libSystem.B.dylib 0x91bad5a5 raise + 26 3 libSystem.B.dylib 0x91bc36e4 abort + 93 4 libjvm.dylib 0x01843a7f os::abort(bool) + 25 5 libjvm.dylib 0x0185cf5a VMError::report_and_die() + 2476 6 libjvm.dylib 0x01c9c053 crash_handler(int, __siginfo*, void*) + 128 7 libSystem.B.dylib 0x91b2005b _sigtramp + 43 8 ??? 0xffffffff 0 + 4294967295 9 libjvm.dylib 0x0185be76 VMError::report(outputStream*) + 2740 10 libjvm.dylib 0x0185cc04 VMError::report_and_die() + 1622 11 libjvm.dylib 0x01bc725f JVM_handle_bsd_signal + 1397 12 libjvm.dylib 0x01bc4bea signalHandler(int, __siginfo*, void*) + 42 13 libSystem.B.dylib 0x91b2005b _sigtramp + 43 14 ??? 0xffffffff 0 + 4294967295 In a crash log. I thought Eclipse was showing a related SIGSEGV in it's console too but now I'm not seeing that. Probably because I restarted to see if I could reproduce. So far no go. So how do I know if it was my code not properly using invokeLater or something or a jvm race condition? So I suppose not worth the bug report? Pretty sure mine is openjdk this time anyhow. set java.* | grep version System.in:3:java.runtime.version=1.7.0-ea-b215 System.in:4:java.version=1.7.0-ea System.in:7:java.class.version=51.0 System.in:10:java.vm.version=21.0-b17 System.in:20:java.vm.specification.version=1.7 System.in:27:java.specification.version=1.7 From sergey.bylokhov at oracle.com Tue Nov 1 06:59:44 2011 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Tue, 01 Nov 2011 13:59:44 +0000 Subject: hg: macosx-port/macosx-port/jdk: MACOSX_PORT-567: FlowLayoutTest0002 fails in JCK-runtime-7 interactive Message-ID: <20111101135954.A0D2F471EA@hg.openjdk.java.net> Changeset: 3b9f5415a647 Author: serb Date: 2011-11-01 17:53 +0400 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/3b9f5415a647 MACOSX_PORT-567: FlowLayoutTest0002 fails in JCK-runtime-7 interactive ! src/macosx/classes/sun/lwawt/LWButtonPeer.java ! src/macosx/classes/sun/lwawt/LWChoicePeer.java ! src/macosx/classes/sun/lwawt/LWContainerPeer.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java From peter.brunet at oracle.com Tue Nov 1 07:49:54 2011 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 01 Nov 2011 09:49:54 -0500 Subject: Using Fusion for Win builds Message-ID: <4EB00712.5070903@oracle.com> Is anyone doing openjdk Win builds in a VM in addition to the macosx-port builds? Now that I've moved to MBP and Lion for my macosx-port builds I still need to do 32 and 64 bit builds on Win 7 and have installed VMWare Fusion for this. Those builds are failing randomly with Error 126 and the problem is not repeatable when restarting the build. One of my failures wasn't an Error 126 and is shown below. If you're using a VM for Win builds please let me know the details. Thanks, Pete make[5]: Leaving directory `/cygdrive/c/OpenJDK/jdk8/jdk/make/launchers' cd ../launchers && make -f Makefile.launcher PROGRAM=extcheck MAIN_CLASS=com.sun.tools.extcheck.Main MAIN_JAVA_ARGS="" MAIN_ARGS="" make[5]: Entering directory `/cygdrive/c/OpenJDK/jdk8/jdk/make/launchers' make[5]: ../common/Defs.gmk:89: fork: Resource temporarily unavailable make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs.gmk:343: fork: Resource temporarily unavailable make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs-windows.gmk:226: fork: Resource temporarily unavailable make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs-windows.gmk:253: fork: Resource temporarily unavailable make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs-windows.gmk:481: fork: Resource temporarily unavailable C:/OpenJDK/jdk8/jdk/make/common/shared/Defs-windows.gmk:484: "WARNING: Value of DXSDK_PATH cannot be empty, check or set ALT_DXSDK_PATH" make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs-windows.gmk:532: fork: Resource temporarily unavailable make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs-windows.gmk:545: fork: Resource temporarily unavailable make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs-windows.gmk:556: fork: Resource temporarily unavailable make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs-windows.gmk:567: fork: Resource temporarily unavailable make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs.gmk:408: fork: Resource temporarily unavailable make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs.gmk:444: fork: Resource temporarily unavailable make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs.gmk:451: fork: Resource temporarily unavailable make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs.gmk:510: fork: Resource temporarily unavailable C:/OpenJDK/jdk8/jdk/make/common/shared/Defs.gmk:514: "WARNING: Value of CACERTS_FILE cannot be empty, check or set ALT_CACERTS_FILE" make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs.gmk:523: fork: Resource temporarily unavailable make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs.gmk:524: fork: Resource temporarily unavailable make[5]: C:/OpenJDK/jdk8/jdk/make/common/shared/Defs.gmk:542: fork: Resource temporarily unavailable C:/OpenJDK/jdk8/jdk/make/common/shared/Defs.gmk:544: *** "ERROR: Trouble with the absolute path for OUTPUTDIR 'C:/OpenJDK/jdk8/build/windows-i586/../windows-i586-fastdebug', was ALT_OUTPUTDIR 'C:/OpenJDK/jdk8/build/windows-i586/../windows-i586-fastdebug' an absolute path?". Stop. make[5]: Leaving directory `/cygdrive/c/OpenJDK/jdk8/jdk/make/launchers' make[4]: *** [build] Error 2 make[4]: Leaving directory `/cygdrive/c/OpenJDK/jdk8/jdk/make/launchers' make[3]: *** [all] Error 1 make[3]: Leaving directory `/cygdrive/c/OpenJDK/jdk8/jdk/make' make[2]: *** [jdk-build] Error 2 make[2]: Leaving directory `/cygdrive/c/OpenJDK/jdk8' make[1]: *** [generic_debug_build] Error 2 make[1]: Leaving directory `/cygdrive/c/OpenJDK/jdk8' make: *** [build_fastdebug_image] Error 2 From shrode at subnature.com Tue Nov 1 11:19:18 2011 From: shrode at subnature.com (Jason Schroeder) Date: Tue, 1 Nov 2011 12:19:18 -0600 Subject: MacOS FutureTask.get race (sort of) In-Reply-To: References: Message-ID: I made the same problem happen with the macosx: openjdk version "1.7.0-ea" OpenJDK Runtime Environment (build 1.7.0-ea-b215) OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode) The problem here is that the contract of FutureTask.get is breaking and most likely something is not right at runtime with AbstractQueuedSynchronizer or FutureTask.Sync. So far, I have only triggered this problem on MacOS, so I have thought the port team might like to know. On Tue, Nov 1, 2011 at 4:40 AM, Michael Hall wrote: > > On Oct 31, 2011, at 10:07 AM, Jason Schroeder wrote: > > > I hope mentioning the race contained in this example is appropriate. I > can > > only force this bug to appear with the MacOS jvm. > > > > How can I be of useful assistance? > > > > // $ java -version > > // java version "1.6.0_27" > > // Java(TM) SE Runtime Environment (build 1.6.0_27-b07-393-11M3511) > > // Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06-393, mixed mode) > > // > > I think the JVM you show is the current Apple one not openjdk isn't it? > > Do we bug report race conditions, if I'm understanding your use correctly > is sort of an interesting question. > I just got this... > > Thread 16 Crashed: Java: AWT-EventQueue-0 > 0 libSystem.B.dylib 0x91b1ac5a __kill + 10 > 1 libSystem.B.dylib 0x91b1ac4c kill$UNIX2003 + 32 > 2 libSystem.B.dylib 0x91bad5a5 raise + 26 > 3 libSystem.B.dylib 0x91bc36e4 abort + 93 > 4 libjvm.dylib 0x01843a7f os::abort(bool) + 25 > 5 libjvm.dylib 0x0185cf5a > VMError::report_and_die() + 2476 > 6 libjvm.dylib 0x01c9c053 crash_handler(int, > __siginfo*, void*) + 128 > 7 libSystem.B.dylib 0x91b2005b _sigtramp + 43 > 8 ??? 0xffffffff 0 + 4294967295 > 9 libjvm.dylib 0x0185be76 > VMError::report(outputStream*) + 2740 > 10 libjvm.dylib 0x0185cc04 > VMError::report_and_die() + 1622 > 11 libjvm.dylib 0x01bc725f JVM_handle_bsd_signal + > 1397 > 12 libjvm.dylib 0x01bc4bea signalHandler(int, > __siginfo*, void*) + 42 > 13 libSystem.B.dylib 0x91b2005b _sigtramp + 43 > 14 ??? 0xffffffff 0 + 4294967295 > > In a crash log. > > I thought Eclipse was showing a related SIGSEGV in it's console too but > now I'm not seeing that. > > Probably because I restarted to see if I could reproduce. > > So far no go. > > So how do I know if it was my code not properly using invokeLater or > something or a jvm race condition? > So I suppose not worth the bug report? > > Pretty sure mine is openjdk this time anyhow. > > set java.* | grep version > System.in:3:java.runtime.version=1.7.0-ea-b215 > System.in:4:java.version=1.7.0-ea > System.in:7:java.class.version=51.0 > System.in:10:java.vm.version=21.0-b17 > System.in:20:java.vm.specification.version=1.7 > System.in:27:java.specification.version=1.7 From mik3hall at gmail.com Tue Nov 1 14:34:55 2011 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 1 Nov 2011 16:34:55 -0500 Subject: MacOS FutureTask.get race (sort of) In-Reply-To: References: Message-ID: On Nov 1, 2011, at 1:19 PM, Jason Schroeder wrote: > The problem here is that the contract of FutureTask.get is breaking and most likely something is not right at runtime with AbstractQueuedSynchronizer or FutureTask.Sync. > > So far, I have only triggered this problem on MacOS, so I have thought the port team might like to know. Not familiar with the API yet myself. Odd if incorrect only on OS X. They are sort of independent builds. For yours it might make sense to bug report. Since they are independent it would need to be separate bug reports I think. Not sure you'll see a fix with the Apple since it isn't expected to continue beyond 10.7 as far as I know. For mine not even reproducible I think I'll just try to figure out where I need the invokeLater. From henri.gomez at gmail.com Wed Nov 2 00:00:37 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 2 Nov 2011 08:00:37 +0100 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: <4EAF76CE.9080907@oracle.com> References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> Message-ID: Hi Sunder Will you also explain how to get Rhino built into OpenJDK, ie what should be done in makefile's and parameters, to get it loaded and compiled in JDK ? Cheers 2011/11/1 A. Sundararajan : > Hi, > > Yes, we are working on updating the release note to point people to the > CloseJDK Rhino changes. > > Thanks, > -Sundar > > > mark.reinhold at oracle.com wrote: >> >> 2011/10/31 4:51 -0700, mark at klomp.org: >> >>> >>> This might have slipped through with all the excitement around JavaFX >>> being liberated and all the new JEPs. But it would really help us if you >>> could take a quick peek and point us in the right direction. >>> >>> It would be good for us to make sure we all distribute the same >>> javax.script javascript support, whether it is ClosedJDK, OpenJDK, >>> IcedTea or the MacOSX port. Users probably would like to be sure it is >>> all compatible and supports the same features. >>> >> >> Sundar -- Could you please summarize the changes you made to the Rhino >> code when you last updated the copy used in the Oracle builds? ?Thanks. >> >> >>> >>> Maybe it is already in the distribution legal notes somewhere, but we >>> looked and cannot find it (maybe we looked in the wrong place). Assuming >>> you are redistributing Rhino under the GPL/MPL there really should at >>> least be a conspicuous notice stating where to find the modifications >>> used to make the binary Oracle is distributing (MPL section 3.6 and/or >>> GPL section 3). >>> >> >> That should be in the Oracle JDK 7 release notes, but I don't see it, >> so I'll ask someone to take care of it. >> >> - Mark >> > > From tobi at ultramixer.com Wed Nov 2 04:22:47 2011 From: tobi at ultramixer.com (Tobias Bley (UltraMixer)) Date: Wed, 2 Nov 2011 12:22:47 +0100 Subject: Using JavaNativeFoundation.framework with embedded OpenJDK7? Message-ID: <9FB9DB71-4539-4420-A67D-BB2D13D84960@ultramixer.com> Hi Mike, what's the best way to use your excellent JavaNativeFoundation.framework within a Java Application using a private copy of the OpenJDK7? It wrote a jnilib for accessing Cocoa components but my problem is that this library is linked to /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework. So how can I remove this static linking but using JNF? Best regards, Tobi From sergey.bylokhov at oracle.com Wed Nov 2 08:41:19 2011 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Wed, 02 Nov 2011 15:41:19 +0000 Subject: hg: macosx-port/macosx-port/jdk: 2 new changesets Message-ID: <20111102154209.DA695471FF@hg.openjdk.java.net> Changeset: 11dbe2a059f9 Author: serb Date: 2011-11-02 14:52 +0400 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/11dbe2a059f9 Updates in LWTextAreaPeer. ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java Changeset: cb1020b9f276 Author: serb Date: 2011-11-02 19:38 +0400 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/cb1020b9f276 MACOSX_PORT-587: incorrect layout behaviour for GridLayoutTest0004 ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java From artem.ananiev at oracle.com Wed Nov 2 10:05:04 2011 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 02 Nov 2011 21:05:04 +0400 Subject: Any timeline to update to jdk7u2+ In-Reply-To: References: Message-ID: <4EB17840.3070002@oracle.com> On 10/5/2011 10:19 PM, Mark Roos wrote: > Just installed the developer release and it runs fine so far ( I am doing > some invokeDynamic work). > > I see that the vm is not the latest ( which is around 22.0-b06) which has > some invokeDynamic fixes. > > Any comments on when the mac version might migrate? As it was announced at JavaOne, the first 7u version that will include Mac OS X code will be 7u4. At that moment all the platforms will use the same HotSpot version. The exact merging strategy and schedule is TBD. As far as I know, HotSpot team is in progress of reviewing and integrating BSD/MacOSX changes. I would expect the next version of HotSpot may work on Mac, however you'd better ask this question at the hotspot-dev alias. Thanks, Artem > thanks > > mark From artem.ananiev at oracle.com Wed Nov 2 10:41:48 2011 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 02 Nov 2011 21:41:48 +0400 Subject: Any timeline to update to jdk7u2+ In-Reply-To: <4EB17840.3070002@oracle.com> References: <4EB17840.3070002@oracle.com> Message-ID: <4EB180DC.8010002@oracle.com> On 11/2/2011 9:05 PM, Artem Ananiev wrote: > > On 10/5/2011 10:19 PM, Mark Roos wrote: >> Just installed the developer release and it runs fine so far ( I am doing >> some invokeDynamic work). >> >> I see that the vm is not the latest ( which is around 22.0-b06) which has >> some invokeDynamic fixes. >> >> Any comments on when the mac version might migrate? > > As it was announced at JavaOne, the first 7u version that will include > Mac OS X code will be 7u4. At that moment all the platforms will use the > same HotSpot version. > > The exact merging strategy and schedule is TBD. As far as I know, > HotSpot team is in progress of reviewing and integrating BSD/MacOSX > changes. I would expect the next version of HotSpot may work on Mac, > however you'd better ask this question at the hotspot-dev alias. And more information is available in the 7u-dev archives: http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-October/000533.html Thanks, Artem > Thanks, > > Artem > >> thanks >> >> mark From paul.hohensee at oracle.com Wed Nov 2 10:41:00 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 02 Nov 2011 13:41:00 -0400 Subject: Any timeline to update to jdk7u2+ In-Reply-To: <4EB17840.3070002@oracle.com> References: <4EB17840.3070002@oracle.com> Message-ID: <4EB180AC.1060101@oracle.com> The Hotspot team is indeed integrating BSD/OSX changes into hs23, which is the Hotspot version targeted for use in 7u4. Paul On 11/2/11 1:05 PM, Artem Ananiev wrote: > > On 10/5/2011 10:19 PM, Mark Roos wrote: >> Just installed the developer release and it runs fine so far ( I am >> doing >> some invokeDynamic work). >> >> I see that the vm is not the latest ( which is around 22.0-b06) >> which has >> some invokeDynamic fixes. >> >> Any comments on when the mac version might migrate? > > As it was announced at JavaOne, the first 7u version that will include > Mac OS X code will be 7u4. At that moment all the platforms will use > the same HotSpot version. > > The exact merging strategy and schedule is TBD. As far as I know, > HotSpot team is in progress of reviewing and integrating BSD/MacOSX > changes. I would expect the next version of HotSpot may work on Mac, > however you'd better ask this question at the hotspot-dev alias. > > Thanks, > > Artem > >> thanks >> >> mark From sergey.bylokhov at oracle.com Wed Nov 2 10:54:47 2011 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Wed, 02 Nov 2011 17:54:47 +0000 Subject: hg: macosx-port/macosx-port/jdk: ScrollBars in ScrollPane should be visible only when needed. Message-ID: <20111102175458.69C7F47201@hg.openjdk.java.net> Changeset: e39d2fbdffe3 Author: serb Date: 2011-11-02 21:53 +0400 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/e39d2fbdffe3 ScrollBars in ScrollPane should be visible only when needed. ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java From swingler at apple.com Wed Nov 2 10:56:28 2011 From: swingler at apple.com (Mike Swingler) Date: Wed, 02 Nov 2011 10:56:28 -0700 Subject: Using JavaNativeFoundation.framework with embedded OpenJDK7? In-Reply-To: <9FB9DB71-4539-4420-A67D-BB2D13D84960@ultramixer.com> References: <9FB9DB71-4539-4420-A67D-BB2D13D84960@ultramixer.com> Message-ID: <6C0E9B76-EE88-4B9E-BC79-776B29671F10@apple.com> On Nov 2, 2011, at 4:22 AM, Tobias Bley (UltraMixer) wrote: > Hi Mike, > > what's the best way to use your excellent JavaNativeFoundation.framework within a Java Application using a private copy of the OpenJDK7? It wrote a jnilib for accessing Cocoa components but my problem is that this library is linked to /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework. > > So how can I remove this static linking but using JNF? JavaNativeFoundation is only present in /System/Library/Frameworks/JavaVM.framework/Frameworks. There is no private copy in OpenJDK, and OpenJDK itself relies on the version in /System. It's full and proper Mac OS X API - so I'd say don't worry about it. :-) Regards, Mike Swingler Java Engineering Apple Inc. From bino at apple.com Wed Nov 2 11:55:50 2011 From: bino at apple.com (bino at apple.com) Date: Wed, 02 Nov 2011 18:55:50 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fixed MACOSX_PORT-84: Implement java.awt.Desktop Message-ID: <20111102185603.599DC47202@hg.openjdk.java.net> Changeset: 4d08e3657e32 Author: bino at apple.com Date: 2011-11-02 11:54 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/4d08e3657e32 Fixed MACOSX_PORT-84: Implement java.awt.Desktop ! make/sun/lwawt/FILES_c_macosx.gmk ! make/sun/lwawt/FILES_export_macosx.gmk ! src/macosx/classes/sun/lwawt/LWToolkit.java + src/macosx/classes/sun/lwawt/macosx/CDesktopPeer.java + src/macosx/native/sun/awt/CDesktopPeer.m From david.katleman at oracle.com Wed Nov 2 12:37:06 2011 From: david.katleman at oracle.com (David Katleman) Date: Wed, 02 Nov 2011 12:37:06 -0700 Subject: jdk mac 7 ea build b216 has been promoted In-Reply-To: <4EA8937E.6080100@oracle.com> References: <4EA8937E.6080100@oracle.com> Message-ID: <4EB19BE2.5060903@oracle.com> *** Oracle Proprietary/Confidential: For Internal Use Only *** ORIGIN : RE Product : jdk mac Version : 7 Build : ea b216 Date : Wed Nov 2 11:57:15 PDT 2011 Binaries : /java/re/jdk_mac/7/promoted/ea/b216/binaries *Binaries URL : http://jre.us.oracle.com//java/re/jdk_mac/7/promoted/ea/b216/binaries Bundles : /java/re/jdk_mac/7/promoted/ea/b216/bundles Source : /java/re/jdk_mac/7/promoted/ea/b216/ws java -version openjdk version "1.7.0-ea" OpenJDK Runtime Environment (build 1.7.0-ea-b216) OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode) From david.katleman at sun.com Wed Nov 2 12:39:20 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 02 Nov 2011 19:39:20 +0000 Subject: hg: macosx-port/macosx-port: Added tag jdk7-b216 for changeset 4f62490a571c Message-ID: <20111102193920.9B9FC47203@hg.openjdk.java.net> Changeset: 7e0665464c55 Author: katleman Date: 2011-11-02 11:08 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/rev/7e0665464c55 Added tag jdk7-b216 for changeset 4f62490a571c ! .hgtags From david.katleman at sun.com Wed Nov 2 12:39:29 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 02 Nov 2011 19:39:29 +0000 Subject: hg: macosx-port/macosx-port/corba: Added tag jdk7-b216 for changeset 2267482141ce Message-ID: <20111102193929.E294547204@hg.openjdk.java.net> Changeset: f205f3a95def Author: katleman Date: 2011-11-02 11:08 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/corba/rev/f205f3a95def Added tag jdk7-b216 for changeset 2267482141ce ! .hgtags From david.katleman at sun.com Wed Nov 2 12:39:39 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 02 Nov 2011 19:39:39 +0000 Subject: hg: macosx-port/macosx-port/hotspot: Added tag jdk7-b216 for changeset c0bf2b616394 Message-ID: <20111102193941.17C9247205@hg.openjdk.java.net> Changeset: 5f525eeba86f Author: katleman Date: 2011-11-02 11:08 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/5f525eeba86f Added tag jdk7-b216 for changeset c0bf2b616394 ! .hgtags From david.katleman at sun.com Wed Nov 2 12:39:50 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 02 Nov 2011 19:39:50 +0000 Subject: hg: macosx-port/macosx-port/jaxp: Added tag jdk7-b216 for changeset 7665c0b55c39 Message-ID: <20111102193950.6C24647206@hg.openjdk.java.net> Changeset: 34b816af9499 Author: katleman Date: 2011-11-02 11:08 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jaxp/rev/34b816af9499 Added tag jdk7-b216 for changeset 7665c0b55c39 ! .hgtags From david.katleman at sun.com Wed Nov 2 12:39:59 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 02 Nov 2011 19:39:59 +0000 Subject: hg: macosx-port/macosx-port/jaxws: Added tag jdk7-b216 for changeset c5c90bde6acc Message-ID: <20111102193959.0932847207@hg.openjdk.java.net> Changeset: f3046cfe2c95 Author: katleman Date: 2011-11-02 11:08 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jaxws/rev/f3046cfe2c95 Added tag jdk7-b216 for changeset c5c90bde6acc ! .hgtags From david.katleman at sun.com Wed Nov 2 12:40:15 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 02 Nov 2011 19:40:15 +0000 Subject: hg: macosx-port/macosx-port/langtools: Added tag jdk7-b216 for changeset e0466bd86247 Message-ID: <20111102194017.D9F7047208@hg.openjdk.java.net> Changeset: 1633b4dfcb6c Author: katleman Date: 2011-11-02 11:08 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/langtools/rev/1633b4dfcb6c Added tag jdk7-b216 for changeset e0466bd86247 ! .hgtags From tobi at ultramixer.com Thu Nov 3 00:29:38 2011 From: tobi at ultramixer.com (Tobias Bley (UltraMixer)) Date: Thu, 3 Nov 2011 08:29:38 +0100 Subject: Using JavaNativeFoundation.framework with embedded OpenJDK7? In-Reply-To: <6C0E9B76-EE88-4B9E-BC79-776B29671F10@apple.com> References: <9FB9DB71-4539-4420-A67D-BB2D13D84960@ultramixer.com> <6C0E9B76-EE88-4B9E-BC79-776B29671F10@apple.com> Message-ID: <3620D4E8-34C0-431E-A324-0606901DDA66@ultramixer.com> Two more questions: 1. You say "OpenJDK relies on JNF": Does it mean OpenJDK requires the /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework and it doesn't work without it? 2. Why don't you build JNF as "standalone" framework which everbody can include in his Java Application (like Sparkle do)? Or why don't you make a dynamic library for inclusion instead of the current sub framework? Mike, so currently there is no chance to use your JavaNativeFoundation helper classes to build Java Applications uses a bundle OpenJDK jre (for submission in AppStore)? Best regards, Tobi Am 02.11.2011 um 18:56 schrieb Mike Swingler: > On Nov 2, 2011, at 4:22 AM, Tobias Bley (UltraMixer) wrote: > >> Hi Mike, >> >> what's the best way to use your excellent JavaNativeFoundation.framework within a Java Application using a private copy of the OpenJDK7? It wrote a jnilib for accessing Cocoa components but my problem is that this library is linked to /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework. >> >> So how can I remove this static linking but using JNF? > > JavaNativeFoundation is only present in /System/Library/Frameworks/JavaVM.framework/Frameworks. There is no private copy in OpenJDK, and OpenJDK itself relies on the version in /System. It's full and proper Mac OS X API - so I'd say don't worry about it. :-) > > Regards, > Mike Swingler > Java Engineering > Apple Inc. > From sergey.bylokhov at oracle.com Thu Nov 3 01:50:30 2011 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 03 Nov 2011 12:50:30 +0400 Subject: CFV: New Mac OS X Port Committers In-Reply-To: <4EA81FE3.3030405@oracle.com> References: <4EA81FE3.3030405@oracle.com> Message-ID: <4EB255D6.2030505@oracle.com> Vote: YES. 26.10.2011 18:57, Artem Ananiev wrote: > > I hereby nominate the following people to Mac OS X Port Committers: > > Alan Bateman (alanb) > Alexander Potochkin (alexp) > Andrew Brygin (bae) > Dmitry Cherepanov (dcherepanov) > Leonid Romanov (leonidr) > Naoto Sato (naoto) > Phil race (prr) > > Votes are due by November 10, 2011. > > Only currrent Mac OS X Port Committers [1] are eligible to vote on > this nomination. > > For Lazy Consensus voting instructions, see [2] and [3]. > > Thanks, > > Artem > > [1] http://openjdk.java.net/census#macosx-port > [2] http://openjdk.java.net/projects#committer-vote > [3] http://openjdk.java.net/bylaws#lazy-consensus > -- Best regards, Sergey. From sergey.bylokhov at oracle.com Thu Nov 3 03:59:49 2011 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Thu, 03 Nov 2011 10:59:49 +0000 Subject: hg: macosx-port/macosx-port/jdk: Takes into account ScrollbarDisplayPolicy, scrollbars height and width. Message-ID: <20111103105959.A6F6847218@hg.openjdk.java.net> Changeset: e6fc5094bcde Author: serb Date: 2011-11-03 14:59 +0400 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/e6fc5094bcde Takes into account ScrollbarDisplayPolicy, scrollbars height and width. ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java From bino at apple.com Thu Nov 3 10:05:33 2011 From: bino at apple.com (Bino George) Date: Thu, 03 Nov 2011 10:05:33 -0700 Subject: CFV: New Mac OS X Port Committers In-Reply-To: <1E52C270-E442-4A23-A3DE-BAFEA0F601B3@apple.com> References: <4EA81FE3.3030405@oracle.com> <1E52C270-E442-4A23-A3DE-BAFEA0F601B3@apple.com> Message-ID: Vote: YES Regards, Bino George Java Runtime Engineer Apple Inc. On Oct 26, 2011, at 8:01 AM, Mike Swingler wrote: > Vote: YES. > (for all) > > Regards, > Mike Swingler > Java Engineering > Apple Inc. > > On Oct 26, 2011, at 7:57 AM, Artem Ananiev wrote: > >> I hereby nominate the following people to Mac OS X Port Committers: >> >> Alan Bateman (alanb) >> Alexander Potochkin (alexp) >> Andrew Brygin (bae) >> Dmitry Cherepanov (dcherepanov) >> Leonid Romanov (leonidr) >> Naoto Sato (naoto) >> Phil race (prr) >> >> Votes are due by November 10, 2011. >> >> Only currrent Mac OS X Port Committers [1] are eligible to vote on this nomination. >> >> For Lazy Consensus voting instructions, see [2] and [3]. >> >> Thanks, >> >> Artem >> >> [1] http://openjdk.java.net/census#macosx-port >> [2] http://openjdk.java.net/projects#committer-vote >> [3] http://openjdk.java.net/bylaws#lazy-consensus >> > From swingler at apple.com Thu Nov 3 10:13:05 2011 From: swingler at apple.com (Mike Swingler) Date: Thu, 03 Nov 2011 10:13:05 -0700 Subject: Using JavaNativeFoundation.framework with embedded OpenJDK7? In-Reply-To: <3620D4E8-34C0-431E-A324-0606901DDA66@ultramixer.com> References: <9FB9DB71-4539-4420-A67D-BB2D13D84960@ultramixer.com> <6C0E9B76-EE88-4B9E-BC79-776B29671F10@apple.com> <3620D4E8-34C0-431E-A324-0606901DDA66@ultramixer.com> Message-ID: <0C8E1034-FAB1-4987-997B-23C405B7BEDE@apple.com> On Nov 3, 2011, at 12:29 AM, Tobias Bley (UltraMixer) wrote: > Two more questions: > > 1. You say "OpenJDK relies on JNF": Does it mean OpenJDK requires the /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework and it doesn't work without it? That is correct. > 2. Why don't you build JNF as "standalone" framework which everbody can include in his Java Application (like Sparkle do)? Or why don't you make a dynamic library for inclusion instead of the current sub framework? We needed JNF back in 2008 back when we started thinking about how to externalize the helper classes and macros we used in the JDK and related projects. Once it was formally a system framework, it became available for everyone to use. It had not occurred to us that there was a benefit to applications having their own private copy. > Mike, so currently there is no chance to use your JavaNativeFoundation helper classes to build Java Applications uses a bundle OpenJDK jre (for submission in AppStore)? Why not? You shouldn't have any problems by just using the built-in system one. It's system API, just like Foundation and AppKit. The only restriction is instantiating a JVM which is provided by Apple, so as long as you bundle your own, it should work fine. > Best regards, > Tobi > > > > Am 02.11.2011 um 18:56 schrieb Mike Swingler: > >> On Nov 2, 2011, at 4:22 AM, Tobias Bley (UltraMixer) wrote: >> >>> Hi Mike, >>> >>> what's the best way to use your excellent JavaNativeFoundation.framework within a Java Application using a private copy of the OpenJDK7? It wrote a jnilib for accessing Cocoa components but my problem is that this library is linked to /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework. >>> >>> So how can I remove this static linking but using JNF? >> >> JavaNativeFoundation is only present in /System/Library/Frameworks/JavaVM.framework/Frameworks. There is no private copy in OpenJDK, and OpenJDK itself relies on the version in /System. It's full and proper Mac OS X API - so I'd say don't worry about it. :-) Regards, Mike Swingler Java Engineering Apple Inc. From kevin_m_miller at apple.com Thu Nov 3 10:16:26 2011 From: kevin_m_miller at apple.com (Kevin) Date: Thu, 03 Nov 2011 10:16:26 -0700 Subject: CFV: New Mac OS X Port Committers In-Reply-To: <4EA81FE3.3030405@oracle.com> References: <4EA81FE3.3030405@oracle.com> Message-ID: Vote: YES (for all). Regards, Kevin Miller Java Runtime Engineer Apple Inc. On Oct 26, 2011, at 7:57 AM, Artem Ananiev wrote: > > I hereby nominate the following people to Mac OS X Port Committers: > > Alan Bateman (alanb) > Alexander Potochkin (alexp) > Andrew Brygin (bae) > Dmitry Cherepanov (dcherepanov) > Leonid Romanov (leonidr) > Naoto Sato (naoto) > Phil race (prr) > > Votes are due by November 10, 2011. > > Only currrent Mac OS X Port Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2] and [3]. > > Thanks, > > Artem > > [1] http://openjdk.java.net/census#macosx-port > [2] http://openjdk.java.net/projects#committer-vote > [3] http://openjdk.java.net/bylaws#lazy-consensus > From astrange at apple.com Thu Nov 3 11:10:52 2011 From: astrange at apple.com (Alexander Strange) Date: Thu, 03 Nov 2011 14:10:52 -0400 Subject: CFV: New Mac OS X Port Committers In-Reply-To: <4EA81FE3.3030405@oracle.com> References: <4EA81FE3.3030405@oracle.com> Message-ID: Vote: yes On Oct 26, 2011, at 10:57 AM, Artem Ananiev wrote: > > I hereby nominate the following people to Mac OS X Port Committers: > > Alan Bateman (alanb) > Alexander Potochkin (alexp) > Andrew Brygin (bae) > Dmitry Cherepanov (dcherepanov) > Leonid Romanov (leonidr) > Naoto Sato (naoto) > Phil race (prr) > > Votes are due by November 10, 2011. > > Only currrent Mac OS X Port Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2] and [3]. > > Thanks, > > Artem > > [1] http://openjdk.java.net/census#macosx-port > [2] http://openjdk.java.net/projects#committer-vote > [3] http://openjdk.java.net/bylaws#lazy-consensus > From rhoover at apple.com Thu Nov 3 11:21:50 2011 From: rhoover at apple.com (roger hoover) Date: Thu, 03 Nov 2011 12:21:50 -0600 Subject: CFV: New Mac OS X Port Committers In-Reply-To: <4EA81FE3.3030405@oracle.com> References: <4EA81FE3.3030405@oracle.com> Message-ID: <63F3676E-25F6-40DB-AFD2-7FF58C771066@apple.com> Vote: YES. (for all) On Oct 26, 2011, at 8:57 AM, Artem Ananiev wrote: > > I hereby nominate the following people to Mac OS X Port Committers: > > Alan Bateman (alanb) > Alexander Potochkin (alexp) > Andrew Brygin (bae) > Dmitry Cherepanov (dcherepanov) > Leonid Romanov (leonidr) > Naoto Sato (naoto) > Phil race (prr) > > Votes are due by November 10, 2011. > > Only currrent Mac OS X Port Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2] and [3]. > > Thanks, > > Artem > > [1] http://openjdk.java.net/census#macosx-port > [2] http://openjdk.java.net/projects#committer-vote > [3] http://openjdk.java.net/bylaws#lazy-consensus > From kevin_m_miller at apple.com Fri Nov 4 14:53:55 2011 From: kevin_m_miller at apple.com (kevin_m_miller at apple.com) Date: Fri, 04 Nov 2011 21:53:55 +0000 Subject: hg: macosx-port/macosx-port/jdk: Porting window resize indicator for Snow Leopard Message-ID: <20111104215413.EF9B947245@hg.openjdk.java.net> Changeset: 9a5cd4354db9 Author: kevin_m_miller at apple.com Date: 2011-11-04 14:51 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/9a5cd4354db9 Porting window resize indicator for Snow Leopard ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m From swingler at apple.com Fri Nov 4 15:19:50 2011 From: swingler at apple.com (swingler at apple.com) Date: Fri, 04 Nov 2011 22:19:50 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fixing longstanding bug with JTables and the Command key triggering editing Message-ID: <20111104222000.5A39D47246@hg.openjdk.java.net> Changeset: cdb54244ebee Author: swingler at apple.com Date: 2011-11-04 15:19 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/cdb54244ebee Fixing longstanding bug with JTables and the Command key triggering editing ! src/share/classes/javax/swing/JTable.java From kevin_m_miller at apple.com Fri Nov 4 15:49:36 2011 From: kevin_m_miller at apple.com (kevin_m_miller at apple.com) Date: Fri, 04 Nov 2011 22:49:36 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fixing memory management issue in CSystemColors Message-ID: <20111104224946.911D547247@hg.openjdk.java.net> Changeset: 7e6e08242bba Author: kevin_m_miller at apple.com Date: 2011-11-04 15:49 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/7e6e08242bba Fixing memory management issue in CSystemColors ! src/macosx/native/sun/awt/CSystemColors.m From swingler at apple.com Fri Nov 4 18:40:46 2011 From: swingler at apple.com (swingler at apple.com) Date: Sat, 05 Nov 2011 01:40:46 +0000 Subject: hg: macosx-port/macosx-port/jdk: Using system standard artwork on Lion or better for the security lock icon. Message-ID: <20111105014056.9AC9247249@hg.openjdk.java.net> Changeset: 37919dcf3968 Author: swingler at apple.com Date: 2011-11-04 18:40 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/37919dcf3968 Using system standard artwork on Lion or better for the security lock icon. ! src/macosx/classes/apple/laf/JRSUIUtils.java ! src/macosx/classes/com/apple/laf/AquaImageFactory.java From swingler at apple.com Fri Nov 4 19:39:44 2011 From: swingler at apple.com (swingler at apple.com) Date: Sat, 05 Nov 2011 02:39:44 +0000 Subject: hg: macosx-port/macosx-port/jdk: Converting tabs to spaces, per style guidelines. Message-ID: <20111105023954.7366D4724B@hg.openjdk.java.net> Changeset: 8bfcfea69314 Author: swingler at apple.com Date: 2011-11-04 19:39 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/8bfcfea69314 Converting tabs to spaces, per style guidelines. ! src/macosx/classes/apple/laf/JRSUIState.java ! src/macosx/classes/apple/laf/JRSUIUtils.java ! src/macosx/classes/apple/launcher/JavaAppLauncher.java ! src/macosx/classes/com/apple/concurrent/Dispatch.java ! src/macosx/classes/com/apple/concurrent/LibDispatchConcurrentQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchMainQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchNative.java ! src/macosx/classes/com/apple/concurrent/LibDispatchQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchRetainedResource.java ! src/macosx/classes/com/apple/concurrent/LibDispatchSerialQueue.java ! src/macosx/classes/com/apple/eawt/AboutHandler.java ! src/macosx/classes/com/apple/eawt/AppEvent.java ! src/macosx/classes/com/apple/eawt/AppForegroundListener.java ! src/macosx/classes/com/apple/eawt/AppHiddenListener.java ! src/macosx/classes/com/apple/eawt/AppReOpenedListener.java ! src/macosx/classes/com/apple/eawt/Application.java ! src/macosx/classes/com/apple/eawt/ApplicationAdapter.java ! src/macosx/classes/com/apple/eawt/ApplicationBeanInfo.java ! src/macosx/classes/com/apple/eawt/ApplicationEvent.java ! src/macosx/classes/com/apple/eawt/ApplicationListener.java ! src/macosx/classes/com/apple/eawt/OpenFilesHandler.java ! src/macosx/classes/com/apple/eawt/OpenURIHandler.java ! src/macosx/classes/com/apple/eawt/PreferencesHandler.java ! src/macosx/classes/com/apple/eawt/PrintFilesHandler.java ! src/macosx/classes/com/apple/eawt/QuitHandler.java ! src/macosx/classes/com/apple/eawt/QuitResponse.java ! src/macosx/classes/com/apple/eawt/QuitStrategy.java ! src/macosx/classes/com/apple/eawt/ScreenSleepListener.java ! src/macosx/classes/com/apple/eawt/SystemSleepListener.java ! src/macosx/classes/com/apple/eawt/UserSessionListener.java ! src/macosx/classes/com/apple/eawt/_AppDockIconHandler.java ! src/macosx/classes/com/apple/eawt/_AppEventHandler.java ! src/macosx/classes/com/apple/eawt/_AppEventLegacyHandler.java ! src/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java ! src/macosx/classes/com/apple/eawt/_AppMiscHandlers.java ! src/macosx/classes/com/apple/eawt/event/GestureAdapter.java ! src/macosx/classes/com/apple/eawt/event/GestureEvent.java ! src/macosx/classes/com/apple/eawt/event/GestureHandler.java ! src/macosx/classes/com/apple/eawt/event/GesturePhaseEvent.java ! src/macosx/classes/com/apple/eawt/event/GesturePhaseListener.java ! src/macosx/classes/com/apple/eawt/event/GestureUtilities.java ! src/macosx/classes/com/apple/eawt/event/MagnificationEvent.java ! src/macosx/classes/com/apple/eawt/event/MagnificationListener.java ! src/macosx/classes/com/apple/eawt/event/RotationEvent.java ! src/macosx/classes/com/apple/eawt/event/RotationListener.java ! src/macosx/classes/com/apple/eawt/event/SwipeEvent.java ! src/macosx/classes/com/apple/eawt/event/SwipeListener.java ! src/macosx/classes/com/apple/eio/FileManager.java ! src/macosx/classes/com/apple/laf/AquaButtonUI.java ! src/macosx/classes/sun/awt/CGraphicsConfig.java ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/font/CCharToGlyphMapper.java ! src/macosx/classes/sun/font/CFont.java ! src/macosx/classes/sun/font/CFontManager.java ! src/macosx/classes/sun/font/CStrike.java ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java ! src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/macosx/CCheckboxMenuItem.java ! src/macosx/classes/sun/lwawt/macosx/CClipboard.java ! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java ! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/macosx/classes/sun/lwawt/macosx/CFRetainedResource.java ! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/macosx/classes/sun/lwawt/macosx/CocoaConstants.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/com/apple/concurrent/Dispatch.m ! src/macosx/native/com/apple/eio/CFileManager.m ! src/macosx/native/com/apple/laf/ScreenMenu.m ! src/macosx/native/com/sun/media/sound/CARingBuffer.cpp ! src/macosx/native/com/sun/media/sound/CARingBuffer.h ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_PCM.cpp ! src/macosx/native/jobjc/extract_classes.pl ! src/macosx/native/sun/awt/AWTView.h ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/ApplicationDelegate.h ! src/macosx/native/sun/awt/CClipboard.m ! src/macosx/native/sun/awt/CDataTransferer.m ! src/macosx/native/sun/awt/CDragSource.m ! src/macosx/native/sun/awt/CDropTarget.m ! src/macosx/native/sun/awt/DnDUtilities.m ! src/macosx/native/sun/awt/NSApplicationAWT.m ! src/macosx/native/sun/font/AWTStrike.m ! src/macosx/native/sun/font/CCharToGlyphMapper.m ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m From alexander.zuev at oracle.com Mon Nov 7 04:04:03 2011 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Mon, 07 Nov 2011 12:04:03 +0000 Subject: hg: macosx-port/macosx-port/jdk: Takink care of additional mouse buttons (other than left, right and middle), making them behave is if they were middle button (this is how JDK 1.6 treats them). Message-ID: <20111107120422.9BD9747261@hg.openjdk.java.net> Changeset: 0863d2c2b628 Author: leonidr Date: 2011-11-07 16:03 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/0863d2c2b628 Takink care of additional mouse buttons (other than left, right and middle), making them behave is if they were middle button (this is how JDK 1.6 treats them). ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/native/sun/awt/AWTEvent.m From alexander.zuev at oracle.com Mon Nov 7 04:11:59 2011 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Mon, 07 Nov 2011 12:11:59 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fix for MACOSX_PORT-368: UnsupportedOperationException on TrayIcon.dispose() Message-ID: <20111107121209.BA56847262@hg.openjdk.java.net> Changeset: 605dfb5d7cec Author: leonidr Date: 2011-11-07 16:11 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/605dfb5d7cec Fix for MACOSX_PORT-368: UnsupportedOperationException on TrayIcon.dispose() ! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/macosx/native/sun/awt/CTrayIcon.h ! src/macosx/native/sun/awt/CTrayIcon.m From swingler at apple.com Mon Nov 7 07:47:45 2011 From: swingler at apple.com (Mike Swingler) Date: Mon, 07 Nov 2011 07:47:45 -0800 Subject: hg: macosx-port/macosx-port/jdk: Fix for MACOSX_PORT-368: UnsupportedOperationException on TrayIcon.dispose() In-Reply-To: <20111107121209.BA56847262@hg.openjdk.java.net> References: <20111107121209.BA56847262@hg.openjdk.java.net> Message-ID: On Nov 7, 2011, at 4:11 AM, alexander.zuev at oracle.com wrote: > Changeset: 605dfb5d7cec > Author: leonidr > Date: 2011-11-07 16:11 +0300 > URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/605dfb5d7cec > > Fix for MACOSX_PORT-368: UnsupportedOperationException on TrayIcon.dispose() > > ! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java > ! src/macosx/native/sun/awt/CTrayIcon.h > ! src/macosx/native/sun/awt/CTrayIcon.m Why not just have CTrayIcon extend CFRetainedResource, then you don't have to write your own native disposer, and you can specify that the release automatically happen on the AppKit thread so the dispose will happen on the AppKit thread (which it usually won't as the code is currently written). Regards, Mike Swingler Java Engineering Apple Inc. From leonid.romanov at oracle.com Mon Nov 7 07:53:12 2011 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 7 Nov 2011 19:53:12 +0400 Subject: hg: macosx-port/macosx-port/jdk: Fix for MACOSX_PORT-368: UnsupportedOperationException on TrayIcon.dispose() In-Reply-To: References: <20111107121209.BA56847262@hg.openjdk.java.net> Message-ID: <3245910B-0D1D-4855-8128-89548827E7A8@oracle.com> Yep, sounds like a good idea. Thanks! Leonid. On 07.11.2011, at 19:47, Mike Swingler wrote: > On Nov 7, 2011, at 4:11 AM, alexander.zuev at oracle.com wrote: > >> Changeset: 605dfb5d7cec >> Author: leonidr >> Date: 2011-11-07 16:11 +0300 >> URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/605dfb5d7cec >> >> Fix for MACOSX_PORT-368: UnsupportedOperationException on TrayIcon.dispose() >> >> ! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java >> ! src/macosx/native/sun/awt/CTrayIcon.h >> ! src/macosx/native/sun/awt/CTrayIcon.m > > Why not just have CTrayIcon extend CFRetainedResource, then you don't have to write your own native disposer, and you can specify that the release automatically happen on the AppKit thread so the dispose will happen on the AppKit thread (which it usually won't as the code is currently written). > > Regards, > Mike Swingler > Java Engineering > Apple Inc. > From alexander.zuev at oracle.com Mon Nov 7 08:59:59 2011 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Mon, 07 Nov 2011 16:59:59 +0000 Subject: hg: macosx-port/macosx-port/jdk: More optimal CTrayIcon.dispose() implementation. Message-ID: <20111107170025.5557047267@hg.openjdk.java.net> Changeset: 8e5dae99e3d6 Author: leonidr Date: 2011-11-07 20:59 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/8e5dae99e3d6 More optimal CTrayIcon.dispose() implementation. ! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/macosx/native/sun/awt/CTrayIcon.m From alexander.zuev at oracle.com Mon Nov 7 09:17:19 2011 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Mon, 07 Nov 2011 17:17:19 +0000 Subject: hg: macosx-port/macosx-port/jdk: Removing the global ref at CTrayIcon. Message-ID: <20111107171730.1AC7047268@hg.openjdk.java.net> Changeset: 64001bad9a58 Author: leonidr Date: 2011-11-07 21:17 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/64001bad9a58 Removing the global ref at CTrayIcon. ! src/macosx/native/sun/awt/CTrayIcon.m From alexander.zuev at oracle.com Mon Nov 7 10:08:15 2011 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Mon, 07 Nov 2011 18:08:15 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fix for MACOSX_PORT-639: RuntimeErrors setting dock icon with Application.getApplication().setDockIconImage(...) Message-ID: <20111107180834.BD7B14726F@hg.openjdk.java.net> Changeset: 8274d4865707 Author: kizune Date: 2011-11-07 22:08 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/8274d4865707 Fix for MACOSX_PORT-639: RuntimeErrors setting dock icon with Application.getApplication().setDockIconImage(...) ! src/macosx/classes/com/apple/eawt/_AppDockIconHandler.java From frank.kline at gmail.com Mon Nov 7 15:37:20 2011 From: frank.kline at gmail.com (Frank-Robert Kline) Date: Mon, 7 Nov 2011 15:37:20 -0800 Subject: New Java Developer Preview from Apple, new API for OpenJDK Message-ID: Hi Mike, Given the lack of Java support built into Lion, and for the benefit of consistency across installations, we had been planning to simply embed a JRE into our application for distribution to end users. This works well enough on Windows and Linux for Java 7, but from your comments it appears as though the Apple-distributed Java 6 runtime installs API hooks that OpenJDK 7 Mac Port relies on. As we can't be sure that end users have Java installed on Lion: 1. What's the recommended distribution strategy for Java 7 applications on mac? Or, what's the planned recommended distribution strategy? 2. Is there a plan to include these API dependencies in the Mac Port, so that Java applications can continue to embed the JRE for simplicity/consistency? 3. If we continue to embed the JRE, and the potential for an unsatisfied dependency exists - how can we detect it and alert users to install what's needed? Thanks! Frank On Thu, Sep 8, 2011 at 4:46 PM, Mike Swingler wrote: > Hello OpenJDK hackers, > > Today we have posted a new developer preview of "Java for Mac OS X 10.7 > Update 1" and "Java for Mac OS X 10.6 Update 6". We don't normally announce > these previews to the OpenJDK community, but this particular set of builds > have new API introduced to the JavaRuntimeSupport.framework for the benefit > of macosx-port specifically. > > Once you install this preview, you will notice that apps running with the > current macosx-port binaries will now have the correct name in the Dock and > in the menu bar. Also, input methods will be programmatically selectable, > and other app startup properties like "apple.awt.UIElement" will now work, > and various drag-and-drop bugs should be resolved. > > You can download the preview here: > < > https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20920 > > > > Please let us know if you have any issues with the preview at: > > > While we will not require installing this preview for building the > macosx-port, we will ask that you install it if you are running the > binaries and filing bugs at . > The new API changes in this preview will be incorporated into future Apple > software updates shipped to all Mac OS X customers, and we use these > previews to refine the API, find bugs, and ensure we deliver a solid > product for all users of both Apple's Java SE 6 and OpenJDK. > > Thanks for all your help, > Mike Swingler > Java Engineering > Apple Inc. > > From swingler at apple.com Mon Nov 7 17:50:49 2011 From: swingler at apple.com (Mike Swingler) Date: Mon, 07 Nov 2011 17:50:49 -0800 Subject: New Java Developer Preview from Apple, new API for OpenJDK In-Reply-To: References: Message-ID: On Nov 7, 2011, at 3:37 PM, Frank-Robert Kline wrote: > Hi Mike, > > Given the lack of Java support built into Lion, and for the benefit of consistency across installations, we had been planning to simply embed a JRE into our application for distribution to end users. This works well enough on Windows and Linux for Java 7, but from your comments it appears as though the Apple-distributed Java 6 runtime installs API hooks that OpenJDK 7 Mac Port relies on. > > As we can't be sure that end users have Java installed on Lion: > 1. What's the recommended distribution strategy for Java 7 applications on mac? Or, what's the planned recommended distribution strategy? Embed Java 7 into your own app's bundle. > 2. Is there a plan to include these API dependencies in the Mac Port, so that Java applications can continue to embed the JRE for simplicity/consistency? We plan to deliver a future OS software update contains the new API which is currently only available from the Java developer preview. By the definition of what this API is (a cover for internal non-published, externally unsupportable SPI), it cannot be open-sourced, and it cannot be contributed to the Mac Port. Apple takes responsibility for updating the internal implementation of this API to compensate for changes in the lower level SPI. > 3. If we continue to embed the JRE, and the potential for an unsatisfied dependency exists - how can we detect it and alert users to install what's needed? All the dependancies are now soft-linked runtime dependencies. OpenJDK is largely functional without these APIs present, but obviously if you hit something in your testing, your users will either require "Java for Mac OS X 10.7 Update 1", or the forthcoming OS update. Since Java 7 for Mac is not near GA from Oracle at this point, we still have some time to resolve this issue and ensure that Apple's OS software update is available before then. Regards, Mike Swingler Java Engineering Apple Inc. > Thanks! > Frank > > > > > On Thu, Sep 8, 2011 at 4:46 PM, Mike Swingler wrote: > Hello OpenJDK hackers, > > Today we have posted a new developer preview of "Java for Mac OS X 10.7 Update 1" and "Java for Mac OS X 10.6 Update 6". We don't normally announce these previews to the OpenJDK community, but this particular set of builds have new API introduced to the JavaRuntimeSupport.framework for the benefit of macosx-port specifically. > > Once you install this preview, you will notice that apps running with the current macosx-port binaries will now have the correct name in the Dock and in the menu bar. Also, input methods will be programmatically selectable, and other app startup properties like "apple.awt.UIElement" will now work, and various drag-and-drop bugs should be resolved. > > You can download the preview here: > > > Please let us know if you have any issues with the preview at: > > > While we will not require installing this preview for building the macosx-port, we will ask that you install it if you are running the binaries and filing bugs at . The new API changes in this preview will be incorporated into future Apple software updates shipped to all Mac OS X customers, and we use these previews to refine the API, find bugs, and ensure we deliver a solid product for all users of both Apple's Java SE 6 and OpenJDK. > > Thanks for all your help, > Mike Swingler > Java Engineering > Apple Inc. > From andrew.brygin at oracle.com Tue Nov 8 01:36:44 2011 From: andrew.brygin at oracle.com (andrew.brygin at oracle.com) Date: Tue, 08 Nov 2011 09:36:44 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fix for MACOSX_PORT-353: Different instances of the ColorModel Message-ID: <20111108093703.B94844728F@hg.openjdk.java.net> Changeset: 86644aa327aa Author: bae Date: 2011-11-08 12:35 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/86644aa327aa Fix for MACOSX_PORT-353: Different instances of the ColorModel ! src/macosx/classes/sun/awt/CGraphicsConfig.java From artem.ananiev at oracle.com Tue Nov 8 08:00:54 2011 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 08 Nov 2011 20:00:54 +0400 Subject: NSSavePanel access in OpenJDK7 ? In-Reply-To: References: <7F91DC50-E5D1-407F-8B83-32714E14C5BD@ultramixer.com> Message-ID: <4EB95236.2060700@oracle.com> On 10/7/2011 12:38 PM, Harald Kuhr wrote: > > On 6. okt. 2011, at 19:51, Mike Swingler wrote: > >> The AWT FileChooser is already hooked up to the native >> NSSave/OpenPanels. Have you tried them out? > > Has there been any work on the AWT FileChooser API, to allow multiple > selection, folder selection, different modality etc (I know of the > Apple system property that helps with folder selection, but that's > not what I'm looking for here) in (Open)JDK 7? I know there was some > talk about overhauling the AWT FileChooser some time ago, but haven't > seen anything come out of it. Multiple file selection: yes, it's in JDK7 API. It's not implemented yet in Mac OS X port, though :) Folder selection: no. Different modality: it was introduced in JDK6, with all other AWT modality features. However, there is no "sheet" modality type, only "document" and "application". It can be a good candidate for JDK8. > Best regards, Thanks, Artem From swingler at apple.com Tue Nov 8 16:25:54 2011 From: swingler at apple.com (Mike Swingler) Date: Tue, 08 Nov 2011 16:25:54 -0800 Subject: Java for Mac OS X 10.7 Update 1 and 10.6 Update 6 is live Message-ID: Mac OpenJDK developers, The latest Java SE 6 software updates from Apple for both Mac OS X 10.7 and 10.6 are now live and available to all customers via Software Update. If you installed any of the developer previews, running Software Update will automatically bring your system JDK up to date with the GM 1.6.0_29 version, leaving previous developer preview JDKs in-place in /Library/Java/JavaVirtualMachines. As of this update, all of the new API additions to the JavaRuntimeSupport.framework that have previously only been available via the developer previews are now available via this public Java software update. We are still planning a subsequent OS software update that will also contain these API additions, so end users will not have to install Apple's Java to obtain the API required for OpenJDK. Manual download links: Java for Mac OS X 10.7 Update 1: Java for Mac OS X 10.6 Update 6: To additionally install an updated developer JDK which contains src.jar, docs.jar, appledocs.jar, and other documentation, please download the appropriate Java Developer package from ADC: Java for Mac OS X 10.7 Update 1 Developer Package: Java for Mac OS X 10.6 Update 6 Developer Package: The team would like to thank everyone who used the developer previews, filed bugs, and helped us build out the JavaRuntimeSupport.framework for OpenJDK. Our best regards, Mike Swingler Java Engineering Apple Inc. From frank.kline at gmail.com Tue Nov 8 18:15:42 2011 From: frank.kline at gmail.com (Frank-Robert Kline) Date: Tue, 8 Nov 2011 18:15:42 -0800 Subject: Java for Mac OS X 10.7 Update 1 and 10.6 Update 6 is live In-Reply-To: References: Message-ID: Hey Mike, For the manual download links... The 10.6 link still has the old title and subtitle saying "Update 5" even though the description has the proper version listed: http://support.apple.com/kb/DL1360 The Lion link has the incorrect version 1.6.0_26 listed and a July post date (didn't check if it was actually the correct download itself): http://support.apple.com/kb/DL1421 Frank On Tue, Nov 8, 2011 at 4:25 PM, Mike Swingler wrote: > Mac OpenJDK developers, > > The latest Java SE 6 software updates from Apple for both Mac OS X 10.7 > and 10.6 are now live and available to all customers via Software Update. > If you installed any of the developer previews, running Software Update > will automatically bring your system JDK up to date with the GM 1.6.0_29 > version, leaving previous developer preview JDKs in-place in > /Library/Java/JavaVirtualMachines. > > As of this update, all of the new API additions to the > JavaRuntimeSupport.framework that have previously only been available via > the developer previews are now available via this public Java software > update. We are still planning a subsequent OS software update that will > also contain these API additions, so end users will not have to install > Apple's Java to obtain the API required for OpenJDK. > > > Manual download links: > Java for Mac OS X 10.7 Update 1: > Java for Mac OS X 10.6 Update 6: > > To additionally install an updated developer JDK which contains src.jar, > docs.jar, appledocs.jar, and other documentation, please download the > appropriate Java Developer package from ADC: > > Java for Mac OS X 10.7 Update 1 Developer Package: > < > http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20992 > > > Java for Mac OS X 10.6 Update 6 Developer Package: > < > http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20991 > > > > > The team would like to thank everyone who used the developer previews, > filed bugs, and helped us build out the JavaRuntimeSupport.framework for > OpenJDK. > > Our best regards, > Mike Swingler > Java Engineering > Apple Inc. > > From swingler at apple.com Wed Nov 9 09:44:48 2011 From: swingler at apple.com (Mike Swingler) Date: Wed, 09 Nov 2011 09:44:48 -0800 Subject: Java for Mac OS X 10.7 Update 1 and 10.6 Update 6 is live In-Reply-To: References: Message-ID: <47D256C2-7FB7-471D-BF9C-BA2D3E6B067A@apple.com> It's possible you were seeing older cached content. Please check out the links now and see if they haven't been updated. Regards, Mike Swingler Java Engineering Apple Inc. On Nov 8, 2011, at 6:15 PM, Frank-Robert Kline wrote: > Hey Mike, > > For the manual download links... > > The 10.6 link still has the old title and subtitle saying "Update 5" even though the description has the proper version listed: > http://support.apple.com/kb/DL1360 > > The Lion link has the incorrect version 1.6.0_26 listed and a July post date (didn't check if it was actually the correct download itself): > http://support.apple.com/kb/DL1421 > > Frank > > On Tue, Nov 8, 2011 at 4:25 PM, Mike Swingler wrote: > Mac OpenJDK developers, > > The latest Java SE 6 software updates from Apple for both Mac OS X 10.7 and 10.6 are now live and available to all customers via Software Update. If you installed any of the developer previews, running Software Update will automatically bring your system JDK up to date with the GM 1.6.0_29 version, leaving previous developer preview JDKs in-place in /Library/Java/JavaVirtualMachines. > > As of this update, all of the new API additions to the JavaRuntimeSupport.framework that have previously only been available via the developer previews are now available via this public Java software update. We are still planning a subsequent OS software update that will also contain these API additions, so end users will not have to install Apple's Java to obtain the API required for OpenJDK. > > > Manual download links: > Java for Mac OS X 10.7 Update 1: > Java for Mac OS X 10.6 Update 6: > > To additionally install an updated developer JDK which contains src.jar, docs.jar, appledocs.jar, and other documentation, please download the appropriate Java Developer package from ADC: > > Java for Mac OS X 10.7 Update 1 Developer Package: > > Java for Mac OS X 10.6 Update 6 Developer Package: > > > > The team would like to thank everyone who used the developer previews, filed bugs, and helped us build out the JavaRuntimeSupport.framework for OpenJDK. > > Our best regards, > Mike Swingler > Java Engineering > Apple Inc. > > From swingler at apple.com Wed Nov 9 09:45:57 2011 From: swingler at apple.com (Mike Swingler) Date: Wed, 09 Nov 2011 09:45:57 -0800 Subject: Java for Mac OS X 10.7 Update 1 and 10.6 Update 6 is live In-Reply-To: References: Message-ID: <3054D840-1025-4138-BF60-79B7D29ABB4C@apple.com> On Nov 8, 2011, at 4:25 PM, Mike Swingler wrote: > Mac OpenJDK developers, > > The latest Java SE 6 software updates from Apple for both Mac OS X 10.7 and 10.6 are now live and available to all customers via Software Update. If you installed any of the developer previews, running Software Update will automatically bring your system JDK up to date with the GM 1.6.0_29 version, leaving previous developer preview JDKs in-place in /Library/Java/JavaVirtualMachines. > > As of this update, all of the new API additions to the JavaRuntimeSupport.framework that have previously only been available via the developer previews are now available via this public Java software update. We are still planning a subsequent OS software update that will also contain these API additions, so end users will not have to install Apple's Java to obtain the API required for OpenJDK. > > > Manual download links: > Java for Mac OS X 10.7 Update 1: > Java for Mac OS X 10.6 Update 6: > > To additionally install an updated developer JDK which contains src.jar, docs.jar, appledocs.jar, and other documentation, please download the appropriate Java Developer package from ADC: > > Java for Mac OS X 10.7 Update 1 Developer Package: > > Java for Mac OS X 10.6 Update 6 Developer Package: > > > > The team would like to thank everyone who used the developer previews, filed bugs, and helped us build out the JavaRuntimeSupport.framework for OpenJDK. To follow up on this, I've update the prerequisite information at: Regards, Mike Swingler Java Engineering Apple Inc. From loefty at apple.com Wed Nov 9 12:12:34 2011 From: loefty at apple.com (loefty at apple.com) Date: Wed, 09 Nov 2011 20:12:34 +0000 Subject: hg: macosx-port/macosx-port/jdk: Tests from Apple: more in Graphics, Graphics/Primitives Message-ID: <20111109201244.6785F472AF@hg.openjdk.java.net> Changeset: 51f2613bc50f Author: loefty at apple.com Date: 2011-11-09 12:11 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/51f2613bc50f Tests from Apple: more in Graphics, Graphics/Primitives + test/java/awt/Graphics/CustomCompositePositioningTest.java + test/java/awt/Graphics/HexagonTest01.java + test/java/awt/Graphics/InterpolationTest.java + test/java/awt/Graphics/Primitives/DrawRectWithComplexStroke.java + test/java/awt/Graphics/Primitives/FillRoundRect01.java + test/java/awt/Graphics/Primitives/LineAntialiasing01.java + test/java/awt/Graphics/Primitives/NaNPathDrawing.java From david.katleman at oracle.com Wed Nov 9 13:52:50 2011 From: david.katleman at oracle.com (David Katleman) Date: Wed, 09 Nov 2011 13:52:50 -0800 Subject: hdiutil attach behaviour changed with Lion In-Reply-To: <58DAD3DD-09E9-45FC-BD79-7963333FC89D@apple.com> References: <4E95C020.8030007@oracle.com> <58DAD3DD-09E9-45FC-BD79-7963333FC89D@apple.com> Message-ID: <4EBAF632.7090307@oracle.com> Hi Mike! In our .dmg generation script (from Shura), we call hdiutil hdiutil attach ./JDK7.dmg -readwrite -noverify -noidme -mountpoint $mount In 10.6, the above command merrily ran. Our new 10.7 (Lion) build system gives us this message There may be a problem with this disk image. Are you sure you want to open it? [Opening this disk image may make your computer less secure or cause other problems.] Attach? (Y/N) Is there something in Lion or macosx itself I need to configure to avoid this question being asked? Seems to generate a .dmg fine if I answer "Y", but I'd like to avoid the question. Thanks Dave Portion of script to generate .dmg > echo "Generating jdk-7-ea-macosx-${BUILD_NUMBER}.dmg" > rm -rf ./JDK7-MACOSX-PORT.dmg > cp -r ./JDK7-template.dmg ./JDK7.dmg > mount=/tmp/JDK7_IMAGE > rm -rf $mount > mkdir -p $mount > echo "Calling hdiutil..." > hdiutil attach ./JDK7.dmg -readwrite -noverify -noidme -mountpoint $mount > jdk=./JDK > mkdir -p "$mount/JDK 1.7.0 Developer Preview.jdk/Contents" > cp -R $jdk/* "$mount/JDK 1.7.0 Developer Preview.jdk/Contents" > hdiutil detach $mount -quiet -force > dmg=./jdk-7-ea-macosx-${BUILD_NUMBER}.dmg > rm -f $dmg > hdiutil convert ./JDK7.dmg -format UDZO -imagekey zlib-level=9 -o $dmg From david.katleman at oracle.com Wed Nov 9 14:00:55 2011 From: david.katleman at oracle.com (David Katleman) Date: Wed, 09 Nov 2011 14:00:55 -0800 Subject: hdiutil attach behaviour changed with Lion In-Reply-To: <4EBAF632.7090307@oracle.com> References: <4E95C020.8030007@oracle.com> <58DAD3DD-09E9-45FC-BD79-7963333FC89D@apple.com> <4EBAF632.7090307@oracle.com> Message-ID: <4EBAF817.4000901@oracle.com> Nothing like replying to your own query... Adding -quiet shuts it up. Still concerned about config differences between 10.6 and 10.7. Dave On 11/9/2011 1:52 PM, David Katleman wrote: > Hi Mike! > > In our .dmg generation script (from Shura), we call hdiutil > > hdiutil attach ./JDK7.dmg -readwrite -noverify -noidme -mountpoint $mount > > In 10.6, the above command merrily ran. Our new 10.7 (Lion) build > system gives us this message > > There may be a problem with this disk image. Are you sure you want to > open it? > [Opening this disk image may make your computer less secure or cause > other problems.] > Attach? (Y/N) > > Is there something in Lion or macosx itself I need to configure to > avoid this question being asked? > > Seems to generate a .dmg fine if I answer "Y", but I'd like to avoid > the question. > > Thanks > Dave > > Portion of script to generate .dmg >> echo "Generating jdk-7-ea-macosx-${BUILD_NUMBER}.dmg" >> rm -rf ./JDK7-MACOSX-PORT.dmg >> cp -r ./JDK7-template.dmg ./JDK7.dmg >> mount=/tmp/JDK7_IMAGE >> rm -rf $mount >> mkdir -p $mount >> echo "Calling hdiutil..." >> hdiutil attach ./JDK7.dmg -readwrite -noverify -noidme -mountpoint >> $mount >> jdk=./JDK >> mkdir -p "$mount/JDK 1.7.0 Developer Preview.jdk/Contents" >> cp -R $jdk/* "$mount/JDK 1.7.0 Developer Preview.jdk/Contents" >> hdiutil detach $mount -quiet -force >> dmg=./jdk-7-ea-macosx-${BUILD_NUMBER}.dmg >> rm -f $dmg >> hdiutil convert ./JDK7.dmg -format UDZO -imagekey zlib-level=9 -o $dmg From david.katleman at sun.com Wed Nov 9 14:35:27 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 09 Nov 2011 22:35:27 +0000 Subject: hg: macosx-port/macosx-port: Added tag jdk7-b217 for changeset 7e0665464c55 Message-ID: <20111109223528.0A935472B8@hg.openjdk.java.net> Changeset: a3e4c9587247 Author: katleman Date: 2011-11-09 14:26 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/rev/a3e4c9587247 Added tag jdk7-b217 for changeset 7e0665464c55 ! .hgtags From david.katleman at sun.com Wed Nov 9 14:35:36 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 09 Nov 2011 22:35:36 +0000 Subject: hg: macosx-port/macosx-port/corba: Added tag jdk7-b217 for changeset f205f3a95def Message-ID: <20111109223538.07A6C472B9@hg.openjdk.java.net> Changeset: d94a4a9e4094 Author: katleman Date: 2011-11-09 14:26 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/corba/rev/d94a4a9e4094 Added tag jdk7-b217 for changeset f205f3a95def ! .hgtags From david.katleman at sun.com Wed Nov 9 14:35:47 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 09 Nov 2011 22:35:47 +0000 Subject: hg: macosx-port/macosx-port/hotspot: Added tag jdk7-b217 for changeset 5f525eeba86f Message-ID: <20111109223551.BDA31472BA@hg.openjdk.java.net> Changeset: 59d9e6327637 Author: katleman Date: 2011-11-09 14:26 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/59d9e6327637 Added tag jdk7-b217 for changeset 5f525eeba86f ! .hgtags From david.katleman at sun.com Wed Nov 9 14:36:03 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 09 Nov 2011 22:36:03 +0000 Subject: hg: macosx-port/macosx-port/jaxp: Added tag jdk7-b217 for changeset 34b816af9499 Message-ID: <20111109223603.DA634472BB@hg.openjdk.java.net> Changeset: 120b7a15ba54 Author: katleman Date: 2011-11-09 14:26 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jaxp/rev/120b7a15ba54 Added tag jdk7-b217 for changeset 34b816af9499 ! .hgtags From david.katleman at sun.com Wed Nov 9 14:36:12 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 09 Nov 2011 22:36:12 +0000 Subject: hg: macosx-port/macosx-port/jaxws: Added tag jdk7-b217 for changeset f3046cfe2c95 Message-ID: <20111109223612.25A73472BC@hg.openjdk.java.net> Changeset: f79b95e6d1b2 Author: katleman Date: 2011-11-09 14:26 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jaxws/rev/f79b95e6d1b2 Added tag jdk7-b217 for changeset f3046cfe2c95 ! .hgtags From david.katleman at sun.com Wed Nov 9 14:36:22 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 09 Nov 2011 22:36:22 +0000 Subject: hg: macosx-port/macosx-port/jdk: Added tag jdk7-b217 for changeset 51f2613bc50f Message-ID: <20111109223641.F04DD472BD@hg.openjdk.java.net> Changeset: 4b43ec5d2d96 Author: katleman Date: 2011-11-09 14:26 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/4b43ec5d2d96 Added tag jdk7-b217 for changeset 51f2613bc50f ! .hgtags From david.katleman at sun.com Wed Nov 9 14:36:53 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 09 Nov 2011 22:36:53 +0000 Subject: hg: macosx-port/macosx-port/langtools: Added tag jdk7-b217 for changeset 1633b4dfcb6c Message-ID: <20111109223657.7EA37472BE@hg.openjdk.java.net> Changeset: 6d750f52d368 Author: katleman Date: 2011-11-09 14:26 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/langtools/rev/6d750f52d368 Added tag jdk7-b217 for changeset 1633b4dfcb6c ! .hgtags From roger.yeung at oracle.com Wed Nov 9 15:38:07 2011 From: roger.yeung at oracle.com (Roger Yeung) Date: Wed, 09 Nov 2011 15:38:07 -0800 Subject: JDK 7 Mac Port Preview b217 Available Message-ID: <4EBB0EDF.5090408@oracle.com> Hi, The JDK 7 Mac Port Preview b217 is now available: http://jdk7.java.net/macportpreview/ This is the first build with Lion (10.7). Regards, Roger Y. From sundararajan.athijegannathan at oracle.com Wed Nov 9 19:46:11 2011 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Nov 2011 09:16:11 +0530 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: <4EAF76CE.9080907@oracle.com> References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> Message-ID: <4EBB4903.90902@oracle.com> Hi All, We have posted CloseJDK changes to Rhino to java.net site. The Oracle modified Rhino sources can be downloaded from http://jdk7.java.net/rhino/ The jdk7 release notes will be shortly updated to point to the aforementioned URL. Thanks, -Sundar A. Sundararajan wrote: > Hi, > > Yes, we are working on updating the release note to point people to > the CloseJDK Rhino changes. > > Thanks, > -Sundar > > > mark.reinhold at oracle.com wrote: >> 2011/10/31 4:51 -0700, mark at klomp.org: >> >>> This might have slipped through with all the excitement around JavaFX >>> being liberated and all the new JEPs. But it would really help us if >>> you >>> could take a quick peek and point us in the right direction. >>> >>> It would be good for us to make sure we all distribute the same >>> javax.script javascript support, whether it is ClosedJDK, OpenJDK, >>> IcedTea or the MacOSX port. Users probably would like to be sure it is >>> all compatible and supports the same features. >>> >> >> Sundar -- Could you please summarize the changes you made to the Rhino >> code when you last updated the copy used in the Oracle builds? Thanks. >> >> >>> Maybe it is already in the distribution legal notes somewhere, but we >>> looked and cannot find it (maybe we looked in the wrong place). >>> Assuming >>> you are redistributing Rhino under the GPL/MPL there really should at >>> least be a conspicuous notice stating where to find the modifications >>> used to make the binary Oracle is distributing (MPL section 3.6 and/or >>> GPL section 3). >>> >> >> That should be in the Oracle JDK 7 release notes, but I don't see it, >> so I'll ask someone to take care of it. >> >> - Mark >> > > From henri.gomez at gmail.com Thu Nov 10 01:02:49 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 10 Nov 2011 10:02:49 +0100 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: <4EBB4903.90902@oracle.com> References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> <4EBB4903.90902@oracle.com> Message-ID: Very good news. Questions : - Could these CloseJDK changes be used in OpenJDK builds ? - Advices/directions on how to tweak current build to include them ? Cheers 2011/11/10 A. Sundararajan : > Hi All, > > We have posted CloseJDK changes to Rhino to java.net site. ?The Oracle > modified Rhino sources can be downloaded from http://jdk7.java.net/rhino/ > > The jdk7 release notes will be shortly updated to point to the > aforementioned URL. > > Thanks, > -Sundar > > A. Sundararajan wrote: >> >> Hi, >> >> Yes, we are working on updating the release note to point people to the >> CloseJDK Rhino changes. >> >> Thanks, >> -Sundar >> >> >> mark.reinhold at oracle.com wrote: >>> >>> 2011/10/31 4:51 -0700, mark at klomp.org: >>> >>>> >>>> This might have slipped through with all the excitement around JavaFX >>>> being liberated and all the new JEPs. But it would really help us if you >>>> could take a quick peek and point us in the right direction. >>>> >>>> It would be good for us to make sure we all distribute the same >>>> javax.script javascript support, whether it is ClosedJDK, OpenJDK, >>>> IcedTea or the MacOSX port. Users probably would like to be sure it is >>>> all compatible and supports the same features. >>>> >>> >>> Sundar -- Could you please summarize the changes you made to the Rhino >>> code when you last updated the copy used in the Oracle builds? ?Thanks. >>> >>> >>>> >>>> Maybe it is already in the distribution legal notes somewhere, but we >>>> looked and cannot find it (maybe we looked in the wrong place). Assuming >>>> you are redistributing Rhino under the GPL/MPL there really should at >>>> least be a conspicuous notice stating where to find the modifications >>>> used to make the binary Oracle is distributing (MPL section 3.6 and/or >>>> GPL section 3). >>>> >>> >>> That should be in the Oracle JDK 7 release notes, but I don't see it, >>> so I'll ask someone to take care of it. >>> >>> - Mark >>> >> >> > > From sundararajan.athijegannathan at oracle.com Thu Nov 10 08:15:00 2011 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Nov 2011 21:45:00 +0530 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> <4EBB4903.90902@oracle.com> Message-ID: <4EBBF884.1070401@oracle.com> Hi Henri, The sources are self contained - no external dependencies apart from jdk code itself. The "javax.script" API classes and other "com.sun.script" implementation classes are already part of OpenJDK. It should be possible expand contents of src directory under $jdk/src/share/classes and adjust makefiles to add "sun/org" package (pls note that sun/org is the package prefix of the modified Rhino sources). -Sundar Henri Gomez wrote: > Very good news. > > Questions : > > - Could these CloseJDK changes be used in OpenJDK builds ? > - Advices/directions on how to tweak current build to include them ? > > Cheers > > 2011/11/10 A. Sundararajan : > >> Hi All, >> >> We have posted CloseJDK changes to Rhino to java.net site. The Oracle >> modified Rhino sources can be downloaded from http://jdk7.java.net/rhino/ >> >> The jdk7 release notes will be shortly updated to point to the >> aforementioned URL. >> >> Thanks, >> -Sundar >> >> A. Sundararajan wrote: >> >>> Hi, >>> >>> Yes, we are working on updating the release note to point people to the >>> CloseJDK Rhino changes. >>> >>> Thanks, >>> -Sundar >>> >>> >>> mark.reinhold at oracle.com wrote: >>> >>>> 2011/10/31 4:51 -0700, mark at klomp.org: >>>> >>>> >>>>> This might have slipped through with all the excitement around JavaFX >>>>> being liberated and all the new JEPs. But it would really help us if you >>>>> could take a quick peek and point us in the right direction. >>>>> >>>>> It would be good for us to make sure we all distribute the same >>>>> javax.script javascript support, whether it is ClosedJDK, OpenJDK, >>>>> IcedTea or the MacOSX port. Users probably would like to be sure it is >>>>> all compatible and supports the same features. >>>>> >>>>> >>>> Sundar -- Could you please summarize the changes you made to the Rhino >>>> code when you last updated the copy used in the Oracle builds? Thanks. >>>> >>>> >>>> >>>>> Maybe it is already in the distribution legal notes somewhere, but we >>>>> looked and cannot find it (maybe we looked in the wrong place). Assuming >>>>> you are redistributing Rhino under the GPL/MPL there really should at >>>>> least be a conspicuous notice stating where to find the modifications >>>>> used to make the binary Oracle is distributing (MPL section 3.6 and/or >>>>> GPL section 3). >>>>> >>>>> >>>> That should be in the Oracle JDK 7 release notes, but I don't see it, >>>> so I'll ask someone to take care of it. >>>> >>>> - Mark >>>> >>>> >>> >> From sergey.bylokhov at oracle.com Thu Nov 10 08:56:07 2011 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Thu, 10 Nov 2011 16:56:07 +0000 Subject: hg: macosx-port/macosx-port/jdk: MACOSX_PORT-671: Duplicate TextEvent on setText and replaceRange unlike insert; plus an event on initialization Message-ID: <20111110165630.0069F472F1@hg.openjdk.java.net> Changeset: 9ee89397008f Author: serb Date: 2011-11-10 20:55 +0400 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/9ee89397008f MACOSX_PORT-671: Duplicate TextEvent on setText and replaceRange unlike insert; plus an event on initialization MACOSX_PORT-673: TextField.setText() works correct only with repaint() Most of duplicate code in the text peers was merged. ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java From Alexander.Potochkin at oracle.com Thu Nov 10 10:33:32 2011 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 10 Nov 2011 21:33:32 +0300 Subject: NotSerializableException (question for pals from Apple) Message-ID: <4EBC18FC.5030102@oracle.com> Hello I am working on the following bug: http://java.net/jira/browse/MACOSX_PORT-543 I checked that the provided code fails in the official JDK 6 from Apple, does it mean that Aqua ui delegates are not designed to be serializable? Thanks much alexp From swingler at apple.com Thu Nov 10 09:40:53 2011 From: swingler at apple.com (Mike Swingler) Date: Thu, 10 Nov 2011 09:40:53 -0800 Subject: NotSerializableException (question for pals from Apple) In-Reply-To: <4EBC18FC.5030102@oracle.com> References: <4EBC18FC.5030102@oracle.com> Message-ID: On Nov 10, 2011, at 10:33 AM, Alexander Potochkin wrote: > Hello > > I am working on the following bug: > http://java.net/jira/browse/MACOSX_PORT-543 > > I checked that the provided code fails in the official JDK 6 from Apple, > does it mean that Aqua ui delegates are not designed to be serializable? We never focused on making the Aqua UI serializable, outside of what was required by the JCK or customer complaints. I wouldn't surprised if this is broken, but it was not a conscious design decision. Regards, Mike Swingler Java Engineering Apple Inc. From henri.gomez at gmail.com Thu Nov 10 10:27:47 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 10 Nov 2011 19:27:47 +0100 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: <4EBBF884.1070401@oracle.com> References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> <4EBB4903.90902@oracle.com> <4EBBF884.1070401@oracle.com> Message-ID: > Hi Henri, > The sources are self contained - no external dependencies apart from jdk > code itself. ?The "javax.script" API classes and other "com.sun.script" > implementation classes are already part of OpenJDK. ?It should be possible > expand contents of src directory under $jdk/src/share/classes and adjust > makefiles to add "sun/org" package (pls note that sun/org is the package > prefix of the modified Rhino sources). Hello Sundar. Since it still unclear about licence (and including this modified Rhino sources), I'll stick for now with RH way. Everything should works : script support is built into rt.jar testing: com/sun/script/javascript/ExternalScriptable.class OK testing: com/sun/script/javascript/JSAdapter.class OK testing: com/sun/script/javascript/JavaAdapter.class OK testing: com/sun/script/javascript/RhinoClassShutter.class OK testing: com/sun/script/javascript/RhinoCompiledScript.class OK testing: com/sun/script/javascript/RhinoScriptEngine$1.class OK testing: com/sun/script/javascript/RhinoScriptEngine$2.class OK testing: com/sun/script/javascript/RhinoScriptEngine.class OK testing: com/sun/script/javascript/RhinoScriptEngineFactory.class OK testing: com/sun/script/javascript/RhinoTopLevel.class OK testing: com/sun/script/javascript/RhinoWrapFactory$RhinoJavaObject.class OK testing: com/sun/script/javascript/RhinoWrapFactory.class OK testing: com/sun/script/util/BindingsBase.class OK testing: com/sun/script/util/BindingsEntrySet$BindingsEntry.class OK testing: com/sun/script/util/BindingsEntrySet$BindingsIterator.class OK testing: com/sun/script/util/BindingsEntrySet.class OK testing: com/sun/script/util/BindingsImpl.class OK testing: com/sun/script/util/InterfaceImplementor$InterfaceImplementorInvocationHandler$1.class OK testing: com/sun/script/util/InterfaceImplementor$InterfaceImplementorInvocationHandler.class OK testing: com/sun/script/util/InterfaceImplementor.class OK testing: com/sun/script/util/ScriptEngineFactoryBase.class OK Mozilla rhino.jar is also installed under jre/lib (ie: classes renamed) : testing: META-INF/ OK testing: META-INF/MANIFEST.MF OK testing: sun/ OK testing: sun/org/ OK testing: sun/org/mozilla/ OK testing: sun/org/mozilla/classfile/ OK testing: sun/org/mozilla/classfile/ByteCode.class OK testing: sun/org/mozilla/classfile/ClassFileField.class OK testing: sun/org/mozilla/classfile/ClassFileMethod.class OK testing: sun/org/mozilla/classfile/ClassFileWriter$ClassFileFormatException.class OK testing: sun/org/mozilla/classfile/ClassFileWriter$StackMapTable.class OK testing: sun/org/mozilla/classfile/ClassFileWriter.class OK testing: sun/org/mozilla/classfile/ConstantPool.class OK testing: sun/org/mozilla/classfile/ExceptionTableEntry.class OK But jrunscript still complains about missing sun/org/mozilla/javascript/ContextFactory imac-hgomez-exo:workspace henri$ build/macosx-universal/j2sdk-image/1.7.0.jdk/Contents/Home/bin/jrunscript Exception in thread "main" java.lang.NoClassDefFoundError: sun/org/mozilla/javascript/ContextFactory at com.sun.script.javascript.RhinoScriptEngine.(RhinoScriptEngine.java:67) at com.sun.script.javascript.RhinoScriptEngineFactory.getScriptEngine(RhinoScriptEngineFactory.java:74) at javax.script.ScriptEngineManager.getEngineByName(ScriptEngineManager.java:243) at com.sun.tools.script.shell.Main.getScriptEngine(Main.java:411) at com.sun.tools.script.shell.Main.processOptions(Main.java:169) at com.sun.tools.script.shell.Main.main(Main.java:44) strange, os.cpp has been modified to include rhino.jar From henri.gomez at gmail.com Thu Nov 10 11:54:56 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 10 Nov 2011 20:54:56 +0100 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> <4EBB4903.90902@oracle.com> <4EBBF884.1070401@oracle.com> Message-ID: > > imac-hgomez-exo:workspace henri$ > build/macosx-universal/j2sdk-image/1.7.0.jdk/Contents/Home/bin/jrunscript > Exception in thread "main" java.lang.NoClassDefFoundError: > sun/org/mozilla/javascript/ContextFactory > ? ? ? ?at com.sun.script.javascript.RhinoScriptEngine.(RhinoScriptEngine.java:67) > ? ? ? ?at com.sun.script.javascript.RhinoScriptEngineFactory.getScriptEngine(RhinoScriptEngineFactory.java:74) > ? ? ? ?at javax.script.ScriptEngineManager.getEngineByName(ScriptEngineManager.java:243) > ? ? ? ?at com.sun.tools.script.shell.Main.getScriptEngine(Main.java:411) > ? ? ? ?at com.sun.tools.script.shell.Main.processOptions(Main.java:169) > ? ? ? ?at com.sun.tools.script.shell.Main.main(Main.java:44) > > strange, os.cpp has been modified to include rhino.jar Problem fixed, a clean build produced a correct jrunscript : mbp:workspace henri$ build/macosx-universal/j2sdk-image/1.7.0.jdk/Contents/Home/bin/jrunscript js> I'll apply change to my current build script to include rhino support in openjdk-osx-build packages. Stay tuned :) From rhoover at apple.com Thu Nov 10 13:36:37 2011 From: rhoover at apple.com (rhoover at apple.com) Date: Thu, 10 Nov 2011 21:36:37 +0000 Subject: hg: macosx-port/macosx-port/jdk: changes to allow codesigning of jsadebug+jinfo+jmap Message-ID: <20111110213647.CCF8347309@hg.openjdk.java.net> Changeset: d228858028d9 Author: rhoover Date: 2011-11-10 14:36 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/d228858028d9 changes to allow codesigning of jsadebug+jinfo+jmap ! make/common/Program.gmk ! make/launchers/Makefile.launcher + src/solaris/lib/Info-cmdline.plist + src/solaris/lib/Info-privileged.plist From pranav.bhat at oracle.com Thu Nov 10 13:39:55 2011 From: pranav.bhat at oracle.com (pranav bhat) Date: Thu, 10 Nov 2011 16:39:55 -0500 Subject: Fwd: Build fails for osx-port Message-ID: <4EBC44AB.6020907@oracle.com> Hello, I am fairly new to the osx-port for openJDK and I am trying to build; however it fails somewhere in the awt code(/jdk/src/macosx/native/sun/awt/*) .Please find a partial log attached. I am following the instructions on the wiki for every step except for the *bold *part below: make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=*false* ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` OS: 10.6.8 Xcode : 3.6.2 I was previously able to build (around last month) on Xcode 4.2 and OS X Lion. What am I doing wrong? Is some different / special configuration required to build it on snow leopard? Thanks, - Pranav Bhat Here is a snapshot of the log. Let me know if someone needs to see the entire log. From swingler at apple.com Thu Nov 10 14:20:08 2011 From: swingler at apple.com (Mike Swingler) Date: Thu, 10 Nov 2011 14:20:08 -0800 Subject: Build fails for osx-port In-Reply-To: <4EBC44AB.6020907@oracle.com> References: <4EBC44AB.6020907@oracle.com> Message-ID: <40161969-09B7-4514-8D34-CE4CC6A928F7@apple.com> On Nov 10, 2011, at 1:39 PM, pranav bhat wrote: > Hello, > > I am fairly new to the osx-port for openJDK and I am trying to build; however it fails somewhere in the awt code(/jdk/src/macosx/native/sun/awt/*) .Please find a partial log attached. I am following the instructions on the wiki for every step except for the *bold *part below: > > make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=*false* ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` > > OS: 10.6.8 > Xcode : 3.6.2 > > I was previously able to build (around last month) on Xcode 4.2 and OS X Lion. What am I doing wrong? Is some different / special configuration required to build it on snow leopard? Have you installed the "Java for Mac OS X 10.6 Update 6" software update that went live on Tuesday? Be sure you have fully reviewed the prerequisites at: Regards, Mike Swingler Java Engineering Apple Inc. From pranav.bhat at oracle.com Thu Nov 10 14:32:27 2011 From: pranav.bhat at oracle.com (pranav bhat) Date: Thu, 10 Nov 2011 17:32:27 -0500 Subject: Build fails for osx-port In-Reply-To: <40161969-09B7-4514-8D34-CE4CC6A928F7@apple.com> References: <4EBC44AB.6020907@oracle.com> <40161969-09B7-4514-8D34-CE4CC6A928F7@apple.com> Message-ID: <4EBC50FB.9090704@oracle.com> On 11/10/2011 5:20 PM, Mike Swingler wrote: > On Nov 10, 2011, at 1:39 PM, pranav bhat wrote: > >> Hello, >> >> I am fairly new to the osx-port for openJDK and I am trying to build; however it fails somewhere in the awt code(/jdk/src/macosx/native/sun/awt/*) .Please find a partial log attached. I am following the instructions on the wiki for every step except for the *bold *part below: >> >> make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=*false* ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` >> >> OS: 10.6.8 >> Xcode : 3.6.2 >> >> I was previously able to build (around last month) on Xcode 4.2 and OS X Lion. What am I doing wrong? Is some different / special configuration required to build it on snow leopard? > Have you installed the "Java for Mac OS X 10.6 Update 6" software update that went live on Tuesday? > Yes. Java -version gives the following : vegax:~ pranav$ java -version java version "1.6.0_29" Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) vegax:~ pranav$ I believe 1.6.0_29 was the latest one pushed on Tuesday. With respect to other pre-requisites - Snow Leopard Server updated upto 10.6.8 XCode 3.6.2 The only thing I don't have is Jtreg which I don't really need. I wonder the OS being the "server" version makes any difference - does it? Thanks, - Pranav Bhat > Be sure you have fully reviewed the prerequisites at: > > Regards, > Mike Swingler > Java Engineering > Apple Inc. > From henri.gomez at gmail.com Thu Nov 10 14:37:40 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 10 Nov 2011 23:37:40 +0100 Subject: Build fails for osx-port In-Reply-To: <4EBC50FB.9090704@oracle.com> References: <4EBC44AB.6020907@oracle.com> <40161969-09B7-4514-8D34-CE4CC6A928F7@apple.com> <4EBC50FB.9090704@oracle.com> Message-ID: I'm also using 10.6.8, jdk 1.6.0-29 (latest release) and Xcode 4.0.2 What's the error in log ? 2011/11/10 pranav bhat : > > > On 11/10/2011 5:20 PM, Mike Swingler wrote: >> >> On Nov 10, 2011, at 1:39 PM, pranav bhat wrote: >> >>> Hello, >>> >>> I am fairly new to the osx-port for openJDK and I am trying to build; >>> however it fails somewhere in the awt code(/jdk/src/macosx/native/sun/awt/*) >>> .Please find a partial log attached. I am following the instructions on the >>> wiki for every step except for the *bold *part below: >>> >>> make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true >>> ALWAYS_PASS_TEST_GAMMA=*false* ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` >>> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` >>> >>> OS: 10.6.8 >>> Xcode : 3.6.2 >>> >>> I was previously able to build (around last month) on Xcode 4.2 and OS X >>> Lion. What am I doing wrong? Is some different / special configuration >>> required to build it on snow leopard? >> >> Have you installed the "Java for Mac OS X 10.6 Update 6" software update >> that went live on Tuesday? >> > Yes. > Java -version gives the following : > > vegax:~ pranav$ java -version > java version "1.6.0_29" > Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) > Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) > vegax:~ pranav$ > > I believe 1.6.0_29 was the latest one pushed on Tuesday. > > With respect to other pre-requisites - > > Snow Leopard Server updated upto 10.6.8 > XCode 3.6.2 > > The only thing I don't have is Jtreg which I don't really need. I wonder the > OS being the "server" version makes any difference - does it? > > Thanks, > - Pranav Bhat >> >> Be sure you have fully reviewed the prerequisites >> at: >> >> Regards, >> Mike Swingler >> Java Engineering >> Apple Inc. >> > From pranav.bhat at oracle.com Thu Nov 10 14:43:53 2011 From: pranav.bhat at oracle.com (pranav bhat) Date: Thu, 10 Nov 2011 17:43:53 -0500 Subject: Build fails for osx-port In-Reply-To: References: <4EBC44AB.6020907@oracle.com> <40161969-09B7-4514-8D34-CE4CC6A928F7@apple.com> <4EBC50FB.9090704@oracle.com> Message-ID: <4EBC53A9.7090903@oracle.com> Partial log (around the end of the build where it fails attached below). thanks, - Pranav /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt_Application_nativeInitializeApplicationDelegate': /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: (Messages without a matching method signature /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: will be assumed to return 'id' and accept /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: '...' as arguments.) /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeOpenCocoaAboutWindow': /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:540: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeReplyToAppShouldTerminate': /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:558: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockMenu': /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:597: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeGetDockIconImage': /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:640: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockIconBadge': /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:665: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestActivation': /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:687: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestUserAttention': /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' make[4]: *** [library_parallel_compile] Error 2 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [jdk-build] Error 2 make: *** [build_product_image] Error 2 On 11/10/2011 5:37 PM, Henri Gomez wrote: > I'm also using 10.6.8, jdk 1.6.0-29 (latest release) and Xcode 4.0.2 > > What's the error in log ? > > 2011/11/10 pranav bhat: >> >> On 11/10/2011 5:20 PM, Mike Swingler wrote: >>> On Nov 10, 2011, at 1:39 PM, pranav bhat wrote: >>> >>>> Hello, >>>> >>>> I am fairly new to the osx-port for openJDK and I am trying to build; >>>> however it fails somewhere in the awt code(/jdk/src/macosx/native/sun/awt/*) >>>> .Please find a partial log attached. I am following the instructions on the >>>> wiki for every step except for the *bold *part below: >>>> >>>> make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true >>>> ALWAYS_PASS_TEST_GAMMA=*false* ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` >>>> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` >>>> >>>> OS: 10.6.8 >>>> Xcode : 3.6.2 >>>> >>>> I was previously able to build (around last month) on Xcode 4.2 and OS X >>>> Lion. What am I doing wrong? Is some different / special configuration >>>> required to build it on snow leopard? >>> Have you installed the "Java for Mac OS X 10.6 Update 6" software update >>> that went live on Tuesday? >>> >> Yes. >> Java -version gives the following : >> >> vegax:~ pranav$ java -version >> java version "1.6.0_29" >> Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) >> Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) >> vegax:~ pranav$ >> >> I believe 1.6.0_29 was the latest one pushed on Tuesday. >> >> With respect to other pre-requisites - >> >> Snow Leopard Server updated upto 10.6.8 >> XCode 3.6.2 >> >> The only thing I don't have is Jtreg which I don't really need. I wonder the >> OS being the "server" version makes any difference - does it? >> >> Thanks, >> - Pranav Bhat >>> Be sure you have fully reviewed the prerequisites >>> at: >>> >>> Regards, >>> Mike Swingler >>> Java Engineering >>> Apple Inc. >>> From rhoover at apple.com Thu Nov 10 15:03:45 2011 From: rhoover at apple.com (rhoover at apple.com) Date: Thu, 10 Nov 2011 23:03:45 +0000 Subject: hg: macosx-port/macosx-port/jdk: correct macosx search from libhprof.dylib to jvm.hprof.txt Message-ID: <20111110230358.B46B94730A@hg.openjdk.java.net> Changeset: 3837001db71b Author: rhoover Date: 2011-11-10 16:03 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/3837001db71b correct macosx search from libhprof.dylib to jvm.hprof.txt ! src/solaris/demo/jvmti/hprof/hprof_md.c From pranav.bhat at oracle.com Thu Nov 10 15:25:09 2011 From: pranav.bhat at oracle.com (pranav bhat) Date: Thu, 10 Nov 2011 18:25:09 -0500 Subject: Build fails for osx-port In-Reply-To: <4EBC53A9.7090903@oracle.com> References: <4EBC44AB.6020907@oracle.com> <40161969-09B7-4514-8D34-CE4CC6A928F7@apple.com> <4EBC50FB.9090704@oracle.com> <4EBC53A9.7090903@oracle.com> Message-ID: <4EBC5D55.2030306@oracle.com> More information below - Looks like *AWTWindow.h* is where the errors begin. Thanks, - Pranav In file included from /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:32: /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/AWTWindow.h:40: error: expected specifier-qualifier-list before 'JNFWeakJObjectWrapper' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/AWTWindow.h:48: error: expected specifier-qualifier-list before 'JNFWeakJObjectWrapper' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/AWTWindow.h:55: error: expected ')' before 'JNFWeakJObjectWrapper' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m: In function '-[NSApplicationAWT finishLaunching]': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:126: error: 'JNFRunLoopDidStartNotification' undeclared (first use in this function) /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:126: error: (Each undeclared identifier is reported only once /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:126: error: for each function it appears in.) /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m: In function '-[NSApplicationAWT registerWithProcessManager]': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:243: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:243: warning: (Messages without a matching method signature /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:243: warning: will be assumed to return 'id' and accept /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:243: warning: '...' as arguments.) lipo: can't figure out the architecture type of: /var/tmp//cc1bpKKU.out make[5]: *** [/Users/pranav/workspace/workspace/macosx_port/build/macosx-universal/tmp/sun/sun.lwawt/lwawt/obj/NSApplicationAWT.o] Error 1 make[5]: *** Waiting for unfinished jobs.... /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt_Application_nativeInitializeApplicationDelegate': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: (Messages without a matching method signature /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: will be assumed to return 'id' and accept /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: '...' as arguments.) /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeOpenCocoaAboutWindow': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:540: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeReplyToAppShouldTerminate': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:558: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockMenu': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:597: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeGetDockIconImage': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:640: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockIconBadge': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:665: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestActivation': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:687: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestUserAttention': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt_Application_nativeInitializeApplicationDelegate': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: (Messages without a matching method signature /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: will be assumed to return 'id' and accept /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: '...' as arguments.) /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeOpenCocoaAboutWindow': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:540: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeReplyToAppShouldTerminate': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:558: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockMenu': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:597: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeGetDockIconImage': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:640: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockIconBadge': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:665: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestActivation': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:687: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestUserAttention': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' make[4]: *** [library_parallel_compile] Error 2 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [jdk-build] Error 2 make: *** [build_product_image] Error 2 On 11/10/2011 5:43 PM, pranav bhat wrote: > Partial log (around the end of the build where it fails attached below). > > thanks, > - Pranav > > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: > warning: 'JNFRunLoop' may not respond to > '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: > In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: > warning: 'JNFRunLoop' may not respond to > '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: > In function > 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: > warning: 'JNFRunLoop' may not respond to > '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: > In function > 'Java_com_apple_eawt_Application_nativeInitializeApplicationDelegate': > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: > warning: 'JNFRunLoop' may not respond to > '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: > warning: (Messages without a matching method signature > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: > warning: will be assumed to return 'id' and accept > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: > warning: '...' as arguments.) > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: > In function > 'Java_com_apple_eawt__1AppEventHandler_nativeOpenCocoaAboutWindow': > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:540: > warning: 'JNFRunLoop' may not respond to > '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: > In function > 'Java_com_apple_eawt__1AppEventHandler_nativeReplyToAppShouldTerminate': > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:558: > warning: 'JNFRunLoop' may not respond to > '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: > In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockMenu': > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:597: > warning: 'JNFRunLoop' may not respond to > '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: > In function > 'Java_com_apple_eawt__1AppDockIconHandler_nativeGetDockIconImage': > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:640: > warning: 'JNFRunLoop' may not respond to > '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: > In function > 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockIconBadge': > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:665: > warning: 'JNFRunLoop' may not respond to > '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: > In function > 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestActivation': > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:687: > warning: 'JNFRunLoop' may not respond to > '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: > In function > 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestUserAttention': > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: > warning: 'JNFRunLoop' may not respond to > '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: > In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: > warning: 'JNFRunLoop' may not respond to > '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: > In function > 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': > /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: > warning: 'JNFRunLoop' may not respond to > '+performOnMainThreadWaiting:withBlock:' > make[4]: *** [library_parallel_compile] Error 2 > make[3]: *** [all] Error 1 > make[2]: *** [all] Error 1 > make[1]: *** [jdk-build] Error 2 > make: *** [build_product_image] Error 2 > > On 11/10/2011 5:37 PM, Henri Gomez wrote: >> I'm also using 10.6.8, jdk 1.6.0-29 (latest release) and Xcode 4.0.2 >> >> What's the error in log ? >> >> 2011/11/10 pranav bhat: >>> >>> On 11/10/2011 5:20 PM, Mike Swingler wrote: >>>> On Nov 10, 2011, at 1:39 PM, pranav bhat wrote: >>>> >>>>> Hello, >>>>> >>>>> I am fairly new to the osx-port for openJDK and I am trying to build; >>>>> however it fails somewhere in the awt >>>>> code(/jdk/src/macosx/native/sun/awt/*) >>>>> .Please find a partial log attached. I am following the >>>>> instructions on the >>>>> wiki for every step except for the *bold *part below: >>>>> >>>>> make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true >>>>> ALWAYS_PASS_TEST_GAMMA=*false* ALT_BOOTDIR=`/usr/libexec/java_home >>>>> -v 1.6` >>>>> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` >>>>> >>>>> OS: 10.6.8 >>>>> Xcode : 3.6.2 >>>>> >>>>> I was previously able to build (around last month) on Xcode 4.2 >>>>> and OS X >>>>> Lion. What am I doing wrong? Is some different / special >>>>> configuration >>>>> required to build it on snow leopard? >>>> Have you installed the "Java for Mac OS X 10.6 Update 6" software >>>> update >>>> that went live on Tuesday? >>>> >>> Yes. >>> Java -version gives the following : >>> >>> vegax:~ pranav$ java -version >>> java version "1.6.0_29" >>> Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) >>> Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) >>> vegax:~ pranav$ >>> >>> I believe 1.6.0_29 was the latest one pushed on Tuesday. >>> >>> With respect to other pre-requisites - >>> >>> Snow Leopard Server updated upto 10.6.8 >>> XCode 3.6.2 >>> >>> The only thing I don't have is Jtreg which I don't really need. I >>> wonder the >>> OS being the "server" version makes any difference - does it? >>> >>> Thanks, >>> - Pranav Bhat >>>> Be sure you have fully reviewed the prerequisites >>>> at: >>>> >>>> Regards, >>>> Mike Swingler >>>> Java Engineering >>>> Apple Inc. >>>> From swingler at apple.com Thu Nov 10 15:30:56 2011 From: swingler at apple.com (Mike Swingler) Date: Thu, 10 Nov 2011 15:30:56 -0800 Subject: Build fails for osx-port In-Reply-To: <4EBC5D55.2030306@oracle.com> References: <4EBC44AB.6020907@oracle.com> <40161969-09B7-4514-8D34-CE4CC6A928F7@apple.com> <4EBC50FB.9090704@oracle.com> <4EBC53A9.7090903@oracle.com> <4EBC5D55.2030306@oracle.com> Message-ID: <35318A31-1797-46A3-ABC3-47BBFBC10035@apple.com> You must install "Java for Mac OS X 10.6 Update 6" *after* installing Xcode, because Xcode will revert the system headers. Regards, Mike Swingler Java Engineering Apple Inc. On Nov 10, 2011, at 3:25 PM, pranav bhat wrote: > More information below - > > Looks like AWTWindow.h is where the errors begin. > > Thanks, > - Pranav > In file included from /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:32: > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/AWTWindow.h:40: error: expected specifier-qualifier-list before 'JNFWeakJObjectWrapper' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/AWTWindow.h:48: error: expected specifier-qualifier-list before 'JNFWeakJObjectWrapper' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/AWTWindow.h:55: error: expected ')' before 'JNFWeakJObjectWrapper' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m: In function '-[NSApplicationAWT finishLaunching]': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:126: error: 'JNFRunLoopDidStartNotification' undeclared (first use in this function) > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:126: error: (Each undeclared identifier is reported only once > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:126: error: for each function it appears in.) > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m: In function '-[NSApplicationAWT registerWithProcessManager]': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:243: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:243: warning: (Messages without a matching method signature > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:243: warning: will be assumed to return 'id' and accept > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:243: warning: '...' as arguments.) > lipo: can't figure out the architecture type of: /var/tmp//cc1bpKKU.out > make[5]: *** [/Users/pranav/workspace/workspace/macosx_port/build/macosx-universal/tmp/sun/sun.lwawt/lwawt/obj/NSApplicationAWT.o] Error 1 > make[5]: *** Waiting for unfinished jobs.... > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt_Application_nativeInitializeApplicationDelegate': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: (Messages without a matching method signature > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: will be assumed to return 'id' and accept > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: '...' as arguments.) > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeOpenCocoaAboutWindow': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:540: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeReplyToAppShouldTerminate': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:558: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockMenu': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:597: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeGetDockIconImage': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:640: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockIconBadge': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:665: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestActivation': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:687: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestUserAttention': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt_Application_nativeInitializeApplicationDelegate': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: (Messages without a matching method signature > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: will be assumed to return 'id' and accept > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: '...' as arguments.) > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeOpenCocoaAboutWindow': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:540: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeReplyToAppShouldTerminate': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:558: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockMenu': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:597: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeGetDockIconImage': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:640: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockIconBadge': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:665: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestActivation': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:687: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestUserAttention': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': > /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' > make[4]: *** [library_parallel_compile] Error 2 > make[3]: *** [all] Error 1 > make[2]: *** [all] Error 1 > make[1]: *** [jdk-build] Error 2 > make: *** [build_product_image] Error 2 > > > > On 11/10/2011 5:43 PM, pranav bhat wrote: >> >> Partial log (around the end of the build where it fails attached below). >> >> thanks, >> - Pranav >> >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt_Application_nativeInitializeApplicationDelegate': >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: (Messages without a matching method signature >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: will be assumed to return 'id' and accept >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: '...' as arguments.) >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeOpenCocoaAboutWindow': >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:540: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeReplyToAppShouldTerminate': >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:558: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockMenu': >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:597: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeGetDockIconImage': >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:640: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockIconBadge': >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:665: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestActivation': >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:687: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestUserAttention': >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': >> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> make[4]: *** [library_parallel_compile] Error 2 >> make[3]: *** [all] Error 1 >> make[2]: *** [all] Error 1 >> make[1]: *** [jdk-build] Error 2 >> make: *** [build_product_image] Error 2 >> >> On 11/10/2011 5:37 PM, Henri Gomez wrote: >>> I'm also using 10.6.8, jdk 1.6.0-29 (latest release) and Xcode 4.0.2 >>> >>> What's the error in log ? >>> >>> 2011/11/10 pranav bhat: >>>> >>>> On 11/10/2011 5:20 PM, Mike Swingler wrote: >>>>> On Nov 10, 2011, at 1:39 PM, pranav bhat wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I am fairly new to the osx-port for openJDK and I am trying to build; >>>>>> however it fails somewhere in the awt code(/jdk/src/macosx/native/sun/awt/*) >>>>>> .Please find a partial log attached. I am following the instructions on the >>>>>> wiki for every step except for the *bold *part below: >>>>>> >>>>>> make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true >>>>>> ALWAYS_PASS_TEST_GAMMA=*false* ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` >>>>>> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` >>>>>> >>>>>> OS: 10.6.8 >>>>>> Xcode : 3.6.2 >>>>>> >>>>>> I was previously able to build (around last month) on Xcode 4.2 and OS X >>>>>> Lion. What am I doing wrong? Is some different / special configuration >>>>>> required to build it on snow leopard? >>>>> Have you installed the "Java for Mac OS X 10.6 Update 6" software update >>>>> that went live on Tuesday? >>>>> >>>> Yes. >>>> Java -version gives the following : >>>> >>>> vegax:~ pranav$ java -version >>>> java version "1.6.0_29" >>>> Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) >>>> Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) >>>> vegax:~ pranav$ >>>> >>>> I believe 1.6.0_29 was the latest one pushed on Tuesday. >>>> >>>> With respect to other pre-requisites - >>>> >>>> Snow Leopard Server updated upto 10.6.8 >>>> XCode 3.6.2 >>>> >>>> The only thing I don't have is Jtreg which I don't really need. I wonder the >>>> OS being the "server" version makes any difference - does it? >>>> >>>> Thanks, >>>> - Pranav Bhat >>>>> Be sure you have fully reviewed the prerequisites >>>>> at: >>>>> >>>>> Regards, >>>>> Mike Swingler >>>>> Java Engineering >>>>> Apple Inc. >>>>> From bino at apple.com Thu Nov 10 16:14:01 2011 From: bino at apple.com (bino at apple.com) Date: Fri, 11 Nov 2011 00:14:01 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fixed MACOSX_PORT-689: Port eawt Fullscreen API to JDK7 Message-ID: <20111111001412.9686F4730E@hg.openjdk.java.net> Changeset: b93877fb0c3b Author: bino at apple.com Date: 2011-11-10 16:11 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/b93877fb0c3b Fixed MACOSX_PORT-689: Port eawt Fullscreen API to JDK7 ! make/sun/lwawt/FILES_export_macosx.gmk ! src/macosx/classes/com/apple/eawt/AppEvent.java ! src/macosx/classes/com/apple/eawt/Application.java + src/macosx/classes/com/apple/eawt/FullScreenAdapter.java + src/macosx/classes/com/apple/eawt/FullScreenHandler.java + src/macosx/classes/com/apple/eawt/FullScreenListener.java + src/macosx/classes/com/apple/eawt/FullScreenUtilities.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m From swpalmer at gmail.com Thu Nov 10 16:49:56 2011 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 10 Nov 2011 19:49:56 -0500 Subject: JDK 7 Mac Port Preview b217 Available In-Reply-To: <4EBB0EDF.5090408@oracle.com> References: <4EBB0EDF.5090408@oracle.com> Message-ID: On 2011-11-09, at 6:38 PM, Roger Yeung wrote: > Hi, > > The JDK 7 Mac Port Preview b217 is now available: > > http://jdk7.java.net/macportpreview/ > > > This is the first build with Lion (10.7). > > Regards, > Roger Y. i'll ask again? Am I the only one that can't get any GUI code to work with these builds? This and OpenJDK7 fails 100% of the time if you try to launch any Java app with a GUI. Here's a sample stack trace: Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException at java.awt.Window.initGC(Window.java:464) at java.awt.Window.init(Window.java:484) at java.awt.Window.(Window.java:533) at java.awt.Frame.(Frame.java:418) at java.awt.Frame.(Frame.java:383) at javax.swing.JFrame.(JFrame.java:180) at ca.digitalrapids.kayak.gui.KayakDesignerFrame.(KayakDesignerFrame.java:33) at ca.digitalrapids.kayak.gui.KayakGUIUtils._createKayakDesignerFrame(KayakGUIUtils.java:96) at ca.digitalrapids.kayak.gui.KayakGUIUtils.createKayakDesignerFrame(KayakGUIUtils.java:145) at ca.digitalrapids.kayak.KayakMain$1.run(KayakMain.java:63) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) at java.awt.EventQueue.access$000(EventQueue.java:101) at java.awt.EventQueue$3.run(EventQueue.java:666) at java.awt.EventQueue$3.run(EventQueue.java:664) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:240) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:146) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:142) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:134) at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) This has been an issue for months and I don't get why I don't hear anything about it from others. My system isn't "special" in any way. I don't hear about it in any release notes or anything? what's up? Scott From frank.kline at gmail.com Thu Nov 10 16:59:17 2011 From: frank.kline at gmail.com (Frank-Robert Kline) Date: Thu, 10 Nov 2011 16:59:17 -0800 Subject: JDK 7 Mac Port Preview b217 Available In-Reply-To: References: <4EBB0EDF.5090408@oracle.com> Message-ID: I just filed a bug on this - would probably be helpful if you added your system information as well: http://java.net/jira/browse/MACOSX_PORT-688 On Thu, Nov 10, 2011 at 4:49 PM, Scott Palmer wrote: > > On 2011-11-09, at 6:38 PM, Roger Yeung wrote: > > > Hi, > > > > The JDK 7 Mac Port Preview b217 is now available: > > > > http://jdk7.java.net/macportpreview/ > > > > > > This is the first build with Lion (10.7). > > > > Regards, > > Roger Y. > > i'll ask again? Am I the only one that can't get any GUI code to work with > these builds? > This and OpenJDK7 fails 100% of the time if you try to launch any Java app > with a GUI. > > Here's a sample stack trace: > > Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException > at java.awt.Window.initGC(Window.java:464) > at java.awt.Window.init(Window.java:484) > at java.awt.Window.(Window.java:533) > at java.awt.Frame.(Frame.java:418) > at java.awt.Frame.(Frame.java:383) > at javax.swing.JFrame.(JFrame.java:180) > at > ca.digitalrapids.kayak.gui.KayakDesignerFrame.(KayakDesignerFrame.java:33) > at > ca.digitalrapids.kayak.gui.KayakGUIUtils._createKayakDesignerFrame(KayakGUIUtils.java:96) > at > ca.digitalrapids.kayak.gui.KayakGUIUtils.createKayakDesignerFrame(KayakGUIUtils.java:145) > at ca.digitalrapids.kayak.KayakMain$1.run(KayakMain.java:63) > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) > at java.awt.EventQueue.access$000(EventQueue.java:101) > at java.awt.EventQueue$3.run(EventQueue.java:666) > at java.awt.EventQueue$3.run(EventQueue.java:664) > at java.security.AccessController.doPrivileged(Native Method) > at > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) > at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:240) > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:157) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:146) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:142) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:134) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) > > > This has been an issue for months and I don't get why I don't hear > anything about it from others. My system isn't "special" in any way. > > I don't hear about it in any release notes or anything? what's up? > > Scott > > From swpalmer at gmail.com Thu Nov 10 17:10:52 2011 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 10 Nov 2011 20:10:52 -0500 Subject: JDK 7 Mac Port Preview b217 Available In-Reply-To: References: <4EBB0EDF.5090408@oracle.com> Message-ID: <2138098D-60AF-4197-8DAC-044D5DE9A6E2@gmail.com> I filed a bug about this as well.. months ago (July 30th, 2011). http://java.net/jira/browse/MACOSX_PORT-203 Glad to see that at least one person can reproduce it. I just don't understand how anyone can be testing all the AquaUI porting stuff on a daily basis when you can't even run a GUI app! Scott On 2011-11-10, at 7:59 PM, Frank-Robert Kline wrote: > I just filed a bug on this - would probably be helpful if you added your system information as well: > http://java.net/jira/browse/MACOSX_PORT-688 > > On Thu, Nov 10, 2011 at 4:49 PM, Scott Palmer wrote: > > On 2011-11-09, at 6:38 PM, Roger Yeung wrote: > > > Hi, > > > > The JDK 7 Mac Port Preview b217 is now available: > > > > http://jdk7.java.net/macportpreview/ > > > > > > This is the first build with Lion (10.7). > > > > Regards, > > Roger Y. > > i'll ask again? Am I the only one that can't get any GUI code to work with these builds? > This and OpenJDK7 fails 100% of the time if you try to launch any Java app with a GUI. > > Here's a sample stack trace: > > Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException > at java.awt.Window.initGC(Window.java:464) > at java.awt.Window.init(Window.java:484) > at java.awt.Window.(Window.java:533) > at java.awt.Frame.(Frame.java:418) > at java.awt.Frame.(Frame.java:383) > at javax.swing.JFrame.(JFrame.java:180) > at ca.digitalrapids.kayak.gui.KayakDesignerFrame.(KayakDesignerFrame.java:33) > at ca.digitalrapids.kayak.gui.KayakGUIUtils._createKayakDesignerFrame(KayakGUIUtils.java:96) > at ca.digitalrapids.kayak.gui.KayakGUIUtils.createKayakDesignerFrame(KayakGUIUtils.java:145) > at ca.digitalrapids.kayak.KayakMain$1.run(KayakMain.java:63) > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) > at java.awt.EventQueue.access$000(EventQueue.java:101) > at java.awt.EventQueue$3.run(EventQueue.java:666) > at java.awt.EventQueue$3.run(EventQueue.java:664) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:240) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:157) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:146) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:142) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:134) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) > > > This has been an issue for months and I don't get why I don't hear anything about it from others. My system isn't "special" in any way. > > I don't hear about it in any release notes or anything? what's up? > > Scott > > From frank.kline at gmail.com Thu Nov 10 18:16:28 2011 From: frank.kline at gmail.com (Frank-Robert Kline) Date: Thu, 10 Nov 2011 18:16:28 -0800 Subject: JDK 7 Mac Port Preview b217 Available In-Reply-To: <2138098D-60AF-4197-8DAC-044D5DE9A6E2@gmail.com> References: <4EBB0EDF.5090408@oracle.com> <2138098D-60AF-4197-8DAC-044D5DE9A6E2@gmail.com> Message-ID: This was actually only one out of a handful of macs I've tested that showed this issue; however it's immediately showstopping when it appears as you can't start a gui app. Thanks for the link to the older issue, missed that when searching. On Thu, Nov 10, 2011 at 5:10 PM, Scott Palmer wrote: > I filed a bug about this as well.. months ago (July 30th, 2011). > > http://java.net/jira/browse/MACOSX_PORT-203 > > Glad to see that at least one person can reproduce it. I just don't > understand how anyone can be testing all the AquaUI porting stuff on a > daily basis when you can't even run a GUI app! > > Scott > > On 2011-11-10, at 7:59 PM, Frank-Robert Kline wrote: > > I just filed a bug on this - would probably be helpful if you added your > system information as well: > http://java.net/jira/browse/MACOSX_PORT-688 > > On Thu, Nov 10, 2011 at 4:49 PM, Scott Palmer wrote: > >> >> On 2011-11-09, at 6:38 PM, Roger Yeung wrote: >> >> > Hi, >> > >> > The JDK 7 Mac Port Preview b217 is now available: >> > >> > http://jdk7.java.net/macportpreview/ >> > >> > >> > This is the first build with Lion (10.7). >> > >> > Regards, >> > Roger Y. >> >> i'll ask again? Am I the only one that can't get any GUI code to work >> with these builds? >> This and OpenJDK7 fails 100% of the time if you try to launch any Java >> app with a GUI. >> >> Here's a sample stack trace: >> >> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException >> at java.awt.Window.initGC(Window.java:464) >> at java.awt.Window.init(Window.java:484) >> at java.awt.Window.(Window.java:533) >> at java.awt.Frame.(Frame.java:418) >> at java.awt.Frame.(Frame.java:383) >> at javax.swing.JFrame.(JFrame.java:180) >> at >> ca.digitalrapids.kayak.gui.KayakDesignerFrame.(KayakDesignerFrame.java:33) >> at >> ca.digitalrapids.kayak.gui.KayakGUIUtils._createKayakDesignerFrame(KayakGUIUtils.java:96) >> at >> ca.digitalrapids.kayak.gui.KayakGUIUtils.createKayakDesignerFrame(KayakGUIUtils.java:145) >> at ca.digitalrapids.kayak.KayakMain$1.run(KayakMain.java:63) >> at >> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) >> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) >> at java.awt.EventQueue.access$000(EventQueue.java:101) >> at java.awt.EventQueue$3.run(EventQueue.java:666) >> at java.awt.EventQueue$3.run(EventQueue.java:664) >> at java.security.AccessController.doPrivileged(Native Method) >> at >> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) >> at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) >> at >> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:240) >> at >> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:157) >> at >> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:146) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:142) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:134) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) >> >> >> This has been an issue for months and I don't get why I don't hear >> anything about it from others. My system isn't "special" in any way. >> >> I don't hear about it in any release notes or anything? what's up? >> >> Scott >> >> > > From swpalmer at gmail.com Thu Nov 10 18:58:56 2011 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 10 Nov 2011 21:58:56 -0500 Subject: JDK 7 Mac Port Preview b217 Available In-Reply-To: References: <4EBB0EDF.5090408@oracle.com> <2138098D-60AF-4197-8DAC-044D5DE9A6E2@gmail.com> Message-ID: Interesting.. I wonder what these failing machines have in common? My machine specs: 15-inch MacBook Pro (Mid 2010) 15-inch (1680 x 1050) Processor 2.53 GHz Intel Core i5 Memory 8 GB 1067 MHz DDR3 Graphics Intel HD Graphics 288 MB Software Mac OS X Lion 10.7.2 (11C74) $ /usr/libexec/java_home -v1.7 --exec java -version openjdk version "1.7.0-ea" OpenJDK Runtime Environment (build 1.7.0-ea-b217) OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode) As I mentioned in the bug report. It fails 100% of the time and always has. Scott On 2011-11-10, at 9:16 PM, Frank-Robert Kline wrote: > This was actually only one out of a handful of macs I've tested that showed this issue; however it's immediately showstopping when it appears as you can't start a gui app. > > Thanks for the link to the older issue, missed that when searching. > > On Thu, Nov 10, 2011 at 5:10 PM, Scott Palmer wrote: > I filed a bug about this as well.. months ago (July 30th, 2011). > > http://java.net/jira/browse/MACOSX_PORT-203 > > Glad to see that at least one person can reproduce it. I just don't understand how anyone can be testing all the AquaUI porting stuff on a daily basis when you can't even run a GUI app! > > Scott > > On 2011-11-10, at 7:59 PM, Frank-Robert Kline wrote: > >> I just filed a bug on this - would probably be helpful if you added your system information as well: >> http://java.net/jira/browse/MACOSX_PORT-688 >> >> On Thu, Nov 10, 2011 at 4:49 PM, Scott Palmer wrote: >> >> On 2011-11-09, at 6:38 PM, Roger Yeung wrote: >> >> > Hi, >> > >> > The JDK 7 Mac Port Preview b217 is now available: >> > >> > http://jdk7.java.net/macportpreview/ >> > >> > >> > This is the first build with Lion (10.7). >> > >> > Regards, >> > Roger Y. >> >> i'll ask again? Am I the only one that can't get any GUI code to work with these builds? >> This and OpenJDK7 fails 100% of the time if you try to launch any Java app with a GUI. >> >> Here's a sample stack trace: >> >> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException >> at java.awt.Window.initGC(Window.java:464) >> at java.awt.Window.init(Window.java:484) >> at java.awt.Window.(Window.java:533) >> at java.awt.Frame.(Frame.java:418) >> at java.awt.Frame.(Frame.java:383) >> at javax.swing.JFrame.(JFrame.java:180) >> at ca.digitalrapids.kayak.gui.KayakDesignerFrame.(KayakDesignerFrame.java:33) >> at ca.digitalrapids.kayak.gui.KayakGUIUtils._createKayakDesignerFrame(KayakGUIUtils.java:96) >> at ca.digitalrapids.kayak.gui.KayakGUIUtils.createKayakDesignerFrame(KayakGUIUtils.java:145) >> at ca.digitalrapids.kayak.KayakMain$1.run(KayakMain.java:63) >> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) >> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) >> at java.awt.EventQueue.access$000(EventQueue.java:101) >> at java.awt.EventQueue$3.run(EventQueue.java:666) >> at java.awt.EventQueue$3.run(EventQueue.java:664) >> at java.security.AccessController.doPrivileged(Native Method) >> at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) >> at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) >> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:240) >> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:157) >> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:146) >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:142) >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:134) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) >> >> >> This has been an issue for months and I don't get why I don't hear anything about it from others. My system isn't "special" in any way. >> >> I don't hear about it in any release notes or anything? what's up? >> >> Scott >> >> > > From frank.kline at gmail.com Thu Nov 10 19:32:32 2011 From: frank.kline at gmail.com (Frank-Robert Kline) Date: Thu, 10 Nov 2011 19:32:32 -0800 Subject: JDK 7 Mac Port Preview b217 Available In-Reply-To: References: <4EBB0EDF.5090408@oracle.com> <2138098D-60AF-4197-8DAC-044D5DE9A6E2@gmail.com> Message-ID: Fails 100% of the time on this machine as well. I posted this information to http://java.net/jira/browse/MACOSX_PORT-688 for future reference: - Brand new Mac Book Pro - Lion 10.7.2 - Java for OS X Lion Update 1 has been installed from http://support.apple.com/kb/DL1421 - OpenJDK 1.7.0-b216-20111104 Hardware Overview: Model Name: MacBook Pro Model Identifier: MacBookPro8,2 Processor Name: Intel Core i7 Processor Speed: 2.2 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 6 MB Memory: 4 GB There were 2 graphics entries in System Information: AMD Radeon HD 6750M: Chipset Model: AMD Radeon HD 6750M Type: GPU Bus: PCIe PCIe Lane Width: x8 VRAM (Total): 512 MB Vendor: ATI (0x1002) Device ID: 0x6741 Revision ID: 0x0000 ROM Revision: 113-C0170L-573 gMux Version: 1.9.23 EFI Driver Version: 01.00.573 Intel HD Graphics 3000: Chipset Model: Intel HD Graphics 3000 Type: GPU Bus: Built-In VRAM (Total): 384 MB Vendor: Intel (0x8086) Device ID: 0x0116 Revision ID: 0x0009 gMux Version: 1.9.23 Displays: Color LCD: Resolution: 1440 x 900 Pixel Depth: 32-Bit Color (ARGB8888) Main Display: Yes Mirror: Off Online: Yes Built-In: Yes On Thu, Nov 10, 2011 at 6:58 PM, Scott Palmer wrote: > Interesting.. I wonder what these failing machines have in common? > > My machine specs: > 15-inch MacBook Pro (Mid 2010) > 15-inch (1680 x 1050) > Processor 2.53 GHz Intel Core i5 > Memory 8 GB 1067 MHz DDR3 > Graphics Intel HD Graphics 288 MB > Software Mac OS X Lion 10.7.2 (11C74) > > $ /usr/libexec/java_home -v1.7 --exec java -version > openjdk version "1.7.0-ea" > OpenJDK Runtime Environment (build 1.7.0-ea-b217) > OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode) > > As I mentioned in the bug report. It fails 100% of the time and always > has. > > Scott > > > On 2011-11-10, at 9:16 PM, Frank-Robert Kline wrote: > > > This was actually only one out of a handful of macs I've tested that > showed this issue; however it's immediately showstopping when it appears as > you can't start a gui app. > > > > Thanks for the link to the older issue, missed that when searching. > > > > On Thu, Nov 10, 2011 at 5:10 PM, Scott Palmer > wrote: > > I filed a bug about this as well.. months ago (July 30th, 2011). > > > > http://java.net/jira/browse/MACOSX_PORT-203 > > > > Glad to see that at least one person can reproduce it. I just don't > understand how anyone can be testing all the AquaUI porting stuff on a > daily basis when you can't even run a GUI app! > > > > Scott > > > > On 2011-11-10, at 7:59 PM, Frank-Robert Kline wrote: > > > >> I just filed a bug on this - would probably be helpful if you added > your system information as well: > >> http://java.net/jira/browse/MACOSX_PORT-688 > >> > >> On Thu, Nov 10, 2011 at 4:49 PM, Scott Palmer > wrote: > >> > >> On 2011-11-09, at 6:38 PM, Roger Yeung wrote: > >> > >> > Hi, > >> > > >> > The JDK 7 Mac Port Preview b217 is now available: > >> > > >> > http://jdk7.java.net/macportpreview/ > >> > > >> > > >> > This is the first build with Lion (10.7). > >> > > >> > Regards, > >> > Roger Y. > >> > >> i'll ask again? Am I the only one that can't get any GUI code to work > with these builds? > >> This and OpenJDK7 fails 100% of the time if you try to launch any Java > app with a GUI. > >> > >> Here's a sample stack trace: > >> > >> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException > >> at java.awt.Window.initGC(Window.java:464) > >> at java.awt.Window.init(Window.java:484) > >> at java.awt.Window.(Window.java:533) > >> at java.awt.Frame.(Frame.java:418) > >> at java.awt.Frame.(Frame.java:383) > >> at javax.swing.JFrame.(JFrame.java:180) > >> at > ca.digitalrapids.kayak.gui.KayakDesignerFrame.(KayakDesignerFrame.java:33) > >> at > ca.digitalrapids.kayak.gui.KayakGUIUtils._createKayakDesignerFrame(KayakGUIUtils.java:96) > >> at > ca.digitalrapids.kayak.gui.KayakGUIUtils.createKayakDesignerFrame(KayakGUIUtils.java:145) > >> at ca.digitalrapids.kayak.KayakMain$1.run(KayakMain.java:63) > >> at > java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) > >> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) > >> at java.awt.EventQueue.access$000(EventQueue.java:101) > >> at java.awt.EventQueue$3.run(EventQueue.java:666) > >> at java.awt.EventQueue$3.run(EventQueue.java:664) > >> at java.security.AccessController.doPrivileged(Native Method) > >> at > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) > >> at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) > >> at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:240) > >> at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:157) > >> at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:146) > >> at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:142) > >> at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:134) > >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) > >> > >> > >> This has been an issue for months and I don't get why I don't hear > anything about it from others. My system isn't "special" in any way. > >> > >> I don't hear about it in any release notes or anything? what's up? > >> > >> Scott > >> > >> > > > > > > From rhoover at apple.com Thu Nov 10 20:49:02 2011 From: rhoover at apple.com (rhoover at apple.com) Date: Fri, 11 Nov 2011 04:49:02 +0000 Subject: hg: macosx-port/macosx-port/jdk: added unavailable functions for Java_com_sun_management_UnixOperatingSystem_getProcessCpuLoad and Java_com_sun_management_UnixOperatingSystem_getSystemCpuLoad on macosx Message-ID: <20111111044912.4A26C4730F@hg.openjdk.java.net> Changeset: 8daaf03e35b7 Author: rhoover Date: 2011-11-10 21:48 -0700 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/8daaf03e35b7 added unavailable functions for Java_com_sun_management_UnixOperatingSystem_getProcessCpuLoad and Java_com_sun_management_UnixOperatingSystem_getSystemCpuLoad on macosx ! make/java/management/Makefile + src/solaris/native/com/sun/management/MacosxOperatingSystem.c From artem.ananiev at oracle.com Fri Nov 11 01:51:38 2011 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 11 Nov 2011 13:51:38 +0400 Subject: JDK 7 Mac Port Preview b217 Available In-Reply-To: <2138098D-60AF-4197-8DAC-044D5DE9A6E2@gmail.com> References: <4EBB0EDF.5090408@oracle.com> <2138098D-60AF-4197-8DAC-044D5DE9A6E2@gmail.com> Message-ID: <4EBCF02A.2090101@oracle.com> On 11/11/2011 5:10 AM, Scott Palmer wrote: > I filed a bug about this as well.. months ago (July 30th, 2011). > > http://java.net/jira/browse/MACOSX_PORT-203 > > Glad to see that at least one person can reproduce it. I just don't understand how anyone can be testing all the AquaUI porting stuff on a daily basis when you can't even run a GUI app! Development team at Oracle can't reproduce #203 on our hardware, that's why it's still open... I've closed #688 as duplicate of #203 and at the same time raised #203 priority to Critical. Thanks, Artem > Scott > > On 2011-11-10, at 7:59 PM, Frank-Robert Kline wrote: > >> I just filed a bug on this - would probably be helpful if you added your system information as well: >> http://java.net/jira/browse/MACOSX_PORT-688 >> >> On Thu, Nov 10, 2011 at 4:49 PM, Scott Palmer wrote: >> >> On 2011-11-09, at 6:38 PM, Roger Yeung wrote: >> >>> Hi, >>> >>> The JDK 7 Mac Port Preview b217 is now available: >>> >>> http://jdk7.java.net/macportpreview/ >>> >>> >>> This is the first build with Lion (10.7). >>> >>> Regards, >>> Roger Y. >> >> i'll ask again? Am I the only one that can't get any GUI code to work with these builds? >> This and OpenJDK7 fails 100% of the time if you try to launch any Java app with a GUI. >> >> Here's a sample stack trace: >> >> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException >> at java.awt.Window.initGC(Window.java:464) >> at java.awt.Window.init(Window.java:484) >> at java.awt.Window.(Window.java:533) >> at java.awt.Frame.(Frame.java:418) >> at java.awt.Frame.(Frame.java:383) >> at javax.swing.JFrame.(JFrame.java:180) >> at ca.digitalrapids.kayak.gui.KayakDesignerFrame.(KayakDesignerFrame.java:33) >> at ca.digitalrapids.kayak.gui.KayakGUIUtils._createKayakDesignerFrame(KayakGUIUtils.java:96) >> at ca.digitalrapids.kayak.gui.KayakGUIUtils.createKayakDesignerFrame(KayakGUIUtils.java:145) >> at ca.digitalrapids.kayak.KayakMain$1.run(KayakMain.java:63) >> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) >> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) >> at java.awt.EventQueue.access$000(EventQueue.java:101) >> at java.awt.EventQueue$3.run(EventQueue.java:666) >> at java.awt.EventQueue$3.run(EventQueue.java:664) >> at java.security.AccessController.doPrivileged(Native Method) >> at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) >> at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) >> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:240) >> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:157) >> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:146) >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:142) >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:134) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) >> >> >> This has been an issue for months and I don't get why I don't hear anything about it from others. My system isn't "special" in any way. >> >> I don't hear about it in any release notes or anything? what's up? >> >> Scott >> >> > From Alexander.Potochkin at oracle.com Fri Nov 11 03:18:06 2011 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Fri, 11 Nov 2011 14:18:06 +0300 Subject: NotSerializableException (question for pals from Apple) In-Reply-To: References: <4EBC18FC.5030102@oracle.com> Message-ID: <4EBD046E.8080603@oracle.com> Hello Mike > On Nov 10, 2011, at 10:33 AM, Alexander Potochkin wrote: > >> Hello >> >> I am working on the following bug: >> http://java.net/jira/browse/MACOSX_PORT-543 >> >> I checked that the provided code fails in the official JDK 6 from Apple, >> does it mean that Aqua ui delegates are not designed to be serializable? > We never focused on making the Aqua UI serializable, outside of what was required by the JCK or customer complaints. I wouldn't surprised if this is broken, but it was not a conscious design decision. I see Thanks! alexp > > Regards, > Mike Swingler > Java Engineering > Apple Inc. > From steve.mcleod at gmail.com Fri Nov 11 02:29:48 2011 From: steve.mcleod at gmail.com (Steve McLeod) Date: Fri, 11 Nov 2011 11:29:48 +0100 Subject: JDK 7 Mac Port Preview b217 Available Message-ID: I had this problem some weeks ago but now I don't...I can't offer an explanation I'm afraid. It is mystifying. > Here's a sample stack trace: > > Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException > at java.awt.Window.initGC(Window.java:464) > at java.awt.Window.init(Window.java:484) > at java.awt.Window.(Window.java:533) > at java.awt.Frame.(Frame.java:418) > at java.awt.Frame.(Frame.java:383) > at javax.swing.JFrame.(JFrame.java:180) > at ca.digitalrapids.kayak.gui.KayakDesignerFrame.(KayakDesignerFrame.java:33) > at ca.digitalrapids.kayak.gui.KayakGUIUtils._createKayakDesignerFrame(KayakGUIUtils.java:96) > at ca.digitalrapids.kayak.gui.KayakGUIUtils.createKayakDesignerFrame(KayakGUIUtils.java:145) > at ca.digitalrapids.kayak.KayakMain$1.run(KayakMain.java:63) > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) > at java.awt.EventQueue.access$000(EventQueue.java:101) > at java.awt.EventQueue$3.run(EventQueue.java:666) > at java.awt.EventQueue$3.run(EventQueue.java:664) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:240) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:157) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:146) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:142) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:134) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) > From mik3hall at gmail.com Fri Nov 11 02:45:17 2011 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 11 Nov 2011 04:45:17 -0600 Subject: NotSerializableException (question for pals from Apple) In-Reply-To: <4EBD046E.8080603@oracle.com> References: <4EBC18FC.5030102@oracle.com> <4EBD046E.8080603@oracle.com> Message-ID: On Nov 11, 2011, at 5:18 AM, Alexander Potochkin wrote: > Hello Mike >> On Nov 10, 2011, at 10:33 AM, Alexander Potochkin wrote: >> >>> Hello >>> >>> I am working on the following bug: >>> http://java.net/jira/browse/MACOSX_PORT-543 >>> >>> I checked that the provided code fails in the official JDK 6 from Apple, >>> does it mean that Aqua ui delegates are not designed to be serializable? >> We never focused on making the Aqua UI serializable, outside of what was required by the JCK or customer complaints. I wouldn't surprised if this is broken, but it was not a conscious design decision. > > I see If I'm understanding this correctly is there any serializable L&F other than metal? I didn't think so. I did come up something for Aqua at one point for my own application. It relied on my own Object input/output streams. It tried to substitute constructable instances of the classes that couldn't be serializable. Basically on the deserialize if it encountered one of these blueprint substitutes it would try to construct a new instance according to it's specs. It got into having to bypass access restrictions at times to access object state to properly construct new instances with correctly set fields. Sometimes of non-public api Apple classes. it was a little difficult to come up with correct substitute versions sometimes. It was easily breakable. Change the ui a little bit and new classes became involved in serialization that I hadn't addressed. It was also very vulnerable to breaking if any of the underlying non-public API classes changed. Very possible. I thought if you really analyzed the Swing interfaces you could determine the proper places to do the needed substitutions that wouldn't involve getting into the tricky private API's. This could also work to make any L&F effectively serializable. I never followed through on that though. From dalibor.topic at oracle.com Fri Nov 11 03:47:26 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 11 Nov 2011 12:47:26 +0100 Subject: Rhino build support In-Reply-To: References: Message-ID: <4EBD0B4E.2050403@oracle.com> On 10/17/11 7:06 PM, Henri Gomez wrote: > 1) Did there is any reason why Rhino is not included in bsd-port (and > so macosx-port) like licence problems ? Rhino is not necessary for OpenJDK to build & run, so it doesn't really belong in the OpenJDK code base. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 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 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Fri Nov 11 03:48:44 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 11 Nov 2011 12:48:44 +0100 Subject: Rhino on bsd-port/osx-port OpenJDK 7 In-Reply-To: References: <4E539643.2070301@oracle.com> <4E539EF4.5070607@oracle.com> <4E53AAAB.9030700@oracle.com> <4E54ED99.7090001@oracle.com> Message-ID: <4EBD0B9C.2050902@oracle.com> On 10/10/11 7:33 PM, Henri Gomez wrote: > 2011/10/10 Henri Gomez : >> Question about Rhino included in JDK 7. >> >> Do you know version of Rhino from Mozilla.org used ? > > Readme reports 1.7R3 > > > But digging in js.jar from Rhino 1.7R3, I could see 443 classes > whereas jdk 1.7.0 for Linux came with 316 classes > See README.TXT. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 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 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From alexander.potochkin at sun.com Fri Nov 11 07:16:04 2011 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Fri, 11 Nov 2011 15:16:04 +0000 Subject: hg: macosx-port/macosx-port/jdk: fixed #576: Scrollbar displays incorrectly in ContainerTest0001 Message-ID: <20111111151614.CFCFE47318@hg.openjdk.java.net> Changeset: a7e13f33b3e1 Author: alexp Date: 2011-11-11 18:36 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/a7e13f33b3e1 fixed #576: Scrollbar displays incorrectly in ContainerTest0001 ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java From henri.gomez at gmail.com Fri Nov 11 07:55:41 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 11 Nov 2011 16:55:41 +0100 Subject: Rhino on bsd-port/osx-port OpenJDK 7 In-Reply-To: <4EBD0B9C.2050902@oracle.com> References: <4E539643.2070301@oracle.com> <4E539EF4.5070607@oracle.com> <4E53AAAB.9030700@oracle.com> <4E54ED99.7090001@oracle.com> <4EBD0B9C.2050902@oracle.com> Message-ID: >> But digging in js.jar from Rhino 1.7R3, I could see 443 classes >> whereas jdk 1.7.0 for Linux came with 316 classes >> > > See README.TXT. There is a mention in THIRD_PARTY_README : %% This notice is provided with respect to Mozilla Rhino v1.7R3, which is included with JRE 7, JDK 7, and OpenJDK 7 Mozilla Rhino is included in JRE/JDK and OpenJDK 7. It's now included in latest openjdk-osx-build packages From henri.gomez at gmail.com Fri Nov 11 07:56:49 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 11 Nov 2011 16:56:49 +0100 Subject: Rhino build support In-Reply-To: <4EBD0B4E.2050403@oracle.com> References: <4EBD0B4E.2050403@oracle.com> Message-ID: > Rhino is not necessary for OpenJDK to build & run, so it doesn't really > belong in the OpenJDK code base. jrunscript require it (and is built in OpenJDK 7). And Mozilla Rhino is mentioned to be included also. From vanjab at icetec.biz Fri Nov 11 08:01:23 2011 From: vanjab at icetec.biz (Bucic Vanja) Date: Fri, 11 Nov 2011 11:01:23 -0500 Subject: JDK 7 Mac Port Preview b217 Available In-Reply-To: References: Message-ID: <0CE6EC20-A8B4-401C-805D-C72571C070DF@icetec.biz> Has anybody tried to use Netbeans? Any and all things that have to do with font rendering fail (draw a blank). (see img below) All the previews are behaving that way. Latest Lion Model Name: Mac Pro Model Identifier: MacPro1,1 Processor Name: Dual-Core Intel Xeon Processor Speed: 2.66 GHz Number of Processors: 2 Total Number of Cores: 4 L2 Cache (per Processor): 4 MB Memory: 7 GB Bus Speed: 1.33 GHz Boot ROM Version: MP11.005C.B08 SMC Version (system): 1.7f10 On Nov 11, 2011, at 5:29 AM, Steve McLeod wrote: > I had this problem some weeks ago but now I don't...I can't offer an > explanation I'm afraid. It is mystifying. > >> Here's a sample stack trace: >> >> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException >> at java.awt.Window.initGC(Window.java:464) >> at java.awt.Window.init(Window.java:484) >> at java.awt.Window.(Window.java:533) >> at java.awt.Frame.(Frame.java:418) >> at java.awt.Frame.(Frame.java:383) >> at javax.swing.JFrame.(JFrame.java:180) >> at ca.digitalrapids.kayak.gui.KayakDesignerFrame.(KayakDesignerFrame.java:33) >> at ca.digitalrapids.kayak.gui.KayakGUIUtils._createKayakDesignerFrame(KayakGUIUtils.java:96) >> at ca.digitalrapids.kayak.gui.KayakGUIUtils.createKayakDesignerFrame(KayakGUIUtils.java:145) >> at ca.digitalrapids.kayak.KayakMain$1.run(KayakMain.java:63) >> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) >> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) >> at java.awt.EventQueue.access$000(EventQueue.java:101) >> at java.awt.EventQueue$3.run(EventQueue.java:666) >> at java.awt.EventQueue$3.run(EventQueue.java:664) >> at java.security.AccessController.doPrivileged(Native Method) >> at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) >> at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) >> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:240) >> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:157) >> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:146) >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:142) >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:134) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) >> From frank.kline at gmail.com Fri Nov 11 08:11:39 2011 From: frank.kline at gmail.com (Frank-Robert Kline) Date: Fri, 11 Nov 2011 08:11:39 -0800 Subject: JDK 7 Mac Port Preview b217 Available In-Reply-To: References: Message-ID: Actually, I might have figured it out a bit more. The MacBook Pro I see this on can switch between integrated graphics and the Radeon video card. By default, in System Preferences > Energy Saver, Automatic Graphics Switching is enabled by default, causing the Intel integrated graphics to be selected as active. When the integrated graphics is active, I can reproduce this issue. When I uncheck Automated Graphics Switching, the Radeon video card becomes active (you can see which graphics device is active in System Information) and this issue goes away. Scott - maybe you could try switching off Automated Graphics Switching in System Preferences > Energy Saver and see if this issue goes away? On Fri, Nov 11, 2011 at 2:29 AM, Steve McLeod wrote: > I had this problem some weeks ago but now I don't...I can't offer an > explanation I'm afraid. It is mystifying. > > > Here's a sample stack trace: > > > > Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException > > at java.awt.Window.initGC(Window.java:464) > > at java.awt.Window.init(Window.java:484) > > at java.awt.Window.(Window.java:533) > > at java.awt.Frame.(Frame.java:418) > > at java.awt.Frame.(Frame.java:383) > > at javax.swing.JFrame.(JFrame.java:180) > > at > ca.digitalrapids.kayak.gui.KayakDesignerFrame.(KayakDesignerFrame.java:33) > > at > ca.digitalrapids.kayak.gui.KayakGUIUtils._createKayakDesignerFrame(KayakGUIUtils.java:96) > > at > ca.digitalrapids.kayak.gui.KayakGUIUtils.createKayakDesignerFrame(KayakGUIUtils.java:145) > > at ca.digitalrapids.kayak.KayakMain$1.run(KayakMain.java:63) > > at > java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) > > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) > > at java.awt.EventQueue.access$000(EventQueue.java:101) > > at java.awt.EventQueue$3.run(EventQueue.java:666) > > at java.awt.EventQueue$3.run(EventQueue.java:664) > > at java.security.AccessController.doPrivileged(Native Method) > > at > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) > > at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:240) > > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:157) > > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:146) > > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:142) > > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:134) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) > > > From alexander.potochkin at sun.com Fri Nov 11 09:11:07 2011 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Fri, 11 Nov 2011 17:11:07 +0000 Subject: hg: macosx-port/macosx-port/jdk: fixed #486: add/replace functionality do not work for ListTests in JCK-runtime-7 interactive Message-ID: <20111111171117.CE3DD47319@hg.openjdk.java.net> Changeset: 2246c06d2b9e Author: alexp Date: 2011-11-11 20:31 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/2246c06d2b9e fixed #486: add/replace functionality do not work for ListTests in JCK-runtime-7 interactive ! src/macosx/classes/sun/lwawt/LWListPeer.java From pranav.bhat at oracle.com Fri Nov 11 22:01:53 2011 From: pranav.bhat at oracle.com (pranav bhat) Date: Sat, 12 Nov 2011 01:01:53 -0500 Subject: Build fails for osx-port In-Reply-To: <35318A31-1797-46A3-ABC3-47BBFBC10035@apple.com> References: <4EBC44AB.6020907@oracle.com> <40161969-09B7-4514-8D34-CE4CC6A928F7@apple.com> <4EBC50FB.9090704@oracle.com> <4EBC53A9.7090903@oracle.com> <4EBC5D55.2030306@oracle.com> <35318A31-1797-46A3-ABC3-47BBFBC10035@apple.com> Message-ID: <4EBE0BD1.5000002@oracle.com> On 11/10/2011 6:30 PM, Mike Swingler wrote: > You must install "Java for Mac OS X 10.6 Update 6" *after* installing > Xcode, because Xcode will revert the system headers. > > That helped. Thanks! :-) - Pranav > Regards, > Mike Swingler > Java Engineering > Apple Inc. > > On Nov 10, 2011, at 3:25 PM, pranav bhat wrote: > >> More information below - >> >> Looks like *AWTWindow.h* is where the errors begin. >> >> Thanks, >> - Pranav >> In file included from /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:32: >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/AWTWindow.h:40: error: expected specifier-qualifier-list before 'JNFWeakJObjectWrapper' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/AWTWindow.h:48: error: expected specifier-qualifier-list before 'JNFWeakJObjectWrapper' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/AWTWindow.h:55: error: expected ')' before 'JNFWeakJObjectWrapper' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m: In function '-[NSApplicationAWT finishLaunching]': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:126: error: 'JNFRunLoopDidStartNotification' undeclared (first use in this function) >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:126: error: (Each undeclared identifier is reported only once >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:126: error: for each function it appears in.) >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m: In function '-[NSApplicationAWT registerWithProcessManager]': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:243: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:243: warning: (Messages without a matching method signature >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:243: warning: will be assumed to return 'id' and accept >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/NSApplicationAWT.m:243: warning: '...' as arguments.) >> lipo: can't figure out the architecture type of: /var/tmp//cc1bpKKU.out >> make[5]: *** [/Users/pranav/workspace/workspace/macosx_port/build/macosx-universal/tmp/sun/sun.lwawt/lwawt/obj/NSApplicationAWT.o] Error 1 >> make[5]: *** Waiting for unfinished jobs.... >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt_Application_nativeInitializeApplicationDelegate': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: (Messages without a matching method signature >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: will be assumed to return 'id' and accept >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: '...' as arguments.) >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeOpenCocoaAboutWindow': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:540: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeReplyToAppShouldTerminate': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:558: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockMenu': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:597: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeGetDockIconImage': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:640: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockIconBadge': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:665: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestActivation': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:687: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestUserAttention': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt_Application_nativeInitializeApplicationDelegate': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: (Messages without a matching method signature >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: will be assumed to return 'id' and accept >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: warning: '...' as arguments.) >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeOpenCocoaAboutWindow': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:540: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppEventHandler_nativeReplyToAppShouldTerminate': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:558: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockMenu': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:597: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeGetDockIconImage': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:640: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockIconBadge': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:665: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestActivation': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:687: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestUserAttention': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: In function 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': >> /Users/pranav/workspace/workspace/macosx_port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: warning: 'JNFRunLoop' may not respond to '+performOnMainThreadWaiting:withBlock:' >> make[4]: *** [library_parallel_compile] Error 2 >> make[3]: *** [all] Error 1 >> make[2]: *** [all] Error 1 >> make[1]: *** [jdk-build] Error 2 >> make: *** [build_product_image] Error 2 >> >> >> >> On 11/10/2011 5:43 PM, pranav bhat wrote: >>> Partial log (around the end of the build where it fails attached >>> below). >>> >>> thanks, >>> - Pranav >>> >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: >>> warning: 'JNFRunLoop' may not respond to >>> '+performOnMainThreadWaiting:withBlock:' >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: >>> In function >>> 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: >>> warning: 'JNFRunLoop' may not respond to >>> '+performOnMainThreadWaiting:withBlock:' >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: >>> In function >>> 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: >>> warning: 'JNFRunLoop' may not respond to >>> '+performOnMainThreadWaiting:withBlock:' >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: >>> In function >>> 'Java_com_apple_eawt_Application_nativeInitializeApplicationDelegate': >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: >>> warning: 'JNFRunLoop' may not respond to >>> '+performOnMainThreadWaiting:withBlock:' >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: >>> warning: (Messages without a matching method signature >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: >>> warning: will be assumed to return 'id' and accept >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:523: >>> warning: '...' as arguments.) >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: >>> In function >>> 'Java_com_apple_eawt__1AppEventHandler_nativeOpenCocoaAboutWindow': >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:540: >>> warning: 'JNFRunLoop' may not respond to >>> '+performOnMainThreadWaiting:withBlock:' >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: >>> In function >>> 'Java_com_apple_eawt__1AppEventHandler_nativeReplyToAppShouldTerminate': >>> >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:558: >>> warning: 'JNFRunLoop' may not respond to >>> '+performOnMainThreadWaiting:withBlock:' >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: >>> In function >>> 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockMenu': >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:597: >>> warning: 'JNFRunLoop' may not respond to >>> '+performOnMainThreadWaiting:withBlock:' >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: >>> In function >>> 'Java_com_apple_eawt__1AppDockIconHandler_nativeGetDockIconImage': >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:640: >>> warning: 'JNFRunLoop' may not respond to >>> '+performOnMainThreadWaiting:withBlock:' >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: >>> In function >>> 'Java_com_apple_eawt__1AppDockIconHandler_nativeSetDockIconBadge': >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:665: >>> warning: 'JNFRunLoop' may not respond to >>> '+performOnMainThreadWaiting:withBlock:' >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: >>> In function >>> 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestActivation': >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:687: >>> warning: 'JNFRunLoop' may not respond to >>> '+performOnMainThreadWaiting:withBlock:' >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: >>> In function >>> 'Java_com_apple_eawt__1AppMiscHandlers_nativeRequestUserAttention': >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:707: >>> warning: 'JNFRunLoop' may not respond to >>> '+performOnMainThreadWaiting:withBlock:' >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: >>> In function >>> 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState': >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:786: >>> warning: 'JNFRunLoop' may not respond to >>> '+performOnMainThreadWaiting:withBlock:' >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m: >>> In function >>> 'Java_com_apple_eawt__1AppMenuBarHandler_nativeSetDefaultMenuBar': >>> /Users/pranav/workspace/osx-port/macosx-port/jdk/src/macosx/native/sun/awt/ApplicationDelegate.m:806: >>> warning: 'JNFRunLoop' may not respond to >>> '+performOnMainThreadWaiting:withBlock:' >>> make[4]: *** [library_parallel_compile] Error 2 >>> make[3]: *** [all] Error 1 >>> make[2]: *** [all] Error 1 >>> make[1]: *** [jdk-build] Error 2 >>> make: *** [build_product_image] Error 2 >>> >>> On 11/10/2011 5:37 PM, Henri Gomez wrote: >>>> I'm also using 10.6.8, jdk 1.6.0-29 (latest release) and Xcode 4.0.2 >>>> >>>> What's the error in log ? >>>> >>>> 2011/11/10 pranav bhat: >>>>> >>>>> On 11/10/2011 5:20 PM, Mike Swingler wrote: >>>>>> On Nov 10, 2011, at 1:39 PM, pranav bhat wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am fairly new to the osx-port for openJDK and I am trying to >>>>>>> build; >>>>>>> however it fails somewhere in the awt >>>>>>> code(/jdk/src/macosx/native/sun/awt/*) >>>>>>> .Please find a partial log attached. I am following the >>>>>>> instructions on the >>>>>>> wiki for every step except for the *bold *part below: >>>>>>> >>>>>>> make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true >>>>>>> ALWAYS_PASS_TEST_GAMMA=*false* >>>>>>> ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` >>>>>>> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` >>>>>>> >>>>>>> OS: 10.6.8 >>>>>>> Xcode : 3.6.2 >>>>>>> >>>>>>> I was previously able to build (around last month) on Xcode 4.2 >>>>>>> and OS X >>>>>>> Lion. What am I doing wrong? Is some different / special >>>>>>> configuration >>>>>>> required to build it on snow leopard? >>>>>> Have you installed the "Java for Mac OS X 10.6 Update 6" software >>>>>> update >>>>>> that went live on Tuesday? >>>>>> >>>>> Yes. >>>>> Java -version gives the following : >>>>> >>>>> vegax:~ pranav$ java -version >>>>> java version "1.6.0_29" >>>>> Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) >>>>> vegax:~ pranav$ >>>>> >>>>> I believe 1.6.0_29 was the latest one pushed on Tuesday. >>>>> >>>>> With respect to other pre-requisites - >>>>> >>>>> Snow Leopard Server updated upto 10.6.8 >>>>> XCode 3.6.2 >>>>> >>>>> The only thing I don't have is Jtreg which I don't really need. I >>>>> wonder the >>>>> OS being the "server" version makes any difference - does it? >>>>> >>>>> Thanks, >>>>> - Pranav Bhat >>>>>> Be sure you have fully reviewed the prerequisites >>>>>> at: >>>>>> >>>>>> >>>>>> Regards, >>>>>> Mike Swingler >>>>>> Java Engineering >>>>>> Apple Inc. >>>>>> > From alexander.zuev at oracle.com Mon Nov 14 06:54:29 2011 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Mon, 14 Nov 2011 14:54:29 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fix for issue MACOSX_PORT-621: Robot.keyPress(alt), robot.keyPress(letter) doesn't properly work on Mac without a delay Message-ID: <20111114145453.CD21B47357@hg.openjdk.java.net> Changeset: 048edd7100b7 Author: leonidr Date: 2011-11-14 18:54 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/048edd7100b7 Fix for issue MACOSX_PORT-621: Robot.keyPress(alt), robot.keyPress(letter) doesn't properly work on Mac without a delay ! src/macosx/native/sun/awt/CRobot.m From alexander.potochkin at sun.com Mon Nov 14 09:48:51 2011 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Mon, 14 Nov 2011 17:48:51 +0000 Subject: hg: macosx-port/macosx-port/jdk: fixed #626: JSpinner.setFont doesn't change JSpinner.getEditor().getTextField().getFont() Message-ID: <20111114174903.84F4A4735B@hg.openjdk.java.net> Changeset: 020c0565d156 Author: alexp Date: 2011-11-14 21:09 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/020c0565d156 fixed #626: JSpinner.setFont doesn't change JSpinner.getEditor().getTextField().getFont() ! src/macosx/classes/com/apple/laf/AquaSpinnerUI.java From mik3hall at gmail.com Mon Nov 14 15:02:57 2011 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 14 Nov 2011 17:02:57 -0600 Subject: hprof broke? Message-ID: <90308C9E-5ABC-4681-A58A-63F75EE8A0E8@gmail.com> If I'm looking at this issue MACOSX_PORT-179 correctly. hprof should work now? I just got this though... ava -Djava.security.manager -Djava.security.policy=/Users/mjh/all.policy -Dapp=CommandWrap.app -agentlib:hprof=heap=sites -Dconsole=pane -Dapple.laf.useScreenMenuBar=true -Djruby.home=/Volumes/mbvol/jruby-1.6.0.RC3 -cp halfpipe.jar:/Volumes/mbvol/jruby-1.6.0.RC3/lib/jruby.jar:/Volumes/mbvol/rhino1_7R3/js.jar org.cmdline.CommandLine HPROF ERROR: Can't open /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/jvm.hprof.txt [hprof_io.c:736] HPROF TERMINATED PROCESS From mik3hall at gmail.com Mon Nov 14 15:26:20 2011 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 14 Nov 2011 17:26:20 -0600 Subject: hprof broke? In-Reply-To: <90308C9E-5ABC-4681-A58A-63F75EE8A0E8@gmail.com> References: <90308C9E-5ABC-4681-A58A-63F75EE8A0E8@gmail.com> Message-ID: Sorry for following up on my own but after doing a 'locate' cp /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/lib/jvm.hprof.txt /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/jvm.hprof.txt localhost:~ mjh$ java -Djava.security.manager -Djava.security.policy=/Users/mjh/all.policy -Dapp=CommandWrap.app -agentlib:hprof=heap=sites -Dconsole=pane -Dapple.laf.useScreenMenuBar=true -Djruby.home=/Volumes/mbvol/jruby-1.6.0.RC3 -cp halfpipe.jar:/Volumes/mbvol/jruby-1.6.0.RC3/lib/jruby.jar:/Volumes/mbvol/rhino1_7R3/js.jar org.cmdline.CommandLine Error: Could not find or load main class org.cmdline.CommandLine Dumping allocation sites ... done. Yeah, I was in the wrong directory to begin with. It appears jvm.hprof.txt is too? s/b jre/lib? From daniel.daugherty at oracle.com Mon Nov 14 15:35:03 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 14 Nov 2011 16:35:03 -0700 Subject: hprof broke? In-Reply-To: References: <90308C9E-5ABC-4681-A58A-63F75EE8A0E8@gmail.com> Message-ID: <4EC1A5A7.1080207@oracle.com> The jvm.hprof.txt file should live in $JAVA_HOME/jre/lib/jvm.hprof.txt. I believe that the attached changeset from Roger fixes the issue. Dan On 11/14/11 4:26 PM, Michael Hall wrote: > Sorry for following up on my own but after doing a 'locate' > > cp /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/lib/jvm.hprof.txt /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/jvm.hprof.txt > > localhost:~ mjh$ java -Djava.security.manager -Djava.security.policy=/Users/mjh/all.policy -Dapp=CommandWrap.app -agentlib:hprof=heap=sites -Dconsole=pane -Dapple.laf.useScreenMenuBar=true -Djruby.home=/Volumes/mbvol/jruby-1.6.0.RC3 -cp halfpipe.jar:/Volumes/mbvol/jruby-1.6.0.RC3/lib/jruby.jar:/Volumes/mbvol/rhino1_7R3/js.jar org.cmdline.CommandLine > > Error: Could not find or load main class org.cmdline.CommandLine > > Dumping allocation sites ... done. > > Yeah, I was in the wrong directory to begin with. It appears jvm.hprof.txt is too? s/b jre/lib? From mik3hall at gmail.com Mon Nov 14 15:43:48 2011 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 14 Nov 2011 17:43:48 -0600 Subject: hprof broke? In-Reply-To: <4EC1A5A7.1080207@oracle.com> References: <90308C9E-5ABC-4681-A58A-63F75EE8A0E8@gmail.com> <4EC1A5A7.1080207@oracle.com> Message-ID: Ah, sorry, missed how recent the resolution was. I'll look for it in the next developer preview. Copying the file seems a workaround for now anyhow. On Nov 14, 2011, at 5:35 PM, Daniel D. Daugherty wrote: > The jvm.hprof.txt file should live in $JAVA_HOME/jre/lib/jvm.hprof.txt. > > I believe that the attached changeset from Roger fixes the issue. > > Dan > > > > On 11/14/11 4:26 PM, Michael Hall wrote: >> Sorry for following up on my own but after doing a 'locate' >> >> cp /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/lib/jvm.hprof.txt /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/jvm.hprof.txt >> >> localhost:~ mjh$ java -Djava.security.manager -Djava.security.policy=/Users/mjh/all.policy -Dapp=CommandWrap.app -agentlib:hprof=heap=sites -Dconsole=pane -Dapple.laf.useScreenMenuBar=true -Djruby.home=/Volumes/mbvol/jruby-1.6.0.RC3 -cp halfpipe.jar:/Volumes/mbvol/jruby-1.6.0.RC3/lib/jruby.jar:/Volumes/mbvol/rhino1_7R3/js.jar org.cmdline.CommandLine >> >> Error: Could not find or load main class org.cmdline.CommandLine >> >> Dumping allocation sites ... done. >> >> Yeah, I was in the wrong directory to begin with. It appears jvm.hprof.txt is too? s/b jre/lib? From daniel.daugherty at oracle.com Mon Nov 14 15:47:21 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 14 Nov 2011 16:47:21 -0700 Subject: hprof broke? In-Reply-To: References: <90308C9E-5ABC-4681-A58A-63F75EE8A0E8@gmail.com> <4EC1A5A7.1080207@oracle.com> Message-ID: <4EC1A889.5040605@oracle.com> Another work around is: $ cd $JAVA_HOME $ ln -s jre/lib/jvm.hprof.txt jre/jvm.hprof.txt Dan On 11/14/11 4:43 PM, Michael Hall wrote: > Ah, sorry, missed how recent the resolution was. I'll look for it in the next developer preview. > Copying the file seems a workaround for now anyhow. > > On Nov 14, 2011, at 5:35 PM, Daniel D. Daugherty wrote: > >> The jvm.hprof.txt file should live in $JAVA_HOME/jre/lib/jvm.hprof.txt. >> >> I believe that the attached changeset from Roger fixes the issue. >> >> Dan >> >> >> >> On 11/14/11 4:26 PM, Michael Hall wrote: >>> Sorry for following up on my own but after doing a 'locate' >>> >>> cp /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/lib/jvm.hprof.txt /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/jvm.hprof.txt >>> >>> localhost:~ mjh$ java -Djava.security.manager -Djava.security.policy=/Users/mjh/all.policy -Dapp=CommandWrap.app -agentlib:hprof=heap=sites -Dconsole=pane -Dapple.laf.useScreenMenuBar=true -Djruby.home=/Volumes/mbvol/jruby-1.6.0.RC3 -cp halfpipe.jar:/Volumes/mbvol/jruby-1.6.0.RC3/lib/jruby.jar:/Volumes/mbvol/rhino1_7R3/js.jar org.cmdline.CommandLine >>> >>> Error: Could not find or load main class org.cmdline.CommandLine >>> >>> Dumping allocation sites ... done. >>> >>> Yeah, I was in the wrong directory to begin with. It appears jvm.hprof.txt is too? s/b jre/lib? From kelly.ohair at oracle.com Mon Nov 14 16:33:06 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 14 Nov 2011 16:33:06 -0800 Subject: hprof broke? In-Reply-To: <4EC1A889.5040605@oracle.com> References: <90308C9E-5ABC-4681-A58A-63F75EE8A0E8@gmail.com> <4EC1A5A7.1080207@oracle.com> <4EC1A889.5040605@oracle.com> Message-ID: hprof actually works on the Mac? I'm amazed. ;^) -kto On Nov 14, 2011, at 3:47 PM, Daniel D. Daugherty wrote: > Another work around is: > > $ cd $JAVA_HOME > $ ln -s jre/lib/jvm.hprof.txt jre/jvm.hprof.txt > > Dan > > > On 11/14/11 4:43 PM, Michael Hall wrote: >> Ah, sorry, missed how recent the resolution was. I'll look for it in the next developer preview. >> Copying the file seems a workaround for now anyhow. >> >> On Nov 14, 2011, at 5:35 PM, Daniel D. Daugherty wrote: >> >>> The jvm.hprof.txt file should live in $JAVA_HOME/jre/lib/jvm.hprof.txt. >>> >>> I believe that the attached changeset from Roger fixes the issue. >>> >>> Dan >>> >>> >>> >>> On 11/14/11 4:26 PM, Michael Hall wrote: >>>> Sorry for following up on my own but after doing a 'locate' >>>> >>>> cp /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/lib/jvm.hprof.txt /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/jvm.hprof.txt >>>> >>>> localhost:~ mjh$ java -Djava.security.manager -Djava.security.policy=/Users/mjh/all.policy -Dapp=CommandWrap.app -agentlib:hprof=heap=sites -Dconsole=pane -Dapple.laf.useScreenMenuBar=true -Djruby.home=/Volumes/mbvol/jruby-1.6.0.RC3 -cp halfpipe.jar:/Volumes/mbvol/jruby-1.6.0.RC3/lib/jruby.jar:/Volumes/mbvol/rhino1_7R3/js.jar org.cmdline.CommandLine >>>> >>>> Error: Could not find or load main class org.cmdline.CommandLine >>>> >>>> Dumping allocation sites ... done. >>>> >>>> Yeah, I was in the wrong directory to begin with. It appears jvm.hprof.txt is too? s/b jre/lib? From astrange at apple.com Mon Nov 14 19:09:49 2011 From: astrange at apple.com (astrange at apple.com) Date: Tue, 15 Nov 2011 03:09:49 +0000 Subject: hg: macosx-port/macosx-port/hotspot: Fixing MACOSX_PORT-163: Cannot receive DatagramPacket with zero-length buffer Message-ID: <20111115030951.740A24735F@hg.openjdk.java.net> Changeset: 2cfafd882715 Author: astrange Date: 2011-11-14 22:09 -0500 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/2cfafd882715 Fixing MACOSX_PORT-163: Cannot receive DatagramPacket with zero-length buffer ! src/os/bsd/vm/os_bsd.inline.hpp From alexander.zuev at oracle.com Tue Nov 15 02:59:06 2011 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 15 Nov 2011 10:59:06 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fix for MACOSX_PORT-456: DnDTextDropTest 0001 fails in JCK-runtime-7 interactive Message-ID: <20111115105930.959A847362@hg.openjdk.java.net> Changeset: bd6849181039 Author: kizune Date: 2011-11-15 14:58 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/bd6849181039 Fix for MACOSX_PORT-456: DnDTextDropTest 0001 fails in JCK-runtime-7 interactive ! src/macosx/native/sun/awt/CDropTarget.m ! src/macosx/native/sun/awt/CDropTargetContextPeer.m From kirk at kodewerk.com Tue Nov 15 06:08:12 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Tue, 15 Nov 2011 15:08:12 +0100 Subject: hprof broke? In-Reply-To: References: <90308C9E-5ABC-4681-A58A-63F75EE8A0E8@gmail.com> <4EC1A5A7.1080207@oracle.com> <4EC1A889.5040605@oracle.com> Message-ID: very nicely! Kirk On Nov 15, 2011, at 1:33 AM, Kelly O'Hair wrote: > hprof actually works on the Mac? I'm amazed. ;^) > > -kto > > On Nov 14, 2011, at 3:47 PM, Daniel D. Daugherty wrote: > >> Another work around is: >> >> $ cd $JAVA_HOME >> $ ln -s jre/lib/jvm.hprof.txt jre/jvm.hprof.txt >> >> Dan >> >> >> On 11/14/11 4:43 PM, Michael Hall wrote: >>> Ah, sorry, missed how recent the resolution was. I'll look for it in the next developer preview. >>> Copying the file seems a workaround for now anyhow. >>> >>> On Nov 14, 2011, at 5:35 PM, Daniel D. Daugherty wrote: >>> >>>> The jvm.hprof.txt file should live in $JAVA_HOME/jre/lib/jvm.hprof.txt. >>>> >>>> I believe that the attached changeset from Roger fixes the issue. >>>> >>>> Dan >>>> >>>> >>>> >>>> On 11/14/11 4:26 PM, Michael Hall wrote: >>>>> Sorry for following up on my own but after doing a 'locate' >>>>> >>>>> cp /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/lib/jvm.hprof.txt /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/jvm.hprof.txt >>>>> >>>>> localhost:~ mjh$ java -Djava.security.manager -Djava.security.policy=/Users/mjh/all.policy -Dapp=CommandWrap.app -agentlib:hprof=heap=sites -Dconsole=pane -Dapple.laf.useScreenMenuBar=true -Djruby.home=/Volumes/mbvol/jruby-1.6.0.RC3 -cp halfpipe.jar:/Volumes/mbvol/jruby-1.6.0.RC3/lib/jruby.jar:/Volumes/mbvol/rhino1_7R3/js.jar org.cmdline.CommandLine >>>>> >>>>> Error: Could not find or load main class org.cmdline.CommandLine >>>>> >>>>> Dumping allocation sites ... done. >>>>> >>>>> Yeah, I was in the wrong directory to begin with. It appears jvm.hprof.txt is too? s/b jre/lib? > From sergey.bylokhov at oracle.com Tue Nov 15 06:18:52 2011 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Tue, 15 Nov 2011 14:18:52 +0000 Subject: hg: macosx-port/macosx-port/jdk: MACOSX_PORT-544: Choice doesn't send ItemEvent if a current item selected again Message-ID: <20111115141903.8EEDB47364@hg.openjdk.java.net> Changeset: 5908e905f845 Author: serb Date: 2011-11-15 18:16 +0400 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/5908e905f845 MACOSX_PORT-544: Choice doesn't send ItemEvent if a current item selected again ! src/macosx/classes/sun/lwawt/LWChoicePeer.java From henri.gomez at gmail.com Tue Nov 15 06:40:09 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 15 Nov 2011 15:40:09 +0100 Subject: hprof broke? In-Reply-To: References: <90308C9E-5ABC-4681-A58A-63F75EE8A0E8@gmail.com> <4EC1A5A7.1080207@oracle.com> <4EC1A889.5040605@oracle.com> Message-ID: I confirm "jvm.hprof.txt" is installed on correct location for openjdk-osx-build releases : /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/jvm.hprof.txt And it works for me like this. 2011/11/15 Charles K Pepperdine : > very nicely! > > Kirk > > On Nov 15, 2011, at 1:33 AM, Kelly O'Hair wrote: > >> hprof actually works on the Mac? I'm amazed. ;^) >> >> -kto >> >> On Nov 14, 2011, at 3:47 PM, Daniel D. Daugherty wrote: >> >>> Another work around is: >>> >>> ? $ cd $JAVA_HOME >>> ? $ ln -s jre/lib/jvm.hprof.txt jre/jvm.hprof.txt >>> >>> Dan >>> >>> >>> On 11/14/11 4:43 PM, Michael Hall wrote: >>>> Ah, sorry, missed how recent the resolution was. I'll look for it in the next developer preview. >>>> Copying the file seems a workaround for now anyhow. >>>> >>>> On Nov 14, 2011, at 5:35 PM, Daniel D. Daugherty wrote: >>>> >>>>> The jvm.hprof.txt file should live in $JAVA_HOME/jre/lib/jvm.hprof.txt. >>>>> >>>>> I believe that the attached changeset from Roger fixes the issue. >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> On 11/14/11 4:26 PM, Michael Hall wrote: >>>>>> Sorry for following up on my own but after doing a 'locate' >>>>>> >>>>>> cp /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/lib/jvm.hprof.txt /Library/Java/JavaVirtualMachines/JDK1.7.0.jdk/Contents/Home/jre/jvm.hprof.txt >>>>>> >>>>>> localhost:~ mjh$ java -Djava.security.manager -Djava.security.policy=/Users/mjh/all.policy -Dapp=CommandWrap.app -agentlib:hprof=heap=sites -Dconsole=pane -Dapple.laf.useScreenMenuBar=true -Djruby.home=/Volumes/mbvol/jruby-1.6.0.RC3 -cp halfpipe.jar:/Volumes/mbvol/jruby-1.6.0.RC3/lib/jruby.jar:/Volumes/mbvol/rhino1_7R3/js.jar org.cmdline.CommandLine >>>>>> >>>>>> Error: Could not find or load main class org.cmdline.CommandLine >>>>>> >>>>>> Dumping allocation sites ... done. >>>>>> >>>>>> Yeah, I was in the wrong directory to begin with. It appears jvm.hprof.txt is too? s/b jre/lib? >> > > From alexander.zuev at oracle.com Tue Nov 15 06:41:47 2011 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 15 Nov 2011 14:41:47 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fix for MACOSX_PORT-617: click count is zero in mouse event Message-ID: <20111115144157.73E4947365@hg.openjdk.java.net> Changeset: f99132d6a2d6 Author: leonidr Date: 2011-11-15 18:41 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/f99132d6a2d6 Fix for MACOSX_PORT-617: click count is zero in mouse event ! src/macosx/native/sun/awt/CRobot.m From swingler at apple.com Tue Nov 15 07:47:57 2011 From: swingler at apple.com (Mike Swingler) Date: Tue, 15 Nov 2011 07:47:57 -0800 Subject: hg: macosx-port/macosx-port/jdk: Fix for MACOSX_PORT-456: DnDTextDropTest 0001 fails in JCK-runtime-7 interactive In-Reply-To: <20111115105930.959A847362@hg.openjdk.java.net> References: <20111115105930.959A847362@hg.openjdk.java.net> Message-ID: <5210331D-03A6-4692-AD3E-783668F2698D@apple.com> On Nov 15, 2011, at 2:59 AM, alexander.zuev at oracle.com wrote: > Changeset: bd6849181039 > Author: kizune > Date: 2011-11-15 14:58 +0300 > URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/bd6849181039 > > Fix for MACOSX_PORT-456: DnDTextDropTest 0001 fails in JCK-runtime-7 interactive > > ! src/macosx/native/sun/awt/CDropTarget.m > ! src/macosx/native/sun/awt/CDropTargetContextPeer.m > This seems problematic: --- a/src/macosx/native/sun/awt/CDropTarget.m Mon Nov 14 21:09:29 2011 +0300 +++ b/src/macosx/native/sun/awt/CDropTarget.m Tue Nov 15 14:58:46 2011 +0300 @@ -320,7 +320,11 @@ extern JNFClassInfo jc_CDropTargetContex - (jobject) copyDraggingDataForFormat:(jlong)format { - JNIEnv* env = [ThreadUtilities getJNIEnv]; // Can be called from threads other than the native event thread! + __block JNIEnv* env; + + [JNFRunLoop performOnMainThreadWaiting:YES withBlock:^(){ + env = [ThreadUtilities getJNIEnv]; // Can be called from threads other than the native event thread! + }]; NSData* data = nil; // Convert the Java format (datatransferer int index) to a pasteboard format (NSString): You can't use the AppKit/Thread-0 Env from another thread, or HotSpot can crash. You need to use an Env that is local to your thread, no matter what thread it gets called from, and if that means attaching the current thread, so be-it. Regards, Mike Swingler Apple Inc. From sergey.bylokhov at oracle.com Tue Nov 15 08:14:58 2011 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Tue, 15 Nov 2011 16:14:58 +0000 Subject: hg: macosx-port/macosx-port/jdk: MACOSX_PORT-525: return of 6248016: Removal of the selected item at runtime removes all the elements in the choice, was: XToolkit. Message-ID: <20111115161519.E6E3447367@hg.openjdk.java.net> Changeset: 9a927b9423b5 Author: serb Date: 2011-11-15 20:12 +0400 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/9a927b9423b5 MACOSX_PORT-525: return of 6248016: Removal of the selected item at runtime removes all the elements in the choice, was: XToolkit. ! src/macosx/classes/sun/lwawt/LWChoicePeer.java From astrange at apple.com Tue Nov 15 08:42:53 2011 From: astrange at apple.com (astrange at apple.com) Date: Tue, 15 Nov 2011 16:42:53 +0000 Subject: hg: macosx-port/macosx-port/hotspot: Fix select-based os::timeout for timeout=-1 Message-ID: <20111115164255.13DAA47368@hg.openjdk.java.net> Changeset: 67bb51286384 Author: astrange Date: 2011-11-15 11:42 -0500 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/67bb51286384 Fix select-based os::timeout for timeout=-1 Fixes the test java/net/Authenticator/BasicTest.java and more ! src/os/bsd/vm/os_bsd.inline.hpp From alexander.zuev at oracle.com Tue Nov 15 10:02:29 2011 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 15 Nov 2011 21:02:29 +0300 Subject: hg: macosx-port/macosx-port/jdk: Fix for MACOSX_PORT-456: DnDTextDropTest 0001 fails in JCK-runtime-7 interactive In-Reply-To: <5210331D-03A6-4692-AD3E-783668F2698D@apple.com> References: <20111115105930.959A847362@hg.openjdk.java.net> <5210331D-03A6-4692-AD3E-783668F2698D@apple.com> Message-ID: <4EC2A935.8060303@oracle.com> On 11/15/11 6:47 PM, Mike Swingler wrote: > On Nov 15, 2011, at 2:59 AM, alexander.zuev at oracle.com > wrote: > >> Changeset: bd6849181039 >> Author: kizune >> Date: 2011-11-15 14:58 +0300 >> URL: >> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/bd6849181039 >> >> Fix for MACOSX_PORT-456: DnDTextDropTest 0001 fails in JCK-runtime-7 >> interactive >> >> ! src/macosx/native/sun/awt/CDropTarget.m >> ! src/macosx/native/sun/awt/CDropTargetContextPeer.m >> > > This seems problematic: > --- a/src/macosx/native/sun/awt/CDropTarget.m Mon Nov 14 21:09:29 2011 > +0300 > +++ b/src/macosx/native/sun/awt/CDropTarget.m Tue Nov 15 14:58:46 2011 > +0300 > @@ -320,7 +320,11 @@ extern JNFClassInfo jc_CDropTargetContex > - (jobject) copyDraggingDataForFormat:(jlong)format > { > - JNIEnv* env = [ThreadUtilities getJNIEnv]; // Can be called from > threads other than the native event thread! > + __block JNIEnv* env; > + > + [JNFRunLoop performOnMainThreadWaiting:YES withBlock:^(){ > + env = [ThreadUtilities getJNIEnv]; // Can be called from threads > other than the native event thread! > + }]; > NSData* data = nil; > // Convert the Java format (datatransferer int index) to a pasteboard > format (NSString): > > You can't use the AppKit/Thread-0 Env from another thread, or HotSpot > can crash. You need to use an Env that is local to your thread, no > matter what thread it gets called from, and if that means attaching > the current thread, so be-it. So you saying that using AppKit's env is not thread-safe? Should we just execute the rest of the method on the AppKit thread synchronously by packing the rest of the code (well, minus the return part of course) into this block? With best regards, Alexander Zuev. From swingler at apple.com Tue Nov 15 09:53:03 2011 From: swingler at apple.com (Mike Swingler) Date: Tue, 15 Nov 2011 09:53:03 -0800 Subject: hg: macosx-port/macosx-port/jdk: Fix for MACOSX_PORT-456: DnDTextDropTest 0001 fails in JCK-runtime-7 interactive In-Reply-To: <4EC2A935.8060303@oracle.com> References: <20111115105930.959A847362@hg.openjdk.java.net> <5210331D-03A6-4692-AD3E-783668F2698D@apple.com> <4EC2A935.8060303@oracle.com> Message-ID: On Nov 15, 2011, at 10:02 AM, Alexander Zuev wrote: > On 11/15/11 6:47 PM, Mike Swingler wrote: >> >> On Nov 15, 2011, at 2:59 AM, alexander.zuev at oracle.com wrote: >> >>> Changeset: bd6849181039 >>> Author: kizune >>> Date: 2011-11-15 14:58 +0300 >>> URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/bd6849181039 >>> >>> Fix for MACOSX_PORT-456: DnDTextDropTest 0001 fails in JCK-runtime-7 interactive >>> >>> ! src/macosx/native/sun/awt/CDropTarget.m >>> ! src/macosx/native/sun/awt/CDropTargetContextPeer.m >>> >> >> This seems problematic: >> --- a/src/macosx/native/sun/awt/CDropTarget.m Mon Nov 14 21:09:29 2011 +0300 >> +++ b/src/macosx/native/sun/awt/CDropTarget.m Tue Nov 15 14:58:46 2011 +0300 >> @@ -320,7 +320,11 @@ extern JNFClassInfo jc_CDropTargetContex >> >> - (jobject) copyDraggingDataForFormat:(jlong)format >> { >> - JNIEnv* env = [ThreadUtilities getJNIEnv]; // Can be called from threads other than the native event thread! >> + __block JNIEnv* env; >> + >> + [JNFRunLoop performOnMainThreadWaiting:YES withBlock:^(){ >> + env = [ThreadUtilities getJNIEnv]; // Can be called from threads other than the native event thread! >> + }]; >> NSData* data = nil; >> >> // Convert the Java format (datatransferer int index) to a pasteboard format (NSString): >> >> You can't use the AppKit/Thread-0 Env from another thread, or HotSpot can crash. You need to use an Env that is local to your thread, no matter what thread it gets called from, and if that means attaching the current thread, so be-it. > So you saying that using AppKit's env is not thread-safe? Should we just execute the rest of the method on the AppKit thread synchronously by packing the rest of the code (well, minus the return part of course) into this block? No, you should be able to use the +getJNIEnvUncached variant which unconditionally attaches the current thread, or you need to re-think how the callers are accessing this function. Since it's returning a jobject, perhaps you should redesign it to take an Env from it's caller. Regards, ~Mike From mik3hall at gmail.com Tue Nov 15 15:19:11 2011 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 15 Nov 2011 17:19:11 -0600 Subject: hprof broke? In-Reply-To: References: <90308C9E-5ABC-4681-A58A-63F75EE8A0E8@gmail.com> <4EC1A5A7.1080207@oracle.com> <4EC1A889.5040605@oracle.com> Message-ID: <695B0A68-DD7A-439A-BFAA-D72F7D4CD55B@gmail.com> On Nov 14, 2011, at 6:33 PM, Kelly O'Hair wrote: > hprof actually works on the Mac? I'm amazed. ;^) I guess for one more confirmation. Yes, for quite some time, and its looked better doing it. From mik3hall at gmail.com Tue Nov 15 16:37:35 2011 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 15 Nov 2011 18:37:35 -0600 Subject: hprof broke? In-Reply-To: <695B0A68-DD7A-439A-BFAA-D72F7D4CD55B@gmail.com> References: <90308C9E-5ABC-4681-A58A-63F75EE8A0E8@gmail.com> <4EC1A5A7.1080207@oracle.com> <4EC1A889.5040605@oracle.com> <695B0A68-DD7A-439A-BFAA-D72F7D4CD55B@gmail.com> Message-ID: On Nov 15, 2011, at 5:19 PM, Michael Hall wrote: > > On Nov 14, 2011, at 6:33 PM, Kelly O'Hair wrote: > >> hprof actually works on the Mac? I'm amazed. ;^) > > I guess for one more confirmation. Yes, for quite some time, and its looked better doing it. To clarify in order to limit potential offense, ...looked better doing it than on other platforms. The irony being it's text. No implications for this implementation of hprof, or java. From alexander.potochkin at sun.com Wed Nov 16 09:40:39 2011 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Wed, 16 Nov 2011 17:40:39 +0000 Subject: hg: macosx-port/macosx-port/jdk: fixed #507: List doesn't receive Item and Action events Message-ID: <20111116174050.2EBBD47391@hg.openjdk.java.net> Changeset: 67893f14ee5e Author: alexp Date: 2011-11-16 21:01 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67893f14ee5e fixed #507: List doesn't receive Item and Action events ! src/macosx/classes/sun/lwawt/LWListPeer.java From tobi at ultramixer.com Wed Nov 16 14:23:48 2011 From: tobi at ultramixer.com (Tobias Bley (UltraMixer)) Date: Wed, 16 Nov 2011 23:23:48 +0100 Subject: apple.awt.brushMetalLook support on OpenJDK7? Message-ID: Hi, is there a replacement for the JDK6 property apple.awt.brushMetalLook? e.g. frame.getRootPane().putClientProperty("apple.awt.brushMetalLook", Boolean.TRUE); Tobi From roger.yeung at oracle.com Wed Nov 16 15:49:02 2011 From: roger.yeung at oracle.com (Roger Yeung) Date: Wed, 16 Nov 2011 15:49:02 -0800 Subject: JDK 7 Mac Port Preview b218 Available Message-ID: <4EC44BEE.3020004@oracle.com> Hi, The JDK 7 Mac Port Preview b218 is now available: http://jdk7.java.net/macportpreview/ Regards, Roger Y. From david.katleman at sun.com Wed Nov 16 16:09:19 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Thu, 17 Nov 2011 00:09:19 +0000 Subject: hg: macosx-port/macosx-port: Added tag jdk7-b218 for changeset a3e4c9587247 Message-ID: <20111117000919.3A1BE4739C@hg.openjdk.java.net> Changeset: 3dace5474996 Author: katleman Date: 2011-11-16 15:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/rev/3dace5474996 Added tag jdk7-b218 for changeset a3e4c9587247 ! .hgtags From david.katleman at sun.com Wed Nov 16 16:09:28 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Thu, 17 Nov 2011 00:09:28 +0000 Subject: hg: macosx-port/macosx-port/corba: Added tag jdk7-b218 for changeset d94a4a9e4094 Message-ID: <20111117000929.3A7A94739D@hg.openjdk.java.net> Changeset: b66336ec335d Author: katleman Date: 2011-11-16 15:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/corba/rev/b66336ec335d Added tag jdk7-b218 for changeset d94a4a9e4094 ! .hgtags From david.katleman at sun.com Wed Nov 16 16:09:38 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Thu, 17 Nov 2011 00:09:38 +0000 Subject: hg: macosx-port/macosx-port/hotspot: Added tag jdk7-b218 for changeset 67bb51286384 Message-ID: <20111117000940.7BE454739E@hg.openjdk.java.net> Changeset: 1dcc5a7638f0 Author: katleman Date: 2011-11-16 15:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/1dcc5a7638f0 Added tag jdk7-b218 for changeset 67bb51286384 ! .hgtags From david.katleman at sun.com Wed Nov 16 16:09:49 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Thu, 17 Nov 2011 00:09:49 +0000 Subject: hg: macosx-port/macosx-port/jaxp: Added tag jdk7-b218 for changeset 120b7a15ba54 Message-ID: <20111117000949.D21D94739F@hg.openjdk.java.net> Changeset: c7b29a21a5fd Author: katleman Date: 2011-11-16 15:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jaxp/rev/c7b29a21a5fd Added tag jdk7-b218 for changeset 120b7a15ba54 ! .hgtags From david.katleman at sun.com Wed Nov 16 16:09:59 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Thu, 17 Nov 2011 00:09:59 +0000 Subject: hg: macosx-port/macosx-port/jaxws: Added tag jdk7-b218 for changeset f79b95e6d1b2 Message-ID: <20111117000959.DC581473A0@hg.openjdk.java.net> Changeset: fe89960c4a3f Author: katleman Date: 2011-11-16 15:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jaxws/rev/fe89960c4a3f Added tag jdk7-b218 for changeset f79b95e6d1b2 ! .hgtags From david.katleman at sun.com Wed Nov 16 16:10:11 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Thu, 17 Nov 2011 00:10:11 +0000 Subject: hg: macosx-port/macosx-port/jdk: Added tag jdk7-b218 for changeset 67893f14ee5e Message-ID: <20111117001022.CC64D473A1@hg.openjdk.java.net> Changeset: f9090569b53f Author: katleman Date: 2011-11-16 15:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/f9090569b53f Added tag jdk7-b218 for changeset 67893f14ee5e ! .hgtags From david.katleman at sun.com Wed Nov 16 16:10:32 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Thu, 17 Nov 2011 00:10:32 +0000 Subject: hg: macosx-port/macosx-port/langtools: Added tag jdk7-b218 for changeset 6d750f52d368 Message-ID: <20111117001035.087F6473A2@hg.openjdk.java.net> Changeset: b3cd6d13fd49 Author: katleman Date: 2011-11-16 15:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/langtools/rev/b3cd6d13fd49 Added tag jdk7-b218 for changeset 6d750f52d368 ! .hgtags From dmitry.cherepanov at oracle.com Thu Nov 17 00:37:46 2011 From: dmitry.cherepanov at oracle.com (dmitry.cherepanov at oracle.com) Date: Thu, 17 Nov 2011 08:37:46 +0000 Subject: hg: macosx-port/macosx-port/jdk: Implemented support for translucent windows Message-ID: <20111117083805.9D131473AF@hg.openjdk.java.net> Changeset: d17dbce63ee3 Author: dcherepanov Date: 2011-11-17 11:31 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/d17dbce63ee3 Implemented support for translucent windows ! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/CWrapper.m ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m From dmitry.cherepanov at oracle.com Thu Nov 17 06:33:45 2011 From: dmitry.cherepanov at oracle.com (dmitry.cherepanov at oracle.com) Date: Thu, 17 Nov 2011 14:33:45 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fixing regression (incorrectly translated graphics context) after changes for translucent windows Message-ID: <20111117143406.4AB99473B3@hg.openjdk.java.net> Changeset: 9ae1dedbf3d3 Author: dcherepanov Date: 2011-11-17 17:32 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/9ae1dedbf3d3 Fixing regression (incorrectly translated graphics context) after changes for translucent windows ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java From alex.menkov at sun.com Thu Nov 17 02:59:12 2011 From: alex.menkov at sun.com (alex.menkov at sun.com) Date: Thu, 17 Nov 2011 10:59:12 +0000 Subject: hg: macosx-port/macosx-port/jdk: fixed a number of PCM issues (including MACOSX_PORT-580, -620) Message-ID: <20111117105942.580E1473B0@hg.openjdk.java.net> Changeset: d95bd6323f70 Author: amenkov Date: 2011-11-17 13:57 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/d95bd6323f70 fixed a number of PCM issues (including MACOSX_PORT-580, -620) ! make/javax/sound/FILES_c.gmk - src/macosx/native/com/sun/media/sound/CARingBuffer.cpp - src/macosx/native/com/sun/media/sound/CARingBuffer.h ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_PCM.cpp From gk_brown at verizon.net Fri Nov 18 05:21:02 2011 From: gk_brown at verizon.net (Greg Brown) Date: Fri, 18 Nov 2011 08:21:02 -0500 Subject: JObjC.jar ? In-Reply-To: <42D8F6E1-6966-4C01-BFF0-C6BA434DFC07@verizon.net> References: <04F01C84-526B-4AEB-B665-8645FAC416D0@ultramixer.com> <4CB84C02-581F-43DC-8DF2-0AAA7FD02E6A@apple.com> <42D8F6E1-6966-4C01-BFF0-C6BA434DFC07@verizon.net> Message-ID: <62339519-7052-437E-9EB1-B22383A7DBD8@verizon.net> Wow, I can't believe this message actually made it through. I sent it almost a month ago. :-) On Oct 25, 2011, at 8:03 PM, Greg Brown wrote: > Hi Mike, > > Can you define "high performance"? :-) For example, would it be suitable for use in a basic GUI app? > > Is there any documentation available for this? A quick Google search on "jobjc" didn't turn up much. > > Thanks, > Greg > > On Oct 10, 2011, at 6:23 PM, Mike Swingler wrote: > >> On Oct 8, 2011, at 3:13 PM, Tobias Bley (UltraMixer) wrote: >> >>> Hi Mike, >>> >>> I recently found the JObjC.jar in JDK7. Could you please tell us something about it? Can we use it to use native cocoa components like NSOpenPanel (i saw NSOpenPanel.class)? >> >> Potentially. It is really only for the internal use of the JVM class libraries themselves for native platform integration which does not require high performance. >> >> Regards, >> Mike Swingler >> Java Engineering >> Apple Inc. >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Java-dev mailing list (Java-dev at lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/java-dev/gk_brown%40verizon.net >> >> This email sent to gk_brown at verizon.net > From alexander.potochkin at sun.com Fri Nov 18 07:36:14 2011 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Fri, 18 Nov 2011 15:36:14 +0000 Subject: hg: macosx-port/macosx-port/jdk: fixed #475: ListSelectionModel.MULTIPLE_INTERVAL_SELECTION Message-ID: <20111118153625.4BD31473D2@hg.openjdk.java.net> Changeset: 949ead790928 Author: alexp Date: 2011-11-18 18:56 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/949ead790928 fixed #475: ListSelectionModel.MULTIPLE_INTERVAL_SELECTION ! src/macosx/classes/sun/lwawt/LWListPeer.java From philip.race at oracle.com Fri Nov 18 14:54:13 2011 From: philip.race at oracle.com (philip.race at oracle.com) Date: Fri, 18 Nov 2011 22:54:13 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fixed MACOSX_PORT 702: Printing to a postscript stream results is printing to a default printer Message-ID: <20111118225424.13A53473E7@hg.openjdk.java.net> Changeset: 23cb1cb7f1b6 Author: prr Date: 2011-11-18 14:53 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/23cb1cb7f1b6 Fixed MACOSX_PORT 702: Printing to a postscript stream results is printing to a default printer ! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java From neugens at limasoftware.net Fri Nov 18 15:17:44 2011 From: neugens at limasoftware.net (Mario Torre) Date: Sat, 19 Nov 2011 00:17:44 +0100 Subject: SunGraphics2D instead of Graphics2D Message-ID: Hello all, While developing our Swing/JavaFX integration [1] I've found that with the aqua look and feel it doesn't paint correctly, unless I set the awt.nativeDoubleBuffering to false. The reason for this is that internally, Graphics2D objects are casted to SunGraphics2D, probably this is a left over for some specific optimizations in the Apple JDK, but from the current OpenJDK code I can't see any reason for that cast to exist. The problem surfaces because we use a special component to proxy heavyweight behavior to the Java FX view and to provide graphics and all the usual goodies that the swing hierarchy wants. In particular, the graphics object for the heavyweight component is a proxy graphics that wraps a BufferedImage. Since those cast gets in the way only when native double buffering is enabled on the Mac, I can workaround for older JDK releases, but I would really like to see if this fix can be pushed in for OpenJDK 7. The webrev for the patch is here: http://cr.openjdk.java.net/~neugens/use_graphics2d/webrev.01/ Any comments? Cheers, Mario [1] Some links: http://jroller.com/neugens/entry/jfreechartfx http://jroller.com/neugens/entry/oh_no_i_lost_focus http://thingsfx.com/ --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com 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 sergey.bylokhov at oracle.com Sat Nov 19 09:33:51 2011 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Sat, 19 Nov 2011 17:33:51 +0000 Subject: hg: macosx-port/macosx-port/jdk: MACOSX_PORT-453: DrawTest0001 fails to draw with points control. Message-ID: <20111119173410.4636B473FA@hg.openjdk.java.net> Changeset: 2614a9a5722c Author: serb Date: 2011-11-19 21:29 +0400 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/2614a9a5722c MACOSX_PORT-453: DrawTest0001 fails to draw with points control. MACOSX_PORT-517: DrawTest demo: Selected color is not being used for the drawing ! src/macosx/classes/sun/lwawt/LWButtonPeer.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWPanelPeer.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CInputMethod.java ! src/macosx/classes/sun/lwawt/macosx/CRobot.java From sergey.bylokhov at oracle.com Sat Nov 19 10:42:28 2011 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Sat, 19 Nov 2011 18:42:28 +0000 Subject: hg: macosx-port/macosx-port/jdk: MACOSX_PORT-733: scrollbars operations are not functional in TextAreaTests. Message-ID: <20111119184238.43216473FB@hg.openjdk.java.net> Changeset: 4ecc62fc5696 Author: serb Date: 2011-11-19 22:39 +0400 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/4ecc62fc5696 MACOSX_PORT-733: scrollbars operations are not functional in TextAreaTests. ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java From tobi at ultramixer.com Sat Nov 19 13:04:10 2011 From: tobi at ultramixer.com (Tobias Bley) Date: Sat, 19 Nov 2011 22:04:10 +0100 Subject: can't hide Fullscreen icon on JFrame on OpenJDK7 b218 Message-ID: <54134E8A-2861-4EE8-B77C-F0997417B10C@ultramixer.com> Hi, In OpenJDK7 I can't hide the fullscreen icon shown in the right corner by default. When I press the fullscreen icon the Java application freezes. So I tried to hide the icon using the FullScreenUtilities-Class or native code. But it's not possible to hide the fullscreen icon in OpenJDK7, in JDK6 it works. The difference between both JDK versions is the type of the main window: When I call the following native code, I'll get the following results: NSWindow *mainWindow = [[NSApplication sharedApplication] mainWindow]; OpenJDK7: AWTWindow JDK6: CocoaAppWindow Is it a bug or how can I disable the fullscreen capability? Best regards, Tobi From bino at apple.com Sat Nov 19 22:33:42 2011 From: bino at apple.com (bino at apple.com) Date: Sun, 20 Nov 2011 06:33:42 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fixed problem with all windows being Fullscreenable Message-ID: <20111120063403.F317447408@hg.openjdk.java.net> Changeset: bb80a680fbc1 Author: bino at apple.com Date: 2011-11-19 22:33 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/bb80a680fbc1 Fixed problem with all windows being Fullscreenable ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m From bino at apple.com Sat Nov 19 22:38:02 2011 From: bino at apple.com (Bino George) Date: Sat, 19 Nov 2011 22:38:02 -0800 Subject: can't hide Fullscreen icon on JFrame on OpenJDK7 b218 In-Reply-To: <54134E8A-2861-4EE8-B77C-F0997417B10C@ultramixer.com> References: <54134E8A-2861-4EE8-B77C-F0997417B10C@ultramixer.com> Message-ID: <6ABF122F-3714-4ECF-ADF6-7A3D76D1364E@apple.com> Hi Tobey, This was a bug in the Fullscreen code I checked in last week. I have checked in a fix for it. Sorry about that. The Lion Fullscreen implementation in JDK7 is still broken due to a bug in AppKit, but at least you will not see the bug unless you opt into Lion Fullscreen support. Thanks, Bino. On Nov 19, 2011, at 1:04 PM, Tobias Bley wrote: > Hi, > > In OpenJDK7 I can't hide the fullscreen icon shown in the right corner by default. When I press the fullscreen icon the Java application freezes. So I tried to hide the icon using the FullScreenUtilities-Class or native code. But it's not possible to hide the fullscreen icon in OpenJDK7, in JDK6 it works. > > The difference between both JDK versions is the type of the main window: > > When I call the following native code, I'll get the following results: > > NSWindow *mainWindow = [[NSApplication sharedApplication] mainWindow]; > > OpenJDK7: AWTWindow > JDK6: CocoaAppWindow > > Is it a bug or how can I disable the fullscreen capability? > > Best regards, > Tobi From artem.ananiev at oracle.com Mon Nov 21 03:07:44 2011 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 21 Nov 2011 15:07:44 +0400 Subject: Result: New Mac OS X Port Committers In-Reply-To: <4EA81FE3.3030405@oracle.com> References: <4EA81FE3.3030405@oracle.com> Message-ID: <4ECA3100.4000202@oracle.com> Voting is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Artem On 10/26/2011 6:57 PM, Artem Ananiev wrote: > > I hereby nominate the following people to Mac OS X Port Committers: > > Alan Bateman (alanb) > Alexander Potochkin (alexp) > Andrew Brygin (bae) > Dmitry Cherepanov (dcherepanov) > Leonid Romanov (leonidr) > Naoto Sato (naoto) > Phil race (prr) > > Votes are due by November 10, 2011. > > Only currrent Mac OS X Port Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2] and [3]. > > Thanks, > > Artem > > [1] http://openjdk.java.net/census#macosx-port > [2] http://openjdk.java.net/projects#committer-vote > [3] http://openjdk.java.net/bylaws#lazy-consensus > From michael.x.mcmahon at oracle.com Mon Nov 21 07:46:36 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 21 Nov 2011 15:46:36 +0000 Subject: webrevs for macosx changes to jdk7u-osx Message-ID: <4ECA725C.3050606@oracle.com> Hi, The following webrevs are an initial set of changes taken from the macosx-port forest to be applied to the jd7u-osx forest at: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ This will eventually be merged into the main jdk7u-dev forest. Hotspot has already integrated into this forest. This changeset includes the changes (in the jdk and corba) repositories that are needed to build and run openjdk on MacOSX. The AWT/client code is however taken from the BSD forest. So, the native Apple AWT/client code will be integrated later. By default, the VM will run in headless mode. To run with the X windows AWT, set the environment variable AWT_TOOLKIT to XToolkit. This is a work in progress and much remains to be done. But, it does build and run. All comments welcome. Thanks, Michael. JDK repo ===== Modified files ------------------ http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/ New files ------------ http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/new/ Corba repo ======= http://cr.openjdk.java.net/~michaelm/7113349/1/corba/webrev/ From neugens.limasoftware at gmail.com Mon Nov 21 07:55:32 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 21 Nov 2011 16:55:32 +0100 Subject: SunGraphics2D instead of Graphics2D In-Reply-To: References: Message-ID: <93A9E076-6F56-4178-B154-D87FB4FCA288@gmail.com> Il giorno 19/nov/2011, alle ore 00:17, Mario Torre ha scritto: > Hello all, > > While developing our Swing/JavaFX integration [1] I've found that with the aqua look and feel it doesn't paint correctly, unless I set the awt.nativeDoubleBuffering to false. > > The reason for this is that internally, Graphics2D objects are casted to SunGraphics2D, probably this is a left over for some specific optimizations in the Apple JDK, but from the current OpenJDK code I can't see any reason for that cast to exist. > > The problem surfaces because we use a special component to proxy heavyweight behavior to the Java FX view and to provide graphics and all the usual goodies that the swing hierarchy wants. > > In particular, the graphics object for the heavyweight component is a proxy graphics that wraps a BufferedImage. > > Since those cast gets in the way only when native double buffering is enabled on the Mac, I can workaround for older JDK releases, but I would really like to see if this fix can be pushed in for OpenJDK 7. > > The webrev for the patch is here: > > http://cr.openjdk.java.net/~neugens/use_graphics2d/webrev.01/ > > Any comments? > > Cheers, > Mario > > [1] Some links: > http://jroller.com/neugens/entry/jfreechartfx > http://jroller.com/neugens/entry/oh_no_i_lost_focus > http://thingsfx.com/ Hello all, Any comments on this one? Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com 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 Alexander.Potochkin at oracle.com Mon Nov 21 08:58:18 2011 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 21 Nov 2011 19:58:18 +0300 Subject: SunGraphics2D instead of Graphics2D In-Reply-To: References: Message-ID: <4ECA832A.4030307@oracle.com> Hello Mario Your patch looks very logic, let me ask the Apple guys what were the reasons behind that SunGraphics2D cast Thanks! alexp > Hello all, > > While developing our Swing/JavaFX integration [1] I've found that with the aqua look and feel it doesn't paint correctly, unless I set the awt.nativeDoubleBuffering to false. > > The reason for this is that internally, Graphics2D objects are casted to SunGraphics2D, probably this is a left over for some specific optimizations in the Apple JDK, but from the current OpenJDK code I can't see any reason for that cast to exist. > > The problem surfaces because we use a special component to proxy heavyweight behavior to the Java FX view and to provide graphics and all the usual goodies that the swing hierarchy wants. > > In particular, the graphics object for the heavyweight component is a proxy graphics that wraps a BufferedImage. > > Since those cast gets in the way only when native double buffering is enabled on the Mac, I can workaround for older JDK releases, but I would really like to see if this fix can be pushed in for OpenJDK 7. > > The webrev for the patch is here: > > http://cr.openjdk.java.net/~neugens/use_graphics2d/webrev.01/ > > Any comments? > > Cheers, > Mario > > [1] Some links: > http://jroller.com/neugens/entry/jfreechartfx > http://jroller.com/neugens/entry/oh_no_i_lost_focus > http://thingsfx.com/ > --- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > http://www.ladybug-studio.com > > 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 henri.gomez at gmail.com Mon Nov 21 08:59:49 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 21 Nov 2011 17:59:49 +0100 Subject: webrevs for macosx changes to jdk7u-osx In-Reply-To: <4ECA725C.3050606@oracle.com> References: <4ECA725C.3050606@oracle.com> Message-ID: Well it deserve a build and if it works a new package from openjdk-osx-build. How did you build it ? osx way (ie: make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true ALT_DROPS_DIR=$DROP_DIR ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` HOTSPOT_BUILD_JOBS=$NUM_CPUS PARALLEL_COMPILE_JOBS=8) ? 2011/11/21 Michael McMahon : > Hi, > > The following webrevs are an initial set of changes > taken from the macosx-port forest to be applied > to the jd7u-osx forest at: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ > This will eventually be merged into the main jdk7u-dev forest. > > Hotspot has already integrated into this forest. This changeset includes > the changes (in the jdk and corba) repositories that are needed to build and > run > openjdk on MacOSX. The AWT/client code is however taken from the BSD forest. > So, the > native Apple AWT/client code will be integrated later. By default, the VM > will run in headless > mode. To run with the X windows AWT, set the environment variable > AWT_TOOLKIT to XToolkit. > > This is a work in progress and much remains to be done. But, it does build > and run. > All comments welcome. > > Thanks, > Michael. > > > JDK repo > ===== > > Modified files > ------------------ > http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/ > > New files > ------------ > http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/new/ > > Corba repo > ======= > http://cr.openjdk.java.net/~michaelm/7113349/1/corba/webrev/ > From michael.x.mcmahon at oracle.com Mon Nov 21 09:20:55 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 21 Nov 2011 17:20:55 +0000 Subject: webrevs for macosx changes to jdk7u-osx In-Reply-To: References: <4ECA725C.3050606@oracle.com> Message-ID: <4ECA8877.3080601@oracle.com> Henri, The changes haven't been pushed yet. But, here is the command I use to build it. make \ ARCH_DATA_MODEL=64 \ OPENJDK=true \ SA_APPLE_BOOT_JAVA=true \ ALWAYS_PASS_TEST_GAMMA=true \ ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` \ HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` \ ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include \ ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib \ NO_DOCS=true \ -w >> make.log 2>&1 - Michael. On 21/11/11 16:59, Henri Gomez wrote: > Well it deserve a build and if it works a new package from openjdk-osx-build. > > How did you build it ? > > osx way (ie: make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true > ALWAYS_PASS_TEST_GAMMA=true ALT_DROPS_DIR=$DROP_DIR > ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` > HOTSPOT_BUILD_JOBS=$NUM_CPUS PARALLEL_COMPILE_JOBS=8) ? > > > > 2011/11/21 Michael McMahon: >> Hi, >> >> The following webrevs are an initial set of changes >> taken from the macosx-port forest to be applied >> to the jd7u-osx forest at: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ >> This will eventually be merged into the main jdk7u-dev forest. >> >> Hotspot has already integrated into this forest. This changeset includes >> the changes (in the jdk and corba) repositories that are needed to build and >> run >> openjdk on MacOSX. The AWT/client code is however taken from the BSD forest. >> So, the >> native Apple AWT/client code will be integrated later. By default, the VM >> will run in headless >> mode. To run with the X windows AWT, set the environment variable >> AWT_TOOLKIT to XToolkit. >> >> This is a work in progress and much remains to be done. But, it does build >> and run. >> All comments welcome. >> >> Thanks, >> Michael. >> >> >> JDK repo >> ===== >> >> Modified files >> ------------------ >> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/ >> >> New files >> ------------ >> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/new/ >> >> Corba repo >> ======= >> http://cr.openjdk.java.net/~michaelm/7113349/1/corba/webrev/ >> From henri.gomez at gmail.com Mon Nov 21 09:37:17 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 21 Nov 2011 18:37:17 +0100 Subject: webrevs for macosx changes to jdk7u-osx In-Reply-To: <4ECA8877.3080601@oracle.com> References: <4ECA725C.3050606@oracle.com> <4ECA8877.3080601@oracle.com> Message-ID: 2011/11/21 Michael McMahon : > Henri, > > The changes haven't been pushed yet. But, here is the command I use to build > it. > > make \ > ? ? ARCH_DATA_MODEL=64 \ > ? ? OPENJDK=true \ > ? ? SA_APPLE_BOOT_JAVA=true \ > ? ? ALWAYS_PASS_TEST_GAMMA=true \ > ? ? ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` \ > ? ? HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` \ > ? ? ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include \ > ? ? ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib \ > ? ? NO_DOCS=true \ > ? ? -w >> make.log 2>&1 Ok, so I should wait change to be pushed. Thanks to send a note when commited :) From Alexander.Potochkin at oracle.com Mon Nov 21 11:11:03 2011 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 21 Nov 2011 22:11:03 +0300 Subject: Shortcuts in Swing? (question for pals from Apple) Message-ID: <4ECAA247.6060704@oracle.com> Hello guys We have a code snippet which tests the various shortcuts in a simple Swing application, Alt+A and Alt+B are among them. It turned out that when the focus is inside a JTextArea, Alt+A works as expected but Alt+B types a special symbol. This behavior is different from what we have on Windows or Linux and our testers consider it as a bug. Is there any workarounds to suppress typing on Alt+B? (Alt+B + some other magic keys?) If not, is there a specification that counts the shortcuts that can't be mapped to the users action? By the way, how to move the focus out of a focused JTextArea on Mac? On windows we use Ctrl+Tab, but it doesn't work on Mac. Thanks much alexp From Alexander.Potochkin at oracle.com Mon Nov 21 11:13:08 2011 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 21 Nov 2011 22:13:08 +0300 Subject: SunGraphics2D instead of Graphics2D (question for pals from Apple) In-Reply-To: <4ECA832A.4030307@oracle.com> References: <4ECA832A.4030307@oracle.com> Message-ID: <4ECAA2C4.2040107@oracle.com> The best place to ask is here anyway :-) Kevin, Mike, could you please comment is it safe to apply the proposed fix? Thanks! alexp > Hello Mario > > Your patch looks very logic, > let me ask the Apple guys what were the reasons behind that > SunGraphics2D cast > > Thanks! > alexp >> Hello all, >> >> While developing our Swing/JavaFX integration [1] I've found that >> with the aqua look and feel it doesn't paint correctly, unless I set >> the awt.nativeDoubleBuffering to false. >> >> The reason for this is that internally, Graphics2D objects are casted >> to SunGraphics2D, probably this is a left over for some specific >> optimizations in the Apple JDK, but from the current OpenJDK code I >> can't see any reason for that cast to exist. >> >> The problem surfaces because we use a special component to proxy >> heavyweight behavior to the Java FX view and to provide graphics and >> all the usual goodies that the swing hierarchy wants. >> >> In particular, the graphics object for the heavyweight component is a >> proxy graphics that wraps a BufferedImage. >> >> Since those cast gets in the way only when native double buffering is >> enabled on the Mac, I can workaround for older JDK releases, but I >> would really like to see if this fix can be pushed in for OpenJDK 7. >> >> The webrev for the patch is here: >> >> http://cr.openjdk.java.net/~neugens/use_graphics2d/webrev.01/ >> >> Any comments? >> >> Cheers, >> Mario >> >> [1] Some links: >> http://jroller.com/neugens/entry/jfreechartfx >> http://jroller.com/neugens/entry/oh_no_i_lost_focus >> http://thingsfx.com/ >> --- >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >> >> http://www.ladybug-studio.com >> >> 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 alexander.potochkin at sun.com Mon Nov 21 10:41:25 2011 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Mon, 21 Nov 2011 18:41:25 +0000 Subject: hg: macosx-port/macosx-port/jdk: fixed #611: Popup doesn't appear on jspinner Message-ID: <20111121184135.682F847413@hg.openjdk.java.net> Changeset: 635995e43a3c Author: alexp Date: 2011-11-21 22:02 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/635995e43a3c fixed #611: Popup doesn't appear on jspinner ! src/macosx/classes/com/apple/laf/AquaSpinnerUI.java From philip.race at oracle.com Mon Nov 21 10:53:01 2011 From: philip.race at oracle.com (Phil Race) Date: Mon, 21 Nov 2011 10:53:01 -0800 Subject: webrevs for macosx changes to jdk7u-osx In-Reply-To: <4ECA725C.3050606@oracle.com> References: <4ECA725C.3050606@oracle.com> Message-ID: <4ECA9E0D.1060507@oracle.com> Michael, Thanks for preparing this so we can see what the delta is. I have a few comments from a very quick skim over this This includes a whole bunch of "isBSD" checks and the like which I don't think belong in mainline. There also seems to be a bit of schizophrenia around what System.getProperty("os.name"); should return. In one place I see "Mac OS X" http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/print/PSPrinterJob.java.sdiff.html here I see "Darwin" http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/font/FontUtilities.java.sdiff.html I'm also a bit concerned by what looks like its going to remove some only recently added code here :- http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/awt/FontConfiguration.java.sdiff.html And there "not so clean" comments and changes in shared 2D code where some editing is justified before adding to mainline, and perhaps even examination as to whether its the right change http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/print/RasterPrinterJob.java.sdiff.html The changes here http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/native/sun/font/AccelGlyphCache.c.sdiff.html maybe would be better to be just "#include " on all platforms. You'd obviously want to make sure it all builds properly on the other platforms but I think at least the Solaris and Linux builds should be OK. In fact such a change was just made in JDK 8 for this case :- http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/native/sun/awt/medialib/mlib_types.h.sdiff.html So I don't think these changes should be pushed into mainline wholesale as is. It needs some review by area owners and perhaps changes beyond those I noticed. -phil. On 11/21/2011 7:46 AM, Michael McMahon wrote: > Hi, > > The following webrevs are an initial set of changes > taken from the macosx-port forest to be applied > to the jd7u-osx forest at: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ > This will eventually be merged into the main jdk7u-dev forest. > > Hotspot has already integrated into this forest. This changeset includes > the changes (in the jdk and corba) repositories that are needed to > build and run > openjdk on MacOSX. The AWT/client code is however taken from the BSD > forest. So, the > native Apple AWT/client code will be integrated later. By default, the > VM will run in headless > mode. To run with the X windows AWT, set the environment variable > AWT_TOOLKIT to XToolkit. > > This is a work in progress and much remains to be done. But, it does > build and run. > All comments welcome. > > Thanks, > Michael. > > > JDK repo > ===== > > Modified files > ------------------ > http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/ > > New files > ------------ > http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/new/ > > Corba repo > ======= > http://cr.openjdk.java.net/~michaelm/7113349/1/corba/webrev/ From swingler at apple.com Mon Nov 21 12:06:22 2011 From: swingler at apple.com (Mike Swingler) Date: Mon, 21 Nov 2011 12:06:22 -0800 Subject: SunGraphics2D instead of Graphics2D In-Reply-To: <4ECA832A.4030307@oracle.com> References: <4ECA832A.4030307@oracle.com> Message-ID: I don't think we had any specific reason to cast SunGraphics2D instead of just Graphics2D. Feel free to change the casts. Regards, Mike Swingler Apple Inc. On Nov 21, 2011, at 8:58 AM, Alexander Potochkin wrote: > Hello Mario > > Your patch looks very logic, > let me ask the Apple guys what were the reasons behind that SunGraphics2D cast > > Thanks! > alexp >> Hello all, >> >> While developing our Swing/JavaFX integration [1] I've found that with the aqua look and feel it doesn't paint correctly, unless I set the awt.nativeDoubleBuffering to false. >> >> The reason for this is that internally, Graphics2D objects are casted to SunGraphics2D, probably this is a left over for some specific optimizations in the Apple JDK, but from the current OpenJDK code I can't see any reason for that cast to exist. >> >> The problem surfaces because we use a special component to proxy heavyweight behavior to the Java FX view and to provide graphics and all the usual goodies that the swing hierarchy wants. >> >> In particular, the graphics object for the heavyweight component is a proxy graphics that wraps a BufferedImage. >> >> Since those cast gets in the way only when native double buffering is enabled on the Mac, I can workaround for older JDK releases, but I would really like to see if this fix can be pushed in for OpenJDK 7. >> >> The webrev for the patch is here: >> >> http://cr.openjdk.java.net/~neugens/use_graphics2d/webrev.01/ >> >> Any comments? >> >> Cheers, >> Mario >> >> [1] Some links: >> http://jroller.com/neugens/entry/jfreechartfx >> http://jroller.com/neugens/entry/oh_no_i_lost_focus >> http://thingsfx.com/ >> --- >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >> >> http://www.ladybug-studio.com >> >> 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 neugens.limasoftware at gmail.com Mon Nov 21 12:48:18 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 21 Nov 2011 21:48:18 +0100 Subject: SunGraphics2D instead of Graphics2D In-Reply-To: References: <4ECA832A.4030307@oracle.com> Message-ID: <3A736034-C9BE-4D9C-B18C-07AE449A33DC@gmail.com> Il giorno 21/nov/2011, alle ore 21:06, Mike Swingler ha scritto: > I don't think we had any specific reason to cast SunGraphics2D instead of just Graphics2D. Feel free to change the casts. > > Regards, > Mike Swingler > Apple Inc. > > On Nov 21, 2011, at 8:58 AM, Alexander Potochkin wrote: > >> Hello Mario >> >> Your patch looks very logic, >> let me ask the Apple guys what were the reasons behind that SunGraphics2D cast >> >> Thanks! >> alexp Hi Mike, Alex, Thanks for the review. Should I commit by myself directly? If so, this is the first time I commit to the OSX branch, I'm not sure what the rules are here (do I need a bug id, a special commit repository etc...) Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com 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 michael.x.mcmahon at oracle.com Mon Nov 21 14:08:52 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 21 Nov 2011 22:08:52 +0000 Subject: webrevs for macosx changes to jdk7u-osx In-Reply-To: <4ECA9E0D.1060507@oracle.com> References: <4ECA725C.3050606@oracle.com> <4ECA9E0D.1060507@oracle.com> Message-ID: <4ECACBF4.50007@oracle.com> Phil, Thanks for looking at this. The client code in this webrev was intended just as a temporary version to get a basic system up and running. I was thinking that the client folks would replace it all en-masse when they are ready. Hence, the fact that some recent changes might be missing, or otherwise not of ideal quality, might not be such a serious problem. In any case, I'll look at all of these points and make the changes. Thanks, Michael. On 21/11/11 18:53, Phil Race wrote: > Michael, > > Thanks for preparing this so we can see what the delta is. I have a > few comments from > a very quick skim over this > > This includes a whole bunch of "isBSD" checks and the like which I > don't think belong in mainline. > > There also seems to be a bit of schizophrenia around what > System.getProperty("os.name"); > should return. In one place I see "Mac OS X" > http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/print/PSPrinterJob.java.sdiff.html > > here I see "Darwin" > http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/font/FontUtilities.java.sdiff.html > > > I'm also a bit concerned by what looks like its going to remove some > only recently added code here :- > http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/awt/FontConfiguration.java.sdiff.html > > > And there "not so clean" comments and changes in shared 2D code where > some editing > is justified before adding to mainline, and perhaps even examination > as to whether its > the right change > http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/print/RasterPrinterJob.java.sdiff.html > > > The changes here > http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/native/sun/font/AccelGlyphCache.c.sdiff.html > > > maybe would be better to be just "#include " on all platforms. > > > You'd obviously want to make sure it all builds properly on the other > platforms but I think > at least the Solaris and Linux builds should be OK. In fact such a > change was just made in JDK 8 for this case :- > http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/native/sun/awt/medialib/mlib_types.h.sdiff.html > > > > So I don't think these changes should be pushed into mainline > wholesale as is. > It needs some review by area owners and perhaps changes beyond those I > noticed. > > -phil. > > > On 11/21/2011 7:46 AM, Michael McMahon wrote: >> Hi, >> >> The following webrevs are an initial set of changes >> taken from the macosx-port forest to be applied >> to the jd7u-osx forest at: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ >> This will eventually be merged into the main jdk7u-dev forest. >> >> Hotspot has already integrated into this forest. This changeset includes >> the changes (in the jdk and corba) repositories that are needed to >> build and run >> openjdk on MacOSX. The AWT/client code is however taken from the BSD >> forest. So, the >> native Apple AWT/client code will be integrated later. By default, >> the VM will run in headless >> mode. To run with the X windows AWT, set the environment variable >> AWT_TOOLKIT to XToolkit. >> >> This is a work in progress and much remains to be done. But, it does >> build and run. >> All comments welcome. >> >> Thanks, >> Michael. >> >> >> JDK repo >> ===== >> >> Modified files >> ------------------ >> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/ >> >> New files >> ------------ >> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/new/ >> >> Corba repo >> ======= >> http://cr.openjdk.java.net/~michaelm/7113349/1/corba/webrev/ > From philip.race at oracle.com Mon Nov 21 14:41:23 2011 From: philip.race at oracle.com (Phil Race) Date: Mon, 21 Nov 2011 14:41:23 -0800 Subject: webrevs for macosx changes to jdk7u-osx In-Reply-To: <4ECACBF4.50007@oracle.com> References: <4ECA725C.3050606@oracle.com> <4ECA9E0D.1060507@oracle.com> <4ECACBF4.50007@oracle.com> Message-ID: <4ECAD393.90309@oracle.com> Hmm, I just realised I didn't read properly and I now see that "The AWT/client code is however taken from the BSD forest." In other words, these aren't from the macos x port as I'd supposed. That explains a lot and this is maybe even worse than I'd first realised. If these changes are based on the bsd port, I can't be sure without checking if the same files in the same places are even touched in the current macos x port. And likely not in the same way .. so the "client folks" might not even notice these vestiges. And there's enough to do without finding and un-doing or re-doing these .. It is the shared code changes that concern me most as its not like we'll just "rm" that like you could rm the src/bsd directory .. Although I also see a whole bunch of new src/solaris files (inc. many for sound) What's that about ? I'm really (really) uncomfortable with pushing this into mainline. My strong recommendation is to reconsider this whole thing as I believe its going to pollute mainline big time. I think its a big mistake. -phil. On 11/21/2011 2:08 PM, Michael McMahon wrote: > Phil, > > Thanks for looking at this. The client code in this webrev was > intended just as a temporary > version to get a basic system up and running. I was thinking that the > client folks would replace > it all en-masse when they are ready. Hence, the fact that some recent > changes might be missing, > or otherwise not of ideal quality, might not be such a serious > problem. In any case, I'll look > at all of these points and make the changes. > > Thanks, > Michael. > > On 21/11/11 18:53, Phil Race wrote: >> Michael, >> >> Thanks for preparing this so we can see what the delta is. I have a >> few comments from >> a very quick skim over this >> >> This includes a whole bunch of "isBSD" checks and the like which I >> don't think belong in mainline. >> >> There also seems to be a bit of schizophrenia around what >> System.getProperty("os.name"); >> should return. In one place I see "Mac OS X" >> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/print/PSPrinterJob.java.sdiff.html >> >> here I see "Darwin" >> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/font/FontUtilities.java.sdiff.html >> >> >> I'm also a bit concerned by what looks like its going to remove some >> only recently added code here :- >> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/awt/FontConfiguration.java.sdiff.html >> >> >> And there "not so clean" comments and changes in shared 2D code >> where some editing >> is justified before adding to mainline, and perhaps even examination >> as to whether its >> the right change >> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/print/RasterPrinterJob.java.sdiff.html >> >> >> The changes here >> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/native/sun/font/AccelGlyphCache.c.sdiff.html >> >> >> maybe would be better to be just "#include " on all platforms. >> >> >> You'd obviously want to make sure it all builds properly on the other >> platforms but I think >> at least the Solaris and Linux builds should be OK. In fact such a >> change was just made in JDK 8 for this case :- >> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/native/sun/awt/medialib/mlib_types.h.sdiff.html >> >> >> >> So I don't think these changes should be pushed into mainline >> wholesale as is. >> It needs some review by area owners and perhaps changes beyond those >> I noticed. >> >> -phil. >> >> >> On 11/21/2011 7:46 AM, Michael McMahon wrote: >>> Hi, >>> >>> The following webrevs are an initial set of changes >>> taken from the macosx-port forest to be applied >>> to the jd7u-osx forest at: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ >>> This will eventually be merged into the main jdk7u-dev forest. >>> >>> Hotspot has already integrated into this forest. This changeset >>> includes >>> the changes (in the jdk and corba) repositories that are needed to >>> build and run >>> openjdk on MacOSX. The AWT/client code is however taken from the BSD >>> forest. So, the >>> native Apple AWT/client code will be integrated later. By default, >>> the VM will run in headless >>> mode. To run with the X windows AWT, set the environment variable >>> AWT_TOOLKIT to XToolkit. >>> >>> This is a work in progress and much remains to be done. But, it does >>> build and run. >>> All comments welcome. >>> >>> Thanks, >>> Michael. >>> >>> >>> JDK repo >>> ===== >>> >>> Modified files >>> ------------------ >>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/ >>> >>> New files >>> ------------ >>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/new/ >>> >>> Corba repo >>> ======= >>> http://cr.openjdk.java.net/~michaelm/7113349/1/corba/webrev/ >> > From paul.hohensee at oracle.com Mon Nov 21 14:53:19 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 21 Nov 2011 17:53:19 -0500 Subject: webrevs for macosx changes to jdk7u-osx In-Reply-To: <4ECAD393.90309@oracle.com> References: <4ECA725C.3050606@oracle.com> <4ECA9E0D.1060507@oracle.com> <4ECACBF4.50007@oracle.com> <4ECAD393.90309@oracle.com> Message-ID: <4ECAD65F.1080709@oracle.com> Note that Mike isn't proposing to push this into the baseline, rather he's proposing to push it into the jdk7u-osx development forest, which is logically a child of jdk7u-dev. We'd like to get an X11-based build going so everyone except the client group can get work done in the jdk7u-osx forest. The hotspot group has already pushed a recent version of hs23 into it. Paul On 11/21/11 5:41 PM, Phil Race wrote: > Hmm, I just realised I didn't read properly and I now see that > "The AWT/client code is however taken from the BSD forest." > > In other words, these aren't from the macos x port as I'd supposed. > That explains a lot and this is maybe even worse than I'd first realised. > > If these changes are based on the bsd port, I can't be sure without > checking if > the same files in the same places are even touched in the current > macos x port. > And likely not in the same way .. so the "client folks" might not > even notice these vestiges. > And there's enough to do without finding and un-doing or re-doing > these .. > > It is the shared code changes that concern me most as its not like > we'll just "rm" > that like you could rm the src/bsd directory .. > > Although I also see a whole bunch of new src/solaris files (inc. many > for sound) > What's that about ? > > I'm really (really) uncomfortable with pushing this into mainline. > My strong recommendation is to reconsider this whole thing as I > believe its going > to pollute mainline big time. I think its a big mistake. > > -phil. > > On 11/21/2011 2:08 PM, Michael McMahon wrote: >> Phil, >> >> Thanks for looking at this. The client code in this webrev was >> intended just as a temporary >> version to get a basic system up and running. I was thinking that the >> client folks would replace >> it all en-masse when they are ready. Hence, the fact that some recent >> changes might be missing, >> or otherwise not of ideal quality, might not be such a serious >> problem. In any case, I'll look >> at all of these points and make the changes. >> >> Thanks, >> Michael. >> >> On 21/11/11 18:53, Phil Race wrote: >>> Michael, >>> >>> Thanks for preparing this so we can see what the delta is. I have a >>> few comments from >>> a very quick skim over this >>> >>> This includes a whole bunch of "isBSD" checks and the like which I >>> don't think belong in mainline. >>> >>> There also seems to be a bit of schizophrenia around what >>> System.getProperty("os.name"); >>> should return. In one place I see "Mac OS X" >>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/print/PSPrinterJob.java.sdiff.html >>> >>> here I see "Darwin" >>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/font/FontUtilities.java.sdiff.html >>> >>> >>> I'm also a bit concerned by what looks like its going to remove some >>> only recently added code here :- >>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/awt/FontConfiguration.java.sdiff.html >>> >>> >>> And there "not so clean" comments and changes in shared 2D code >>> where some editing >>> is justified before adding to mainline, and perhaps even examination >>> as to whether its >>> the right change >>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/print/RasterPrinterJob.java.sdiff.html >>> >>> >>> The changes here >>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/native/sun/font/AccelGlyphCache.c.sdiff.html >>> >>> >>> maybe would be better to be just "#include " on all >>> platforms. >>> >>> >>> You'd obviously want to make sure it all builds properly on the >>> other platforms but I think >>> at least the Solaris and Linux builds should be OK. In fact such a >>> change was just made in JDK 8 for this case :- >>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/native/sun/awt/medialib/mlib_types.h.sdiff.html >>> >>> >>> >>> So I don't think these changes should be pushed into mainline >>> wholesale as is. >>> It needs some review by area owners and perhaps changes beyond those >>> I noticed. >>> >>> -phil. >>> >>> >>> On 11/21/2011 7:46 AM, Michael McMahon wrote: >>>> Hi, >>>> >>>> The following webrevs are an initial set of changes >>>> taken from the macosx-port forest to be applied >>>> to the jd7u-osx forest at: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ >>>> This will eventually be merged into the main jdk7u-dev forest. >>>> >>>> Hotspot has already integrated into this forest. This changeset >>>> includes >>>> the changes (in the jdk and corba) repositories that are needed to >>>> build and run >>>> openjdk on MacOSX. The AWT/client code is however taken from the >>>> BSD forest. So, the >>>> native Apple AWT/client code will be integrated later. By default, >>>> the VM will run in headless >>>> mode. To run with the X windows AWT, set the environment variable >>>> AWT_TOOLKIT to XToolkit. >>>> >>>> This is a work in progress and much remains to be done. But, it >>>> does build and run. >>>> All comments welcome. >>>> >>>> Thanks, >>>> Michael. >>>> >>>> >>>> JDK repo >>>> ===== >>>> >>>> Modified files >>>> ------------------ >>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/ >>>> >>>> New files >>>> ------------ >>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/new/ >>>> >>>> Corba repo >>>> ======= >>>> http://cr.openjdk.java.net/~michaelm/7113349/1/corba/webrev/ >>> >> > From philip.race at oracle.com Mon Nov 21 15:28:20 2011 From: philip.race at oracle.com (Phil Race) Date: Mon, 21 Nov 2011 15:28:20 -0800 Subject: webrevs for macosx changes to jdk7u-osx In-Reply-To: <4ECAD65F.1080709@oracle.com> References: <4ECA725C.3050606@oracle.com> <4ECA9E0D.1060507@oracle.com> <4ECACBF4.50007@oracle.com> <4ECAD393.90309@oracle.com> <4ECAD65F.1080709@oracle.com> Message-ID: <4ECADE94.10307@oracle.com> I understand that this isn't 7ux but ultimately this will go to the 7ux forest via an hg push, somewhere along the line before that happens all this needs to be undone. In fact it needs to be undone before we merge the macos port and definitely before we create shippable bits. It would be wiser to base the client portion off the code we are going to use (the os x port). For all I know (right now) a lot of the same changes will surface in a diff against that and then we can clean up the OS X port so a clean copy goes into 7ux for all the changes to date. -phil. On 11/21/2011 2:53 PM, Paul Hohensee wrote: > Note that Mike isn't proposing to push this into the baseline, rather > he's > proposing to push it into the jdk7u-osx development forest, which is > logically a child of jdk7u-dev. We'd like to get an X11-based build > going so everyone except the client group can get work done in the > jdk7u-osx forest. The hotspot group has already pushed a recent > version of hs23 into it. > > Paul > > On 11/21/11 5:41 PM, Phil Race wrote: >> Hmm, I just realised I didn't read properly and I now see that >> "The AWT/client code is however taken from the BSD forest." >> >> In other words, these aren't from the macos x port as I'd supposed. >> That explains a lot and this is maybe even worse than I'd first >> realised. >> >> If these changes are based on the bsd port, I can't be sure without >> checking if >> the same files in the same places are even touched in the current >> macos x port. >> And likely not in the same way .. so the "client folks" might not >> even notice these vestiges. >> And there's enough to do without finding and un-doing or re-doing >> these .. >> >> It is the shared code changes that concern me most as its not like >> we'll just "rm" >> that like you could rm the src/bsd directory .. >> >> Although I also see a whole bunch of new src/solaris files (inc. many >> for sound) >> What's that about ? >> >> I'm really (really) uncomfortable with pushing this into mainline. >> My strong recommendation is to reconsider this whole thing as I >> believe its going >> to pollute mainline big time. I think its a big mistake. >> >> -phil. >> >> On 11/21/2011 2:08 PM, Michael McMahon wrote: >>> Phil, >>> >>> Thanks for looking at this. The client code in this webrev was >>> intended just as a temporary >>> version to get a basic system up and running. I was thinking that >>> the client folks would replace >>> it all en-masse when they are ready. Hence, the fact that some >>> recent changes might be missing, >>> or otherwise not of ideal quality, might not be such a serious >>> problem. In any case, I'll look >>> at all of these points and make the changes. >>> >>> Thanks, >>> Michael. >>> >>> On 21/11/11 18:53, Phil Race wrote: >>>> Michael, >>>> >>>> Thanks for preparing this so we can see what the delta is. I have a >>>> few comments from >>>> a very quick skim over this >>>> >>>> This includes a whole bunch of "isBSD" checks and the like which I >>>> don't think belong in mainline. >>>> >>>> There also seems to be a bit of schizophrenia around what >>>> System.getProperty("os.name"); >>>> should return. In one place I see "Mac OS X" >>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/print/PSPrinterJob.java.sdiff.html >>>> >>>> here I see "Darwin" >>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/font/FontUtilities.java.sdiff.html >>>> >>>> >>>> I'm also a bit concerned by what looks like its going to remove >>>> some only recently added code here :- >>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/awt/FontConfiguration.java.sdiff.html >>>> >>>> >>>> And there "not so clean" comments and changes in shared 2D code >>>> where some editing >>>> is justified before adding to mainline, and perhaps even >>>> examination as to whether its >>>> the right change >>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/print/RasterPrinterJob.java.sdiff.html >>>> >>>> >>>> The changes here >>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/native/sun/font/AccelGlyphCache.c.sdiff.html >>>> >>>> >>>> maybe would be better to be just "#include " on all >>>> platforms. >>>> >>>> >>>> You'd obviously want to make sure it all builds properly on the >>>> other platforms but I think >>>> at least the Solaris and Linux builds should be OK. In fact such a >>>> change was just made in JDK 8 for this case :- >>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/native/sun/awt/medialib/mlib_types.h.sdiff.html >>>> >>>> >>>> >>>> So I don't think these changes should be pushed into mainline >>>> wholesale as is. >>>> It needs some review by area owners and perhaps changes beyond >>>> those I noticed. >>>> >>>> -phil. >>>> >>>> >>>> On 11/21/2011 7:46 AM, Michael McMahon wrote: >>>>> Hi, >>>>> >>>>> The following webrevs are an initial set of changes >>>>> taken from the macosx-port forest to be applied >>>>> to the jd7u-osx forest at: >>>>> http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ >>>>> This will eventually be merged into the main jdk7u-dev forest. >>>>> >>>>> Hotspot has already integrated into this forest. This changeset >>>>> includes >>>>> the changes (in the jdk and corba) repositories that are needed to >>>>> build and run >>>>> openjdk on MacOSX. The AWT/client code is however taken from the >>>>> BSD forest. So, the >>>>> native Apple AWT/client code will be integrated later. By default, >>>>> the VM will run in headless >>>>> mode. To run with the X windows AWT, set the environment variable >>>>> AWT_TOOLKIT to XToolkit. >>>>> >>>>> This is a work in progress and much remains to be done. But, it >>>>> does build and run. >>>>> All comments welcome. >>>>> >>>>> Thanks, >>>>> Michael. >>>>> >>>>> >>>>> JDK repo >>>>> ===== >>>>> >>>>> Modified files >>>>> ------------------ >>>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/ >>>>> >>>>> New files >>>>> ------------ >>>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/new/ >>>>> >>>>> Corba repo >>>>> ======= >>>>> http://cr.openjdk.java.net/~michaelm/7113349/1/corba/webrev/ >>>> >>> >> From michael.x.mcmahon at oracle.com Mon Nov 21 23:18:05 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 22 Nov 2011 07:18:05 +0000 Subject: webrevs for macosx changes to jdk7u-osx Message-ID: OK then. How about I include only changes required to build headless in this changeset, and the rest of the changes required for the X toolkit as a patch that be thrown away when the proper AWT port is ready? - Michael Phil Race wrote: >I understand that this isn't 7ux but ultimately this will go to the 7ux >forest via an hg push, >somewhere along the line before that happens all this needs to be undone. >In fact it needs to be undone before we merge the macos port and definitely >before we create shippable bits. > >It would be wiser to base the client portion off the code we are going >to use (the os x port). >For all I know (right now) a lot of the same changes will surface in a >diff against >that and then we can clean up the OS X port so a clean copy goes into 7ux >for all the changes to date. > >-phil. > >On 11/21/2011 2:53 PM, Paul Hohensee wrote: >> Note that Mike isn't proposing to push this into the baseline, rather >> he's >> proposing to push it into the jdk7u-osx development forest, which is >> logically a child of jdk7u-dev. We'd like to get an X11-based build >> going so everyone except the client group can get work done in the >> jdk7u-osx forest. The hotspot group has already pushed a recent >> version of hs23 into it. >> >> Paul >> >> On 11/21/11 5:41 PM, Phil Race wrote: >>> Hmm, I just realised I didn't read properly and I now see that >>> "The AWT/client code is however taken from the BSD forest." >>> >>> In other words, these aren't from the macos x port as I'd supposed. >>> That explains a lot and this is maybe even worse than I'd first >>> realised. >>> >>> If these changes are based on the bsd port, I can't be sure without >>> checking if >>> the same files in the same places are even touched in the current >>> macos x port. >>> And likely not in the same way .. so the "client folks" might not >>> even notice these vestiges. >>> And there's enough to do without finding and un-doing or re-doing >>> these .. >>> >>> It is the shared code changes that concern me most as its not like >>> we'll just "rm" >>> that like you could rm the src/bsd directory .. >>> >>> Although I also see a whole bunch of new src/solaris files (inc. many >>> for sound) >>> What's that about ? >>> >>> I'm really (really) uncomfortable with pushing this into mainline. >>> My strong recommendation is to reconsider this whole thing as I >>> believe its going >>> to pollute mainline big time. I think its a big mistake. >>> >>> -phil. >>> >>> On 11/21/2011 2:08 PM, Michael McMahon wrote: >>>> Phil, >>>> >>>> Thanks for looking at this. The client code in this webrev was >>>> intended just as a temporary >>>> version to get a basic system up and running. I was thinking that >>>> the client folks would replace >>>> it all en-masse when they are ready. Hence, the fact that some >>>> recent changes might be missing, >>>> or otherwise not of ideal quality, might not be such a serious >>>> problem. In any case, I'll look >>>> at all of these points and make the changes. >>>> >>>> Thanks, >>>> Michael. >>>> >>>> On 21/11/11 18:53, Phil Race wrote: >>>>> Michael, >>>>> >>>>> Thanks for preparing this so we can see what the delta is. I have a >>>>> few comments from >>>>> a very quick skim over this >>>>> >>>>> This includes a whole bunch of "isBSD" checks and the like which I >>>>> don't think belong in mainline. >>>>> >>>>> There also seems to be a bit of schizophrenia around what >>>>> System.getProperty("os.name"); >>>>> should return. In one place I see "Mac OS X" >>>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/print/PSPrinterJob.java.sdiff.html >>>>> >>>>> here I see "Darwin" >>>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/font/FontUtilities.java.sdiff.html >>>>> >>>>> >>>>> I'm also a bit concerned by what looks like its going to remove >>>>> some only recently added code here :- >>>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/awt/FontConfiguration.java.sdiff.html >>>>> >>>>> >>>>> And there "not so clean" comments and changes in shared 2D code >>>>> where some editing >>>>> is justified before adding to mainline, and perhaps even >>>>> examination as to whether its >>>>> the right change >>>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/classes/sun/print/RasterPrinterJob.java.sdiff.html >>>>> >>>>> >>>>> The changes here >>>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/native/sun/font/AccelGlyphCache.c.sdiff.html >>>>> >>>>> >>>>> maybe would be better to be just "#include " on all >>>>> platforms. >>>>> >>>>> >>>>> You'd obviously want to make sure it all builds properly on the >>>>> other platforms but I think >>>>> at least the Solaris and Linux builds should be OK. In fact such a >>>>> change was just made in JDK 8 for this case :- >>>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/src/share/native/sun/awt/medialib/mlib_types.h.sdiff.html >>>>> >>>>> >>>>> >>>>> So I don't think these changes should be pushed into mainline >>>>> wholesale as is. >>>>> It needs some review by area owners and perhaps changes beyond >>>>> those I noticed. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 11/21/2011 7:46 AM, Michael McMahon wrote: >>>>>> Hi, >>>>>> >>>>>> The following webrevs are an initial set of changes >>>>>> taken from the macosx-port forest to be applied >>>>>> to the jd7u-osx forest at: >>>>>> http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ >>>>>> This will eventually be merged into the main jdk7u-dev forest. >>>>>> >>>>>> Hotspot has already integrated into this forest. This changeset >>>>>> includes >>>>>> the changes (in the jdk and corba) repositories that are needed to >>>>>> build and run >>>>>> openjdk on MacOSX. The AWT/client code is however taken from the >>>>>> BSD forest. So, the >>>>>> native Apple AWT/client code will be integrated later. By default, >>>>>> the VM will run in headless >>>>>> mode. To run with the X windows AWT, set the environment variable >>>>>> AWT_TOOLKIT to XToolkit. >>>>>> >>>>>> This is a work in progress and much remains to be done. But, it >>>>>> does build and run. >>>>>> All comments welcome. >>>>>> >>>>>> Thanks, >>>>>> Michael. >>>>>> >>>>>> >>>>>> JDK repo >>>>>> ===== >>>>>> >>>>>> Modified files >>>>>> ------------------ >>>>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/modified/ >>>>>> >>>>>> New files >>>>>> ------------ >>>>>> http://cr.openjdk.java.net/~michaelm/7113349/1/jdk/new/ >>>>>> >>>>>> Corba repo >>>>>> ======= >>>>>> http://cr.openjdk.java.net/~michaelm/7113349/1/corba/webrev/ >>>>> >>>> >>> > From astrange at apple.com Mon Nov 21 23:45:52 2011 From: astrange at apple.com (astrange at apple.com) Date: Tue, 22 Nov 2011 07:45:52 +0000 Subject: hg: macosx-port/macosx-port/jdk: Port Java 6 fix for test java/net/DatagramSocket/Send12k.java Message-ID: <20111122074615.94A844741E@hg.openjdk.java.net> Changeset: ce91b5cb15e9 Author: astrange Date: 2011-11-22 02:45 -0500 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/ce91b5cb15e9 Port Java 6 fix for test java/net/DatagramSocket/Send12k.java ! src/solaris/native/java/net/PlainDatagramSocketImpl.c From alexander.zuev at oracle.com Tue Nov 22 02:55:54 2011 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 22 Nov 2011 10:55:54 +0000 Subject: hg: macosx-port/macosx-port/jdk: Implementation for TrayIcon.displayMessage() functionality Message-ID: <20111122105638.147AA47420@hg.openjdk.java.net> Changeset: 9bd64ea9b75b Author: leonidr Date: 2011-11-22 14:55 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/9bd64ea9b75b Implementation for TrayIcon.displayMessage() functionality ! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/macosx/native/sun/awt/CTrayIcon.m From Alan.Bateman at oracle.com Tue Nov 22 03:48:52 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Nov 2011 11:48:52 +0000 Subject: webrevs for macosx changes to jdk7u-osx In-Reply-To: <4ECA725C.3050606@oracle.com> References: <4ECA725C.3050606@oracle.com> Message-ID: <4ECB8C24.40002@oracle.com> On 21/11/2011 15:46, Michael McMahon wrote: > Hi, > > The following webrevs are an initial set of changes > taken from the macosx-port forest to be applied > to the jd7u-osx forest at: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ > This will eventually be merged into the main jdk7u-dev forest. > > Hotspot has already integrated into this forest. This changeset includes > the changes (in the jdk and corba) repositories that are needed to > build and run > openjdk on MacOSX. The AWT/client code is however taken from the BSD > forest. So, the > native Apple AWT/client code will be integrated later. By default, the > VM will run in headless > mode. To run with the X windows AWT, set the environment variable > AWT_TOOLKIT to XToolkit. > > This is a work in progress and much remains to be done. But, it does > build and run. > All comments welcome. > Thanks for getting this going. I haven't done a detailed review but I have skimmed through the webrevs and have a couple of comments, some of which are just to note areas that need closer examination. I had expected to see lots of updates to the tests but they aren't in the webrev. It would be good to get Kelly or someone from build-dev to do a pass over the make file changes. I think the launcher changes should be re-examined and probably refactored into platform specific code for the launcher. System.java/ClassLoader.java - I think we need to re-examine these changes aswell to see whether they are needed and where the best place is to support it. I agree with Phil's comment that we need to be consistent on the value of os.name. In check_code.c then _ck_ntohl seems a bit odd. I assume it has been renamed because of a conflict. src/share/native/java/lang/System.c - this needs to be re-examined/moved to platform specific code. src/share/transport/socket/socketTransport.c - this seems to be fixing a bug that isn't Mac specific and should be fixed upstream. src/solaris/native/com/sun/management/UnixOperatingSystem_md.c - this is missing implementations of several functions and I assume is on the list to examine. src/solaris/native/java/io/io_util_md.c - the addition of code to convert to Unicode NFD is a reminder that this is not the only place where this need to do done (looks like it's missing from the new code added in jdk7). src/solaris/native/java/net/Inet4AddressImpl.c - is this necessary? Would it be easier to get 7112670 back-ported into 7u? src/macosx/classes/sun/nio/ch/DefaultSelectorProvider.java - the kqueue Selector fails quite a few tests so I would suggest default to sun.nio.ch.PollSelectorProvider until those issues are fixed. Also no need for the java.nio.preferSelect property as there is a standard property (java.nio.channels.spi.SelectorProvider) defined in the specification to selector the provider. src/solaris/classes/sun/nio/fs/BsdFileStore.java - looks like the commented out code can be removed (not needed). src/solaris/classes/sun/nio/fs/BsdFileSystem.java - looks like supportedFileAttributeViews() and copyNonPosixAttributes() can be removed. src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java - looks like the getFileAttributeView and readAttributes can be removed. I hope to do a second and more detailed pass over the changes once I get time. -Alan. From sergey.bylokhov at oracle.com Tue Nov 22 06:05:35 2011 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Tue, 22 Nov 2011 14:05:35 +0000 Subject: hg: macosx-port/macosx-port/jdk: MACOSX_PORT-458: GridBagLayoutTests throw java.lang.NullPointerException. Message-ID: <20111122140550.06F9347425@hg.openjdk.java.net> Changeset: 573b9ecab9f7 Author: serb Date: 2011-11-22 18:05 +0400 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/573b9ecab9f7 MACOSX_PORT-458: GridBagLayoutTests throw java.lang.NullPointerException. ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java From costi at sync.ro Tue Nov 22 06:27:51 2011 From: costi at sync.ro (Costi) Date: Tue, 22 Nov 2011 16:27:51 +0200 Subject: Issue concerning dialog resizing Message-ID: <4ECBB167.8080206@sync.ro> Hi, There is an issue on resizing a modal dialog over a frame. The resizing icon from the bottom-right corner disappears when resizing the dialog. After the dialog is closed, the icon appears on the main frame. In most cases, the icon disappears after the first click in the frame, but sometimes it generates a JVM crash (see attachment). OS: Mac OS X 10.6.8 Best regards, Costi -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid607.log Url: http://mail.openjdk.java.net/pipermail/macosx-port-dev/attachments/20111122/0695bf47/hs_err_pid607-0001.log From michael.x.mcmahon at oracle.com Tue Nov 22 08:05:22 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 22 Nov 2011 16:05:22 +0000 Subject: webrevs for macosx changes to jdk7u-osx In-Reply-To: <4ECB8C24.40002@oracle.com> References: <4ECA725C.3050606@oracle.com> <4ECB8C24.40002@oracle.com> Message-ID: <4ECBC842.4080703@oracle.com> On 22/11/11 11:48, Alan Bateman wrote: > On 21/11/2011 15:46, Michael McMahon wrote: >> Hi, >> >> The following webrevs are an initial set of changes >> taken from the macosx-port forest to be applied >> to the jd7u-osx forest at: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ >> This will eventually be merged into the main jdk7u-dev forest. >> >> Hotspot has already integrated into this forest. This changeset includes >> the changes (in the jdk and corba) repositories that are needed to >> build and run >> openjdk on MacOSX. The AWT/client code is however taken from the BSD >> forest. So, the >> native Apple AWT/client code will be integrated later. By default, >> the VM will run in headless >> mode. To run with the X windows AWT, set the environment variable >> AWT_TOOLKIT to XToolkit. >> >> This is a work in progress and much remains to be done. But, it does >> build and run. >> All comments welcome. >> > Thanks for getting this going. I haven't done a detailed review but I > have skimmed through the webrevs and have a couple of comments, some > of which are just to note areas that need closer examination. > Thanks for the review. I'm currently re-merging with macos-port to eliminate the BSD artifacts. This will address some of the issues you mentioned below (and also from Phil yesterday). We have test script changes ready to be pushed soon after this initial version. But, I would prefer to get it working with a minimal set of changes to start with. I will ask Kelly to look at the build changes. The other points will be addressed later. - Michael > I had expected to see lots of updates to the tests but they aren't in > the webrev. > > It would be good to get Kelly or someone from build-dev to do a pass > over the make file changes. > > I think the launcher changes should be re-examined and probably > refactored into platform specific code for the launcher. > > System.java/ClassLoader.java - I think we need to re-examine these > changes aswell to see whether they are needed and where the best place > is to support it. > > I agree with Phil's comment that we need to be consistent on the value > of os.name. > > In check_code.c then _ck_ntohl seems a bit odd. I assume it has been > renamed because of a conflict. > > src/share/native/java/lang/System.c - this needs to be > re-examined/moved to platform specific code. > > src/share/transport/socket/socketTransport.c - this seems to be fixing > a bug that isn't Mac specific and should be fixed upstream. > > src/solaris/native/com/sun/management/UnixOperatingSystem_md.c - this > is missing implementations of several functions and I assume is on the > list to examine. > > src/solaris/native/java/io/io_util_md.c - the addition of code to > convert to Unicode NFD is a reminder that this is not the only place > where this need to do done (looks like it's missing from the new code > added in jdk7). > > src/solaris/native/java/net/Inet4AddressImpl.c - is this necessary? > Would it be easier to get 7112670 back-ported into 7u? > > src/macosx/classes/sun/nio/ch/DefaultSelectorProvider.java - the > kqueue Selector fails quite a few tests so I would suggest default to > sun.nio.ch.PollSelectorProvider until those issues are fixed. Also no > need for the java.nio.preferSelect property as there is a standard > property (java.nio.channels.spi.SelectorProvider) defined in the > specification to selector the provider. > > src/solaris/classes/sun/nio/fs/BsdFileStore.java - looks like the > commented out code can be removed (not needed). > > src/solaris/classes/sun/nio/fs/BsdFileSystem.java - looks like > supportedFileAttributeViews() and copyNonPosixAttributes() can be removed. > > src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java - looks like > the getFileAttributeView and readAttributes can be removed. > > I hope to do a second and more detailed pass over the changes once I > get time. > > -Alan. > > > > > > > > > > > > > > > > > > > > > > > > > > > > From scott.kovatch at oracle.com Tue Nov 22 09:22:55 2011 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 22 Nov 2011 09:22:55 -0800 Subject: Shortcuts in Swing? (question for pals from Apple) In-Reply-To: <4ECAA247.6060704@oracle.com> References: <4ECAA247.6060704@oracle.com> Message-ID: On Nov 21, 2011, at 11:11 AM, Alexander Potochkin wrote: > We have a code snippet which tests the various shortcuts in a simple Swing application, > Alt+A and Alt+B are among them. > > It turned out that when the focus is inside a JTextArea, > Alt+A works as expected but Alt+B types a special symbol. > > This behavior is different from what we have on Windows or Linux > and our testers consider it as a bug. That test is making an invalid assumption that Alt is the shortcut accelerator on all platforms, and it isn't. In fact, I consider it a bug that Alt-A does not produce '?' in that case. On the Mac, Alt maps to the option key, which is what you use in combination with other keys to type many non-ASCII Roman symbols. The equivalent behavior of Alt on Windows or Linux is the Command key. This has always been the case on the Mac. Somewhere in the Aqua L&F there is a mapping of key combinations to actions. It sounds like Alt+A may be mapped to 'select all'. > Is there any workarounds to suppress typing on Alt+B? > (Alt+B + some other magic keys?) You really don't want to change the behavior of Alt-B without a good reason, as users expect to see a character when you type Alt-B ('?'). It's hard to answer this without seeing what the test is actually looking for. > By the way, how to move the focus out of a focused JTextArea on Mac? > On windows we use Ctrl+Tab, but it doesn't work on Mac. It should be Shift+Tab. If it doesn't work that's a bug. -- Scott From Johannes.Schindelin at gmx.de Tue Nov 22 11:34:42 2011 From: Johannes.Schindelin at gmx.de (Johannes Schindelin) Date: Tue, 22 Nov 2011 13:34:42 -0600 (CST) Subject: Shortcuts in Swing? (question for pals from Apple) In-Reply-To: References: <4ECAA247.6060704@oracle.com> Message-ID: Hi Scott, On Tue, 22 Nov 2011, Scott Kovatch wrote: > On the Mac, Alt maps to the option key, which is what you use in > combination with other keys to type many non-ASCII Roman symbols. The > equivalent behavior of Alt on Windows or Linux is the Command key. This > has always been the case on the Mac. Actually, that is not true. The _Control_ key on Windows or Linux is equivalent to the Command key on MacOSX. As far as I know, there are no accelerators to open menus on MacOSX. On Windows and Linux, you frequently have underscores under one letter of the menu label (which you might only see when you hold the Alt key down in modern UIs, something I have yet to learn a good reason for) and when you hit Alt plus that letter, the corresponding menu opens. For example, it is a common assumption by a Windows/Linux person that Alt+F opens the File menu. Frankly, I miss this functionality on MacOSX -- I am one of the few people who prefers that gadget with the 105 pressable items to the gadget with only one -- but hopefully some expert will enlighten me that it exists and how I can trigger it. Ciao, Johannes From mik3hall at gmail.com Tue Nov 22 14:39:10 2011 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 22 Nov 2011 16:39:10 -0600 Subject: Shortcuts in Swing? (question for pals from Apple) In-Reply-To: References: <4ECAA247.6060704@oracle.com> Message-ID: On Nov 22, 2011, at 1:34 PM, Johannes Schindelin wrote: > Hi Scott, > > On Tue, 22 Nov 2011, Scott Kovatch wrote: > >> On the Mac, Alt maps to the option key, which is what you use in >> combination with other keys to type many non-ASCII Roman symbols. The >> equivalent behavior of Alt on Windows or Linux is the Command key. This >> has always been the case on the Mac. > > Actually, that is not true. The _Control_ key on Windows or Linux is > equivalent to the Command key on MacOSX. > > As far as I know, there are no accelerators to open menus on MacOSX. On > Windows and Linux, you frequently have underscores under one letter of the > menu label (which you might only see when you hold the Alt key down in > modern UIs, something I have yet to learn a good reason for) and when you > hit Alt plus that letter, the corresponding menu opens. > > For example, it is a common assumption by a Windows/Linux person that > Alt+F opens the File menu. > > Frankly, I miss this functionality on MacOSX -- I am one of the few people > who prefers that gadget with the 105 pressable items to the gadget with > only one -- but hopefully some expert will enlighten me that it exists and > how I can trigger it. I'm not quite sure why you even want to see the menu, other than you are used to how Windows works. Command+character should work on OS X absent the awkward visual of the menu drop down. I just tried command+o from one application and the open dialog appeared. For the java app I'm working on I appear to have been negligent and only one option shows the command symbol or 'Apple squiggle' character with the menu option, meaning it should keyboard shortcut. Trying that - Command+f, and this appears in the app console. CmdJConsole: action is Find... it works. Theres a dialog too. I'm not sure why I put out the message, this was probably 'in progress' and incomplete the last time I worked on this. But what, besides seeing the menu when you don't need to, is it that you miss? Also fwiw, the underscore just doesn't look good. I'll take the squiggle. From swpalmer at gmail.com Tue Nov 22 15:25:21 2011 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 22 Nov 2011 18:25:21 -0500 Subject: Shortcuts in Swing? (question for pals from Apple) In-Reply-To: References: <4ECAA247.6060704@oracle.com> Message-ID: <289968442351966401@unknownmsgid> On 2011-11-22, at 5:41 PM, Michael Hall wrote: > > On Nov 22, 2011, at 1:34 PM, Johannes Schindelin wrote: > >> Hi Scott, >> >> On Tue, 22 Nov 2011, Scott Kovatch wrote: >> >>> On the Mac, Alt maps to the option key, which is what you use in >>> combination with other keys to type many non-ASCII Roman symbols. The >>> equivalent behavior of Alt on Windows or Linux is the Command key. This >>> has always been the case on the Mac. >> >> Actually, that is not true. The _Control_ key on Windows or Linux is >> equivalent to the Command key on MacOSX. >> >> As far as I know, there are no accelerators to open menus on MacOSX. On >> Windows and Linux, you frequently have underscores under one letter of the >> menu label (which you might only see when you hold the Alt key down in >> modern UIs, something I have yet to learn a good reason for) and when you >> hit Alt plus that letter, the corresponding menu opens. >> >> For example, it is a common assumption by a Windows/Linux person that >> Alt+F opens the File menu. >> >> Frankly, I miss this functionality on MacOSX -- I am one of the few people >> who prefers that gadget with the 105 pressable items to the gadget with >> only one -- but hopefully some expert will enlighten me that it exists and >> how I can trigger it. > > I'm not quite sure why you even want to see the menu, other than you are used to how Windows works. > Command+character should work on OS X absent the awkward visual of the menu drop down. > I just tried command+o from one application and the open dialog appeared. > For the java app I'm working on I appear to have been negligent and only one option shows the command symbol or 'Apple squiggle' character with the menu option, meaning it should keyboard shortcut. > Trying that - Command+f, and this appears in the app console. > > CmdJConsole: action is Find... > > it works. Theres a dialog too. I'm not sure why I put out the message, this was probably 'in progress' and incomplete the last time I worked on this. > But what, besides seeing the menu when you don't need to, is it that you miss? > Also fwiw, the underscore just doesn't look good. I'll take the squiggle. > The problem is that if there is no keyboard shortcut like Cmd-O to open, then the action is completely inaccessible via the keyboard. Also if you don't remember the key you have to switch to mouse control to discover it via the menus instead of using the keyboard to navigate the menus and get the visual feedback that lets you learn what actions are available and what the keystroke is. Scott From mik3hall at gmail.com Tue Nov 22 15:31:25 2011 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 22 Nov 2011 17:31:25 -0600 Subject: Shortcuts in Swing? (question for pals from Apple) In-Reply-To: <289968442351966401@unknownmsgid> References: <4ECAA247.6060704@oracle.com> <289968442351966401@unknownmsgid> Message-ID: <55236AE0-C6E7-413D-8E99-5E6FCFAD5A66@gmail.com> On Nov 22, 2011, at 5:25 PM, Scott Palmer wrote: > The problem is that if there is no keyboard shortcut like Cmd-O to > open, then the action is completely inaccessible via the keyboard. Ah. Been a while since I did much of anything with Windows, also I tend to more often use the mouse. I thought the Windows menu items still needed to be set as well and show the underscore equivalent to the Mac command symbol. I could be remembering wrong there. I read once where you'd expect anyone you were hiring for the Mac to know all the keyboard shortcuts. Might explain why I was IBM mainframe. From david.katleman at sun.com Tue Nov 22 16:08:09 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 23 Nov 2011 00:08:09 +0000 Subject: hg: macosx-port/macosx-port: Added tag jdk7-b219 for changeset 3dace5474996 Message-ID: <20111123000809.E99004742E@hg.openjdk.java.net> Changeset: da05c2622f9b Author: katleman Date: 2011-11-22 16:01 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/rev/da05c2622f9b Added tag jdk7-b219 for changeset 3dace5474996 ! .hgtags From david.katleman at sun.com Tue Nov 22 16:08:18 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 23 Nov 2011 00:08:18 +0000 Subject: hg: macosx-port/macosx-port/corba: Added tag jdk7-b219 for changeset b66336ec335d Message-ID: <20111123000819.654C84742F@hg.openjdk.java.net> Changeset: 380d6827f711 Author: katleman Date: 2011-11-22 16:01 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/corba/rev/380d6827f711 Added tag jdk7-b219 for changeset b66336ec335d ! .hgtags From david.katleman at sun.com Tue Nov 22 16:08:29 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 23 Nov 2011 00:08:29 +0000 Subject: hg: macosx-port/macosx-port/hotspot: Added tag jdk7-b219 for changeset 1dcc5a7638f0 Message-ID: <20111123000831.213CC47430@hg.openjdk.java.net> Changeset: 552b8fc9f54d Author: katleman Date: 2011-11-22 16:01 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/552b8fc9f54d Added tag jdk7-b219 for changeset 1dcc5a7638f0 ! .hgtags From david.katleman at sun.com Tue Nov 22 16:08:40 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 23 Nov 2011 00:08:40 +0000 Subject: hg: macosx-port/macosx-port/jaxp: Added tag jdk7-b219 for changeset c7b29a21a5fd Message-ID: <20111123000840.5F0A647431@hg.openjdk.java.net> Changeset: 73fb06be0c8a Author: katleman Date: 2011-11-22 16:01 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jaxp/rev/73fb06be0c8a Added tag jdk7-b219 for changeset c7b29a21a5fd ! .hgtags From david.katleman at sun.com Tue Nov 22 16:08:50 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 23 Nov 2011 00:08:50 +0000 Subject: hg: macosx-port/macosx-port/jaxws: Added tag jdk7-b219 for changeset fe89960c4a3f Message-ID: <20111123000850.4A4CC47432@hg.openjdk.java.net> Changeset: 662c4761cc87 Author: katleman Date: 2011-11-22 16:01 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jaxws/rev/662c4761cc87 Added tag jdk7-b219 for changeset fe89960c4a3f ! .hgtags From david.katleman at sun.com Tue Nov 22 16:09:03 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 23 Nov 2011 00:09:03 +0000 Subject: hg: macosx-port/macosx-port/jdk: Added tag jdk7-b219 for changeset 573b9ecab9f7 Message-ID: <20111123000913.65F2947433@hg.openjdk.java.net> Changeset: 2a76fda3fe23 Author: katleman Date: 2011-11-22 16:01 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/2a76fda3fe23 Added tag jdk7-b219 for changeset 573b9ecab9f7 ! .hgtags From david.katleman at sun.com Tue Nov 22 16:09:25 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 23 Nov 2011 00:09:25 +0000 Subject: hg: macosx-port/macosx-port/langtools: Added tag jdk7-b219 for changeset b3cd6d13fd49 Message-ID: <20111123000927.3E47247434@hg.openjdk.java.net> Changeset: fd65eb1ab980 Author: katleman Date: 2011-11-22 16:01 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/langtools/rev/fd65eb1ab980 Added tag jdk7-b219 for changeset b3cd6d13fd49 ! .hgtags From Johannes.Schindelin at gmx.de Tue Nov 22 16:19:48 2011 From: Johannes.Schindelin at gmx.de (Johannes Schindelin) Date: Tue, 22 Nov 2011 18:19:48 -0600 (CST) Subject: Shortcuts in Swing? (question for pals from Apple) In-Reply-To: <55236AE0-C6E7-413D-8E99-5E6FCFAD5A66@gmail.com> References: <4ECAA247.6060704@oracle.com> <289968442351966401@unknownmsgid> <55236AE0-C6E7-413D-8E99-5E6FCFAD5A66@gmail.com> Message-ID: Hi Michael, On Tue, 22 Nov 2011, Michael Hall wrote: > On Nov 22, 2011, at 5:25 PM, Scott Palmer wrote: > > > The problem is that if there is no keyboard shortcut like Cmd-O to > > open, then the action is completely inaccessible via the keyboard. > > Ah. Been a while since I did much of anything with Windows, also I tend > to more often use the mouse. Having to reach over to the mouse just slows me down. I am a touch typer, and one of the applications I use regularly has way more than the 26 letters that would be easily accessible via the accelerators (even 52 -- with the Shift key -- or 51 -- Cmd+H cannot be used -- would be too few). Besides, it is very convenient if the application does not ask you to remember all the shortcuts. For example, if I need to access the "Create Mask" menu entry in the "Selection" menu in the "Edit" menu _a lot_ today (and maybe tomorrow) but not so often any other time, I really like to get used to the Alt+E S M incantation _for that day_. Please understand, however, that I have not the slightest interest in starting a flamewar about user interface design here. I don't care what others prefer. I do have my preference and if it is supported on the OS, I am happy. So if you have an answer to my original question ("How do I access menus [not menu entries] quickly via the keyboard?") I would be most grateful. Ciao, Johannes From mik3hall at gmail.com Tue Nov 22 16:29:07 2011 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 22 Nov 2011 18:29:07 -0600 Subject: Shortcuts in Swing? (question for pals from Apple) In-Reply-To: References: <4ECAA247.6060704@oracle.com> <289968442351966401@unknownmsgid> <55236AE0-C6E7-413D-8E99-5E6FCFAD5A66@gmail.com> Message-ID: On Nov 22, 2011, at 6:19 PM, Johannes Schindelin wrote: > So if you have an answer to my original question ("How do I access menus > [not menu entries] quickly via the keyboard?") I would be most grateful. Can't myself maybe someone else can. A platform specific thing unsupported on this one as far as I know. But again not a feature I would probably use if available. I can probably list the complete set of keyboard shortcuts I use cut, copy, paste select all save quit close window CTRL-C but thats getting off elsewhere. About all I use day to day. Unfortunately we seem to tend to get used to a platforms way of doing things besides having our own preferences. Or the platform has had a influence in forming our own preferences. From jean.christophe.helary at gmail.com Tue Nov 22 16:31:28 2011 From: jean.christophe.helary at gmail.com (Jean-Christophe Helary) Date: Wed, 23 Nov 2011 09:31:28 +0900 Subject: Shortcuts in Swing? (question for pals from Apple) In-Reply-To: References: <4ECAA247.6060704@oracle.com> <289968442351966401@unknownmsgid> <55236AE0-C6E7-413D-8E99-5E6FCFAD5A66@gmail.com> Message-ID: On Nov 23, 2011, at 9:19 AM, Johannes Schindelin wrote: > So if you have an answer to my original question ("How do I access menus [not menu entries] quickly via the keyboard?") I would be most grateful. System Preferences > Keyboard > Keyboard Shortcut You must have a "Move the focus to the menu bar" shortcut enabled. Use that and navigate the menus with the arrows. It is slightly less efficient than what Windows has but it works when necessary. Jean-Christophe Helary ---------------------------------------- fun: http://mac4translators.blogspot.com work: http://www.doublet.jp (ja/en > fr) tweets: http://twitter.com/brandelune From yuri.nesterenko at oracle.com Tue Nov 22 23:17:38 2011 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 23 Nov 2011 11:17:38 +0400 Subject: Shortcuts in Swing? (question for pals from Apple) In-Reply-To: <4ECB4051.7010704@oracle.com> References: <4ECAA247.6060704@oracle.com> <4ECB4051.7010704@oracle.com> Message-ID: <4ECC9E12.7060007@oracle.com> NB: I use this page for reference: Mac OS X keyboard shortcuts http://support.apple.com/kb/ht1343 Thanks, -yan > On 11/21/2011 11:11 PM, Alexander Potochkin wrote: >> Hello guys >> >> We have a code snippet which tests the various shortcuts in a simple >> Swing application, >> Alt+A and Alt+B are among them. >> >> It turned out that when the focus is inside a JTextArea, >> Alt+A works as expected but Alt+B types a special symbol. >> >> This behavior is different from what we have on Windows or Linux >> and our testers consider it as a bug. >> >> Is there any workarounds to suppress typing on Alt+B? >> (Alt+B + some other magic keys?) >> >> If not, is there a specification that counts the shortcuts that can't be >> mapped to the users action? >> >> By the way, how to move the focus out of a focused JTextArea on Mac? >> On windows we use Ctrl+Tab, but it doesn't work on Mac. >> >> Thanks much >> alexp >> >> > From wmoore40 at gmail.com Tue Nov 22 23:39:04 2011 From: wmoore40 at gmail.com (William Moore) Date: Wed, 23 Nov 2011 08:39:04 +0100 Subject: Shortcuts in Swing? (question for pals from Apple) In-Reply-To: References: Message-ID: <00A47655-D8CC-4CDF-8F0F-9879CF78354A@gmail.com> On Nov 22, 2011, at 6:19 PM, Johannes Schindelin wrote: > So if you have an answer to my original question ("How do I access > menus > [not menu entries] quickly via the keyboard?") I would be most > grateful. Hi I don't know about Lion, but on Leopard and Snow Leopard there is an option under Keyboard Shortcuts/Keyboard Navigation in System Preferences - "Move Focus to the Menu Bar". It does not go direct to individual menus so is probably not what Johannes wants, but anything else needs to be provided by individual applications. William From anthony.petrov at oracle.com Wed Nov 23 07:21:42 2011 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 23 Nov 2011 19:21:42 +0400 Subject: dlload() a library from JDK's lib/ not knowing its full path Message-ID: <4ECD0F86.7020101@oracle.com> Hello, I'm currently working on MACOSX_PORT-176 (AWT Splashscreen support), and I need to be able to dlopen() the splash screen dynamic library from the native code. The library normally goes into the lib/ subdirectory of the jdk (or jre). I've grep'ed macosx native code for other dlopen() calls and found out that we either load '0' (i.e. the current process itself), or use full path names to load a couple of common libs (notably, JavaRuntimeSupport and libGL.dylib). Apparently, in the former case we simply assume that all the necessary libs have already been loaded from Java code with a System.loadLibrary() call or an equivalent. In the case of the splash screen we can't load the library from Java because the JVM isn't started yet - the splash screen initialization code is triggered from the Java launcher code. Using dlopen("libsplashscreen.dylib"...) fails since the lib/ directory isn't in the search path for the dlopen() function. Any suggestions on how to load the library? Could I somehow retrieve the executable's path (which must be /bin/java or whatever other launcher is used) and calculate the full path for the library off it? Do I use argv[0] for that, or anything else specific to the Java launcher machinery (which I'm unfamiliar with, unfortunately)? Any other options? -- best regards, Anthony From anthony.petrov at oracle.com Wed Nov 23 08:11:55 2011 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 23 Nov 2011 20:11:55 +0400 Subject: SplashScreen and NSApplicationAWT Message-ID: <4ECD1B4B.3080908@oracle.com> Hello, Another issue with the splash screen is that it needs to display a window on the screen. For this purpose the Cocoa event loop must be started, and as such an NSApp instance be initialized. And this instance is a singleton in Cocoa. I see that there's already a custom NSApplication descendant present (the NSApplicationAWT), and we can't create and initialize it at the time of splash screen showing since the AWT dynamic library isn't loaded yet. I see two options to resolve this: 1. Move the NSApplciationAWT code into the Java launcher code. Either the splash screen code, or AWT would trigger the creation of an application instance. This approach, however, might require a lot of refactoring. 2. Use Xlib to display the splash screen. This must be the easiest solution, although it may appear a bit inconsistent to the end user (the X icon flashing in the dock, etc. - but perhaps there's a way to suppress that?) Also, I'm not sure if an Xlib-based app is able to actually initialize Cocoa later. Any thoughts on this? -- best regards, Anthony From mark at klomp.org Wed Nov 2 01:37:57 2011 From: mark at klomp.org (Mark Wielaard) Date: Wed, 02 Nov 2011 08:37:57 -0000 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: <4EAF76CE.9080907@oracle.com> References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> Message-ID: <20111102083751.GB25788@hermans.wildebeest.org> On Tue, Nov 01, 2011 at 10:04:22AM +0530, A. Sundararajan wrote: > mark.reinhold at oracle.com wrote: > >2011/10/31 4:51 -0700, mark at klomp.org: > >>Maybe it is already in the distribution legal notes somewhere, but we > >>looked and cannot find it (maybe we looked in the wrong place). Assuming > >>you are redistributing Rhino under the GPL/MPL there really should at > >>least be a conspicuous notice stating where to find the modifications > >>used to make the binary Oracle is distributing (MPL section 3.6 and/or > >>GPL section 3). > > > >That should be in the Oracle JDK 7 release notes, but I don't see it, > >so I'll ask someone to take care of it. > > Yes, we are working on updating the release note to point people to > the CloseJDK Rhino changes. That is really appreciated. Easiest for us would be just a repository with the current code, as you use it in your integration builds. Or a diff against the upstream release you made the changes to and how it integrates with the rest of the build. Thanks, Mark From luchsh at linux.vnet.ibm.com Wed Nov 9 00:01:51 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Wed, 09 Nov 2011 16:01:51 +0800 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EB37782.9010507@oracle.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> <4EB15356.9080209@oracle.com> <4EB23FD5.60108@linux.vnet.ibm.com> <4EB3664C.1050908@oracle.com> <4EB36FD3.3030306@oracle.com> <4EB37782.9010507@oracle.com> Message-ID: <4EBA336F.9060004@linux.vnet.ibm.com> On 11/04/2011 01:26 PM, David Holmes wrote: > On 4/11/2011 2:53 PM, David Holmes wrote: >> On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: >>> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu >>> 10.03. The difference still exists. >>> >>> Solaris 10: >>> $ unset TZ >>> $ date >>> Fri Nov 4 13:04:45 JST 2011 >>> $ TZ="" date >>> Fri Nov 4 13:04:53 JST 2011 >>> >>> Ubuntu 10.04: >>> $ unset TZ >>> $ date >>> Fri Nov 4 13:05:50 JST 2011 >>> $ TZ="" date >>> Fri Nov 4 04:05:55 UTC 2011 >>> >>> When the TZ value is an empty string, Ubuntu uses UTC while Solaris >>> still looks up the system default. >> >> I have to take back my comment regarding this not seeming to be platform >> specific code - it is highly platform specific! It seems that on Linux >> we are happy to report a TZ of "" but not so on Solaris. I presume this >> is an attempt to keep Java's use of TZ consistent with how other apps >> handle it on that platform. (environ(5) gives a little insight on >> Solaris as to how TZ is used.) >> >> So the key thing here is to not disturb the existing behaviour on either >> linux or Solaris - which suggests the original patch. That said I'm not >> convinced - given this is so platform specific - that simply treating >> non-linux the same as Solaris is a reasonable thing to do. I think it >> would be useful to see what the BSD/OSX port(s) had to do with this code >> - if anything. > > To answer my own queries BSD/OSX does > > 511 #if defined(__linux__) || defined(_ALLBSD_SOURCE) > 512 if (tz == NULL) { > 513 #else > 514 #ifdef __solaris__ > 515 if (tz == NULL || *tz == '\0') { > 516 #endif > 517 #endif > > so the suggested patch would at least not interfere. > > Anyway this needs input from other core-libs folk. I didn't intend to > get quite so heavily involved. ;-) > > David > ----- > > > >> David >> ----- >> >> >>> Thanks, >>> Masayoshi >>> >>> On 11/3/2011 4:16 PM, Jonathan Lu wrote: >>>> Hi Masayoshi, >>>> >>>> I did find some references about date-time related functions / TZ >>>> variables on Linux but got only a few about Solaris, so could not see >>>> any differences between those two platforms about the changes >>>> described in my patch. Have you got any links or references about >>>> these differences? I'm interested in it and may update the patch again >>>> after reading them. >>>> >>>> Thanks a lot! >>>> - Jonathan >>>> >>>> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: >>>>> Hi Jonathan, >>>>> >>>>> IIRC, the difference came from some behavioral difference between the >>>>> Linux and Solaris libc date-time functions and/or the date command, >>>>> and TimeZone_md.c tries to follow the difference. But the code was >>>>> written looooong ago. The difference may no longer exist. >>>>> >>>>> Thanks, >>>>> Masayoshi >>>>> >>>>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: >>>>>> On 11/02/2011 07:00 PM, David Holmes wrote: >>>>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>>>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>>>>>>> Hi core-libs-dev, >>>>>>>>> >>>>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from >>>>>>>>> line >>>>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>>>>>>> narrow, since it also works for some kind of OS which I'm >>>>>>>>> currently >>>>>>>>> working on, such as AIX. >>>>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave >>>>>>>>> the >>>>>>>>> "#else" to accommodate more conditions, see attachment >>>>>>>>> 'patch.diff'. I >>>>>>>>> think this may enhance the cross-platform ability, any ideas >>>>>>>>> about >>>>>>>>> this modification? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> - Jonathan Lu >>>>>>>> I'm not sure why the attachment got filtered, here paste it to the >>>>>>>> mail >>>>>>>> content directly. >>>>>>>> >>>>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 >>>>>>>> 19:06:53 >>>>>>>> 2011 -0700 >>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 >>>>>>>> 13:43:47 >>>>>>>> 2011 +0800 >>>>>>>> @@ -626,10 +626,8 @@ >>>>>>>> #ifdef __linux__ >>>>>>>> if (tz == NULL) { >>>>>>>> #else >>>>>>>> -#ifdef __solaris__ >>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>> #endif >>>>>>>> -#endif >>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>> freetz = tz; >>>>>>>> } >>>>>>> >>>>>>> I'm unclear why any of that code needs to be platform specific - is >>>>>>> an empty TZ string somehow valid on linux? I would have thought the >>>>>>> following would be platform neutral: >>>>>>> >>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>> tz = getPlatformTimeZoneID(); >>>>>>> freetz = tz; >>>>>>> } >>>>>>> >>>>>> Hi David, >>>>>> >>>>>> getenv("TZ") returns NULL when TZ environment variable is not set at >>>>>> all and returns '\0' when TZ was exported as empty string. After >>>>>> more checking for both cases, I agree with you, nothing useful can >>>>>> be retrieved from that environment variable. >>>>>> So I changed the patch to this, >>>>>> >>>>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c >>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 >>>>>> 2011 -0700 >>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 >>>>>> 2011 +0800 >>>>>> @@ -623,13 +623,7 @@ >>>>>> >>>>>> tz = getenv("TZ"); >>>>>> >>>>>> -#ifdef __linux__ >>>>>> - if (tz == NULL) { >>>>>> -#else >>>>>> -#ifdef __solaris__ >>>>>> if (tz == NULL || *tz == '\0') { >>>>>> -#endif >>>>>> -#endif >>>>>> tz = getPlatformTimeZoneID(); >>>>>> freetz = tz; >>>>>> } >>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Regards >>>>>>>> - Jonathan Lu >>>>>> Regards >>>>>> >>>>>> - Jonathan >>>>>> >>>> Copy to bsd-port-dev and macosx-port-dev lists to see if anybody here has some ideas about this issue. -Jonathan From kurt at intricatesoftware.com Wed Nov 9 19:09:22 2011 From: kurt at intricatesoftware.com (Kurt Miller) Date: Wed, 09 Nov 2011 22:09:22 -0500 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EBA336F.9060004@linux.vnet.ibm.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> <4EB15356.9080209@oracle.com> <4EB23FD5.60108@linux.vnet.ibm.com> <4EB3664C.1050908@oracle.com> <4EB36FD3.3030306@oracle.com> <4EB37782.9010507@oracle.com> <4EBA336F.9060004@linux.vnet.ibm.com> Message-ID: <4EBB4062.8050403@intricatesoftware.com> On 11/09/11 03:01, Jonathan Lu wrote: > On 11/04/2011 01:26 PM, David Holmes wrote: >> On 4/11/2011 2:53 PM, David Holmes wrote: >>> On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: >>>> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu >>>> 10.03. The difference still exists. >>>> >>>> Solaris 10: >>>> $ unset TZ >>>> $ date >>>> Fri Nov 4 13:04:45 JST 2011 >>>> $ TZ="" date >>>> Fri Nov 4 13:04:53 JST 2011 >>>> >>>> Ubuntu 10.04: >>>> $ unset TZ >>>> $ date >>>> Fri Nov 4 13:05:50 JST 2011 >>>> $ TZ="" date >>>> Fri Nov 4 04:05:55 UTC 2011 >>>> >>>> When the TZ value is an empty string, Ubuntu uses UTC while Solaris >>>> still looks up the system default. >>> >>> I have to take back my comment regarding this not seeming to be platform >>> specific code - it is highly platform specific! It seems that on Linux >>> we are happy to report a TZ of "" but not so on Solaris. I presume this >>> is an attempt to keep Java's use of TZ consistent with how other apps >>> handle it on that platform. (environ(5) gives a little insight on >>> Solaris as to how TZ is used.) >>> >>> So the key thing here is to not disturb the existing behaviour on either >>> linux or Solaris - which suggests the original patch. That said I'm not >>> convinced - given this is so platform specific - that simply treating >>> non-linux the same as Solaris is a reasonable thing to do. I think it >>> would be useful to see what the BSD/OSX port(s) had to do with this code >>> - if anything. >> >> To answer my own queries BSD/OSX does >> >> 511 #if defined(__linux__) || defined(_ALLBSD_SOURCE) >> 512 if (tz == NULL) { >> 513 #else >> 514 #ifdef __solaris__ >> 515 if (tz == NULL || *tz == '\0') { >> 516 #endif >> 517 #endif >> >> so the suggested patch would at least not interfere. >> >> Anyway this needs input from other core-libs folk. I didn't intend to >> get quite so heavily involved. ;-) >> >> David >> ----- >> >> >> >>> David >>> ----- >>> >>> >>>> Thanks, >>>> Masayoshi >>>> >>>> On 11/3/2011 4:16 PM, Jonathan Lu wrote: >>>>> Hi Masayoshi, >>>>> >>>>> I did find some references about date-time related functions / TZ >>>>> variables on Linux but got only a few about Solaris, so could not see >>>>> any differences between those two platforms about the changes >>>>> described in my patch. Have you got any links or references about >>>>> these differences? I'm interested in it and may update the patch again >>>>> after reading them. >>>>> >>>>> Thanks a lot! >>>>> - Jonathan >>>>> >>>>> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: >>>>>> Hi Jonathan, >>>>>> >>>>>> IIRC, the difference came from some behavioral difference between the >>>>>> Linux and Solaris libc date-time functions and/or the date command, >>>>>> and TimeZone_md.c tries to follow the difference. But the code was >>>>>> written looooong ago. The difference may no longer exist. >>>>>> >>>>>> Thanks, >>>>>> Masayoshi >>>>>> >>>>>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: >>>>>>> On 11/02/2011 07:00 PM, David Holmes wrote: >>>>>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>>>>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>>>>>>>> Hi core-libs-dev, >>>>>>>>>> >>>>>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from >>>>>>>>>> line >>>>>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>>>>>>>> narrow, since it also works for some kind of OS which I'm >>>>>>>>>> currently >>>>>>>>>> working on, such as AIX. >>>>>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave >>>>>>>>>> the >>>>>>>>>> "#else" to accommodate more conditions, see attachment >>>>>>>>>> 'patch.diff'. I >>>>>>>>>> think this may enhance the cross-platform ability, any ideas >>>>>>>>>> about >>>>>>>>>> this modification? >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> - Jonathan Lu >>>>>>>>> I'm not sure why the attachment got filtered, here paste it to the >>>>>>>>> mail >>>>>>>>> content directly. >>>>>>>>> >>>>>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 >>>>>>>>> 19:06:53 >>>>>>>>> 2011 -0700 >>>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 >>>>>>>>> 13:43:47 >>>>>>>>> 2011 +0800 >>>>>>>>> @@ -626,10 +626,8 @@ >>>>>>>>> #ifdef __linux__ >>>>>>>>> if (tz == NULL) { >>>>>>>>> #else >>>>>>>>> -#ifdef __solaris__ >>>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>>> #endif >>>>>>>>> -#endif >>>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>>> freetz = tz; >>>>>>>>> } >>>>>>>> >>>>>>>> I'm unclear why any of that code needs to be platform specific - is >>>>>>>> an empty TZ string somehow valid on linux? I would have thought the >>>>>>>> following would be platform neutral: >>>>>>>> >>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>> freetz = tz; >>>>>>>> } >>>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> getenv("TZ") returns NULL when TZ environment variable is not set at >>>>>>> all and returns '\0' when TZ was exported as empty string. After >>>>>>> more checking for both cases, I agree with you, nothing useful can >>>>>>> be retrieved from that environment variable. >>>>>>> So I changed the patch to this, >>>>>>> >>>>>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c >>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 >>>>>>> 2011 -0700 >>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 >>>>>>> 2011 +0800 >>>>>>> @@ -623,13 +623,7 @@ >>>>>>> >>>>>>> tz = getenv("TZ"); >>>>>>> >>>>>>> -#ifdef __linux__ >>>>>>> - if (tz == NULL) { >>>>>>> -#else >>>>>>> -#ifdef __solaris__ >>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>> -#endif >>>>>>> -#endif >>>>>>> tz = getPlatformTimeZoneID(); >>>>>>> freetz = tz; >>>>>>> } >>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> Regards >>>>>>>>> - Jonathan Lu >>>>>>> Regards >>>>>>> >>>>>>> - Jonathan >>>>>>> >>>>> > Copy to bsd-port-dev and macosx-port-dev lists to see if anybody here > has some ideas about this issue. Hi Jonathan, The above email is a bit hard to follow due to the mixture of top and bottom replies. I can confirm that OpenBSD and Mac OS X 10.5.8 follow the Linux behavior which confirms the need for platform ifdef's in this code. Seems like you need to make the following change: -#ifdef __solaris__ +#if defined(__solaris__) || defined(__AIX__) or something similar to maintain compatibility. In general the approach taken for adding BSD support was to never assume you can change other supported code paths. If your architecture follows an existing code path behavior add it like I did above. Otherwise just create a #ifdef myarch section for it. Unifying or changing another architecture's code path requires access to the arch, research and confirmation that the change is ok. Typically this may be done by writing independent test programs and running them on each arch. Regards, -Kurt From luchsh at linux.vnet.ibm.com Mon Nov 14 00:40:01 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 14 Nov 2011 16:40:01 +0800 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EBB4062.8050403@intricatesoftware.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> <4EB15356.9080209@oracle.com> <4EB23FD5.60108@linux.vnet.ibm.com> <4EB3664C.1050908@oracle.com> <4EB36FD3.3030306@oracle.com> <4EB37782.9010507@oracle.com> <4EBA336F.9060004@linux.vnet.ibm.com> <4EBB4062.8050403@intricatesoftware.com> Message-ID: <4EC0D3E1.6080807@linux.vnet.ibm.com> Hi Kurt, On 11/10/2011 11:09 AM, Kurt Miller wrote: > On 11/09/11 03:01, Jonathan Lu wrote: >> On 11/04/2011 01:26 PM, David Holmes wrote: >>> On 4/11/2011 2:53 PM, David Holmes wrote: >>>> On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: >>>>> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu >>>>> 10.03. The difference still exists. >>>>> >>>>> Solaris 10: >>>>> $ unset TZ >>>>> $ date >>>>> Fri Nov 4 13:04:45 JST 2011 >>>>> $ TZ="" date >>>>> Fri Nov 4 13:04:53 JST 2011 >>>>> >>>>> Ubuntu 10.04: >>>>> $ unset TZ >>>>> $ date >>>>> Fri Nov 4 13:05:50 JST 2011 >>>>> $ TZ="" date >>>>> Fri Nov 4 04:05:55 UTC 2011 >>>>> >>>>> When the TZ value is an empty string, Ubuntu uses UTC while Solaris >>>>> still looks up the system default. >>>> I have to take back my comment regarding this not seeming to be platform >>>> specific code - it is highly platform specific! It seems that on Linux >>>> we are happy to report a TZ of "" but not so on Solaris. I presume this >>>> is an attempt to keep Java's use of TZ consistent with how other apps >>>> handle it on that platform. (environ(5) gives a little insight on >>>> Solaris as to how TZ is used.) >>>> >>>> So the key thing here is to not disturb the existing behaviour on either >>>> linux or Solaris - which suggests the original patch. That said I'm not >>>> convinced - given this is so platform specific - that simply treating >>>> non-linux the same as Solaris is a reasonable thing to do. I think it >>>> would be useful to see what the BSD/OSX port(s) had to do with this code >>>> - if anything. >>> To answer my own queries BSD/OSX does >>> >>> 511 #if defined(__linux__) || defined(_ALLBSD_SOURCE) >>> 512 if (tz == NULL) { >>> 513 #else >>> 514 #ifdef __solaris__ >>> 515 if (tz == NULL || *tz == '\0') { >>> 516 #endif >>> 517 #endif >>> >>> so the suggested patch would at least not interfere. >>> >>> Anyway this needs input from other core-libs folk. I didn't intend to >>> get quite so heavily involved. ;-) >>> >>> David >>> ----- >>> >>> >>> >>>> David >>>> ----- >>>> >>>> >>>>> Thanks, >>>>> Masayoshi >>>>> >>>>> On 11/3/2011 4:16 PM, Jonathan Lu wrote: >>>>>> Hi Masayoshi, >>>>>> >>>>>> I did find some references about date-time related functions / TZ >>>>>> variables on Linux but got only a few about Solaris, so could not see >>>>>> any differences between those two platforms about the changes >>>>>> described in my patch. Have you got any links or references about >>>>>> these differences? I'm interested in it and may update the patch again >>>>>> after reading them. >>>>>> >>>>>> Thanks a lot! >>>>>> - Jonathan >>>>>> >>>>>> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: >>>>>>> Hi Jonathan, >>>>>>> >>>>>>> IIRC, the difference came from some behavioral difference between the >>>>>>> Linux and Solaris libc date-time functions and/or the date command, >>>>>>> and TimeZone_md.c tries to follow the difference. But the code was >>>>>>> written looooong ago. The difference may no longer exist. >>>>>>> >>>>>>> Thanks, >>>>>>> Masayoshi >>>>>>> >>>>>>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: >>>>>>>> On 11/02/2011 07:00 PM, David Holmes wrote: >>>>>>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>>>>>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>>>>>>>>> Hi core-libs-dev, >>>>>>>>>>> >>>>>>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from >>>>>>>>>>> line >>>>>>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>>>>>>>>> narrow, since it also works for some kind of OS which I'm >>>>>>>>>>> currently >>>>>>>>>>> working on, such as AIX. >>>>>>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave >>>>>>>>>>> the >>>>>>>>>>> "#else" to accommodate more conditions, see attachment >>>>>>>>>>> 'patch.diff'. I >>>>>>>>>>> think this may enhance the cross-platform ability, any ideas >>>>>>>>>>> about >>>>>>>>>>> this modification? >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> - Jonathan Lu >>>>>>>>>> I'm not sure why the attachment got filtered, here paste it to the >>>>>>>>>> mail >>>>>>>>>> content directly. >>>>>>>>>> >>>>>>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>>>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 >>>>>>>>>> 19:06:53 >>>>>>>>>> 2011 -0700 >>>>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 >>>>>>>>>> 13:43:47 >>>>>>>>>> 2011 +0800 >>>>>>>>>> @@ -626,10 +626,8 @@ >>>>>>>>>> #ifdef __linux__ >>>>>>>>>> if (tz == NULL) { >>>>>>>>>> #else >>>>>>>>>> -#ifdef __solaris__ >>>>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>>>> #endif >>>>>>>>>> -#endif >>>>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>>>> freetz = tz; >>>>>>>>>> } >>>>>>>>> I'm unclear why any of that code needs to be platform specific - is >>>>>>>>> an empty TZ string somehow valid on linux? I would have thought the >>>>>>>>> following would be platform neutral: >>>>>>>>> >>>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>>> freetz = tz; >>>>>>>>> } >>>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> getenv("TZ") returns NULL when TZ environment variable is not set at >>>>>>>> all and returns '\0' when TZ was exported as empty string. After >>>>>>>> more checking for both cases, I agree with you, nothing useful can >>>>>>>> be retrieved from that environment variable. >>>>>>>> So I changed the patch to this, >>>>>>>> >>>>>>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c >>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 >>>>>>>> 2011 -0700 >>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 >>>>>>>> 2011 +0800 >>>>>>>> @@ -623,13 +623,7 @@ >>>>>>>> >>>>>>>> tz = getenv("TZ"); >>>>>>>> >>>>>>>> -#ifdef __linux__ >>>>>>>> - if (tz == NULL) { >>>>>>>> -#else >>>>>>>> -#ifdef __solaris__ >>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>> -#endif >>>>>>>> -#endif >>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>> freetz = tz; >>>>>>>> } >>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> - Jonathan Lu >>>>>>>> Regards >>>>>>>> >>>>>>>> - Jonathan >>>>>>>> >> Copy to bsd-port-dev and macosx-port-dev lists to see if anybody here >> has some ideas about this issue. > Hi Jonathan, > > The above email is a bit hard to follow due to the mixture of top and > bottom replies. > > I can confirm that OpenBSD and Mac OS X 10.5.8 follow the Linux behavior > which confirms the need for platform ifdef's in this code. > > Seems like you need to make the following change: > > -#ifdef __solaris__ > +#if defined(__solaris__) || defined(__AIX__) > > or something similar to maintain compatibility. > > In general the approach taken for adding BSD support was to never > assume you can change other supported code paths. If your architecture > follows an existing code path behavior add it like I did above. > Otherwise just create a #ifdef myarch section for it. > But for this case, I think it is a good idea to leave a default code path here. Since in src/solaris/native/java/util/TimeZone_md.c starting from line 624, the return value of getenv("TZ"); has to be tested afterward on any platforms. So to improve portability for OpenJDK, how about leaving Solaris style checking as the default approach? > Unifying or changing another architecture's code path requires access > to the arch, research and confirmation that the change is ok. Typically > this may be done by writing independent test programs and running them > on each arch. > > Regards, > -Kurt > > > From kurt at intricatesoftware.com Mon Nov 14 10:22:39 2011 From: kurt at intricatesoftware.com (Kurt Miller) Date: Mon, 14 Nov 2011 14:22:39 -0400 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EC0D3E1.6080807@linux.vnet.ibm.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EBB4062.8050403@intricatesoftware.com> <4EC0D3E1.6080807@linux.vnet.ibm.com> Message-ID: <201111141322.40010.kurt@intricatesoftware.com> On Monday 14 November 2011 03:40:01 am Jonathan Lu wrote: > Hi Kurt, > > On 11/10/2011 11:09 AM, Kurt Miller wrote: > > On 11/09/11 03:01, Jonathan Lu wrote: > >> On 11/04/2011 01:26 PM, David Holmes wrote: > >>> On 4/11/2011 2:53 PM, David Holmes wrote: > >>>> On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: > >>>>> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu > >>>>> 10.03. The difference still exists. > >>>>> > >>>>> Solaris 10: > >>>>> $ unset TZ > >>>>> $ date > >>>>> Fri Nov 4 13:04:45 JST 2011 > >>>>> $ TZ="" date > >>>>> Fri Nov 4 13:04:53 JST 2011 > >>>>> > >>>>> Ubuntu 10.04: > >>>>> $ unset TZ > >>>>> $ date > >>>>> Fri Nov 4 13:05:50 JST 2011 > >>>>> $ TZ="" date > >>>>> Fri Nov 4 04:05:55 UTC 2011 > >>>>> > >>>>> When the TZ value is an empty string, Ubuntu uses UTC while Solaris > >>>>> still looks up the system default. > >>>> I have to take back my comment regarding this not seeming to be platform > >>>> specific code - it is highly platform specific! It seems that on Linux > >>>> we are happy to report a TZ of "" but not so on Solaris. I presume this > >>>> is an attempt to keep Java's use of TZ consistent with how other apps > >>>> handle it on that platform. (environ(5) gives a little insight on > >>>> Solaris as to how TZ is used.) > >>>> > >>>> So the key thing here is to not disturb the existing behaviour on either > >>>> linux or Solaris - which suggests the original patch. That said I'm not > >>>> convinced - given this is so platform specific - that simply treating > >>>> non-linux the same as Solaris is a reasonable thing to do. I think it > >>>> would be useful to see what the BSD/OSX port(s) had to do with this code > >>>> - if anything. > >>> To answer my own queries BSD/OSX does > >>> > >>> 511 #if defined(__linux__) || defined(_ALLBSD_SOURCE) > >>> 512 if (tz == NULL) { > >>> 513 #else > >>> 514 #ifdef __solaris__ > >>> 515 if (tz == NULL || *tz == '\0') { > >>> 516 #endif > >>> 517 #endif > >>> > >>> so the suggested patch would at least not interfere. > >>> > >>> Anyway this needs input from other core-libs folk. I didn't intend to > >>> get quite so heavily involved. ;-) > >>> > >>> David > >>> ----- > >>> > >>> > >>> > >>>> David > >>>> ----- > >>>> > >>>> > >>>>> Thanks, > >>>>> Masayoshi > >>>>> > >>>>> On 11/3/2011 4:16 PM, Jonathan Lu wrote: > >>>>>> Hi Masayoshi, > >>>>>> > >>>>>> I did find some references about date-time related functions / TZ > >>>>>> variables on Linux but got only a few about Solaris, so could not see > >>>>>> any differences between those two platforms about the changes > >>>>>> described in my patch. Have you got any links or references about > >>>>>> these differences? I'm interested in it and may update the patch again > >>>>>> after reading them. > >>>>>> > >>>>>> Thanks a lot! > >>>>>> - Jonathan > >>>>>> > >>>>>> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: > >>>>>>> Hi Jonathan, > >>>>>>> > >>>>>>> IIRC, the difference came from some behavioral difference between the > >>>>>>> Linux and Solaris libc date-time functions and/or the date command, > >>>>>>> and TimeZone_md.c tries to follow the difference. But the code was > >>>>>>> written looooong ago. The difference may no longer exist. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Masayoshi > >>>>>>> > >>>>>>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: > >>>>>>>> On 11/02/2011 07:00 PM, David Holmes wrote: > >>>>>>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: > >>>>>>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: > >>>>>>>>>>> Hi core-libs-dev, > >>>>>>>>>>> > >>>>>>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from > >>>>>>>>>>> line > >>>>>>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too > >>>>>>>>>>> narrow, since it also works for some kind of OS which I'm > >>>>>>>>>>> currently > >>>>>>>>>>> working on, such as AIX. > >>>>>>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave > >>>>>>>>>>> the > >>>>>>>>>>> "#else" to accommodate more conditions, see attachment > >>>>>>>>>>> 'patch.diff'. I > >>>>>>>>>>> think this may enhance the cross-platform ability, any ideas > >>>>>>>>>>> about > >>>>>>>>>>> this modification? > >>>>>>>>>>> > >>>>>>>>>>> Regards > >>>>>>>>>>> - Jonathan Lu > >>>>>>>>>> I'm not sure why the attachment got filtered, here paste it to the > >>>>>>>>>> mail > >>>>>>>>>> content directly. > >>>>>>>>>> > >>>>>>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c > >>>>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 > >>>>>>>>>> 19:06:53 > >>>>>>>>>> 2011 -0700 > >>>>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 > >>>>>>>>>> 13:43:47 > >>>>>>>>>> 2011 +0800 > >>>>>>>>>> @@ -626,10 +626,8 @@ > >>>>>>>>>> #ifdef __linux__ > >>>>>>>>>> if (tz == NULL) { > >>>>>>>>>> #else > >>>>>>>>>> -#ifdef __solaris__ > >>>>>>>>>> if (tz == NULL || *tz == '\0') { > >>>>>>>>>> #endif > >>>>>>>>>> -#endif > >>>>>>>>>> tz = getPlatformTimeZoneID(); > >>>>>>>>>> freetz = tz; > >>>>>>>>>> } > >>>>>>>>> I'm unclear why any of that code needs to be platform specific - is > >>>>>>>>> an empty TZ string somehow valid on linux? I would have thought the > >>>>>>>>> following would be platform neutral: > >>>>>>>>> > >>>>>>>>> if (tz == NULL || *tz == '\0') { > >>>>>>>>> tz = getPlatformTimeZoneID(); > >>>>>>>>> freetz = tz; > >>>>>>>>> } > >>>>>>>>> > >>>>>>>> Hi David, > >>>>>>>> > >>>>>>>> getenv("TZ") returns NULL when TZ environment variable is not set at > >>>>>>>> all and returns '\0' when TZ was exported as empty string. After > >>>>>>>> more checking for both cases, I agree with you, nothing useful can > >>>>>>>> be retrieved from that environment variable. > >>>>>>>> So I changed the patch to this, > >>>>>>>> > >>>>>>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c > >>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 > >>>>>>>> 2011 -0700 > >>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 > >>>>>>>> 2011 +0800 > >>>>>>>> @@ -623,13 +623,7 @@ > >>>>>>>> > >>>>>>>> tz = getenv("TZ"); > >>>>>>>> > >>>>>>>> -#ifdef __linux__ > >>>>>>>> - if (tz == NULL) { > >>>>>>>> -#else > >>>>>>>> -#ifdef __solaris__ > >>>>>>>> if (tz == NULL || *tz == '\0') { > >>>>>>>> -#endif > >>>>>>>> -#endif > >>>>>>>> tz = getPlatformTimeZoneID(); > >>>>>>>> freetz = tz; > >>>>>>>> } > >>>>>>>> > >>>>>>>>> David > >>>>>>>>> ----- > >>>>>>>>> > >>>>>>>>>> Regards > >>>>>>>>>> - Jonathan Lu > >>>>>>>> Regards > >>>>>>>> > >>>>>>>> - Jonathan > >>>>>>>> > >> Copy to bsd-port-dev and macosx-port-dev lists to see if anybody here > >> has some ideas about this issue. > > Hi Jonathan, > > > > The above email is a bit hard to follow due to the mixture of top and > > bottom replies. > > > > I can confirm that OpenBSD and Mac OS X 10.5.8 follow the Linux behavior > > which confirms the need for platform ifdef's in this code. > > > > Seems like you need to make the following change: > > > > -#ifdef __solaris__ > > +#if defined(__solaris__) || defined(__AIX__) > > > > or something similar to maintain compatibility. > > > > In general the approach taken for adding BSD support was to never > > assume you can change other supported code paths. If your architecture > > follows an existing code path behavior add it like I did above. > > Otherwise just create a #ifdef myarch section for it. > > > > But for this case, I think it is a good idea to leave a default code > path here. > Since in src/solaris/native/java/util/TimeZone_md.c starting from line > 624, the return value of getenv("TZ"); has to be tested afterward on any > platforms. > So to improve portability for OpenJDK, how about leaving Solaris style > checking as the default approach? Ah I see what you're getting at now. As a bsd-port only committer my opinion has limited value, but for what its worth I can give you my perspective on the issue. The code base is large and there are many places like this where unifying the behavior of different archs is the goal. Keeping with the non-configure approach where ifdef __MYARCH__ is used for differing behaviors then I see the ideal situation being that the porter/developer is required to make the correct choice for the new __MYARCH__ and no default be assumed. If a default behavior is assumed, which one do you pick? Also what happens when your done porting but many of the defaults don't match your new arch? I can tell you it is a lot of work to find the bits of code embedded into the jdk code base to fix when the TCK fails tests. I rather do that work up front and be forced to pick the correct behavior due to a failure to compile. For example, had this code compiled for you it is quite posible you would not have know that there are different behaviors to pick from and to select the correct one for you. Regards, -Kurt From yuri.nesterenko at oracle.com Mon Nov 21 22:25:21 2011 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Tue, 22 Nov 2011 10:25:21 +0400 Subject: Shortcuts in Swing? (question for pals from Apple) In-Reply-To: <4ECAA247.6060704@oracle.com> References: <4ECAA247.6060704@oracle.com> Message-ID: <4ECB4051.7010704@oracle.com> NB: I use this page for reference: Mac OS X keyboard shortcuts http://support.apple.com/kb/ht1343 Thanks, -yan On 11/21/2011 11:11 PM, Alexander Potochkin wrote: > Hello guys > > We have a code snippet which tests the various shortcuts in a simple > Swing application, > Alt+A and Alt+B are among them. > > It turned out that when the focus is inside a JTextArea, > Alt+A works as expected but Alt+B types a special symbol. > > This behavior is different from what we have on Windows or Linux > and our testers consider it as a bug. > > Is there any workarounds to suppress typing on Alt+B? > (Alt+B + some other magic keys?) > > If not, is there a specification that counts the shortcuts that can't be > mapped to the users action? > > By the way, how to move the focus out of a focused JTextArea on Mac? > On windows we use Ctrl+Tab, but it doesn't work on Mac. > > Thanks much > alexp > > From alexander.potochkin at sun.com Wed Nov 23 09:30:56 2011 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Wed, 23 Nov 2011 17:30:56 +0000 Subject: hg: macosx-port/macosx-port/jdk: fixed #723: JTabbedPane throws ArrayIndexOutOfBoundsException Message-ID: <20111123173107.4D5C94743D@hg.openjdk.java.net> Changeset: 7d24f1f92b5f Author: alexp Date: 2011-11-23 20:52 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/7d24f1f92b5f fixed #723: JTabbedPane throws ArrayIndexOutOfBoundsException ! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java From philip.race at oracle.com Wed Nov 23 10:30:54 2011 From: philip.race at oracle.com (Phil Race) Date: Wed, 23 Nov 2011 10:30:54 -0800 Subject: SplashScreen and NSApplicationAWT In-Reply-To: <4ECD1B4B.3080908@oracle.com> References: <4ECD1B4B.3080908@oracle.com> Message-ID: <4ECD3BDE.6080200@oracle.com> I suspect you'll have to do something like #1. Previous advice on another topic is not to rely on X11. Sounds like a hybrid monster in any case. My gut is that this is something to steer well clear of. Is it possible for an app to start a cocoa event loop for splashscreen, then exit that when AWT is ready to launch .. and start up the real one ? I'm afraid the answer here will probably be no .. and its probably impossible to do whilst keeping the splashscreen visible, but its worth asking. -phil. On 11/23/2011 8:11 AM, Anthony Petrov wrote: > Hello, > > Another issue with the splash screen is that it needs to display a > window on the screen. For this purpose the Cocoa event loop must be > started, and as such an NSApp instance be initialized. And this > instance is a singleton in Cocoa. > > I see that there's already a custom NSApplication descendant present > (the NSApplicationAWT), and we can't create and initialize it at the > time of splash screen showing since the AWT dynamic library isn't > loaded yet. > > I see two options to resolve this: > > 1. Move the NSApplciationAWT code into the Java launcher code. Either > the splash screen code, or AWT would trigger the creation of an > application instance. This approach, however, might require a lot of > refactoring. > > 2. Use Xlib to display the splash screen. This must be the easiest > solution, although it may appear a bit inconsistent to the end user > (the X icon flashing in the dock, etc. - but perhaps there's a way to > suppress that?) Also, I'm not sure if an Xlib-based app is able to > actually initialize Cocoa later. > > Any thoughts on this? > > -- > best regards, > Anthony From dalibor.topic at oracle.com Wed Nov 23 15:40:21 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 24 Nov 2011 00:40:21 +0100 Subject: Fwd: JDK 7 Mac Port Preview b219 Available In-Reply-To: <4ECD2F7D.5030901@oracle.com> References: <4ECD2F7D.5030901@oracle.com> Message-ID: <4ECD8465.1060009@oracle.com> Roger seems to be having some trouble posting to this list, so I'm forwarding this one for him. cheers, dalibor topic -------- Original Message -------- Subject: JDK 7 Mac Port Preview b219 Available Date: Wed, 23 Nov 2011 09:38:05 -0800 From: Roger Lewis To: macosx-port-dev at openjdk.java.net CC: Dalibor Topic Hi, The JDK 7 Mac Port Preview b219 is now available: http://jdk7.java.net/macportpreview/ Regards, Roger L. (temporarily filling in for Roger Yeung) -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 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 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From astrange at apple.com Wed Nov 23 22:36:21 2011 From: astrange at apple.com (Alexander Strange) Date: Thu, 24 Nov 2011 01:36:21 -0500 Subject: Illegal Instruction in debug_build In-Reply-To: <83D80E9F-5946-4922-9929-C35CDA0094DE@oracle.com> References: <3A0D0B72-80EF-4DDB-ABCE-E5AC79637E0B@oracle.com> <83D80E9F-5946-4922-9929-C35CDA0094DE@oracle.com> Message-ID: <3B08A452-FD2F-44C0-963B-0031B95A5524@apple.com> I assume this thread is discussing building something besides macosx-port on OS X. I fixed this in the debug build in macosx-port hotspot here: http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/51d10977410a Your code seems to be failing because of a compiler bug. That said, the LLVM developers recommend against the use of register variables. On Oct 15, 2011, at 7:23 PM, John Rose wrote: > I don't know the ins and outs of asm and grabbing rsp on Mac, but the OS X port group probably know something about it. -- John > > On Oct 15, 2011, at 8:49 AM, Michael Barker wrote: > >> Good luck! > > Thanks. I found where the problem is, it's in the > os::current_stack_pointer method in os_bsd_x86.cpp and it depends on > level of compilation. If I compile the code below without > optimisation e.g.: > > #include > > class os { > public: > void* current_stack_pointer(); > }; > > void* os::current_stack_pointer() { > register void *esp __asm__ ("rsp"); > return esp; > } > > int main() { > os o = os(); > printf("%p\n", o.current_stack_pointer()); > } > > # g++ test.cc -o test > > It will generate the following assembly: > > __ZN2os21current_stack_pointerEv: > 0000000000000000 pushq %rbp > 0000000000000001 movq %rsp,%rbp > 0000000000000004 movq %rdi,0xf8(%rbp) > 0000000000000008 movq 0xe0(%rbp),%rax > 000000000000000c movq %rax,%rsp > 000000000000000f movq %rsp,%rax > 0000000000000012 movq %rax,0xe8(%rbp) > 0000000000000016 movq 0xe8(%rbp),%rax > 000000000000001a movq %rax,0xf0(%rbp) > 000000000000001e movq 0xf0(%rbp),%rax > 0000000000000022 popq %rbp > > And will fail with an illegal instruction. If optimisation is added > (-O1 is sufficient) it works fine: > > # g++ -O1 test.cc -o test > > And the generated assembly looks far more sane: > > 0000000000000000 pushq %rbp > 0000000000000001 movq %rsp,%rbp > 0000000000000004 movq %rsp,%rax > 0000000000000007 popq %rbp > 0000000000000008 ret > > So I've added -01 to the debug flags in > hotspot/make/bsd/makefiles/gcc.make and it now seems to run okay. I'm > not sure that it's the best fix. Is there are better way to get hold > of the stack pointer? I.e. one that doesn't get stomped over by a > lack of optimisation :-). Not sure if this specific to Mac OS 7 or > gcc 4.2. > > Mike. > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From andrew.brygin at oracle.com Thu Nov 24 01:16:51 2011 From: andrew.brygin at oracle.com (andrew.brygin at oracle.com) Date: Thu, 24 Nov 2011 09:16:51 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fix for MACOSX_PORT-705: In HeadlessFont test, UnsatisfiedLinkError: sun.font.CFontManager.loadNativeDirFonts Message-ID: <20111124091714.9970847442@hg.openjdk.java.net> Changeset: 8de4156325d2 Author: bae Date: 2011-11-24 12:16 +0300 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/8de4156325d2 Fix for MACOSX_PORT-705: In HeadlessFont test, UnsatisfiedLinkError: sun.font.CFontManager.loadNativeDirFonts ! src/solaris/native/sun/awt/awt_LoadLibrary.c From mikeb01 at gmail.com Thu Nov 24 01:00:48 2011 From: mikeb01 at gmail.com (Michael Barker) Date: Thu, 24 Nov 2011 09:00:48 +0000 Subject: Illegal Instruction in debug_build In-Reply-To: <3B08A452-FD2F-44C0-963B-0031B95A5524@apple.com> References: <3A0D0B72-80EF-4DDB-ABCE-E5AC79637E0B@oracle.com> <83D80E9F-5946-4922-9929-C35CDA0094DE@oracle.com> <3B08A452-FD2F-44C0-963B-0031B95A5524@apple.com> Message-ID: Hi, Yes I'm compiling mlvm which is a set of patches on the hotspot tree. I noticed that fix has recently made it's way through to the hotspot branch. However, I'm compiling against gcc 4.2 therefore the compiler falls through to the default case on the ifdef and hits the illegal instruction bug. The fix I'm using locally looks like: address os::current_stack_pointer() { #if defined(SPARC_WORKS) register void *esp; __asm__("mov %%"SPELL_REG_SP", %0":"=r"(esp)); return (address) ((char*)esp + sizeof(long)*2); #else register void *esp; __asm__("mov %%"SPELL_REG_SP", %0":"=r"(esp)); return (address) esp; #endif } And similar for "_get_previous_fp()" in os_bsd_x86.cpp. I'm not sure what the correct fix is here. Should I be using clang instead of gcc 4.2 or should there be an additional option on the #ifdef, e.g. if defined(__clang__) || defined(__llvm__) || defined(__gcc42__)? Mike. On Thu, Nov 24, 2011 at 6:36 AM, Alexander Strange wrote: > I assume this thread is discussing building something besides macosx-port on OS X. > > I fixed this in the debug build in macosx-port hotspot here: > http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/51d10977410a > > Your code seems to be failing because of a compiler bug. That said, the LLVM developers recommend against the use of register variables. > > On Oct 15, 2011, at 7:23 PM, John Rose wrote: > >> I don't know the ins and outs of asm and grabbing rsp on Mac, but the OS X port group probably know something about it. ?-- John >> >> On Oct 15, 2011, at 8:49 AM, Michael Barker wrote: >> >>> Good luck! >> >> Thanks. ?I found where the problem is, it's in the >> os::current_stack_pointer method in os_bsd_x86.cpp and it depends on >> level of compilation. ?If I compile the code below without >> optimisation e.g.: >> >> #include >> >> class os { >> public: >> ? void* current_stack_pointer(); >> }; >> >> void* os::current_stack_pointer() { >> register void *esp __asm__ ("rsp"); >> return esp; >> } >> >> int main() { >> os o = os(); >> printf("%p\n", o.current_stack_pointer()); >> } >> >> # g++ test.cc -o test >> >> It will generate the following assembly: >> >> __ZN2os21current_stack_pointerEv: >> 0000000000000000 ? ? ?pushq ? %rbp >> 0000000000000001 ? ? ?movq ? ?%rsp,%rbp >> 0000000000000004 ? ? ?movq ? ?%rdi,0xf8(%rbp) >> 0000000000000008 ? ? ?movq ? ?0xe0(%rbp),%rax >> 000000000000000c ? ? ?movq ? ?%rax,%rsp >> 000000000000000f ? ? ?movq ? ?%rsp,%rax >> 0000000000000012 ? ? ?movq ? ?%rax,0xe8(%rbp) >> 0000000000000016 ? ? ?movq ? ?0xe8(%rbp),%rax >> 000000000000001a ? ? ?movq ? ?%rax,0xf0(%rbp) >> 000000000000001e ? ? ?movq ? ?0xf0(%rbp),%rax >> 0000000000000022 ? ? ?popq ? ?%rbp >> >> And will fail with an illegal instruction. ?If optimisation is added >> (-O1 is sufficient) it works fine: >> >> # g++ -O1 test.cc -o test >> >> And the generated assembly looks far more sane: >> >> 0000000000000000 ? ? ?pushq ? %rbp >> 0000000000000001 ? ? ?movq ? ?%rsp,%rbp >> 0000000000000004 ? ? ?movq ? ?%rsp,%rax >> 0000000000000007 ? ? ?popq ? ?%rbp >> 0000000000000008 ? ? ?ret >> >> So I've added -01 to the debug flags in >> hotspot/make/bsd/makefiles/gcc.make and it now seems to run okay. ?I'm >> not sure that it's the best fix. ?Is there are better way to get hold >> of the stack pointer? ?I.e. one that doesn't get stomped over by a >> lack of optimisation :-). ?Not sure if this specific to Mac OS 7 or >> gcc 4.2. >> >> Mike. >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From neugens.limasoftware at gmail.com Mon Nov 28 04:26:09 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 28 Nov 2011 13:26:09 +0100 Subject: SunGraphics2D instead of Graphics2D In-Reply-To: <3A736034-C9BE-4D9C-B18C-07AE449A33DC@gmail.com> References: <4ECA832A.4030307@oracle.com> <3A736034-C9BE-4D9C-B18C-07AE449A33DC@gmail.com> Message-ID: <7DA8EE55-FCD1-4A57-8E0F-F04175936F2D@gmail.com> Il giorno 21/nov/2011, alle ore 21:48, Mario Torre ha scritto: > Il giorno 21/nov/2011, alle ore 21:06, Mike Swingler ha scritto: >> I don't think we had any specific reason to cast SunGraphics2D instead of just Graphics2D. Feel free to change the casts. >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On Nov 21, 2011, at 8:58 AM, Alexander Potochkin wrote: >> >>> Hello Mario >>> >>> Your patch looks very logic, >>> let me ask the Apple guys what were the reasons behind that SunGraphics2D cast >>> >>> Thanks! >>> alexp > > Hi Mike, Alex, > > Thanks for the review. > > Should I commit by myself directly? If so, this is the first time I commit to the OSX branch, I'm not sure what the rules are here (do I need a bug id, a special commit repository etc...) > > Cheers, > Mario Hi all, Can you please give me some indication how to proceed with this one? Thanks a lot, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com 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 michael.x.mcmahon at oracle.com Mon Nov 28 08:08:35 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 28 Nov 2011 16:08:35 +0000 Subject: webrevs.2 for macosx changes to jdk7u-osx Message-ID: <4ED3B203.4060602@oracle.com> Hi, Here is another version of the macosx webrev. This time it includes all of the modifications and new files from macosx-port. Hence many of the problems pointed out earlier with the inconsistencies relative to the bsd code are gone now. It builds and runs on all platforms and has been synced with jdk7u-dev (as of Friday Nov 25). I left the // MacOSX comments in to highlight changes that people may want to look at more closely. Lastly, this time I have also included a webrev showing the changes relative to macosx-port for reference. Changes relative to jdk7u-osx http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ New files http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ Changes relative to macosx-port http://cr.openjdk.java.net/~michaelm/7113349/2/macosx-port/modified/ Thanks, Michael. From michael.x.mcmahon at oracle.com Mon Nov 28 08:19:59 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 28 Nov 2011 16:19:59 +0000 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED3B203.4060602@oracle.com> References: <4ED3B203.4060602@oracle.com> Message-ID: <4ED3B4AF.8020608@oracle.com> On 28/11/11 16:08, Michael McMahon wrote: > Hi, > > > New files > http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ > Sorry, the link above for new files should be: http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/new/ From anthony.petrov at oracle.com Mon Nov 28 11:57:09 2011 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 28 Nov 2011 23:57:09 +0400 Subject: SplashScreen and NSApplication instance initialization Message-ID: <4ED3E795.30404@oracle.com> Hi Mike et al., For the SplashScreen we need to initialize an instance of NSApplication before JVM (and hence AWT) are loaded. I'm trying to move the code from the NSApplicationAWT.m into the Java launcher code so that it would be shared by both the splashscreen library and the AWT. The problem I've encountered is that certain settings are retrieved from the JVM properties: // needed by registerWithProcessManager: apple.awt.application.name sun.java.launcher apple.awt.UIElement apple.awt.BackgroundOnly // needed by finishLaunching: apple.awt.application.nib apple.awt.application.icon Since the JVM isn't initialized yet when the splash screen code is launching, the properties aren't available. Some parameters have alternative ways of discovery (e.g. there are more options to retrieve the application name in addition to using apple.awt.application.name, and they are all tried in the code), however, the rest of them have not such alternatives. I've made a quick test by creating a generic NSApplication instance in the splash screen code. Later, when the AWT has started (in the "embedded" mode, sort of, since the event loop has already been started by the splash screen library), I called the registerWithProcessManager and finishLaunching methods static for the NSApp (I've turned them into static methods before that so that I could apply them to any kind of NSAPplication, not only the NSApplicationAWT). This didn't do much though. The only pieces of code that seem to be useful or did anything at all seem to be a) the "// HACK BEGIN" section that helped make the app foreground and display it in the dock (although with a generic, OS-provided icon only), and b) the menu update loop at finishLaunching (which oddly added the new items rather than updated the default ones; and it didn't change the name of the application menu itself). Note that the icon in the dock wasn't updated to the Java icon, and neither was the main menu updated automatically - I had to switch to another app, and then back to my test to make the menu show. Note that the app's title was just "java". I realize that in part this is because the registerWithProcessManager should actually happen before the application instance is even constructed, but that was just a quick test. Besides, I don't understand why would the finishLaunching code not do its job properly - it just has to be executed some time after starting the event loop. Did the fact that a window has already been shown on the screen prevent it from updating the dock icon? Anyway, to make it all work right we probably need to enhance the JRSAppKitAWT interface so that it could update those values rather than register them just once. We could provide some default values from the splash screen code, and later initiate an update at the time when AWT has finally loaded. Is this possible? Another option is to declare that the mentioned properties are simply not supported in case the app uses a splash screen. After all, the properties don't seem to belong to Java specification anyway. However, it would still be cool to (at least) have a shiny Java icon in the dock and a proper application title in the main menu. How do we do that if we choose this way? -- best regards, Anthony From henri.gomez at gmail.com Tue Nov 29 00:26:39 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 29 Nov 2011 09:26:39 +0100 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED3B4AF.8020608@oracle.com> References: <4ED3B203.4060602@oracle.com> <4ED3B4AF.8020608@oracle.com> Message-ID: Does it means we could expect a macosx-port version of u2 in a near future ? 2011/11/28 Michael McMahon : > On 28/11/11 16:08, Michael McMahon wrote: >> >> Hi, >> >> >> New files >> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >> > Sorry, the link above for new files should be: > > http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/new/ > > > From artem.ananiev at oracle.com Tue Nov 29 02:07:20 2011 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 29 Nov 2011 14:07:20 +0400 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: References: <4ED3B203.4060602@oracle.com> <4ED3B4AF.8020608@oracle.com> Message-ID: <4ED4AED8.3020501@oracle.com> On 11/29/2011 12:26 PM, Henri Gomez wrote: > Does it means we could expect a macosx-port version of u2 in a near future ? jdk7u/jdk7u-osx is a kind of integration workspace for 7u4, not 7u2. See Dalibor's announcement for details: http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-October/000552.html Thanks, Artem > 2011/11/28 Michael McMahon: >> On 28/11/11 16:08, Michael McMahon wrote: >>> >>> Hi, >>> >>> >>> New files >>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >>> >> Sorry, the link above for new files should be: >> >> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/new/ >> >> >> From artem.ananiev at oracle.com Tue Nov 29 03:11:44 2011 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 29 Nov 2011 15:11:44 +0400 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED3B203.4060602@oracle.com> References: <4ED3B203.4060602@oracle.com> Message-ID: <4ED4BDF0.8060108@oracle.com> Hi, Michael, thanks for this hard work! See my comments below. I only looked at the changes related to the current macosx-port workspace. Will take a look at the webrev against 7u-osx a little bit later. On 11/28/2011 8:08 PM, Michael McMahon wrote: > Hi, > > Here is another version of the macosx webrev. This time it includes > all of the modifications and new files from macosx-port. Hence many > of the problems pointed out earlier with the inconsistencies relative to > the bsd code > are gone now. It builds and runs on all platforms and has been synced with > jdk7u-dev (as of Friday Nov 25). I left the // MacOSX comments in > to highlight changes that people may want to look at more closely. > > Lastly, this time I have also included a webrev showing the changes > relative to macosx-port > for reference. > > Changes relative to jdk7u-osx > http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ > > New files > http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ > > Changes relative to macosx-port > http://cr.openjdk.java.net/~michaelm/7113349/2/macosx-port/modified/ I haven't looked through all the files, just those that are related to client libs. One general question is about BSD support: do we really want to throw it out? make/sun/awt/Makefile: initIDs.c is already included to FILES_c on linux/solaris, in make/sun/xawt/FILES_c_unix.gmk make/sun/Makefile: what is this comment about? make/sun/awt/mawt.gmk: some ifdef changes look strange, lines 226-235 and 252. make/sun/font/Makefile: lines 200-213 and 213-224 could be merged. make/sun/jawt/Makefile: the same as in make/sun/font/Makefile make/sun/xawt/Makefile: the same as in make/sun/awt/mawt.gmk make/tools/freetypecheck/Makefile: still contains some checks against BSD platform src/share/classes/java/lang/System.java: empty diff src/share/classes/javax/accessibility/AccessibleContext.java: empty diff src/share/classes/javax/swing/UIManager.java: default L&F selection will likely be changed later, but for now the instanceof check can be changed to "toolkit.getClass().getName().equals(LWCToolkit)" to avoid loading LWCToolkit class, if it's not loaded yet. src/share/classes/sun/awt/image/BufImgSurfaceData.java: should be unchanged? src/share/classes/sun/font/FileFont.java: src/share/classes/sun/font/FontManagerFactory.java: the same as right above src/share/classes/sun/print/PrintJob2D.java: src/share/classes/sun/print/RasterPrinterJob.java: src/share/native/common/check_code.c: src/share/native/java/lang/java_props.h: empty diff src/share/native/sun/awt/image/BufImgSurfaceData.c: should it be "malloc.h" instead of ? src/share/native/sun/awt/debug/debug_util.h: src/share/native/sun/awt/image/DataBufferNative.c: src/share/native/sun/font/DrawGlyphList.c: src/share/native/sun/font/sunFont.c: src/share/native/sun/java2d/SurfaceData.c: src/share/native/sun/java2d/opengl/OGLRenderQueue.c: src/share/native/sun/java2d/opengl/OGLTextRenderer.c: src/solaris/native/sun/awt/X11Color.c: src/solaris/native/sun/awt/X11DrawingArea.c: src/solaris/native/sun/awt/list.c: src/solaris/native/sun/font/X11FontScaler.c: src/solaris/native/sun/font/X11TextRenderer.c: the same as right above src/share/native/sun/awt/medialib/mlib_ImageAffine.h: should be either !defined(MACOSX), or no changes to this file at all src/share/native/sun/awt/medialib/mlib_types.h: the same as right above src/share/native/sun/font/AccelGlyphCache.c: the same as in BufImgSurfaceData.c the same as right above src/solaris/native/java/lang/java_props_md.c: sprops.os_arch is already set at line 460 (and then overridden if MACOSX), so the change at line 476 looks wrong. Given that, this file could be left unchanged at all src/solaris/native/sun/awt/awt_LoadLibrary.c: should be unchanged > Thanks, > Michael. Thanks, Artem From henri.gomez at gmail.com Tue Nov 29 05:23:23 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 29 Nov 2011 14:23:23 +0100 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED4AED8.3020501@oracle.com> References: <4ED3B203.4060602@oracle.com> <4ED3B4AF.8020608@oracle.com> <4ED4AED8.3020501@oracle.com> Message-ID: > jdk7u/jdk7u-osx is a kind of integration workspace for 7u4, not 7u2. See > Dalibor's announcement for details: > > http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-October/000552.html Ok nice. And then which repo should be used to build OpenJDK for OSX, actual macosx-port or a new one ? From artem.ananiev at oracle.com Tue Nov 29 05:29:13 2011 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 29 Nov 2011 17:29:13 +0400 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: References: <4ED3B203.4060602@oracle.com> <4ED3B4AF.8020608@oracle.com> <4ED4AED8.3020501@oracle.com> Message-ID: <4ED4DE29.10306@oracle.com> On 11/29/2011 5:23 PM, Henri Gomez wrote: >> jdk7u/jdk7u-osx is a kind of integration workspace for 7u4, not 7u2. See >> Dalibor's announcement for details: >> >> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-October/000552.html > > Ok nice. > > And then which repo should be used to build OpenJDK for OSX, actual > macosx-port or a new one ? Right now, development is done in the macosx-port workspace. Once the patch sent by Michael is reviewed and integrated into 7u-osx, I would expect macosx-port to become obsolete. The exact schedule of integration into 7u-osx and 7u4 is being discussed. Thanks, Artem From henri.gomez at gmail.com Tue Nov 29 05:27:38 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 29 Nov 2011 14:27:38 +0100 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED4DE29.10306@oracle.com> References: <4ED3B203.4060602@oracle.com> <4ED3B4AF.8020608@oracle.com> <4ED4AED8.3020501@oracle.com> <4ED4DE29.10306@oracle.com> Message-ID: > Right now, development is done in the macosx-port workspace. Once the patch > sent by Michael is reviewed and integrated into 7u-osx, I would expect > macosx-port to become obsolete. The exact schedule of integration into > 7u-osx and 7u4 is being discussed. being discussed where and by who ? From michael.x.mcmahon at oracle.com Tue Nov 29 05:41:37 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 29 Nov 2011 13:41:37 +0000 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED4BDF0.8060108@oracle.com> References: <4ED3B203.4060602@oracle.com> <4ED4BDF0.8060108@oracle.com> Message-ID: <4ED4E111.80505@oracle.com> On 29/11/11 11:11, Artem Ananiev wrote: > Hi, Michael, > > thanks for this hard work! > > See my comments below. I only looked at the changes related to the > current macosx-port workspace. Will take a look at the webrev against > 7u-osx a little bit later. > > On 11/28/2011 8:08 PM, Michael McMahon wrote: >> Hi, >> >> Here is another version of the macosx webrev. This time it includes >> all of the modifications and new files from macosx-port. Hence many >> of the problems pointed out earlier with the inconsistencies relative to >> the bsd code >> are gone now. It builds and runs on all platforms and has been synced >> with >> jdk7u-dev (as of Friday Nov 25). I left the // MacOSX comments in >> to highlight changes that people may want to look at more closely. >> >> Lastly, this time I have also included a webrev showing the changes >> relative to macosx-port >> for reference. >> >> Changes relative to jdk7u-osx >> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >> >> New files >> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >> >> Changes relative to macosx-port >> http://cr.openjdk.java.net/~michaelm/7113349/2/macosx-port/modified/ > > I haven't looked through all the files, just those that are related to > client libs. One general question is about BSD support: do we really > want to throw it out? > My understanding is the policy is not to include code for platforms that are not directly buildable and supported. It wouldn't be difficult to put the BSD stuff back in, should one of the variants become supported in future. > make/sun/awt/Makefile: initIDs.c is already included to FILES_c on > linux/solaris, in make/sun/xawt/FILES_c_unix.gmk > Ok, I'll take that out, though it wasn't put in by this effort. [..] > make/sun/awt/mawt.gmk: some ifdef changes look strange, lines 226-235 and 252. The X11 includes were needed but not the CUPS ones (same in make/sun/xawt/Makefile) > > src/share/classes/java/lang/System.java: empty diff > There are changes in there (which we'll be looking at again later) > src/share/classes/javax/accessibility/AccessibleContext.java: empty diff > same as above > src/share/classes/sun/awt/image/BufImgSurfaceData.java: should be > unchanged? > a new protected constructor has been added, which is used by a sub-class. > src/share/classes/sun/font/FileFont.java: > src/share/classes/sun/font/FontManagerFactory.java: the same as right > above > > src/share/classes/sun/print/PrintJob2D.java: > src/share/classes/sun/print/RasterPrinterJob.java: > src/share/native/common/check_code.c: > src/share/native/java/lang/java_props.h: empty diff > > src/share/native/sun/awt/image/BufImgSurfaceData.c: should it be > "malloc.h" instead of ? > > src/share/native/sun/awt/debug/debug_util.h: > src/share/native/sun/awt/image/DataBufferNative.c: > src/share/native/sun/font/DrawGlyphList.c: > src/share/native/sun/font/sunFont.c: > src/share/native/sun/java2d/SurfaceData.c: > src/share/native/sun/java2d/opengl/OGLRenderQueue.c: > src/share/native/sun/java2d/opengl/OGLTextRenderer.c: > src/solaris/native/sun/awt/X11Color.c: > src/solaris/native/sun/awt/X11DrawingArea.c: > src/solaris/native/sun/awt/list.c: > src/solaris/native/sun/font/X11FontScaler.c: > src/solaris/native/sun/font/X11TextRenderer.c: the same as right above > > src/share/native/sun/awt/medialib/mlib_ImageAffine.h: should be either > !defined(MACOSX), or no changes to this file at all > > src/share/native/sun/awt/medialib/mlib_types.h: the same as right above > > src/share/native/sun/font/AccelGlyphCache.c: the same as in > BufImgSurfaceData.c > > the same as right above > > src/solaris/native/java/lang/java_props_md.c: sprops.os_arch is > already set at line 460 (and then overridden if MACOSX), so the change > at line 476 looks wrong. Given that, this file could be left unchanged > at all > > src/solaris/native/sun/awt/awt_LoadLibrary.c: should be unchanged > >> Thanks, >> Michael. > > Thanks, > > Artem From michael.x.mcmahon at oracle.com Tue Nov 29 05:43:45 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 29 Nov 2011 13:43:45 +0000 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED4E111.80505@oracle.com> References: <4ED3B203.4060602@oracle.com> <4ED4BDF0.8060108@oracle.com> <4ED4E111.80505@oracle.com> Message-ID: <4ED4E191.5060704@oracle.com> Artem, I hit send prematurely on the message I just sent. I'm still going through your comments. Thanks! Michael. On 29/11/11 13:41, Michael McMahon wrote: > On 29/11/11 11:11, Artem Ananiev wrote: >> Hi, Michael, >> >> thanks for this hard work! >> >> See my comments below. I only looked at the changes related to the >> current macosx-port workspace. Will take a look at the webrev against >> 7u-osx a little bit later. >> >> On 11/28/2011 8:08 PM, Michael McMahon wrote: >>> Hi, >>> >>> Here is another version of the macosx webrev. This time it includes >>> all of the modifications and new files from macosx-port. Hence many >>> of the problems pointed out earlier with the inconsistencies >>> relative to >>> the bsd code >>> are gone now. It builds and runs on all platforms and has been >>> synced with >>> jdk7u-dev (as of Friday Nov 25). I left the // MacOSX comments in >>> to highlight changes that people may want to look at more closely. >>> >>> Lastly, this time I have also included a webrev showing the changes >>> relative to macosx-port >>> for reference. >>> >>> Changes relative to jdk7u-osx >>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >>> >>> New files >>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >>> >>> Changes relative to macosx-port >>> http://cr.openjdk.java.net/~michaelm/7113349/2/macosx-port/modified/ >> >> I haven't looked through all the files, just those that are related >> to client libs. One general question is about BSD support: do we >> really want to throw it out? >> > My understanding is the policy is not to include code for platforms > that are not directly > buildable and supported. It wouldn't be difficult to put the BSD stuff > back in, should one of the > variants become supported in future. >> make/sun/awt/Makefile: initIDs.c is already included to FILES_c on >> linux/solaris, in make/sun/xawt/FILES_c_unix.gmk >> > Ok, I'll take that out, though it wasn't put in by this effort. > > [..] > > > make/sun/awt/mawt.gmk: some ifdef changes look strange, lines > 226-235 and 252. > > The X11 includes were needed but not the CUPS ones (same in > make/sun/xawt/Makefile) > >> >> src/share/classes/java/lang/System.java: empty diff >> > There are changes in there (which we'll be looking at again later) >> src/share/classes/javax/accessibility/AccessibleContext.java: empty diff >> > same as above >> src/share/classes/sun/awt/image/BufImgSurfaceData.java: should be >> unchanged? >> > a new protected constructor has been added, which is used by a sub-class. >> src/share/classes/sun/font/FileFont.java: >> src/share/classes/sun/font/FontManagerFactory.java: the same as right >> above >> >> src/share/classes/sun/print/PrintJob2D.java: >> src/share/classes/sun/print/RasterPrinterJob.java: >> src/share/native/common/check_code.c: >> src/share/native/java/lang/java_props.h: empty diff >> >> src/share/native/sun/awt/image/BufImgSurfaceData.c: should it be >> "malloc.h" instead of ? >> >> src/share/native/sun/awt/debug/debug_util.h: >> src/share/native/sun/awt/image/DataBufferNative.c: >> src/share/native/sun/font/DrawGlyphList.c: >> src/share/native/sun/font/sunFont.c: >> src/share/native/sun/java2d/SurfaceData.c: >> src/share/native/sun/java2d/opengl/OGLRenderQueue.c: >> src/share/native/sun/java2d/opengl/OGLTextRenderer.c: >> src/solaris/native/sun/awt/X11Color.c: >> src/solaris/native/sun/awt/X11DrawingArea.c: >> src/solaris/native/sun/awt/list.c: >> src/solaris/native/sun/font/X11FontScaler.c: >> src/solaris/native/sun/font/X11TextRenderer.c: the same as right above >> >> src/share/native/sun/awt/medialib/mlib_ImageAffine.h: should be >> either !defined(MACOSX), or no changes to this file at all >> >> src/share/native/sun/awt/medialib/mlib_types.h: the same as right above >> >> src/share/native/sun/font/AccelGlyphCache.c: the same as in >> BufImgSurfaceData.c >> >> the same as right above >> >> src/solaris/native/java/lang/java_props_md.c: sprops.os_arch is >> already set at line 460 (and then overridden if MACOSX), so the >> change at line 476 looks wrong. Given that, this file could be left >> unchanged at all >> >> src/solaris/native/sun/awt/awt_LoadLibrary.c: should be unchanged >> >>> Thanks, >>> Michael. >> >> Thanks, >> >> Artem > From michael.x.mcmahon at oracle.com Tue Nov 29 06:09:10 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 29 Nov 2011 14:09:10 +0000 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED4E111.80505@oracle.com> References: <4ED3B203.4060602@oracle.com> <4ED4BDF0.8060108@oracle.com> <4ED4E111.80505@oracle.com> Message-ID: <4ED4E786.208@oracle.com> On 29/11/11 13:41, Michael McMahon wrote: > On 29/11/11 11:11, Artem Ananiev wrote: >> Hi, Michael, >> >> thanks for this hard work! >> >> See my comments below. I only looked at the changes related to the >> current macosx-port workspace. Will take a look at the webrev against >> 7u-osx a little bit later. >> >> On 11/28/2011 8:08 PM, Michael McMahon wrote: >>> Hi, >>> >>> Here is another version of the macosx webrev. This time it includes >>> all of the modifications and new files from macosx-port. Hence many >>> of the problems pointed out earlier with the inconsistencies >>> relative to >>> the bsd code >>> are gone now. It builds and runs on all platforms and has been >>> synced with >>> jdk7u-dev (as of Friday Nov 25). I left the // MacOSX comments in >>> to highlight changes that people may want to look at more closely. >>> >>> Lastly, this time I have also included a webrev showing the changes >>> relative to macosx-port >>> for reference. >>> >>> Changes relative to jdk7u-osx >>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >>> >>> New files >>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >>> >>> Changes relative to macosx-port >>> http://cr.openjdk.java.net/~michaelm/7113349/2/macosx-port/modified/ >> >> I haven't looked through all the files, just those that are related >> to client libs. One general question is about BSD support: do we >> really want to throw it out? >> > My understanding is the policy is not to include code for platforms > that are not directly > buildable and supported. It wouldn't be difficult to put the BSD stuff > back in, should one of the > variants become supported in future. >> make/sun/awt/Makefile: initIDs.c is already included to FILES_c on >> linux/solaris, in make/sun/xawt/FILES_c_unix.gmk >> > Ok, I'll take that out, though it wasn't put in by this effort. > > [..] > > > make/sun/awt/mawt.gmk: some ifdef changes look strange, lines > 226-235 and 252. > > The X11 includes were needed but not the CUPS ones (same in > make/sun/xawt/Makefile) > >> >> src/share/classes/java/lang/System.java: empty diff >> > There are changes in there (which we'll be looking at again later) >> src/share/classes/javax/accessibility/AccessibleContext.java: empty diff >> > same as above >> src/share/classes/sun/awt/image/BufImgSurfaceData.java: should be >> unchanged? >> > a new protected constructor has been added, which is used by a sub-class. >> src/share/classes/sun/font/FileFont.java: >> src/share/classes/sun/font/FontManagerFactory.java: the same as right >> above >> there are small changes in the files above. Are you looking at a different webrev? >> src/share/classes/sun/print/PrintJob2D.java: >> src/share/classes/sun/print/RasterPrinterJob.java: >> src/share/native/common/check_code.c: >> src/share/native/java/lang/java_props.h: empty diff >> >> src/share/native/sun/awt/image/BufImgSurfaceData.c: should it be >> "malloc.h" instead of ? >> >> src/share/native/sun/awt/debug/debug_util.h: >> src/share/native/sun/awt/image/DataBufferNative.c: >> src/share/native/sun/font/DrawGlyphList.c: >> src/share/native/sun/font/sunFont.c: >> src/share/native/sun/java2d/SurfaceData.c: >> src/share/native/sun/java2d/opengl/OGLRenderQueue.c: >> src/share/native/sun/java2d/opengl/OGLTextRenderer.c: >> src/solaris/native/sun/awt/X11Color.c: >> src/solaris/native/sun/awt/X11DrawingArea.c: >> src/solaris/native/sun/awt/list.c: >> src/solaris/native/sun/font/X11FontScaler.c: >> src/solaris/native/sun/font/X11TextRenderer.c: the same as right above >> >> src/share/native/sun/awt/medialib/mlib_ImageAffine.h: should be >> either !defined(MACOSX), or no changes to this file at all >> >> src/share/native/sun/awt/medialib/mlib_types.h: the same as right above >> >> src/share/native/sun/font/AccelGlyphCache.c: the same as in >> BufImgSurfaceData.c >> >> the same as right above >> >> src/solaris/native/java/lang/java_props_md.c: sprops.os_arch is >> already set at line 460 (and then overridden if MACOSX), so the >> change at line 476 looks wrong. Given that, this file could be left >> unchanged at all >> >> src/solaris/native/sun/awt/awt_LoadLibrary.c: should be unchanged >> >>> Thanks, >>> Michael. >> >> Thanks, >> >> Artem > From michael.x.mcmahon at oracle.com Tue Nov 29 06:34:23 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 29 Nov 2011 14:34:23 +0000 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED4E111.80505@oracle.com> References: <4ED3B203.4060602@oracle.com> <4ED4BDF0.8060108@oracle.com> <4ED4E111.80505@oracle.com> Message-ID: <4ED4ED6F.2070204@oracle.com> Artem, Thanks for looking at this! Actually I just realised that your comments were on the changes relative to macosx-port. I only included that webrev for reference, in order to identify if there were mac related changes that I might have missed. So, that is why there are a number of files with no changes. In any case, many of your comments are still useful. I have removed the extraneous definitions from the makefiles. I also made the change to UIManager and java_props_md.c The change from "malloc.h" to stdlib.h is a simplification because stdlib is actually the correct include for malloc(), so it works the same on all platforms. awt_LoadLibrary.c is a complicated change, and I'd certainly appreciate your view on the webrev (relative to jdk7-osx) and indeed the other changes relative to jdk7-osx as well. Thanks Michael. From artem.ananiev at oracle.com Tue Nov 29 08:48:33 2011 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 29 Nov 2011 20:48:33 +0400 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED4ED6F.2070204@oracle.com> References: <4ED3B203.4060602@oracle.com> <4ED4BDF0.8060108@oracle.com> <4ED4E111.80505@oracle.com> <4ED4ED6F.2070204@oracle.com> Message-ID: <4ED50CE1.9020102@oracle.com> On 11/29/2011 6:34 PM, Michael McMahon wrote: > Artem, > > Thanks for looking at this! > > Actually I just realised that your comments were on the changes relative > to macosx-port. Ah, sorry, I didn't mention that explicitly... > I only included that webrev for reference, in order to identify if there > were mac related > changes that I might have missed. So, that is why there are a number of > files with no changes. These webrevs are two different point of views for the same changes. I'm going to look through the webrev against 7u-osx tomorrow and will provide more feedback. > In any case, many of your comments are still useful. I have removed the > extraneous definitions > from the makefiles. I also made the change to UIManager and java_props_md.c > > The change from "malloc.h" to stdlib.h is a simplification because > stdlib is actually the correct > include for malloc(), so it works the same on all platforms. > > awt_LoadLibrary.c is a complicated change, and I'd certainly appreciate > your view on the webrev > (relative to jdk7-osx) and indeed the other changes relative to jdk7-osx > as well. > > Thanks > Michael. Thanks, Artem From swingler at apple.com Tue Nov 29 15:14:30 2011 From: swingler at apple.com (Mike Swingler) Date: Tue, 29 Nov 2011 15:14:30 -0800 Subject: SplashScreen and NSApplication instance initialization In-Reply-To: <4ED3E795.30404@oracle.com> References: <4ED3E795.30404@oracle.com> Message-ID: On Nov 28, 2011, at 11:57 AM, Anthony Petrov wrote: > Hi Mike et al., > > For the SplashScreen we need to initialize an instance of NSApplication before JVM (and hence AWT) are loaded. I'm trying to move the code from the NSApplicationAWT.m into the Java launcher code so that it would be shared by both the splashscreen library and the AWT. > > The problem I've encountered is that certain settings are retrieved from the JVM properties: > > // needed by registerWithProcessManager: > apple.awt.application.name > sun.java.launcher > apple.awt.UIElement > apple.awt.BackgroundOnly > > // needed by finishLaunching: > apple.awt.application.nib > apple.awt.application.icon > > > Since the JVM isn't initialized yet when the splash screen code is launching, the properties aren't available. Some parameters have alternative ways of discovery (e.g. there are more options to retrieve the application name in addition to using apple.awt.application.name, and they are all tried in the code), however, the rest of them have not such alternatives. > > I've made a quick test by creating a generic NSApplication instance in the splash screen code. Later, when the AWT has started (in the "embedded" mode, sort of, since the event loop has already been started by the splash screen library), I called the registerWithProcessManager and finishLaunching methods static for the NSApp (I've turned them into static methods before that so that I could apply them to any kind of NSAPplication, not only the NSApplicationAWT). This didn't do much though. The only pieces of code that seem to be useful or did anything at all seem to be a) the "// HACK BEGIN" section that helped make the app foreground and display it in the dock (although with a generic, OS-provided icon only), and b) the menu update loop at finishLaunching (which oddly added the new items rather than updated the default ones; and it didn't change the name of the application menu itself). > > Note that the icon in the dock wasn't updated to the Java icon, and neither was the main menu updated automatically - I had to switch to another app, and then back to my test to make the menu show. Note that the app's title was just "java". I realize that in part this is because the registerWithProcessManager should actually happen before the application instance is even constructed, but that was just a quick test. Besides, I don't understand why would the finishLaunching code not do its job properly - it just has to be executed some time after starting the event loop. Did the fact that a window has already been shown on the screen prevent it from updating the dock icon? The problem is that the wrong NSApplication instance is installed, and it would be a Bad Idea to try to swap in your own after the default one has fully initialized. > Anyway, to make it all work right we probably need to enhance the JRSAppKitAWT interface so that it could update those values rather than register them just once. We could provide some default values from the splash screen code, and later initiate an update at the time when AWT has finally loaded. Is this possible? This is not possible due to the underlying implementation in AppKit. I looked into this over the Thanksgiving break. > Another option is to declare that the mentioned properties are simply not supported in case the app uses a splash screen. After all, the properties don't seem to belong to Java specification anyway. However, it would still be cool to (at least) have a shiny Java icon in the dock and a proper application title in the main menu. How do we do that if we choose this way? I'd actually suggest creating a helper process to show the splash screen with a minimal UIElement NSApplication instance, and would forward all clicks to the original process over IPC. This would have the added benefit of (potentially) showing the splash screen window before the Dock icon had completely materialized. The only major trick would be handing off image data that was extracted from a jar file (which could be done via a temp file). Unfortunately the existing Java SE 6 splash screen code is SPI from top-to-bottom, and we have no way to practically expose the raw WindowServer window primitives it's built out of via JRS (particularly when a pure-Cocoa helper app will do functionally the same thing). What do you think? Mike Swingler Apple Inc. From philip.race at oracle.com Tue Nov 29 15:54:00 2011 From: philip.race at oracle.com (Phil Race) Date: Tue, 29 Nov 2011 15:54:00 -0800 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED3B203.4060602@oracle.com> References: <4ED3B203.4060602@oracle.com> Message-ID: <4ED57098.5010300@oracle.com> Comments from looking at :- Changes relative to jdk7u-osx http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ But before that I want to raise that there are a few ways of handling issues that require to be done differently and ask what is going to be the case : 1. Fix them first in the MACOSX_PORT and then re-generate the webrev. 2. In the interests of time, push first to jdk7u-osx, *then* fix them in MACOSX_PORT, and create a new patch when they are all resolved. 3. Fix them in this patch only, and expect that they won't crop up again when next syncing from MACOSX_PORT to jdk7u-osx. This latter one is the least work, but implies that the MACOSX_PORT forest is more quickly heading for retirement before we forget all this. So which of these should be the norm ? Also some the comments aren't things I reasonably expect Mike to be able to resolve, as they are far too involved, or maybe just point to clean up we should consider. But in the great scheme of things the number of changes to shared [ client ] code as well as the changes themselves look much more reasonable now. On to comments :- FILES_export.gmk : 79 sun/awt/SunHints.java \ This seems wrong .. or at least unnecessary as there's no native methods declared in this file. More of an observation for investigation is that sun/awt/Makefile installs src/macosx/classes/sun/awt/fontconfigs/macosx.fontconfig.properties I'm not sure if this is needed or used. and it looks a lot like a copy of the Windows file. mawt.gmk - and numerous other locations - reference X11. The client UI will be all cocoa based so the extent to which the X11 code will continue to work is questionable. make/sun/cmm/lcms/Makefile expresses a depdency on libxawt.so This was apparently pre-existing but I can't think what there is in libxawt that would be needed by libcms.so which should run fine against headless .. Also the actual include change will get simplified in JDK 8 where for jigsaw needs the directory structure will be flattened like the OS X version here. sun/font/Makefile .. the duplicate lines 203-212 seem unneeded .. why not just add CLASSHDRDIR to CPPFLAGS on all platforms .. can't do any harm, can it ? The same - more so - goes for lines 98-113 in sun/jawt/Makefile In sun/xawt/Makefile 141 ifeq ($(PLATFORM), macosx) 142 CPPFLAGS += -I$(CUPS_HEADERS_PATH) 143 endif This duplicates line 113 113 CPPFLAGS += -I$(CUPS_HEADERS_PATH) make/tools/freetypecheck/Makefile 53 ifeq ($(PLATFORM), macosx) 54 ifeq ($(OS_NAME), netbsd) 55 FT_LD_OPTIONS += -Wl,-R$(FREETYPE_LIB_PATH) 56 endif 57 FT_LD_OPTIONS += -lfreetype -lz 58 else # linux We don't need the inner netbsd case Component.java 7913 if (clearOnFailure&& !res) { becomes 7913 if (!res) { This needs careful examination by someone who knows the focus manager .. sun/font/FontUtilities - and others - some casts to CompositeFont have been removed because logical fonts in the OSX port are handled as CFont which directly subclassees Font2D .. this is a bit messy in part because of the fact that CFont, which is platform specific relies on shared code a lot. We're getting away with it right now but some day this could force some substantial changes one way or another. SunFontManager.java line 3800 is very .. very long. Definitely> 80 chars src/share/classes/sun/print/PrintJob2D.java 488 // MACOSX change 489 // REGR: Print Dialog does not appear 490 if (jobAttributes.getDialog() == DialogType.NATIVE) { 491 PageFormat oldPF = pageFormat; 492 PageFormat newPF = printerJob.pageDialog(oldPF); 493 if (oldPF == newPF) return false; 494 pageFormat = newPF; 495 } 496 // MACOSX I don't know what problem this was trying to fix but this can't be pushed. AWT printing doesn't provide for a PageDialog, and this would change behaviour on all platforms. *src/share/classes/sun/print/RasterPrinterJob.java* I see a lot of methods made protected. I am not sure how necessary this is (is there a better way), since Windows printing did not need to do this and its similarly all native based. src/solaris/native/sun/awt/fontpath.c 64 // MMM: Is this still needed? I suspect only in the X11 Toolkit 66 // XXXDARWIN: Hard-code the path to Apple's freetype, as it is You mean fontconfig not freetype. 73 #define FONTCONFIG_DLL_VERSIONED X11_PATH "/lib/" VERSIONED_JNI_LIB_NAME("fontconfig", "1") I don't see where X11_PATH is defined but I think yuou can have /usr/X11R6 or /usr/X11R7 in which case we will be baking in something that works only for some people. This is offset by being code that isn't actually for production .. 132 #elif MACOSX 133 static char *fullBSDFontPath[] = { 134 X11_PATH "/lib/X11/fonts/TrueType", ... I expect these directories exist if you have X11 installed but these aren't the standard OS X font folders which are (off the top of my head) /System/Library/Fonts and /Library/Fonts and /User//Library/Fonts It seems a bit at odds with the fontconfig file I commented on above. Not sure what you should do here but I'd at least check the paths are valid and rename the var tofull_MACOSX_X11FontPath -phil. On 11/28/11 08:08 AM, Michael McMahon wrote: > Hi, > > Here is another version of the macosx webrev. This time it includes > all of the modifications and new files from macosx-port. Hence many > of the problems pointed out earlier with the inconsistencies relative > to the bsd code > are gone now. It builds and runs on all platforms and has been synced > with > jdk7u-dev (as of Friday Nov 25). I left the // MacOSX comments in > to highlight changes that people may want to look at more closely. > > Lastly, this time I have also included a webrev showing the changes > relative to macosx-port > for reference. > > Changes relative to jdk7u-osx > http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ > > New files > http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ > > Changes relative to macosx-port > http://cr.openjdk.java.net/~michaelm/7113349/2/macosx-port/modified/ > > Thanks, > Michael. > From swingler at apple.com Tue Nov 29 17:35:09 2011 From: swingler at apple.com (swingler at apple.com) Date: Wed, 30 Nov 2011 01:35:09 +0000 Subject: hg: macosx-port/macosx-port/jdk: Using a modern compiler, to match other usage. Message-ID: <20111130013520.5B3BB474A4@hg.openjdk.java.net> Changeset: d62953cff3de Author: swingler at apple.com Date: 2011-11-29 17:34 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/d62953cff3de Using a modern compiler, to match other usage. ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StructOffsetResolver.java From swingler at apple.com Tue Nov 29 17:51:08 2011 From: swingler at apple.com (swingler at apple.com) Date: Wed, 30 Nov 2011 01:51:08 +0000 Subject: hg: macosx-port/macosx-port/jdk: Fixing Graphics casts in Aqua to be more generic. Message-ID: <20111130015119.424E8474A5@hg.openjdk.java.net> Changeset: 7aa6d26f3478 Author: swingler at apple.com Date: 2011-11-29 17:50 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/7aa6d26f3478 Fixing Graphics casts in Aqua to be more generic. ! src/macosx/classes/com/apple/laf/AquaFocus.java ! src/macosx/classes/com/apple/laf/AquaPainter.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java From peter.brunet at oracle.com Tue Nov 29 20:27:59 2011 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 29 Nov 2011 22:27:59 -0600 Subject: building just awt Message-ID: <4ED5B0CF.8060405@oracle.com> How do I do a rebuild of just changes in .../macosx-port/jdk/src/macosx/native/sun/awt ? Pete From pranav.bhat at oracle.com Tue Nov 29 21:02:23 2011 From: pranav.bhat at oracle.com (Pranav Bhat) Date: Wed, 30 Nov 2011 00:02:23 -0500 Subject: building just awt In-Reply-To: <4ED5B0CF.8060405@oracle.com> References: <4ED5B0CF.8060405@oracle.com> Message-ID: <552540E4-ECCA-4086-B23A-9D85316DDE7F@oracle.com> Hello Pete, I found this in one of the pages: http://wikis.sun.com/display/OpenJDK/Incremental+Building Thanks, - Pranav On Nov 29, 2011, at 11:27 PM, Pete Brunet wrote: > How do I do a rebuild of just changes in > .../macosx-port/jdk/src/macosx/native/sun/awt ? > > Pete From kirk at kodewerk.com Wed Nov 30 04:11:32 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Wed, 30 Nov 2011 13:11:32 +0100 Subject: hang in Lion Message-ID: <4C1AE59E-6E11-4B19-AA48-C0741A0F693D@kodewerk.com> Hi, I've got a chunk of code that mysteriously hangs on my new i7 Air running Lion. This code was given to me by a friend that is also running Lion. We've given it to another person that is also running Lion. I'm using 1.6.0_26-b02-383. It doesn't hang all the time and it doesn't hang on my older i7 17" MBP running Snow Leopard. It's also been tested on other MBP's running Snow Leopard without hanging. Forcing a core dump after the hang gave us this. > Thread 24: Java: Thread-1 > 0 libSystem.B.dylib 0x00007fff89f88d7a mach_msg_trap + 10 > 1 libSystem.B.dylib 0x00007fff89f893ed mach_msg + 59 > 2 libclient64.dylib 0x000000010100d903 jio_snprintf + 37641 > 3 libclient64.dylib 0x000000010100d7c3 jio_snprintf + 37321 > 4 libclient64.dylib 0x000000010100d722 jio_snprintf + 37160 > 5 libclient64.dylib 0x000000010100c5ad jio_snprintf + 32691 > 6 libclient64.dylib 0x000000010100c4ef jio_snprintf + 32501 > 7 libclient64.dylib 0x00000001011afefd JVM_GetClassInterfaces + 12075 > 8 libclient64.dylib 0x00000001010a7c8c JVM_Lseek + 204251 > 9 libclient64.dylib 0x00000001010a7bea JVM_Lseek + 204089 > 10 libclient64.dylib 0x00000001011b4931 JVM_Socket + 5319 > 11 ??? 0x000000010380f0e7 0 + 4353749223 > 12 ??? 0x000000010386fd90 0 + 4354145680 > > Thread 25: Java: Thread-2 > 0 libSystem.B.dylib 0x00007fff89f88d7a mach_msg_trap + 10 > 1 libSystem.B.dylib 0x00007fff89f893ed mach_msg + 59 > 2 libclient64.dylib 0x000000010100db03 jio_snprintf + 38153 > 3 libclient64.dylib 0x00000001010cb569 JVM_Write + 9130 > 4 libclient64.dylib 0x00000001011ddfcd JVM_NanoTime + 39179 > 5 ??? 0x000000010386ea60 0 + 4354140768 All of the other thread could be attributed to VM processes (GC, compiler etc...). On my machine, the hang seems to only happen when thread-2 finishes before thread-1. I've never seen it hang when thread-1 finishes before thread-2 Again it doesn't hang all the time when thread-2 finishes first. This is a hard hang in that I can only get rid of the process with a kill -9. ^C and kill simply don't to anything. Code follows, Regards, Kirk Pepperdine public class Foo { private int counter; public static void main(String[] args) throws Exception { new Foo().run(); } public void run() throws Exception { Thread[] threads = new Thread[2]; for (int i = 0; i < threads.length; i++) { threads[i] = new Thread() { public void run() { System.out.println("Thread started " + Thread.currentThread().getName()); System.out.flush(); for (int i = 0; i < 100000; i++) { increment(); } System.out.println("Thread done " + Thread.currentThread().getName()); System.out.flush(); } }; } for (Thread t : threads) { t.start(); } System.out.println("Started"); System.out.flush(); System.out.println("Awaiting complete..."); System.out.flush(); for (Thread t : threads) { t.join(); } System.out.println("Completed..."); System.out.flush(); } private synchronized void increment() { counter++; if (counter % 10000 == 0) { System.out.printf("%s: %d\n", Thread.currentThread().getName(), counter); System.out.flush(); } } } From dalibor.topic at oracle.com Wed Nov 30 05:35:44 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 30 Nov 2011 14:35:44 +0100 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED4E111.80505@oracle.com> References: <4ED3B203.4060602@oracle.com> <4ED4BDF0.8060108@oracle.com> <4ED4E111.80505@oracle.com> Message-ID: <4ED63130.3010804@oracle.com> On 11/29/11 2:41 PM, Michael McMahon wrote: > My understanding is the policy is not to include code for platforms that are not directly > buildable and supported. It wouldn't be difficult to put the BSD stuff back in, should one of the > variants become supported in future. We've included community supported ports (Zero, Shark) in the past when they have passed the corresponding TCK with the expectation that they are kept in shape by the corresponding (sub)community in OpenJDK, and if they aren't, that they'd get dropped out of mainline again. Since the BSD port hasn't been able yet to pass the 7 TCK [0], not including code specific to that port is fine, in my opinion. I'd expect that the work done on the Mac OS X port in the future in that problem domain will be something the BSD porters would be able to leverage once they can start working toward that goal themselves. So in that light focusing the integration work attention into JDK 7 Updates on Mac OS X parts for now seems like a sensible choice to me. cheers, dalibor topic [0] There is no updated OCTLA for 7 yet, but it's coming: http://mail.openjdk.java.net/pipermail/discuss/2011-November/002214.html -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 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 dalibor.topic at oracle.com Wed Nov 30 05:58:21 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 30 Nov 2011 14:58:21 +0100 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: References: <4ED3B203.4060602@oracle.com> <4ED3B4AF.8020608@oracle.com> <4ED4AED8.3020501@oracle.com> <4ED4DE29.10306@oracle.com> Message-ID: <4ED6367D.9010007@oracle.com> On 11/29/11 2:27 PM, Henri Gomez wrote: >> Right now, development is done in the macosx-port workspace. Once the patch >> sent by Michael is reviewed and integrated into 7u-osx, I would expect >> macosx-port to become obsolete. The exact schedule of integration into >> 7u-osx and 7u4 is being discussed. > > being discussed where on macosx-port-dev and jdk7u-dev mailing lists, starting when the jdk7u-osx forest was discussed initially on the jdk7u-dev mailing list. It's still a hot topic, as you can see from this thread - as a rough pointer you can also look at the JDK 7 Updates roadmap published at this year's JavaOne, which has several things to say about plans for Mac OS X support in JDK 7 updates: http://blogs.oracle.com/javaone/entry/moving_java_forward_java_strategy > and by who ? by everyone involved in making the move happen, afaict. ;) cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 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 henri.gomez at gmail.com Wed Nov 30 06:21:57 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 30 Nov 2011 15:21:57 +0100 Subject: hang in Lion In-Reply-To: <4C1AE59E-6E11-4B19-AA48-C0741A0F693D@kodewerk.com> References: <4C1AE59E-6E11-4B19-AA48-C0741A0F693D@kodewerk.com> Message-ID: Hi Charles Just tried with latest build of OpenJDK 7 for OSX (http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-jdk-b219-20111130.dmg) : openjdk version "1.7.0-b219" OpenJDK Runtime Environment (build 1.7.0-b219-20111130) OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode) Compiled and run with OpenJDK 7 : Started Awaiting complete... Thread started Thread-0 Thread started Thread-1 Thread-0: 10000 Thread-1: 20000 Thread-0: 30000 Thread-0: 40000 Thread-1: 50000 Thread-1: 60000 Thread-1: 70000 Thread-1: 80000 Thread-1: 90000 Thread-1: 100000 Thread-0: 110000 Thread-0: 120000 Thread-1: 130000 Thread-0: 140000 Thread-1: 150000 Thread-0: 160000 Thread-0: 170000 Thread-0: 180000 Thread done Thread-1 Thread-0: 190000 Thread-0: 200000 Thread done Thread-0 Completed... Tried on latest Apple Java 6 (1.6.0-29) and rebuilt Foo with it : java version "1.6.0_29" Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) Started Thread started Thread-1 Thread started Thread-2 Awaiting complete... Thread-2: 10000 Thread-1: 20000 Thread-1: 30000 Thread-2: 40000 Thread-2: 50000 Thread-1: 60000 Thread-1: 70000 Thread-2: 80000 Thread-2: 90000 Thread-1: 100000 Thread-1: 110000 Thread-2: 120000 Thread-1: 130000 Thread-1: 140000 Thread-1: 150000 Thread-1: 160000 Thread-1: 170000 Thread-2: 180000 Thread-2: 190000 Thread-1: 200000 Thread done Thread-2 Thread done Thread-1 Completed... Tried on both SnowLeopard and Lion machines. Cheers 2011/11/30 Charles K Pepperdine : > Hi, > > I've got a chunk of code that mysteriously hangs on my new i7 Air running Lion. This code was given to me by a friend that is also running Lion. We've given it to another person that is also running Lion. I'm using 1.6.0_26-b02-383. It doesn't hang all the time and it doesn't hang on my older i7 17" MBP running Snow Leopard. It's also been tested on other MBP's running Snow Leopard without hanging. Forcing a core dump after the hang gave us this. > >> Thread 24: ?Java: Thread-1 >> 0 ? libSystem.B.dylib ? ? ? ? ? ? ? ? 0x00007fff89f88d7a mach_msg_trap + 10 >> 1 ? libSystem.B.dylib ? ? ? ? ? ? ? ? 0x00007fff89f893ed mach_msg + 59 >> 2 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100d903 jio_snprintf + 37641 >> 3 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100d7c3 jio_snprintf + 37321 >> 4 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100d722 jio_snprintf + 37160 >> 5 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100c5ad jio_snprintf + 32691 >> 6 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100c4ef jio_snprintf + 32501 >> 7 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001011afefd JVM_GetClassInterfaces + 12075 >> 8 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001010a7c8c JVM_Lseek + 204251 >> 9 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001010a7bea JVM_Lseek + 204089 >> 10 ?libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001011b4931 JVM_Socket + 5319 >> 11 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x000000010380f0e7 0 + 4353749223 >> 12 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x000000010386fd90 0 + 4354145680 >> >> Thread 25: ?Java: Thread-2 >> 0 ? libSystem.B.dylib ? ? ? ? ? ? ? ? 0x00007fff89f88d7a mach_msg_trap + 10 >> 1 ? libSystem.B.dylib ? ? ? ? ? ? ? ? 0x00007fff89f893ed mach_msg + 59 >> 2 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100db03 jio_snprintf + 38153 >> 3 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001010cb569 JVM_Write + 9130 >> 4 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001011ddfcd JVM_NanoTime + 39179 >> 5 ? ??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x000000010386ea60 0 + 4354140768 > > All of the other thread could be attributed to VM processes (GC, compiler etc...). > > On my machine, the hang seems to only happen when thread-2 finishes before thread-1. I've never seen it hang when thread-1 finishes before thread-2 Again it doesn't hang all the time when thread-2 finishes first. This is a hard hang in that I can only get rid of the process with a kill -9. ^C and kill simply don't to anything. > > Code follows, > > Regards, > Kirk Pepperdine > > public class Foo { > > ? ?private int counter; > > ? ?public static void main(String[] args) throws Exception { > ? ? ? ?new Foo().run(); > ? ?} > > ? ?public void run() throws Exception { > > ? ? ? ?Thread[] threads = new Thread[2]; > > ? ? ? ?for (int i = 0; i < threads.length; i++) { > ? ? ? ? ? ?threads[i] = new Thread() { > ? ? ? ? ? ? ? ?public void run() { > > ? ? ? ? ? ? ? ? ? ?System.out.println("Thread started " + Thread.currentThread().getName()); > ? ? ? ? ? ? ? ? ? ?System.out.flush(); > > ? ? ? ? ? ? ? ? ? ?for (int i = 0; i < 100000; i++) { > ? ? ? ? ? ? ? ? ? ? ? ?increment(); > ? ? ? ? ? ? ? ? ? ?} > > ? ? ? ? ? ? ? ? ? ?System.out.println("Thread done " + Thread.currentThread().getName()); > ? ? ? ? ? ? ? ? ? ?System.out.flush(); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?}; > ? ? ? ?} > > ? ? ? ?for (Thread t : threads) { > ? ? ? ? ? ?t.start(); > ? ? ? ?} > > ? ? ? ?System.out.println("Started"); > ? ? ? ?System.out.flush(); > > ? ? ? ?System.out.println("Awaiting complete..."); > ? ? ? ?System.out.flush(); > > ? ? ? ?for (Thread t : threads) { > ? ? ? ? ? ?t.join(); > ? ? ? ?} > > ? ? ? ?System.out.println("Completed..."); > ? ? ? ?System.out.flush(); > ? ?} > > ? ?private synchronized void increment() { > > ? ? ? ?counter++; > > ? ? ? ?if (counter % 10000 == 0) { > ? ? ? ? ? ?System.out.printf("%s: %d\n", Thread.currentThread().getName(), counter); > ? ? ? ? ? ?System.out.flush(); > ? ? ? ?} > ? ?} > } From henri.gomez at gmail.com Wed Nov 30 06:26:40 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 30 Nov 2011 15:26:40 +0100 Subject: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED6367D.9010007@oracle.com> References: <4ED3B203.4060602@oracle.com> <4ED3B4AF.8020608@oracle.com> <4ED4AED8.3020501@oracle.com> <4ED4DE29.10306@oracle.com> <4ED6367D.9010007@oracle.com> Message-ID: >> being discussed where > > on macosx-port-dev and jdk7u-dev mailing lists, starting when the jdk7u-osx forest > was discussed initially on the jdk7u-dev mailing list. Ok, didn't see them on mac-osx-port. I'll subscribe to jdk7u-dev ml. > It's still a hot topic, as you can see from this thread - as a rough pointer you can also > look at the JDK 7 Updates roadmap published at this year's JavaOne, which has several things > to say about plans for Mac OS X support in JDK 7 updates: > http://blogs.oracle.com/javaone/entry/moving_java_forward_java_strategy So osx should be in jdk7 u4 (mid 2012 ?) >> and by who ? > > by everyone involved in making the move happen, afaict. ;) Make sense Correct me but the final goal is to have macosx code in jdk7 u4 (and may be jdk8) so it will be a fully supported platform like Linux, Windows or Solaris ? From michael.x.mcmahon at oracle.com Wed Nov 30 06:31:15 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 30 Nov 2011 14:31:15 +0000 Subject: hang in Lion In-Reply-To: References: <4C1AE59E-6E11-4B19-AA48-C0741A0F693D@kodewerk.com> Message-ID: <4ED63E33.4000604@oracle.com> I was able to repeat it using java version "1.6.0_27" on an imac (with -Xcomp, but not -Xint) . Was not able to repeat using 7 on the same system, I also couldn't repeat it on a different machine using 1.6.0_29. So, maybe the issue was fixed between updates 27 and 29? - Michael. On 30/11/11 14:21, Henri Gomez wrote: > Hi Charles > > Just tried with latest build of OpenJDK 7 for OSX > (http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-jdk-b219-20111130.dmg) > : > > openjdk version "1.7.0-b219" > OpenJDK Runtime Environment (build 1.7.0-b219-20111130) > OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode) > > Compiled and run with OpenJDK 7 : > > Started > Awaiting complete... > Thread started Thread-0 > Thread started Thread-1 > Thread-0: 10000 > Thread-1: 20000 > Thread-0: 30000 > Thread-0: 40000 > Thread-1: 50000 > Thread-1: 60000 > Thread-1: 70000 > Thread-1: 80000 > Thread-1: 90000 > Thread-1: 100000 > Thread-0: 110000 > Thread-0: 120000 > Thread-1: 130000 > Thread-0: 140000 > Thread-1: 150000 > Thread-0: 160000 > Thread-0: 170000 > Thread-0: 180000 > Thread done Thread-1 > Thread-0: 190000 > Thread-0: 200000 > Thread done Thread-0 > Completed... > > Tried on latest Apple Java 6 (1.6.0-29) and rebuilt Foo with it : > > java version "1.6.0_29" > Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) > Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) > > Started > Thread started Thread-1 > Thread started Thread-2 > Awaiting complete... > Thread-2: 10000 > Thread-1: 20000 > Thread-1: 30000 > Thread-2: 40000 > Thread-2: 50000 > Thread-1: 60000 > Thread-1: 70000 > Thread-2: 80000 > Thread-2: 90000 > Thread-1: 100000 > Thread-1: 110000 > Thread-2: 120000 > Thread-1: 130000 > Thread-1: 140000 > Thread-1: 150000 > Thread-1: 160000 > Thread-1: 170000 > Thread-2: 180000 > Thread-2: 190000 > Thread-1: 200000 > Thread done Thread-2 > Thread done Thread-1 > Completed... > > Tried on both SnowLeopard and Lion machines. > > Cheers > > 2011/11/30 Charles K Pepperdine: >> Hi, >> >> I've got a chunk of code that mysteriously hangs on my new i7 Air running Lion. This code was given to me by a friend that is also running Lion. We've given it to another person that is also running Lion. I'm using 1.6.0_26-b02-383. It doesn't hang all the time and it doesn't hang on my older i7 17" MBP running Snow Leopard. It's also been tested on other MBP's running Snow Leopard without hanging. Forcing a core dump after the hang gave us this. >> >>> Thread 24: Java: Thread-1 >>> 0 libSystem.B.dylib 0x00007fff89f88d7a mach_msg_trap + 10 >>> 1 libSystem.B.dylib 0x00007fff89f893ed mach_msg + 59 >>> 2 libclient64.dylib 0x000000010100d903 jio_snprintf + 37641 >>> 3 libclient64.dylib 0x000000010100d7c3 jio_snprintf + 37321 >>> 4 libclient64.dylib 0x000000010100d722 jio_snprintf + 37160 >>> 5 libclient64.dylib 0x000000010100c5ad jio_snprintf + 32691 >>> 6 libclient64.dylib 0x000000010100c4ef jio_snprintf + 32501 >>> 7 libclient64.dylib 0x00000001011afefd JVM_GetClassInterfaces + 12075 >>> 8 libclient64.dylib 0x00000001010a7c8c JVM_Lseek + 204251 >>> 9 libclient64.dylib 0x00000001010a7bea JVM_Lseek + 204089 >>> 10 libclient64.dylib 0x00000001011b4931 JVM_Socket + 5319 >>> 11 ??? 0x000000010380f0e7 0 + 4353749223 >>> 12 ??? 0x000000010386fd90 0 + 4354145680 >>> >>> Thread 25: Java: Thread-2 >>> 0 libSystem.B.dylib 0x00007fff89f88d7a mach_msg_trap + 10 >>> 1 libSystem.B.dylib 0x00007fff89f893ed mach_msg + 59 >>> 2 libclient64.dylib 0x000000010100db03 jio_snprintf + 38153 >>> 3 libclient64.dylib 0x00000001010cb569 JVM_Write + 9130 >>> 4 libclient64.dylib 0x00000001011ddfcd JVM_NanoTime + 39179 >>> 5 ??? 0x000000010386ea60 0 + 4354140768 >> All of the other thread could be attributed to VM processes (GC, compiler etc...). >> >> On my machine, the hang seems to only happen when thread-2 finishes before thread-1. I've never seen it hang when thread-1 finishes before thread-2 Again it doesn't hang all the time when thread-2 finishes first. This is a hard hang in that I can only get rid of the process with a kill -9. ^C and kill simply don't to anything. >> >> Code follows, >> >> Regards, >> Kirk Pepperdine >> >> public class Foo { >> >> private int counter; >> >> public static void main(String[] args) throws Exception { >> new Foo().run(); >> } >> >> public void run() throws Exception { >> >> Thread[] threads = new Thread[2]; >> >> for (int i = 0; i< threads.length; i++) { >> threads[i] = new Thread() { >> public void run() { >> >> System.out.println("Thread started " + Thread.currentThread().getName()); >> System.out.flush(); >> >> for (int i = 0; i< 100000; i++) { >> increment(); >> } >> >> System.out.println("Thread done " + Thread.currentThread().getName()); >> System.out.flush(); >> } >> }; >> } >> >> for (Thread t : threads) { >> t.start(); >> } >> >> System.out.println("Started"); >> System.out.flush(); >> >> System.out.println("Awaiting complete..."); >> System.out.flush(); >> >> for (Thread t : threads) { >> t.join(); >> } >> >> System.out.println("Completed..."); >> System.out.flush(); >> } >> >> private synchronized void increment() { >> >> counter++; >> >> if (counter % 10000 == 0) { >> System.out.printf("%s: %d\n", Thread.currentThread().getName(), counter); >> System.out.flush(); >> } >> } >> } From henri.gomez at gmail.com Wed Nov 30 06:34:46 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 30 Nov 2011 15:34:46 +0100 Subject: hang in Lion In-Reply-To: <4ED63E33.4000604@oracle.com> References: <4C1AE59E-6E11-4B19-AA48-C0741A0F693D@kodewerk.com> <4ED63E33.4000604@oracle.com> Message-ID: Note, I tested on i7 (SnowLeopard), and Core2Duo (Lion) 2011/11/30 Michael McMahon : > I was able to repeat it using java version "1.6.0_27" > on an imac (with -Xcomp, but not -Xint) . > > Was not able to repeat using 7 on the same system, > I also couldn't repeat it on a different machine using 1.6.0_29. > > So, maybe the issue was fixed between updates 27 and 29? > > - Michael. > > > On 30/11/11 14:21, Henri Gomez wrote: >> >> Hi Charles >> >> Just tried with latest build of OpenJDK 7 for OSX >> >> (http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-jdk-b219-20111130.dmg) >> : >> >> openjdk version "1.7.0-b219" >> OpenJDK Runtime Environment (build 1.7.0-b219-20111130) >> OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode) >> >> Compiled and run with OpenJDK 7 : >> >> Started >> Awaiting complete... >> Thread started Thread-0 >> Thread started Thread-1 >> Thread-0: 10000 >> Thread-1: 20000 >> Thread-0: 30000 >> Thread-0: 40000 >> Thread-1: 50000 >> Thread-1: 60000 >> Thread-1: 70000 >> Thread-1: 80000 >> Thread-1: 90000 >> Thread-1: 100000 >> Thread-0: 110000 >> Thread-0: 120000 >> Thread-1: 130000 >> Thread-0: 140000 >> Thread-1: 150000 >> Thread-0: 160000 >> Thread-0: 170000 >> Thread-0: 180000 >> Thread done Thread-1 >> Thread-0: 190000 >> Thread-0: 200000 >> Thread done Thread-0 >> Completed... >> >> Tried on latest Apple Java 6 (1.6.0-29) and rebuilt Foo with it : >> >> java version "1.6.0_29" >> Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) >> Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) >> >> Started >> Thread started Thread-1 >> Thread started Thread-2 >> Awaiting complete... >> Thread-2: 10000 >> Thread-1: 20000 >> Thread-1: 30000 >> Thread-2: 40000 >> Thread-2: 50000 >> Thread-1: 60000 >> Thread-1: 70000 >> Thread-2: 80000 >> Thread-2: 90000 >> Thread-1: 100000 >> Thread-1: 110000 >> Thread-2: 120000 >> Thread-1: 130000 >> Thread-1: 140000 >> Thread-1: 150000 >> Thread-1: 160000 >> Thread-1: 170000 >> Thread-2: 180000 >> Thread-2: 190000 >> Thread-1: 200000 >> Thread done Thread-2 >> Thread done Thread-1 >> Completed... >> >> Tried on both SnowLeopard and Lion machines. >> >> Cheers >> >> 2011/11/30 Charles K Pepperdine: >>> >>> Hi, >>> >>> I've got a chunk of code that mysteriously hangs on my new i7 Air running >>> Lion. This code was given to me by a friend that is also running Lion. We've >>> given it to another person that is also running Lion. I'm using >>> 1.6.0_26-b02-383. It doesn't hang all the time and it doesn't hang on my >>> older i7 17" MBP running Snow Leopard. It's also been tested on other MBP's >>> running Snow Leopard without hanging. Forcing a core dump after the hang >>> gave us this. >>> >>>> Thread 24: ?Java: Thread-1 >>>> 0 ? libSystem.B.dylib ? ? ? ? ? ? ? ? 0x00007fff89f88d7a mach_msg_trap + >>>> 10 >>>> 1 ? libSystem.B.dylib ? ? ? ? ? ? ? ? 0x00007fff89f893ed mach_msg + 59 >>>> 2 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100d903 jio_snprintf + >>>> 37641 >>>> 3 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100d7c3 jio_snprintf + >>>> 37321 >>>> 4 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100d722 jio_snprintf + >>>> 37160 >>>> 5 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100c5ad jio_snprintf + >>>> 32691 >>>> 6 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100c4ef jio_snprintf + >>>> 32501 >>>> 7 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001011afefd >>>> JVM_GetClassInterfaces + 12075 >>>> 8 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001010a7c8c JVM_Lseek + >>>> 204251 >>>> 9 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001010a7bea JVM_Lseek + >>>> 204089 >>>> 10 ?libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001011b4931 JVM_Socket + >>>> 5319 >>>> 11 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x000000010380f0e7 0 + 4353749223 >>>> 12 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x000000010386fd90 0 + 4354145680 >>>> >>>> Thread 25: ?Java: Thread-2 >>>> 0 ? libSystem.B.dylib ? ? ? ? ? ? ? ? 0x00007fff89f88d7a mach_msg_trap + >>>> 10 >>>> 1 ? libSystem.B.dylib ? ? ? ? ? ? ? ? 0x00007fff89f893ed mach_msg + 59 >>>> 2 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100db03 jio_snprintf + >>>> 38153 >>>> 3 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001010cb569 JVM_Write + >>>> 9130 >>>> 4 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001011ddfcd JVM_NanoTime + >>>> 39179 >>>> 5 ? ??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x000000010386ea60 0 + 4354140768 >>> >>> All of the other thread could be attributed to VM processes (GC, compiler >>> etc...). >>> >>> On my machine, the hang seems to only happen when thread-2 finishes >>> before thread-1. I've never seen it hang when thread-1 finishes before >>> thread-2 Again it doesn't hang all the time when thread-2 finishes first. >>> This is a hard hang in that I can only get rid of the process with a kill >>> -9. ^C and kill simply don't to anything. >>> >>> Code follows, >>> >>> Regards, >>> Kirk Pepperdine >>> >>> public class Foo { >>> >>> ? ?private int counter; >>> >>> ? ?public static void main(String[] args) throws Exception { >>> ? ? ? ?new Foo().run(); >>> ? ?} >>> >>> ? ?public void run() throws Exception { >>> >>> ? ? ? ?Thread[] threads = new Thread[2]; >>> >>> ? ? ? ?for (int i = 0; i< ?threads.length; i++) { >>> ? ? ? ? ? ?threads[i] = new Thread() { >>> ? ? ? ? ? ? ? ?public void run() { >>> >>> ? ? ? ? ? ? ? ? ? ?System.out.println("Thread started " + >>> Thread.currentThread().getName()); >>> ? ? ? ? ? ? ? ? ? ?System.out.flush(); >>> >>> ? ? ? ? ? ? ? ? ? ?for (int i = 0; i< ?100000; i++) { >>> ? ? ? ? ? ? ? ? ? ? ? ?increment(); >>> ? ? ? ? ? ? ? ? ? ?} >>> >>> ? ? ? ? ? ? ? ? ? ?System.out.println("Thread done " + >>> Thread.currentThread().getName()); >>> ? ? ? ? ? ? ? ? ? ?System.out.flush(); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?}; >>> ? ? ? ?} >>> >>> ? ? ? ?for (Thread t : threads) { >>> ? ? ? ? ? ?t.start(); >>> ? ? ? ?} >>> >>> ? ? ? ?System.out.println("Started"); >>> ? ? ? ?System.out.flush(); >>> >>> ? ? ? ?System.out.println("Awaiting complete..."); >>> ? ? ? ?System.out.flush(); >>> >>> ? ? ? ?for (Thread t : threads) { >>> ? ? ? ? ? ?t.join(); >>> ? ? ? ?} >>> >>> ? ? ? ?System.out.println("Completed..."); >>> ? ? ? ?System.out.flush(); >>> ? ?} >>> >>> ? ?private synchronized void increment() { >>> >>> ? ? ? ?counter++; >>> >>> ? ? ? ?if (counter % 10000 == 0) { >>> ? ? ? ? ? ?System.out.printf("%s: %d\n", >>> Thread.currentThread().getName(), counter); >>> ? ? ? ? ? ?System.out.flush(); >>> ? ? ? ?} >>> ? ?} >>> } > > From martijnverburg at gmail.com Wed Nov 30 06:47:42 2011 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 30 Nov 2011 14:47:42 +0000 Subject: hang in Lion In-Reply-To: References: <4C1AE59E-6E11-4B19-AA48-C0741A0F693D@kodewerk.com> <4ED63E33.4000604@oracle.com> Message-ID: Hi all, FWIW I've also tested it using 1.6.0_29 and 1.7.0 b219 on Lion 10.7.2 (on a 13" MBP 2.53 GHz Intel Core 2 Duo) and could not repeat the issue. That said I can't see anything in the _29 release notes that would indicate a fix related to this issue, so I'm dubious that my tests are conclusive. Cheers, Martijn On 30 November 2011 14:34, Henri Gomez wrote: > Note, I tested on i7 (SnowLeopard), and Core2Duo (Lion) > > 2011/11/30 Michael McMahon : >> I was able to repeat it using java version "1.6.0_27" >> on an imac (with -Xcomp, but not -Xint) . >> >> Was not able to repeat using 7 on the same system, >> I also couldn't repeat it on a different machine using 1.6.0_29. >> >> So, maybe the issue was fixed between updates 27 and 29? >> >> - Michael. >> >> >> On 30/11/11 14:21, Henri Gomez wrote: >>> >>> Hi Charles >>> >>> Just tried with latest build of OpenJDK 7 for OSX >>> >>> (http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-jdk-b219-20111130.dmg) >>> : >>> >>> openjdk version "1.7.0-b219" >>> OpenJDK Runtime Environment (build 1.7.0-b219-20111130) >>> OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode) >>> >>> Compiled and run with OpenJDK 7 : >>> >>> Started >>> Awaiting complete... >>> Thread started Thread-0 >>> Thread started Thread-1 >>> Thread-0: 10000 >>> Thread-1: 20000 >>> Thread-0: 30000 >>> Thread-0: 40000 >>> Thread-1: 50000 >>> Thread-1: 60000 >>> Thread-1: 70000 >>> Thread-1: 80000 >>> Thread-1: 90000 >>> Thread-1: 100000 >>> Thread-0: 110000 >>> Thread-0: 120000 >>> Thread-1: 130000 >>> Thread-0: 140000 >>> Thread-1: 150000 >>> Thread-0: 160000 >>> Thread-0: 170000 >>> Thread-0: 180000 >>> Thread done Thread-1 >>> Thread-0: 190000 >>> Thread-0: 200000 >>> Thread done Thread-0 >>> Completed... >>> >>> Tried on latest Apple Java 6 (1.6.0-29) and rebuilt Foo with it : >>> >>> java version "1.6.0_29" >>> Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) >>> Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) >>> >>> Started >>> Thread started Thread-1 >>> Thread started Thread-2 >>> Awaiting complete... >>> Thread-2: 10000 >>> Thread-1: 20000 >>> Thread-1: 30000 >>> Thread-2: 40000 >>> Thread-2: 50000 >>> Thread-1: 60000 >>> Thread-1: 70000 >>> Thread-2: 80000 >>> Thread-2: 90000 >>> Thread-1: 100000 >>> Thread-1: 110000 >>> Thread-2: 120000 >>> Thread-1: 130000 >>> Thread-1: 140000 >>> Thread-1: 150000 >>> Thread-1: 160000 >>> Thread-1: 170000 >>> Thread-2: 180000 >>> Thread-2: 190000 >>> Thread-1: 200000 >>> Thread done Thread-2 >>> Thread done Thread-1 >>> Completed... >>> >>> Tried on both SnowLeopard and Lion machines. >>> >>> Cheers >>> >>> 2011/11/30 Charles K Pepperdine: >>>> >>>> Hi, >>>> >>>> I've got a chunk of code that mysteriously hangs on my new i7 Air running >>>> Lion. This code was given to me by a friend that is also running Lion. We've >>>> given it to another person that is also running Lion. I'm using >>>> 1.6.0_26-b02-383. It doesn't hang all the time and it doesn't hang on my >>>> older i7 17" MBP running Snow Leopard. It's also been tested on other MBP's >>>> running Snow Leopard without hanging. Forcing a core dump after the hang >>>> gave us this. >>>> >>>>> Thread 24: ?Java: Thread-1 >>>>> 0 ? libSystem.B.dylib ? ? ? ? ? ? ? ? 0x00007fff89f88d7a mach_msg_trap + >>>>> 10 >>>>> 1 ? libSystem.B.dylib ? ? ? ? ? ? ? ? 0x00007fff89f893ed mach_msg + 59 >>>>> 2 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100d903 jio_snprintf + >>>>> 37641 >>>>> 3 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100d7c3 jio_snprintf + >>>>> 37321 >>>>> 4 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100d722 jio_snprintf + >>>>> 37160 >>>>> 5 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100c5ad jio_snprintf + >>>>> 32691 >>>>> 6 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100c4ef jio_snprintf + >>>>> 32501 >>>>> 7 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001011afefd >>>>> JVM_GetClassInterfaces + 12075 >>>>> 8 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001010a7c8c JVM_Lseek + >>>>> 204251 >>>>> 9 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001010a7bea JVM_Lseek + >>>>> 204089 >>>>> 10 ?libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001011b4931 JVM_Socket + >>>>> 5319 >>>>> 11 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x000000010380f0e7 0 + 4353749223 >>>>> 12 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x000000010386fd90 0 + 4354145680 >>>>> >>>>> Thread 25: ?Java: Thread-2 >>>>> 0 ? libSystem.B.dylib ? ? ? ? ? ? ? ? 0x00007fff89f88d7a mach_msg_trap + >>>>> 10 >>>>> 1 ? libSystem.B.dylib ? ? ? ? ? ? ? ? 0x00007fff89f893ed mach_msg + 59 >>>>> 2 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x000000010100db03 jio_snprintf + >>>>> 38153 >>>>> 3 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001010cb569 JVM_Write + >>>>> 9130 >>>>> 4 ? libclient64.dylib ? ? ? ? ? ? ? ? 0x00000001011ddfcd JVM_NanoTime + >>>>> 39179 >>>>> 5 ? ??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x000000010386ea60 0 + 4354140768 >>>> >>>> All of the other thread could be attributed to VM processes (GC, compiler >>>> etc...). >>>> >>>> On my machine, the hang seems to only happen when thread-2 finishes >>>> before thread-1. I've never seen it hang when thread-1 finishes before >>>> thread-2 Again it doesn't hang all the time when thread-2 finishes first. >>>> This is a hard hang in that I can only get rid of the process with a kill >>>> -9. ^C and kill simply don't to anything. >>>> >>>> Code follows, >>>> >>>> Regards, >>>> Kirk Pepperdine >>>> >>>> public class Foo { >>>> >>>> ? ?private int counter; >>>> >>>> ? ?public static void main(String[] args) throws Exception { >>>> ? ? ? ?new Foo().run(); >>>> ? ?} >>>> >>>> ? ?public void run() throws Exception { >>>> >>>> ? ? ? ?Thread[] threads = new Thread[2]; >>>> >>>> ? ? ? ?for (int i = 0; i< ?threads.length; i++) { >>>> ? ? ? ? ? ?threads[i] = new Thread() { >>>> ? ? ? ? ? ? ? ?public void run() { >>>> >>>> ? ? ? ? ? ? ? ? ? ?System.out.println("Thread started " + >>>> Thread.currentThread().getName()); >>>> ? ? ? ? ? ? ? ? ? ?System.out.flush(); >>>> >>>> ? ? ? ? ? ? ? ? ? ?for (int i = 0; i< ?100000; i++) { >>>> ? ? ? ? ? ? ? ? ? ? ? ?increment(); >>>> ? ? ? ? ? ? ? ? ? ?} >>>> >>>> ? ? ? ? ? ? ? ? ? ?System.out.println("Thread done " + >>>> Thread.currentThread().getName()); >>>> ? ? ? ? ? ? ? ? ? ?System.out.flush(); >>>> ? ? ? ? ? ? ? ?} >>>> ? ? ? ? ? ?}; >>>> ? ? ? ?} >>>> >>>> ? ? ? ?for (Thread t : threads) { >>>> ? ? ? ? ? ?t.start(); >>>> ? ? ? ?} >>>> >>>> ? ? ? ?System.out.println("Started"); >>>> ? ? ? ?System.out.flush(); >>>> >>>> ? ? ? ?System.out.println("Awaiting complete..."); >>>> ? ? ? ?System.out.flush(); >>>> >>>> ? ? ? ?for (Thread t : threads) { >>>> ? ? ? ? ? ?t.join(); >>>> ? ? ? ?} >>>> >>>> ? ? ? ?System.out.println("Completed..."); >>>> ? ? ? ?System.out.flush(); >>>> ? ?} >>>> >>>> ? ?private synchronized void increment() { >>>> >>>> ? ? ? ?counter++; >>>> >>>> ? ? ? ?if (counter % 10000 == 0) { >>>> ? ? ? ? ? ?System.out.printf("%s: %d\n", >>>> Thread.currentThread().getName(), counter); >>>> ? ? ? ? ? ?System.out.flush(); >>>> ? ? ? ?} >>>> ? ?} >>>> } >> >> > From henri.gomez at gmail.com Wed Nov 30 06:53:13 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 30 Nov 2011 15:53:13 +0100 Subject: hang in Lion In-Reply-To: References: <4C1AE59E-6E11-4B19-AA48-C0741A0F693D@kodewerk.com> <4ED63E33.4000604@oracle.com> Message-ID: 2011/11/30 Martijn Verburg : > Hi all, > > FWIW I've also tested it using 1.6.0_29 and 1.7.0 b219 on Lion 10.7.2 > (on a 13" MBP 2.53 GHz Intel Core 2 Duo) and could not repeat the > issue. ?That said I can't see anything in the _29 release notes that > would indicate a fix related to this issue, so I'm dubious that my > tests are conclusive. I've got a bunch of JVM on my i7 (SnowLeopard) : rwxrwxr-x 3 root admin 102 9 d?c 2010 1.6.0_22-b04-314.jdk drwxrwxr-x 3 root admin 102 5 jan 2011 1.6.0_23-b05-318.jdk drwxrwxr-x 3 root admin 102 25 jan 2011 1.6.0_23-b05-322.jdk drwxrwxr-x 3 root admin 102 7 avr 2011 1.6.0_24-b07-348.jdk drwxrwxr-x 3 root admin 102 3 mai 2011 1.6.0_25-b06-361.jdk drwxrwxr-x 3 root admin 102 17 mai 2011 1.6.0_25-b06-370.jdk drwxrwxr-x 3 root admin 102 3 jui 23:05 1.6.0_26-b03-377.jdk drwxrwxr-x 3 root admin 102 18 jui 00:32 1.6.0_26-b03-384.jdk drwxrwxr-x 3 root admin 102 8 sep 02:57 1.6.0_27-b07-393.jdk drwxrwxr-x 3 root admin 102 22 sep 22:12 1.6.0_27-b07-395.jdk drwxrwxr-x 3 root admin 102 15 oct 00:28 1.6.0_29-b11-397.jdk Tried with latest of each version and didn't get this problem : export JAVA_HOME=/Library/Java/JavaVirtualMachines/1.6.0_26-b03-384.jdk/Contents/Home imac:Desktop henri$ java Foo Started Awaiting complete... Thread started Thread-1 Thread started Thread-2 Thread-1: 10000 Thread-2: 20000 Thread-1: 30000 Thread-1: 40000 Thread-2: 50000 Thread-2: 60000 Thread-1: 70000 Thread-1: 80000 Thread-1: 90000 Thread-1: 100000 Thread-2: 110000 Thread-1: 120000 Thread-2: 130000 Thread-1: 140000 Thread-2: 150000 Thread-1: 160000 Thread-2: 170000 Thread-2: 180000 Thread done Thread-1 Thread-2: 190000 Thread-2: 200000 Thread done Thread-2 Completed... From anthony.petrov at oracle.com Wed Nov 30 07:17:23 2011 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 30 Nov 2011 19:17:23 +0400 Subject: SplashScreen and NSApplication instance initialization In-Reply-To: References: <4ED3E795.30404@oracle.com> Message-ID: <4ED64903.4040309@oracle.com> Hi Mike, Thanks for your comments. On 11/30/2011 3:14 AM, Mike Swingler wrote: > I'd actually suggest creating a helper process to show the splash screen with a minimal UIElement NSApplication instance, and would forward all clicks to the original process over IPC. This would have the added benefit of (potentially) showing the splash screen window before the Dock icon had completely materialized. The only major trick would be handing off image data that was extracted from a jar file (which could be done via a temp file). Rather than playing with IPC, would it be simpler (and faster for that matter) to simply postpone showing the splash screen till the JVM is loaded and initialized but before calling user's main()? This way the NSApplicationAWT code (moved to the Java launcher) could access the necessary system properties. We don't exactly need to have the awt library loaded to init and start an NSApplicationAWT instance properly, do we? The only dependency is setting the ApplicationDelegate, but I guess this could be done later when AWT is finally loaded. Do you expect any issues with this approach? -- best regards, Anthony From swingler at apple.com Wed Nov 30 09:08:12 2011 From: swingler at apple.com (Mike Swingler) Date: Wed, 30 Nov 2011 09:08:12 -0800 Subject: SplashScreen and NSApplication instance initialization In-Reply-To: <4ED64903.4040309@oracle.com> References: <4ED3E795.30404@oracle.com> <4ED64903.4040309@oracle.com> Message-ID: <0C910979-2C9F-417D-9B0E-00FC24D391B8@apple.com> On Nov 30, 2011, at 7:17 AM, Anthony Petrov wrote: > Hi Mike, > > Thanks for your comments. > > On 11/30/2011 3:14 AM, Mike Swingler wrote: >> I'd actually suggest creating a helper process to show the splash screen with a minimal UIElement NSApplication instance, and would forward all clicks to the original process over IPC. This would have the added benefit of (potentially) showing the splash screen window before the Dock icon had completely materialized. The only major trick would be handing off image data that was extracted from a jar file (which could be done via a temp file). > > Rather than playing with IPC, would it be simpler (and faster for that matter) to simply postpone showing the splash screen till the JVM is loaded and initialized but before calling user's main()? This way the NSApplicationAWT code (moved to the Java launcher) could access the necessary system properties. We don't exactly need to have the awt library loaded to init and start an NSApplicationAWT instance properly, do we? The only dependency is setting the ApplicationDelegate, but I guess this could be done later when AWT is finally loaded. > > Do you expect any issues with this approach? AFAIK, any callbacks the NSApplicationAWT class gets from AppKit will require calling into the AWT or the eAWT classes. It would not be wise to defer swapping in the NSApplicationAWT class after you have already created a window, since the NSApp is the arbiter of all of the top-level UI elements. I think you might be able to pull off the splash screen without even doing any IPC, if you just pass arguments to it's main and use the exit code of the helper for any feedback. Regards, Mike Swingler Apple Inc. From swingler at apple.com Wed Nov 30 09:19:19 2011 From: swingler at apple.com (Mike Swingler) Date: Wed, 30 Nov 2011 09:19:19 -0800 Subject: SplashScreen and NSApplicationAWT In-Reply-To: <4ECD3BDE.6080200@oracle.com> References: <4ECD1B4B.3080908@oracle.com> <4ECD3BDE.6080200@oracle.com> Message-ID: <8A562B9F-FBB6-4277-9A6F-D6E6AC03328B@apple.com> I think that the simplest design going forward is it kick off a small command line helper process that links against nothing but AppKit, and embeds an Info.plist in it's binary that contains an LSUIElement=true property (so LaunchServices won't inflate a Dock icon for it when it starts). Regards, Mike Swingler Apple Inc. On Nov 23, 2011, at 10:30 AM, Phil Race wrote: > I suspect you'll have to do something like #1. > > Previous advice on another topic is not to rely on X11. Sounds like a hybrid monster in any case. > My gut is that this is something to steer well clear of. > > Is it possible for an app to start a cocoa event loop for splashscreen, then exit that > when AWT is ready to launch .. and start up the real one ? I'm afraid the answer > here will probably be no .. and its probably impossible to do whilst keeping the > splashscreen visible, but its worth asking. > > -phil. > > On 11/23/2011 8:11 AM, Anthony Petrov wrote: >> Hello, >> >> Another issue with the splash screen is that it needs to display a window on the screen. For this purpose the Cocoa event loop must be started, and as such an NSApp instance be initialized. And this instance is a singleton in Cocoa. >> >> I see that there's already a custom NSApplication descendant present (the NSApplicationAWT), and we can't create and initialize it at the time of splash screen showing since the AWT dynamic library isn't loaded yet. >> >> I see two options to resolve this: >> >> 1. Move the NSApplciationAWT code into the Java launcher code. Either the splash screen code, or AWT would trigger the creation of an application instance. This approach, however, might require a lot of refactoring. >> >> 2. Use Xlib to display the splash screen. This must be the easiest solution, although it may appear a bit inconsistent to the end user (the X icon flashing in the dock, etc. - but perhaps there's a way to suppress that?) Also, I'm not sure if an Xlib-based app is able to actually initialize Cocoa later. >> >> Any thoughts on this? >> >> -- >> best regards, >> Anthony > From peter.brunet at oracle.com Wed Nov 30 10:01:37 2011 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 30 Nov 2011 12:01:37 -0600 Subject: Turning on NSLogs Message-ID: <4ED66F81.5090906@oracle.com> I'm seeing code like this #ifdef JAVA_AX_DEBUG NSLog(@"%s: %@", __FUNCTION__, value); #endif What is the correct way to turn on a definition? I'm also seeing NSLogs which are not bracketed with a define. Does NSLog always output to stdout or does it need a switch of some sort? Thanks, Pete From anthony.petrov at oracle.com Wed Nov 30 10:21:46 2011 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 30 Nov 2011 22:21:46 +0400 Subject: SplashScreen and NSApplication instance initialization In-Reply-To: <0C910979-2C9F-417D-9B0E-00FC24D391B8@apple.com> References: <4ED3E795.30404@oracle.com> <4ED64903.4040309@oracle.com> <0C910979-2C9F-417D-9B0E-00FC24D391B8@apple.com> Message-ID: <4ED6743A.1070701@oracle.com> On 11/30/2011 9:08 PM, Mike Swingler wrote: >> On 11/30/2011 3:14 AM, Mike Swingler wrote: >>> I'd actually suggest creating a helper process to show the splash screen with a minimal UIElement NSApplication instance, and would forward all clicks to the original process over IPC. This would have the added benefit of (potentially) showing the splash screen window before the Dock icon had completely materialized. The only major trick would be handing off image data that was extracted from a jar file (which could be done via a temp file). >> Rather than playing with IPC, would it be simpler (and faster for that matter) to simply postpone showing the splash screen till the JVM is loaded and initialized but before calling user's main()? This way the NSApplicationAWT code (moved to the Java launcher) could access the necessary system properties. We don't exactly need to have the awt library loaded to init and start an NSApplicationAWT instance properly, do we? The only dependency is setting the ApplicationDelegate, but I guess this could be done later when AWT is finally loaded. >> >> Do you expect any issues with this approach? > > AFAIK, any callbacks the NSApplicationAWT class gets from AppKit will require calling into the AWT or the eAWT classes. It would not be wise to defer swapping in the NSApplicationAWT class after you have already created a window, since the NSApp is the arbiter of all of the top-level UI elements. The NSApplicationAWT itself doesn't call AWT directly. It only reads a bunch of Java system properties (which are specified before program starts, obviously). Are those the delegate callbacks that you're referring to? The NSApplication setDelegate: specification doesn't prohibit from setting a delegate at any moment of time. So I suppose theoretically we could install it after AWT has been loaded, while displaying the splash screen window before setting the delegate. Would we just have to invoke a few startup-related callbacks manually then? > I think you might be able to pull off the splash screen without even doing any IPC, if you just pass arguments to it's main and use the exit code of the helper for any feedback. This won't work. The SplashScreen isn't a static entity, the java.awt.SpalshScreen class allows user code to communicate and update it as the application's startup progresses. And the current architecture of the splash screen (e.g. the fact that a pointer to a native structure is stored in the java class, and the structure is used by both shared and platform-specific code) makes it somewhat inconvenient to share the structure between processes. -- best regards, Anthony From swingler at apple.com Wed Nov 30 11:41:29 2011 From: swingler at apple.com (Mike Swingler) Date: Wed, 30 Nov 2011 11:41:29 -0800 Subject: SplashScreen and NSApplication instance initialization In-Reply-To: <4ED6743A.1070701@oracle.com> References: <4ED3E795.30404@oracle.com> <4ED64903.4040309@oracle.com> <0C910979-2C9F-417D-9B0E-00FC24D391B8@apple.com> <4ED6743A.1070701@oracle.com> Message-ID: On Nov 30, 2011, at 10:21 AM, Anthony Petrov wrote: > On 11/30/2011 9:08 PM, Mike Swingler wrote: >>> On 11/30/2011 3:14 AM, Mike Swingler wrote: >>>> I'd actually suggest creating a helper process to show the splash screen with a minimal UIElement NSApplication instance, and would forward all clicks to the original process over IPC. This would have the added benefit of (potentially) showing the splash screen window before the Dock icon had completely materialized. The only major trick would be handing off image data that was extracted from a jar file (which could be done via a temp file). >>> Rather than playing with IPC, would it be simpler (and faster for that matter) to simply postpone showing the splash screen till the JVM is loaded and initialized but before calling user's main()? This way the NSApplicationAWT code (moved to the Java launcher) could access the necessary system properties. We don't exactly need to have the awt library loaded to init and start an NSApplicationAWT instance properly, do we? The only dependency is setting the ApplicationDelegate, but I guess this could be done later when AWT is finally loaded. >>> >>> Do you expect any issues with this approach? >> AFAIK, any callbacks the NSApplicationAWT class gets from AppKit will require calling into the AWT or the eAWT classes. It would not be wise to defer swapping in the NSApplicationAWT class after you have already created a window, since the NSApp is the arbiter of all of the top-level UI elements. > > The NSApplicationAWT itself doesn't call AWT directly. It only reads a bunch of Java system properties (which are specified before program starts, obviously). Are those the delegate callbacks that you're referring to? The NSApplication setDelegate: specification doesn't prohibit from setting a delegate at any moment of time. So I suppose theoretically we could install it after AWT has been loaded, while displaying the splash screen window before setting the delegate. Would we just have to invoke a few startup-related callbacks manually then? The problem is that the moment you show a window, the NSApplicationAWT needs to be installed (if it should be, which it shouldn't in the embedded case). The window won't become visible until the Dock icon has fully materialized. By the time the Dock icon has shown up, your application name is locked in stone, so -registerProcessManager has to be the one controlling that experience or the Java app will look wrong. Also, if the shared delegate is not set in -finishLaunching, you will miss all openFile events that should get delegated to the eAWT listeners. >> I think you might be able to pull off the splash screen without even doing any IPC, if you just pass arguments to it's main and use the exit code of the helper for any feedback. > > This won't work. The SplashScreen isn't a static entity, the java.awt.SpalshScreen class allows user code to communicate and update it as the application's startup progresses. And the current architecture of the splash screen (e.g. the fact that a pointer to a native structure is stored in the java class, and the structure is used by both shared and platform-specific code) makes it somewhat inconvenient to share the structure between processes. Ugh. Yeah, that struct is obnoxious. It might be possible to push AppKit startup logic below AWT, and in the end, the design may be more flexible to accommodate SWT or JavaFX to control the main menubar and the runloop, but it is a fair amount of work. I'd recommend pushing it (as well as the eAWT native functions) into libosxui.dylib (which will change the load library commands in the corresponding Java static initializers). Mike Swingler Apple Inc. From swingler at apple.com Wed Nov 30 12:10:25 2011 From: swingler at apple.com (Mike Swingler) Date: Wed, 30 Nov 2011 12:10:25 -0800 Subject: Turning on NSLogs In-Reply-To: <4ED66F81.5090906@oracle.com> References: <4ED66F81.5090906@oracle.com> Message-ID: <6A41837B-DC00-40EA-BDAA-4C1CA8AF7FAE@apple.com> On Nov 30, 2011, at 10:01 AM, Pete Brunet wrote: > I'm seeing code like this > > #ifdef JAVA_AX_DEBUG > NSLog(@"%s: %@", __FUNCTION__, value); > #endif > > What is the correct way to turn on a definition? #define JAVA_AX_DEBUG 1 > I'm also seeing NSLogs which are not bracketed with a define. Does > NSLog always output to stdout or does it need a switch of some sort? NSLog goes to both stderr and the ASL database (which Console.app shows and lets you query). Regards, Mike Swingler Apple Inc. From swingler at apple.com Wed Nov 30 12:43:56 2011 From: swingler at apple.com (Mike Swingler) Date: Wed, 30 Nov 2011 12:43:56 -0800 Subject: SunGraphics2D instead of Graphics2D In-Reply-To: <7DA8EE55-FCD1-4A57-8E0F-F04175936F2D@gmail.com> References: <4ECA832A.4030307@oracle.com> <3A736034-C9BE-4D9C-B18C-07AE449A33DC@gmail.com> <7DA8EE55-FCD1-4A57-8E0F-F04175936F2D@gmail.com> Message-ID: <1D4394B9-06F8-4BB7-8E77-1DB06C56B97B@apple.com> On Nov 28, 2011, at 4:26 AM, Mario Torre wrote: > Il giorno 21/nov/2011, alle ore 21:48, Mario Torre ha scritto: >> Il giorno 21/nov/2011, alle ore 21:06, Mike Swingler ha scritto: >>> I don't think we had any specific reason to cast SunGraphics2D instead of just Graphics2D. Feel free to change the casts. >>> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> >>> On Nov 21, 2011, at 8:58 AM, Alexander Potochkin wrote: >>> >>>> Hello Mario >>>> >>>> Your patch looks very logic, >>>> let me ask the Apple guys what were the reasons behind that SunGraphics2D cast >>>> >>>> Thanks! >>>> alexp >> >> Hi Mike, Alex, >> >> Thanks for the review. >> >> Should I commit by myself directly? If so, this is the first time I commit to the OSX branch, I'm not sure what the rules are here (do I need a bug id, a special commit repository etc...) >> >> Cheers, >> Mario > > > Hi all, > > Can you please give me some indication how to proceed with this one? I integrated this last night. Cheers, Mike Swingler Apple Inc. From neugens.limasoftware at gmail.com Wed Nov 30 12:46:26 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 30 Nov 2011 21:46:26 +0100 Subject: SunGraphics2D instead of Graphics2D In-Reply-To: <1D4394B9-06F8-4BB7-8E77-1DB06C56B97B@apple.com> References: <4ECA832A.4030307@oracle.com> <3A736034-C9BE-4D9C-B18C-07AE449A33DC@gmail.com> <7DA8EE55-FCD1-4A57-8E0F-F04175936F2D@gmail.com> <1D4394B9-06F8-4BB7-8E77-1DB06C56B97B@apple.com> Message-ID: 2011/11/30 Mike Swingler : > I integrated this last night. > > Cheers, > Mike Swingler > Apple Inc. > Hi Mike, Thanks a lot, 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 leonid.romanov at oracle.com Wed Nov 30 12:43:43 2011 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 1 Dec 2011 00:43:43 +0400 Subject: Tray icon L&F Message-ID: Hi, In JDK 7 (as well in JDK6) clicking status bar image corresponding to TrayIcon gives it grayed out appearance. The thing is, none of the other icons I have sitting in my menu bar highlight in that way. So, I wonder, is there any particular UX reason for such nonstandard L&F or it's just an implementation artifact? I have a patch ready that fixes it, so if there are no objection, I'll go ahead and commit it. Thanks, Leonid. From swingler at apple.com Wed Nov 30 13:04:12 2011 From: swingler at apple.com (Mike Swingler) Date: Wed, 30 Nov 2011 13:04:12 -0800 Subject: Tray icon L&F In-Reply-To: References: Message-ID: <54C5D781-84B9-4637-A970-95EFAD9D4E78@apple.com> On Nov 30, 2011, at 12:43 PM, Leonid Romanov wrote: > Hi, > In JDK 7 (as well in JDK6) clicking status bar image corresponding to TrayIcon gives it grayed out appearance. The thing is, none of the other icons I have sitting in my menu bar highlight in that way. So, I wonder, is there any particular UX reason for such nonstandard L&F or it's just an implementation artifact? I have a patch ready that fixes it, so if there are no objection, I'll go ahead and commit it. Are you setting the NSImage to be a "template" image? Curious, Mike Swingler Apple Inc. From david.katleman at sun.com Wed Nov 30 13:09:45 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 30 Nov 2011 21:09:45 +0000 Subject: hg: macosx-port/macosx-port: Added tag jdk7-b220 for changeset da05c2622f9b Message-ID: <20111130210945.4B913474BC@hg.openjdk.java.net> Changeset: b841f069c9aa Author: katleman Date: 2011-11-30 12:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/rev/b841f069c9aa Added tag jdk7-b220 for changeset da05c2622f9b ! .hgtags From david.katleman at sun.com Wed Nov 30 13:09:54 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 30 Nov 2011 21:09:54 +0000 Subject: hg: macosx-port/macosx-port/corba: Added tag jdk7-b220 for changeset 380d6827f711 Message-ID: <20111130210954.9FE17474BD@hg.openjdk.java.net> Changeset: 1b6549132d99 Author: katleman Date: 2011-11-30 12:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/corba/rev/1b6549132d99 Added tag jdk7-b220 for changeset 380d6827f711 ! .hgtags From david.katleman at sun.com Wed Nov 30 13:10:04 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 30 Nov 2011 21:10:04 +0000 Subject: hg: macosx-port/macosx-port/hotspot: Added tag jdk7-b220 for changeset 552b8fc9f54d Message-ID: <20111130211006.990BA474BE@hg.openjdk.java.net> Changeset: 934d8ea8457c Author: katleman Date: 2011-11-30 12:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/934d8ea8457c Added tag jdk7-b220 for changeset 552b8fc9f54d ! .hgtags From david.katleman at sun.com Wed Nov 30 13:10:15 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 30 Nov 2011 21:10:15 +0000 Subject: hg: macosx-port/macosx-port/jaxp: Added tag jdk7-b220 for changeset 73fb06be0c8a Message-ID: <20111130211016.027B9474BF@hg.openjdk.java.net> Changeset: d81b5ce9d328 Author: katleman Date: 2011-11-30 12:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jaxp/rev/d81b5ce9d328 Added tag jdk7-b220 for changeset 73fb06be0c8a ! .hgtags From david.katleman at sun.com Wed Nov 30 13:10:25 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 30 Nov 2011 21:10:25 +0000 Subject: hg: macosx-port/macosx-port/jaxws: Added tag jdk7-b220 for changeset 662c4761cc87 Message-ID: <20111130211025.8ACCF474C0@hg.openjdk.java.net> Changeset: 0575c4ba3cc6 Author: katleman Date: 2011-11-30 12:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jaxws/rev/0575c4ba3cc6 Added tag jdk7-b220 for changeset 662c4761cc87 ! .hgtags From david.katleman at sun.com Wed Nov 30 13:10:36 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 30 Nov 2011 21:10:36 +0000 Subject: hg: macosx-port/macosx-port/jdk: Added tag jdk7-b220 for changeset 7aa6d26f3478 Message-ID: <20111130211047.6EFF4474C1@hg.openjdk.java.net> Changeset: 147b70f7c35f Author: katleman Date: 2011-11-30 12:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/147b70f7c35f Added tag jdk7-b220 for changeset 7aa6d26f3478 ! .hgtags From david.katleman at sun.com Wed Nov 30 13:10:58 2011 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 30 Nov 2011 21:10:58 +0000 Subject: hg: macosx-port/macosx-port/langtools: Added tag jdk7-b220 for changeset fd65eb1ab980 Message-ID: <20111130211100.4FC28474C3@hg.openjdk.java.net> Changeset: 7f9cfd5d0d9c Author: katleman Date: 2011-11-30 12:35 -0800 URL: http://hg.openjdk.java.net/macosx-port/macosx-port/langtools/rev/7f9cfd5d0d9c Added tag jdk7-b220 for changeset fd65eb1ab980 ! .hgtags From peter.brunet at oracle.com Wed Nov 30 14:05:56 2011 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 30 Nov 2011 16:05:56 -0600 Subject: Turning on NSLogs In-Reply-To: <6A41837B-DC00-40EA-BDAA-4C1CA8AF7FAE@apple.com> References: <4ED66F81.5090906@oracle.com> <6A41837B-DC00-40EA-BDAA-4C1CA8AF7FAE@apple.com> Message-ID: <4ED6A8C4.5070309@oracle.com> On 11/30/11 2:10 PM, Mike Swingler wrote: > On Nov 30, 2011, at 10:01 AM, Pete Brunet wrote: > >> I'm seeing code like this >> >> #ifdef JAVA_AX_DEBUG >> NSLog(@"%s: %@", __FUNCTION__, value); >> #endif >> >> What is the correct way to turn on a definition? > #define JAVA_AX_DEBUG 1 Thanks Mike, What I meant was, can I do something like -DJAVA_AX_DEBUG when invoking make? > >> I'm also seeing NSLogs which are not bracketed with a define. Does >> NSLog always output to stdout or does it need a switch of some sort? > NSLog goes to both stderr and the ASL database (which Console.app shows and lets you query). I see lots of logs in /Library/Logs. Is one of these the "Java" log? > > Regards, > Mike Swingler > Apple Inc. > From swingler at apple.com Wed Nov 30 18:39:25 2011 From: swingler at apple.com (Mike Swingler) Date: Wed, 30 Nov 2011 18:39:25 -0800 Subject: Turning on NSLogs In-Reply-To: <4ED6A8C4.5070309@oracle.com> References: <4ED66F81.5090906@oracle.com> <6A41837B-DC00-40EA-BDAA-4C1CA8AF7FAE@apple.com> <4ED6A8C4.5070309@oracle.com> Message-ID: On Nov 30, 2011, at 2:05 PM, Pete Brunet wrote: > On 11/30/11 2:10 PM, Mike Swingler wrote: >> On Nov 30, 2011, at 10:01 AM, Pete Brunet wrote: >> >>> I'm seeing code like this >>> >>> #ifdef JAVA_AX_DEBUG >>> NSLog(@"%s: %@", __FUNCTION__, value); >>> #endif >>> >>> What is the correct way to turn on a definition? >> #define JAVA_AX_DEBUG 1 > Thanks Mike, What I meant was, can I do something like -DJAVA_AX_DEBUG > when invoking make? I'm not sure - does a Make expert know what the exact syntax is? >>> I'm also seeing NSLogs which are not bracketed with a define. Does >>> NSLog always output to stdout or does it need a switch of some sort? >> NSLog goes to both stderr and the ASL database (which Console.app shows and lets you query). > I see lots of logs in /Library/Logs. Is one of these the "Java" log? No, Java applications are not categorically all logged together. You'll have the most success just reading stderr and ignoring the ASL database. I only mentioned it for technical completeness. Regards, Mike Swingler Apple Inc.