From petr.pchelko at oracle.com Mon Jul 1 06:09:07 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 1 Jul 2013 17:09:07 +0400 Subject: AppContext issues breaks -XstartOnFirstThread for multithreaded programs on both 6_51 and 7_25 In-Reply-To: References: <6D01C8B3-4990-4761-976C-532F5288EE8C@inventivegroup.com>, <51CD9869.5000004@oracle.com> Message-ID: <11BA519B-0FFE-4A64-B284-90B04A1D37D4@oracle.com> Hello, Erik. About the SWT_AWT bridge: it was broken on the Mac OS X for quite a long time, but the new class was implemented within JDK 7 and 8 to support the bridge. This class would be available with JDK7u40. You could download the early access release here: https://jdk7.java.net/download.html However, the new class is not a drop-in replacement of the Apple's implementation, so some changes were needed in SWT. The latest SWT 4.3 builds support the new implementation. So, JDK7u40 + SWT 4.3 would support the SWT_AWT bridge on the Mac again. Here's the swt issue which covers some details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=374199 With best regards. Petr. On Jun 28, 2013, at 7:27 PM, Erik Vanherck wrote: > Nothing really, it was just the simplest test case i came up with. The issue for us is we use swt based apps and even installers all throughout our product suite which do require the parameter and all of them hang at startup. We have one product which uses the swt_awt bridge as well so we are well aware of the mess there but this is preventing any of the apps to properly work. > > As my test case shows even apps which don't go anywhere near awt (or so they think) will end up with hangs, so it won't be long I guess until some eclipse projects will start bumping into the same issue > > Sent from my iPhone > > On 28 Jun 2013, at 16:52, "Anthony Petrov" wrote: > >> Hi Erik, >> >> While this does look like a bug (please file it at http://bugs.sun.com), I have a question. Since this is not a GUI app, why would you run it with -XstartOnFirstThread ? What exactly are you trying to achieve with this command-line switch? >> >> -- >> best regards, >> Anthony >> >> On 06/28/2013 04:57 PM, Erik Vanherck wrote: >>> Hi, >>> >>> I wanted to weigh in a bit since although many people are complaining about the AWT/Swing and webstart issues, it goes much further than that. The AppContext can trigger AWT loading from many locations even as simple as java.util.logging or jmx. In my mind I find it extremely suspicious that these low level utility classes should try to do anything with AWT, especially considering server apps. >>> >>> This test program results in a hang in the spawned thread trying to load in one of the 3 places both on Apple java 1.6.0_51 (with and without the Apple 09 hotfix) and Java 1.7.0_25. It runs as normal java applications, no applet or webstart required, no security manager set, Just add -XstartOnFirstThread to the commandline. >>> >>> import java.lang.management.ManagementFactory; >>> import java.util.logging.Logger; >>> >>> import javax.imageio.spi.IIORegistry; >>> import javax.management.MBeanServer; >>> >>> /** >>> * @author evanherc >>> */ >>> public class AppContextJVMBug { >>> >>> public static void main(String[] args) { >>> try { >>> System.out.println("Launching"); >>> >>> final Thread t = new Thread(new Runnable() { >>> public void run() { >>> try { >>> utilLoggingHang(); >>> jmxHang(); >>> imageioHang(); >>> } catch (Throwable t) { >>> t.printStackTrace(); >>> } >>> } >>> }); >>> >>> t.start(); >>> t.join(); >>> System.out.println("Finished"); >>> } catch (Throwable t) { >>> t.printStackTrace(); >>> } >>> } >>> >>> private static void utilLoggingHang() { >>> final Logger l = Logger.getLogger("MyApp"); >>> System.out.println("Done obtaining a logger " + l); >>> } >>> >>> private static void jmxHang() { >>> final MBeanServer mb = ManagementFactory.getPlatformMBeanServer(); >>> System.out.println("Done getting the platform mbean server " + mb); >>> } >>> >>> private static void imageioHang() { >>> final IIORegistry registry = IIORegistry.getDefaultInstance(); >>> System.out.println("Done retrieving image registry " + registry); >>> } >>> } >>> >>> >>> >>> Tested on several Apple Mac OS X 10.8.4 machines. >>> Without JVM arguments : runs fine >>> With -XstartOnFirstThread : hangs >>> With -XstartOnFirstThread and -Djava.awt.headless=true : runs fine >>> >>> Here's actual stack traces from our large product suites. They break for everyone as we run inside Eclipse and as such have to specify -XstartOnFirstThread. >>> I've seen a dozen variants now (there is other classes triggering AppContext as well). >>> >>> "Thread-4" daemon prio=5 tid=7febb49ae800 nid=0x10f2fb000 runnable [10f2f6000] >>> java.lang.Thread.State: RUNNABLE >>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1827) >>> - locked <7dc02aec0> (a java.util.Vector) >>> - locked <7dc02aee0> (a java.util.Vector) >>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1724) >>> at java.lang.Runtime.loadLibrary0(Runtime.java:823) >>> - locked <7dc02cb28> (a java.lang.Runtime) >>> at java.lang.System.loadLibrary(System.java:1045) >>> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at java.awt.Toolkit.loadLibraries(Toolkit.java:1605) >>> at java.awt.Toolkit.(Toolkit.java:1627) >>> at sun.awt.AppContext$2.run(AppContext.java:240) >>> at sun.awt.AppContext$2.run(AppContext.java:226) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at sun.awt.AppContext.initMainAppContext(AppContext.java:226) >>> at sun.awt.AppContext.access$200(AppContext.java:112) >>> at sun.awt.AppContext$3.run(AppContext.java:306) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at sun.awt.AppContext.getAppContext(AppContext.java:287) >>> at com.sun.jmx.trace.Trace.out(Trace.java:180) >>> - locked <7f8eea490> (a java.lang.Class for com.sun.jmx.trace.Trace) >>> at com.sun.jmx.trace.Trace.isSelected(Trace.java:88) >>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.isTraceOn(DefaultMBeanServerInterceptor.java:1830) >>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:929) >>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:916) >>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) >>> at com.sun.jmx.mbeanserver.JmxMBeanServer$2.run(JmxMBeanServer.java:1195) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at com.sun.jmx.mbeanserver.JmxMBeanServer.initialize(JmxMBeanServer.java:1193) >>> at com.sun.jmx.mbeanserver.JmxMBeanServer.(JmxMBeanServer.java:225) >>> at com.sun.jmx.mbeanserver.JmxMBeanServer.(JmxMBeanServer.java:170) >>> at com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(JmxMBeanServer.java:1401) >>> at javax.management.MBeanServerBuilder.newMBeanServer(MBeanServerBuilder.java:93) >>> at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:311) >>> - locked <7d824f618> (a javax.management.MBeanServerBuilder) >>> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:214) >>> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:175) >>> at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302) >>> at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504) >>> - locked <7f8e00140> (a java.lang.Class for java.lang.management.ManagementFactory) >>> at id.core.version.provider.ProductVersionProvider.(ProductVersionProvider.java:68) >>> at id.core.version.provider.ProductVersionProvider.getInstance(ProductVersionProvider.java:37) >>> - locked <7f8dd00a8> (a java.lang.Class for id.core.version.provider.ProductVersionProvider) >>> at id.core.version.VersionInfo.getProductID(VersionInfo.java:98) >>> at com.id.core.platform.util.application.ProductDirectories.calculateCurrentUserProgramDir(ProductDirectories.java:31) >>> at com.id.core.platform.util.application.ProductDirectories.(ProductDirectories.java:22) >>> at com.id.core.platform.repository.BundleRepository.parsePluginFile(BundleRepository.java:235) >>> at com.id.core.platform.repository.BundleRepository.(BundleRepository.java:101) >>> at com.id.core.platform.Platform.bootstrap(Platform.java:178) >>> - locked <7d81cb4c8> (a java.lang.Object) >>> - locked <7d81cb4a8> (a com.id.core.platform.Platform) >>> at com.id.core.platform.activator.Activator$1.run(Activator.java:77) >>> - locked <7d81aca68> (a java.lang.Object) >>> >>> "Thread-2" prio=5 tid=0x00007f9973093800 nid=0x7e03 runnable [0x0000000137b2f000] >>> java.lang.Thread.State: RUNNABLE >>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>> at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957) >>> - locked <0x0000000128bc39a8> (a java.util.Vector) >>> - locked <0x0000000128bc3610> (a java.util.Vector) >>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882) >>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843) >>> at java.lang.Runtime.load0(Runtime.java:795) >>> - locked <0x0000000110a457a8> (a java.lang.Runtime) >>> at java.lang.System.load(System.java:1061) >>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>> at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957) >>> - locked <0x0000000128bc39a8> (a java.util.Vector) >>> - locked <0x0000000128bc3610> (a java.util.Vector) >>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882) >>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864) >>> at java.lang.Runtime.loadLibrary0(Runtime.java:849) >>> - locked <0x0000000110a457a8> (a java.lang.Runtime) >>> at java.lang.System.loadLibrary(System.java:1087) >>> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67) >>> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at java.awt.Toolkit.loadLibraries(Toolkit.java:1646) >>> at java.awt.Toolkit.(Toolkit.java:1668) >>> at sun.awt.AppContext$2.run(AppContext.java:271) >>> at sun.awt.AppContext$2.run(AppContext.java:260) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at sun.awt.AppContext.initMainAppContext(AppContext.java:260) >>> at sun.awt.AppContext.access$200(AppContext.java:133) >>> at sun.awt.AppContext$3.run(AppContext.java:316) >>> at sun.awt.AppContext$3.run(AppContext.java:298) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at sun.awt.AppContext.getAppContext(AppContext.java:297) >>> at javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:154) >>> at com.id.external.javax.media.jai.Services.register(Services.java:20) >>> at com.id.external.javax.media.jai.activator.Activator.start(Activator.java:26) >>> at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702) >>> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683) >>> at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381) >>> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299) >>> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291) >>> at com.id.core.platform.repository.BundleRepository.startBundle(BundleRepository.java:486) >>> at com.id.core.platform.repository.BundleRepository.handleResolvedBundle(BundleRepository.java:389) >>> at com.id.core.platform.repository.BundleRepository.scanBundles(BundleRepository.java:269) >>> at com.id.core.platform.repository.BundleRepository.start(BundleRepository.java:118) >>> - locked <0x00000001259d7d20> (a java.lang.Object) >>> at com.id.core.platform.Platform.bootstrap(Platform.java:184) >>> - locked <0x00000001259d4000> (a java.lang.Object) >>> - locked <0x00000001259d3fe0> (a com.id.core.platform.Platform) >>> at com.id.core.platform.activator.Activator$1.run(Activator.java:77) >>> - locked <0x00000001259ce758> (a java.lang.Object) >>> >>> I've been looking in the source but not sure if those fixes are already in the jdk 1.7u forest. >>> >>> Erik Vanherck >>> >>> ________________________________ >>> >>> Inventive Designers' Email Disclaimer: >>> http://www.inventivedesigners.com/email-disclaimer >> >> > > ________________________________ > > Inventive Designers' Email Disclaimer: > http://www.inventivedesigners.com/email-disclaimer From Erik.Vanherck at inventivegroup.com Mon Jul 1 07:48:26 2013 From: Erik.Vanherck at inventivegroup.com (Erik Vanherck) Date: Mon, 1 Jul 2013 14:48:26 +0000 Subject: AppContext issues breaks -XstartOnFirstThread for multithreaded programs on both 6_51 and 7_25 In-Reply-To: <11BA519B-0FFE-4A64-B284-90B04A1D37D4@oracle.com> References: <6D01C8B3-4990-4761-976C-532F5288EE8C@inventivegroup.com>, <51CD9869.5000004@oracle.com> <11BA519B-0FFE-4A64-B284-90B04A1D37D4@oracle.com> Message-ID: <07D4DC6F-EF26-414C-B72B-6A2B94263729@inventivegroup.com> Hi Petr, Yes I'm aware of that, I'm the original reporter of the SWT_AWT being broken. I try to keep up with the early access builds and have been toying with it already. We still need to back port the SWT changes as we depend on Eclipse 3.7.2 and get our QA to run through it. I definitely appreciate all the hard work you did on that part especially since as a developer I certainly also feel that the whole SWT-AWT bridge thing is just a patch on a workaround on a gaping hole on a bad idea but once those things get out, they start leading their own life :-) Our mac users of that particular application are the very last holdouts on java 1.6 (for us) so would be welcome once we get that out in the field. In regards to the current mail : it's currently been accepted as bug 9004676 Cheers, Erik On 01 Jul 2013, at 15:09, Petr Pchelko wrote: > Hello, Erik. > > About the SWT_AWT bridge: it was broken on the Mac OS X for quite a long time, but the new class was implemented within JDK 7 and 8 to support the bridge. This class would be available with JDK7u40. You could download the early access release here: https://jdk7.java.net/download.html However, the new class is not a drop-in replacement of the Apple's implementation, so some changes were needed in SWT. The latest SWT 4.3 builds support the new implementation. > > So, JDK7u40 + SWT 4.3 would support the SWT_AWT bridge on the Mac again. > > Here's the swt issue which covers some details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=374199 > > With best regards. Petr. > > On Jun 28, 2013, at 7:27 PM, Erik Vanherck wrote: > >> Nothing really, it was just the simplest test case i came up with. The issue for us is we use swt based apps and even installers all throughout our product suite which do require the parameter and all of them hang at startup. We have one product which uses the swt_awt bridge as well so we are well aware of the mess there but this is preventing any of the apps to properly work. >> >> As my test case shows even apps which don't go anywhere near awt (or so they think) will end up with hangs, so it won't be long I guess until some eclipse projects will start bumping into the same issue >> >> Sent from my iPhone >> >> On 28 Jun 2013, at 16:52, "Anthony Petrov" wrote: >> >>> Hi Erik, >>> >>> While this does look like a bug (please file it at http://bugs.sun.com), I have a question. Since this is not a GUI app, why would you run it with -XstartOnFirstThread ? What exactly are you trying to achieve with this command-line switch? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 06/28/2013 04:57 PM, Erik Vanherck wrote: >>>> Hi, >>>> >>>> I wanted to weigh in a bit since although many people are complaining about the AWT/Swing and webstart issues, it goes much further than that. The AppContext can trigger AWT loading from many locations even as simple as java.util.logging or jmx. In my mind I find it extremely suspicious that these low level utility classes should try to do anything with AWT, especially considering server apps. >>>> >>>> This test program results in a hang in the spawned thread trying to load in one of the 3 places both on Apple java 1.6.0_51 (with and without the Apple 09 hotfix) and Java 1.7.0_25. It runs as normal java applications, no applet or webstart required, no security manager set, Just add -XstartOnFirstThread to the commandline. >>>> >>>> import java.lang.management.ManagementFactory; >>>> import java.util.logging.Logger; >>>> >>>> import javax.imageio.spi.IIORegistry; >>>> import javax.management.MBeanServer; >>>> >>>> /** >>>> * @author evanherc >>>> */ >>>> public class AppContextJVMBug { >>>> >>>> public static void main(String[] args) { >>>> try { >>>> System.out.println("Launching"); >>>> >>>> final Thread t = new Thread(new Runnable() { >>>> public void run() { >>>> try { >>>> utilLoggingHang(); >>>> jmxHang(); >>>> imageioHang(); >>>> } catch (Throwable t) { >>>> t.printStackTrace(); >>>> } >>>> } >>>> }); >>>> >>>> t.start(); >>>> t.join(); >>>> System.out.println("Finished"); >>>> } catch (Throwable t) { >>>> t.printStackTrace(); >>>> } >>>> } >>>> >>>> private static void utilLoggingHang() { >>>> final Logger l = Logger.getLogger("MyApp"); >>>> System.out.println("Done obtaining a logger " + l); >>>> } >>>> >>>> private static void jmxHang() { >>>> final MBeanServer mb = ManagementFactory.getPlatformMBeanServer(); >>>> System.out.println("Done getting the platform mbean server " + mb); >>>> } >>>> >>>> private static void imageioHang() { >>>> final IIORegistry registry = IIORegistry.getDefaultInstance(); >>>> System.out.println("Done retrieving image registry " + registry); >>>> } >>>> } >>>> >>>> >>>> >>>> Tested on several Apple Mac OS X 10.8.4 machines. >>>> Without JVM arguments : runs fine >>>> With -XstartOnFirstThread : hangs >>>> With -XstartOnFirstThread and -Djava.awt.headless=true : runs fine >>>> >>>> Here's actual stack traces from our large product suites. They break for everyone as we run inside Eclipse and as such have to specify -XstartOnFirstThread. >>>> I've seen a dozen variants now (there is other classes triggering AppContext as well). >>>> >>>> "Thread-4" daemon prio=5 tid=7febb49ae800 nid=0x10f2fb000 runnable [10f2f6000] >>>> java.lang.Thread.State: RUNNABLE >>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1827) >>>> - locked <7dc02aec0> (a java.util.Vector) >>>> - locked <7dc02aee0> (a java.util.Vector) >>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1724) >>>> at java.lang.Runtime.loadLibrary0(Runtime.java:823) >>>> - locked <7dc02cb28> (a java.lang.Runtime) >>>> at java.lang.System.loadLibrary(System.java:1045) >>>> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at java.awt.Toolkit.loadLibraries(Toolkit.java:1605) >>>> at java.awt.Toolkit.(Toolkit.java:1627) >>>> at sun.awt.AppContext$2.run(AppContext.java:240) >>>> at sun.awt.AppContext$2.run(AppContext.java:226) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at sun.awt.AppContext.initMainAppContext(AppContext.java:226) >>>> at sun.awt.AppContext.access$200(AppContext.java:112) >>>> at sun.awt.AppContext$3.run(AppContext.java:306) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at sun.awt.AppContext.getAppContext(AppContext.java:287) >>>> at com.sun.jmx.trace.Trace.out(Trace.java:180) >>>> - locked <7f8eea490> (a java.lang.Class for com.sun.jmx.trace.Trace) >>>> at com.sun.jmx.trace.Trace.isSelected(Trace.java:88) >>>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.isTraceOn(DefaultMBeanServerInterceptor.java:1830) >>>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:929) >>>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:916) >>>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) >>>> at com.sun.jmx.mbeanserver.JmxMBeanServer$2.run(JmxMBeanServer.java:1195) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at com.sun.jmx.mbeanserver.JmxMBeanServer.initialize(JmxMBeanServer.java:1193) >>>> at com.sun.jmx.mbeanserver.JmxMBeanServer.(JmxMBeanServer.java:225) >>>> at com.sun.jmx.mbeanserver.JmxMBeanServer.(JmxMBeanServer.java:170) >>>> at com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(JmxMBeanServer.java:1401) >>>> at javax.management.MBeanServerBuilder.newMBeanServer(MBeanServerBuilder.java:93) >>>> at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:311) >>>> - locked <7d824f618> (a javax.management.MBeanServerBuilder) >>>> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:214) >>>> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:175) >>>> at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302) >>>> at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504) >>>> - locked <7f8e00140> (a java.lang.Class for java.lang.management.ManagementFactory) >>>> at id.core.version.provider.ProductVersionProvider.(ProductVersionProvider.java:68) >>>> at id.core.version.provider.ProductVersionProvider.getInstance(ProductVersionProvider.java:37) >>>> - locked <7f8dd00a8> (a java.lang.Class for id.core.version.provider.ProductVersionProvider) >>>> at id.core.version.VersionInfo.getProductID(VersionInfo.java:98) >>>> at com.id.core.platform.util.application.ProductDirectories.calculateCurrentUserProgramDir(ProductDirectories.java:31) >>>> at com.id.core.platform.util.application.ProductDirectories.(ProductDirectories.java:22) >>>> at com.id.core.platform.repository.BundleRepository.parsePluginFile(BundleRepository.java:235) >>>> at com.id.core.platform.repository.BundleRepository.(BundleRepository.java:101) >>>> at com.id.core.platform.Platform.bootstrap(Platform.java:178) >>>> - locked <7d81cb4c8> (a java.lang.Object) >>>> - locked <7d81cb4a8> (a com.id.core.platform.Platform) >>>> at com.id.core.platform.activator.Activator$1.run(Activator.java:77) >>>> - locked <7d81aca68> (a java.lang.Object) >>>> >>>> "Thread-2" prio=5 tid=0x00007f9973093800 nid=0x7e03 runnable [0x0000000137b2f000] >>>> java.lang.Thread.State: RUNNABLE >>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>> at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957) >>>> - locked <0x0000000128bc39a8> (a java.util.Vector) >>>> - locked <0x0000000128bc3610> (a java.util.Vector) >>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882) >>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843) >>>> at java.lang.Runtime.load0(Runtime.java:795) >>>> - locked <0x0000000110a457a8> (a java.lang.Runtime) >>>> at java.lang.System.load(System.java:1061) >>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>> at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957) >>>> - locked <0x0000000128bc39a8> (a java.util.Vector) >>>> - locked <0x0000000128bc3610> (a java.util.Vector) >>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882) >>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864) >>>> at java.lang.Runtime.loadLibrary0(Runtime.java:849) >>>> - locked <0x0000000110a457a8> (a java.lang.Runtime) >>>> at java.lang.System.loadLibrary(System.java:1087) >>>> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67) >>>> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at java.awt.Toolkit.loadLibraries(Toolkit.java:1646) >>>> at java.awt.Toolkit.(Toolkit.java:1668) >>>> at sun.awt.AppContext$2.run(AppContext.java:271) >>>> at sun.awt.AppContext$2.run(AppContext.java:260) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at sun.awt.AppContext.initMainAppContext(AppContext.java:260) >>>> at sun.awt.AppContext.access$200(AppContext.java:133) >>>> at sun.awt.AppContext$3.run(AppContext.java:316) >>>> at sun.awt.AppContext$3.run(AppContext.java:298) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at sun.awt.AppContext.getAppContext(AppContext.java:297) >>>> at javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:154) >>>> at com.id.external.javax.media.jai.Services.register(Services.java:20) >>>> at com.id.external.javax.media.jai.activator.Activator.start(Activator.java:26) >>>> at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702) >>>> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683) >>>> at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381) >>>> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299) >>>> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291) >>>> at com.id.core.platform.repository.BundleRepository.startBundle(BundleRepository.java:486) >>>> at com.id.core.platform.repository.BundleRepository.handleResolvedBundle(BundleRepository.java:389) >>>> at com.id.core.platform.repository.BundleRepository.scanBundles(BundleRepository.java:269) >>>> at com.id.core.platform.repository.BundleRepository.start(BundleRepository.java:118) >>>> - locked <0x00000001259d7d20> (a java.lang.Object) >>>> at com.id.core.platform.Platform.bootstrap(Platform.java:184) >>>> - locked <0x00000001259d4000> (a java.lang.Object) >>>> - locked <0x00000001259d3fe0> (a com.id.core.platform.Platform) >>>> at com.id.core.platform.activator.Activator$1.run(Activator.java:77) >>>> - locked <0x00000001259ce758> (a java.lang.Object) >>>> >>>> I've been looking in the source but not sure if those fixes are already in the jdk 1.7u forest. >>>> >>>> Erik Vanherck >>>> >>>> ________________________________ >>>> >>>> Inventive Designers' Email Disclaimer: >>>> http://www.inventivedesigners.com/email-disclaimer >>> >>> >> >> ________________________________ >> >> Inventive Designers' Email Disclaimer: >> http://www.inventivedesigners.com/email-disclaimer > > > ________________________________ Inventive Designers' Email Disclaimer: http://www.inventivedesigners.com/email-disclaimer From anthony.petrov at oracle.com Mon Jul 1 08:16:42 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 01 Jul 2013 19:16:42 +0400 Subject: AppContext issues breaks -XstartOnFirstThread for multithreaded programs on both 6_51 and 7_25 In-Reply-To: <07D4DC6F-EF26-414C-B72B-6A2B94263729@inventivegroup.com> References: <6D01C8B3-4990-4761-976C-532F5288EE8C@inventivegroup.com>, <51CD9869.5000004@oracle.com> <11BA519B-0FFE-4A64-B284-90B04A1D37D4@oracle.com> <07D4DC6F-EF26-414C-B72B-6A2B94263729@inventivegroup.com> Message-ID: <51D19D5A.3030502@oracle.com> > In regards to the current mail : it's currently been accepted as bug 9004676 Which is actually 8019496 now. You can watch it on bugs.sun.com (once it becomes visible). The 9* are internal incident numbers, they aren't very useful. -- best regards, Anthony On 07/01/2013 06:48 PM, Erik Vanherck wrote: > Hi Petr, > > Yes I'm aware of that, I'm the original reporter of the SWT_AWT being broken. I try to keep up with the early access builds and have been toying with it already. We still need to back port the SWT changes as we depend on Eclipse 3.7.2 and get our QA to run through it. I definitely appreciate all the hard work you did on that part especially since as a developer I certainly also feel that the whole SWT-AWT bridge thing is just a patch on a workaround on a gaping hole on a bad idea but once those things get out, they start leading their own life :-) Our mac users of that particular application are the very last holdouts on java 1.6 (for us) so would be welcome once we get that out in the field. > > In regards to the current mail : it's currently been accepted as bug 9004676 > > Cheers, > Erik > > On 01 Jul 2013, at 15:09, Petr Pchelko wrote: > >> Hello, Erik. >> >> About the SWT_AWT bridge: it was broken on the Mac OS X for quite a long time, but the new class was implemented within JDK 7 and 8 to support the bridge. This class would be available with JDK7u40. You could download the early access release here: https://jdk7.java.net/download.html However, the new class is not a drop-in replacement of the Apple's implementation, so some changes were needed in SWT. The latest SWT 4.3 builds support the new implementation. >> >> So, JDK7u40 + SWT 4.3 would support the SWT_AWT bridge on the Mac again. >> >> Here's the swt issue which covers some details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=374199 >> >> With best regards. Petr. >> >> On Jun 28, 2013, at 7:27 PM, Erik Vanherck wrote: >> >>> Nothing really, it was just the simplest test case i came up with. The issue for us is we use swt based apps and even installers all throughout our product suite which do require the parameter and all of them hang at startup. We have one product which uses the swt_awt bridge as well so we are well aware of the mess there but this is preventing any of the apps to properly work. >>> >>> As my test case shows even apps which don't go anywhere near awt (or so they think) will end up with hangs, so it won't be long I guess until some eclipse projects will start bumping into the same issue >>> >>> Sent from my iPhone >>> >>> On 28 Jun 2013, at 16:52, "Anthony Petrov" wrote: >>> >>>> Hi Erik, >>>> >>>> While this does look like a bug (please file it at http://bugs.sun.com), I have a question. Since this is not a GUI app, why would you run it with -XstartOnFirstThread ? What exactly are you trying to achieve with this command-line switch? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 06/28/2013 04:57 PM, Erik Vanherck wrote: >>>>> Hi, >>>>> >>>>> I wanted to weigh in a bit since although many people are complaining about the AWT/Swing and webstart issues, it goes much further than that. The AppContext can trigger AWT loading from many locations even as simple as java.util.logging or jmx. In my mind I find it extremely suspicious that these low level utility classes should try to do anything with AWT, especially considering server apps. >>>>> >>>>> This test program results in a hang in the spawned thread trying to load in one of the 3 places both on Apple java 1.6.0_51 (with and without the Apple 09 hotfix) and Java 1.7.0_25. It runs as normal java applications, no applet or webstart required, no security manager set, Just add -XstartOnFirstThread to the commandline. >>>>> >>>>> import java.lang.management.ManagementFactory; >>>>> import java.util.logging.Logger; >>>>> >>>>> import javax.imageio.spi.IIORegistry; >>>>> import javax.management.MBeanServer; >>>>> >>>>> /** >>>>> * @author evanherc >>>>> */ >>>>> public class AppContextJVMBug { >>>>> >>>>> public static void main(String[] args) { >>>>> try { >>>>> System.out.println("Launching"); >>>>> >>>>> final Thread t = new Thread(new Runnable() { >>>>> public void run() { >>>>> try { >>>>> utilLoggingHang(); >>>>> jmxHang(); >>>>> imageioHang(); >>>>> } catch (Throwable t) { >>>>> t.printStackTrace(); >>>>> } >>>>> } >>>>> }); >>>>> >>>>> t.start(); >>>>> t.join(); >>>>> System.out.println("Finished"); >>>>> } catch (Throwable t) { >>>>> t.printStackTrace(); >>>>> } >>>>> } >>>>> >>>>> private static void utilLoggingHang() { >>>>> final Logger l = Logger.getLogger("MyApp"); >>>>> System.out.println("Done obtaining a logger " + l); >>>>> } >>>>> >>>>> private static void jmxHang() { >>>>> final MBeanServer mb = ManagementFactory.getPlatformMBeanServer(); >>>>> System.out.println("Done getting the platform mbean server " + mb); >>>>> } >>>>> >>>>> private static void imageioHang() { >>>>> final IIORegistry registry = IIORegistry.getDefaultInstance(); >>>>> System.out.println("Done retrieving image registry " + registry); >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>>> Tested on several Apple Mac OS X 10.8.4 machines. >>>>> Without JVM arguments : runs fine >>>>> With -XstartOnFirstThread : hangs >>>>> With -XstartOnFirstThread and -Djava.awt.headless=true : runs fine >>>>> >>>>> Here's actual stack traces from our large product suites. They break for everyone as we run inside Eclipse and as such have to specify -XstartOnFirstThread. >>>>> I've seen a dozen variants now (there is other classes triggering AppContext as well). >>>>> >>>>> "Thread-4" daemon prio=5 tid=7febb49ae800 nid=0x10f2fb000 runnable [10f2f6000] >>>>> java.lang.Thread.State: RUNNABLE >>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1827) >>>>> - locked <7dc02aec0> (a java.util.Vector) >>>>> - locked <7dc02aee0> (a java.util.Vector) >>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1724) >>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:823) >>>>> - locked <7dc02cb28> (a java.lang.Runtime) >>>>> at java.lang.System.loadLibrary(System.java:1045) >>>>> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at java.awt.Toolkit.loadLibraries(Toolkit.java:1605) >>>>> at java.awt.Toolkit.(Toolkit.java:1627) >>>>> at sun.awt.AppContext$2.run(AppContext.java:240) >>>>> at sun.awt.AppContext$2.run(AppContext.java:226) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at sun.awt.AppContext.initMainAppContext(AppContext.java:226) >>>>> at sun.awt.AppContext.access$200(AppContext.java:112) >>>>> at sun.awt.AppContext$3.run(AppContext.java:306) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at sun.awt.AppContext.getAppContext(AppContext.java:287) >>>>> at com.sun.jmx.trace.Trace.out(Trace.java:180) >>>>> - locked <7f8eea490> (a java.lang.Class for com.sun.jmx.trace.Trace) >>>>> at com.sun.jmx.trace.Trace.isSelected(Trace.java:88) >>>>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.isTraceOn(DefaultMBeanServerInterceptor.java:1830) >>>>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:929) >>>>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:916) >>>>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) >>>>> at com.sun.jmx.mbeanserver.JmxMBeanServer$2.run(JmxMBeanServer.java:1195) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at com.sun.jmx.mbeanserver.JmxMBeanServer.initialize(JmxMBeanServer.java:1193) >>>>> at com.sun.jmx.mbeanserver.JmxMBeanServer.(JmxMBeanServer.java:225) >>>>> at com.sun.jmx.mbeanserver.JmxMBeanServer.(JmxMBeanServer.java:170) >>>>> at com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(JmxMBeanServer.java:1401) >>>>> at javax.management.MBeanServerBuilder.newMBeanServer(MBeanServerBuilder.java:93) >>>>> at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:311) >>>>> - locked <7d824f618> (a javax.management.MBeanServerBuilder) >>>>> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:214) >>>>> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:175) >>>>> at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302) >>>>> at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504) >>>>> - locked <7f8e00140> (a java.lang.Class for java.lang.management.ManagementFactory) >>>>> at id.core.version.provider.ProductVersionProvider.(ProductVersionProvider.java:68) >>>>> at id.core.version.provider.ProductVersionProvider.getInstance(ProductVersionProvider.java:37) >>>>> - locked <7f8dd00a8> (a java.lang.Class for id.core.version.provider.ProductVersionProvider) >>>>> at id.core.version.VersionInfo.getProductID(VersionInfo.java:98) >>>>> at com.id.core.platform.util.application.ProductDirectories.calculateCurrentUserProgramDir(ProductDirectories.java:31) >>>>> at com.id.core.platform.util.application.ProductDirectories.(ProductDirectories.java:22) >>>>> at com.id.core.platform.repository.BundleRepository.parsePluginFile(BundleRepository.java:235) >>>>> at com.id.core.platform.repository.BundleRepository.(BundleRepository.java:101) >>>>> at com.id.core.platform.Platform.bootstrap(Platform.java:178) >>>>> - locked <7d81cb4c8> (a java.lang.Object) >>>>> - locked <7d81cb4a8> (a com.id.core.platform.Platform) >>>>> at com.id.core.platform.activator.Activator$1.run(Activator.java:77) >>>>> - locked <7d81aca68> (a java.lang.Object) >>>>> >>>>> "Thread-2" prio=5 tid=0x00007f9973093800 nid=0x7e03 runnable [0x0000000137b2f000] >>>>> java.lang.Thread.State: RUNNABLE >>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>> at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957) >>>>> - locked <0x0000000128bc39a8> (a java.util.Vector) >>>>> - locked <0x0000000128bc3610> (a java.util.Vector) >>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882) >>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843) >>>>> at java.lang.Runtime.load0(Runtime.java:795) >>>>> - locked <0x0000000110a457a8> (a java.lang.Runtime) >>>>> at java.lang.System.load(System.java:1061) >>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>> at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957) >>>>> - locked <0x0000000128bc39a8> (a java.util.Vector) >>>>> - locked <0x0000000128bc3610> (a java.util.Vector) >>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882) >>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864) >>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:849) >>>>> - locked <0x0000000110a457a8> (a java.lang.Runtime) >>>>> at java.lang.System.loadLibrary(System.java:1087) >>>>> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67) >>>>> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at java.awt.Toolkit.loadLibraries(Toolkit.java:1646) >>>>> at java.awt.Toolkit.(Toolkit.java:1668) >>>>> at sun.awt.AppContext$2.run(AppContext.java:271) >>>>> at sun.awt.AppContext$2.run(AppContext.java:260) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at sun.awt.AppContext.initMainAppContext(AppContext.java:260) >>>>> at sun.awt.AppContext.access$200(AppContext.java:133) >>>>> at sun.awt.AppContext$3.run(AppContext.java:316) >>>>> at sun.awt.AppContext$3.run(AppContext.java:298) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at sun.awt.AppContext.getAppContext(AppContext.java:297) >>>>> at javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:154) >>>>> at com.id.external.javax.media.jai.Services.register(Services.java:20) >>>>> at com.id.external.javax.media.jai.activator.Activator.start(Activator.java:26) >>>>> at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702) >>>>> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683) >>>>> at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381) >>>>> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299) >>>>> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291) >>>>> at com.id.core.platform.repository.BundleRepository.startBundle(BundleRepository.java:486) >>>>> at com.id.core.platform.repository.BundleRepository.handleResolvedBundle(BundleRepository.java:389) >>>>> at com.id.core.platform.repository.BundleRepository.scanBundles(BundleRepository.java:269) >>>>> at com.id.core.platform.repository.BundleRepository.start(BundleRepository.java:118) >>>>> - locked <0x00000001259d7d20> (a java.lang.Object) >>>>> at com.id.core.platform.Platform.bootstrap(Platform.java:184) >>>>> - locked <0x00000001259d4000> (a java.lang.Object) >>>>> - locked <0x00000001259d3fe0> (a com.id.core.platform.Platform) >>>>> at com.id.core.platform.activator.Activator$1.run(Activator.java:77) >>>>> - locked <0x00000001259ce758> (a java.lang.Object) >>>>> >>>>> I've been looking in the source but not sure if those fixes are already in the jdk 1.7u forest. >>>>> >>>>> Erik Vanherck >>>>> >>>>> ________________________________ >>>>> >>>>> Inventive Designers' Email Disclaimer: >>>>> http://www.inventivedesigners.com/email-disclaimer >>>> >>>> >>> >>> ________________________________ >>> >>> Inventive Designers' Email Disclaimer: >>> http://www.inventivedesigners.com/email-disclaimer >> >> >> > > > ________________________________ > > Inventive Designers' Email Disclaimer: > http://www.inventivedesigners.com/email-disclaimer > From leonid.romanov at oracle.com Mon Jul 1 19:10:54 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 2 Jul 2013 06:10:54 +0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: <51CDC8A2.2060708@oracle.com> References: <48FF7D86-1A7C-4C99-BA97-B765CB02AE0C@gmail.com> <51CDC8A2.2060708@oracle.com> Message-ID: On Jun 28, 2013, at 9:32 PM, Artem Ananiev wrote: > > This is a bug in eAWT, which uses SwingUtilities.invokeLater(), but should use SunToolkit.postEvent(AppContext, AWTEvent) or similar. > What do you think about introducing a new API, like SwingUtilities.invokeLater(Runnable runnable, Component target) which would invoke the runnable using the target's AppContext? It might be useful both for AWT/Swing engineers and apps writers. Leonid. From artem.ananiev at oracle.com Tue Jul 2 02:42:17 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 02 Jul 2013 13:42:17 +0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: References: <48FF7D86-1A7C-4C99-BA97-B765CB02AE0C@gmail.com> <51CDC8A2.2060708@oracle.com> Message-ID: <51D2A079.3050909@oracle.com> Cross-posting to swing-dev and awt-dev. On 7/2/2013 6:10 AM, Leonid Romanov wrote: > > On Jun 28, 2013, at 9:32 PM, Artem Ananiev wrote: >> >> This is a bug in eAWT, which uses SwingUtilities.invokeLater(), but should use SunToolkit.postEvent(AppContext, AWTEvent) or similar. > > What do you think about introducing a new API, like SwingUtilities.invokeLater(Runnable runnable, Component target) which would invoke the runnable using the target's AppContext? It might be useful both for AWT/Swing engineers and apps writers. I don't think SwingUtilities/EventQueue is the right place for such API. It's useless for app developers, as application code should always be in the right AppContext, i.e. invokeLater(Runnable) should always post the runnable to the right place. Such API is useful, when your code is on a thread like the toolkit thread (AppKit thread on OS X). So a better place would be SunToolkit or SwingUtilities2, but SunToolkit already has a method named executeOnEventHandlerThread(). Thanks, Artem > Leonid. From ca at censhare.de Tue Jul 2 06:00:53 2013 From: ca at censhare.de (Christof Aenderl) Date: Tue, 2 Jul 2013 15:00:53 +0200 Subject: Crash in liblwawt.dylib on OS X 10.9 Message-ID: <7ACF7412-B58F-4614-AE50-AD45EDB350FB@censhare.de> Hi, concerning a fixed bug: http://bugs.sun.com/view_bug.do?bug_id=7152608 I found the same problem on the OS X 10.9 DP2 with Java 7_25: --------------------------------------------------------------- Process: JavaAppLauncher [2333] Path: /Users/USER/Documents/*/censhare Client.app/Contents/MacOS/JavaAppLauncher Identifier: com.censhare.javaclient Version: 4.7.8 (1.0) Code Type: X86-64 (Native) Parent Process: launchd [152] Responsible: JavaAppLauncher [2333] User ID: 501 Date/Time: 2013-07-01 22:22:18.259 +0200 OS Version: Mac OS X 10.9 (13A497d) Report Version: 11 Crashed Thread: 23 Java: Java2D Queue Flusher Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 VM Regions Near 0: --> __TEXT 00000001052e6000-00000001052e9000 [ 12K] r-x/rwx SM=COW /Users/USER/Documents/*/censhare Client.app/Contents/MacOS/JavaAppLauncher Application Specific Information: abort() called Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff8a0aba66 mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff8a0aad64 mach_msg + 64 2 com.apple.CoreFoundation 0x00007fff8e4ba6f5 __CFRunLoopServiceMachPort + 181 3 com.apple.CoreFoundation 0x00007fff8e4c0989 __CFRunLoopRun + 1497 4 com.apple.CoreFoundation 0x00007fff8e4bffc3 CFRunLoopRunSpecific + 467 5 com.apple.HIToolbox 0x00007fff86b0ab11 RunCurrentEventLoopInMode + 226 6 com.apple.HIToolbox 0x00007fff86b0a8b4 ReceiveNextEventCommon + 479 7 com.apple.HIToolbox 0x00007fff86c1e8e9 _BlockUntilNextEventMatchingListInModeWithFilter + 65 8 com.apple.AppKit 0x00007fff9156204e _DPSNextEvent + 1434 9 com.apple.AppKit 0x00007fff9156169b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122 10 libosxapp.dylib 0x000000012f38ab56 -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 11 com.apple.AppKit 0x00007fff9179376f -[NSApplication _realDoModalLoop:peek:] + 620 12 com.apple.AppKit 0x00007fff91793a4b -[NSApplication runModalForWindow:] + 117 13 com.apple.AppKit 0x00007fff9178479d -[NSAlert runModal] + 145 14 com.apple.AppKit 0x00007fff91d551d9 __55-[NSPersistentUIRestorer promptToIgnorePersistentState]_block_invoke + 1054 15 com.apple.AppKit 0x00007fff914c5778 -[NSApplication _suppressFinishLaunchingFromEventHandlersWhilePerformingBlock:] + 28 16 com.apple.AppKit 0x00007fff91d54d7f -[NSPersistentUIRestorer promptToIgnorePersistentState] + 213 17 com.apple.AppKit 0x00007fff914c5753 -[NSPersistentUIManager promptToIgnorePersistentState] + 28 18 com.apple.AppKit 0x00007fff91565f64 -[NSApplication _reopenWindowsAsNecessaryIncludingRestorableState:registeringAsReady:completionHandler:] + 252 19 com.apple.AppKit 0x00007fff91565d39 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 557 20 com.apple.AppKit 0x00007fff9156585b -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 242 21 com.apple.Foundation 0x00007fff87aa709a -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 294 22 com.apple.Foundation 0x00007fff87aa6f0d _NSAppleEventManagerGenericHandler + 106 23 com.apple.AE 0x00007fff896a9b7f aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 381 24 com.apple.AE 0x00007fff896a9992 dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 31 25 com.apple.AE 0x00007fff896a9856 aeProcessAppleEvent + 315 26 com.apple.HIToolbox 0x00007fff86b1420e AEProcessAppleEvent + 56 27 com.apple.AppKit 0x00007fff91561eb6 _DPSNextEvent + 1026 28 com.apple.AppKit 0x00007fff9156169b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122 29 libosxapp.dylib 0x000000012f38ab56 -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 30 com.apple.AppKit 0x00007fff915598ec -[NSApplication run] + 553 31 libosxapp.dylib 0x000000012f38a9b9 +[NSApplicationAWT runAWTLoopWithApp:] + 156 32 libsplashscreen.dylib 0x000000012f341996 __SplashInitPlatform_block_invoke_1 + 86 33 libdispatch.dylib 0x00007fff93ed86d0 _dispatch_call_block_and_release + 12 34 libdispatch.dylib 0x00007fff93ed5984 _dispatch_client_callout + 8 35 libdispatch.dylib 0x00007fff93ed96a1 _dispatch_main_queue_callback_4CF + 333 36 com.apple.CoreFoundation 0x00007fff8e5884a9 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 37 com.apple.CoreFoundation 0x00007fff8e4c0ae4 __CFRunLoopRun + 1844 38 com.apple.CoreFoundation 0x00007fff8e4bffc3 CFRunLoopRunSpecific + 467 39 libjli.dylib 0x000000010535f88d CreateExecutionEnvironment + 871 40 libjli.dylib 0x000000010535a03c JLI_Launch + 1952 41 com.censhare.javaclient 0x00000001052e8948 launch + 4776 42 com.censhare.javaclient 0x00000001052e7556 main + 102 43 com.censhare.javaclient 0x00000001052e74e4 start + 52 Thread 1:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x00007fff8a0b0692 kevent64 + 10 1 libdispatch.dylib 0x00007fff93ed7ac1 _dispatch_mgr_invoke + 239 2 libdispatch.dylib 0x00007fff93ed79c2 _dispatch_mgr_thread + 52 Thread 2: 0 libsystem_kernel.dylib 0x00007fff8a0afa6a __semwait_signal + 10 1 libsystem_pthread.dylib 0x00007fff8a564830 pthread_join + 430 2 libjli.dylib 0x000000010535ee8d ContinueInNewThread0 + 102 3 libjli.dylib 0x000000010535aca7 ContinueInNewThread + 201 4 libjli.dylib 0x000000010535ebf0 JVMInit + 251 5 libjli.dylib 0x000000010535aa25 JLI_Launch + 4489 6 com.censhare.javaclient 0x00000001052e8948 launch + 4776 7 com.censhare.javaclient 0x00000001052e7556 main + 102 8 libjli.dylib 0x000000010535f51f apple_main + 92 9 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 10 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 11 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 3: 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 3 libjvm.dylib 0x00000001057fa109 ObjectMonitor::wait(long long, bool, Thread*) + 627 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 6 ??? 0x0000000106056f90 0 + 4395986832 7 ??? 0x000000010604b158 0 + 4395938136 8 ??? 0x000000010604b158 0 + 4395938136 9 ??? 0x000000010604b158 0 + 4395938136 10 ??? 0x000000010604b158 0 + 4395938136 11 ??? 0x000000010604b158 0 + 4395938136 12 ??? 0x000000010604b333 0 + 4395938611 13 ??? 0x000000010604b158 0 + 4395938136 14 ??? 0x000000010604b158 0 + 4395938136 15 ??? 0x00000001060454f7 0 + 4395914487 16 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 17 libjvm.dylib 0x00000001056d4390 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 18 libjvm.dylib 0x0000000105843c06 Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 2514 19 libjvm.dylib 0x0000000105843ed9 Reflection::invoke_constructor(oopDesc*, objArrayHandle, Thread*) + 417 20 libjvm.dylib 0x0000000105708b0e JVM_NewInstanceFromConstructor + 124 21 ??? 0x0000000106056f90 0 + 4395986832 22 ??? 0x000000010604b333 0 + 4395938611 23 ??? 0x000000010604b333 0 + 4395938611 24 ??? 0x000000010604b9e1 0 + 4395940321 25 ??? 0x000000010604b333 0 + 4395938611 26 ??? 0x000000010604b333 0 + 4395938611 27 ??? 0x000000010604b333 0 + 4395938611 28 ??? 0x000000010604b333 0 + 4395938611 29 ??? 0x000000010604b333 0 + 4395938611 30 ??? 0x000000010604b333 0 + 4395938611 31 ??? 0x000000010604b333 0 + 4395938611 32 ??? 0x000000010604b158 0 + 4395938136 33 ??? 0x00000001060454f7 0 + 4395914487 34 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 35 libjvm.dylib 0x00000001056d4390 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 36 libjvm.dylib 0x000000010570fa8f JVM_DoPrivileged + 1037 37 ??? 0x0000000106056f90 0 + 4395986832 38 ??? 0x000000010604b333 0 + 4395938611 39 ??? 0x000000010604b158 0 + 4395938136 40 ??? 0x000000010604b158 0 + 4395938136 41 ??? 0x000000010604b158 0 + 4395938136 42 ??? 0x000000010604b158 0 + 4395938136 43 ??? 0x00000001060454f7 0 + 4395914487 44 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 45 libjvm.dylib 0x00000001056d4390 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 46 libjvm.dylib 0x00000001056efe70 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 219 47 libjvm.dylib 0x00000001056e91c8 jni_CallStaticVoidMethod + 267 48 libjli.dylib 0x000000010535b5de JavaMain + 2333 49 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 50 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 51 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 4: 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 2 libjvm.dylib 0x0000000105800af7 os::PlatformEvent::park(long long) + 385 3 libjvm.dylib 0x00000001057e3402 Monitor::IWait(Thread*, long long) + 160 4 libjvm.dylib 0x00000001057e365f Monitor::wait(bool, long, bool) + 375 5 libjvm.dylib 0x00000001058f7b00 VMThread::loop() + 444 6 libjvm.dylib 0x00000001058f761b VMThread::run() + 121 7 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 8 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 9 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 10 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 5:: Java: Reference Handler 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 3 libjvm.dylib 0x00000001057fa109 ObjectMonitor::wait(long long, bool, Thread*) + 627 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 6 ??? 0x0000000106056f90 0 + 4395986832 7 ??? 0x000000010604b158 0 + 4395938136 8 ??? 0x000000010604b158 0 + 4395938136 9 ??? 0x00000001060454f7 0 + 4395914487 10 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 11 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 12 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 13 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 14 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 15 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 16 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 17 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 18 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 19 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 6:: Java: Finalizer 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 3 libjvm.dylib 0x00000001057fa109 ObjectMonitor::wait(long long, bool, Thread*) + 627 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 6 ??? 0x0000000106056f90 0 + 4395986832 7 ??? 0x000000010604b158 0 + 4395938136 8 ??? 0x000000010604b333 0 + 4395938611 9 ??? 0x000000010604b333 0 + 4395938611 10 ??? 0x00000001060454f7 0 + 4395914487 11 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 12 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 13 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 14 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 15 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 16 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 17 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 19 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 7: 0 libsystem_kernel.dylib 0x00007fff8a0afe9a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff8a561f4e _pthread_wqthread + 324 2 libsystem_pthread.dylib 0x00007fff8a564fd9 start_wqthread + 13 Thread 8: 0 libsystem_kernel.dylib 0x00007fff8a0afe9a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff8a561f4e _pthread_wqthread + 324 2 libsystem_pthread.dylib 0x00007fff8a564fd9 start_wqthread + 13 Thread 9:: Java: Signal Dispatcher 0 libsystem_kernel.dylib 0x00007fff8a0abaa2 semaphore_wait_trap + 10 1 libjvm.dylib 0x0000000105801e57 check_pending_signals(bool) + 128 2 libjvm.dylib 0x00000001057fe994 signal_thread_entry(JavaThread*, Thread*) + 57 3 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 4 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 5 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 6 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 7 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 8 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 10:: Java: C2 CompilerThread0 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 3 libjvm.dylib 0x00000001057e2c10 ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x00000001057e3402 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x00000001057e35c6 Monitor::wait(bool, long, bool) + 222 6 libjvm.dylib 0x00000001055d2281 CompileQueue::get() + 153 7 libjvm.dylib 0x00000001055d2da2 CompileBroker::compiler_thread_loop() + 410 8 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 9 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 10 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 11 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 12 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 13 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 11:: Java: C2 CompilerThread1 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 3 libjvm.dylib 0x00000001057e2c10 ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x00000001057e3402 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x00000001057e35c6 Monitor::wait(bool, long, bool) + 222 6 libjvm.dylib 0x00000001055d2281 CompileQueue::get() + 153 7 libjvm.dylib 0x00000001055d2da2 CompileBroker::compiler_thread_loop() + 410 8 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 9 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 10 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 11 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 12 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 13 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 12:: Java: Service Thread 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 3 libjvm.dylib 0x00000001057e2c10 ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x00000001057e3402 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x00000001057e365f Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x0000000105852249 ServiceThread::service_thread_entry(JavaThread*, Thread*) + 109 7 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 8 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 9 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 10 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 11 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 12 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 13: 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 2 libjvm.dylib 0x0000000105800af7 os::PlatformEvent::park(long long) + 385 3 libjvm.dylib 0x00000001058c7d06 WatcherThread::run() + 328 4 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 5 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 6 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 7 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 14: 0 libsystem_kernel.dylib 0x00007fff8a0b09aa poll + 10 1 libsplashscreen.dylib 0x000000012f34281c SplashEventLoop + 220 2 libsplashscreen.dylib 0x000000012f342b9e SplashScreenThread + 574 3 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 4 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 5 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 15: 0 libsystem_kernel.dylib 0x00007fff8a0afe9a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff8a561f4e _pthread_wqthread + 324 2 libsystem_pthread.dylib 0x00007fff8a564fd9 start_wqthread + 13 Thread 16: 0 libsystem_kernel.dylib 0x00007fff8a0afe9a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff8a561f4e _pthread_wqthread + 324 2 libsystem_pthread.dylib 0x00007fff8a564fd9 start_wqthread + 13 Thread 17: 0 libsystem_kernel.dylib 0x00007fff8a0afe9a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff8a561f4e _pthread_wqthread + 324 2 libsystem_pthread.dylib 0x00007fff8a564fd9 start_wqthread + 13 Thread 18:: Java: ActiveActionsRegistryThread 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 2 libjvm.dylib 0x0000000105800af7 os::PlatformEvent::park(long long) + 385 3 libjvm.dylib 0x00000001057fa113 ObjectMonitor::wait(long long, bool, Thread*) + 637 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 6 ??? 0x0000000106056f90 0 + 4395986832 7 ??? 0x000000010604b158 0 + 4395938136 8 ??? 0x000000010604b158 0 + 4395938136 9 ??? 0x000000010604b806 0 + 4395939846 10 ??? 0x00000001060454f7 0 + 4395914487 11 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 12 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 13 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 14 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 15 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 16 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 17 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 19 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 19:: Java: TaskScheduler-no-EDT 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 3 libjvm.dylib 0x00000001057fa109 ObjectMonitor::wait(long long, bool, Thread*) + 627 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 6 ??? 0x0000000106056f90 0 + 4395986832 7 ??? 0x000000010604b158 0 + 4395938136 8 ??? 0x000000010604b158 0 + 4395938136 9 ??? 0x000000010604b158 0 + 4395938136 10 ??? 0x00000001060454f7 0 + 4395914487 11 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 12 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 13 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 14 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 15 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 16 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 17 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 19 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 20:: com.apple.appkit-heartbeat 0 com.apple.AppKit 0x00007fff915321d5 -[NSView(NSPrivateHLTBSupport) _boundToHIView] + 17 1 com.apple.AppKit 0x00007fff91532144 -[NSView visibleRect] + 227 2 com.apple.AppKit 0x00007fff91752df9 -[NSWindow(NSWindow_Theme) heartBeat:] + 236 3 com.apple.AppKit 0x00007fff9172cfad -[NSUIHeartBeat _heartBeatThread:] + 868 4 com.apple.Foundation 0x00007fff87ad6fcc __NSThread__main__ + 1318 5 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 6 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 7 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 21:: Java: AWT-Shutdown 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 3 libjvm.dylib 0x00000001057fa109 ObjectMonitor::wait(long long, bool, Thread*) + 627 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 6 ??? 0x0000000106056f90 0 + 4395986832 7 ??? 0x000000010604b158 0 + 4395938136 8 ??? 0x000000010604b158 0 + 4395938136 9 ??? 0x000000010604b806 0 + 4395939846 10 ??? 0x00000001060454f7 0 + 4395914487 11 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 12 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 13 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 14 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 15 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 16 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 17 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 19 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 22:: Java: Image Fetcher 0 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 2 libjvm.dylib 0x0000000105800af7 os::PlatformEvent::park(long long) + 385 3 libjvm.dylib 0x00000001057fa113 ObjectMonitor::wait(long long, bool, Thread*) + 637 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 6 ??? 0x0000000106056f90 0 + 4395986832 7 ??? 0x000000010604b158 0 + 4395938136 8 ??? 0x000000010604b333 0 + 4395938611 9 ??? 0x000000010604b158 0 + 4395938136 10 ??? 0x00000001060454f7 0 + 4395914487 11 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 12 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 13 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 14 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 15 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 16 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 17 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 19 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 23 Crashed:: Java: Java2D Queue Flusher 0 libsystem_kernel.dylib 0x00007fff8a0af896 __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff8a5613c5 pthread_kill + 92 2 libsystem_c.dylib 0x00007fff8ea61c22 abort + 125 3 libjvm.dylib 0x00000001058030d7 os::abort(bool) + 25 4 libjvm.dylib 0x00000001058f2020 VMError::report_and_die() + 2306 5 libjvm.dylib 0x00000001058047cb JVM_handle_bsd_signal + 1073 6 libsystem_platform.dylib 0x00007fff8a20d80a _sigtramp + 26 7 libGL.dylib 0x00007fff93983fc8 glGetString + 15 8 liblwawt.dylib 0x000000013391a69f Java_sun_java2d_opengl_OGLContext_getOGLIdString + 35 9 ??? 0x0000000106056f90 0 + 4395986832 10 ??? 0x000000010604b333 0 + 4395938611 11 ??? 0x000000010604b806 0 + 4395939846 12 ??? 0x00000001060454f7 0 + 4395914487 13 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 14 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 15 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 16 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 17 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 18 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 19 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 20 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 21 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 22 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 Thread 23 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x0000000134733000 rcx: 0x0000000134732088 rdx: 0x0000000000000000 rdi: 0x0000000000008d07 rsi: 0x0000000000000006 rbp: 0x00000001347320b0 rsp: 0x0000000134732088 r8: 0x0000000000000040 r9: 0x0000000134732000 r10: 0x0000000008000000 r11: 0x0000000000000206 r12: 0x0000000105b961f0 r13: 0x0000000129997498 r14: 0x0000000000000006 r15: 0x00000001058066bc rip: 0x00007fff8a0af896 rfl: 0x0000000000000206 cr2: 0x000000010592a000 Logical CPU: 0 Error Code: 0x02000148 Trap Number: 133 Binary Images: 0x1052e6000 - 0x1052e8ff7 +com.censhare.javaclient (4.7.8pre - 1.0) <5A002039-2B05-362A-BD4C-37CA0CD6B136> /Users/USER/Documents/*/censhare Client.app/Contents/MacOS/JavaAppLauncher 0x105358000 - 0x105362fff +libjli.dylib (1) <9792ED7A-1BD0-3D84-B551-F5DA12537016> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/jli/libjli.dylib 0x10544a000 - 0x105ad5fef +libjvm.dylib (1) <1B03A29F-0248-337E-8529-87706B48A7DE> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/server/libjvm.dylib 0x105ff6000 - 0x105ffefff +libverify.dylib (1) /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libverify.dylib 0x106003000 - 0x106024fef +libjava.dylib (1) /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libjava.dylib 0x10603c000 - 0x106041fff +libzip.dylib (1) <89DD8E8C-F4A4-3E92-A2D6-CC8642447AC3> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libzip.dylib 0x12eb60000 - 0x12eb69ff7 com.apple.java.JavaRuntimeSupport (14.8.0 - 14.8.0) /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/JavaRuntimeSupport 0x12eb78000 - 0x12eb82fff JavaNativeFoundation (1) /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation 0x12eb8d000 - 0x12eb92fff com.apple.JavaVM (14.8.0 - 14.8.0) <83C8C2AB-E99D-39FF-80B4-90A7DEB1DAFB> /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM 0x12eb9a000 - 0x12eb9ffff JavaLaunching (1) /System/Library/PrivateFrameworks/JavaLaunching.framework/Versions/A/JavaLaunching 0x12f33a000 - 0x12f379fff +libsplashscreen.dylib (1) /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libsplashscreen.dylib 0x12f389000 - 0x12f38ffff +libosxapp.dylib (1) <19D025A3-9368-319D-AA64-EF835D78A0FF> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libosxapp.dylib 0x12f3a5000 - 0x12f3a7fff com.apple.ExceptionHandling (1.5 - 10) /System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ExceptionHandling 0x131880000 - 0x131888ffb libCGCMS.A.dylib (565) <978DCDAA-A34D-3223-A362-9A51E3697D93> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGCMS.A.dylib 0x1319b8000 - 0x1319e1ffb libRIP.A.dylib (565) <7A4FA177-8BCD-3A95-A577-57B079C8C9D2> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib 0x131cd2000 - 0x131cd5ffa libCGXType.A.dylib (565) <6EF5CFC1-05F8-3E78-86D5-AD5659D92642> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib 0x13379a000 - 0x133806ff7 +libawt.dylib (1) <614FC193-CE14-3B85-9F8B-33F92FBD6D92> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libawt.dylib 0x13384a000 - 0x13390ffff +libmlib_image.dylib (1) <95F6D0B2-3A92-305F-A6AE-822BC990901B> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libmlib_image.dylib 0x133916000 - 0x133986ff7 +liblwawt.dylib (1) <8004F9F2-4EDF-3FF4-8B40-12F06C5C97FA> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/lwawt/liblwawt.dylib 0x1341cd000 - 0x13420efff +libfontmanager.dylib (1) <63A05734-9483-3B12-BAB0-E1EB020C1A32> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libfontmanager.dylib 0x1344b5000 - 0x1344b9fff +libosxui.dylib (1) <56D2A1A1-1532-3AF5-98CC-0A3BE7B986B7> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libosxui.dylib 0x1344be000 - 0x1344c6fff +libnio.dylib (1) <4E9F4A0E-BC84-31E8-AB60-3F9F37B08B00> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libnio.dylib 0x1344cd000 - 0x1344dbff7 +libnet.dylib (1) <6A30865D-EBB7-3D91-921C-7A3E0416E481> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libnet.dylib 0x134735000 - 0x1348c5fff GLEngine (9.0.74) <1D7D765E-402A-36E3-A879-0E2A0E406293> /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine 0x1348fd000 - 0x134926fff GLRendererFloat (9.0.74) <37D2C111-A7C9-3657-96D2-586C0BFE1EAB> /System/Library/Frameworks/OpenGL.framework/Resources/GLRendererFloat.bundle/GLRendererFloat 0x13492f000 - 0x134938ff7 libcldcpuengine.dylib (2.3.49) <7C0F237D-4818-3101-86C3-9B05243FC173> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libcldcpuengine.dylib 0x7fff6f401000 - 0x7fff6f4344a7 dyld (237) /usr/lib/dyld 0x7fff86aa2000 - 0x7fff86aa2ffd com.apple.audio.units.AudioUnit (1.9 - 1.9) /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit 0x7fff86aae000 - 0x7fff86d56ff9 com.apple.HIToolbox (2.1 - 681) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x7fff86d59000 - 0x7fff86da6fff com.apple.opencl (2.3.50 - 2.3.50) <33C1EC76-02A2-3474-BB9D-8F77B96E57CC> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 0x7fff86da7000 - 0x7fff86e89ff7 com.apple.backup.framework (1.5 - 1.5) <70E20485-EDB6-3225-8AF6-6D9494CB98B7> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup 0x7fff86e8a000 - 0x7fff86e8dff7 com.apple.help (1.3.3 - 46) <4FF8A8E2-33C2-30DF-86CE-A7ADA9F56A3F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x7fff86eb2000 - 0x7fff86ecefff libresolv.9.dylib (54) <78D891A1-6F8B-34D4-8F0D-59DB6DF53411> /usr/lib/libresolv.9.dylib 0x7fff86ecf000 - 0x7fff86f0efff libGLU.dylib (9.0.74) <294F4F86-E900-356C-9A47-0C47A929F2FB> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x7fff872a7000 - 0x7fff872dbfff libssl.0.9.8.dylib (50) <1A09EC98-23CF-39F1-9C99-38A47ED7184E> /usr/lib/libssl.0.9.8.dylib 0x7fff873c4000 - 0x7fff873c5ff7 libsystem_blocks.dylib (63) <7836104E-39B9-31B6-A0C7-C02ACD401ADE> /usr/lib/system/libsystem_blocks.dylib 0x7fff873c6000 - 0x7fff873deff7 com.apple.GenerationalStorage (2.0 - 158) <5BCFBEED-09D2-3BD3-8EE0-85E809C47380> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage 0x7fff873df000 - 0x7fff874cafff libsqlite3.dylib (155) /usr/lib/libsqlite3.dylib 0x7fff874cb000 - 0x7fff878acffe libLAPACK.dylib (1094.4) <19E25957-74BA-3770-AAB5-B6A05F19BDC2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x7fff878ad000 - 0x7fff87a49fff com.apple.QuartzCore (1.8 - 329.0) <08CE1885-71E8-3A38-AEB6-4BBB1A43785F> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x7fff87a4a000 - 0x7fff87d49ff7 com.apple.Foundation (6.9 - 1042) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff87d84000 - 0x7fff87dd6fff libc++.1.dylib (118) <5FF54631-AC11-3AD8-B42D-04FAC953CCED> /usr/lib/libc++.1.dylib 0x7fff87dd7000 - 0x7fff87e56fff com.apple.CoreSymbolication (3.0 - 137) <85C4F6E2-5039-3E53-9AB2-6D65CAC9AAC5> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication 0x7fff87e57000 - 0x7fff87e69fff com.apple.ImageCapture (9.0 - 9.0) <9613F27D-A905-35BF-A23F-C69CD5337035> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x7fff87e6a000 - 0x7fff87e71ffb liblaunch.dylib (842.1.1) <7055DF9E-52CE-3746-96EB-3718DDBF0BD0> /usr/lib/system/liblaunch.dylib 0x7fff87ec5000 - 0x7fff87f50fff libCoreStorage.dylib (377) /usr/lib/libCoreStorage.dylib 0x7fff87f51000 - 0x7fff8823bff7 com.apple.CoreServices.CarbonCore (1077.6 - 1077.6) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x7fff8837a000 - 0x7fff88381fff com.apple.NetFS (6.0 - 4.0) <553EA9F4-7B2C-371A-AF03-4B709A730582> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x7fff88382000 - 0x7fff883c6ffe com.apple.HIServices (1.22 - 454) <3625AF2C-1965-349D-B831-1FCC9084B675> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x7fff883c7000 - 0x7fff883c8ffb libremovefile.dylib (33) /usr/lib/system/libremovefile.dylib 0x7fff883c9000 - 0x7fff883f0ff3 libsystem_info.dylib (449) /usr/lib/system/libsystem_info.dylib 0x7fff883f1000 - 0x7fff88432ff7 com.apple.PerformanceAnalysis (1.45 - 45) <6C498B15-45DB-362F-983B-764ECC9B8E21> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis 0x7fff88433000 - 0x7fff884a2ff1 com.apple.ApplicationServices.ATS (360 - 360) <8A3AD47D-2777-3019-80BB-4B17AA055E13> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x7fff884a3000 - 0x7fff8856bff7 libvDSP.dylib (423.29) <72A38066-D6F5-38EC-A8B9-0D025AFC6E2B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x7fff89149000 - 0x7fff89181ff7 com.apple.RemoteViewServices (2.0 - 94) <7E7B5F1F-9F0E-3DF7-B6B9-152DFD2DFFC7> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices 0x7fff893d1000 - 0x7fff893d4fff com.apple.TCC (1.0 - 1) <1DF1D216-1355-3E4F-B4BE-3E3BA5A696EB> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC 0x7fff89407000 - 0x7fff89430fff com.apple.DictionaryServices (1.2 - 197) <862F498E-3CB7-3087-BB07-AC185D5D08F8> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x7fff8946b000 - 0x7fff89492ff7 libsystem_network.dylib (241.3) /usr/lib/system/libsystem_network.dylib 0x7fff89493000 - 0x7fff894fdff7 com.apple.framework.IOKit (2.0.1 - 907.1.5) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x7fff89505000 - 0x7fff89529fff libJPEG.dylib (1029) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x7fff8952a000 - 0x7fff89534fff libcommonCrypto.dylib (60049) /usr/lib/system/libcommonCrypto.dylib 0x7fff89535000 - 0x7fff89566fff com.apple.MediaKit (15 - 709) /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit 0x7fff89669000 - 0x7fff89684ff7 libCRFSuite.dylib (34) /usr/lib/libCRFSuite.dylib 0x7fff896a3000 - 0x7fff896fdff8 com.apple.AE (665.2 - 665.2) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x7fff89b72000 - 0x7fff89b72ff7 libkeymgr.dylib (28) /usr/lib/system/libkeymgr.dylib 0x7fff89b8d000 - 0x7fff89bbcfff com.apple.DebugSymbols (106 - 106) <545E5A48-3516-3398-A33D-D6FB4FED4B7B> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols 0x7fff89bc0000 - 0x7fff89c23ff3 com.apple.SystemConfiguration (1.13 - 1.13) <73B50935-DFE8-31B8-8583-27A28B5A9D1E> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x7fff89c2b000 - 0x7fff89c2bfff com.apple.CoreServices (59 - 59) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x7fff89c8b000 - 0x7fff89cb0ffb com.apple.CoreVideo (1.8 - 117.0) <50587BF1-D111-3D49-9DAB-8F86B5E95808> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x7fff89cfe000 - 0x7fff89e54ff3 com.apple.audio.toolbox.AudioToolbox (1.9 - 1.9) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 0x7fff89e9e000 - 0x7fff89f11ffb com.apple.securityfoundation (6.0 - 55122) /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation 0x7fff89fa0000 - 0x7fff89fa1fff libunc.dylib (28) <53C7CED6-55F5-3121-B00E-4339C29297C8> /usr/lib/system/libunc.dylib 0x7fff89fa2000 - 0x7fff89fa6fff com.apple.CommonPanels (1.2.6 - 96) <3E07F8FE-B061-318D-A00F-E7D993DEF4FB> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x7fff89fb3000 - 0x7fff8a09afff libxml2.2.dylib (25) /usr/lib/libxml2.2.dylib 0x7fff8a09b000 - 0x7fff8a0b6ff7 libsystem_kernel.dylib (2422.1.26.0.1) <5F99677C-C760-3877-AFF7-F60B5ECE365E> /usr/lib/system/libsystem_kernel.dylib 0x7fff8a0b7000 - 0x7fff8a0c1ff7 libcsfde.dylib (377) /usr/lib/libcsfde.dylib 0x7fff8a0c2000 - 0x7fff8a0c6ff7 libheimdal-asn1.dylib (323.3) <90100758-0CC6-3D00-90AB-D3C7DC8CCE45> /usr/lib/libheimdal-asn1.dylib 0x7fff8a12a000 - 0x7fff8a209fff libcrypto.0.9.8.dylib (50) <9B1D3623-4A41-3A5B-88C7-1927AF7E2532> /usr/lib/libcrypto.0.9.8.dylib 0x7fff8a20a000 - 0x7fff8a210fef libsystem_platform.dylib (24) <5D8FE8C3-2A62-3705-AB7D-FBD7C284AFBD> /usr/lib/system/libsystem_platform.dylib 0x7fff8a211000 - 0x7fff8a4e0fdf com.apple.vImage (7.0 - 7.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x7fff8a55f000 - 0x7fff8a566ff7 libsystem_pthread.dylib (53) <2160EC74-26FC-32CE-8161-B1A72D2B09B0> /usr/lib/system/libsystem_pthread.dylib 0x7fff8a5a9000 - 0x7fff8a616fff com.apple.SearchKit (1.4.0 - 1.4.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x7fff8a64c000 - 0x7fff8a65bff8 com.apple.LangAnalysis (1.7.0 - 1.7.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x7fff8a91a000 - 0x7fff8a930fff com.apple.CFOpenDirectory (10.9 - 171) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory 0x7fff8a9ba000 - 0x7fff8aa46ff7 com.apple.ink.framework (10.9 - 205) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x7fff8aa47000 - 0x7fff8b34d043 com.apple.CoreGraphics (1.600.0 - 565) <81F84822-675E-3466-97A7-6FF69DF569E3> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x7fff8b485000 - 0x7fff8b49ffff libsystem_malloc.dylib (23.1.1) /usr/lib/system/libsystem_malloc.dylib 0x7fff8b4a0000 - 0x7fff8b4a0fff com.apple.Accelerate (1.9 - Accelerate 1.9) <94C28250-6BDB-30AD-B157-995D9C34A6FA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x7fff8b4a3000 - 0x7fff8b4a5fff libCVMSPluginSupport.dylib (9.0.74) <11FCA581-0FFD-37B1-966A-E47F4722D297> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib 0x7fff8b4b7000 - 0x7fff8b4c5ff7 com.apple.opengl (9.0.74 - 9.0.74) <9BD0013A-E503-3DA2-9F94-C42A11D2E734> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x7fff8b538000 - 0x7fff8b5f0ff7 com.apple.DiscRecording (8.0 - 8000.4.6) <62C23719-2144-3137-87DF-0858239A08BE> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording 0x7fff8ba7a000 - 0x7fff8bb29ff7 libvMisc.dylib (423.29) <83CBEBB6-B9C2-3D83-A32A-CED47CDB65D6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x7fff8bb2a000 - 0x7fff8bb36fff com.apple.OpenDirectory (10.9 - 171) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 0x7fff8bb37000 - 0x7fff8bb3cfff com.apple.DiskArbitration (2.6 - 2.6) <4D7487BB-C4A7-32DB-BEE2-CE55EA7F40B2> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x7fff8bb3d000 - 0x7fff8bbffff9 com.apple.CoreText (352.0 - 367.6) /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText 0x7fff8bdae000 - 0x7fff8bdbbfff com.apple.Sharing (112 - 112) <24BA2112-4FFB-318A-B881-93FEB4648371> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing 0x7fff8bde7000 - 0x7fff8bdebfff libpam.2.dylib (20) <17E3DA0D-EE71-3398-BA30-BDD8514A6135> /usr/lib/libpam.2.dylib 0x7fff8bdec000 - 0x7fff8bedbfff libFontParser.dylib (106) <16B9215D-3244-365F-910F-FA033495E3F5> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib 0x7fff8bedc000 - 0x7fff8bef5ff3 com.apple.Ubiquity (1.3 - 280) <581DAEFC-B314-3F92-93CF-7B70BF22AEEF> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity 0x7fff8bf41000 - 0x7fff8bf76ffc com.apple.LDAPFramework (2.4.28 - 194.5) <44544698-E9CA-3440-808A-FF5417E55538> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP 0x7fff8bf77000 - 0x7fff8bf79ffb libutil.dylib (34) <9A9338CF-FD16-3D8F-8564-0797A4DAFC5F> /usr/lib/libutil.dylib 0x7fff8c1f5000 - 0x7fff8c1f5fff com.apple.Cocoa (6.8 - 20) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 0x7fff8c1f6000 - 0x7fff8c1f9fff libCoreVMClient.dylib (58.1) <331C429A-3AE5-30B8-A4DE-1BF4EE4D8FA6> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib 0x7fff8c224000 - 0x7fff8c227ffc com.apple.IOSurface (91 - 91) <1B7746FC-3599-3BDB-A0DA-65795C999435> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface 0x7fff8c26d000 - 0x7fff8c4aafff com.apple.CoreData (107 - 468) <51F9B655-84D2-3E88-991B-914C9017BB08> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData 0x7fff8c4ab000 - 0x7fff8c4b5ff7 com.apple.bsd.ServiceManagement (2.0 - 2.0) <3E92DCA9-DA23-34E1-8C38-DA7488621FFB> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement 0x7fff8c51a000 - 0x7fff8c51bff7 libsystem_sandbox.dylib (278.1) /usr/lib/system/libsystem_sandbox.dylib 0x7fff8c9d3000 - 0x7fff8ca0cff7 com.apple.QD (3.49 - 297) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x7fff8ca0d000 - 0x7fff8ca36ff7 libc++abi.dylib (43) /usr/lib/libc++abi.dylib 0x7fff8ca78000 - 0x7fff8cac8ffa com.apple.audio.CoreAudio (4.2.0 - 4.2.0) <548AC059-62DD-3CF6-B083-CABE454AFA38> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x7fff8d929000 - 0x7fff8d92aff7 libDiagnosticMessagesClient.dylib (100) /usr/lib/libDiagnosticMessagesClient.dylib 0x7fff8dde9000 - 0x7fff8decbfff com.apple.coreui (2.1 - 224) <9F8C1983-1795-34DA-A0C1-7F126ECA0D8E> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI 0x7fff8decf000 - 0x7fff8ded2ff7 libdyld.dylib (237) /usr/lib/system/libdyld.dylib 0x7fff8ded3000 - 0x7fff8e039fff libGLProgrammability.dylib (9.0.74) <07E259BB-1EDA-3EBE-9CDB-8DB09DE5D509> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib 0x7fff8e0af000 - 0x7fff8e0e9ffb com.apple.bom (12.0 - 192) /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom 0x7fff8e0ea000 - 0x7fff8e175fff com.apple.Metadata (10.7.0 - 778.1) <93F05A4E-6581-3CD5-8697-84783CEBF764> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x7fff8e176000 - 0x7fff8e199fff com.apple.IconServices (25 - 25.4) <525BAAE5-F45C-3A15-ACED-2AF4EFFED546> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices 0x7fff8e319000 - 0x7fff8e31aff7 com.apple.print.framework.Print (9.0 - 260) <264DAE2A-7FD5-36B4-A737-F521E62AE687> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x7fff8e31b000 - 0x7fff8e484ff3 com.apple.CFNetwork (657 - 657) <59A9476F-19A2-3F8B-A9B0-8531EA36A4AE> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x7fff8e48a000 - 0x7fff8e491fff libcompiler_rt.dylib (35) /usr/lib/system/libcompiler_rt.dylib 0x7fff8e492000 - 0x7fff8e675ff7 com.apple.CoreFoundation (6.9 - 842) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff8e6f1000 - 0x7fff8e6f2fff com.apple.TrustEvaluationAgent (2.0 - 25) <644D981B-A5A7-31F5-99A6-9F180B9A5DE3> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0x7fff8e6f3000 - 0x7fff8e705ff7 com.apple.MultitouchSupport.framework (245.12 - 245.12) <06CAA8FB-BEC6-3EF1-96FA-3D8A1EEB0959> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport 0x7fff8e706000 - 0x7fff8e76aff6 com.apple.Heimdal (4.0 - 2.0) <463F41AC-39FF-30FC-B03A-4198E7A9321F> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal 0x7fff8e76b000 - 0x7fff8e79afd2 libsystem_m.dylib (3047.15) <8A6B4EC2-BB25-342B-B3FE-9585175225B8> /usr/lib/system/libsystem_m.dylib 0x7fff8e800000 - 0x7fff8e809ff7 com.apple.speech.synthesis.framework (4.5.3 - 4.5.3) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x7fff8e80a000 - 0x7fff8e815ff7 com.apple.NetAuth (5.0 - 5.0) <64D42204-C075-3440-8C29-BBD68A99A771> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth 0x7fff8e9bf000 - 0x7fff8e9c1fff com.apple.EFILogin (2.0 - 2) <2A4E94B1-F1A5-36A5-989E-013D646E1CE3> /System/Library/PrivateFrameworks/EFILogin.framework/Versions/A/EFILogin 0x7fff8e9c2000 - 0x7fff8ea04ff7 libauto.dylib (185.4) <379FBDA3-DB2A-35A3-A637-3893C0F0E52F> /usr/lib/libauto.dylib 0x7fff8ea05000 - 0x7fff8ea8efe7 libsystem_c.dylib (997) <5BAB0B09-A39E-39B9-9552-48B540B3ABD0> /usr/lib/system/libsystem_c.dylib 0x7fff8ea8f000 - 0x7fff8ea99ff7 com.apple.CrashReporterSupport (10.9 - 529) /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport 0x7fff8ea9a000 - 0x7fff8ea9affd libOpenScriptingUtil.dylib (154) <9B8CECA0-360D-3C6D-A37D-95EE34AE2B16> /usr/lib/libOpenScriptingUtil.dylib 0x7fff8ee6d000 - 0x7fff8f2a0ff7 com.apple.vision.FaceCore (3.0.0 - 3.0.0) <14255DCC-80BD-3690-9269-057D175A9FC5> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore 0x7fff8f2a1000 - 0x7fff8f2a9ffc libGFXShared.dylib (9.0.74) <13A420C1-1B14-36F8-8F08-4698D423E52F> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib 0x7fff8f34f000 - 0x7fff8f454fff com.apple.ImageIO.framework (3.2.0 - 1029) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x7fff8fba5000 - 0x7fff8fe75ff4 com.apple.CoreImage (9.0.33) <8BB17AEC-D09A-3173-8767-7DB5C982670E> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage 0x7fff9011b000 - 0x7fff90162ff3 libFontRegistry.dylib (121.1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib 0x7fff9016f000 - 0x7fff901c8ff7 libTIFF.dylib (1029) <12303E45-734B-3D6C-A5C8-1495ECBC0344> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x7fff901c9000 - 0x7fff9041dff0 com.apple.security (7.0 - 55377) <2F4EFC9E-DD86-32E5-A2CB-E83A5DF34F8F> /System/Library/Frameworks/Security.framework/Versions/A/Security 0x7fff9045c000 - 0x7fff90461fff libmacho.dylib (845) <0038681B-CEC4-348A-A7B8-4236C701F2F8> /usr/lib/system/libmacho.dylib 0x7fff90462000 - 0x7fff90469ff3 libcopyfile.dylib (103) <54DD5730-3F05-3F18-B55C-24EA9546286F> /usr/lib/system/libcopyfile.dylib 0x7fff9046a000 - 0x7fff9046cff3 libsystem_configuration.dylib (596.1) <1E0FDEA3-8822-3E80-AA0D-57D0F4E30E2E> /usr/lib/system/libsystem_configuration.dylib 0x7fff90481000 - 0x7fff905efff7 libBLAS.dylib (1094.4) <80E99B02-BD2D-3D88-97B6-0BE2D8973633> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x7fff90622000 - 0x7fff90633fff libsystem_asl.dylib (217) /usr/lib/system/libsystem_asl.dylib 0x7fff90637000 - 0x7fff90652ff7 libPng.dylib (1029) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x7fff90653000 - 0x7fff906caff7 com.apple.CoreServices.OSServices (600 - 600) <73820122-62D4-359C-9312-CD49FCEDFE09> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x7fff906cb000 - 0x7fff906faff5 com.apple.GSS (4.0 - 2.0) <6765C9D7-8AC9-3694-B5D4-5C26B119851D> /System/Library/Frameworks/GSS.framework/Versions/A/GSS 0x7fff906fb000 - 0x7fff9070bffb libsasl2.2.dylib (169) <4DB6E107-D03E-3EC2-BCD2-80483FAC3FFF> /usr/lib/libsasl2.2.dylib 0x7fff9070c000 - 0x7fff9075afff libcorecrypto.dylib (161) <56048D2C-3668-3E15-AF02-5C5A377320F6> /usr/lib/system/libcorecrypto.dylib 0x7fff90cf4000 - 0x7fff90d01ff0 libbz2.1.0.dylib (29) /usr/lib/libbz2.1.0.dylib 0x7fff90d02000 - 0x7fff90d2efff com.apple.CoreServicesInternal (184.1 - 184.1) <84F93D96-0544-3377-B7E3-99716DC57A8A> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal 0x7fff90d5a000 - 0x7fff90d5bff3 libSystem.B.dylib (1197) <7589D08E-9338-3E28-AA74-9734F0D51CE0> /usr/lib/libSystem.B.dylib 0x7fff90da4000 - 0x7fff90e92fff libJP2.dylib (1029) <720403F5-7863-30D6-AC09-F5A04F069E1B> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib 0x7fff90e93000 - 0x7fff90e97ff7 libcache.dylib (61) /usr/lib/system/libcache.dylib 0x7fff90e98000 - 0x7fff90ea1ffe com.apple.CommonAuth (4.0 - 2.0) <3918EBA0-A124-37DC-9BA6-4D1370AF03A8> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth 0x7fff90ea2000 - 0x7fff90ee0ff7 libGLImage.dylib (9.0.74) <0DD99DA1-A8E7-3309-8DED-A2AB410E59C8> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x7fff90ef6000 - 0x7fff90f5aff7 com.apple.datadetectorscore (5.0 - 343.0) <7FE14856-0C85-3382-AD6C-1B9E21C276CB> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore 0x7fff90f5b000 - 0x7fff90fe4ff7 com.apple.ColorSync (4.9.0 - 4.9.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x7fff90fe5000 - 0x7fff91112ff7 com.apple.desktopservices (1.8 - 1.8) /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x7fff91113000 - 0x7fff91114fff liblangid.dylib (117) <5146A22B-088F-3D8D-B245-F03DD3CDA2B0> /usr/lib/liblangid.dylib 0x7fff9117e000 - 0x7fff91244ff7 com.apple.LaunchServices (572.3 - 572.3.1) <39618733-CC97-3991-BD3B-485BD7247115> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x7fff91245000 - 0x7fff9128aff7 libcurl.4.dylib (78) /usr/lib/libcurl.4.dylib 0x7fff9142c000 - 0x7fff91f8afff com.apple.AppKit (6.9 - 1240) <53CEC6E0-F928-32EC-919D-B34C0818C88C> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x7fff91f8b000 - 0x7fff9205cff2 com.apple.DiskImagesFramework (10.9 - 368.1) <2BF556C1-94D9-3816-BDD8-FB152BB7A89A> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages 0x7fff9205d000 - 0x7fff920b0fff com.apple.ScalableUserInterface (1.0 - 1) /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface 0x7fff920c5000 - 0x7fff9211cfff com.apple.Symbolication (1.4 - 125) /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication 0x7fff9211d000 - 0x7fff9211fff7 com.apple.securityhi (9.0 - 55005) <5BFDED08-3282-35B4-A37F-66BF8EAB0C90> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x7fff92144000 - 0x7fff92151ffc com.apple.Librarian (1.2 - 1) <556E5FA3-4DDB-3B59-ADE8-07411751B667> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian 0x7fff9215d000 - 0x7fff92315ffb libicucore.A.dylib (511.16) /usr/lib/libicucore.A.dylib 0x7fff926ea000 - 0x7fff926ecfff libRadiance.dylib (1029) <4E13C7E9-9B17-33D3-9142-B645B5BBCCD6> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x7fff9276f000 - 0x7fff92771ff7 libquarantine.dylib (69) <1776AABC-F1D7-3CB0-B698-B0C70D4E535B> /usr/lib/system/libquarantine.dylib 0x7fff92772000 - 0x7fff9278aff3 com.apple.openscripting (1.4 - 154) <1C16D0EF-C8D8-3D43-8155-F86968505E79> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x7fff9278b000 - 0x7fff92794ff3 libsystem_notify.dylib (121) /usr/lib/system/libsystem_notify.dylib 0x7fff92795000 - 0x7fff927b7fff libxpc.dylib (300.1.4) <4F832032-9709-3E80-91C4-71914C67A32B> /usr/lib/system/libxpc.dylib 0x7fff927b8000 - 0x7fff927ffff7 libcups.2.dylib (365) <49F3E642-D748-3A60-AF51-F9E90F65C543> /usr/lib/libcups.2.dylib 0x7fff92800000 - 0x7fff9284dff2 com.apple.print.framework.PrintCore (9.0 - 424) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x7fff9284e000 - 0x7fff92873ff7 com.apple.ChunkingLibrary (2.0 - 154) /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary 0x7fff92908000 - 0x7fff9290efff com.apple.AOSNotification (1.7.0 - 760) /System/Library/PrivateFrameworks/AOSNotification.framework/Versions/A/AOSNotification 0x7fff9293e000 - 0x7fff92946fff libsystem_dnssd.dylib (522.1.3) <29695A12-75FC-36EE-97AC-179F6E9DA419> /usr/lib/system/libsystem_dnssd.dylib 0x7fff92e6b000 - 0x7fff92e7cff7 libz.1.dylib (53) <372E2641-66CA-3B13-8BE6-3A4335F861A6> /usr/lib/libz.1.dylib 0x7fff92e7d000 - 0x7fff92e82ff7 libunwind.dylib (35.3) <838CE69D-44F1-305C-8FA5-5E439D217F78> /usr/lib/system/libunwind.dylib 0x7fff92e83000 - 0x7fff930c0ffb com.apple.RawCamera.bundle (4.06 - 695) /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera 0x7fff931f7000 - 0x7fff931f7fff com.apple.Carbon (154 - 157) <382844CD-59CB-3D50-83BF-35FC73D02C03> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x7fff93251000 - 0x7fff93342ff9 libiconv.2.dylib (41) /usr/lib/libiconv.2.dylib 0x7fff93369000 - 0x7fff93371ff7 com.apple.speech.recognition.framework (4.2.4 - 4.2.4) <1CE37DE8-BA4A-30CD-A802-18DAF42C328F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0x7fff934c3000 - 0x7fff934c3fff com.apple.Accelerate.vecLib (3.9 - vecLib 3.9) <349BA8B4-1C72-30BE-B2BB-1898F51B9B5E> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff934c8000 - 0x7fff934d5ff7 libxar.1.dylib (202) /usr/lib/libxar.1.dylib 0x7fff9386f000 - 0x7fff93897ffb libxslt.1.dylib (13) <33D39746-6FCD-3F32-AFAE-2E45232BF6FB> /usr/lib/libxslt.1.dylib 0x7fff93922000 - 0x7fff93926ff7 libGIF.dylib (1029) <000B8500-FC82-3016-8E59-9FA0D6395F04> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib 0x7fff93927000 - 0x7fff93975ff9 libstdc++.6.dylib (60) /usr/lib/libstdc++.6.dylib 0x7fff93976000 - 0x7fff93981fff libkxld.dylib (2422.1.26.0.1) /usr/lib/system/libkxld.dylib 0x7fff93982000 - 0x7fff9398dfff libGL.dylib (9.0.74) <2DB19533-5983-3F59-93F3-2761DA6EEDA5> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x7fff9398e000 - 0x7fff93b3bf8f libobjc.A.dylib (551) <853FA2C9-7BF1-3962-896E-6367F99FD358> /usr/lib/libobjc.A.dylib 0x7fff93b3c000 - 0x7fff93b3ffff libsystem_stats.dylib (93.1.8.1.1) /usr/lib/system/libsystem_stats.dylib 0x7fff93b40000 - 0x7fff93b50fff libbsm.0.dylib (33) <65C2FC5C-4B4B-3C1B-B935-D67A3BF96A79> /usr/lib/libbsm.0.dylib 0x7fff93b60000 - 0x7fff93b6cff3 com.apple.AppleFSCompression (56 - 1.0) /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression 0x7fff93b70000 - 0x7fff93b89ff7 com.apple.Kerberos (3.0 - 1) <13DDC487-95C0-379F-BD7F-E0FC5F5922D3> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x7fff93ed4000 - 0x7fff93eeefff libdispatch.dylib (339.1.2) /usr/lib/system/libdispatch.dylib 0x7fff93f3c000 - 0x7fff93f3cfff com.apple.ApplicationServices (48 - 48) <21188B7D-50E8-3C28-A15E-5345AE7BAFBB> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 1 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 6269 thread_create: 0 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=174.3M resident=68.1M(39%) swapped_out_or_unallocated=106.2M(61%) Writable regions: Total=754.9M written=50.8M(7%) resident=54.8M(7%) swapped_out=0K(0%) unallocated=700.1M(93%) REGION TYPE VIRTUAL =========== ======= CG backing stores 1204K CG image 1040K CG raster data 12K CG shared images 180K CoreServices 1364K Image IO 64K Kernel Alloc Once 8K MALLOC 62.9M MALLOC (admin) 32K Memory Tag 242 12K Memory Tag 251 36K STACK GUARD 56.1M Stack 26.2M VM_ALLOCATE 104.0M VM_ALLOCATE (reserved) 557.2M reserved VM address space (unallocated) __DATA 22.5M __IMAGE 528K __LINKEDIT 68.1M __TEXT 106.2M __UNICODE 544K mapped file 52.5M shared memory 4K =========== ======= TOTAL 1.0G TOTAL, minus reserved VM space 503.4M Model: VMware7,1, BootROM VMW71.00V.0.B64.1206270404, 4 processors, 3.23 GHz, 4 GB, SMC 1.16f8 Graphics: Display, PCI, 128 MB Memory Module: RAM slot #0/RAM slot #0, 4 GB, DRAM, 0 MHz, VMware Virtual RAM, VMW-4096MB Bluetooth: Version 4.2.0b11 12562, 3 services, 20 devices, 3 incoming serial ports Network Service: Ethernet, Ethernet, en0 SCSI Device: SCSI Target Device @ 0 SCSI Device: SCSI Target Device @ 0 USB Device: VMware Virtual USB Hub USB Device: Virtual Bluetooth Adapter USB Device: VMware Virtual USB Keyboard USB Device: VMware Virtual USB Mouse Thunderbolt Bus: From anthony.petrov at oracle.com Tue Jul 2 06:29:11 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 02 Jul 2013 17:29:11 +0400 Subject: Crash in liblwawt.dylib on OS X 10.9 In-Reply-To: <7ACF7412-B58F-4614-AE50-AD45EDB350FB@censhare.de> References: <7ACF7412-B58F-4614-AE50-AD45EDB350FB@censhare.de> Message-ID: <51D2D5A7.7050706@oracle.com> Hi Christof, Please file a bug at http://bug.sun.com/ and provide a reproducible test case/instructions in your bug report. -- best regards, Anthony On 07/02/2013 05:00 PM, Christof Aenderl wrote: > Hi, > > concerning a fixed bug: > http://bugs.sun.com/view_bug.do?bug_id=7152608 > > I found the same problem on the OS X 10.9 DP2 with Java 7_25: > > --------------------------------------------------------------- > Process: JavaAppLauncher [2333] > Path: /Users/USER/Documents/*/censhare Client.app/Contents/MacOS/JavaAppLauncher > Identifier: com.censhare.javaclient > Version: 4.7.8 (1.0) > Code Type: X86-64 (Native) > Parent Process: launchd [152] > Responsible: JavaAppLauncher [2333] > User ID: 501 > > Date/Time: 2013-07-01 22:22:18.259 +0200 > OS Version: Mac OS X 10.9 (13A497d) > Report Version: 11 > > Crashed Thread: 23 Java: Java2D Queue Flusher > > Exception Type: EXC_BAD_ACCESS (SIGABRT) > Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 > > VM Regions Near 0: > --> > __TEXT 00000001052e6000-00000001052e9000 [ 12K] r-x/rwx SM=COW /Users/USER/Documents/*/censhare Client.app/Contents/MacOS/JavaAppLauncher > > Application Specific Information: > abort() called > > Thread 0:: Dispatch queue: com.apple.main-thread > 0 libsystem_kernel.dylib 0x00007fff8a0aba66 mach_msg_trap + 10 > 1 libsystem_kernel.dylib 0x00007fff8a0aad64 mach_msg + 64 > 2 com.apple.CoreFoundation 0x00007fff8e4ba6f5 __CFRunLoopServiceMachPort + 181 > 3 com.apple.CoreFoundation 0x00007fff8e4c0989 __CFRunLoopRun + 1497 > 4 com.apple.CoreFoundation 0x00007fff8e4bffc3 CFRunLoopRunSpecific + 467 > 5 com.apple.HIToolbox 0x00007fff86b0ab11 RunCurrentEventLoopInMode + 226 > 6 com.apple.HIToolbox 0x00007fff86b0a8b4 ReceiveNextEventCommon + 479 > 7 com.apple.HIToolbox 0x00007fff86c1e8e9 _BlockUntilNextEventMatchingListInModeWithFilter + 65 > 8 com.apple.AppKit 0x00007fff9156204e _DPSNextEvent + 1434 > 9 com.apple.AppKit 0x00007fff9156169b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122 > 10 libosxapp.dylib 0x000000012f38ab56 -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 > 11 com.apple.AppKit 0x00007fff9179376f -[NSApplication _realDoModalLoop:peek:] + 620 > 12 com.apple.AppKit 0x00007fff91793a4b -[NSApplication runModalForWindow:] + 117 > 13 com.apple.AppKit 0x00007fff9178479d -[NSAlert runModal] + 145 > 14 com.apple.AppKit 0x00007fff91d551d9 __55-[NSPersistentUIRestorer promptToIgnorePersistentState]_block_invoke + 1054 > 15 com.apple.AppKit 0x00007fff914c5778 -[NSApplication _suppressFinishLaunchingFromEventHandlersWhilePerformingBlock:] + 28 > 16 com.apple.AppKit 0x00007fff91d54d7f -[NSPersistentUIRestorer promptToIgnorePersistentState] + 213 > 17 com.apple.AppKit 0x00007fff914c5753 -[NSPersistentUIManager promptToIgnorePersistentState] + 28 > 18 com.apple.AppKit 0x00007fff91565f64 -[NSApplication _reopenWindowsAsNecessaryIncludingRestorableState:registeringAsReady:completionHandler:] + 252 > 19 com.apple.AppKit 0x00007fff91565d39 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 557 > 20 com.apple.AppKit 0x00007fff9156585b -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 242 > 21 com.apple.Foundation 0x00007fff87aa709a -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 294 > 22 com.apple.Foundation 0x00007fff87aa6f0d _NSAppleEventManagerGenericHandler + 106 > 23 com.apple.AE 0x00007fff896a9b7f aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 381 > 24 com.apple.AE 0x00007fff896a9992 dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 31 > 25 com.apple.AE 0x00007fff896a9856 aeProcessAppleEvent + 315 > 26 com.apple.HIToolbox 0x00007fff86b1420e AEProcessAppleEvent + 56 > 27 com.apple.AppKit 0x00007fff91561eb6 _DPSNextEvent + 1026 > 28 com.apple.AppKit 0x00007fff9156169b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122 > 29 libosxapp.dylib 0x000000012f38ab56 -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 > 30 com.apple.AppKit 0x00007fff915598ec -[NSApplication run] + 553 > 31 libosxapp.dylib 0x000000012f38a9b9 +[NSApplicationAWT runAWTLoopWithApp:] + 156 > 32 libsplashscreen.dylib 0x000000012f341996 __SplashInitPlatform_block_invoke_1 + 86 > 33 libdispatch.dylib 0x00007fff93ed86d0 _dispatch_call_block_and_release + 12 > 34 libdispatch.dylib 0x00007fff93ed5984 _dispatch_client_callout + 8 > 35 libdispatch.dylib 0x00007fff93ed96a1 _dispatch_main_queue_callback_4CF + 333 > 36 com.apple.CoreFoundation 0x00007fff8e5884a9 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 > 37 com.apple.CoreFoundation 0x00007fff8e4c0ae4 __CFRunLoopRun + 1844 > 38 com.apple.CoreFoundation 0x00007fff8e4bffc3 CFRunLoopRunSpecific + 467 > 39 libjli.dylib 0x000000010535f88d CreateExecutionEnvironment + 871 > 40 libjli.dylib 0x000000010535a03c JLI_Launch + 1952 > 41 com.censhare.javaclient 0x00000001052e8948 launch + 4776 > 42 com.censhare.javaclient 0x00000001052e7556 main + 102 > 43 com.censhare.javaclient 0x00000001052e74e4 start + 52 > > Thread 1:: Dispatch queue: com.apple.libdispatch-manager > 0 libsystem_kernel.dylib 0x00007fff8a0b0692 kevent64 + 10 > 1 libdispatch.dylib 0x00007fff93ed7ac1 _dispatch_mgr_invoke + 239 > 2 libdispatch.dylib 0x00007fff93ed79c2 _dispatch_mgr_thread + 52 > > Thread 2: > 0 libsystem_kernel.dylib 0x00007fff8a0afa6a __semwait_signal + 10 > 1 libsystem_pthread.dylib 0x00007fff8a564830 pthread_join + 430 > 2 libjli.dylib 0x000000010535ee8d ContinueInNewThread0 + 102 > 3 libjli.dylib 0x000000010535aca7 ContinueInNewThread + 201 > 4 libjli.dylib 0x000000010535ebf0 JVMInit + 251 > 5 libjli.dylib 0x000000010535aa25 JLI_Launch + 4489 > 6 com.censhare.javaclient 0x00000001052e8948 launch + 4776 > 7 com.censhare.javaclient 0x00000001052e7556 main + 102 > 8 libjli.dylib 0x000000010535f51f apple_main + 92 > 9 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 10 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 11 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 3: > 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 > 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 > 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x00000001057fa109 ObjectMonitor::wait(long long, bool, Thread*) + 627 > 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 > 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 > 6 ??? 0x0000000106056f90 0 + 4395986832 > 7 ??? 0x000000010604b158 0 + 4395938136 > 8 ??? 0x000000010604b158 0 + 4395938136 > 9 ??? 0x000000010604b158 0 + 4395938136 > 10 ??? 0x000000010604b158 0 + 4395938136 > 11 ??? 0x000000010604b158 0 + 4395938136 > 12 ??? 0x000000010604b333 0 + 4395938611 > 13 ??? 0x000000010604b158 0 + 4395938136 > 14 ??? 0x000000010604b158 0 + 4395938136 > 15 ??? 0x00000001060454f7 0 + 4395914487 > 16 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 > 17 libjvm.dylib 0x00000001056d4390 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 > 18 libjvm.dylib 0x0000000105843c06 Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 2514 > 19 libjvm.dylib 0x0000000105843ed9 Reflection::invoke_constructor(oopDesc*, objArrayHandle, Thread*) + 417 > 20 libjvm.dylib 0x0000000105708b0e JVM_NewInstanceFromConstructor + 124 > 21 ??? 0x0000000106056f90 0 + 4395986832 > 22 ??? 0x000000010604b333 0 + 4395938611 > 23 ??? 0x000000010604b333 0 + 4395938611 > 24 ??? 0x000000010604b9e1 0 + 4395940321 > 25 ??? 0x000000010604b333 0 + 4395938611 > 26 ??? 0x000000010604b333 0 + 4395938611 > 27 ??? 0x000000010604b333 0 + 4395938611 > 28 ??? 0x000000010604b333 0 + 4395938611 > 29 ??? 0x000000010604b333 0 + 4395938611 > 30 ??? 0x000000010604b333 0 + 4395938611 > 31 ??? 0x000000010604b333 0 + 4395938611 > 32 ??? 0x000000010604b158 0 + 4395938136 > 33 ??? 0x00000001060454f7 0 + 4395914487 > 34 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 > 35 libjvm.dylib 0x00000001056d4390 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 > 36 libjvm.dylib 0x000000010570fa8f JVM_DoPrivileged + 1037 > 37 ??? 0x0000000106056f90 0 + 4395986832 > 38 ??? 0x000000010604b333 0 + 4395938611 > 39 ??? 0x000000010604b158 0 + 4395938136 > 40 ??? 0x000000010604b158 0 + 4395938136 > 41 ??? 0x000000010604b158 0 + 4395938136 > 42 ??? 0x000000010604b158 0 + 4395938136 > 43 ??? 0x00000001060454f7 0 + 4395914487 > 44 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 > 45 libjvm.dylib 0x00000001056d4390 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 > 46 libjvm.dylib 0x00000001056efe70 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 219 > 47 libjvm.dylib 0x00000001056e91c8 jni_CallStaticVoidMethod + 267 > 48 libjli.dylib 0x000000010535b5de JavaMain + 2333 > 49 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 50 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 51 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 4: > 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 > 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 > 2 libjvm.dylib 0x0000000105800af7 os::PlatformEvent::park(long long) + 385 > 3 libjvm.dylib 0x00000001057e3402 Monitor::IWait(Thread*, long long) + 160 > 4 libjvm.dylib 0x00000001057e365f Monitor::wait(bool, long, bool) + 375 > 5 libjvm.dylib 0x00000001058f7b00 VMThread::loop() + 444 > 6 libjvm.dylib 0x00000001058f761b VMThread::run() + 121 > 7 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 > 8 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 9 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 10 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 5:: Java: Reference Handler > 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 > 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 > 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x00000001057fa109 ObjectMonitor::wait(long long, bool, Thread*) + 627 > 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 > 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 > 6 ??? 0x0000000106056f90 0 + 4395986832 > 7 ??? 0x000000010604b158 0 + 4395938136 > 8 ??? 0x000000010604b158 0 + 4395938136 > 9 ??? 0x00000001060454f7 0 + 4395914487 > 10 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 > 11 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 > 12 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 > 13 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 > 14 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 > 15 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 > 16 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 > 17 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 18 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 19 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 6:: Java: Finalizer > 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 > 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 > 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x00000001057fa109 ObjectMonitor::wait(long long, bool, Thread*) + 627 > 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 > 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 > 6 ??? 0x0000000106056f90 0 + 4395986832 > 7 ??? 0x000000010604b158 0 + 4395938136 > 8 ??? 0x000000010604b333 0 + 4395938611 > 9 ??? 0x000000010604b333 0 + 4395938611 > 10 ??? 0x00000001060454f7 0 + 4395914487 > 11 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 > 12 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 > 13 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 > 14 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 > 15 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 > 16 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 > 17 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 > 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 19 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 7: > 0 libsystem_kernel.dylib 0x00007fff8a0afe9a __workq_kernreturn + 10 > 1 libsystem_pthread.dylib 0x00007fff8a561f4e _pthread_wqthread + 324 > 2 libsystem_pthread.dylib 0x00007fff8a564fd9 start_wqthread + 13 > > Thread 8: > 0 libsystem_kernel.dylib 0x00007fff8a0afe9a __workq_kernreturn + 10 > 1 libsystem_pthread.dylib 0x00007fff8a561f4e _pthread_wqthread + 324 > 2 libsystem_pthread.dylib 0x00007fff8a564fd9 start_wqthread + 13 > > Thread 9:: Java: Signal Dispatcher > 0 libsystem_kernel.dylib 0x00007fff8a0abaa2 semaphore_wait_trap + 10 > 1 libjvm.dylib 0x0000000105801e57 check_pending_signals(bool) + 128 > 2 libjvm.dylib 0x00000001057fe994 signal_thread_entry(JavaThread*, Thread*) + 57 > 3 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 > 4 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 > 5 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 > 6 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 7 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 8 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 10:: Java: C2 CompilerThread0 > 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 > 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 > 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x00000001057e2c10 ParkCommon(ParkEvent*, long long) + 42 > 4 libjvm.dylib 0x00000001057e3402 Monitor::IWait(Thread*, long long) + 160 > 5 libjvm.dylib 0x00000001057e35c6 Monitor::wait(bool, long, bool) + 222 > 6 libjvm.dylib 0x00000001055d2281 CompileQueue::get() + 153 > 7 libjvm.dylib 0x00000001055d2da2 CompileBroker::compiler_thread_loop() + 410 > 8 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 > 9 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 > 10 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 > 11 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 12 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 13 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 11:: Java: C2 CompilerThread1 > 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 > 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 > 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x00000001057e2c10 ParkCommon(ParkEvent*, long long) + 42 > 4 libjvm.dylib 0x00000001057e3402 Monitor::IWait(Thread*, long long) + 160 > 5 libjvm.dylib 0x00000001057e35c6 Monitor::wait(bool, long, bool) + 222 > 6 libjvm.dylib 0x00000001055d2281 CompileQueue::get() + 153 > 7 libjvm.dylib 0x00000001055d2da2 CompileBroker::compiler_thread_loop() + 410 > 8 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 > 9 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 > 10 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 > 11 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 12 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 13 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 12:: Java: Service Thread > 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 > 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 > 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x00000001057e2c10 ParkCommon(ParkEvent*, long long) + 42 > 4 libjvm.dylib 0x00000001057e3402 Monitor::IWait(Thread*, long long) + 160 > 5 libjvm.dylib 0x00000001057e365f Monitor::wait(bool, long, bool) + 375 > 6 libjvm.dylib 0x0000000105852249 ServiceThread::service_thread_entry(JavaThread*, Thread*) + 109 > 7 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 > 8 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 > 9 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 > 10 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 11 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 12 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 13: > 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 > 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 > 2 libjvm.dylib 0x0000000105800af7 os::PlatformEvent::park(long long) + 385 > 3 libjvm.dylib 0x00000001058c7d06 WatcherThread::run() + 328 > 4 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 > 5 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 6 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 7 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 14: > 0 libsystem_kernel.dylib 0x00007fff8a0b09aa poll + 10 > 1 libsplashscreen.dylib 0x000000012f34281c SplashEventLoop + 220 > 2 libsplashscreen.dylib 0x000000012f342b9e SplashScreenThread + 574 > 3 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 4 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 5 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 15: > 0 libsystem_kernel.dylib 0x00007fff8a0afe9a __workq_kernreturn + 10 > 1 libsystem_pthread.dylib 0x00007fff8a561f4e _pthread_wqthread + 324 > 2 libsystem_pthread.dylib 0x00007fff8a564fd9 start_wqthread + 13 > > Thread 16: > 0 libsystem_kernel.dylib 0x00007fff8a0afe9a __workq_kernreturn + 10 > 1 libsystem_pthread.dylib 0x00007fff8a561f4e _pthread_wqthread + 324 > 2 libsystem_pthread.dylib 0x00007fff8a564fd9 start_wqthread + 13 > > Thread 17: > 0 libsystem_kernel.dylib 0x00007fff8a0afe9a __workq_kernreturn + 10 > 1 libsystem_pthread.dylib 0x00007fff8a561f4e _pthread_wqthread + 324 > 2 libsystem_pthread.dylib 0x00007fff8a564fd9 start_wqthread + 13 > > Thread 18:: Java: ActiveActionsRegistryThread > 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 > 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 > 2 libjvm.dylib 0x0000000105800af7 os::PlatformEvent::park(long long) + 385 > 3 libjvm.dylib 0x00000001057fa113 ObjectMonitor::wait(long long, bool, Thread*) + 637 > 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 > 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 > 6 ??? 0x0000000106056f90 0 + 4395986832 > 7 ??? 0x000000010604b158 0 + 4395938136 > 8 ??? 0x000000010604b158 0 + 4395938136 > 9 ??? 0x000000010604b806 0 + 4395939846 > 10 ??? 0x00000001060454f7 0 + 4395914487 > 11 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 > 12 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 > 13 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 > 14 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 > 15 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 > 16 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 > 17 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 > 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 19 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 19:: Java: TaskScheduler-no-EDT > 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 > 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 > 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x00000001057fa109 ObjectMonitor::wait(long long, bool, Thread*) + 627 > 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 > 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 > 6 ??? 0x0000000106056f90 0 + 4395986832 > 7 ??? 0x000000010604b158 0 + 4395938136 > 8 ??? 0x000000010604b158 0 + 4395938136 > 9 ??? 0x000000010604b158 0 + 4395938136 > 10 ??? 0x00000001060454f7 0 + 4395914487 > 11 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 > 12 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 > 13 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 > 14 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 > 15 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 > 16 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 > 17 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 > 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 19 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 20:: com.apple.appkit-heartbeat > 0 com.apple.AppKit 0x00007fff915321d5 -[NSView(NSPrivateHLTBSupport) _boundToHIView] + 17 > 1 com.apple.AppKit 0x00007fff91532144 -[NSView visibleRect] + 227 > 2 com.apple.AppKit 0x00007fff91752df9 -[NSWindow(NSWindow_Theme) heartBeat:] + 236 > 3 com.apple.AppKit 0x00007fff9172cfad -[NSUIHeartBeat _heartBeatThread:] + 868 > 4 com.apple.Foundation 0x00007fff87ad6fcc __NSThread__main__ + 1318 > 5 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 6 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 7 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 21:: Java: AWT-Shutdown > 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 > 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 > 2 libjvm.dylib 0x00000001057ff98b os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x00000001057fa109 ObjectMonitor::wait(long long, bool, Thread*) + 627 > 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 > 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 > 6 ??? 0x0000000106056f90 0 + 4395986832 > 7 ??? 0x000000010604b158 0 + 4395938136 > 8 ??? 0x000000010604b158 0 + 4395938136 > 9 ??? 0x000000010604b806 0 + 4395939846 > 10 ??? 0x00000001060454f7 0 + 4395914487 > 11 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 > 12 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 > 13 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 > 14 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 > 15 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 > 16 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 > 17 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 > 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 19 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 22:: Java: Image Fetcher 0 > 0 libsystem_kernel.dylib 0x00007fff8a0af746 __psynch_cvwait + 10 > 1 libsystem_pthread.dylib 0x00007fff8a562c7b _pthread_cond_wait + 727 > 2 libjvm.dylib 0x0000000105800af7 os::PlatformEvent::park(long long) + 385 > 3 libjvm.dylib 0x00000001057fa113 ObjectMonitor::wait(long long, bool, Thread*) + 637 > 4 libjvm.dylib 0x0000000105897407 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 > 5 libjvm.dylib 0x0000000105710723 JVM_MonitorWait + 156 > 6 ??? 0x0000000106056f90 0 + 4395986832 > 7 ??? 0x000000010604b158 0 + 4395938136 > 8 ??? 0x000000010604b333 0 + 4395938611 > 9 ??? 0x000000010604b158 0 + 4395938136 > 10 ??? 0x00000001060454f7 0 + 4395914487 > 11 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 > 12 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 > 13 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 > 14 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 > 15 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 > 16 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 > 17 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 > 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 19 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 23 Crashed:: Java: Java2D Queue Flusher > 0 libsystem_kernel.dylib 0x00007fff8a0af896 __pthread_kill + 10 > 1 libsystem_pthread.dylib 0x00007fff8a5613c5 pthread_kill + 92 > 2 libsystem_c.dylib 0x00007fff8ea61c22 abort + 125 > 3 libjvm.dylib 0x00000001058030d7 os::abort(bool) + 25 > 4 libjvm.dylib 0x00000001058f2020 VMError::report_and_die() + 2306 > 5 libjvm.dylib 0x00000001058047cb JVM_handle_bsd_signal + 1073 > 6 libsystem_platform.dylib 0x00007fff8a20d80a _sigtramp + 26 > 7 libGL.dylib 0x00007fff93983fc8 glGetString + 15 > 8 liblwawt.dylib 0x000000013391a69f Java_sun_java2d_opengl_OGLContext_getOGLIdString + 35 > 9 ??? 0x0000000106056f90 0 + 4395986832 > 10 ??? 0x000000010604b333 0 + 4395938611 > 11 ??? 0x000000010604b806 0 + 4395939846 > 12 ??? 0x00000001060454f7 0 + 4395914487 > 13 libjvm.dylib 0x00000001056d45c3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 > 14 libjvm.dylib 0x00000001056d4aa2 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 258 > 15 libjvm.dylib 0x00000001056d4bdc JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 > 16 libjvm.dylib 0x000000010570b868 thread_entry(JavaThread*, Thread*) + 173 > 17 libjvm.dylib 0x00000001058c6bd8 JavaThread::thread_main_inner() + 134 > 18 libjvm.dylib 0x00000001058c80ca JavaThread::run() + 440 > 19 libjvm.dylib 0x00000001058035f9 java_start(Thread*) + 173 > 20 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body + 138 > 21 libsystem_pthread.dylib 0x00007fff8a5607a0 _pthread_start + 131 > 22 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start + 13 > > Thread 23 crashed with X86 Thread State (64-bit): > rax: 0x0000000000000000 rbx: 0x0000000134733000 rcx: 0x0000000134732088 rdx: 0x0000000000000000 > rdi: 0x0000000000008d07 rsi: 0x0000000000000006 rbp: 0x00000001347320b0 rsp: 0x0000000134732088 > r8: 0x0000000000000040 r9: 0x0000000134732000 r10: 0x0000000008000000 r11: 0x0000000000000206 > r12: 0x0000000105b961f0 r13: 0x0000000129997498 r14: 0x0000000000000006 r15: 0x00000001058066bc > rip: 0x00007fff8a0af896 rfl: 0x0000000000000206 cr2: 0x000000010592a000 > > Logical CPU: 0 > Error Code: 0x02000148 > Trap Number: 133 > > > Binary Images: > 0x1052e6000 - 0x1052e8ff7 +com.censhare.javaclient (4.7.8pre - 1.0) <5A002039-2B05-362A-BD4C-37CA0CD6B136> /Users/USER/Documents/*/censhare Client.app/Contents/MacOS/JavaAppLauncher > 0x105358000 - 0x105362fff +libjli.dylib (1) <9792ED7A-1BD0-3D84-B551-F5DA12537016> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/jli/libjli.dylib > 0x10544a000 - 0x105ad5fef +libjvm.dylib (1) <1B03A29F-0248-337E-8529-87706B48A7DE> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/server/libjvm.dylib > 0x105ff6000 - 0x105ffefff +libverify.dylib (1) /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libverify.dylib > 0x106003000 - 0x106024fef +libjava.dylib (1) /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libjava.dylib > 0x10603c000 - 0x106041fff +libzip.dylib (1) <89DD8E8C-F4A4-3E92-A2D6-CC8642447AC3> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libzip.dylib > 0x12eb60000 - 0x12eb69ff7 com.apple.java.JavaRuntimeSupport (14.8.0 - 14.8.0) /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/JavaRuntimeSupport > 0x12eb78000 - 0x12eb82fff JavaNativeFoundation (1) /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation > 0x12eb8d000 - 0x12eb92fff com.apple.JavaVM (14.8.0 - 14.8.0) <83C8C2AB-E99D-39FF-80B4-90A7DEB1DAFB> /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM > 0x12eb9a000 - 0x12eb9ffff JavaLaunching (1) /System/Library/PrivateFrameworks/JavaLaunching.framework/Versions/A/JavaLaunching > 0x12f33a000 - 0x12f379fff +libsplashscreen.dylib (1) /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libsplashscreen.dylib > 0x12f389000 - 0x12f38ffff +libosxapp.dylib (1) <19D025A3-9368-319D-AA64-EF835D78A0FF> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libosxapp.dylib > 0x12f3a5000 - 0x12f3a7fff com.apple.ExceptionHandling (1.5 - 10) /System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ExceptionHandling > 0x131880000 - 0x131888ffb libCGCMS.A.dylib (565) <978DCDAA-A34D-3223-A362-9A51E3697D93> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGCMS.A.dylib > 0x1319b8000 - 0x1319e1ffb libRIP.A.dylib (565) <7A4FA177-8BCD-3A95-A577-57B079C8C9D2> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib > 0x131cd2000 - 0x131cd5ffa libCGXType.A.dylib (565) <6EF5CFC1-05F8-3E78-86D5-AD5659D92642> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib > 0x13379a000 - 0x133806ff7 +libawt.dylib (1) <614FC193-CE14-3B85-9F8B-33F92FBD6D92> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libawt.dylib > 0x13384a000 - 0x13390ffff +libmlib_image.dylib (1) <95F6D0B2-3A92-305F-A6AE-822BC990901B> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libmlib_image.dylib > 0x133916000 - 0x133986ff7 +liblwawt.dylib (1) <8004F9F2-4EDF-3FF4-8B40-12F06C5C97FA> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/lwawt/liblwawt.dylib > 0x1341cd000 - 0x13420efff +libfontmanager.dylib (1) <63A05734-9483-3B12-BAB0-E1EB020C1A32> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libfontmanager.dylib > 0x1344b5000 - 0x1344b9fff +libosxui.dylib (1) <56D2A1A1-1532-3AF5-98CC-0A3BE7B986B7> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libosxui.dylib > 0x1344be000 - 0x1344c6fff +libnio.dylib (1) <4E9F4A0E-BC84-31E8-AB60-3F9F37B08B00> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libnio.dylib > 0x1344cd000 - 0x1344dbff7 +libnet.dylib (1) <6A30865D-EBB7-3D91-921C-7A3E0416E481> /Users/USER/Documents/*/censhare Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libnet.dylib > 0x134735000 - 0x1348c5fff GLEngine (9.0.74) <1D7D765E-402A-36E3-A879-0E2A0E406293> /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine > 0x1348fd000 - 0x134926fff GLRendererFloat (9.0.74) <37D2C111-A7C9-3657-96D2-586C0BFE1EAB> /System/Library/Frameworks/OpenGL.framework/Resources/GLRendererFloat.bundle/GLRendererFloat > 0x13492f000 - 0x134938ff7 libcldcpuengine.dylib (2.3.49) <7C0F237D-4818-3101-86C3-9B05243FC173> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libcldcpuengine.dylib > 0x7fff6f401000 - 0x7fff6f4344a7 dyld (237) /usr/lib/dyld > 0x7fff86aa2000 - 0x7fff86aa2ffd com.apple.audio.units.AudioUnit (1.9 - 1.9) /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit > 0x7fff86aae000 - 0x7fff86d56ff9 com.apple.HIToolbox (2.1 - 681) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox > 0x7fff86d59000 - 0x7fff86da6fff com.apple.opencl (2.3.50 - 2.3.50) <33C1EC76-02A2-3474-BB9D-8F77B96E57CC> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL > 0x7fff86da7000 - 0x7fff86e89ff7 com.apple.backup.framework (1.5 - 1.5) <70E20485-EDB6-3225-8AF6-6D9494CB98B7> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup > 0x7fff86e8a000 - 0x7fff86e8dff7 com.apple.help (1.3.3 - 46) <4FF8A8E2-33C2-30DF-86CE-A7ADA9F56A3F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help > 0x7fff86eb2000 - 0x7fff86ecefff libresolv.9.dylib (54) <78D891A1-6F8B-34D4-8F0D-59DB6DF53411> /usr/lib/libresolv.9.dylib > 0x7fff86ecf000 - 0x7fff86f0efff libGLU.dylib (9.0.74) <294F4F86-E900-356C-9A47-0C47A929F2FB> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib > 0x7fff872a7000 - 0x7fff872dbfff libssl.0.9.8.dylib (50) <1A09EC98-23CF-39F1-9C99-38A47ED7184E> /usr/lib/libssl.0.9.8.dylib > 0x7fff873c4000 - 0x7fff873c5ff7 libsystem_blocks.dylib (63) <7836104E-39B9-31B6-A0C7-C02ACD401ADE> /usr/lib/system/libsystem_blocks.dylib > 0x7fff873c6000 - 0x7fff873deff7 com.apple.GenerationalStorage (2.0 - 158) <5BCFBEED-09D2-3BD3-8EE0-85E809C47380> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage > 0x7fff873df000 - 0x7fff874cafff libsqlite3.dylib (155) /usr/lib/libsqlite3.dylib > 0x7fff874cb000 - 0x7fff878acffe libLAPACK.dylib (1094.4) <19E25957-74BA-3770-AAB5-B6A05F19BDC2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib > 0x7fff878ad000 - 0x7fff87a49fff com.apple.QuartzCore (1.8 - 329.0) <08CE1885-71E8-3A38-AEB6-4BBB1A43785F> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore > 0x7fff87a4a000 - 0x7fff87d49ff7 com.apple.Foundation (6.9 - 1042) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation > 0x7fff87d84000 - 0x7fff87dd6fff libc++.1.dylib (118) <5FF54631-AC11-3AD8-B42D-04FAC953CCED> /usr/lib/libc++.1.dylib > 0x7fff87dd7000 - 0x7fff87e56fff com.apple.CoreSymbolication (3.0 - 137) <85C4F6E2-5039-3E53-9AB2-6D65CAC9AAC5> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication > 0x7fff87e57000 - 0x7fff87e69fff com.apple.ImageCapture (9.0 - 9.0) <9613F27D-A905-35BF-A23F-C69CD5337035> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture > 0x7fff87e6a000 - 0x7fff87e71ffb liblaunch.dylib (842.1.1) <7055DF9E-52CE-3746-96EB-3718DDBF0BD0> /usr/lib/system/liblaunch.dylib > 0x7fff87ec5000 - 0x7fff87f50fff libCoreStorage.dylib (377) /usr/lib/libCoreStorage.dylib > 0x7fff87f51000 - 0x7fff8823bff7 com.apple.CoreServices.CarbonCore (1077.6 - 1077.6) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore > 0x7fff8837a000 - 0x7fff88381fff com.apple.NetFS (6.0 - 4.0) <553EA9F4-7B2C-371A-AF03-4B709A730582> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS > 0x7fff88382000 - 0x7fff883c6ffe com.apple.HIServices (1.22 - 454) <3625AF2C-1965-349D-B831-1FCC9084B675> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices > 0x7fff883c7000 - 0x7fff883c8ffb libremovefile.dylib (33) /usr/lib/system/libremovefile.dylib > 0x7fff883c9000 - 0x7fff883f0ff3 libsystem_info.dylib (449) /usr/lib/system/libsystem_info.dylib > 0x7fff883f1000 - 0x7fff88432ff7 com.apple.PerformanceAnalysis (1.45 - 45) <6C498B15-45DB-362F-983B-764ECC9B8E21> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis > 0x7fff88433000 - 0x7fff884a2ff1 com.apple.ApplicationServices.ATS (360 - 360) <8A3AD47D-2777-3019-80BB-4B17AA055E13> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS > 0x7fff884a3000 - 0x7fff8856bff7 libvDSP.dylib (423.29) <72A38066-D6F5-38EC-A8B9-0D025AFC6E2B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib > 0x7fff89149000 - 0x7fff89181ff7 com.apple.RemoteViewServices (2.0 - 94) <7E7B5F1F-9F0E-3DF7-B6B9-152DFD2DFFC7> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices > 0x7fff893d1000 - 0x7fff893d4fff com.apple.TCC (1.0 - 1) <1DF1D216-1355-3E4F-B4BE-3E3BA5A696EB> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC > 0x7fff89407000 - 0x7fff89430fff com.apple.DictionaryServices (1.2 - 197) <862F498E-3CB7-3087-BB07-AC185D5D08F8> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices > 0x7fff8946b000 - 0x7fff89492ff7 libsystem_network.dylib (241.3) /usr/lib/system/libsystem_network.dylib > 0x7fff89493000 - 0x7fff894fdff7 com.apple.framework.IOKit (2.0.1 - 907.1.5) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit > 0x7fff89505000 - 0x7fff89529fff libJPEG.dylib (1029) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib > 0x7fff8952a000 - 0x7fff89534fff libcommonCrypto.dylib (60049) /usr/lib/system/libcommonCrypto.dylib > 0x7fff89535000 - 0x7fff89566fff com.apple.MediaKit (15 - 709) /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit > 0x7fff89669000 - 0x7fff89684ff7 libCRFSuite.dylib (34) /usr/lib/libCRFSuite.dylib > 0x7fff896a3000 - 0x7fff896fdff8 com.apple.AE (665.2 - 665.2) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE > 0x7fff89b72000 - 0x7fff89b72ff7 libkeymgr.dylib (28) /usr/lib/system/libkeymgr.dylib > 0x7fff89b8d000 - 0x7fff89bbcfff com.apple.DebugSymbols (106 - 106) <545E5A48-3516-3398-A33D-D6FB4FED4B7B> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols > 0x7fff89bc0000 - 0x7fff89c23ff3 com.apple.SystemConfiguration (1.13 - 1.13) <73B50935-DFE8-31B8-8583-27A28B5A9D1E> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration > 0x7fff89c2b000 - 0x7fff89c2bfff com.apple.CoreServices (59 - 59) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices > 0x7fff89c8b000 - 0x7fff89cb0ffb com.apple.CoreVideo (1.8 - 117.0) <50587BF1-D111-3D49-9DAB-8F86B5E95808> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo > 0x7fff89cfe000 - 0x7fff89e54ff3 com.apple.audio.toolbox.AudioToolbox (1.9 - 1.9) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox > 0x7fff89e9e000 - 0x7fff89f11ffb com.apple.securityfoundation (6.0 - 55122) /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation > 0x7fff89fa0000 - 0x7fff89fa1fff libunc.dylib (28) <53C7CED6-55F5-3121-B00E-4339C29297C8> /usr/lib/system/libunc.dylib > 0x7fff89fa2000 - 0x7fff89fa6fff com.apple.CommonPanels (1.2.6 - 96) <3E07F8FE-B061-318D-A00F-E7D993DEF4FB> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels > 0x7fff89fb3000 - 0x7fff8a09afff libxml2.2.dylib (25) /usr/lib/libxml2.2.dylib > 0x7fff8a09b000 - 0x7fff8a0b6ff7 libsystem_kernel.dylib (2422.1.26.0.1) <5F99677C-C760-3877-AFF7-F60B5ECE365E> /usr/lib/system/libsystem_kernel.dylib > 0x7fff8a0b7000 - 0x7fff8a0c1ff7 libcsfde.dylib (377) /usr/lib/libcsfde.dylib > 0x7fff8a0c2000 - 0x7fff8a0c6ff7 libheimdal-asn1.dylib (323.3) <90100758-0CC6-3D00-90AB-D3C7DC8CCE45> /usr/lib/libheimdal-asn1.dylib > 0x7fff8a12a000 - 0x7fff8a209fff libcrypto.0.9.8.dylib (50) <9B1D3623-4A41-3A5B-88C7-1927AF7E2532> /usr/lib/libcrypto.0.9.8.dylib > 0x7fff8a20a000 - 0x7fff8a210fef libsystem_platform.dylib (24) <5D8FE8C3-2A62-3705-AB7D-FBD7C284AFBD> /usr/lib/system/libsystem_platform.dylib > 0x7fff8a211000 - 0x7fff8a4e0fdf com.apple.vImage (7.0 - 7.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage > 0x7fff8a55f000 - 0x7fff8a566ff7 libsystem_pthread.dylib (53) <2160EC74-26FC-32CE-8161-B1A72D2B09B0> /usr/lib/system/libsystem_pthread.dylib > 0x7fff8a5a9000 - 0x7fff8a616fff com.apple.SearchKit (1.4.0 - 1.4.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit > 0x7fff8a64c000 - 0x7fff8a65bff8 com.apple.LangAnalysis (1.7.0 - 1.7.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis > 0x7fff8a91a000 - 0x7fff8a930fff com.apple.CFOpenDirectory (10.9 - 171) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory > 0x7fff8a9ba000 - 0x7fff8aa46ff7 com.apple.ink.framework (10.9 - 205) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink > 0x7fff8aa47000 - 0x7fff8b34d043 com.apple.CoreGraphics (1.600.0 - 565) <81F84822-675E-3466-97A7-6FF69DF569E3> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics > 0x7fff8b485000 - 0x7fff8b49ffff libsystem_malloc.dylib (23.1.1) /usr/lib/system/libsystem_malloc.dylib > 0x7fff8b4a0000 - 0x7fff8b4a0fff com.apple.Accelerate (1.9 - Accelerate 1.9) <94C28250-6BDB-30AD-B157-995D9C34A6FA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate > 0x7fff8b4a3000 - 0x7fff8b4a5fff libCVMSPluginSupport.dylib (9.0.74) <11FCA581-0FFD-37B1-966A-E47F4722D297> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib > 0x7fff8b4b7000 - 0x7fff8b4c5ff7 com.apple.opengl (9.0.74 - 9.0.74) <9BD0013A-E503-3DA2-9F94-C42A11D2E734> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL > 0x7fff8b538000 - 0x7fff8b5f0ff7 com.apple.DiscRecording (8.0 - 8000.4.6) <62C23719-2144-3137-87DF-0858239A08BE> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording > 0x7fff8ba7a000 - 0x7fff8bb29ff7 libvMisc.dylib (423.29) <83CBEBB6-B9C2-3D83-A32A-CED47CDB65D6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib > 0x7fff8bb2a000 - 0x7fff8bb36fff com.apple.OpenDirectory (10.9 - 171) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory > 0x7fff8bb37000 - 0x7fff8bb3cfff com.apple.DiskArbitration (2.6 - 2.6) <4D7487BB-C4A7-32DB-BEE2-CE55EA7F40B2> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration > 0x7fff8bb3d000 - 0x7fff8bbffff9 com.apple.CoreText (352.0 - 367.6) /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText > 0x7fff8bdae000 - 0x7fff8bdbbfff com.apple.Sharing (112 - 112) <24BA2112-4FFB-318A-B881-93FEB4648371> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing > 0x7fff8bde7000 - 0x7fff8bdebfff libpam.2.dylib (20) <17E3DA0D-EE71-3398-BA30-BDD8514A6135> /usr/lib/libpam.2.dylib > 0x7fff8bdec000 - 0x7fff8bedbfff libFontParser.dylib (106) <16B9215D-3244-365F-910F-FA033495E3F5> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib > 0x7fff8bedc000 - 0x7fff8bef5ff3 com.apple.Ubiquity (1.3 - 280) <581DAEFC-B314-3F92-93CF-7B70BF22AEEF> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity > 0x7fff8bf41000 - 0x7fff8bf76ffc com.apple.LDAPFramework (2.4.28 - 194.5) <44544698-E9CA-3440-808A-FF5417E55538> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP > 0x7fff8bf77000 - 0x7fff8bf79ffb libutil.dylib (34) <9A9338CF-FD16-3D8F-8564-0797A4DAFC5F> /usr/lib/libutil.dylib > 0x7fff8c1f5000 - 0x7fff8c1f5fff com.apple.Cocoa (6.8 - 20) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa > 0x7fff8c1f6000 - 0x7fff8c1f9fff libCoreVMClient.dylib (58.1) <331C429A-3AE5-30B8-A4DE-1BF4EE4D8FA6> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib > 0x7fff8c224000 - 0x7fff8c227ffc com.apple.IOSurface (91 - 91) <1B7746FC-3599-3BDB-A0DA-65795C999435> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface > 0x7fff8c26d000 - 0x7fff8c4aafff com.apple.CoreData (107 - 468) <51F9B655-84D2-3E88-991B-914C9017BB08> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData > 0x7fff8c4ab000 - 0x7fff8c4b5ff7 com.apple.bsd.ServiceManagement (2.0 - 2.0) <3E92DCA9-DA23-34E1-8C38-DA7488621FFB> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement > 0x7fff8c51a000 - 0x7fff8c51bff7 libsystem_sandbox.dylib (278.1) /usr/lib/system/libsystem_sandbox.dylib > 0x7fff8c9d3000 - 0x7fff8ca0cff7 com.apple.QD (3.49 - 297) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD > 0x7fff8ca0d000 - 0x7fff8ca36ff7 libc++abi.dylib (43) /usr/lib/libc++abi.dylib > 0x7fff8ca78000 - 0x7fff8cac8ffa com.apple.audio.CoreAudio (4.2.0 - 4.2.0) <548AC059-62DD-3CF6-B083-CABE454AFA38> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio > 0x7fff8d929000 - 0x7fff8d92aff7 libDiagnosticMessagesClient.dylib (100) /usr/lib/libDiagnosticMessagesClient.dylib > 0x7fff8dde9000 - 0x7fff8decbfff com.apple.coreui (2.1 - 224) <9F8C1983-1795-34DA-A0C1-7F126ECA0D8E> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI > 0x7fff8decf000 - 0x7fff8ded2ff7 libdyld.dylib (237) /usr/lib/system/libdyld.dylib > 0x7fff8ded3000 - 0x7fff8e039fff libGLProgrammability.dylib (9.0.74) <07E259BB-1EDA-3EBE-9CDB-8DB09DE5D509> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib > 0x7fff8e0af000 - 0x7fff8e0e9ffb com.apple.bom (12.0 - 192) /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom > 0x7fff8e0ea000 - 0x7fff8e175fff com.apple.Metadata (10.7.0 - 778.1) <93F05A4E-6581-3CD5-8697-84783CEBF764> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata > 0x7fff8e176000 - 0x7fff8e199fff com.apple.IconServices (25 - 25.4) <525BAAE5-F45C-3A15-ACED-2AF4EFFED546> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices > 0x7fff8e319000 - 0x7fff8e31aff7 com.apple.print.framework.Print (9.0 - 260) <264DAE2A-7FD5-36B4-A737-F521E62AE687> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print > 0x7fff8e31b000 - 0x7fff8e484ff3 com.apple.CFNetwork (657 - 657) <59A9476F-19A2-3F8B-A9B0-8531EA36A4AE> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork > 0x7fff8e48a000 - 0x7fff8e491fff libcompiler_rt.dylib (35) /usr/lib/system/libcompiler_rt.dylib > 0x7fff8e492000 - 0x7fff8e675ff7 com.apple.CoreFoundation (6.9 - 842) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > 0x7fff8e6f1000 - 0x7fff8e6f2fff com.apple.TrustEvaluationAgent (2.0 - 25) <644D981B-A5A7-31F5-99A6-9F180B9A5DE3> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent > 0x7fff8e6f3000 - 0x7fff8e705ff7 com.apple.MultitouchSupport.framework (245.12 - 245.12) <06CAA8FB-BEC6-3EF1-96FA-3D8A1EEB0959> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport > 0x7fff8e706000 - 0x7fff8e76aff6 com.apple.Heimdal (4.0 - 2.0) <463F41AC-39FF-30FC-B03A-4198E7A9321F> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal > 0x7fff8e76b000 - 0x7fff8e79afd2 libsystem_m.dylib (3047.15) <8A6B4EC2-BB25-342B-B3FE-9585175225B8> /usr/lib/system/libsystem_m.dylib > 0x7fff8e800000 - 0x7fff8e809ff7 com.apple.speech.synthesis.framework (4.5.3 - 4.5.3) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis > 0x7fff8e80a000 - 0x7fff8e815ff7 com.apple.NetAuth (5.0 - 5.0) <64D42204-C075-3440-8C29-BBD68A99A771> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth > 0x7fff8e9bf000 - 0x7fff8e9c1fff com.apple.EFILogin (2.0 - 2) <2A4E94B1-F1A5-36A5-989E-013D646E1CE3> /System/Library/PrivateFrameworks/EFILogin.framework/Versions/A/EFILogin > 0x7fff8e9c2000 - 0x7fff8ea04ff7 libauto.dylib (185.4) <379FBDA3-DB2A-35A3-A637-3893C0F0E52F> /usr/lib/libauto.dylib > 0x7fff8ea05000 - 0x7fff8ea8efe7 libsystem_c.dylib (997) <5BAB0B09-A39E-39B9-9552-48B540B3ABD0> /usr/lib/system/libsystem_c.dylib > 0x7fff8ea8f000 - 0x7fff8ea99ff7 com.apple.CrashReporterSupport (10.9 - 529) /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport > 0x7fff8ea9a000 - 0x7fff8ea9affd libOpenScriptingUtil.dylib (154) <9B8CECA0-360D-3C6D-A37D-95EE34AE2B16> /usr/lib/libOpenScriptingUtil.dylib > 0x7fff8ee6d000 - 0x7fff8f2a0ff7 com.apple.vision.FaceCore (3.0.0 - 3.0.0) <14255DCC-80BD-3690-9269-057D175A9FC5> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore > 0x7fff8f2a1000 - 0x7fff8f2a9ffc libGFXShared.dylib (9.0.74) <13A420C1-1B14-36F8-8F08-4698D423E52F> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib > 0x7fff8f34f000 - 0x7fff8f454fff com.apple.ImageIO.framework (3.2.0 - 1029) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO > 0x7fff8fba5000 - 0x7fff8fe75ff4 com.apple.CoreImage (9.0.33) <8BB17AEC-D09A-3173-8767-7DB5C982670E> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage > 0x7fff9011b000 - 0x7fff90162ff3 libFontRegistry.dylib (121.1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib > 0x7fff9016f000 - 0x7fff901c8ff7 libTIFF.dylib (1029) <12303E45-734B-3D6C-A5C8-1495ECBC0344> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib > 0x7fff901c9000 - 0x7fff9041dff0 com.apple.security (7.0 - 55377) <2F4EFC9E-DD86-32E5-A2CB-E83A5DF34F8F> /System/Library/Frameworks/Security.framework/Versions/A/Security > 0x7fff9045c000 - 0x7fff90461fff libmacho.dylib (845) <0038681B-CEC4-348A-A7B8-4236C701F2F8> /usr/lib/system/libmacho.dylib > 0x7fff90462000 - 0x7fff90469ff3 libcopyfile.dylib (103) <54DD5730-3F05-3F18-B55C-24EA9546286F> /usr/lib/system/libcopyfile.dylib > 0x7fff9046a000 - 0x7fff9046cff3 libsystem_configuration.dylib (596.1) <1E0FDEA3-8822-3E80-AA0D-57D0F4E30E2E> /usr/lib/system/libsystem_configuration.dylib > 0x7fff90481000 - 0x7fff905efff7 libBLAS.dylib (1094.4) <80E99B02-BD2D-3D88-97B6-0BE2D8973633> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib > 0x7fff90622000 - 0x7fff90633fff libsystem_asl.dylib (217) /usr/lib/system/libsystem_asl.dylib > 0x7fff90637000 - 0x7fff90652ff7 libPng.dylib (1029) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib > 0x7fff90653000 - 0x7fff906caff7 com.apple.CoreServices.OSServices (600 - 600) <73820122-62D4-359C-9312-CD49FCEDFE09> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices > 0x7fff906cb000 - 0x7fff906faff5 com.apple.GSS (4.0 - 2.0) <6765C9D7-8AC9-3694-B5D4-5C26B119851D> /System/Library/Frameworks/GSS.framework/Versions/A/GSS > 0x7fff906fb000 - 0x7fff9070bffb libsasl2.2.dylib (169) <4DB6E107-D03E-3EC2-BCD2-80483FAC3FFF> /usr/lib/libsasl2.2.dylib > 0x7fff9070c000 - 0x7fff9075afff libcorecrypto.dylib (161) <56048D2C-3668-3E15-AF02-5C5A377320F6> /usr/lib/system/libcorecrypto.dylib > 0x7fff90cf4000 - 0x7fff90d01ff0 libbz2.1.0.dylib (29) /usr/lib/libbz2.1.0.dylib > 0x7fff90d02000 - 0x7fff90d2efff com.apple.CoreServicesInternal (184.1 - 184.1) <84F93D96-0544-3377-B7E3-99716DC57A8A> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal > 0x7fff90d5a000 - 0x7fff90d5bff3 libSystem.B.dylib (1197) <7589D08E-9338-3E28-AA74-9734F0D51CE0> /usr/lib/libSystem.B.dylib > 0x7fff90da4000 - 0x7fff90e92fff libJP2.dylib (1029) <720403F5-7863-30D6-AC09-F5A04F069E1B> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib > 0x7fff90e93000 - 0x7fff90e97ff7 libcache.dylib (61) /usr/lib/system/libcache.dylib > 0x7fff90e98000 - 0x7fff90ea1ffe com.apple.CommonAuth (4.0 - 2.0) <3918EBA0-A124-37DC-9BA6-4D1370AF03A8> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth > 0x7fff90ea2000 - 0x7fff90ee0ff7 libGLImage.dylib (9.0.74) <0DD99DA1-A8E7-3309-8DED-A2AB410E59C8> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib > 0x7fff90ef6000 - 0x7fff90f5aff7 com.apple.datadetectorscore (5.0 - 343.0) <7FE14856-0C85-3382-AD6C-1B9E21C276CB> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore > 0x7fff90f5b000 - 0x7fff90fe4ff7 com.apple.ColorSync (4.9.0 - 4.9.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync > 0x7fff90fe5000 - 0x7fff91112ff7 com.apple.desktopservices (1.8 - 1.8) /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv > 0x7fff91113000 - 0x7fff91114fff liblangid.dylib (117) <5146A22B-088F-3D8D-B245-F03DD3CDA2B0> /usr/lib/liblangid.dylib > 0x7fff9117e000 - 0x7fff91244ff7 com.apple.LaunchServices (572.3 - 572.3.1) <39618733-CC97-3991-BD3B-485BD7247115> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices > 0x7fff91245000 - 0x7fff9128aff7 libcurl.4.dylib (78) /usr/lib/libcurl.4.dylib > 0x7fff9142c000 - 0x7fff91f8afff com.apple.AppKit (6.9 - 1240) <53CEC6E0-F928-32EC-919D-B34C0818C88C> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit > 0x7fff91f8b000 - 0x7fff9205cff2 com.apple.DiskImagesFramework (10.9 - 368.1) <2BF556C1-94D9-3816-BDD8-FB152BB7A89A> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages > 0x7fff9205d000 - 0x7fff920b0fff com.apple.ScalableUserInterface (1.0 - 1) /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface > 0x7fff920c5000 - 0x7fff9211cfff com.apple.Symbolication (1.4 - 125) /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication > 0x7fff9211d000 - 0x7fff9211fff7 com.apple.securityhi (9.0 - 55005) <5BFDED08-3282-35B4-A37F-66BF8EAB0C90> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI > 0x7fff92144000 - 0x7fff92151ffc com.apple.Librarian (1.2 - 1) <556E5FA3-4DDB-3B59-ADE8-07411751B667> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian > 0x7fff9215d000 - 0x7fff92315ffb libicucore.A.dylib (511.16) /usr/lib/libicucore.A.dylib > 0x7fff926ea000 - 0x7fff926ecfff libRadiance.dylib (1029) <4E13C7E9-9B17-33D3-9142-B645B5BBCCD6> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib > 0x7fff9276f000 - 0x7fff92771ff7 libquarantine.dylib (69) <1776AABC-F1D7-3CB0-B698-B0C70D4E535B> /usr/lib/system/libquarantine.dylib > 0x7fff92772000 - 0x7fff9278aff3 com.apple.openscripting (1.4 - 154) <1C16D0EF-C8D8-3D43-8155-F86968505E79> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting > 0x7fff9278b000 - 0x7fff92794ff3 libsystem_notify.dylib (121) /usr/lib/system/libsystem_notify.dylib > 0x7fff92795000 - 0x7fff927b7fff libxpc.dylib (300.1.4) <4F832032-9709-3E80-91C4-71914C67A32B> /usr/lib/system/libxpc.dylib > 0x7fff927b8000 - 0x7fff927ffff7 libcups.2.dylib (365) <49F3E642-D748-3A60-AF51-F9E90F65C543> /usr/lib/libcups.2.dylib > 0x7fff92800000 - 0x7fff9284dff2 com.apple.print.framework.PrintCore (9.0 - 424) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore > 0x7fff9284e000 - 0x7fff92873ff7 com.apple.ChunkingLibrary (2.0 - 154) /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary > 0x7fff92908000 - 0x7fff9290efff com.apple.AOSNotification (1.7.0 - 760) /System/Library/PrivateFrameworks/AOSNotification.framework/Versions/A/AOSNotification > 0x7fff9293e000 - 0x7fff92946fff libsystem_dnssd.dylib (522.1.3) <29695A12-75FC-36EE-97AC-179F6E9DA419> /usr/lib/system/libsystem_dnssd.dylib > 0x7fff92e6b000 - 0x7fff92e7cff7 libz.1.dylib (53) <372E2641-66CA-3B13-8BE6-3A4335F861A6> /usr/lib/libz.1.dylib > 0x7fff92e7d000 - 0x7fff92e82ff7 libunwind.dylib (35.3) <838CE69D-44F1-305C-8FA5-5E439D217F78> /usr/lib/system/libunwind.dylib > 0x7fff92e83000 - 0x7fff930c0ffb com.apple.RawCamera.bundle (4.06 - 695) /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera > 0x7fff931f7000 - 0x7fff931f7fff com.apple.Carbon (154 - 157) <382844CD-59CB-3D50-83BF-35FC73D02C03> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon > 0x7fff93251000 - 0x7fff93342ff9 libiconv.2.dylib (41) /usr/lib/libiconv.2.dylib > 0x7fff93369000 - 0x7fff93371ff7 com.apple.speech.recognition.framework (4.2.4 - 4.2.4) <1CE37DE8-BA4A-30CD-A802-18DAF42C328F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition > 0x7fff934c3000 - 0x7fff934c3fff com.apple.Accelerate.vecLib (3.9 - vecLib 3.9) <349BA8B4-1C72-30BE-B2BB-1898F51B9B5E> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib > 0x7fff934c8000 - 0x7fff934d5ff7 libxar.1.dylib (202) /usr/lib/libxar.1.dylib > 0x7fff9386f000 - 0x7fff93897ffb libxslt.1.dylib (13) <33D39746-6FCD-3F32-AFAE-2E45232BF6FB> /usr/lib/libxslt.1.dylib > 0x7fff93922000 - 0x7fff93926ff7 libGIF.dylib (1029) <000B8500-FC82-3016-8E59-9FA0D6395F04> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib > 0x7fff93927000 - 0x7fff93975ff9 libstdc++.6.dylib (60) /usr/lib/libstdc++.6.dylib > 0x7fff93976000 - 0x7fff93981fff libkxld.dylib (2422.1.26.0.1) /usr/lib/system/libkxld.dylib > 0x7fff93982000 - 0x7fff9398dfff libGL.dylib (9.0.74) <2DB19533-5983-3F59-93F3-2761DA6EEDA5> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib > 0x7fff9398e000 - 0x7fff93b3bf8f libobjc.A.dylib (551) <853FA2C9-7BF1-3962-896E-6367F99FD358> /usr/lib/libobjc.A.dylib > 0x7fff93b3c000 - 0x7fff93b3ffff libsystem_stats.dylib (93.1.8.1.1) /usr/lib/system/libsystem_stats.dylib > 0x7fff93b40000 - 0x7fff93b50fff libbsm.0.dylib (33) <65C2FC5C-4B4B-3C1B-B935-D67A3BF96A79> /usr/lib/libbsm.0.dylib > 0x7fff93b60000 - 0x7fff93b6cff3 com.apple.AppleFSCompression (56 - 1.0) /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression > 0x7fff93b70000 - 0x7fff93b89ff7 com.apple.Kerberos (3.0 - 1) <13DDC487-95C0-379F-BD7F-E0FC5F5922D3> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos > 0x7fff93ed4000 - 0x7fff93eeefff libdispatch.dylib (339.1.2) /usr/lib/system/libdispatch.dylib > 0x7fff93f3c000 - 0x7fff93f3cfff com.apple.ApplicationServices (48 - 48) <21188B7D-50E8-3C28-A15E-5345AE7BAFBB> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices > > External Modification Summary: > Calls made by other processes targeting this process: > task_for_pid: 1 > thread_create: 0 > thread_set_state: 0 > Calls made by this process: > task_for_pid: 0 > thread_create: 0 > thread_set_state: 0 > Calls made by all processes on this machine: > task_for_pid: 6269 > thread_create: 0 > thread_set_state: 0 > > VM Region Summary: > ReadOnly portion of Libraries: Total=174.3M resident=68.1M(39%) swapped_out_or_unallocated=106.2M(61%) > Writable regions: Total=754.9M written=50.8M(7%) resident=54.8M(7%) swapped_out=0K(0%) unallocated=700.1M(93%) > > REGION TYPE VIRTUAL > =========== ======= > CG backing stores 1204K > CG image 1040K > CG raster data 12K > CG shared images 180K > CoreServices 1364K > Image IO 64K > Kernel Alloc Once 8K > MALLOC 62.9M > MALLOC (admin) 32K > Memory Tag 242 12K > Memory Tag 251 36K > STACK GUARD 56.1M > Stack 26.2M > VM_ALLOCATE 104.0M > VM_ALLOCATE (reserved) 557.2M reserved VM address space (unallocated) > __DATA 22.5M > __IMAGE 528K > __LINKEDIT 68.1M > __TEXT 106.2M > __UNICODE 544K > mapped file 52.5M > shared memory 4K > =========== ======= > TOTAL 1.0G > TOTAL, minus reserved VM space 503.4M > > > Model: VMware7,1, BootROM VMW71.00V.0.B64.1206270404, 4 processors, 3.23 GHz, 4 GB, SMC 1.16f8 > Graphics: Display, PCI, 128 MB > Memory Module: RAM slot #0/RAM slot #0, 4 GB, DRAM, 0 MHz, VMware Virtual RAM, VMW-4096MB > Bluetooth: Version 4.2.0b11 12562, 3 services, 20 devices, 3 incoming serial ports > Network Service: Ethernet, Ethernet, en0 > SCSI Device: SCSI Target Device @ 0 > SCSI Device: SCSI Target Device @ 0 > USB Device: VMware Virtual USB Hub > USB Device: Virtual Bluetooth Adapter > USB Device: VMware Virtual USB Keyboard > USB Device: VMware Virtual USB Mouse > Thunderbolt Bus: > > > From anthony.petrov at oracle.com Tue Jul 2 07:36:49 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 02 Jul 2013 18:36:49 +0400 Subject: Crash in liblwawt.dylib on OS X 10.9 In-Reply-To: <51D2D5A7.7050706@oracle.com> References: <7ACF7412-B58F-4614-AE50-AD45EDB350FB@censhare.de> <51D2D5A7.7050706@oracle.com> Message-ID: <51D2E581.6040609@oracle.com> A small typo in the url: http://bugs.sun.com/ is the correct one. -- best regards, Anthony On 07/02/2013 05:29 PM, Anthony Petrov wrote: > Hi Christof, > > Please file a bug at http://bug.sun.com/ and provide a reproducible test > case/instructions in your bug report. > > -- > best regards, > Anthony > > On 07/02/2013 05:00 PM, Christof Aenderl wrote: >> Hi, >> >> concerning a fixed bug: >> http://bugs.sun.com/view_bug.do?bug_id=7152608 >> >> I found the same problem on the OS X 10.9 DP2 with Java 7_25: >> >> --------------------------------------------------------------- >> Process: JavaAppLauncher [2333] >> Path: /Users/USER/Documents/*/censhare >> Client.app/Contents/MacOS/JavaAppLauncher >> Identifier: com.censhare.javaclient >> Version: 4.7.8 (1.0) >> Code Type: X86-64 (Native) >> Parent Process: launchd [152] >> Responsible: JavaAppLauncher [2333] >> User ID: 501 >> >> Date/Time: 2013-07-01 22:22:18.259 +0200 >> OS Version: Mac OS X 10.9 (13A497d) >> Report Version: 11 >> >> Crashed Thread: 23 Java: Java2D Queue Flusher >> >> Exception Type: EXC_BAD_ACCESS (SIGABRT) >> Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 >> >> VM Regions Near 0: >> --> >> __TEXT 00000001052e6000-00000001052e9000 [ 12K] >> r-x/rwx SM=COW /Users/USER/Documents/*/censhare >> Client.app/Contents/MacOS/JavaAppLauncher >> >> Application Specific Information: >> abort() called >> >> Thread 0:: Dispatch queue: com.apple.main-thread >> 0 libsystem_kernel.dylib 0x00007fff8a0aba66 mach_msg_trap >> + 10 >> 1 libsystem_kernel.dylib 0x00007fff8a0aad64 mach_msg + 64 >> 2 com.apple.CoreFoundation 0x00007fff8e4ba6f5 >> __CFRunLoopServiceMachPort + 181 >> 3 com.apple.CoreFoundation 0x00007fff8e4c0989 >> __CFRunLoopRun + 1497 >> 4 com.apple.CoreFoundation 0x00007fff8e4bffc3 >> CFRunLoopRunSpecific + 467 >> 5 com.apple.HIToolbox 0x00007fff86b0ab11 >> RunCurrentEventLoopInMode + 226 >> 6 com.apple.HIToolbox 0x00007fff86b0a8b4 >> ReceiveNextEventCommon + 479 >> 7 com.apple.HIToolbox 0x00007fff86c1e8e9 >> _BlockUntilNextEventMatchingListInModeWithFilter + 65 >> 8 com.apple.AppKit 0x00007fff9156204e _DPSNextEvent >> + 1434 >> 9 com.apple.AppKit 0x00007fff9156169b >> -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122 >> 10 libosxapp.dylib 0x000000012f38ab56 >> -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 >> 11 com.apple.AppKit 0x00007fff9179376f >> -[NSApplication _realDoModalLoop:peek:] + 620 >> 12 com.apple.AppKit 0x00007fff91793a4b >> -[NSApplication runModalForWindow:] + 117 >> 13 com.apple.AppKit 0x00007fff9178479d -[NSAlert >> runModal] + 145 >> 14 com.apple.AppKit 0x00007fff91d551d9 >> __55-[NSPersistentUIRestorer >> promptToIgnorePersistentState]_block_invoke + 1054 >> 15 com.apple.AppKit 0x00007fff914c5778 >> -[NSApplication >> _suppressFinishLaunchingFromEventHandlersWhilePerformingBlock:] + 28 >> 16 com.apple.AppKit 0x00007fff91d54d7f >> -[NSPersistentUIRestorer promptToIgnorePersistentState] + 213 >> 17 com.apple.AppKit 0x00007fff914c5753 >> -[NSPersistentUIManager promptToIgnorePersistentState] + 28 >> 18 com.apple.AppKit 0x00007fff91565f64 >> -[NSApplication >> _reopenWindowsAsNecessaryIncludingRestorableState:registeringAsReady:completionHandler:] >> + 252 >> 19 com.apple.AppKit 0x00007fff91565d39 >> -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 557 >> 20 com.apple.AppKit 0x00007fff9156585b >> -[NSApplication(NSAppleEventHandling) >> _handleCoreEvent:withReplyEvent:] + 242 >> 21 com.apple.Foundation 0x00007fff87aa709a >> -[NSAppleEventManager >> dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 294 >> 22 com.apple.Foundation 0x00007fff87aa6f0d >> _NSAppleEventManagerGenericHandler + 106 >> 23 com.apple.AE 0x00007fff896a9b7f >> aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned >> char*) + 381 >> 24 com.apple.AE 0x00007fff896a9992 >> dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 31 >> 25 com.apple.AE 0x00007fff896a9856 >> aeProcessAppleEvent + 315 >> 26 com.apple.HIToolbox 0x00007fff86b1420e >> AEProcessAppleEvent + 56 >> 27 com.apple.AppKit 0x00007fff91561eb6 _DPSNextEvent >> + 1026 >> 28 com.apple.AppKit 0x00007fff9156169b >> -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122 >> 29 libosxapp.dylib 0x000000012f38ab56 >> -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 >> 30 com.apple.AppKit 0x00007fff915598ec >> -[NSApplication run] + 553 >> 31 libosxapp.dylib 0x000000012f38a9b9 >> +[NSApplicationAWT runAWTLoopWithApp:] + 156 >> 32 libsplashscreen.dylib 0x000000012f341996 >> __SplashInitPlatform_block_invoke_1 + 86 >> 33 libdispatch.dylib 0x00007fff93ed86d0 >> _dispatch_call_block_and_release + 12 >> 34 libdispatch.dylib 0x00007fff93ed5984 >> _dispatch_client_callout + 8 >> 35 libdispatch.dylib 0x00007fff93ed96a1 >> _dispatch_main_queue_callback_4CF + 333 >> 36 com.apple.CoreFoundation 0x00007fff8e5884a9 >> __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 >> 37 com.apple.CoreFoundation 0x00007fff8e4c0ae4 >> __CFRunLoopRun + 1844 >> 38 com.apple.CoreFoundation 0x00007fff8e4bffc3 >> CFRunLoopRunSpecific + 467 >> 39 libjli.dylib 0x000000010535f88d >> CreateExecutionEnvironment + 871 >> 40 libjli.dylib 0x000000010535a03c JLI_Launch + >> 1952 >> 41 com.censhare.javaclient 0x00000001052e8948 launch + 4776 >> 42 com.censhare.javaclient 0x00000001052e7556 main + 102 >> 43 com.censhare.javaclient 0x00000001052e74e4 start + 52 >> >> Thread 1:: Dispatch queue: com.apple.libdispatch-manager >> 0 libsystem_kernel.dylib 0x00007fff8a0b0692 kevent64 + 10 >> 1 libdispatch.dylib 0x00007fff93ed7ac1 >> _dispatch_mgr_invoke + 239 >> 2 libdispatch.dylib 0x00007fff93ed79c2 >> _dispatch_mgr_thread + 52 >> >> Thread 2: >> 0 libsystem_kernel.dylib 0x00007fff8a0afa6a >> __semwait_signal + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a564830 pthread_join >> + 430 >> 2 libjli.dylib 0x000000010535ee8d >> ContinueInNewThread0 + 102 >> 3 libjli.dylib 0x000000010535aca7 >> ContinueInNewThread + 201 >> 4 libjli.dylib 0x000000010535ebf0 JVMInit + 251 >> 5 libjli.dylib 0x000000010535aa25 JLI_Launch + >> 4489 >> 6 com.censhare.javaclient 0x00000001052e8948 launch + 4776 >> 7 com.censhare.javaclient 0x00000001052e7556 main + 102 >> 8 libjli.dylib 0x000000010535f51f apple_main + 92 >> 9 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 10 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 11 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 3: >> 0 libsystem_kernel.dylib 0x00007fff8a0af746 >> __psynch_cvwait + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a562c7b >> _pthread_cond_wait + 727 >> 2 libjvm.dylib 0x00000001057ff98b >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x00000001057fa109 >> ObjectMonitor::wait(long long, bool, Thread*) + 627 >> 4 libjvm.dylib 0x0000000105897407 >> ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 >> 5 libjvm.dylib 0x0000000105710723 >> JVM_MonitorWait + 156 >> 6 ??? 0x0000000106056f90 0 + 4395986832 >> 7 ??? 0x000000010604b158 0 + 4395938136 >> 8 ??? 0x000000010604b158 0 + 4395938136 >> 9 ??? 0x000000010604b158 0 + 4395938136 >> 10 ??? 0x000000010604b158 0 + 4395938136 >> 11 ??? 0x000000010604b158 0 + 4395938136 >> 12 ??? 0x000000010604b333 0 + 4395938611 >> 13 ??? 0x000000010604b158 0 + 4395938136 >> 14 ??? 0x000000010604b158 0 + 4395938136 >> 15 ??? 0x00000001060454f7 0 + 4395914487 >> 16 libjvm.dylib 0x00000001056d45c3 >> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 557 >> 17 libjvm.dylib 0x00000001056d4390 >> JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) >> + 40 >> 18 libjvm.dylib 0x0000000105843c06 >> Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool, >> objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 2514 >> 19 libjvm.dylib 0x0000000105843ed9 >> Reflection::invoke_constructor(oopDesc*, objArrayHandle, Thread*) + 417 >> 20 libjvm.dylib 0x0000000105708b0e >> JVM_NewInstanceFromConstructor + 124 >> 21 ??? 0x0000000106056f90 0 + 4395986832 >> 22 ??? 0x000000010604b333 0 + 4395938611 >> 23 ??? 0x000000010604b333 0 + 4395938611 >> 24 ??? 0x000000010604b9e1 0 + 4395940321 >> 25 ??? 0x000000010604b333 0 + 4395938611 >> 26 ??? 0x000000010604b333 0 + 4395938611 >> 27 ??? 0x000000010604b333 0 + 4395938611 >> 28 ??? 0x000000010604b333 0 + 4395938611 >> 29 ??? 0x000000010604b333 0 + 4395938611 >> 30 ??? 0x000000010604b333 0 + 4395938611 >> 31 ??? 0x000000010604b333 0 + 4395938611 >> 32 ??? 0x000000010604b158 0 + 4395938136 >> 33 ??? 0x00000001060454f7 0 + 4395914487 >> 34 libjvm.dylib 0x00000001056d45c3 >> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 557 >> 35 libjvm.dylib 0x00000001056d4390 >> JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) >> + 40 >> 36 libjvm.dylib 0x000000010570fa8f >> JVM_DoPrivileged + 1037 >> 37 ??? 0x0000000106056f90 0 + 4395986832 >> 38 ??? 0x000000010604b333 0 + 4395938611 >> 39 ??? 0x000000010604b158 0 + 4395938136 >> 40 ??? 0x000000010604b158 0 + 4395938136 >> 41 ??? 0x000000010604b158 0 + 4395938136 >> 42 ??? 0x000000010604b158 0 + 4395938136 >> 43 ??? 0x00000001060454f7 0 + 4395914487 >> 44 libjvm.dylib 0x00000001056d45c3 >> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 557 >> 45 libjvm.dylib 0x00000001056d4390 >> JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) >> + 40 >> 46 libjvm.dylib 0x00000001056efe70 >> jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, >> _jmethodID*, JNI_ArgumentPusher*, Thread*) + 219 >> 47 libjvm.dylib 0x00000001056e91c8 >> jni_CallStaticVoidMethod + 267 >> 48 libjli.dylib 0x000000010535b5de JavaMain + 2333 >> 49 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 50 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 51 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 4: >> 0 libsystem_kernel.dylib 0x00007fff8a0af746 >> __psynch_cvwait + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a562c7b >> _pthread_cond_wait + 727 >> 2 libjvm.dylib 0x0000000105800af7 >> os::PlatformEvent::park(long long) + 385 >> 3 libjvm.dylib 0x00000001057e3402 >> Monitor::IWait(Thread*, long long) + 160 >> 4 libjvm.dylib 0x00000001057e365f >> Monitor::wait(bool, long, bool) + 375 >> 5 libjvm.dylib 0x00000001058f7b00 >> VMThread::loop() + 444 >> 6 libjvm.dylib 0x00000001058f761b >> VMThread::run() + 121 >> 7 libjvm.dylib 0x00000001058035f9 >> java_start(Thread*) + 173 >> 8 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 9 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 10 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 5:: Java: Reference Handler >> 0 libsystem_kernel.dylib 0x00007fff8a0af746 >> __psynch_cvwait + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a562c7b >> _pthread_cond_wait + 727 >> 2 libjvm.dylib 0x00000001057ff98b >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x00000001057fa109 >> ObjectMonitor::wait(long long, bool, Thread*) + 627 >> 4 libjvm.dylib 0x0000000105897407 >> ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 >> 5 libjvm.dylib 0x0000000105710723 >> JVM_MonitorWait + 156 >> 6 ??? 0x0000000106056f90 0 + 4395986832 >> 7 ??? 0x000000010604b158 0 + 4395938136 >> 8 ??? 0x000000010604b158 0 + 4395938136 >> 9 ??? 0x00000001060454f7 0 + 4395914487 >> 10 libjvm.dylib 0x00000001056d45c3 >> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 557 >> 11 libjvm.dylib 0x00000001056d4aa2 >> JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, >> JavaCallArguments*, Thread*) + 258 >> 12 libjvm.dylib 0x00000001056d4bdc >> JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, >> Symbol*, Thread*) + 74 >> 13 libjvm.dylib 0x000000010570b868 >> thread_entry(JavaThread*, Thread*) + 173 >> 14 libjvm.dylib 0x00000001058c6bd8 >> JavaThread::thread_main_inner() + 134 >> 15 libjvm.dylib 0x00000001058c80ca >> JavaThread::run() + 440 >> 16 libjvm.dylib 0x00000001058035f9 >> java_start(Thread*) + 173 >> 17 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 18 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 19 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 6:: Java: Finalizer >> 0 libsystem_kernel.dylib 0x00007fff8a0af746 >> __psynch_cvwait + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a562c7b >> _pthread_cond_wait + 727 >> 2 libjvm.dylib 0x00000001057ff98b >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x00000001057fa109 >> ObjectMonitor::wait(long long, bool, Thread*) + 627 >> 4 libjvm.dylib 0x0000000105897407 >> ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 >> 5 libjvm.dylib 0x0000000105710723 >> JVM_MonitorWait + 156 >> 6 ??? 0x0000000106056f90 0 + 4395986832 >> 7 ??? 0x000000010604b158 0 + 4395938136 >> 8 ??? 0x000000010604b333 0 + 4395938611 >> 9 ??? 0x000000010604b333 0 + 4395938611 >> 10 ??? 0x00000001060454f7 0 + 4395914487 >> 11 libjvm.dylib 0x00000001056d45c3 >> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 557 >> 12 libjvm.dylib 0x00000001056d4aa2 >> JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, >> JavaCallArguments*, Thread*) + 258 >> 13 libjvm.dylib 0x00000001056d4bdc >> JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, >> Symbol*, Thread*) + 74 >> 14 libjvm.dylib 0x000000010570b868 >> thread_entry(JavaThread*, Thread*) + 173 >> 15 libjvm.dylib 0x00000001058c6bd8 >> JavaThread::thread_main_inner() + 134 >> 16 libjvm.dylib 0x00000001058c80ca >> JavaThread::run() + 440 >> 17 libjvm.dylib 0x00000001058035f9 >> java_start(Thread*) + 173 >> 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 19 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 7: >> 0 libsystem_kernel.dylib 0x00007fff8a0afe9a >> __workq_kernreturn + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a561f4e >> _pthread_wqthread + 324 >> 2 libsystem_pthread.dylib 0x00007fff8a564fd9 >> start_wqthread + 13 >> >> Thread 8: >> 0 libsystem_kernel.dylib 0x00007fff8a0afe9a >> __workq_kernreturn + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a561f4e >> _pthread_wqthread + 324 >> 2 libsystem_pthread.dylib 0x00007fff8a564fd9 >> start_wqthread + 13 >> >> Thread 9:: Java: Signal Dispatcher >> 0 libsystem_kernel.dylib 0x00007fff8a0abaa2 >> semaphore_wait_trap + 10 >> 1 libjvm.dylib 0x0000000105801e57 >> check_pending_signals(bool) + 128 >> 2 libjvm.dylib 0x00000001057fe994 >> signal_thread_entry(JavaThread*, Thread*) + 57 >> 3 libjvm.dylib 0x00000001058c6bd8 >> JavaThread::thread_main_inner() + 134 >> 4 libjvm.dylib 0x00000001058c80ca >> JavaThread::run() + 440 >> 5 libjvm.dylib 0x00000001058035f9 >> java_start(Thread*) + 173 >> 6 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 7 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 8 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 10:: Java: C2 CompilerThread0 >> 0 libsystem_kernel.dylib 0x00007fff8a0af746 >> __psynch_cvwait + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a562c7b >> _pthread_cond_wait + 727 >> 2 libjvm.dylib 0x00000001057ff98b >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x00000001057e2c10 >> ParkCommon(ParkEvent*, long long) + 42 >> 4 libjvm.dylib 0x00000001057e3402 >> Monitor::IWait(Thread*, long long) + 160 >> 5 libjvm.dylib 0x00000001057e35c6 >> Monitor::wait(bool, long, bool) + 222 >> 6 libjvm.dylib 0x00000001055d2281 >> CompileQueue::get() + 153 >> 7 libjvm.dylib 0x00000001055d2da2 >> CompileBroker::compiler_thread_loop() + 410 >> 8 libjvm.dylib 0x00000001058c6bd8 >> JavaThread::thread_main_inner() + 134 >> 9 libjvm.dylib 0x00000001058c80ca >> JavaThread::run() + 440 >> 10 libjvm.dylib 0x00000001058035f9 >> java_start(Thread*) + 173 >> 11 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 12 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 13 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 11:: Java: C2 CompilerThread1 >> 0 libsystem_kernel.dylib 0x00007fff8a0af746 >> __psynch_cvwait + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a562c7b >> _pthread_cond_wait + 727 >> 2 libjvm.dylib 0x00000001057ff98b >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x00000001057e2c10 >> ParkCommon(ParkEvent*, long long) + 42 >> 4 libjvm.dylib 0x00000001057e3402 >> Monitor::IWait(Thread*, long long) + 160 >> 5 libjvm.dylib 0x00000001057e35c6 >> Monitor::wait(bool, long, bool) + 222 >> 6 libjvm.dylib 0x00000001055d2281 >> CompileQueue::get() + 153 >> 7 libjvm.dylib 0x00000001055d2da2 >> CompileBroker::compiler_thread_loop() + 410 >> 8 libjvm.dylib 0x00000001058c6bd8 >> JavaThread::thread_main_inner() + 134 >> 9 libjvm.dylib 0x00000001058c80ca >> JavaThread::run() + 440 >> 10 libjvm.dylib 0x00000001058035f9 >> java_start(Thread*) + 173 >> 11 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 12 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 13 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 12:: Java: Service Thread >> 0 libsystem_kernel.dylib 0x00007fff8a0af746 >> __psynch_cvwait + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a562c7b >> _pthread_cond_wait + 727 >> 2 libjvm.dylib 0x00000001057ff98b >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x00000001057e2c10 >> ParkCommon(ParkEvent*, long long) + 42 >> 4 libjvm.dylib 0x00000001057e3402 >> Monitor::IWait(Thread*, long long) + 160 >> 5 libjvm.dylib 0x00000001057e365f >> Monitor::wait(bool, long, bool) + 375 >> 6 libjvm.dylib 0x0000000105852249 >> ServiceThread::service_thread_entry(JavaThread*, Thread*) + 109 >> 7 libjvm.dylib 0x00000001058c6bd8 >> JavaThread::thread_main_inner() + 134 >> 8 libjvm.dylib 0x00000001058c80ca >> JavaThread::run() + 440 >> 9 libjvm.dylib 0x00000001058035f9 >> java_start(Thread*) + 173 >> 10 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 11 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 12 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 13: >> 0 libsystem_kernel.dylib 0x00007fff8a0af746 >> __psynch_cvwait + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a562c7b >> _pthread_cond_wait + 727 >> 2 libjvm.dylib 0x0000000105800af7 >> os::PlatformEvent::park(long long) + 385 >> 3 libjvm.dylib 0x00000001058c7d06 >> WatcherThread::run() + 328 >> 4 libjvm.dylib 0x00000001058035f9 >> java_start(Thread*) + 173 >> 5 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 6 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 7 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 14: >> 0 libsystem_kernel.dylib 0x00007fff8a0b09aa poll + 10 >> 1 libsplashscreen.dylib 0x000000012f34281c >> SplashEventLoop + 220 >> 2 libsplashscreen.dylib 0x000000012f342b9e >> SplashScreenThread + 574 >> 3 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 4 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 5 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 15: >> 0 libsystem_kernel.dylib 0x00007fff8a0afe9a >> __workq_kernreturn + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a561f4e >> _pthread_wqthread + 324 >> 2 libsystem_pthread.dylib 0x00007fff8a564fd9 >> start_wqthread + 13 >> >> Thread 16: >> 0 libsystem_kernel.dylib 0x00007fff8a0afe9a >> __workq_kernreturn + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a561f4e >> _pthread_wqthread + 324 >> 2 libsystem_pthread.dylib 0x00007fff8a564fd9 >> start_wqthread + 13 >> >> Thread 17: >> 0 libsystem_kernel.dylib 0x00007fff8a0afe9a >> __workq_kernreturn + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a561f4e >> _pthread_wqthread + 324 >> 2 libsystem_pthread.dylib 0x00007fff8a564fd9 >> start_wqthread + 13 >> >> Thread 18:: Java: ActiveActionsRegistryThread >> 0 libsystem_kernel.dylib 0x00007fff8a0af746 >> __psynch_cvwait + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a562c7b >> _pthread_cond_wait + 727 >> 2 libjvm.dylib 0x0000000105800af7 >> os::PlatformEvent::park(long long) + 385 >> 3 libjvm.dylib 0x00000001057fa113 >> ObjectMonitor::wait(long long, bool, Thread*) + 637 >> 4 libjvm.dylib 0x0000000105897407 >> ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 >> 5 libjvm.dylib 0x0000000105710723 >> JVM_MonitorWait + 156 >> 6 ??? 0x0000000106056f90 0 + 4395986832 >> 7 ??? 0x000000010604b158 0 + 4395938136 >> 8 ??? 0x000000010604b158 0 + 4395938136 >> 9 ??? 0x000000010604b806 0 + 4395939846 >> 10 ??? 0x00000001060454f7 0 + 4395914487 >> 11 libjvm.dylib 0x00000001056d45c3 >> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 557 >> 12 libjvm.dylib 0x00000001056d4aa2 >> JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, >> JavaCallArguments*, Thread*) + 258 >> 13 libjvm.dylib 0x00000001056d4bdc >> JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, >> Symbol*, Thread*) + 74 >> 14 libjvm.dylib 0x000000010570b868 >> thread_entry(JavaThread*, Thread*) + 173 >> 15 libjvm.dylib 0x00000001058c6bd8 >> JavaThread::thread_main_inner() + 134 >> 16 libjvm.dylib 0x00000001058c80ca >> JavaThread::run() + 440 >> 17 libjvm.dylib 0x00000001058035f9 >> java_start(Thread*) + 173 >> 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 19 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 19:: Java: TaskScheduler-no-EDT >> 0 libsystem_kernel.dylib 0x00007fff8a0af746 >> __psynch_cvwait + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a562c7b >> _pthread_cond_wait + 727 >> 2 libjvm.dylib 0x00000001057ff98b >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x00000001057fa109 >> ObjectMonitor::wait(long long, bool, Thread*) + 627 >> 4 libjvm.dylib 0x0000000105897407 >> ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 >> 5 libjvm.dylib 0x0000000105710723 >> JVM_MonitorWait + 156 >> 6 ??? 0x0000000106056f90 0 + 4395986832 >> 7 ??? 0x000000010604b158 0 + 4395938136 >> 8 ??? 0x000000010604b158 0 + 4395938136 >> 9 ??? 0x000000010604b158 0 + 4395938136 >> 10 ??? 0x00000001060454f7 0 + 4395914487 >> 11 libjvm.dylib 0x00000001056d45c3 >> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 557 >> 12 libjvm.dylib 0x00000001056d4aa2 >> JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, >> JavaCallArguments*, Thread*) + 258 >> 13 libjvm.dylib 0x00000001056d4bdc >> JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, >> Symbol*, Thread*) + 74 >> 14 libjvm.dylib 0x000000010570b868 >> thread_entry(JavaThread*, Thread*) + 173 >> 15 libjvm.dylib 0x00000001058c6bd8 >> JavaThread::thread_main_inner() + 134 >> 16 libjvm.dylib 0x00000001058c80ca >> JavaThread::run() + 440 >> 17 libjvm.dylib 0x00000001058035f9 >> java_start(Thread*) + 173 >> 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 19 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 20:: com.apple.appkit-heartbeat >> 0 com.apple.AppKit 0x00007fff915321d5 >> -[NSView(NSPrivateHLTBSupport) _boundToHIView] + 17 >> 1 com.apple.AppKit 0x00007fff91532144 -[NSView >> visibleRect] + 227 >> 2 com.apple.AppKit 0x00007fff91752df9 >> -[NSWindow(NSWindow_Theme) heartBeat:] + 236 >> 3 com.apple.AppKit 0x00007fff9172cfad >> -[NSUIHeartBeat _heartBeatThread:] + 868 >> 4 com.apple.Foundation 0x00007fff87ad6fcc >> __NSThread__main__ + 1318 >> 5 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 6 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 7 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 21:: Java: AWT-Shutdown >> 0 libsystem_kernel.dylib 0x00007fff8a0af746 >> __psynch_cvwait + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a562c7b >> _pthread_cond_wait + 727 >> 2 libjvm.dylib 0x00000001057ff98b >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x00000001057fa109 >> ObjectMonitor::wait(long long, bool, Thread*) + 627 >> 4 libjvm.dylib 0x0000000105897407 >> ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 >> 5 libjvm.dylib 0x0000000105710723 >> JVM_MonitorWait + 156 >> 6 ??? 0x0000000106056f90 0 + 4395986832 >> 7 ??? 0x000000010604b158 0 + 4395938136 >> 8 ??? 0x000000010604b158 0 + 4395938136 >> 9 ??? 0x000000010604b806 0 + 4395939846 >> 10 ??? 0x00000001060454f7 0 + 4395914487 >> 11 libjvm.dylib 0x00000001056d45c3 >> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 557 >> 12 libjvm.dylib 0x00000001056d4aa2 >> JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, >> JavaCallArguments*, Thread*) + 258 >> 13 libjvm.dylib 0x00000001056d4bdc >> JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, >> Symbol*, Thread*) + 74 >> 14 libjvm.dylib 0x000000010570b868 >> thread_entry(JavaThread*, Thread*) + 173 >> 15 libjvm.dylib 0x00000001058c6bd8 >> JavaThread::thread_main_inner() + 134 >> 16 libjvm.dylib 0x00000001058c80ca >> JavaThread::run() + 440 >> 17 libjvm.dylib 0x00000001058035f9 >> java_start(Thread*) + 173 >> 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 19 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 22:: Java: Image Fetcher 0 >> 0 libsystem_kernel.dylib 0x00007fff8a0af746 >> __psynch_cvwait + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a562c7b >> _pthread_cond_wait + 727 >> 2 libjvm.dylib 0x0000000105800af7 >> os::PlatformEvent::park(long long) + 385 >> 3 libjvm.dylib 0x00000001057fa113 >> ObjectMonitor::wait(long long, bool, Thread*) + 637 >> 4 libjvm.dylib 0x0000000105897407 >> ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 >> 5 libjvm.dylib 0x0000000105710723 >> JVM_MonitorWait + 156 >> 6 ??? 0x0000000106056f90 0 + 4395986832 >> 7 ??? 0x000000010604b158 0 + 4395938136 >> 8 ??? 0x000000010604b333 0 + 4395938611 >> 9 ??? 0x000000010604b158 0 + 4395938136 >> 10 ??? 0x00000001060454f7 0 + 4395914487 >> 11 libjvm.dylib 0x00000001056d45c3 >> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 557 >> 12 libjvm.dylib 0x00000001056d4aa2 >> JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, >> JavaCallArguments*, Thread*) + 258 >> 13 libjvm.dylib 0x00000001056d4bdc >> JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, >> Symbol*, Thread*) + 74 >> 14 libjvm.dylib 0x000000010570b868 >> thread_entry(JavaThread*, Thread*) + 173 >> 15 libjvm.dylib 0x00000001058c6bd8 >> JavaThread::thread_main_inner() + 134 >> 16 libjvm.dylib 0x00000001058c80ca >> JavaThread::run() + 440 >> 17 libjvm.dylib 0x00000001058035f9 >> java_start(Thread*) + 173 >> 18 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 19 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 20 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 23 Crashed:: Java: Java2D Queue Flusher >> 0 libsystem_kernel.dylib 0x00007fff8a0af896 >> __pthread_kill + 10 >> 1 libsystem_pthread.dylib 0x00007fff8a5613c5 pthread_kill >> + 92 >> 2 libsystem_c.dylib 0x00007fff8ea61c22 abort + 125 >> 3 libjvm.dylib 0x00000001058030d7 >> os::abort(bool) + 25 >> 4 libjvm.dylib 0x00000001058f2020 >> VMError::report_and_die() + 2306 >> 5 libjvm.dylib 0x00000001058047cb >> JVM_handle_bsd_signal + 1073 >> 6 libsystem_platform.dylib 0x00007fff8a20d80a _sigtramp + 26 >> 7 libGL.dylib 0x00007fff93983fc8 glGetString + 15 >> 8 liblwawt.dylib 0x000000013391a69f >> Java_sun_java2d_opengl_OGLContext_getOGLIdString + 35 >> 9 ??? 0x0000000106056f90 0 + 4395986832 >> 10 ??? 0x000000010604b333 0 + 4395938611 >> 11 ??? 0x000000010604b806 0 + 4395939846 >> 12 ??? 0x00000001060454f7 0 + 4395914487 >> 13 libjvm.dylib 0x00000001056d45c3 >> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 557 >> 14 libjvm.dylib 0x00000001056d4aa2 >> JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, >> JavaCallArguments*, Thread*) + 258 >> 15 libjvm.dylib 0x00000001056d4bdc >> JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, >> Symbol*, Thread*) + 74 >> 16 libjvm.dylib 0x000000010570b868 >> thread_entry(JavaThread*, Thread*) + 173 >> 17 libjvm.dylib 0x00000001058c6bd8 >> JavaThread::thread_main_inner() + 134 >> 18 libjvm.dylib 0x00000001058c80ca >> JavaThread::run() + 440 >> 19 libjvm.dylib 0x00000001058035f9 >> java_start(Thread*) + 173 >> 20 libsystem_pthread.dylib 0x00007fff8a56090f _pthread_body >> + 138 >> 21 libsystem_pthread.dylib 0x00007fff8a5607a0 >> _pthread_start + 131 >> 22 libsystem_pthread.dylib 0x00007fff8a564fe9 thread_start >> + 13 >> >> Thread 23 crashed with X86 Thread State (64-bit): >> rax: 0x0000000000000000 rbx: 0x0000000134733000 rcx: >> 0x0000000134732088 rdx: 0x0000000000000000 >> rdi: 0x0000000000008d07 rsi: 0x0000000000000006 rbp: >> 0x00000001347320b0 rsp: 0x0000000134732088 >> r8: 0x0000000000000040 r9: 0x0000000134732000 r10: >> 0x0000000008000000 r11: 0x0000000000000206 >> r12: 0x0000000105b961f0 r13: 0x0000000129997498 r14: >> 0x0000000000000006 r15: 0x00000001058066bc >> rip: 0x00007fff8a0af896 rfl: 0x0000000000000206 cr2: >> 0x000000010592a000 >> >> Logical CPU: 0 >> Error Code: 0x02000148 >> Trap Number: 133 >> >> >> Binary Images: >> 0x1052e6000 - 0x1052e8ff7 +com.censhare.javaclient >> (4.7.8pre - 1.0) <5A002039-2B05-362A-BD4C-37CA0CD6B136> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/MacOS/JavaAppLauncher >> 0x105358000 - 0x105362fff +libjli.dylib (1) >> <9792ED7A-1BD0-3D84-B551-F5DA12537016> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/jli/libjli.dylib >> >> 0x10544a000 - 0x105ad5fef +libjvm.dylib (1) >> <1B03A29F-0248-337E-8529-87706B48A7DE> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/server/libjvm.dylib >> >> 0x105ff6000 - 0x105ffefff +libverify.dylib (1) >> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libverify.dylib >> >> 0x106003000 - 0x106024fef +libjava.dylib (1) >> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libjava.dylib >> >> 0x10603c000 - 0x106041fff +libzip.dylib (1) >> <89DD8E8C-F4A4-3E92-A2D6-CC8642447AC3> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libzip.dylib >> >> 0x12eb60000 - 0x12eb69ff7 >> com.apple.java.JavaRuntimeSupport (14.8.0 - 14.8.0) >> >> /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/JavaRuntimeSupport >> >> 0x12eb78000 - 0x12eb82fff JavaNativeFoundation (1) >> >> /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation >> >> 0x12eb8d000 - 0x12eb92fff com.apple.JavaVM (14.8.0 - >> 14.8.0) <83C8C2AB-E99D-39FF-80B4-90A7DEB1DAFB> >> /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM >> 0x12eb9a000 - 0x12eb9ffff JavaLaunching (1) >> >> /System/Library/PrivateFrameworks/JavaLaunching.framework/Versions/A/JavaLaunching >> >> 0x12f33a000 - 0x12f379fff +libsplashscreen.dylib (1) >> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libsplashscreen.dylib >> >> 0x12f389000 - 0x12f38ffff +libosxapp.dylib (1) >> <19D025A3-9368-319D-AA64-EF835D78A0FF> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libosxapp.dylib >> >> 0x12f3a5000 - 0x12f3a7fff com.apple.ExceptionHandling >> (1.5 - 10) >> /System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ExceptionHandling >> >> 0x131880000 - 0x131888ffb libCGCMS.A.dylib (565) >> <978DCDAA-A34D-3223-A362-9A51E3697D93> >> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGCMS.A.dylib >> >> 0x1319b8000 - 0x1319e1ffb libRIP.A.dylib (565) >> <7A4FA177-8BCD-3A95-A577-57B079C8C9D2> >> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib >> >> 0x131cd2000 - 0x131cd5ffa libCGXType.A.dylib (565) >> <6EF5CFC1-05F8-3E78-86D5-AD5659D92642> >> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib >> >> 0x13379a000 - 0x133806ff7 +libawt.dylib (1) >> <614FC193-CE14-3B85-9F8B-33F92FBD6D92> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libawt.dylib >> >> 0x13384a000 - 0x13390ffff +libmlib_image.dylib (1) >> <95F6D0B2-3A92-305F-A6AE-822BC990901B> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libmlib_image.dylib >> >> 0x133916000 - 0x133986ff7 +liblwawt.dylib (1) >> <8004F9F2-4EDF-3FF4-8B40-12F06C5C97FA> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/lwawt/liblwawt.dylib >> >> 0x1341cd000 - 0x13420efff +libfontmanager.dylib (1) >> <63A05734-9483-3B12-BAB0-E1EB020C1A32> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libfontmanager.dylib >> >> 0x1344b5000 - 0x1344b9fff +libosxui.dylib (1) >> <56D2A1A1-1532-3AF5-98CC-0A3BE7B986B7> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libosxui.dylib >> >> 0x1344be000 - 0x1344c6fff +libnio.dylib (1) >> <4E9F4A0E-BC84-31E8-AB60-3F9F37B08B00> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libnio.dylib >> >> 0x1344cd000 - 0x1344dbff7 +libnet.dylib (1) >> <6A30865D-EBB7-3D91-921C-7A3E0416E481> >> /Users/USER/Documents/*/censhare >> Client.app/Contents/PlugIns/jdk1.7.0_25.jdk/Contents/Home/jre/lib/libnet.dylib >> >> 0x134735000 - 0x1348c5fff GLEngine (9.0.74) >> <1D7D765E-402A-36E3-A879-0E2A0E406293> >> /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine >> >> 0x1348fd000 - 0x134926fff GLRendererFloat (9.0.74) >> <37D2C111-A7C9-3657-96D2-586C0BFE1EAB> >> /System/Library/Frameworks/OpenGL.framework/Resources/GLRendererFloat.bundle/GLRendererFloat >> >> 0x13492f000 - 0x134938ff7 libcldcpuengine.dylib >> (2.3.49) <7C0F237D-4818-3101-86C3-9B05243FC173> >> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libcldcpuengine.dylib >> >> 0x7fff6f401000 - 0x7fff6f4344a7 dyld (237) >> /usr/lib/dyld >> 0x7fff86aa2000 - 0x7fff86aa2ffd >> com.apple.audio.units.AudioUnit (1.9 - 1.9) >> >> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit >> 0x7fff86aae000 - 0x7fff86d56ff9 com.apple.HIToolbox (2.1 - >> 681) >> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox >> >> 0x7fff86d59000 - 0x7fff86da6fff com.apple.opencl (2.3.50 - >> 2.3.50) <33C1EC76-02A2-3474-BB9D-8F77B96E57CC> >> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL >> 0x7fff86da7000 - 0x7fff86e89ff7 com.apple.backup.framework >> (1.5 - 1.5) <70E20485-EDB6-3225-8AF6-6D9494CB98B7> >> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup >> 0x7fff86e8a000 - 0x7fff86e8dff7 com.apple.help (1.3.3 - 46) >> <4FF8A8E2-33C2-30DF-86CE-A7ADA9F56A3F> >> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help >> >> 0x7fff86eb2000 - 0x7fff86ecefff libresolv.9.dylib (54) >> <78D891A1-6F8B-34D4-8F0D-59DB6DF53411> /usr/lib/libresolv.9.dylib >> 0x7fff86ecf000 - 0x7fff86f0efff libGLU.dylib (9.0.74) >> <294F4F86-E900-356C-9A47-0C47A929F2FB> >> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib >> >> 0x7fff872a7000 - 0x7fff872dbfff libssl.0.9.8.dylib (50) >> <1A09EC98-23CF-39F1-9C99-38A47ED7184E> /usr/lib/libssl.0.9.8.dylib >> 0x7fff873c4000 - 0x7fff873c5ff7 libsystem_blocks.dylib (63) >> <7836104E-39B9-31B6-A0C7-C02ACD401ADE> >> /usr/lib/system/libsystem_blocks.dylib >> 0x7fff873c6000 - 0x7fff873deff7 >> com.apple.GenerationalStorage (2.0 - 158) >> <5BCFBEED-09D2-3BD3-8EE0-85E809C47380> >> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage >> >> 0x7fff873df000 - 0x7fff874cafff libsqlite3.dylib (155) >> /usr/lib/libsqlite3.dylib >> 0x7fff874cb000 - 0x7fff878acffe libLAPACK.dylib (1094.4) >> <19E25957-74BA-3770-AAB5-B6A05F19BDC2> >> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib >> >> 0x7fff878ad000 - 0x7fff87a49fff com.apple.QuartzCore (1.8 - >> 329.0) <08CE1885-71E8-3A38-AEB6-4BBB1A43785F> >> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore >> 0x7fff87a4a000 - 0x7fff87d49ff7 com.apple.Foundation (6.9 - >> 1042) >> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation >> 0x7fff87d84000 - 0x7fff87dd6fff libc++.1.dylib (118) >> <5FF54631-AC11-3AD8-B42D-04FAC953CCED> /usr/lib/libc++.1.dylib >> 0x7fff87dd7000 - 0x7fff87e56fff com.apple.CoreSymbolication >> (3.0 - 137) <85C4F6E2-5039-3E53-9AB2-6D65CAC9AAC5> >> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication >> >> 0x7fff87e57000 - 0x7fff87e69fff com.apple.ImageCapture (9.0 >> - 9.0) <9613F27D-A905-35BF-A23F-C69CD5337035> >> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture >> >> 0x7fff87e6a000 - 0x7fff87e71ffb liblaunch.dylib (842.1.1) >> <7055DF9E-52CE-3746-96EB-3718DDBF0BD0> /usr/lib/system/liblaunch.dylib >> 0x7fff87ec5000 - 0x7fff87f50fff libCoreStorage.dylib (377) >> /usr/lib/libCoreStorage.dylib >> 0x7fff87f51000 - 0x7fff8823bff7 >> com.apple.CoreServices.CarbonCore (1077.6 - 1077.6) >> >> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore >> >> 0x7fff8837a000 - 0x7fff88381fff com.apple.NetFS (6.0 - 4.0) >> <553EA9F4-7B2C-371A-AF03-4B709A730582> >> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS >> 0x7fff88382000 - 0x7fff883c6ffe com.apple.HIServices (1.22 - >> 454) <3625AF2C-1965-349D-B831-1FCC9084B675> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices >> >> 0x7fff883c7000 - 0x7fff883c8ffb libremovefile.dylib (33) >> >> /usr/lib/system/libremovefile.dylib >> 0x7fff883c9000 - 0x7fff883f0ff3 libsystem_info.dylib (449) >> >> /usr/lib/system/libsystem_info.dylib >> 0x7fff883f1000 - 0x7fff88432ff7 >> com.apple.PerformanceAnalysis (1.45 - 45) >> <6C498B15-45DB-362F-983B-764ECC9B8E21> >> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis >> >> 0x7fff88433000 - 0x7fff884a2ff1 >> com.apple.ApplicationServices.ATS (360 - 360) >> <8A3AD47D-2777-3019-80BB-4B17AA055E13> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS >> >> 0x7fff884a3000 - 0x7fff8856bff7 libvDSP.dylib (423.29) >> <72A38066-D6F5-38EC-A8B9-0D025AFC6E2B> >> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib >> >> 0x7fff89149000 - 0x7fff89181ff7 com.apple.RemoteViewServices >> (2.0 - 94) <7E7B5F1F-9F0E-3DF7-B6B9-152DFD2DFFC7> >> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices >> >> 0x7fff893d1000 - 0x7fff893d4fff com.apple.TCC (1.0 - 1) >> <1DF1D216-1355-3E4F-B4BE-3E3BA5A696EB> >> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC >> 0x7fff89407000 - 0x7fff89430fff com.apple.DictionaryServices >> (1.2 - 197) <862F498E-3CB7-3087-BB07-AC185D5D08F8> >> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices >> >> 0x7fff8946b000 - 0x7fff89492ff7 libsystem_network.dylib >> (241.3) >> /usr/lib/system/libsystem_network.dylib >> 0x7fff89493000 - 0x7fff894fdff7 com.apple.framework.IOKit >> (2.0.1 - 907.1.5) >> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit >> 0x7fff89505000 - 0x7fff89529fff libJPEG.dylib (1029) >> >> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib >> >> 0x7fff8952a000 - 0x7fff89534fff libcommonCrypto.dylib >> (60049) >> /usr/lib/system/libcommonCrypto.dylib >> 0x7fff89535000 - 0x7fff89566fff com.apple.MediaKit (15 - >> 709) >> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit >> 0x7fff89669000 - 0x7fff89684ff7 libCRFSuite.dylib (34) >> /usr/lib/libCRFSuite.dylib >> 0x7fff896a3000 - 0x7fff896fdff8 com.apple.AE (665.2 - 665.2) >> >> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE >> >> 0x7fff89b72000 - 0x7fff89b72ff7 libkeymgr.dylib (28) >> /usr/lib/system/libkeymgr.dylib >> 0x7fff89b8d000 - 0x7fff89bbcfff com.apple.DebugSymbols (106 >> - 106) <545E5A48-3516-3398-A33D-D6FB4FED4B7B> >> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols >> >> 0x7fff89bc0000 - 0x7fff89c23ff3 >> com.apple.SystemConfiguration (1.13 - 1.13) >> <73B50935-DFE8-31B8-8583-27A28B5A9D1E> >> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration >> >> 0x7fff89c2b000 - 0x7fff89c2bfff com.apple.CoreServices (59 - >> 59) >> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices >> 0x7fff89c8b000 - 0x7fff89cb0ffb com.apple.CoreVideo (1.8 - >> 117.0) <50587BF1-D111-3D49-9DAB-8F86B5E95808> >> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo >> 0x7fff89cfe000 - 0x7fff89e54ff3 >> com.apple.audio.toolbox.AudioToolbox (1.9 - 1.9) >> >> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox >> 0x7fff89e9e000 - 0x7fff89f11ffb com.apple.securityfoundation >> (6.0 - 55122) >> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation >> >> 0x7fff89fa0000 - 0x7fff89fa1fff libunc.dylib (28) >> <53C7CED6-55F5-3121-B00E-4339C29297C8> /usr/lib/system/libunc.dylib >> 0x7fff89fa2000 - 0x7fff89fa6fff com.apple.CommonPanels >> (1.2.6 - 96) <3E07F8FE-B061-318D-A00F-E7D993DEF4FB> >> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels >> >> 0x7fff89fb3000 - 0x7fff8a09afff libxml2.2.dylib (25) >> /usr/lib/libxml2.2.dylib >> 0x7fff8a09b000 - 0x7fff8a0b6ff7 libsystem_kernel.dylib >> (2422.1.26.0.1) <5F99677C-C760-3877-AFF7-F60B5ECE365E> >> /usr/lib/system/libsystem_kernel.dylib >> 0x7fff8a0b7000 - 0x7fff8a0c1ff7 libcsfde.dylib (377) >> /usr/lib/libcsfde.dylib >> 0x7fff8a0c2000 - 0x7fff8a0c6ff7 libheimdal-asn1.dylib >> (323.3) <90100758-0CC6-3D00-90AB-D3C7DC8CCE45> >> /usr/lib/libheimdal-asn1.dylib >> 0x7fff8a12a000 - 0x7fff8a209fff libcrypto.0.9.8.dylib (50) >> <9B1D3623-4A41-3A5B-88C7-1927AF7E2532> /usr/lib/libcrypto.0.9.8.dylib >> 0x7fff8a20a000 - 0x7fff8a210fef libsystem_platform.dylib >> (24) <5D8FE8C3-2A62-3705-AB7D-FBD7C284AFBD> >> /usr/lib/system/libsystem_platform.dylib >> 0x7fff8a211000 - 0x7fff8a4e0fdf com.apple.vImage (7.0 - 7.0) >> >> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage >> >> 0x7fff8a55f000 - 0x7fff8a566ff7 libsystem_pthread.dylib (53) >> <2160EC74-26FC-32CE-8161-B1A72D2B09B0> >> /usr/lib/system/libsystem_pthread.dylib >> 0x7fff8a5a9000 - 0x7fff8a616fff com.apple.SearchKit (1.4.0 - >> 1.4.0) >> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit >> >> 0x7fff8a64c000 - 0x7fff8a65bff8 com.apple.LangAnalysis >> (1.7.0 - 1.7.0) >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis >> >> 0x7fff8a91a000 - 0x7fff8a930fff com.apple.CFOpenDirectory >> (10.9 - 171) >> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory >> >> 0x7fff8a9ba000 - 0x7fff8aa46ff7 com.apple.ink.framework >> (10.9 - 205) >> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink >> >> 0x7fff8aa47000 - 0x7fff8b34d043 com.apple.CoreGraphics >> (1.600.0 - 565) <81F84822-675E-3466-97A7-6FF69DF569E3> >> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics >> 0x7fff8b485000 - 0x7fff8b49ffff libsystem_malloc.dylib >> (23.1.1) >> /usr/lib/system/libsystem_malloc.dylib >> 0x7fff8b4a0000 - 0x7fff8b4a0fff com.apple.Accelerate (1.9 - >> Accelerate 1.9) <94C28250-6BDB-30AD-B157-995D9C34A6FA> >> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate >> 0x7fff8b4a3000 - 0x7fff8b4a5fff libCVMSPluginSupport.dylib >> (9.0.74) <11FCA581-0FFD-37B1-966A-E47F4722D297> >> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib >> >> 0x7fff8b4b7000 - 0x7fff8b4c5ff7 com.apple.opengl (9.0.74 - >> 9.0.74) <9BD0013A-E503-3DA2-9F94-C42A11D2E734> >> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL >> 0x7fff8b538000 - 0x7fff8b5f0ff7 com.apple.DiscRecording (8.0 >> - 8000.4.6) <62C23719-2144-3137-87DF-0858239A08BE> >> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording >> >> 0x7fff8ba7a000 - 0x7fff8bb29ff7 libvMisc.dylib (423.29) >> <83CBEBB6-B9C2-3D83-A32A-CED47CDB65D6> >> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib >> >> 0x7fff8bb2a000 - 0x7fff8bb36fff com.apple.OpenDirectory >> (10.9 - 171) >> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory >> >> 0x7fff8bb37000 - 0x7fff8bb3cfff com.apple.DiskArbitration >> (2.6 - 2.6) <4D7487BB-C4A7-32DB-BEE2-CE55EA7F40B2> >> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration >> >> 0x7fff8bb3d000 - 0x7fff8bbffff9 com.apple.CoreText (352.0 - >> 367.6) >> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText >> 0x7fff8bdae000 - 0x7fff8bdbbfff com.apple.Sharing (112 - >> 112) <24BA2112-4FFB-318A-B881-93FEB4648371> >> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing >> 0x7fff8bde7000 - 0x7fff8bdebfff libpam.2.dylib (20) >> <17E3DA0D-EE71-3398-BA30-BDD8514A6135> /usr/lib/libpam.2.dylib >> 0x7fff8bdec000 - 0x7fff8bedbfff libFontParser.dylib (106) >> <16B9215D-3244-365F-910F-FA033495E3F5> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib >> >> 0x7fff8bedc000 - 0x7fff8bef5ff3 com.apple.Ubiquity (1.3 - >> 280) <581DAEFC-B314-3F92-93CF-7B70BF22AEEF> >> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity >> 0x7fff8bf41000 - 0x7fff8bf76ffc com.apple.LDAPFramework >> (2.4.28 - 194.5) <44544698-E9CA-3440-808A-FF5417E55538> >> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP >> 0x7fff8bf77000 - 0x7fff8bf79ffb libutil.dylib (34) >> <9A9338CF-FD16-3D8F-8564-0797A4DAFC5F> /usr/lib/libutil.dylib >> 0x7fff8c1f5000 - 0x7fff8c1f5fff com.apple.Cocoa (6.8 - 20) >> >> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa >> 0x7fff8c1f6000 - 0x7fff8c1f9fff libCoreVMClient.dylib (58.1) >> <331C429A-3AE5-30B8-A4DE-1BF4EE4D8FA6> >> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib >> >> 0x7fff8c224000 - 0x7fff8c227ffc com.apple.IOSurface (91 - >> 91) <1B7746FC-3599-3BDB-A0DA-65795C999435> >> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface >> 0x7fff8c26d000 - 0x7fff8c4aafff com.apple.CoreData (107 - >> 468) <51F9B655-84D2-3E88-991B-914C9017BB08> >> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData >> 0x7fff8c4ab000 - 0x7fff8c4b5ff7 >> com.apple.bsd.ServiceManagement (2.0 - 2.0) >> <3E92DCA9-DA23-34E1-8C38-DA7488621FFB> >> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement >> >> 0x7fff8c51a000 - 0x7fff8c51bff7 libsystem_sandbox.dylib >> (278.1) >> /usr/lib/system/libsystem_sandbox.dylib >> 0x7fff8c9d3000 - 0x7fff8ca0cff7 com.apple.QD (3.49 - 297) >> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD >> >> 0x7fff8ca0d000 - 0x7fff8ca36ff7 libc++abi.dylib (43) >> /usr/lib/libc++abi.dylib >> 0x7fff8ca78000 - 0x7fff8cac8ffa com.apple.audio.CoreAudio >> (4.2.0 - 4.2.0) <548AC059-62DD-3CF6-B083-CABE454AFA38> >> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio >> 0x7fff8d929000 - 0x7fff8d92aff7 >> libDiagnosticMessagesClient.dylib (100) >> >> /usr/lib/libDiagnosticMessagesClient.dylib >> 0x7fff8dde9000 - 0x7fff8decbfff com.apple.coreui (2.1 - 224) >> <9F8C1983-1795-34DA-A0C1-7F126ECA0D8E> >> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI >> 0x7fff8decf000 - 0x7fff8ded2ff7 libdyld.dylib (237) >> /usr/lib/system/libdyld.dylib >> 0x7fff8ded3000 - 0x7fff8e039fff libGLProgrammability.dylib >> (9.0.74) <07E259BB-1EDA-3EBE-9CDB-8DB09DE5D509> >> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib >> >> 0x7fff8e0af000 - 0x7fff8e0e9ffb com.apple.bom (12.0 - 192) >> >> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom >> 0x7fff8e0ea000 - 0x7fff8e175fff com.apple.Metadata (10.7.0 - >> 778.1) <93F05A4E-6581-3CD5-8697-84783CEBF764> >> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata >> >> 0x7fff8e176000 - 0x7fff8e199fff com.apple.IconServices (25 - >> 25.4) <525BAAE5-F45C-3A15-ACED-2AF4EFFED546> >> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices >> >> 0x7fff8e319000 - 0x7fff8e31aff7 >> com.apple.print.framework.Print (9.0 - 260) >> <264DAE2A-7FD5-36B4-A737-F521E62AE687> >> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print >> >> 0x7fff8e31b000 - 0x7fff8e484ff3 com.apple.CFNetwork (657 - >> 657) <59A9476F-19A2-3F8B-A9B0-8531EA36A4AE> >> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork >> 0x7fff8e48a000 - 0x7fff8e491fff libcompiler_rt.dylib (35) >> >> /usr/lib/system/libcompiler_rt.dylib >> 0x7fff8e492000 - 0x7fff8e675ff7 com.apple.CoreFoundation >> (6.9 - 842) >> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation >> >> 0x7fff8e6f1000 - 0x7fff8e6f2fff >> com.apple.TrustEvaluationAgent (2.0 - 25) >> <644D981B-A5A7-31F5-99A6-9F180B9A5DE3> >> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent >> >> 0x7fff8e6f3000 - 0x7fff8e705ff7 >> com.apple.MultitouchSupport.framework (245.12 - 245.12) >> <06CAA8FB-BEC6-3EF1-96FA-3D8A1EEB0959> >> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport >> >> 0x7fff8e706000 - 0x7fff8e76aff6 com.apple.Heimdal (4.0 - >> 2.0) <463F41AC-39FF-30FC-B03A-4198E7A9321F> >> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal >> 0x7fff8e76b000 - 0x7fff8e79afd2 libsystem_m.dylib (3047.15) >> <8A6B4EC2-BB25-342B-B3FE-9585175225B8> /usr/lib/system/libsystem_m.dylib >> 0x7fff8e800000 - 0x7fff8e809ff7 >> com.apple.speech.synthesis.framework (4.5.3 - 4.5.3) >> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis >> >> 0x7fff8e80a000 - 0x7fff8e815ff7 com.apple.NetAuth (5.0 - >> 5.0) <64D42204-C075-3440-8C29-BBD68A99A771> >> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth >> 0x7fff8e9bf000 - 0x7fff8e9c1fff com.apple.EFILogin (2.0 - 2) >> <2A4E94B1-F1A5-36A5-989E-013D646E1CE3> >> /System/Library/PrivateFrameworks/EFILogin.framework/Versions/A/EFILogin >> 0x7fff8e9c2000 - 0x7fff8ea04ff7 libauto.dylib (185.4) >> <379FBDA3-DB2A-35A3-A637-3893C0F0E52F> /usr/lib/libauto.dylib >> 0x7fff8ea05000 - 0x7fff8ea8efe7 libsystem_c.dylib (997) >> <5BAB0B09-A39E-39B9-9552-48B540B3ABD0> /usr/lib/system/libsystem_c.dylib >> 0x7fff8ea8f000 - 0x7fff8ea99ff7 >> com.apple.CrashReporterSupport (10.9 - 529) >> >> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport >> >> 0x7fff8ea9a000 - 0x7fff8ea9affd libOpenScriptingUtil.dylib >> (154) <9B8CECA0-360D-3C6D-A37D-95EE34AE2B16> >> /usr/lib/libOpenScriptingUtil.dylib >> 0x7fff8ee6d000 - 0x7fff8f2a0ff7 com.apple.vision.FaceCore >> (3.0.0 - 3.0.0) <14255DCC-80BD-3690-9269-057D175A9FC5> >> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore >> 0x7fff8f2a1000 - 0x7fff8f2a9ffc libGFXShared.dylib (9.0.74) >> <13A420C1-1B14-36F8-8F08-4698D423E52F> >> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib >> >> 0x7fff8f34f000 - 0x7fff8f454fff com.apple.ImageIO.framework >> (3.2.0 - 1029) >> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO >> 0x7fff8fba5000 - 0x7fff8fe75ff4 com.apple.CoreImage (9.0.33) >> <8BB17AEC-D09A-3173-8767-7DB5C982670E> >> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage >> >> 0x7fff9011b000 - 0x7fff90162ff3 libFontRegistry.dylib >> (121.1) >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib >> >> 0x7fff9016f000 - 0x7fff901c8ff7 libTIFF.dylib (1029) >> <12303E45-734B-3D6C-A5C8-1495ECBC0344> >> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib >> >> 0x7fff901c9000 - 0x7fff9041dff0 com.apple.security (7.0 - >> 55377) <2F4EFC9E-DD86-32E5-A2CB-E83A5DF34F8F> >> /System/Library/Frameworks/Security.framework/Versions/A/Security >> 0x7fff9045c000 - 0x7fff90461fff libmacho.dylib (845) >> <0038681B-CEC4-348A-A7B8-4236C701F2F8> /usr/lib/system/libmacho.dylib >> 0x7fff90462000 - 0x7fff90469ff3 libcopyfile.dylib (103) >> <54DD5730-3F05-3F18-B55C-24EA9546286F> /usr/lib/system/libcopyfile.dylib >> 0x7fff9046a000 - 0x7fff9046cff3 >> libsystem_configuration.dylib (596.1) >> <1E0FDEA3-8822-3E80-AA0D-57D0F4E30E2E> >> /usr/lib/system/libsystem_configuration.dylib >> 0x7fff90481000 - 0x7fff905efff7 libBLAS.dylib (1094.4) >> <80E99B02-BD2D-3D88-97B6-0BE2D8973633> >> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib >> >> 0x7fff90622000 - 0x7fff90633fff libsystem_asl.dylib (217) >> >> /usr/lib/system/libsystem_asl.dylib >> 0x7fff90637000 - 0x7fff90652ff7 libPng.dylib (1029) >> >> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib >> >> 0x7fff90653000 - 0x7fff906caff7 >> com.apple.CoreServices.OSServices (600 - 600) >> <73820122-62D4-359C-9312-CD49FCEDFE09> >> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices >> >> 0x7fff906cb000 - 0x7fff906faff5 com.apple.GSS (4.0 - 2.0) >> <6765C9D7-8AC9-3694-B5D4-5C26B119851D> >> /System/Library/Frameworks/GSS.framework/Versions/A/GSS >> 0x7fff906fb000 - 0x7fff9070bffb libsasl2.2.dylib (169) >> <4DB6E107-D03E-3EC2-BCD2-80483FAC3FFF> /usr/lib/libsasl2.2.dylib >> 0x7fff9070c000 - 0x7fff9075afff libcorecrypto.dylib (161) >> <56048D2C-3668-3E15-AF02-5C5A377320F6> >> /usr/lib/system/libcorecrypto.dylib >> 0x7fff90cf4000 - 0x7fff90d01ff0 libbz2.1.0.dylib (29) >> /usr/lib/libbz2.1.0.dylib >> 0x7fff90d02000 - 0x7fff90d2efff >> com.apple.CoreServicesInternal (184.1 - 184.1) >> <84F93D96-0544-3377-B7E3-99716DC57A8A> >> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal >> >> 0x7fff90d5a000 - 0x7fff90d5bff3 libSystem.B.dylib (1197) >> <7589D08E-9338-3E28-AA74-9734F0D51CE0> /usr/lib/libSystem.B.dylib >> 0x7fff90da4000 - 0x7fff90e92fff libJP2.dylib (1029) >> <720403F5-7863-30D6-AC09-F5A04F069E1B> >> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib >> >> 0x7fff90e93000 - 0x7fff90e97ff7 libcache.dylib (61) >> /usr/lib/system/libcache.dylib >> 0x7fff90e98000 - 0x7fff90ea1ffe com.apple.CommonAuth (4.0 - >> 2.0) <3918EBA0-A124-37DC-9BA6-4D1370AF03A8> >> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth >> >> 0x7fff90ea2000 - 0x7fff90ee0ff7 libGLImage.dylib (9.0.74) >> <0DD99DA1-A8E7-3309-8DED-A2AB410E59C8> >> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib >> >> 0x7fff90ef6000 - 0x7fff90f5aff7 com.apple.datadetectorscore >> (5.0 - 343.0) <7FE14856-0C85-3382-AD6C-1B9E21C276CB> >> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore >> >> 0x7fff90f5b000 - 0x7fff90fe4ff7 com.apple.ColorSync (4.9.0 - >> 4.9.0) >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync >> >> 0x7fff90fe5000 - 0x7fff91112ff7 com.apple.desktopservices >> (1.8 - 1.8) >> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv >> >> 0x7fff91113000 - 0x7fff91114fff liblangid.dylib (117) >> <5146A22B-088F-3D8D-B245-F03DD3CDA2B0> /usr/lib/liblangid.dylib >> 0x7fff9117e000 - 0x7fff91244ff7 com.apple.LaunchServices >> (572.3 - 572.3.1) <39618733-CC97-3991-BD3B-485BD7247115> >> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices >> >> 0x7fff91245000 - 0x7fff9128aff7 libcurl.4.dylib (78) >> /usr/lib/libcurl.4.dylib >> 0x7fff9142c000 - 0x7fff91f8afff com.apple.AppKit (6.9 - >> 1240) <53CEC6E0-F928-32EC-919D-B34C0818C88C> >> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit >> 0x7fff91f8b000 - 0x7fff9205cff2 >> com.apple.DiskImagesFramework (10.9 - 368.1) >> <2BF556C1-94D9-3816-BDD8-FB152BB7A89A> >> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages >> >> 0x7fff9205d000 - 0x7fff920b0fff >> com.apple.ScalableUserInterface (1.0 - 1) >> >> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface >> >> 0x7fff920c5000 - 0x7fff9211cfff com.apple.Symbolication (1.4 >> - 125) >> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication >> >> 0x7fff9211d000 - 0x7fff9211fff7 com.apple.securityhi (9.0 - >> 55005) <5BFDED08-3282-35B4-A37F-66BF8EAB0C90> >> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI >> >> 0x7fff92144000 - 0x7fff92151ffc com.apple.Librarian (1.2 - >> 1) <556E5FA3-4DDB-3B59-ADE8-07411751B667> >> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian >> >> 0x7fff9215d000 - 0x7fff92315ffb libicucore.A.dylib (511.16) >> /usr/lib/libicucore.A.dylib >> 0x7fff926ea000 - 0x7fff926ecfff libRadiance.dylib (1029) >> <4E13C7E9-9B17-33D3-9142-B645B5BBCCD6> >> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib >> >> 0x7fff9276f000 - 0x7fff92771ff7 libquarantine.dylib (69) >> <1776AABC-F1D7-3CB0-B698-B0C70D4E535B> >> /usr/lib/system/libquarantine.dylib >> 0x7fff92772000 - 0x7fff9278aff3 com.apple.openscripting (1.4 >> - 154) <1C16D0EF-C8D8-3D43-8155-F86968505E79> >> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting >> >> 0x7fff9278b000 - 0x7fff92794ff3 libsystem_notify.dylib (121) >> >> /usr/lib/system/libsystem_notify.dylib >> 0x7fff92795000 - 0x7fff927b7fff libxpc.dylib (300.1.4) >> <4F832032-9709-3E80-91C4-71914C67A32B> /usr/lib/system/libxpc.dylib >> 0x7fff927b8000 - 0x7fff927ffff7 libcups.2.dylib (365) >> <49F3E642-D748-3A60-AF51-F9E90F65C543> /usr/lib/libcups.2.dylib >> 0x7fff92800000 - 0x7fff9284dff2 >> com.apple.print.framework.PrintCore (9.0 - 424) >> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore >> >> 0x7fff9284e000 - 0x7fff92873ff7 com.apple.ChunkingLibrary >> (2.0 - 154) >> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary >> >> 0x7fff92908000 - 0x7fff9290efff com.apple.AOSNotification >> (1.7.0 - 760) >> /System/Library/PrivateFrameworks/AOSNotification.framework/Versions/A/AOSNotification >> >> 0x7fff9293e000 - 0x7fff92946fff libsystem_dnssd.dylib >> (522.1.3) <29695A12-75FC-36EE-97AC-179F6E9DA419> >> /usr/lib/system/libsystem_dnssd.dylib >> 0x7fff92e6b000 - 0x7fff92e7cff7 libz.1.dylib (53) >> <372E2641-66CA-3B13-8BE6-3A4335F861A6> /usr/lib/libz.1.dylib >> 0x7fff92e7d000 - 0x7fff92e82ff7 libunwind.dylib (35.3) >> <838CE69D-44F1-305C-8FA5-5E439D217F78> /usr/lib/system/libunwind.dylib >> 0x7fff92e83000 - 0x7fff930c0ffb com.apple.RawCamera.bundle >> (4.06 - 695) >> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera >> 0x7fff931f7000 - 0x7fff931f7fff com.apple.Carbon (154 - 157) >> <382844CD-59CB-3D50-83BF-35FC73D02C03> >> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon >> 0x7fff93251000 - 0x7fff93342ff9 libiconv.2.dylib (41) >> /usr/lib/libiconv.2.dylib >> 0x7fff93369000 - 0x7fff93371ff7 >> com.apple.speech.recognition.framework (4.2.4 - 4.2.4) >> <1CE37DE8-BA4A-30CD-A802-18DAF42C328F> >> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition >> >> 0x7fff934c3000 - 0x7fff934c3fff com.apple.Accelerate.vecLib >> (3.9 - vecLib 3.9) <349BA8B4-1C72-30BE-B2BB-1898F51B9B5E> >> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib >> >> 0x7fff934c8000 - 0x7fff934d5ff7 libxar.1.dylib (202) >> /usr/lib/libxar.1.dylib >> 0x7fff9386f000 - 0x7fff93897ffb libxslt.1.dylib (13) >> <33D39746-6FCD-3F32-AFAE-2E45232BF6FB> /usr/lib/libxslt.1.dylib >> 0x7fff93922000 - 0x7fff93926ff7 libGIF.dylib (1029) >> <000B8500-FC82-3016-8E59-9FA0D6395F04> >> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib >> >> 0x7fff93927000 - 0x7fff93975ff9 libstdc++.6.dylib (60) >> /usr/lib/libstdc++.6.dylib >> 0x7fff93976000 - 0x7fff93981fff libkxld.dylib >> (2422.1.26.0.1) >> /usr/lib/system/libkxld.dylib >> 0x7fff93982000 - 0x7fff9398dfff libGL.dylib (9.0.74) >> <2DB19533-5983-3F59-93F3-2761DA6EEDA5> >> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib >> >> 0x7fff9398e000 - 0x7fff93b3bf8f libobjc.A.dylib (551) >> <853FA2C9-7BF1-3962-896E-6367F99FD358> /usr/lib/libobjc.A.dylib >> 0x7fff93b3c000 - 0x7fff93b3ffff libsystem_stats.dylib >> (93.1.8.1.1) >> /usr/lib/system/libsystem_stats.dylib >> 0x7fff93b40000 - 0x7fff93b50fff libbsm.0.dylib (33) >> <65C2FC5C-4B4B-3C1B-B935-D67A3BF96A79> /usr/lib/libbsm.0.dylib >> 0x7fff93b60000 - 0x7fff93b6cff3 com.apple.AppleFSCompression >> (56 - 1.0) >> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression >> >> 0x7fff93b70000 - 0x7fff93b89ff7 com.apple.Kerberos (3.0 - 1) >> <13DDC487-95C0-379F-BD7F-E0FC5F5922D3> >> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos >> 0x7fff93ed4000 - 0x7fff93eeefff libdispatch.dylib (339.1.2) >> /usr/lib/system/libdispatch.dylib >> 0x7fff93f3c000 - 0x7fff93f3cfff >> com.apple.ApplicationServices (48 - 48) >> <21188B7D-50E8-3C28-A15E-5345AE7BAFBB> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices >> >> >> External Modification Summary: >> Calls made by other processes targeting this process: >> task_for_pid: 1 >> thread_create: 0 >> thread_set_state: 0 >> Calls made by this process: >> task_for_pid: 0 >> thread_create: 0 >> thread_set_state: 0 >> Calls made by all processes on this machine: >> task_for_pid: 6269 >> thread_create: 0 >> thread_set_state: 0 >> >> VM Region Summary: >> ReadOnly portion of Libraries: Total=174.3M resident=68.1M(39%) >> swapped_out_or_unallocated=106.2M(61%) >> Writable regions: Total=754.9M written=50.8M(7%) resident=54.8M(7%) >> swapped_out=0K(0%) unallocated=700.1M(93%) >> >> REGION TYPE VIRTUAL >> =========== ======= >> CG backing stores 1204K >> CG image 1040K >> CG raster data 12K >> CG shared images 180K >> CoreServices 1364K >> Image IO 64K >> Kernel Alloc Once 8K >> MALLOC 62.9M >> MALLOC (admin) 32K >> Memory Tag 242 12K >> Memory Tag 251 36K >> STACK GUARD 56.1M >> Stack 26.2M >> VM_ALLOCATE 104.0M >> VM_ALLOCATE (reserved) 557.2M reserved VM address >> space (unallocated) >> __DATA 22.5M >> __IMAGE 528K >> __LINKEDIT 68.1M >> __TEXT 106.2M >> __UNICODE 544K >> mapped file 52.5M >> shared memory 4K >> =========== ======= >> TOTAL 1.0G >> TOTAL, minus reserved VM space 503.4M >> >> >> Model: VMware7,1, BootROM VMW71.00V.0.B64.1206270404, 4 processors, >> 3.23 GHz, 4 GB, SMC 1.16f8 >> Graphics: Display, PCI, 128 MB >> Memory Module: RAM slot #0/RAM slot #0, 4 GB, DRAM, 0 MHz, VMware >> Virtual RAM, VMW-4096MB >> Bluetooth: Version 4.2.0b11 12562, 3 services, 20 devices, 3 incoming >> serial ports >> Network Service: Ethernet, Ethernet, en0 >> SCSI Device: SCSI Target Device @ 0 >> SCSI Device: SCSI Target Device @ 0 >> USB Device: VMware Virtual USB Hub >> USB Device: Virtual Bluetooth Adapter >> USB Device: VMware Virtual USB Keyboard >> USB Device: VMware Virtual USB Mouse >> Thunderbolt Bus: >> >> >> From ca at censhare.de Tue Jul 2 07:44:51 2013 From: ca at censhare.de (Christof Aenderl) Date: Tue, 2 Jul 2013 16:44:51 +0200 Subject: Crash in liblwawt.dylib on OS X 10.9 In-Reply-To: <51D2E581.6040609@oracle.com> References: <7ACF7412-B58F-4614-AE50-AD45EDB350FB@censhare.de> <51D2D5A7.7050706@oracle.com> <51D2E581.6040609@oracle.com> Message-ID: Hi Anthony, as Sergey Bylokhov told me, the bug has already been fixed in 7_40b25 http://bugs.sun.com/view_bug.do?bug_id=8008660 I can confirm this. Thanks und best regards, Christof Am 02.07.2013 um 16:36 schrieb Anthony Petrov : > A small typo in the url: http://bugs.sun.com/ is the correct one. > > -- > best regards, > Anthony > > On 07/02/2013 05:29 PM, Anthony Petrov wrote: >> Hi Christof, >> >> Please file a bug at http://bug.sun.com/ and provide a reproducible test >> case/instructions in your bug report. >> >> -- >> best regards, >> Anthony >> From pflahrty at rampageinc.com Tue Jul 2 12:16:40 2013 From: pflahrty at rampageinc.com (Patrick Flaherty) Date: Tue, 2 Jul 2013 15:16:40 -0400 Subject: 10.8.5 and Safari cannot access local file system via signed applet Message-ID: <3CCBD08A-B71F-436D-B832-6399524C5548@rampageinc.com> Hi, Since I received all the latest updates on Mac OSX 10.8.5 along with Java 1.7.25, signed applets run from Safari (6.1) cannot access the local file system. If the applet is called via Firefox I can access the local file system as I always have been as long as the applet is signed. I added the permissions and codebase tags to the jar manifest thinking that may be causing the issue. The manifest change got rid of the console massages about the permission and codebase but no change with the file system. Basically when JFileChooser is called all my folders and volumes have a red circle indicating no access. Same on OSX 10.9 with Safari 7.0 ! Anyone understand why this is? Thanks Pat From david.dehaven at oracle.com Tue Jul 2 13:40:16 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 2 Jul 2013 14:40:16 -0600 Subject: 10.8.5 and Safari cannot access local file system via signed applet In-Reply-To: <3CCBD08A-B71F-436D-B832-6399524C5548@rampageinc.com> References: <3CCBD08A-B71F-436D-B832-6399524C5548@rampageinc.com> Message-ID: <2ED4B5C7-05CB-4BE2-AE64-E32FF94D37D6@oracle.com> > Since I received all the latest updates on Mac OSX 10.8.5 along with Java 1.7.25, signed applets run from Safari (6.1) cannot access the local file system. If the applet is called via > Firefox I can access the local file system as I always have been as long as the applet is signed. I added the permissions and codebase tags to the jar manifest thinking that may be causing the issue. The manifest change got rid of the console massages about the permission and codebase but no change with the file system. Basically when JFileChooser is called all my folders and volumes have a red circle indicating no access. > > Same on OSX 10.9 with Safari 7.0 ! Can't comment on 10.9 or 10.8.5 since they're not released. Try whitelisting the app. Open preferences, click on the security tab then click "Manage Website Settings...", set the website in question to "Allow Always", then try again. -DrD- From ashesfall at gmail.com Tue Jul 2 14:38:38 2013 From: ashesfall at gmail.com (Mike Murray) Date: Tue, 2 Jul 2013 14:38:38 -0700 Subject: Hyrbid Mac Apps Java 1.6/1.7 Message-ID: *This may or may not be relevant to you guys on here, but it was suggested I post here as well as on java-dev at lists.apple.com* -- Greetings fellow strugglers in the war with Java on the Desktop, I've got a few things that [from recent posts here] appear to be of some value to the community. 1. An application stub, written in C, which is capable of starting either the 32 bit application stub for Java 1.6 compatible machines (resulting in the app starting with Java 1.6, if it is installed on the machine, or presenting the standard dialog to download Java 1.6, if it is not yet installed) *or* *instead* starting the 64 bit application stub for Java 1.7 compatible machines (resulting in the app starting with a bundled JRE, included in the app).* This was based on some work that was already up here, so perhaps this is not of any special significance.* 2. An ant build file which produces a "hybrid" application that includes a copy of the 1.7 JRE, as well as both stubs and the special stub mentioned in step (1)*plus* a copy of some improvements to the MRJAdapter product ( http://www.java.net/project/mrj-adapter) that I have made to allow it to run against the Mac Runtime stuff found in JRE 1.7 (the project page appears to have no indication that this will be done by its author, and an attempt to get added to the comitters list did not receive a response). 3. An ant task (also in Java) which merges the PLIST for a 32 bit JRE 1.6 compatible app bundle with the PLIST for a 64 bit JRE 1.7 compatible app bundle. These PLISTs can be generated individually using the two products mentioned elsewhere on this developer list (JarBundler and AppBundler), then merged together as part of the build. [*This work is still in progress, but an approaching deadline at work means it will be done very soon*]. Anyway, I'm a bit new to this list so I'm not sure if I may be posting redundantly, but these things provide an end to end solution for the problem of distributing a hybrid app bundle which is compatible with all the OS versions I can imagine people having in the wild, from Mac OS 10.5 onward. Plus, since the stub described in step (1) is a universal binary, the user can switch between 32 bit and 64 bit modes in the same way they would with other apps. In other news, the fact that the app is in fact self contained, and includes JRE 1.7, it should be permissible for it to be distributed in the app store, even though users who are on machines without support for running the embedded JRE will ultimately have to run their local JRE 1.6 *(I can't speak to the legitimacy of this, as it appears to be a gray area in the app store rules on bundling, and I am not a lawyer - at least not a good one)* Please contact me if you would like a copy of any this work, I've only done it out of necessity and I am happy to share. Also, as it turns out, the app in question requires open gl and the JOGL runtime and I've been able to get a hybrid version of that running on both architectures and both JREs. I'm open to discuss any of these challenges via gmail's built in chat app if you have more questions about anything. (ashesfall at gmail.com) Cheers. -Michael Murray (Software Junkie at the Center for the Study of Language and Information, Stanford University) -- -------------------------------------------------------------------------------------- Disco Mike - Amphicoelous (Original Mix) Now available on Beatport Buy it now at: http://btprt.dj/WeaNGz From Doug.Zwick at blackboard.com Tue Jul 2 16:26:12 2013 From: Doug.Zwick at blackboard.com (Doug Zwick) Date: Tue, 2 Jul 2013 19:26:12 -0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: References: Message-ID: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> Michael Hall wrote: > On Jun 28, 2013, at 12:32 PM, Artem Ananiev wrote: >> >> This is a bug in eAWT, which uses SwingUtilities.invokeLater(), but should use SunToolkit.postEvent(AppContext, AWTEvent) or similar. > > This is the only place where invokeLater isn't thread safe? I would expect that invokeLater is not safe when called from a different AppContext. It looks like there is 1:1 correspondence between AppContext and the "main", "javawsSecurityThreadGroup" and "javawsApplicationThreadGroup" ThreadGroups, but this does not necessarily mean that the AppContext is bound to a Thread. >From this old FAQ I concluded that Runnables queued via invokeLater from the wrong AppContext go to the wrong EDT: http://lopica.sourceforge.net/faq.html#two-event-queues Now all threads of a JWS app should run in the javawsApplicationThreadGroup and have the corresponding AppContext. However, taking a thread dump of our JWS app reveals that the AppKit thread is in the "main" ThreadGroup, and seems to use the corresponding AppContext when calling invokeLater, so any use of invokeLater on the AppKit thread would be expected to go to the Swing EDT corresponding to that context. In our case that is AWT-EventQueue-0 in the "main" ThreadGroup ("our" EDT is AWT-EventQueue-2 in the "javawsApplicationThreadGroup" ThreadGroup). As far as I have been able to determine, this is the only way you can get control into your application code with the wrong AppContext. I believe that the bugs in EAWT and the ScreenMenuBar implementation are manifestations of this (the JRE code was called back by native code on the AppKit thread, and they dispatched events or Runnables to the wrong EDT). Sending events directly to the right EDT, in the case of JNI callbacks, does not seem possible. It also does not appear possible to directly determine what the AppContext is, as AppContext seems to be defined in a non-public package, and I could find no way to directly interrogate it using public APIs. Using non-public APIs is not advisable, as they can change without notice. Leonid Romanov wrote: > What do you think about introducing a new API, like SwingUtilities.invokeLater(Runnable runnable, Component target) which would invoke the runnable using the target's AppContext? It might be useful both for AWT/Swing engineers and apps writers. Arten Ananiev wrote: > Such API is useful, when your code is on a thread like the toolkit thread (AppKit thread on OS X). So a better place would be SunToolkit or SwingUtilities2, but SunToolkit already has a method named executeOnEventHandlerThread(). Something like this would be of benefit to OS X JNI implementors. If JNI code on other platforms can call back into Java code on the toolkit thread and the AppContext is not well defined (or wrong), then they would have need of it too. As it stands, I had to set up a utility thread with the right AppContext and a queue of Runnables (and the usual synchronize/wait/notify overhead to make it work) and have that thread use SwingUtilities.invokeLater to put things on the Swing thread when I queue them up from the AppKit thread. That is a bit painful and adds unnecessary latency, which such a utility would avoid. IIRC SunToolkit is not in a public package (i.e. a "java.xxx" or "javax.xxx" package). I don't see "SwingUtilities2" in a public package, either. I'd like to see such a utility provided in a public package, with the support commitments that that implies. Or perhaps better yet, having JNI itself somehow set the AppContext when a native thread calls back into the JVM. Also, is a Component the best way to key the AppContext? When writing JNI code (especially callbacks from system utilities) a Component instance isn't always handy. Ideally the AppContext itself should be used, but since it is not publicly available, that is problematic. This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. From swingler at apple.com Tue Jul 2 17:55:11 2013 From: swingler at apple.com (Mike Swingler) Date: Tue, 02 Jul 2013 17:55:11 -0700 Subject: [8] Request for review: 7190349 [macosx] Text (Label) in a JTabbedPane is incorrectly drawn In-Reply-To: <519D52C6.1050006@oracle.com> References: <519BCDA9.8080601@oracle.com> <519BE6A6.1010102@oracle.com> <519C079D.9070906@oracle.com> <519D039E.4030902@oracle.com> <519D3DF8.307@oracle.com> <519D4203.4090205@oracle.com> <519D52C6.1050006@oracle.com> Message-ID: <16F63A2B-B0B1-4358-B29C-E66F3D465611@apple.com> On May 22, 2013, at 4:20 PM, Phil Race wrote: > On 5/22/13 3:09 PM, Sergey Bylokhov wrote: >> Hi, Phil. >> I was under impression that jdk6 use the same java runtime support, because it has the same issue and because of this e-mail. >> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-November/005156.html > > I can't tell (from that email) if shipping JDK 6 for OS X really uses those APIs, > or if the mentioned re-implementation was just an experiement. > In any case the purpose of inventing them was to expose some non-public functionality. > So its unclear if the problem is in tha JRS layer itself or something else underneath. Sorry for the delay. Yes, Java SE 6 does use all of the JRS functions. We suppress the undesirable behavior of JRSFontGetAdvancesForGlyphsAndStyle() in Retina by forbidding any Java 2D context from actually being pixel-aligned for 2D or text operations when running under Retina (and we also force the renderer off of the Sun2D loops for on-screen operations). For the most part, apps don't seem to notice. Regards, Mike Swingler Apple Inc. From artem.ananiev at oracle.com Wed Jul 3 02:18:47 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 03 Jul 2013 13:18:47 +0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> References: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> Message-ID: <51D3EC77.7000707@oracle.com> On 7/3/2013 3:26 AM, Doug Zwick wrote: > Michael Hall wrote: > >> On Jun 28, 2013, at 12:32 PM, Artem Ananiev wrote: >>> >>> This is a bug in eAWT, which uses SwingUtilities.invokeLater(), >>> but should use SunToolkit.postEvent(AppContext, AWTEvent) or >>> similar. >> >> This is the only place where invokeLater isn't thread safe? > > I would expect that invokeLater is not safe when called from a > different AppContext. It looks like there is 1:1 correspondence > between AppContext and the "main", "javawsSecurityThreadGroup" and > "javawsApplicationThreadGroup" ThreadGroups, but this does not > necessarily mean that the AppContext is bound to a Thread. > > From this old FAQ I concluded that Runnables queued via invokeLater > from the wrong AppContext go to the wrong EDT: > > http://lopica.sourceforge.net/faq.html#two-event-queues > > Now all threads of a JWS app should run in the > javawsApplicationThreadGroup and have the corresponding AppContext. > However, taking a thread dump of our JWS app reveals that the AppKit > thread is in the "main" ThreadGroup, and seems to use the > corresponding AppContext when calling invokeLater, so any use of > invokeLater on the AppKit thread would be expected to go to the Swing > EDT corresponding to that context. In our case that is > AWT-EventQueue-0 in the "main" ThreadGroup ("our" EDT is > AWT-EventQueue-2 in the "javawsApplicationThreadGroup" ThreadGroup). > As far as I have been able to determine, this is the only way you can > get control into your application code with the wrong AppContext. I > believe that the bugs in EAWT and the ScreenMenuBar implementation > are manifestations of this (the JRE code was called back by native > code on the AppKit thread, and they dispatched events or Runnables to > the wrong EDT). Sending events directly to the right EDT, in the case > of JNI callbacks, does not seem possible. It also does not appear > possible to directly determine what the AppContext is, as AppContext > seems to be defined in a non-public package, and I could find no way > to directly interrogate it using public APIs. Using non-public APIs > is not advisable, as they can change without notice. > > Leonid Romanov wrote: > >> What do you think about introducing a new API, like >> SwingUtilities.invokeLater(Runnable runnable, Component target) >> which would invoke the runnable using the target's AppContext? It >> might be useful both for AWT/Swing engineers and apps writers. > > > Arten Ananiev wrote: > >> Such API is useful, when your code is on a thread like the toolkit >> thread (AppKit thread on OS X). So a better place would be >> SunToolkit or SwingUtilities2, but SunToolkit already has a method >> named executeOnEventHandlerThread(). > > > Something like this would be of benefit to OS X JNI implementors. If > JNI code on other platforms can call back into Java code on the > toolkit thread and the AppContext is not well defined (or wrong), > then they would have need of it too. As it stands, I had to set up a > utility thread with the right AppContext and a queue of Runnables > (and the usual synchronize/wait/notify overhead to make it work) and > have that thread use SwingUtilities.invokeLater to put things on the > Swing thread when I queue them up from the AppKit thread. That is a > bit painful and adds unnecessary latency, which such a utility would > avoid. IIRC SunToolkit is not in a public package (i.e. a "java.xxx" > or "javax.xxx" package). I don't see "SwingUtilities2" in a public > package, either. I'd like to see such a utility provided in a public > package, with the support commitments that that implies. Or perhaps > better yet, having JNI itself somehow set the AppContext when a > native thread calls back into the JVM. sun.awt.AppContext is designed to be completely invisible for applets/applications. You should never have to know what is the current AppContext, and whether other AppContexts exist in the same VM. Note that desktop and applet/webstart apps are slightly different: 1. In desktop mode, a single AppContext is created for the system (root) thread group and all the sub-groups. There is one EDT and one event queue in the JVM, so invokeLater() always posts the event to the right queue. 2. In applet/webstart modes, there may be multiple AppContexts in the JVM. All the application code is supposed to run in a single AppContext, including all the helper threads running native code. If you create a new thread group, it will inherit the current AppContext. If you create a new thread group using another (not current) thread group as a parent... Well, you should not do that, and, actually, untrusted code is not allowed to do that. If there are multiple AppContexts in the same JVM, it's reasonable to assume that all of them run different applets (or Java Plugin code, or Java Web Start code). I don't see any scenarios, when an application or a 3rd-party library need to post events to multiple AppContexts. Thanks, Artem > Also, is a Component the best way to key the AppContext? When writing > JNI code (especially callbacks from system utilities) a Component > instance isn't always handy. Ideally the AppContext itself should be > used, but since it is not publicly available, that is problematic. > > > > This email and any attachments may contain confidential and > proprietary information of Blackboard that is for the sole use of the > intended recipient. If you are not the intended recipient, > disclosure, copying, re-distribution or other use of any of this > information is strictly prohibited. Please immediately notify the > sender and delete this transmission if you received this email in > error. > From leonid.romanov at oracle.com Wed Jul 3 06:50:47 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 03 Jul 2013 17:50:47 +0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> References: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> Message-ID: <51D42C37.4040100@oracle.com> On 7/3/2013 3:26, Doug Zwick wrote: > Michael Hall wrote: > >> On Jun 28, 2013, at 12:32 PM, Artem Ananiev wrote: >>> This is a bug in eAWT, which uses SwingUtilities.invokeLater(), but should use SunToolkit.postEvent(AppContext, AWTEvent) or similar. >> This is the only place where invokeLater isn't thread safe? > I would expect that invokeLater is not safe when called from a different AppContext. It looks like there is 1:1 correspondence between AppContext and the "main", "javawsSecurityThreadGroup" and "javawsApplicationThreadGroup" ThreadGroups, but this does not necessarily mean that the AppContext is bound to a Thread. > > From this old FAQ I concluded that Runnables queued via invokeLater from the wrong AppContext go to the wrong EDT: > > http://lopica.sourceforge.net/faq.html#two-event-queues > > Now all threads of a JWS app should run in the javawsApplicationThreadGroup and have the corresponding AppContext. However, taking a thread dump of our JWS app reveals that the AppKit thread is in the "main" ThreadGroup, and seems to use the corresponding AppContext when calling invokeLater, so any use of invokeLater on the AppKit thread would be expected to go to the Swing EDT corresponding to that context. In our case that is AWT-EventQueue-0 in the "main" ThreadGroup ("our" EDT is AWT-EventQueue-2 in the "javawsApplicationThreadGroup" ThreadGroup). As far as I have been able to determine, this is the only way you can get control into your application code with the wrong AppContext. I believe that the bugs in EAWT and the ScreenMenuBar implementation are manifestations of this (the JRE code was called back by native code on the AppKit thread, and they dispatched events or Runnables to the wrong EDT). Sending events directly to the right EDT, in the case of JNI callbacks, does not seem possible. It also does not appear possible to directly determine what the AppContext is, as AppContext seems to be defined in a non-public package, and I could find no way to directly interrogate it using public APIs. Using non-public APIs is not advisable, as they can change without notice. > > Leonid Romanov wrote: > >> What do you think about introducing a new API, like SwingUtilities.invokeLater(Runnable runnable, Component target) which would invoke the runnable using the target's AppContext? It might be useful both for AWT/Swing engineers and apps writers. > > Arten Ananiev wrote: > >> Such API is useful, when your code is on a thread like the toolkit thread (AppKit thread on OS X). So a better place would be SunToolkit or SwingUtilities2, but SunToolkit already has a method named executeOnEventHandlerThread(). > > Something like this would be of benefit to OS X JNI implementors. If JNI code on other platforms can call back into Java code on the toolkit thread and the AppContext is not well defined (or wrong), then they would have need of it too. As it stands, I had to set up a utility thread with the right AppContext and a queue of Runnables (and the usual synchronize/wait/notify overhead to make it work) and have that thread use SwingUtilities.invokeLater to put things on the Swing thread when I queue them up from the AppKit thread. That is a bit painful and adds unnecessary latency, which such a utility would avoid. IIRC SunToolkit is not in a public package (i.e. a "java.xxx" or "javax.xxx" package). I don't see "SwingUtilities2" in a public package, either. I'd like to see such a utility provided in a public package, with the support commitments that that implies. Or perhaps better yet, having JNI itself somehow set the AppContext when a native thread calls back into the JVM. > > Also, is a Component the best way to key the AppContext? When writing JNI code (especially callbacks from system utilities) a Component instance isn't always handy. Ideally the AppContext itself should be used, but since it is not publicly available, that is problematic. > The idea I had in mind when proposing this API was the following. Suppose a JNI call from the AppKit thread has been made. As a result, you want to execute a piece of Java code in the correct AppContext. But what is the correct AppContext? It depends. If that Java code doesn't do anything with UI, then it doesn't matter what AppContext it will be executed in. If it does, though, that is, it changes the state of some UI component, then you want that change to happen in the same AppContext where the UI component lives in. Hence the proposed Component parameter. > > This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. From tim.bell at oracle.com Wed Jul 3 07:58:09 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 03 Jul 2013 07:58:09 -0700 Subject: Is anyone using clang/clang++ to build hotspot? Message-ID: <51D43C01.4040200@oracle.com> Hello I see that hotspot/make/bsd/makefiles/gcc.make contains several sections of: ifeq ($(USE_CLANG),) [...] else [...] endif On a 10.8 Mac with the command line tools installed, trying to use clang to build hotspot fails early on when building adlc because it uses the wrong linker and does not get the C++ runtiime (see below). This leads me to wonder if anyone is using this path through the Makefiles. Thanks in advance- Tim Bell Making adlc /usr/bin/clang -m64 -mno-omit-leaf-frame-pointer -mstack-alignment=16 -m64 -mno-omit-leaf-frame-pointer -mstack-alignment=16 -o ../generated/adfiles/adlc ../generated/adfiles/adlparse.o ../generated/adfiles/archDesc.o ../generated/adfiles/arena.o ../generated/adfiles/dfa.o ../generated/adfiles/dict2.o ../generated/adfiles/filebuff.o ../generated/adfiles/forms.o ../generated/adfiles/formsopt.o ../generated/adfiles/formssel.o ../generated/adfiles/main.o ../generated/adfiles/adlc-opcodes.o ../generated/adfiles/output_c.o ../generated/adfiles/output_h.o Undefined symbols for architecture x86_64: "std::ostream::operator<<(int)", referenced from: printline(std::ostream&, char const*, int, char const*, int, int) in filebuff.o [...] "operator new(unsigned long)", referenced from: ADLParser::instr_parse() in adlparse.o ADLParser::oper_parse() in adlparse.o ADLParser::opclass_parse() in adlparse.o ADLParser::ins_attr_parse() in adlparse.o ADLParser::op_attr_parse() in adlparse.o ADLParser::source_parse() in adlparse.o ADLParser::source_hpp_parse() in adlparse.o ... (maybe you meant: __ZnwmiPKci) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[8]: *** [../generated/adfiles/adlc] Error 1 make[7]: *** [ad_stuff] Error 2 make[6]: *** [fastdebug] Error 2 make[5]: *** [generic_build2] Error 2 make[4]: *** [fastdebug] Error 2 make[3]: *** [all_fastdebug_universal] Error 2 make[2]: *** [universal_fastdebug] Error 2 make[1]: *** [/opt/jprt/tbell/8019470/build/macosx-x86_64-normal-server-fastdebug/hotspot/_hotspot.timestamp] Error 2 make: *** [hotspot-only] Error 2 From Doug.Zwick at blackboard.com Wed Jul 3 09:21:25 2013 From: Doug.Zwick at blackboard.com (Doug Zwick) Date: Wed, 3 Jul 2013 12:21:25 -0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: <51D3EC77.7000707@oracle.com> References: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> <51D3EC77.7000707@oracle.com> Message-ID: <8175C099-D614-4165-B1CB-C35286B7A143@blackboard.com> Artem Ananiev wrote: > sun.awt.AppContext is designed to be completely invisible for > applets/applications. You should never have to know what is the current > AppContext, and whether other AppContexts exist in the same VM. I agree 100%. The problem I am having is with edge cases where the correct AppContext is ambiguous. This happens because the AppKit thread must be shared between all Java AppContexts in the process. > 2. In applet/webstart modes, there may be multiple AppContexts in the > JVM. All the application code is supposed to run in a single AppContext, > including all the helper threads running native code. If you create a > new thread group, it will inherit the current AppContext. If you create > a new thread group using another (not current) thread group as a > parent... Well, you should not do that, and, actually, untrusted code is > not allowed to do that. Unfortunately this can happen by accident. If a native method running on the AppKit thread (or Toolkit thread) calls back into Java, and that Java method creates a Thread (or if the native code uses JNI to create a new Thread) without specifying the ThreadGroup, it will inherit the ThreadGroup of the AppKit (Toolkit) thread, which will be in some other context. We actually ran into this with a third-party library we are using. It created a Executor thread pool in the "main" ThreadGroup, presumably in a WebKit callback on the AppKit thread. That pool was used for sending callbacks from the 3rd party library into our code, which attempted to update our Swing UI. Or app would reliably deadlock within a few seconds of the WebKit component being shown. > If there are multiple AppContexts in the same JVM, it's reasonable to > assume that all of them run different applets (or Java Plugin code, or > Java Web Start code). I don't see any scenarios, when an application or > a 3rd-party library need to post events to multiple AppContexts. Agreed 100%. Code should never post events to an AppContext belonging to "somebody else". To me, the solution is ensuring that code never runs in an environment where the AppContext is ambiguous. That is not the case for native code running on the AppKit thread. As long as that code stays in the native environment, the Java AppContext doesn't matter. It is when JNI is used to access the JVM that it matters. That would be the ideal place to bind the running code to the right AppContext. I don't know if that is a practical approach. If not, then the API pitched by Leonid would certainly work. Or perhaps just flag the AppKit thread as running in an ambiguous context, and throw an exception when attempting to do something requiring an AppContext. The problem is that WebStart code using native callbacks and JNI must jump through non-obvious hoops in order to get things to work right. To solve this, we need to either have JNI get the code into the right context automatically, or provide a mechanism for the programmer to do so, either on the native side or on the Java side. Whatever approach is taken, unless it "just works" it needs to be public and well documented. Hiding it away in a private package does not help JNI programmers. Lenoid Romanov wrote: > The idea I had in mind when proposing this API was the following. > Suppose a JNI call from the AppKit thread has been made. As a result, > you want to execute a piece of Java code in the correct AppContext. But > what is the correct AppContext? It depends. If that Java code doesn't do > anything with UI, then it doesn't matter what AppContext it will be > executed in. If it does, though, that is, it changes the state of some > UI component, then you want that change to happen in the same AppContext > where the UI component lives in. Hence the proposed Component parameter. It is not clear, at least from the outside looking in, that UI is the only area effected by the AppContext. Even if that is the case today, will that continue in the future? Could things like signed applet privileges be specified by the AppContext? I don't know that a ThreadGroup would be any better. Some kind of opaque token identifying the AppContext would work. Given that the only identified vector at the moment is through JNI, it may well be practical to bury the context inside the JNIEnv data structure. This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. From leonid.romanov at oracle.com Wed Jul 3 15:03:07 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 4 Jul 2013 02:03:07 +0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: <8175C099-D614-4165-B1CB-C35286B7A143@blackboard.com> References: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> <51D3EC77.7000707@oracle.com> <8175C099-D614-4165-B1CB-C35286B7A143@blackboard.com> Message-ID: <80DC89E9-1DFD-49B4-8A42-2A7DE4E4DAAC@oracle.com> On Jul 3, 2013, at 8:21 PM, Doug Zwick wrote: > Artem Ananiev wrote: > > >> 2. In applet/webstart modes, there may be multiple AppContexts in the >> JVM. All the application code is supposed to run in a single AppContext, >> including all the helper threads running native code. If you create a >> new thread group, it will inherit the current AppContext. If you create >> a new thread group using another (not current) thread group as a >> parent... Well, you should not do that, and, actually, untrusted code is >> not allowed to do that. > > Unfortunately this can happen by accident. If a native method running on the AppKit thread (or Toolkit thread) calls back into Java, and that Java method creates a Thread (or if the native code uses JNI to create a new Thread) without specifying the ThreadGroup, it will inherit the ThreadGroup of the AppKit (Toolkit) thread, which will be in some other context. We actually ran into this with a third-party library we are using. It created a Executor thread pool in the "main" ThreadGroup, presumably in a WebKit callback on the AppKit thread. That pool was used for sending callbacks from the 3rd party library into our code, which attempted to update our Swing UI. Or app would reliably deadlock within a few seconds of the WebKit component being shown. > This issue is not limited to the OS X/JNI case. According to the FAQ Doug posted in the previous email (http://lopica.sourceforge.net/faq.html#two-event-queues), RMI callbacks get called within "wrong" thread group. By "wrong" I mean that you can't do UI stuff in RMI callbacks. Basically, it looks like it's the same situation as with OS X/JNI. Leonid. From Doug.Zwick at blackboard.com Wed Jul 3 16:32:06 2013 From: Doug.Zwick at blackboard.com (Doug Zwick) Date: Wed, 3 Jul 2013 19:32:06 -0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: <80DC89E9-1DFD-49B4-8A42-2A7DE4E4DAAC@oracle.com> References: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> <51D3EC77.7000707@oracle.com> <8175C099-D614-4165-B1CB-C35286B7A143@blackboard.com> <80DC89E9-1DFD-49B4-8A42-2A7DE4E4DAAC@oracle.com> Message-ID: <042160D2-48EB-44AA-B447-C4A8404E08A8@blackboard.com> Leonid Romanov wrote: > This issue is not limited to the OS X/JNI case. According to the FAQ Doug posted in the previous email (http://lopica.sourceforge.net/faq.html#two-event-queues), RMI callbacks get called within "wrong" thread group. By "wrong" I mean that you can't do UI stuff in RMI callbacks. Basically, it looks like it's the same situation as with OS X/JNI. That is a good point, I'd forgotten about that case. At least the RMI infrastructure is part of the JRE and has access to the internal data structures needed to remediate the situation. That is also an old article, so the RMI case may have been fixed in the interim. This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. From artem.ananiev at oracle.com Thu Jul 4 02:23:39 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 04 Jul 2013 13:23:39 +0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: <8175C099-D614-4165-B1CB-C35286B7A143@blackboard.com> References: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> <51D3EC77.7000707@oracle.com> <8175C099-D614-4165-B1CB-C35286B7A143@blackboard.com> Message-ID: <51D53F1B.4070206@oracle.com> On 7/3/2013 8:21 PM, Doug Zwick wrote: > Artem Ananiev wrote: > >> sun.awt.AppContext is designed to be completely invisible for >> applets/applications. You should never have to know what is the >> current AppContext, and whether other AppContexts exist in the same >> VM. > > I agree 100%. The problem I am having is with edge cases where the > correct AppContext is ambiguous. This happens because the AppKit > thread must be shared between all Java AppContexts in the process. What you refer to as the edge cases should instead be considered JDK bugs. For example, it is AWT/Swing duty to make sure application code is never run on the AppKit thread. >> 2. In applet/webstart modes, there may be multiple AppContexts in >> the JVM. All the application code is supposed to run in a single >> AppContext, including all the helper threads running native code. >> If you create a new thread group, it will inherit the current >> AppContext. If you create a new thread group using another (not >> current) thread group as a parent... Well, you should not do that, >> and, actually, untrusted code is not allowed to do that. > > Unfortunately this can happen by accident. If a native method running > on the AppKit thread (or Toolkit thread) calls back into Java, and > that Java method creates a Thread (or if the native code uses JNI to > create a new Thread) without specifying the ThreadGroup, it will > inherit the ThreadGroup of the AppKit (Toolkit) thread, which will be > in some other context. We actually ran into this with a third-party > library we are using. It created a Executor thread pool in the "main" > ThreadGroup, presumably in a WebKit callback on the AppKit thread. > That pool was used for sending callbacks from the 3rd party library > into our code, which attempted to update our Swing UI. Or app would > reliably deadlock within a few seconds of the WebKit component being > shown. Yes, this is possible. If an app calls native method, which then switches to the AppKit thread, and upcalls to Java from there, there will be problems. In this case a method suggested by Leonid would indeed make sense. However, it still doesn't look like a good candidate for public API (java.*) If a library is allowed to call native methods, it is also allowed to use sun.* classes, including SunToolkit and AppContext. >> If there are multiple AppContexts in the same JVM, it's reasonable >> to assume that all of them run different applets (or Java Plugin >> code, or Java Web Start code). I don't see any scenarios, when an >> application or a 3rd-party library need to post events to multiple >> AppContexts. > > Agreed 100%. Code should never post events to an AppContext belonging > to "somebody else". To me, the solution is ensuring that code never > runs in an environment where the AppContext is ambiguous. That is not > the case for native code running on the AppKit thread. As long as > that code stays in the native environment, the Java AppContext > doesn't matter. It is when JNI is used to access the JVM that it > matters. That would be the ideal place to bind the running code to > the right AppContext. I don't know if that is a practical approach. > If not, then the API pitched by Leonid would certainly work. Or > perhaps just flag the AppKit thread as running in an ambiguous > context, and throw an exception when attempting to do something > requiring an AppContext. > > The problem is that WebStart code using native callbacks and JNI must > jump through non-obvious hoops in order to get things to work right. > To solve this, we need to either have JNI get the code into the right > context automatically, or provide a mechanism for the programmer to > do so, either on the native side or on the Java side. Whatever > approach is taken, unless it "just works" it needs to be public and > well documented. Hiding it away in a private package does not help > JNI programmers. Again, I would rather consider such cases bug in Java Web Start. > Lenoid Romanov wrote: > >> The idea I had in mind when proposing this API was the following. >> Suppose a JNI call from the AppKit thread has been made. As a >> result, you want to execute a piece of Java code in the correct >> AppContext. But what is the correct AppContext? It depends. If that >> Java code doesn't do anything with UI, then it doesn't matter what >> AppContext it will be executed in. If it does, though, that is, it >> changes the state of some UI component, then you want that change >> to happen in the same AppContext where the UI component lives in. >> Hence the proposed Component parameter. > > It is not clear, at least from the outside looking in, that UI is the > only area effected by the AppContext. Even if that is the case today, > will that continue in the future? Could things like signed applet > privileges be specified by the AppContext? I don't know that a > ThreadGroup would be any better. Some kind of opaque token > identifying the AppContext would work. Given that the only identified > vector at the moment is through JNI, it may well be practical to bury > the context inside the JNIEnv data structure. AppContext is in the sun.awt package, so it's clearly related to UI, and it was originally designed to be used in UI code only. Unfortunately, it is now used in a few other places in JDK, which are not related to AWT/Swing, but I hope we'll eventually fix that. Thanks, Artem > This email and any attachments may contain confidential and > proprietary information of Blackboard that is for the sole use of the > intended recipient. If you are not the intended recipient, > disclosure, copying, re-distribution or other use of any of this > information is strictly prohibited. Please immediately notify the > sender and delete this transmission if you received this email in > error. > From russcalvert at astrograv.co.uk Thu Jul 4 07:37:29 2013 From: russcalvert at astrograv.co.uk (Russ Calvert) Date: Thu, 4 Jul 2013 15:37:29 +0100 Subject: setDefaultMenuBar (Bug 8007267) In-Reply-To: References: Message-ID: I read all the 'macosx-port' reports that I receive (by email), and have been waiting until I get the impression that Java 7/8 might be mature enough for end-users (only minor problems), so as not to waste time unnecessarily. For me, the big show stopper is the failure of 'setDefaultMenuBar' (Bug 8007267), as this is fundamental to desktop applications. I'm sure that many others are deterred from experimenting with Java 7/8 for exactly the same reason. Does anyone have any idea when (or even if) this bug is likely to be fixed, or if there's anything that can be done to raise its priority? Russ Calvert AstroGrav Astronomy Software From wjherrmann at gmail.com Thu Jul 4 19:33:20 2013 From: wjherrmann at gmail.com (Will Herrmann) Date: Thu, 4 Jul 2013 21:33:20 -0500 Subject: Support for Apple Extensions Message-ID: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> Will future versions of Java support the Apple Extensions (e.g. com.apple.eawt) that were created while Apple handled Java for Mac OS X? The Stack Overflow topic at http://stackoverflow.com/a/15054600/531762 suggests that they are included in OpenJDK Java 7, but I'm not sure if this is going to continue for Java 8 and beyond. If they are going to be included, where can I find Java Docs for these Apple Extensions? Apple has since taken them down from their original home at https://developer.apple.com/library/mac/documentation/Java/Reference/1.5.0/appledoc/api/overview-summary.html Thanks in Advance, -Will Herrmann From hs at tagtraum.com Thu Jul 4 23:28:58 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Fri, 5 Jul 2013 08:28:58 +0200 Subject: Support for Apple Extensions In-Reply-To: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> Message-ID: <18F9B89F-94EE-44AB-8B84-FCF106118243@tagtraum.com> On Jul 5, 2013, at 4:33 AM, Will Herrmann wrote: > If they are going to be included, where can I find Java Docs for these Apple Extensions? Apple has since taken them down from their original home at https://developer.apple.com/library/mac/documentation/Java/Reference/1.5.0/appledoc/api/overview-summary.html Yep... a little documentation would be nice! And while we're at it: Are the custom Apple swing properties documented on the Oracle/OpenJDK side somewhere? If Apple follows its current path, https://developer.apple.com/library/mac/#technotes/tn2007/tn2196.html will soon be gone, too, I'm sure. -hendrik From Alan.Bateman at oracle.com Fri Jul 5 00:45:13 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Jul 2013 08:45:13 +0100 Subject: Support for Apple Extensions In-Reply-To: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> Message-ID: <51D67989.5060304@oracle.com> On 05/07/2013 03:33, Will Herrmann wrote: > Will future versions of Java support the Apple Extensions (e.g. com.apple.eawt) that were created while Apple handled Java for Mac OS X? The Stack Overflow topic at http://stackoverflow.com/a/15054600/531762 suggests that they are included in OpenJDK Java 7, but I'm not sure if this is going to continue for Java 8 and beyond. > I don't know whether these APIs are supported or not (they came into OpenJDK via the port and I'm not sure that there was any discussion about them). However I am curious to understand how commonly used they and whether the usages are cases where standard APIs should be considered. -Alan From krueger at lesspain.de Fri Jul 5 01:30:19 2013 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Fri, 5 Jul 2013 10:30:19 +0200 Subject: Support for Apple Extensions In-Reply-To: <51D67989.5060304@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> Message-ID: On Fri, Jul 5, 2013 at 9:45 AM, Alan Bateman wrote: > On 05/07/2013 03:33, Will Herrmann wrote: >> >> Will future versions of Java support the Apple Extensions (e.g. >> com.apple.eawt) that were created while Apple handled Java for Mac OS X? The >> Stack Overflow topic at http://stackoverflow.com/a/15054600/531762 suggests >> that they are included in OpenJDK Java 7, but I'm not sure if this is going >> to continue for Java 8 and beyond. >> > I don't know whether these APIs are supported or not (they came into OpenJDK > via the port and I'm not sure that there was any discussion about them). > > However I am curious to understand how commonly used they and whether the > usages are cases where standard APIs should be considered. > > -Alan Ouch! I did not know this was unclear. We use those in our app with OpenJDK8 and so far I have not found anything that did not work as it did with Apple's JDK6, although the app is not used in production with 8 yet and we might have missed something. Definitely one thing you'd better announce, if the plan turns out to be to discontinue those as I believe a lot of people use them on the Mac. Robert From hs at tagtraum.com Fri Jul 5 01:36:29 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Fri, 5 Jul 2013 10:36:29 +0200 Subject: Support for Apple Extensions In-Reply-To: <51D67989.5060304@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> Message-ID: <501E7784-871E-47E0-A059-AAA5BAF8E329@tagtraum.com> On Jul 5, 2013, at 9:45 AM, Alan Bateman wrote: [...] > However I am curious to understand how commonly used they and whether the usages are cases where standard APIs should be considered. Some of them, like the About and Preferences handler, are essential to create a pleasant OS X experience. Without them it is impossible to create a Java app that fits into the native environment. -hendrik From steve at winnall.ch Fri Jul 5 01:45:30 2013 From: steve at winnall.ch (Stephen Winnall) Date: Fri, 5 Jul 2013 10:45:30 +0200 Subject: Support for Apple Extensions In-Reply-To: <51D67989.5060304@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> Message-ID: <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> As long as the standard APIs are Windows- and Linux-biased, as they have been since the beginning of Java, the Apple extensions are going to remain necessary. Any Mac Java client that wants to have a chance of market acceptance will use them extensively. Steve On 05.07.2013, at 09:45, Alan Bateman wrote: > On 05/07/2013 03:33, Will Herrmann wrote: >> Will future versions of Java support the Apple Extensions (e.g. com.apple.eawt) that were created while Apple handled Java for Mac OS X? The Stack Overflow topic at http://stackoverflow.com/a/15054600/531762 suggests that they are included in OpenJDK Java 7, but I'm not sure if this is going to continue for Java 8 and beyond. > I don't know whether these APIs are supported or not (they came into OpenJDK via the port and I'm not sure that there was any discussion about them). > > However I am curious to understand how commonly used they and whether the usages are cases where standard APIs should be considered. > > -Alan From Kustaa.Nyholm at planmeca.com Fri Jul 5 01:51:52 2013 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 5 Jul 2013 11:51:52 +0300 Subject: Support for Apple Extensions In-Reply-To: <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> Message-ID: On 05/07/2013 11:45, "Stephen Winnall" wrote: > >Any Mac Java client that wants to have a chance of market acceptance will >use them extensively. Yes, I'll second that, without them the acceptance among apple users is poor to nil. br Kusti This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. From paul_t100 at fastmail.fm Fri Jul 5 01:53:49 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 05 Jul 2013 09:53:49 +0100 Subject: Support for Apple Extensions In-Reply-To: <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> Message-ID: <51D6899D.9050406@fastmail.fm> On 05/07/2013 09:45, Stephen Winnall wrote: > As long as the standard APIs are Windows- and Linux-biased, as they have been since the beginning of Java, the Apple extensions are going to remain necessary. > > Any Mac Java client that wants to have a chance of market acceptance will use them extensively. > > Steve > > On 05.07.2013, at 09:45, Alan Bateman wrote: > >> On 05/07/2013 03:33, Will Herrmann wrote: >>> Will future versions of Java support the Apple Extensions (e.g. com.apple.eawt) that were created while Apple handled Java for Mac OS X? The Stack Overflow topic at http://stackoverflow.com/a/15054600/531762 suggests that they are included in OpenJDK Java 7, but I'm not sure if this is going to continue for Java 8 and beyond. >> I don't know whether these APIs are supported or not (they came into OpenJDK via the port and I'm not sure that there was any discussion about them). >> >> However I am curious to understand how commonly used they and whether the usages are cases where standard APIs should be considered. >> >> -Alan This was discussed this in some detail last Autumn, and we were assured that support would be continued, and on a postive note from my own experience Ive found everything I need does all work on the 1.7.0_40_ea-b291 release. Alan I would suggest you discuss this with the oracle developers who were looking at this back then. At the time I also requested it should be properly documented but the response on that was pretty divided. 1Paul From Alan.Bateman at oracle.com Fri Jul 5 02:04:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Jul 2013 10:04:17 +0100 Subject: Support for Apple Extensions In-Reply-To: <51D6899D.9050406@fastmail.fm> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> Message-ID: <51D68C11.2000900@oracle.com> On 05/07/2013 09:53, Paul Taylor wrote: > This was discussed this in some detail last Autumn, and we were > assured that support would be continued, and on a postive note from my > own experience Ive found everything I need does all work on the > 1.7.0_40_ea-b291 release. Alan I would suggest you discuss this with > the oracle developers who were looking at this back then. At the time > I also requested it should be properly documented but the response on > that was pretty divided. I think the right thing is to understand which of these com.apple APIs are commonly used as it may may sense to add standard APIs for some of these cases. If you links to the discussion from "last Autumn" that would be useful. -Alan From hs at tagtraum.com Fri Jul 5 02:11:09 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Fri, 5 Jul 2013 11:11:09 +0200 Subject: Support for Apple Extensions In-Reply-To: References: Message-ID: On Jul 5, 2013, at 10:51 AM, Kustaa Nyholm wrote: > On 05/07/2013 11:45, "Stephen Winnall" wrote: >> >> Any Mac Java client that wants to have a chance of market acceptance will >> use them extensively. > > Yes, I'll second that, without them the acceptance among apple users is > poor to nil. +1 -hendrik From kaydell.leavitt at icloud.com Fri Jul 5 02:20:38 2013 From: kaydell.leavitt at icloud.com (Kaydell Leavitt) Date: Fri, 05 Jul 2013 03:20:38 -0600 Subject: Support for Apple Extensions In-Reply-To: <51D68C11.2000900@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> Message-ID: <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> Hi Alan, I would say that I absolutely need the following things: 1. JFileChooser Save dialog that is native for both files and for folders 2. JFileChooser Open dialog that is native for both files and folders. 3. Print Command that is native 4. A menu jar at the top of the screen -- not at the top of the window. (Where a Mac user expects it to be.) 5. Preferences menu item where it is expected to be (in the application menu calling an ApplicationListener) 6. About menu item where it is expected to be (in the application menu calling an ApplicationListener) 7. The quit menu item working in where the user expects it (in the application menu calling an ApplicationListener). 8. The Services menu should just work. I think that would work for me. So, the com.apple.Application class is in limbo? What about the new Application class in JavaFX? Where does that stand? -- Kaydell kaydell.leavitt at icloud.com http://learnbymac.com On Jul 5, 2013, at 3:04 AM, Alan Bateman wrote: > On 05/07/2013 09:53, Paul Taylor wrote: >> This was discussed this in some detail last Autumn, and we were assured that support would be continued, and on a postive note from my own experience Ive found everything I need does all work on the 1.7.0_40_ea-b291 release. Alan I would suggest you discuss this with the oracle developers who were looking at this back then. At the time I also requested it should be properly documented but the response on that was pretty divided. > I think the right thing is to understand which of these com.apple APIs are commonly used as it may may sense to add standard APIs for some of these cases. If you links to the discussion from "last Autumn" that would be useful. > > -Alan From kortenkamp at cinderella.de Fri Jul 5 02:35:36 2013 From: kortenkamp at cinderella.de (Ulrich Kortenkamp) Date: Fri, 5 Jul 2013 11:35:36 +0200 Subject: Support for Apple Extensions In-Reply-To: <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> Message-ID: Yes, these are definitely necessary. And? as a Developer I?d appreciate not having to change the mechanisms again. If the APIs wouldn?t change, we could still run our old code from ten years ago. Ulli On 05 Jul 2013, at 11:20, Kaydell Leavitt wrote: > Hi Alan, > > I would say that I absolutely need the following things: > > 1. JFileChooser Save dialog that is native for both files and for folders > 2. JFileChooser Open dialog that is native for both files and folders. > 3. Print Command that is native > 4. A menu jar at the top of the screen -- not at the top of the window. (Where a Mac user expects it to be.) > 5. Preferences menu item where it is expected to be (in the application menu calling an ApplicationListener) > 6. About menu item where it is expected to be (in the application menu calling an ApplicationListener) > 7. The quit menu item working in where the user expects it (in the application menu calling an ApplicationListener). > 8. The Services menu should just work. > > I think that would work for me. > > So, the com.apple.Application class is in limbo? What about the new Application class in JavaFX? Where does that stand? > > -- Kaydell > kaydell.leavitt at icloud.com > http://learnbymac.com > > > > > On Jul 5, 2013, at 3:04 AM, Alan Bateman wrote: > >> On 05/07/2013 09:53, Paul Taylor wrote: >>> This was discussed this in some detail last Autumn, and we were assured that support would be continued, and on a postive note from my own experience Ive found everything I need does all work on the 1.7.0_40_ea-b291 release. Alan I would suggest you discuss this with the oracle developers who were looking at this back then. At the time I also requested it should be properly documented but the response on that was pretty divided. >> I think the right thing is to understand which of these com.apple APIs are commonly used as it may may sense to add standard APIs for some of these cases. If you links to the discussion from "last Autumn" that would be useful. >> >> -Alan From Alan.Bateman at oracle.com Fri Jul 5 02:36:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Jul 2013 10:36:24 +0100 Subject: Support for Apple Extensions In-Reply-To: References: Message-ID: <51D69398.2090908@oracle.com> On 05/07/2013 10:11, Hendrik Schreiber wrote: > On Jul 5, 2013, at 10:51 AM, Kustaa Nyholm wrote: > >> On 05/07/2013 11:45, "Stephen Winnall" wrote: >>> Any Mac Java client that wants to have a chance of market acceptance will >>> use them extensively. >> Yes, I'll second that, without them the acceptance among apple users is >> poor to nil. > +1 > > -hendrik Can you elaborate? -- ie: list down the com.apple APIs that are you using so that there is some sense as to which of these APIs is being used. -Alan. From darrell.berry at realsimpleinnovation.com Fri Jul 5 02:55:43 2013 From: darrell.berry at realsimpleinnovation.com (Darrell Berry) Date: Fri, 5 Jul 2013 19:55:43 +1000 Subject: Support for Apple Extensions In-Reply-To: <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> Message-ID: That lists works for me too On 5 Jul 2013, at 19:20, Kaydell Leavitt wrote: > Hi Alan, > > I would say that I absolutely need the following things: > > 1. JFileChooser Save dialog that is native for both files and for folders > 2. JFileChooser Open dialog that is native for both files and folders. > 3. Print Command that is native > 4. A menu jar at the top of the screen -- not at the top of the window. (Where a Mac user expects it to be.) > 5. Preferences menu item where it is expected to be (in the application menu calling an ApplicationListener) > 6. About menu item where it is expected to be (in the application menu calling an ApplicationListener) > 7. The quit menu item working in where the user expects it (in the application menu calling an ApplicationListener). > 8. The Services menu should just work. > > I think that would work for me. > > So, the com.apple.Application class is in limbo? What about the new Application class in JavaFX? Where does that stand? > > -- Kaydell > kaydell.leavitt at icloud.com > http://learnbymac.com > > > > > On Jul 5, 2013, at 3:04 AM, Alan Bateman wrote: > >> On 05/07/2013 09:53, Paul Taylor wrote: >>> This was discussed this in some detail last Autumn, and we were assured that support would be continued, and on a postive note from my own experience Ive found everything I need does all work on the 1.7.0_40_ea-b291 release. Alan I would suggest you discuss this with the oracle developers who were looking at this back then. At the time I also requested it should be properly documented but the response on that was pretty divided. >> I think the right thing is to understand which of these com.apple APIs are commonly used as it may may sense to add standard APIs for some of these cases. If you links to the discussion from "last Autumn" that would be useful. >> >> -Alan > From kortenkamp at cinderella.de Fri Jul 5 02:58:04 2013 From: kortenkamp at cinderella.de (Ulrich Kortenkamp) Date: Fri, 5 Jul 2013 11:58:04 +0200 Subject: Support for Apple Extensions In-Reply-To: <51D69398.2090908@oracle.com> References: <51D69398.2090908@oracle.com> Message-ID: <59201378-2554-4D83-BCC4-AE615C8E0369@cinderella.de> On 05 Jul 2013, at 11:36, Alan Bateman wrote: > On 05/07/2013 10:11, Hendrik Schreiber wrote: >> On Jul 5, 2013, at 10:51 AM, Kustaa Nyholm wrote: >> >>> On 05/07/2013 11:45, "Stephen Winnall" wrote: >>>> Any Mac Java client that wants to have a chance of market acceptance will >>>> use them extensively. >>> Yes, I'll second that, without them the acceptance among apple users is >>> poor to nil. >> +1 >> >> -hendrik > Can you elaborate? -- ie: list down the com.apple APIs that are you using so that there is some sense as to which of these APIs is being used. > > -Alan. That?s easy: import com.apple.eawt.ApplicationEvent; import com.apple.eawt.ApplicationListener; com.apple.eawt.Application.getApplication().addAboutMenuItem(); com.apple.eawt.Application.getApplication().addApplicationListener(new OSXApplicationListener()); (where OSXApplicationListener implements all the methods from ApplicationListener). Ulli From paul_t100 at fastmail.fm Fri Jul 5 03:01:05 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 05 Jul 2013 11:01:05 +0100 Subject: Support for Apple Extensions In-Reply-To: <51D68C11.2000900@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> Message-ID: <51D69961.90500@fastmail.fm> On 05/07/2013 10:04, Alan Bateman wrote: > On 05/07/2013 09:53, Paul Taylor wrote: >> This was discussed this in some detail last Autumn, and we were >> assured that support would be continued, and on a postive note from >> my own experience Ive found everything I need does all work on the >> 1.7.0_40_ea-b291 release. Alan I would suggest you discuss this with >> the oracle developers who were looking at this back then. At the time >> I also requested it should be properly documented but the response on >> that was pretty divided. > I think the right thing is to understand which of these com.apple APIs > are commonly used as it may may sense to add standard APIs for some of > these cases. If you links to the discussion from "last Autumn" that > would be useful. > > -Alan > Ok, this was the starting point http://lists.apple.com/archives/java-dev/2012/Aug/msg00004.html sorry cant find the one about documententation. The Features I am successfully using in Java 7 OSX with the latest preview release are: -Dapple.laf.useScreenMenuBar=true for OSX menu bar -Dapple.awt.brushMetalLook=true for a brushed metal look FileManager.moveToTrash(file) to move files to trash rather than hard delete Application.getApplication().openHelpViewer() to open Apple Help book Application.getApplication().setDockIconBadge() to set a count of files processed on my dock icon Application.getApplication().setAboutHandler() to handle About correctly Application.getApplication().setPreferencesHandler to handle preferences correctly Application.getApplication().setQuitHandler Application.getApplication().disableSuddenTermination(); Application.getApplication().setQuitStrategy(); for application exiting Application.getApplication().requestUserAttention() to bring things to usee attention System.setProperty("apple.awt.fileDialogForDirectories", "true"); FileDialog chooser = new FileDialog(SongKong.mainWindow.frame); to allow folder to be open (not files) using a native dialog FileManager.getPathToApplicationBundle() to find said location In my Java 6 application I make use of some of the specific Apple client properties for button types such as the search button and the mini controls. I would also like to see some things that the Quaqua project http://www.randelshofer.ch/quaqua/guide/index.html supports such as Jsheet incorporated into the core api. Paul From christopherbrown06 at gmail.com Fri Jul 5 03:03:09 2013 From: christopherbrown06 at gmail.com (Christopher Brown) Date: Fri, 5 Jul 2013 12:03:09 +0200 Subject: Support for Apple Extensions In-Reply-To: <51D68C11.2000900@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> Message-ID: Hello, It would be nice to maintain (for existing applications) the old APIs, and provide a more cross-platform way to use thereafter (which would avoid reflection hacks for new code). Some inspiration for a standard cross-platform API can be found in the Eclipse SWT APIs, for example : http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet348.java http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet354.java These examples are related to the Mac menu bar, there are other system-specific integration points that are handled nicely to. It's similar to feature-testing in java.awt.Desktop (or feature availability testing in modern browsers from JavaScript). -- Christopher On 5 July 2013 11:04, Alan Bateman wrote: > On 05/07/2013 09:53, Paul Taylor wrote: >> >> This was discussed this in some detail last Autumn, and we were assured >> that support would be continued, and on a postive note from my own >> experience Ive found everything I need does all work on the >> 1.7.0_40_ea-b291 release. Alan I would suggest you discuss this with the >> oracle developers who were looking at this back then. At the time I also >> requested it should be properly documented but the response on that was >> pretty divided. > > I think the right thing is to understand which of these com.apple APIs are > commonly used as it may may sense to add standard APIs for some of these > cases. If you links to the discussion from "last Autumn" that would be > useful. > > -Alan From mik3hall at gmail.com Fri Jul 5 03:04:18 2013 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 5 Jul 2013 05:04:18 -0500 Subject: Support for Apple Extensions In-Reply-To: <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> Message-ID: On Jul 5, 2013, at 4:20 AM, Kaydell Leavitt wrote: > I would say that I absolutely need the following things: > > 1. JFileChooser Save dialog that is native for both files and for folders > 2. JFileChooser Open dialog that is native for both files and folders. I seem to remember at one point a lot of people considered the JFileChooser implementation not the best. Using AWT FileDialog's was a widely recommended alternative. There was also Werner Randelshofer's Quaqua project. I'm not sure that's actively supported by Werner anymore? I thought saw it was open sourced somewhere now? Might be misremembering. This would normally not be considered part of the Apple Extensions. The extensions enabled java applications to behave in the usual ways as normal OS X desktop applications. For exa,[;e they handled standard AppleEvents like opening associated double clicked files, print events, etc. Screen menubar was supported through the usual API implementations with unique Mac system properties. Again not through the extensions. There were other helper functions to native methods commonly needed by OS X desktop applications. Eliminating this support, if they don't integrate them into java api's somehow would further disadvantage OS X java applications versus more native supported ones. Finding the html doc on the Apple pages doesn't look so easy these days. I did come across this for anyone considering it from Oracle? Bug ID: 8008714 [macosx] packages com.apple.eawt and com.apple.eio are not included in symbol file in JDK 7 and 8 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008714 I don't know what the symbol file is that it is talking about but these are the "Apple Extensions" Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From christopherbrown06 at gmail.com Fri Jul 5 03:14:33 2013 From: christopherbrown06 at gmail.com (Christopher Brown) Date: Fri, 5 Jul 2013 12:14:33 +0200 Subject: Packaging Java Applications targeting Apple Java 6 and Oracle Java 7+ Message-ID: Hello, I have a question about on-going availability of the /usr/libexec/java_home Mac OS X command. I've been following the different threads about the different ways of bundling a Java application as an ".app" with Mac OS X, using either JavaApplicationStub (which I've done in the past) or using the equivalent tool for Java 7 onwards. It would seem that that implies creating two variants of the application and hoping that the user picks the right one. The long-term recommended solution would appear to be "use the Oracle", for obvious reasons. However, given that on a new project, we're going to use SWT instead of Swing, we've created an ".app" bundle that starts Java using an embedded ".sh" script (and neither stub, which conveniently side-steps needing to choose one stub or another, and avoids two versions). It relies on /usr/libexec/java_home and currently works fine. I'm probably safe in assuming that at some point (OS X Mavericks / 10.9), the Apple Java 6 will be withdrawn. However, it would be great to have confirmation that the "java_home" command will continue to be supported and provided (as opposed to going down some hacky script that assumes paths, parses paths, and tries to sort them to pick the best version). Thanks in advance, Christopher From artem.ananiev at oracle.com Fri Jul 5 03:18:26 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 05 Jul 2013 14:18:26 +0400 Subject: Support for Apple Extensions In-Reply-To: <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> Message-ID: <51D69D72.60201@oracle.com> On 7/5/2013 1:20 PM, Kaydell Leavitt wrote: > Hi Alan, > > I would say that I absolutely need the following things: > > 1. JFileChooser Save dialog that is native for both files and for folders > 2. JFileChooser Open dialog that is native for both files and folders. > 3. Print Command that is native > 4. A menu jar at the top of the screen -- not at the top of the window. (Where a Mac user expects it to be.) > 5. Preferences menu item where it is expected to be (in the application menu calling an ApplicationListener) > 6. About menu item where it is expected to be (in the application menu calling an ApplicationListener) > 7. The quit menu item working in where the user expects it (in the application menu calling an ApplicationListener). > 8. The Services menu should just work. > > I think that would work for me. All the above is UI related stuff (eAWT). It should work in JDK7/8 as it worked in Apple JDK6, since the code was contributed to OpenJDK by Apple with little or no modifications. Note, however, that it is not as supported as public APIs in java.* and javax.* namespace. We don't have any plans to drop support for eAWT, but all the issues in these classes will be of lower priority by default. What about eIO? Is it used by anybody? > So, the com.apple.Application class is in limbo? What about the new Application class in JavaFX? Where does that stand? Application is in com.apple.eawt, it's still there as it was in JDK6. It is not related to JavaFX Application. Thanks, Artem > -- Kaydell > kaydell.leavitt at icloud.com > http://learnbymac.com > > > > > On Jul 5, 2013, at 3:04 AM, Alan Bateman wrote: > >> On 05/07/2013 09:53, Paul Taylor wrote: >>> This was discussed this in some detail last Autumn, and we were assured that support would be continued, and on a postive note from my own experience Ive found everything I need does all work on the 1.7.0_40_ea-b291 release. Alan I would suggest you discuss this with the oracle developers who were looking at this back then. At the time I also requested it should be properly documented but the response on that was pretty divided. >> I think the right thing is to understand which of these com.apple APIs are commonly used as it may may sense to add standard APIs for some of these cases. If you links to the discussion from "last Autumn" that would be useful. >> >> -Alan > From Fabrizio.Giudici at tidalwave.it Fri Jul 5 03:26:28 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Fri, 05 Jul 2013 12:26:28 +0200 Subject: Support for Apple Extensions In-Reply-To: References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> Message-ID: On Fri, 05 Jul 2013 12:04:18 +0200, Michael Hall wrote: > widely recommended alternative. There was also Werner Randelshofer's > Quaqua project. I'm not sure that's actively supported by Werner > anymore? I thought saw it was open sourced somewhere now? Might be > misremembering. Quaqua is open source, but has not received updates in recent times, even though Werner responded to ping. My current opinion is that Qauqua is an excellent work, but now is for legacy (maintaining existing Swing code). Note that JavaFX FileChooser is native, even though somewhat limited for now. IMO for any new development - unless there are showstoppers - JavaFX is the way to go and AquaFX (http://aquafx-project.com/) the way to be native on Mac OS X, hoping that the project receives the required attention by the community. Note that it's targeted at JDK 8, but today you can take the CSS, comment out the skin references, and already have some improvement with JDK 7. Whether this is good or not for a production environment is something that I'm still studying. But it sounds as the standard way starting from JDK 8. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From krueger at lesspain.de Fri Jul 5 04:29:28 2013 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Fri, 5 Jul 2013 13:29:28 +0200 Subject: Support for Apple Extensions In-Reply-To: <51D69D72.60201@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D69D72.60201@oracle.com> Message-ID: On Fri, Jul 5, 2013 at 12:18 PM, Artem Ananiev wrote: > > On 7/5/2013 1:20 PM, Kaydell Leavitt wrote: >> >> Hi Alan, >> >> I would say that I absolutely need the following things: >> >> 1. JFileChooser Save dialog that is native for both files and for folders >> 2. JFileChooser Open dialog that is native for both files and folders. >> 3. Print Command that is native >> 4. A menu jar at the top of the screen -- not at the top of the window. >> (Where a Mac user expects it to be.) >> 5. Preferences menu item where it is expected to be (in the application >> menu calling an ApplicationListener) >> 6. About menu item where it is expected to be (in the application menu >> calling an ApplicationListener) >> 7. The quit menu item working in where the user expects it (in the >> application menu calling an ApplicationListener). >> 8. The Services menu should just work. >> >> I think that would work for me. > > > All the above is UI related stuff (eAWT). It should work in JDK7/8 as it > worked in Apple JDK6, since the code was contributed to OpenJDK by Apple > with little or no modifications. Note, however, that it is not as supported > as public APIs in java.* and javax.* namespace. We don't have any plans to > drop support for eAWT, but all the issues in these classes will be of lower > priority by default. > > What about eIO? Is it used by anybody? Yep. We use com.apple.eio.FileManager.revealInFinder(File) and com.apple.eio.FileManager.moveToTrash(File) although, to be honest, it would probably not be a too terrible thing to replace those by native calls to their NSFileManager counterparts via JNA or something similar. From paul_t100 at fastmail.fm Fri Jul 5 04:37:48 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 05 Jul 2013 12:37:48 +0100 Subject: Support for Apple Extensions In-Reply-To: References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D69D72.60201@oracle.com> Message-ID: <51D6B00C.9070508@fastmail.fm> On 05/07/2013 12:29, Robert Kr?ger wrote: > On Fri, Jul 5, 2013 at 12:18 PM, Artem Ananiev wrote: >> On 7/5/2013 1:20 PM, Kaydell Leavitt wrote: >>> Hi Alan, >>> >>> I would say that I absolutely need the following things: >>> >>> 1. JFileChooser Save dialog that is native for both files and for folders >>> 2. JFileChooser Open dialog that is native for both files and folders. >>> 3. Print Command that is native >>> 4. A menu jar at the top of the screen -- not at the top of the window. >>> (Where a Mac user expects it to be.) >>> 5. Preferences menu item where it is expected to be (in the application >>> menu calling an ApplicationListener) >>> 6. About menu item where it is expected to be (in the application menu >>> calling an ApplicationListener) >>> 7. The quit menu item working in where the user expects it (in the >>> application menu calling an ApplicationListener). >>> 8. The Services menu should just work. >>> >>> I think that would work for me. >> >> All the above is UI related stuff (eAWT). It should work in JDK7/8 as it >> worked in Apple JDK6, since the code was contributed to OpenJDK by Apple >> with little or no modifications. Note, however, that it is not as supported >> as public APIs in java.* and javax.* namespace. We don't have any plans to >> drop support for eAWT, but all the issues in these classes will be of lower >> priority by default. >> >> What about eIO? Is it used by anybody? > Yep. We use com.apple.eio.FileManager.revealInFinder(File) and > com.apple.eio.FileManager.moveToTrash(File) although, to be honest, it > would probably not be a too terrible thing to replace those by native > calls to their NSFileManager counterparts via JNA or something > similar. > But it would be difficult for many Java developers like me who choose Java so they can write cross-platform applications without having to fully understand the intricacies of the native OS, I have never written anything that directly makes MacOS calls Paul From Alan.Bateman at oracle.com Fri Jul 5 04:45:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Jul 2013 12:45:12 +0100 Subject: Support for Apple Extensions In-Reply-To: <51D69D72.60201@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D69D72.60201@oracle.com> Message-ID: <51D6B1C8.7060007@oracle.com> On 05/07/2013 11:18, Artem Ananiev wrote: > > : > > What about eIO? Is it used by anybody? I'm interesting in hearing about that too as it looks like FileManager defines a few things that might be more appropriate for java.awt.Desktop. Methods to access a file's type/creator codes that could easily be handled via the file system API (I think Michael Hall's FileSystemProvider might already do this). -Alan. From Erik.Vanherck at inventivegroup.com Fri Jul 5 05:09:02 2013 From: Erik.Vanherck at inventivegroup.com (Erik Vanherck) Date: Fri, 5 Jul 2013 12:09:02 +0000 Subject: Java 1.6.0_51 regressions, somewhere we can download an alternative ? In-Reply-To: References: Message-ID: <41112672-45F6-48BE-B05D-8AEB66E97455@inventivegroup.com> Hi Mike, 1. yes the blockers which prevent us from using Java 7/8 (as is available atm are) on OS X - http://bugs.sun.com/view_bug.do?bug_id=7154778 and its sibling https://bugs.eclipse.org/bugs/show_bug.cgi?id=374199 - http://bugs.sun.com/view_bug.do?bug_id=8011686 - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003169 - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005928 - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004821 - http://bugs.sun.com/view_bug.do?bug_id=8006941 There are others but they are just minor annoyances, nothing major. And basically only the first one is a big issue. All of these should be fixed in _40. We have back ported the SWT changes required for the first one and initial testing looked good but we are still experiencing deadlocks in some cases deep in AWT when disconnecting external screens and using mutiple awt frames in the same app. They are hard to reproduce but we are in the process of figuring out if we can work around them or we need to log it as an issue. 2. The blocker for java 6 was reported at Oracle since it affects both Apple 1.6.0_51 and 1.7.0_25 as its clear from the traces that it originates in Oracle maintained code. It's the entire AppContext mess thats now being called from non-GUI code. http://bugs.sun.com/view_bug.do?bug_id=8019496 If you want I can refile it in the Apple database as well. Note that _40 is a good candidate for us to move to (if we can figure out the deadlock issue), but the EA builds do not yet contain the fixes from _51 and _25 which will cause the exact same issues and possible break that one as well. The AppContext issue is most likely the same as other threads I've seen passing about GWT plugins no longer working in Eclipse and other non-gui apps locking up. Thanks for the link to the downloads, I can swear I looked there before and came up with empty searches. Must be user not being awake enough error probably :) And yes I agree, this is in no means meant for anyone outside. Installing old java releases is a bad idea. We just have a couple of devs which were completely locked out of their work. We explicitly disable java in browsers since we don't do any applet or webstart development. Will try the moving dirs arround as the eclipse executables use JNI and we can't point them to the Apple 1.6 jvmlib.dnylib as it doesn't contain the JNI_CreateJava method so it still ends up going to the platform default one provided by the JavaVM Framework. On 03 Jul 2013, at 18:13, Mike Swingler > wrote: On Jul 3, 2013, at 5:18 AM, Erik Vanherck > wrote: Hi, Just wondering since some of us are really completly stuck (oracle java 1.7 isn't mature enough yet and Java 1.6 is broken) any place we can get an older release ? Due to the regressions caused by _51 (not the swing issue which has been hotfixed but others http://bugs.sun.com/view_bug.do?bug_id=8019496), is there any place we can still download a dmg for an older Apple java release ? It doesn't need to be a jre which plugs in a browsers. It's simply a stop gap to help out all the folks with the desktop apps having issues. A JDK would be fine for instance. 1. Are there bugs filed at > for the issues that are blocking you from adopting Java 7/8? What are the bug numbers? 2. Are there bugs filed at > for the regressions in Java SE 6? What are the bug numbers? If we know what the specific issues are, and we have test cases or a copy of your application that can reproduce them, we can ensure that they get fixed for everyone, instead of telling people how to install old software and put their machine into an unsupported state. You can download the Java Developer packages for older releases at: . This will install a JDK in /Library/Java/JavaVirtualMachines, which you can manually request on the command-line for testing/regressing issues. This, by itself, is supported. If you need to disable the internal system JVM at /System/Library/Java/JavaVirtualMachines and rely on one of the Developer JDKs, please move the 1.6.0.jdk aside into a "disabled" directory, so that you can swap it back in when you need to restore your system or do quick comparison testing. This configuration is not supported, but it is unlikely to cause serious problems. This will make your web browsing experience vulnerable if you are on Snow Leopard, or if you have specifically re-enabled the Java SE 6 applet plug-in and Web Start on Lion or Mountain Lion. Please use the Oracle Java 7 applet plug-in, if at all possible. Other modifications to the system JavaVM.framework or other system frameworks are very unsupported, and are unlikely to actually have the effect you intend. Regards, Mike Swingler Apple Inc. ________________________________ Inventive Designers' Email Disclaimer: http://www.inventivedesigners.com/email-disclaimer From hs at tagtraum.com Fri Jul 5 05:59:47 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Fri, 5 Jul 2013 14:59:47 +0200 Subject: Support for Apple Extensions In-Reply-To: <51D6B1C8.7060007@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D69D72.60201@oracle.com> <51D6B1C8.7060007@oracle.com> Message-ID: <0256293E-D071-4997-8B2B-DC1A00FD55F4@tagtraum.com> On Jul 5, 2013, at 1:45 PM, Alan Bateman wrote: > On 05/07/2013 11:18, Artem Ananiev wrote: >> >> : >> >> What about eIO? Is it used by anybody? > I'm interesting in hearing about that too as it looks like FileManager defines a few things that might be more appropriate for java.awt.Desktop. Methods to access a file's type/creator codes that could easily be handled via the file system API (I think Michael Hall's FileSystemProvider might already do this). From the eio package I'm using mostly FileManager methods: - findFolder - moveToTrash - revealInFinder From the eawt package: - Application and its listeners - FullScreenUtilities However, Mac users typically like all their app to behave the same and take advantage of the newest OS features. So more is usually better here... -hendrik From alexandr.scherbatiy at oracle.com Fri Jul 5 06:47:51 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 05 Jul 2013 17:47:51 +0400 Subject: [7u40] Review request for 8019628: [macosx] closed/java/awt/Modal/BlockedMouseInputTest/BlockedMouseInputTest.html failed since 7u40b30 on MacOS Message-ID: <51D6CE87.70907@oracle.com> Hello, Could you review the fix for the regression in JDK 7u40: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8019628 webrev: http://cr.openjdk.java.net/~alexsch/8019628/webrev.00 Generated enter/exit mouse events have been changed to use the current mouse event id during the last merge in the JDK 7u40: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/diff/9062acbc098c/src/macosx/classes/sun/lwawt/LWWindowPeer.java For example ------------------------------- Point oldp = lastMouseEventPeer.windowToLocal(x, y, this); - postEvent(new MouseEvent(lastMouseEventPeer.getTarget(), - MouseEvent.MOUSE_EXITED, - when, modifiers, - oldp.x, oldp.y, screenX, screenY, - clickCount, popupTrigger, button)); + Component target = lastMouseEventPeer.getTarget(); + postMouseEnteredExitedEvent(target, id, when, modifiers, oldp, + screenX, screenY, clickCount, popupTrigger, button); ------------------------------- So the mouse enter/exit events are now can be lost and wrong events can be sent for the lastMouseEventPeer. The fix adds the explicit mouse enter/exit events declaration back as it was before the merge. There are 2 failed tests in the JDK 7u repository because of the regression so it is not necessary to write new one. Thanks, Alexandr. From steve at winnall.ch Fri Jul 5 06:48:53 2013 From: steve at winnall.ch (Stephen Winnall) Date: Fri, 5 Jul 2013 15:48:53 +0200 Subject: Support for Apple Extensions In-Reply-To: References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> Message-ID: AquaFX looks interesting and may form the basis for a Mac look, but there remains the question of the feel: shortcuts, menus, file system conventions, interactions with the desktop ( just to mention a few off the top of my head). If we're talking about standardising through common APIs, Java needs a well-defined platform abstractionAPI in my view, which takes account of desktops in general (Mac, Windows, Linux) and mobiles too. It should be less a question of what has to be done to keep the Mac freaks quiet and more "what do platforms in general provide and how can we make it available and useful?". Steve On 05.07.2013, at 12:26, "Fabrizio Giudici" wrote: > On Fri, 05 Jul 2013 12:04:18 +0200, Michael Hall wrote: > > >> widely recommended alternative. There was also Werner Randelshofer's Quaqua project. I'm not sure that's actively supported by Werner anymore? I thought saw it was open sourced somewhere now? Might be misremembering. > > Quaqua is open source, but has not received updates in recent times, even though Werner responded to ping. > > My current opinion is that Qauqua is an excellent work, but now is for legacy (maintaining existing Swing code). Note that JavaFX FileChooser is native, even though somewhat limited for now. > > IMO for any new development - unless there are showstoppers - JavaFX is the way to go and AquaFX (http://aquafx-project.com/) the way to be native on Mac OS X, hoping that the project receives the required attention by the community. Note that it's targeted at JDK 8, but today you can take the CSS, comment out the skin references, and already have some improvement with JDK 7. Whether this is good or not for a production environment is something that I'm still studying. But it sounds as the standard way starting from JDK 8. > > > > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From Sergey.Bylokhov at oracle.com Fri Jul 5 06:53:43 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 05 Jul 2013 17:53:43 +0400 Subject: [7u40] Review request for 8019628: [macosx] closed/java/awt/Modal/BlockedMouseInputTest/BlockedMouseInputTest.html failed since 7u40b30 on MacOS In-Reply-To: <51D6CE87.70907@oracle.com> References: <51D6CE87.70907@oracle.com> Message-ID: <51D6CFE7.6090103@oracle.com> Hi, Alexander. Fix looks good. On 05.07.2013 17:47, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix for the regression in JDK 7u40: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8019628 > webrev: http://cr.openjdk.java.net/~alexsch/8019628/webrev.00 > > Generated enter/exit mouse events have been changed to use the current > mouse event id during the last merge in the JDK 7u40: > http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/diff/9062acbc098c/src/macosx/classes/sun/lwawt/LWWindowPeer.java > > For example > ------------------------------- > Point oldp = lastMouseEventPeer.windowToLocal(x, y, this); > - postEvent(new MouseEvent(lastMouseEventPeer.getTarget(), > - MouseEvent.MOUSE_EXITED, > - when, modifiers, > - oldp.x, oldp.y, screenX, screenY, > - clickCount, popupTrigger, button)); > + Component target = lastMouseEventPeer.getTarget(); > + postMouseEnteredExitedEvent(target, id, when, modifiers, oldp, > + screenX, screenY, clickCount, popupTrigger, button); > ------------------------------- > > > So the mouse enter/exit events are now can be lost and wrong events > can be sent for the lastMouseEventPeer. > The fix adds the explicit mouse enter/exit events declaration back as > it was before the merge. > > There are 2 failed tests in the JDK 7u repository because of the > regression so it is not necessary to write new one. > > Thanks, > Alexandr. > -- Best regards, Sergey. From swpalmer at gmail.com Fri Jul 5 07:19:09 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 5 Jul 2013 10:19:09 -0400 Subject: Support for Apple Extensions In-Reply-To: <0256293E-D071-4997-8B2B-DC1A00FD55F4@tagtraum.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D69D72.60201@oracle.com> <51D6B1C8.7060007@oracle.com> <0256293E-D071-4997-8B2B-DC1A00FD55F4@tagtraum.com> Message-ID: <74C0C565-CD99-4CEB-A124-DF5F8E1941E6@gmail.com> Note that the JavaFX menu bar has full-screen support as a supported feature. Though JavaFX needs support for the Apple "Application" menu. I think the FileManager methods listed below should all have cross-platform equivalents. Some new APIs came in with Java 7... But I don't see equivalents for these FileManager APIs. The event-based open document stuff seems to be exclusively Mac, but we still need an API. Scott On 2013-07-05, at 8:59 AM, Hendrik Schreiber wrote: > > On Jul 5, 2013, at 1:45 PM, Alan Bateman wrote: > >> On 05/07/2013 11:18, Artem Ananiev wrote: >>> >>> : >>> >>> What about eIO? Is it used by anybody? >> I'm interesting in hearing about that too as it looks like FileManager defines a few things that might be more appropriate for java.awt.Desktop. Methods to access a file's type/creator codes that could easily be handled via the file system API (I think Michael Hall's FileSystemProvider might already do this). > > From the eio package I'm using mostly FileManager methods: > > - findFolder > - moveToTrash > - revealInFinder > > From the eawt package: > > - Application and its listeners > - FullScreenUtilities > > However, Mac users typically like all their app to behave the same and take advantage of the newest OS features. > So more is usually better here... > > -hendrik From artem.ananiev at oracle.com Fri Jul 5 07:31:47 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 05 Jul 2013 18:31:47 +0400 Subject: Support for Apple Extensions In-Reply-To: References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D69D72.60201@oracle.com> Message-ID: <51D6D8D3.2050603@oracle.com> On 7/5/2013 3:29 PM, Robert Kr?ger wrote: > On Fri, Jul 5, 2013 at 12:18 PM, Artem Ananiev wrote: >> >> On 7/5/2013 1:20 PM, Kaydell Leavitt wrote: >>> >>> Hi Alan, >>> >>> I would say that I absolutely need the following things: >>> >>> 1. JFileChooser Save dialog that is native for both files and for folders >>> 2. JFileChooser Open dialog that is native for both files and folders. >>> 3. Print Command that is native >>> 4. A menu jar at the top of the screen -- not at the top of the window. >>> (Where a Mac user expects it to be.) >>> 5. Preferences menu item where it is expected to be (in the application >>> menu calling an ApplicationListener) >>> 6. About menu item where it is expected to be (in the application menu >>> calling an ApplicationListener) >>> 7. The quit menu item working in where the user expects it (in the >>> application menu calling an ApplicationListener). >>> 8. The Services menu should just work. >>> >>> I think that would work for me. >> >> >> All the above is UI related stuff (eAWT). It should work in JDK7/8 as it >> worked in Apple JDK6, since the code was contributed to OpenJDK by Apple >> with little or no modifications. Note, however, that it is not as supported >> as public APIs in java.* and javax.* namespace. We don't have any plans to >> drop support for eAWT, but all the issues in these classes will be of lower >> priority by default. >> >> What about eIO? Is it used by anybody? > > Yep. We use com.apple.eio.FileManager.revealInFinder(File) and > com.apple.eio.FileManager.moveToTrash(File) although, to be honest, it > would probably not be a too terrible thing to replace those by native > calls to their NSFileManager counterparts via JNA or something > similar. As someone (Alan?) wrote in previous emails, these actions look like good candidates for java.awt.Desktop enhancements and can be implemented on other platforms than Mac OS X. I didn't look to these two methods, but at a glance, revealInFinder() is very close to Desktop.browse(), and moveToTrash() can be Desktop.remove(). Thanks, Artem From Fabrizio.Giudici at tidalwave.it Fri Jul 5 09:08:05 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Fri, 05 Jul 2013 18:08:05 +0200 Subject: Support for Apple Extensions In-Reply-To: References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> Message-ID: On Fri, 05 Jul 2013 15:48:53 +0200, Stephen Winnall wrote: > AquaFX looks interesting and may form the basis for a Mac look, but > there remains the question of the feel: shortcuts, menus, file system > conventions, interactions with the desktop ( just to mention a few off > the top of my head). > > If we're talking about standardising through common APIs, Java needs a > well-defined platform abstractionAPI in my view, which takes account of > desktops in general (Mac, Windows, Linux) and mobiles too. It should be > less a question of what has to be done to keep the Mac freaks quiet and > more "what do platforms in general provide and how can we make it > available and useful?". Agreed. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From Alan.Bateman at oracle.com Fri Jul 5 09:40:59 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Jul 2013 17:40:59 +0100 Subject: Support for Apple Extensions In-Reply-To: References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> Message-ID: <51D6F71B.90308@oracle.com> On 05/07/2013 11:04, Michael Hall wrote: > > I did come across this for anyone considering it from Oracle? > Bug ID: 8008714 [macosx] packages com.apple.eawt and com.apple.eio are not included in symbol file in JDK 7 and 8 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008714 > > I don't know what the symbol file is that it is talking about but these are the "Apple Extensions" > I didn't see any replies to this but the symbol file here refers to something that the javac uses. As the com.apple APIs were not added to this mechanism then it means that an attempt to compile something that uses com.apple APIs will fail (unless one compiles with a super secret option that disables the symbol file). So now I'm curious to ask those using com.apple.eawt and com.apple.eio as to whether they have run into this? If not then does it mean you are compiling on 6 but running on 7? -Alan From Johannes.Schindelin at gmx.de Fri Jul 5 09:44:05 2013 From: Johannes.Schindelin at gmx.de (Johannes Schindelin) Date: Fri, 5 Jul 2013 18:44:05 +0200 (CEST) Subject: Support for Apple Extensions In-Reply-To: <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> Message-ID: Hi Alan, On Fri, 5 Jul 2013, Kaydell Leavitt wrote: > I would say that I absolutely need the following things: > > 1. JFileChooser Save dialog that is native for both files and for folders > 2. JFileChooser Open dialog that is native for both files and folders. > 3. Print Command that is native > 4. A menu jar at the top of the screen -- not at the top of the window. (Where a Mac user expects it to be.) > 5. Preferences menu item where it is expected to be (in the application menu calling an ApplicationListener) > 6. About menu item where it is expected to be (in the application menu calling an ApplicationListener) > 7. The quit menu item working in where the user expects it (in the application menu calling an ApplicationListener). > 8. The Services menu should just work. In addition, we are heavy users of handleOpenFile() and handleAbout(), printFiles(), handleQuitRequestWith(), userSessionActivated(), userSessionDeactivated(), systemAboutToSleep(), systemAwoke(), screenAboutToSleep(), screenAwoke(), appHidden, appUnhidden(), appMovedToBackground(), appRaisedToForeground, and appReOpened(). Alan, I think you might be surprised what kind of reactions your suggestion to remove -- even parts of -- a well-established, wide-used API elicited. After all, Sun worked very hard -- and successfully so -- on an incredible backwards-compatibility, so much so that you can still execute code that was compiled for Java 1.1 without *any* problems. That is what makes Java so much nicer to use than, say, C# or C++, where you have to adjust things all the time just to keep them compiling, let alone running. Maybe you can explain what benefits there are in removing that established API, and maybe you could elaborate why those benefits outweigh the costs? I am curious, Johannes From wjherrmann at gmail.com Fri Jul 5 11:19:23 2013 From: wjherrmann at gmail.com (Will Herrmann) Date: Fri, 5 Jul 2013 13:19:23 -0500 Subject: Support for Apple Extensions Message-ID: Unfortunately, JavaFX does not support native look and feels. AquaFX goes a fair ways to bridging the gap, but it's not ideal and may not be suitable for production environments. Right now, this lack of native look and feel is the main thing that prevents me from adopting JavaFX. There is a JIRA feature request for JavaFX native look and feels at https://javafx-jira.kenai.com/browse/RT-20299. Right now it's the #14 most popular feature request, although I encourage everyone to vote for it to make it even higher. -Will Herrmann On Fri Jul 5 03:26:28 PDT 2013, Fabrizio Giudici wrote: > IMO for any new development - unless there are showstoppers - JavaFX is > the way to go and AquaFX (http://aquafx-project.com/) the way to be native > on Mac OS X, hoping that the project receives the required attention by > the community. Note that it's targeted at JDK 8, but today you can take > the CSS, comment out the skin references, and already have some > improvement with JDK 7. Whether this is good or not for a production > environment is something that I'm still studying. But it sounds as the > standard way starting from JDK 8. From Alan.Bateman at oracle.com Fri Jul 5 11:38:44 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Jul 2013 19:38:44 +0100 Subject: Support for Apple Extensions In-Reply-To: References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> Message-ID: <51D712B4.9000608@oracle.com> On 05/07/2013 17:44, Johannes Schindelin wrote: > : > In addition, we are heavy users of handleOpenFile() and handleAbout(), > printFiles(), handleQuitRequestWith(), userSessionActivated(), > userSessionDeactivated(), systemAboutToSleep(), systemAwoke(), > screenAboutToSleep(), screenAwoke(), appHidden, appUnhidden(), > appMovedToBackground(), appRaisedToForeground, and appReOpened(). > > Alan, I think you might be surprised what kind of reactions your > suggestion to remove -- even parts of -- a well-established, wide-used API > elicited. > > After all, Sun worked very hard -- and successfully so -- on an incredible > backwards-compatibility, so much so that you can still execute code that > was compiled for Java 1.1 without *any* problems. That is what makes Java > so much nicer to use than, say, C# or C++, where you have to adjust things > all the time just to keep them compiling, let alone running. > > Maybe you can explain what benefits there are in removing that established > API, and maybe you could elaborate why those benefits outweigh the costs? > > I am curious, > Johannes I haven't proposed removing these APIs. I have instead just asked a few questions to try to get some clarity as to their status and also to get some understanding as to which of these APIs are used. One motive to understanding their supportness is modularity as it's important to know which APIs might need to be "exported". See also JEP-179 [1] for the proposal to try to capture the support status of APIs so that it is clear to both JDK maintainers and to developers using the JDK. -Alan [1] http://openjdk.java.net/jeps/179 From Fabrizio.Giudici at tidalwave.it Fri Jul 5 11:50:44 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Fri, 05 Jul 2013 20:50:44 +0200 Subject: Support for Apple Extensions In-Reply-To: References: Message-ID: On Fri, 05 Jul 2013 20:19:23 +0200, Will Herrmann wrote: > Unfortunately, JavaFX does not support native look and feels. AquaFX > goes a fair ways to bridging the gap, but it's not ideal and may not be > suitable for production environments. Can you elaborate, please? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From Johannes.Schindelin at gmx.de Fri Jul 5 12:06:11 2013 From: Johannes.Schindelin at gmx.de (Johannes Schindelin) Date: Fri, 5 Jul 2013 21:06:11 +0200 (CEST) Subject: Support for Apple Extensions In-Reply-To: <51D712B4.9000608@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D712B4.9000608@oracle.com> Message-ID: Hi Alan, On Fri, 5 Jul 2013, Alan Bateman wrote: > On 05/07/2013 17:44, Johannes Schindelin wrote: > > > Alan, I think you might be surprised what kind of reactions your > > suggestion to remove -- even parts of -- a well-established, wide-used > > API elicited. > > I haven't proposed removing these APIs. Well, it was quite obvious from your question "what parts of this API are used anyway?" that you are not quite interested in supporting them all into the indefinite future. > I have instead just asked a few questions to try to get some clarity as > to their status and also to get some understanding as to which of these > APIs are used. One motive to understanding their supportness is > modularity as it's important to know which APIs might need to be > "exported". Sorry, this does not make too much sense to me. I do not know what you mean by "exported". I know that there are APIs that are available, but deprecated, so if that is what you mean, please say so. > See also JEP-179 [1] for the proposal to try to capture the support > status of APIs so that it is clear to both JDK maintainers and to > developers using the JDK. Again, what other sense does such a question have than to get away with stopping to maintain APIs that are in wide-spread use? In particular, Apple has been very good at burning me, e.g. with the removal of support of the well-used Quicktime4Java API. So I have been warned: Apple takes away things even if they are still used, even if they are still needed. That might explain why I reacted a little more forcefully to your questions, however innocent they were intended to sound. > > Maybe you can explain what benefits there are in removing that > > established API, and maybe you could elaborate why those benefits > > outweigh the costs? > > > > I am curious, And I am still curious. If you do not intend to remove support for those still heavily-used API, why ask in the first place? If you intend to remove it, however, what is the cost/benefit consideration? Do you actually care about those users? Or is it just a question how much effort to spend on maintaining something that was determined to be undesired by somebody? I am sorry if that sounds aggressive, but I still would like to know the answers to those questions and I haven't read anything close to a response. Ciao, Johannes From wjherrmann at gmail.com Fri Jul 5 12:16:41 2013 From: wjherrmann at gmail.com (Will Herrmann) Date: Fri, 5 Jul 2013 14:16:41 -0500 Subject: Support for Apple Extensions In-Reply-To: References: Message-ID: <0275DB4E-4BAB-4250-9E64-8953F38731C8@gmail.com> JavaFX has two included look and feels: Caspian and Modena. Both of them are nice, but like Swing's Metal and Nimbus, they are designed to look exactly the same way on every platform, which especially means that they clash on OS X. Swing provided the ability to use the operating system's "native" LAF via "UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());" However, there is no equivalent to this in JavaFX, meaning that if you want something that looks closer to the native look and feel than Caspian or Modena, you have to use a third party class. AquaFX is one such third party class that tries to bridge this gap via CSS skins, although it's my understanding that it is still undergoing some major revisions so I would be reluctant to use it in a production environment. There are similar third party projects to replicate other platform LAFs, such as: ?JMetro, replicating Windows 8 (http://pixelduke.wordpress.com/2012/10/23/jmetro-windows-8-controls-on-java/) ?JavaFX native skins, replicating Mac OS 10.8 and Windows 7 (http://blog.software4java.com/?p=30) ?Some experimental button LAFs for iOS/Mac/Windows 7 (http://fxexperience.com/2011/12/styling-fx-buttons-with-css/) However, if you want an app that looks native on every platform, you would have to combine these third party CSS skins, which may not be an easy thing to do. Ultimately, I think that JavaFX ought to support a native look and feel for each platform, similar to the Swing code provided above. -Will Herrmann On Jul 5, 2013, at 1:50 PM, Fabrizio Giudici wrote: > On Fri, 05 Jul 2013 20:19:23 +0200, Will Herrmann wrote: > >> Unfortunately, JavaFX does not support native look and feels. AquaFX goes a fair ways to bridging the gap, but it's not ideal and may not be suitable for production environments. > > Can you elaborate, please? > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From leonid.romanov at oracle.com Fri Jul 5 12:17:56 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 05 Jul 2013 23:17:56 +0400 Subject: [7u40] Review request for 8019628: [macosx] closed/java/awt/Modal/BlockedMouseInputTest/BlockedMouseInputTest.html failed since 7u40b30 on MacOS In-Reply-To: <51D6CE87.70907@oracle.com> References: <51D6CE87.70907@oracle.com> Message-ID: <51D71BE4.5010509@oracle.com> Hi, Looks good. On 7/5/2013 17:47, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix for the regression in JDK 7u40: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8019628 > webrev: http://cr.openjdk.java.net/~alexsch/8019628/webrev.00 > > Generated enter/exit mouse events have been changed to use the current > mouse event id during the last merge in the JDK 7u40: > http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/diff/9062acbc098c/src/macosx/classes/sun/lwawt/LWWindowPeer.java > > For example > ------------------------------- > Point oldp = lastMouseEventPeer.windowToLocal(x, y, this); > - postEvent(new MouseEvent(lastMouseEventPeer.getTarget(), > - MouseEvent.MOUSE_EXITED, > - when, modifiers, > - oldp.x, oldp.y, screenX, screenY, > - clickCount, popupTrigger, button)); > + Component target = lastMouseEventPeer.getTarget(); > + postMouseEnteredExitedEvent(target, id, when, modifiers, oldp, > + screenX, screenY, clickCount, popupTrigger, button); > ------------------------------- > > > So the mouse enter/exit events are now can be lost and wrong events > can be sent for the lastMouseEventPeer. > The fix adds the explicit mouse enter/exit events declaration back as > it was before the merge. > > There are 2 failed tests in the JDK 7u repository because of the > regression so it is not necessary to write new one. > > Thanks, > Alexandr. > From Fabrizio.Giudici at tidalwave.it Fri Jul 5 12:27:51 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Fri, 05 Jul 2013 21:27:51 +0200 Subject: Support for Apple Extensions In-Reply-To: <0275DB4E-4BAB-4250-9E64-8953F38731C8@gmail.com> References: <0275DB4E-4BAB-4250-9E64-8953F38731C8@gmail.com> Message-ID: On Fri, 05 Jul 2013 21:16:41 +0200, Will Herrmann wrote: > AquaFX is one such third party class that tries to bridge this gap via > CSS skins, although it's my understanding that it is still undergoing > some major revisions so I would be reluctant to use it in a production Sure, in fact it's targeted at JDK 8 (see my original mail) because of skins, I suppose. But what about quality? Do you think it won't be optimal and the only acceptable solution is a native l&f? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From mik3hall at gmail.com Fri Jul 5 13:09:24 2013 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 5 Jul 2013 15:09:24 -0500 Subject: Support for Apple Extensions In-Reply-To: <51D6B1C8.7060007@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D69D72.60201@oracle.com> <51D6B1C8.7060007@oracle.com> Message-ID: On Jul 5, 2013, at 6:45 AM, Alan Bateman wrote: > On 05/07/2013 11:18, Artem Ananiev wrote: >> >> : >> >> What about eIO? Is it used by anybody? > I'm interesting in hearing about that too as it looks like FileManager defines a few things that might be more appropriate for java.awt.Desktop. Methods to access a file's type/creator codes that could easily be handled via the file system API (I think Michael Hall's FileSystemProvider might already do this). This would be what would probably be considered convenience methods the extensions include for the occasional use for developers to avoid having to come up with their own jni to accomplish the same thing. file type/creator are old mac classic file meta data that is almost deprecated in this day and age. But they are still useful in enough api's like launch services to be nice to have. So yes, the nio.2 OS X filesystem provider I came up, my trz package below, does support them as meta attributes probably via a couple different api's. Not having looked at it for a while I don't remember for sure but with the Finder api's almost certainly. If somehow I did miss this, someone please mention it and I will certainly add it asap. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From swpalmer at gmail.com Fri Jul 5 13:12:51 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 5 Jul 2013 16:12:51 -0400 Subject: Support for Apple Extensions In-Reply-To: References: <0275DB4E-4BAB-4250-9E64-8953F38731C8@gmail.com> Message-ID: A native look and feel is a secondary issue. Even Apple plays around with the look and feel. For instance the "pro" apps like Final Cut Pro, have a very diferent look and feel from the "regular" apps, and nobody cares. Caspian and Modena will only bug a small number of the die hard Mac purists, compared to the big things like not having a screen menu bar or a proper Application menu, open events etc.. Other features mentioned like the notification of the computer sleeping, putting files in the trash, etc. are all things that should have cross-platform APIs since they are concepts that are common to Windows and Linux as well. I would much rather see a supported cross-platform API that just does the right thing on the current platform than to have to code OS specific things. I think that is were the Orcale man hours need to be focused, and let the community continue to do things like AquaFX to handle the rest.. Scott On Fri, Jul 5, 2013 at 3:27 PM, Fabrizio Giudici < Fabrizio.Giudici at tidalwave.it> wrote: > On Fri, 05 Jul 2013 21:16:41 +0200, Will Herrmann > wrote: > > AquaFX is one such third party class that tries to bridge this gap via >> CSS skins, although it's my understanding that it is still undergoing some >> major revisions so I would be reluctant to use it in a production >> > > Sure, in fact it's targeted at JDK 8 (see my original mail) because of > skins, I suppose. But what about quality? Do you think it won't be optimal > and the only acceptable solution is a native l&f? > > > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/**blog - > fabrizio.giudici at tidalwave.it > From wjherrmann at gmail.com Fri Jul 5 13:21:04 2013 From: wjherrmann at gmail.com (Will Herrmann) Date: Fri, 5 Jul 2013 15:21:04 -0500 Subject: Support for Apple Extensions In-Reply-To: References: <0275DB4E-4BAB-4250-9E64-8953F38731C8@gmail.com> Message-ID: <864E45B6-75A7-40DE-8E94-1EF19A429942@gmail.com> AquaFX looks very good from what I've seen of it, but I have two main concerns for it as a third party skin: 1. The creators may not have the time and resources to continue to make it match the appearance of future OS X releases. This was the issue that Quaqua had; it stopped being developed after Mac OS 10.4. I presume that if a native LAF were an official part of JavaFX, Oracle would continue to update it when future versions of OS X are released. 2. As a third party library, it won't be as widely adopted as it would be if it were an official part of JavaFX. Not being aware that it exists and the hurdles to getting it included in a program (minor though they are) would discourage others from adopting a native OS X look and feel in their app. Besides, JavaFX is stated to be a replacement to Swing, but without an included way to use a native LAF like Swing, it can't be a true replacement for those who need that functionality. In my ideal world, AquaFX would be merged into JavaFX as a starting point for an official native look and feel implementation, which would then be continued to be developed by Oracle. Similar projects for a native Windows 7 LAF and other platforms would also be merged in at the same time. Granted, I realize there are somewhat more pressing issues that would affect both JavaFX and Swing apps, such as the functionality provided by com.apple.eawt and com.apple.eio. However, I believe that adding a native JavaFX look and feel for OS X and other platforms should eventually be a priority for Oracle (which is why I voted for the feature request at https://javafx-jira.kenai.com/browse/RT-20299). -Will Herrmann On Jul 5, 2013, at 2:27 PM, Fabrizio Giudici wrote: > On Fri, 05 Jul 2013 21:16:41 +0200, Will Herrmann wrote: > >> AquaFX is one such third party class that tries to bridge this gap via CSS skins, although it's my understanding that it is still undergoing some major revisions so I would be reluctant to use it in a production > > Sure, in fact it's targeted at JDK 8 (see my original mail) because of skins, I suppose. But what about quality? Do you think it won't be optimal and the only acceptable solution is a native l&f? > > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From mik3hall at gmail.com Fri Jul 5 13:28:29 2013 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 5 Jul 2013 15:28:29 -0500 Subject: Support for Apple Extensions In-Reply-To: <0256293E-D071-4997-8B2B-DC1A00FD55F4@tagtraum.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D69D72.60201@oracle.com> <51D6B1C8.7060007@oracle.com> <0256293E-D071-4997-8B2B-DC1A00FD55F4@tagtraum.com> Message-ID: On Jul 5, 2013, at 7:59 AM, Hendrik Schreiber wrote: > On Jul 5, 2013, at 1:45 PM, Alan Bateman wrote: > >> On 05/07/2013 11:18, Artem Ananiev wrote: >>> >>> : >>> >>> What about eIO? Is it used by anybody? >> I'm interesting in hearing about that too as it looks like FileManager defines a few things that might be more appropriate for java.awt.Desktop. Methods to access a file's type/creator codes that could easily be handled via the file system API (I think Michael Hall's FileSystemProvider might already do this). > > From the eio package I'm using mostly FileManager methods: Same here, my trz package below, for convenience even though it includes file related jni of it's own uses? ostypeCreator = FileManager.OSTypeToInt(creator); FileManager.setFileTypeAndCreator(fileName,ostypeType,ostypeCreator); My AppConverter app below uses? f = new File(FileManager.findFolder(FileManager.kUserDomain, FileManager.OSTypeToInt("asup")),app); Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From mik3hall at gmail.com Fri Jul 5 13:39:26 2013 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 5 Jul 2013 15:39:26 -0500 Subject: Support for Apple Extensions In-Reply-To: References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> Message-ID: On Jul 5, 2013, at 5:26 AM, Fabrizio Giudici wrote: > On Fri, 05 Jul 2013 12:04:18 +0200, Michael Hall wrote: > > >> widely recommended alternative. There was also Werner Randelshofer's Quaqua project. I'm not sure that's actively supported by Werner anymore? I thought saw it was open sourced somewhere now? Might be misremembering. > > Quaqua is open source, but has not received updates in recent times, even though Werner responded to ping. > > My current opinion is that Qauqua is an excellent work, but now is for legacy (maintaining existing Swing code). Note that JavaFX FileChooser is native, even though somewhat limited for now. > > IMO for any new development - unless there are showstoppers - JavaFX is the way to go and AquaFX (http://aquafx-project.com/) the way to be native on Mac OS X, hoping that the project receives the required attention by the community. Note that it's targeted at JDK 8, but today you can take the CSS, comment out the skin references, and already have some improvement with JDK 7. Whether this is good or not for a production environment is something that I'm still studying. But it sounds as the standard way starting from JDK 8. https://java.net/projects/quaqua Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From steve at winnall.ch Fri Jul 5 16:20:27 2013 From: steve at winnall.ch (Stephen Winnall) Date: Sat, 6 Jul 2013 01:20:27 +0200 Subject: Support for Apple Extensions In-Reply-To: References: <0275DB4E-4BAB-4250-9E64-8953F38731C8@gmail.com> Message-ID: I almost agree. Except that Apple plays around with the look, but not with the feel. I think the two need to be distinguished. Steve On 05.07.2013, at 22:12, Scott Palmer wrote: > A native look and feel is a secondary issue. Even Apple plays around with > the look and feel. For instance the "pro" apps like Final Cut Pro, have a > very diferent look and feel from the "regular" apps, and nobody cares. > Caspian and Modena will only bug a small number of the die hard Mac > purists, compared to the big things like not having a screen menu bar or a > proper Application menu, open events etc.. > Other features mentioned like the notification of the computer sleeping, > putting files in the trash, etc. are all things that should have > cross-platform APIs since they are concepts that are common to Windows and > Linux as well. I would much rather see a supported cross-platform API that > just does the right thing on the current platform than to have to code OS > specific things. I think that is were the Orcale man hours need to be > focused, and let the community continue to do things like AquaFX to handle > the rest.. > > Scott > > > > On Fri, Jul 5, 2013 at 3:27 PM, Fabrizio Giudici < > Fabrizio.Giudici at tidalwave.it> wrote: > >> On Fri, 05 Jul 2013 21:16:41 +0200, Will Herrmann >> wrote: >> >> AquaFX is one such third party class that tries to bridge this gap via >>> CSS skins, although it's my understanding that it is still undergoing some >>> major revisions so I would be reluctant to use it in a production >> >> Sure, in fact it's targeted at JDK 8 (see my original mail) because of >> skins, I suppose. But what about quality? Do you think it won't be optimal >> and the only acceptable solution is a native l&f? >> >> >> >> -- >> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. >> "We make Java work. Everywhere." >> http://tidalwave.it/fabrizio/**blog - >> fabrizio.giudici at tidalwave.it >> From krueger at lesspain.de Sat Jul 6 01:28:34 2013 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Sat, 6 Jul 2013 10:28:34 +0200 Subject: Support for Apple Extensions In-Reply-To: References: <0275DB4E-4BAB-4250-9E64-8953F38731C8@gmail.com> Message-ID: Couldn't agree more. The resources needed for getting a "native" JFX look & feel to really work like its native counterpart would be considerable because it would mean reinventing or exposing a lot of native API (because as someone correctly mentioned above, it is not only about look but a lot of behaviour and once you dive into the details of this it gets pretty deep or it will again be a half-assed compromise bound to be dissed by die-hard Mac purists anyway). IMHO those resources could be spent a lot better in making the platform robust and high-quality in its core aspects like font rendering and overall UI performance and enabling developers to help themselves in some key areas (see discussions about exposing an OpenGL context). Suboptimal resizing or repainting or animation performance are much more likely to make users perceive your app as unprofessional and "feel like Java" than a well-crafted individual look & feel. As Scott said, there are a lot of extremely successful applications on the Mac that went their own, very individual way as far as look and feel is concerned. On Fri, Jul 5, 2013 at 10:12 PM, Scott Palmer wrote: > A native look and feel is a secondary issue. Even Apple plays around with > the look and feel. For instance the "pro" apps like Final Cut Pro, have a > very diferent look and feel from the "regular" apps, and nobody cares. > Caspian and Modena will only bug a small number of the die hard Mac > purists, compared to the big things like not having a screen menu bar or a > proper Application menu, open events etc.. > Other features mentioned like the notification of the computer sleeping, > putting files in the trash, etc. are all things that should have > cross-platform APIs since they are concepts that are common to Windows and > Linux as well. I would much rather see a supported cross-platform API that > just does the right thing on the current platform than to have to code OS > specific things. I think that is were the Orcale man hours need to be > focused, and let the community continue to do things like AquaFX to handle > the rest.. > > Scott > > > > On Fri, Jul 5, 2013 at 3:27 PM, Fabrizio Giudici < > Fabrizio.Giudici at tidalwave.it> wrote: > >> On Fri, 05 Jul 2013 21:16:41 +0200, Will Herrmann >> wrote: >> >> AquaFX is one such third party class that tries to bridge this gap via >>> CSS skins, although it's my understanding that it is still undergoing some >>> major revisions so I would be reluctant to use it in a production >>> >> >> Sure, in fact it's targeted at JDK 8 (see my original mail) because of >> skins, I suppose. But what about quality? Do you think it won't be optimal >> and the only acceptable solution is a native l&f? >> >> >> >> -- >> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. >> "We make Java work. Everywhere." >> http://tidalwave.it/fabrizio/**blog - >> fabrizio.giudici at tidalwave.it >> From christopherbrown06 at gmail.com Sat Jul 6 02:44:29 2013 From: christopherbrown06 at gmail.com (Christopher Brown) Date: Sat, 6 Jul 2013 11:44:29 +0200 Subject: Support for Apple Extensions In-Reply-To: References: <0275DB4E-4BAB-4250-9E64-8953F38731C8@gmail.com> Message-ID: There is no "one size fits all" answer, however, with Swing in maintenance mode (and the current integration issues), and JavaFX being consumer oriented with partial reach (not compatible with most smartphone/tablet devices, when this area is addressed more and more by HTML5), our more sober business applications are turning to SWT (not in all cases, but it's a trend). -- Christopher On 6 July 2013 01:20, Stephen Winnall wrote: > I almost agree. Except that Apple plays around with the look, but not with the feel. I think the two need to be distinguished. > > Steve > > > On 05.07.2013, at 22:12, Scott Palmer wrote: > >> A native look and feel is a secondary issue. Even Apple plays around with >> the look and feel. For instance the "pro" apps like Final Cut Pro, have a >> very diferent look and feel from the "regular" apps, and nobody cares. >> Caspian and Modena will only bug a small number of the die hard Mac >> purists, compared to the big things like not having a screen menu bar or a >> proper Application menu, open events etc.. >> Other features mentioned like the notification of the computer sleeping, >> putting files in the trash, etc. are all things that should have >> cross-platform APIs since they are concepts that are common to Windows and >> Linux as well. I would much rather see a supported cross-platform API that >> just does the right thing on the current platform than to have to code OS >> specific things. I think that is were the Orcale man hours need to be >> focused, and let the community continue to do things like AquaFX to handle >> the rest.. >> >> Scott From Alan.Bateman at oracle.com Sat Jul 6 09:53:14 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 06 Jul 2013 17:53:14 +0100 Subject: Support for Apple Extensions In-Reply-To: References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D712B4.9000608@oracle.com> Message-ID: <51D84B7A.7070608@oracle.com> On 05/07/2013 20:06, Johannes Schindelin wrote: > : > Well, it was quite obvious from your question "what parts of this API are > used anyway?" that you are not quite interested in supporting them all > into the indefinite future. No, the intent to is to try to get some clarity on these APIs as they are "new" to the JDK (they may have been in Apple's JDK for several releases but only came into the main-line at 7u4 when the Mac port was pushed). > : > Sorry, this does not make too much sense to me. I do not know what you > mean by "exported". I know that there are APIs that are available, but > deprecated, so if that is what you mean, please say so. The long term intent is to get to a modular platform and that requires knowing which APIs are intended to be used by applications (or other modules) and which are implementation/internal APIs. So for "exported" here then think the public types in a module that are accessible to other modules. > >> See also JEP-179 [1] for the proposal to try to capture the support >> status of APIs so that it is clear to both JDK maintainers and to >> developers using the JDK. > Again, what other sense does such a question have than to get away with > stopping to maintain APIs that are in wide-spread use? I don't know if you read the JEP but the com.apple APIs are a fine example of where the supportness and stability is not clear by looking at the code or the API. > : > > If you do not intend to remove support for those still heavily-used API, > why ask in the first place? As I said, I'm not proposing to remove anything. I think the important thing is to understand the status of these APIs. It is clear that there they are used by applications that are developed and/or deployed on Apple's JDK 6 and older. It is somewhat less clear as to the usage on jdk7u builds, the reason being (as was mentioned) that the NON_CORE_PKGS list was not updated and so code that uses these APIs doesn't compile with 7 unless you do something special. As the latter doesn't appear to have brought a crowd with pitchforks onto the streets then it might be a sign of slow adoption or maybe it means that folks are compiling with JDK 6 and deploying to 7. -Alan. From mik3hall at gmail.com Sat Jul 6 10:12:07 2013 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 6 Jul 2013 12:12:07 -0500 Subject: Support for Apple Extensions In-Reply-To: <51D84B7A.7070608@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D712B4.9000608@oracle.com> <51D84B7A.7070608@oracle.com> Message-ID: <269CB576-74FC-4CA9-AD8E-5E8B6CD55B15@gmail.com> On Jul 6, 2013, at 11:53 AM, Alan Bateman wrote: > It is somewhat less clear as to the usage on jdk7u builds, the reason being (as was mentioned) that the NON_CORE_PKGS list was not updated and so code that uses these APIs doesn't compile with 7 unless you do something special. As the latter doesn't appear to have brought a crowd with pitchforks onto the streets then it might be a sign of slow adoption or maybe it means that folks are compiling with JDK 6 and deploying to 7. Something is not making sense here. As mentioned earlier I used Apple extension FileManager methods with my trz package below. That was specifically written against nio.2, which means it requires java 7 to compile and run. It does both - unless this compile breaking thing is more recent than when I did the FileManager using parts? Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From kortenkamp at cinderella.de Sat Jul 6 10:26:33 2013 From: kortenkamp at cinderella.de (Ulrich Kortenkamp) Date: Sat, 6 Jul 2013 19:26:33 +0200 Subject: Support for Apple Extensions In-Reply-To: <51D84B7A.7070608@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D712B4.9000608@oracle.com> <51D84B7A.7070608@oracle.com> Message-ID: On 06 Jul 2013, at 18:53, Alan Bateman wrote: > As the latter doesn't appear to have brought a crowd with pitchforks onto the streets then it might be a sign of slow adoption or maybe it means that folks are compiling with JDK 6 and deploying to 7. Exactly, both is true. We are compiling on JDK6 for the reason that we are still supporting JDK 6 (and we won?t change that soon as we are targeting the educational market with lots of Windows XP machines still out there), so we are compiling on JDK 6 and don?t use any new features. The only reason why we are also deploying to Java 7 (in particular on Mac) is that Java 6 is no longer available. Also, we are using stubs that allow for compiling also on machines that do not have the Apple Java extensions available ? just because we are doing our builds on Linux servers. But if our users will no longer see our fine-tuning for Mac when they finally switch to Java 7 (which they did already for the applet version, which obviously doesn?t need desktop integration), be sure we will hand out pitchforks to them ;-) Ulli From Alan.Bateman at oracle.com Sat Jul 6 12:36:52 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 06 Jul 2013 20:36:52 +0100 Subject: Support for Apple Extensions In-Reply-To: <269CB576-74FC-4CA9-AD8E-5E8B6CD55B15@gmail.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D712B4.9000608@oracle.com> <51D84B7A.7070608@oracle.com> <269CB576-74FC-4CA9-AD8E-5E8B6CD55B15@gmail.com> Message-ID: <51D871D4.3020802@oracle.com> On 06/07/2013 18:12, Michael Hall wrote: > : > Something is not making sense here. > As mentioned earlier I used Apple extension FileManager methods with my trz package below. That was specifically written against nio.2, which means it requires java 7 to compile and run. It does both - unless this compile breaking thing is more recent than when I did the FileManager using parts? > I just checked into it and NON_CORE_PKGS.gmk has these listed so it shouldn't be an issue with builds of jdk7u (sorry about that, I shouldn't have trusted the bug that you sent a link to). However they are not in the symbol file generated in the jdk8 build - that is due to a small bug in the make file that seems to have come in when moving to the new build in 8. -Alan From mik3hall at gmail.com Sat Jul 6 13:01:41 2013 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 6 Jul 2013 15:01:41 -0500 Subject: Support for Apple Extensions In-Reply-To: <51D871D4.3020802@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D712B4.9000608@oracle.com> <51D84B7A.7070608@oracle.com> <269CB576-74FC-4CA9-AD8E-5E8B6CD55B15@gmail.com> <51D871D4.3020802@oracle.com> Message-ID: On Jul 6, 2013, at 2:36 PM, Alan Bateman wrote: > On 06/07/2013 18:12, Michael Hall wrote: >> : >> Something is not making sense here. >> As mentioned earlier I used Apple extension FileManager methods with my trz package below. That was specifically written against nio.2, which means it requires java 7 to compile and run. It does both - unless this compile breaking thing is more recent than when I did the FileManager using parts? >> > I just checked into it and NON_CORE_PKGS.gmk has these listed so it shouldn't be an issue with builds of jdk7u (sorry about that, I shouldn't have trusted the bug that you sent a link to). However they are not in the symbol file generated in the jdk8 build - that is due to a small bug in the make file that seems to have come in when moving to the new build in 8. Sorry about the confusion on the bug, I know I didn't understand it. Glad to hear that the extensions should compile and I hope they continue to do so. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From swingler at apple.com Sun Jul 7 21:51:55 2013 From: swingler at apple.com (Mike Swingler) Date: Sun, 07 Jul 2013 23:51:55 -0500 Subject: Support for Apple Extensions In-Reply-To: <51D871D4.3020802@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D712B4.9000608@oracle.com> <51D84B7A.7070608@oracle.com> <269CB576-74FC-4CA9-AD8E-5E8B6CD55B15@gmail.com> <51D871D4.3020802@oracle.com> Message-ID: <46B07398-4B69-48BF-A79A-44E5F3BD822E@apple.com> On Jul 6, 2013, at 2:36 PM, Alan Bateman wrote: > On 06/07/2013 18:12, Michael Hall wrote: >> : >> Something is not making sense here. >> As mentioned earlier I used Apple extension FileManager methods with my trz package below. That was specifically written against nio.2, which means it requires java 7 to compile and run. It does both - unless this compile breaking thing is more recent than when I did the FileManager using parts? >> > I just checked into it and NON_CORE_PKGS.gmk has these listed so it shouldn't be an issue with builds of jdk7u (sorry about that, I shouldn't have trusted the bug that you sent a link to). However they are not in the symbol file generated in the jdk8 build - that is due to a small bug in the make file that seems to have come in when moving to the new build in 8. What would it take for the JavaDoc for these classes to also be generated? Curious, Mike Swingler Apple Inc. From swingler at apple.com Sun Jul 7 21:57:25 2013 From: swingler at apple.com (Mike Swingler) Date: Sun, 07 Jul 2013 23:57:25 -0500 Subject: Packaging Java Applications targeting Apple Java 6 and Oracle Java 7+ In-Reply-To: References: Message-ID: On Jul 5, 2013, at 5:14 AM, Christopher Brown wrote: > Hello, > > I have a question about on-going availability of the > /usr/libexec/java_home Mac OS X command. > > I've been following the different threads about the different ways of > bundling a Java application as an ".app" with Mac OS X, using either > JavaApplicationStub (which I've done in the past) or using the > equivalent tool for Java 7 onwards. It would seem that that implies > creating two variants of the application and hoping that the user > picks the right one. The long-term recommended solution would appear > to be "use the Oracle", for obvious reasons. > > However, given that on a new project, we're going to use SWT instead > of Swing, we've created an ".app" bundle that starts Java using an > embedded ".sh" script (and neither stub, which conveniently side-steps > needing to choose one stub or another, and avoids two versions). It > relies on /usr/libexec/java_home and currently works fine. > > I'm probably safe in assuming that at some point (OS X Mavericks / > 10.9), the Apple Java 6 will be withdrawn. However, it would be great > to have confirmation that the "java_home" command will continue to be > supported and provided (as opposed to going down some hacky script > that assumes paths, parses paths, and tries to sort them to pick the > best version). We do plan to support the /usr/libexec/java_home tool in it's current form for the foreseeable future. Regards, Mike Swingler Apple Inc. From leonid.romanov at oracle.com Mon Jul 8 07:28:36 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 8 Jul 2013 18:28:36 +0400 Subject: [8] Review request for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread Message-ID: Hello, Please review a fix for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread, As you aware, recent AppContext usage change in 7u25 exposed a number of AppContext related issues in our code. This particular bug focuses on the incorrect invokeLater() and likes usage on OS X. This issue has been discussed in the following thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-June/005788.html Bug: http://bugs.sun.com/view_bug.do?bug_id=8020038 (might not be available yet) Webrev: http://cr.openjdk.java.net/~leonidr/8020038/webrev.00/ Thanks, Leonid. From jesmith at kaon.com Mon Jul 8 08:16:07 2013 From: jesmith at kaon.com (Joshua Smith) Date: Mon, 8 Jul 2013 11:16:07 -0400 Subject: Local file access change with new Java update Message-ID: <3BBF6C80-748B-4A3B-A8EE-ED163730C557@kaon.com> One of my users likes to test their applets locally by just opening the HTML file from the file system (instead of running a local web server). This worked before the most recent update: Java Plug-in 10.25.2.15 Using JRE version 1.7.0_25-b15 Java HotSpot(TM) 64-Bit Server VM It appears that there are two issues. One is that getCodeBase(), when running from the local filesystem, is returning an empty string. getDocumentBase() still gives the right result. If I work around that by using getDocumentBase instead of getCodeBase (which, in this particular case is OK because they should be the same), then I get: java.security.AccessControlException: access denied ("java.io.FilePermission" "/Other/download/etc..." "read") So it appears that with "Medium" security (the lowest available setting), applets will run but they cannot read from the file system, even if that's how they ran. Note that I do have the "Disable Local File Restrictions" checkbox set in the Safari Developer Menu, but I'm guessing that Safari doesn't tell Java about that. Obviously, the user can just run a local web server, which is what I've told them to do. However, I wanted to make sure that these are both "as designed" security changes, and if not, figure out who I should report the bug to. -Joshua From Doug.Zwick at blackboard.com Mon Jul 8 08:52:54 2013 From: Doug.Zwick at blackboard.com (Doug Zwick) Date: Mon, 8 Jul 2013 11:52:54 -0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: References: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> <51D3EC77.7000707@oracle.com> Message-ID: <379C7587-30F8-458D-B7F0-A9841DC3A20F@blackboard.com> Andrew Thompson wrote: > But I can deploy trusted code by signing an applet or a webstart application and it can create a Thread in another ThreadGroup. Elsewhere in this thread people mention JNI and RMI threads and Cocoa's main thread. This is all valid code; there's no prohibitions against doing any of these things. It may be that the ideal thing for Java to do in this situation is to have the Thread inherit the AppContext of its creator thread, rather than that of the ThreadGroup specified in the Thread c'tor. That may not be practical. Perhaps throwing an Exception in such a circumstance would be reasonable, or even just a warning message on System.err. > I understand it is intended that this AppContext idea is transparent and ideally it would be. But at the present time it appears that the abstraction leaks [1] and there is no workarounds possible using supported code (rather than sun.* classes). Have I misunderstood something in this thread? The work-around I came up with was to create my own Thread, in the right context, that services a queue of Runnables. Then code running on the AppKit Thread, an RMI Thread, etc. can queue a Runnable to be run on that Thread (similar to SwingUtilities.invokeLater). It gets cumbersome to defer things to the Swing thread from such a "bad" context, as you need to queue a Runnable to the work-around Thread that then queues yet another Runnable for the Swing Thread. But it does work. I do not know if invoke-and-wait semantics would be reasonable, as blocking the AppKit Thread can lead to trouble (i.e. deadlocks), but may be OK in the RMI case. This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. From Doug.Zwick at blackboard.com Mon Jul 8 09:10:19 2013 From: Doug.Zwick at blackboard.com (Doug Zwick) Date: Mon, 8 Jul 2013 12:10:19 -0400 Subject: Support for Apple Extensions In-Reply-To: References: Message-ID: Alan Bateman wrote: > It is somewhat less clear as to the usage on > jdk7u builds, the reason being (as was mentioned) that the NON_CORE_PKGS > list was not updated and so code that uses these APIs doesn't compile > with 7 unless you do something special. As the latter doesn't appear to > have brought a crowd with pitchforks onto the streets then it might be a > sign of slow adoption or maybe it means that folks are compiling with > JDK 6 and deploying to 7. Because our app is cross-platform, and our developers use multiple platforms while developing, we use reflection to access the Apple APIs, which shouldn't trip over the NON_CORE_PKGS list. This allows the code to be compiled with any JDK, and still use the Apple APIs when running on a Mac JRE. We have used both the stub approach and dynamic proxy to implement Apple-specific interfaces. I'm sure many other shops have done similar things for much the same reason, so the mob likely won't take to the streets until/unless the API is dropped from the JRE. This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. From artem.ananiev at oracle.com Mon Jul 8 09:14:01 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 08 Jul 2013 20:14:01 +0400 Subject: [8] Review request for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread In-Reply-To: References: Message-ID: <51DAE549.1030805@oracle.com> The changes look fine, except _AppEventDispatcher.dispatch(). Should we dispatch the event at all, in case handlerContext hasn't been set (or set to null, which should never happen)? I would say no. Thanks, Artem On 7/8/2013 6:28 PM, Leonid Romanov wrote: > Hello, > Please review a fix for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread, As you aware, recent AppContext usage change in 7u25 exposed a number of AppContext related issues in our code. This particular bug focuses on the incorrect invokeLater() and likes usage on OS X. This issue has been discussed in the following thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-June/005788.html > > Bug: http://bugs.sun.com/view_bug.do?bug_id=8020038 (might not be available yet) > Webrev: http://cr.openjdk.java.net/~leonidr/8020038/webrev.00/ > > Thanks, > Leonid. > > > From leonid.romanov at oracle.com Mon Jul 8 09:35:04 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 8 Jul 2013 20:35:04 +0400 Subject: [8] Review request for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread In-Reply-To: <51DAE549.1030805@oracle.com> References: <51DAE549.1030805@oracle.com> Message-ID: <5DF6C263-BEC6-41F0-923E-50ABFC6C065C@oracle.com> I encountered the case of unset handlerContext while testing SwingSet3 Web Start app. It is triggered by selecting SwingSet3->About from the global menu bar. Since SwingSet3 doesn't use eAWT, it doesn't register any handlers, so selecting "About" menu item just shows standard Cocoa About dialog. In the code, it is accomplished by the following snippet from _AppEventDispatcher.dispatch: if (localHandler == null) { performDefaultAction(event); } else { performUsing(localHandler, event); } _AppEventDispatcher.performDefaultAction() is an abstract method, implemented in _AboutDispacther (shows native about dialog ) and _QuitDispatcher (quits the app). So, in order to display default About dialog we have to do the dispatching, even though handlerContext hasn't been set. On Jul 8, 2013, at 8:14 PM, Artem Ananiev wrote: > > The changes look fine, except _AppEventDispatcher.dispatch(). Should we dispatch the event at all, in case handlerContext hasn't been set (or set to null, which should never happen)? I would say no. > /*= > Thanks, > > Artem > > On 7/8/2013 6:28 PM, Leonid Romanov wrote: >> Hello, >> Please review a fix for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread, As you aware, recent AppContext usage change in 7u25 exposed a number of AppContext related issues in our code. This particular bug focuses on the incorrect invokeLater() and likes usage on OS X. This issue has been discussed in the following thread: >> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-June/005788.html >> >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8020038 (might not be available yet) >> Webrev: http://cr.openjdk.java.net/~leonidr/8020038/webrev.00/ >> >> Thanks, >> Leonid. >> >> >> From joe.mcglynn at oracle.com Mon Jul 8 09:59:23 2013 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Mon, 8 Jul 2013 09:59:23 -0700 Subject: Local file access change with new Java update In-Reply-To: <3BBF6C80-748B-4A3B-A8EE-ED163730C557@kaon.com> References: <3BBF6C80-748B-4A3B-A8EE-ED163730C557@kaon.com> Message-ID: <938B4B4F-A2D0-4B3C-87A9-57D18347D159@oracle.com> This is the expected behavior. -- On Jul 8, 2013, at 8:16 AM, Joshua Smith wrote: > One of my users likes to test their applets locally by just opening the HTML file from the file system (instead of running a local web server). This worked before the most recent update: > > Java Plug-in 10.25.2.15 > Using JRE version 1.7.0_25-b15 Java HotSpot(TM) 64-Bit Server VM > > It appears that there are two issues. One is that getCodeBase(), when running from the local filesystem, is returning an empty string. getDocumentBase() still gives the right result. > > If I work around that by using getDocumentBase instead of getCodeBase (which, in this particular case is OK because they should be the same), then I get: > > java.security.AccessControlException: access denied ("java.io.FilePermission" "/Other/download/etc..." "read") > > So it appears that with "Medium" security (the lowest available setting), applets will run but they cannot read from the file system, even if that's how they ran. > > Note that I do have the "Disable Local File Restrictions" checkbox set in the Safari Developer Menu, but I'm guessing that Safari doesn't tell Java about that. > > Obviously, the user can just run a local web server, which is what I've told them to do. However, I wanted to make sure that these are both "as designed" security changes, and if not, figure out who I should report the bug to. > > -Joshua > From gregg at wonderly.org Mon Jul 8 10:53:33 2013 From: gregg at wonderly.org (Gregg Wonderly) Date: Mon, 8 Jul 2013 12:53:33 -0500 Subject: Local file access change with new Java update In-Reply-To: <938B4B4F-A2D0-4B3C-87A9-57D18347D159@oracle.com> References: <3BBF6C80-748B-4A3B-A8EE-ED163730C557@kaon.com> <938B4B4F-A2D0-4B3C-87A9-57D18347D159@oracle.com> Message-ID: <1E13E777-9118-4D74-BD8E-1CEC02E391B6@wonderly.org> Joe, which security issue does disallowing local access to a filesystem loaded web page address? It seems like a horrible limitation for developers to work around. I appreciate that there are things that the security manager needs to do better in this regard, but I'm not at all sure why this needed to be changed. Is there a bug report or other history/discussion to read about this via? Gregg Wonderly On Jul 8, 2013, at 11:59 AM, Joe McGlynn wrote: > This is the expected behavior. > -- > On Jul 8, 2013, at 8:16 AM, Joshua Smith wrote: > >> One of my users likes to test their applets locally by just opening the HTML file from the file system (instead of running a local web server). This worked before the most recent update: >> >> Java Plug-in 10.25.2.15 >> Using JRE version 1.7.0_25-b15 Java HotSpot(TM) 64-Bit Server VM >> >> It appears that there are two issues. One is that getCodeBase(), when running from the local filesystem, is returning an empty string. getDocumentBase() still gives the right result. >> >> If I work around that by using getDocumentBase instead of getCodeBase (which, in this particular case is OK because they should be the same), then I get: >> >> java.security.AccessControlException: access denied ("java.io.FilePermission" "/Other/download/etc..." "read") >> >> So it appears that with "Medium" security (the lowest available setting), applets will run but they cannot read from the file system, even if that's how they ran. >> >> Note that I do have the "Disable Local File Restrictions" checkbox set in the Safari Developer Menu, but I'm guessing that Safari doesn't tell Java about that. >> >> Obviously, the user can just run a local web server, which is what I've told them to do. However, I wanted to make sure that these are both "as designed" security changes, and if not, figure out who I should report the bug to. >> >> -Joshua >> > From joe.mcglynn at oracle.com Mon Jul 8 13:13:47 2013 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Mon, 8 Jul 2013 13:13:47 -0700 Subject: Local file access change with new Java update In-Reply-To: <1E13E777-9118-4D74-BD8E-1CEC02E391B6@wonderly.org> References: <3BBF6C80-748B-4A3B-A8EE-ED163730C557@kaon.com> <938B4B4F-A2D0-4B3C-87A9-57D18347D159@oracle.com> <1E13E777-9118-4D74-BD8E-1CEC02E391B6@wonderly.org> Message-ID: <15EC04FB-D382-46AC-91F4-839CEDDE37B3@oracle.com> We can't discuss those details, sorry. Fundamentally applets aren't designed for running from the local filesystem. The best practice is to set up a web server deployment environment for development, which gives you a much better approximation of the behavior in actual deployments. We will have another mechanism that developers can use to run applets in this more in a controlled way in the near future. On Jul 8, 2013, at 10:53 AM, Gregg Wonderly wrote: > Joe, which security issue does disallowing local access to a filesystem loaded web page address? It seems like a horrible limitation for developers to work around. I appreciate that there are things that the security manager needs to do better in this regard, but I'm not at all sure why this needed to be changed. Is there a bug report or other history/discussion to read about this via? > > Gregg Wonderly > > On Jul 8, 2013, at 11:59 AM, Joe McGlynn wrote: > >> This is the expected behavior. >> -- >> On Jul 8, 2013, at 8:16 AM, Joshua Smith wrote: >> >>> One of my users likes to test their applets locally by just opening the HTML file from the file system (instead of running a local web server). This worked before the most recent update: >>> >>> Java Plug-in 10.25.2.15 >>> Using JRE version 1.7.0_25-b15 Java HotSpot(TM) 64-Bit Server VM >>> >>> It appears that there are two issues. One is that getCodeBase(), when running from the local filesystem, is returning an empty string. getDocumentBase() still gives the right result. >>> >>> If I work around that by using getDocumentBase instead of getCodeBase (which, in this particular case is OK because they should be the same), then I get: >>> >>> java.security.AccessControlException: access denied ("java.io.FilePermission" "/Other/download/etc..." "read") >>> >>> So it appears that with "Medium" security (the lowest available setting), applets will run but they cannot read from the file system, even if that's how they ran. >>> >>> Note that I do have the "Disable Local File Restrictions" checkbox set in the Safari Developer Menu, but I'm guessing that Safari doesn't tell Java about that. >>> >>> Obviously, the user can just run a local web server, which is what I've told them to do. However, I wanted to make sure that these are both "as designed" security changes, and if not, figure out who I should report the bug to. >>> >>> -Joshua >>> >> > From kortenkamp at cinderella.de Mon Jul 8 13:56:41 2013 From: kortenkamp at cinderella.de (Ulrich Kortenkamp) Date: Mon, 8 Jul 2013 22:56:41 +0200 Subject: Local file access change with new Java update In-Reply-To: <15EC04FB-D382-46AC-91F4-839CEDDE37B3@oracle.com> References: <3BBF6C80-748B-4A3B-A8EE-ED163730C557@kaon.com> <938B4B4F-A2D0-4B3C-87A9-57D18347D159@oracle.com> <1E13E777-9118-4D74-BD8E-1CEC02E391B6@wonderly.org> <15EC04FB-D382-46AC-91F4-839CEDDE37B3@oracle.com> Message-ID: <5A997426-CE57-443A-993F-DE5BEBE6E319@cinderella.de> Hi, Am 08.07.2013 um 22:13 schrieb Joe McGlynn : > We can't discuss those details, sorry. For what reasons? Political? Or is this security by obscurity? > Fundamentally applets aren't designed for running from the local filesystem. Hold on. Applets are designed by developers, not by Oracle. You can ask us not to design applets running on local file systems, but as such your statement makes as much sense as a statement like 'HTML pages must be served by a web server and must not be viewed locally.' I kept quiet about this getCodeBase() change here although it broke our applets and is violating what has been ? and still is ? written in the official documentation. But your ignorant reply just makes me angry and sad. WE USED getCodeBase() FOR 17 YEARS. And then someone decides to kill it. In a minor release. Without being able to discuss details. Great. I am tired of all the 'Java on the desktop is dead' talk. I am tired of Sun/Oracle replacing features that need bug fixes with features that just don't work (here: Swing with JavaFX). Just in case you wonder: yes, Java in the browser is dead, because you kill it. Constantly. Ever wondered why Java did not find its way into mobile browsers? Not even on Android? Because you kill it. It's not a matter of speed or whatever. Java still beats JavaScript. We had working Java 2 VMs on mobile devices back in 2003. That's ten years ago. But still, you manage to fail. You kill it. Don't tell me what Java can do or cannot do. Just try not to break things again and again. Please accept my apologies for this rant. Maybe this is acceptable once, given how long I am working with Java on OS X. I feel old now. Thanks, Ulli PS: Of course I followed the tradition of 'write once, fix everywhere' and made our applets work locally again, by using getDocumentBase() and not accessing the local file system but embedding all resources in a param tag for the applet. This will work until param tags are considered a security risk. PPS: Please replace 'applet' by RIA everywhere above. Or whatever they are called today. From mik3hall at gmail.com Mon Jul 8 16:54:21 2013 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 8 Jul 2013 18:54:21 -0500 Subject: Support for Apple Extensions In-Reply-To: <46B07398-4B69-48BF-A79A-44E5F3BD822E@apple.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D712B4.9000608@oracle.com> <51D84B7A.7070608@oracle.com> <269CB576-74FC-4CA9-AD8E-5E8B6CD55B15@gmail.com> <51D871D4.3020802@oracle.com> <46B07398-4B69-48BF-A79A-44E5F3BD822E@apple.com> Message-ID: On Jul 7, 2013, at 11:51 PM, Mike Swingler wrote: > On Jul 6, 2013, at 2:36 PM, Alan Bateman wrote: > >> On 06/07/2013 18:12, Michael Hall wrote: >>> : >>> Something is not making sense here. >>> As mentioned earlier I used Apple extension FileManager methods with my trz package below. That was specifically written against nio.2, which means it requires java 7 to compile and run. It does both - unless this compile breaking thing is more recent than when I did the FileManager using parts? >>> >> I just checked into it and NON_CORE_PKGS.gmk has these listed so it shouldn't be an issue with builds of jdk7u (sorry about that, I shouldn't have trusted the bug that you sent a link to). However they are not in the symbol file generated in the jdk8 build - that is due to a small bug in the make file that seems to have come in when moving to the new build in 8. > > What would it take for the JavaDoc for these classes to also be generated? I would also be a little curious about this especially since I was having a little trouble finding html on the Apple pages. Where else would we be able to see the doc for these? Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From kaydell.leavitt at icloud.com Mon Jul 8 21:31:49 2013 From: kaydell.leavitt at icloud.com (Kaydell Leavitt) Date: Mon, 08 Jul 2013 22:31:49 -0600 Subject: Local file access change with new Java update In-Reply-To: <3BBF6C80-748B-4A3B-A8EE-ED163730C557@kaon.com> References: <3BBF6C80-748B-4A3B-A8EE-ED163730C557@kaon.com> Message-ID: <1BFD4E69-72A8-4DF1-A19B-01B9DDB67FB5@icloud.com> Hi Joshua, > One of my users likes to test their applets locally by just opening the HTML file from the file system (instead of running a local web server). This worked before the most recent update: Wouldn't it work for your users to install a policy file, granting them permissions to do what they need to do? Or, using the "policytool" command from the command-line to enable applets to do more than the default permissions allow? -- Kaydell kaydell.leavitt at icloud.com http://learnbymac.com On Jul 8, 2013, at 9:16 AM, Joshua Smith wrote: > One of my users likes to test their applets locally by just opening the HTML file from the file system (instead of running a local web server). This worked before the most recent update: > > Java Plug-in 10.25.2.15 > Using JRE version 1.7.0_25-b15 Java HotSpot(TM) 64-Bit Server VM > > It appears that there are two issues. One is that getCodeBase(), when running from the local filesystem, is returning an empty string. getDocumentBase() still gives the right result. > > If I work around that by using getDocumentBase instead of getCodeBase (which, in this particular case is OK because they should be the same), then I get: > > java.security.AccessControlException: access denied ("java.io.FilePermission" "/Other/download/etc..." "read") > > So it appears that with "Medium" security (the lowest available setting), applets will run but they cannot read from the file system, even if that's how they ran. > > Note that I do have the "Disable Local File Restrictions" checkbox set in the Safari Developer Menu, but I'm guessing that Safari doesn't tell Java about that. > > Obviously, the user can just run a local web server, which is what I've told them to do. However, I wanted to make sure that these are both "as designed" security changes, and if not, figure out who I should report the bug to. > > -Joshua > > > _______________________________________________ > 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: > https://lists.apple.com/mailman/options/java-dev/kaydell.leavitt%40icloud.com > > This email sent to kaydell.leavitt at icloud.com From anthony.petrov at oracle.com Tue Jul 9 01:36:54 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 09 Jul 2013 12:36:54 +0400 Subject: [8] Review request for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread In-Reply-To: References: Message-ID: <51DBCBA6.3040506@oracle.com> The fix looks good to me. -- best regards, Anthony On 07/08/2013 06:28 PM, Leonid Romanov wrote: > Hello, > Please review a fix for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread, As you aware, recent AppContext usage change in 7u25 exposed a number of AppContext related issues in our code. This particular bug focuses on the incorrect invokeLater() and likes usage on OS X. This issue has been discussed in the following thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-June/005788.html > > Bug: http://bugs.sun.com/view_bug.do?bug_id=8020038 (might not be available yet) > Webrev: http://cr.openjdk.java.net/~leonidr/8020038/webrev.00/ > > Thanks, > Leonid. > > > From mik3hall at gmail.com Tue Jul 9 03:13:08 2013 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 9 Jul 2013 05:13:08 -0500 Subject: Support for Apple Extensions In-Reply-To: <51D6B1C8.7060007@oracle.com> References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D69D72.60201@oracle.com> <51D6B1C8.7060007@oracle.com> Message-ID: On Jul 5, 2013, at 6:45 AM, Alan Bateman wrote: > On 05/07/2013 11:18, Artem Ananiev wrote: >> >> : >> >> What about eIO? Is it used by anybody? > I'm interesting in hearing about that too as it looks like FileManager defines a few things that might be more appropriate for java.awt.Desktop. Methods to access a file's type/creator codes that could easily be handled via the file system API (I think Michael Hall's FileSystemProvider might already do this). Artem Ananiev > All the above is UI related stuff (eAWT). It should work in JDK7/8 as it worked in Apple JDK6, since the code was contributed to OpenJDK by Apple with little or no modifications. Note, however, that it is not as supported as public APIs in java.* and javax.* namespace. We don't have any plans to drop support for eAWT, but all the issues in these classes will be of lower priority by default. > > What about eIO? Is it used by anybody? If this project is not entirely committed to supporting some of this. I could try to add more of the eio functionality into my trz project. Would licensing be concern if I did some of it more cut and paste initially to get it in place or should I write it from scratch? I could make this project more available to others somehow. How would be best? I am not thinking of eawt at this point. Artem says it is more supported and should be through JDK8. Although not at a high priority? That I think requires custom hooks between the api and the jdk so I don't think it could be 3rd partied if anyone wanted to? So it still might be wondered where it would be documented? My own opinion is that some of the eawt api's are very important to making java app's work as Mac app's. Would there be a possibility of some of it going into Desktop as was suggested? Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From jesmith at kaon.com Tue Jul 9 06:57:38 2013 From: jesmith at kaon.com (Joshua Smith) Date: Tue, 9 Jul 2013 09:57:38 -0400 Subject: Local file access change with new Java update In-Reply-To: <1BFD4E69-72A8-4DF1-A19B-01B9DDB67FB5@icloud.com> References: <3BBF6C80-748B-4A3B-A8EE-ED163730C557@kaon.com> <1BFD4E69-72A8-4DF1-A19B-01B9DDB67FB5@icloud.com> Message-ID: If you are following the thread, it sounds like Oracle is pretty hostile to this mode of operation (and I can't say I blame them, as it does seem next-to-impossible to allow applets work work properly with the local file system without at the same time losing much of the security sandbox). I'd be really hesitant to suggest that regular users start doing things in their policy files that open them up to security vulnerabilities. Since this really only applies to developers, and you can't use chrome properly from the file system anyway (it doesn't have a "Disable Local File Restrictions" checkbox like Safari does), I think requiring that users access these files through a local web server is not that big a deal. -Joshua On Jul 9, 2013, at 12:31 AM, Kaydell Leavitt wrote: > Hi Joshua, > >> One of my users likes to test their applets locally by just opening the HTML file from the file system (instead of running a local web server). This worked before the most recent update: > > > Wouldn't it work for your users to install a policy file, granting them permissions to do what they need to do? > > Or, using the "policytool" command from the command-line to enable applets to do more than the default permissions allow? > > -- Kaydell > kaydell.leavitt at icloud.com > http://learnbymac.com > > > > > On Jul 8, 2013, at 9:16 AM, Joshua Smith wrote: > >> One of my users likes to test their applets locally by just opening the HTML file from the file system (instead of running a local web server). This worked before the most recent update: >> >> Java Plug-in 10.25.2.15 >> Using JRE version 1.7.0_25-b15 Java HotSpot(TM) 64-Bit Server VM >> >> It appears that there are two issues. One is that getCodeBase(), when running from the local filesystem, is returning an empty string. getDocumentBase() still gives the right result. >> >> If I work around that by using getDocumentBase instead of getCodeBase (which, in this particular case is OK because they should be the same), then I get: >> >> java.security.AccessControlException: access denied ("java.io.FilePermission" "/Other/download/etc..." "read") >> >> So it appears that with "Medium" security (the lowest available setting), applets will run but they cannot read from the file system, even if that's how they ran. >> >> Note that I do have the "Disable Local File Restrictions" checkbox set in the Safari Developer Menu, but I'm guessing that Safari doesn't tell Java about that. >> >> Obviously, the user can just run a local web server, which is what I've told them to do. However, I wanted to make sure that these are both "as designed" security changes, and if not, figure out who I should report the bug to. >> >> -Joshua >> >> >> _______________________________________________ >> 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: >> https://lists.apple.com/mailman/options/java-dev/kaydell.leavitt%40icloud.com >> >> This email sent to kaydell.leavitt at icloud.com > From ca at censhare.de Tue Jul 9 07:03:22 2013 From: ca at censhare.de (Christof Aenderl) Date: Tue, 9 Jul 2013 16:03:22 +0200 Subject: ScreenMenuBar bug fixed in Java 8 but what about 7? Message-ID: Hello, there is this known bug that should be fixed in 8 (b77): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006 Is there any chance to get the fix in 7 too? Apple is closing support for Java 6 more and more and 8 is far away. I getting a bit in trouble because I can't really use Java 7 for Mac at the moment. Thanks and regards, Christof From Sergey.Bylokhov at oracle.com Tue Jul 9 07:25:45 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 09 Jul 2013 18:25:45 +0400 Subject: ScreenMenuBar bug fixed in Java 8 but what about 7? In-Reply-To: References: Message-ID: <51DC1D69.2040907@oracle.com> Hi, Christof. It is already fixed in the jdk7u, which means it will be available in the 7u40. JDK 7 Update 40 Early Access Release: https://jdk7.java.net/download.html On 09.07.2013 18:03, Christof Aenderl wrote: > Hello, > > there is this known bug that should be fixed in 8 (b77): > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006 > > Is there any chance to get the fix in 7 too? > > Apple is closing support for Java 6 more and more and 8 is far away. > I getting a bit in trouble because I can't really use Java 7 for Mac at the moment. > > Thanks and regards, > Christof > -- Best regards, Sergey. From ca at censhare.de Tue Jul 9 07:30:00 2013 From: ca at censhare.de (Christof Aenderl) Date: Tue, 9 Jul 2013 16:30:00 +0200 Subject: ScreenMenuBar bug fixed in Java 8 but what about 7? In-Reply-To: <51DC1D69.2040907@oracle.com> References: <51DC1D69.2040907@oracle.com> Message-ID: <78A65394-74C4-470B-BC88-305122C55F51@censhare.de> Hi Sergey, ok, thank you for the information. I will wait for the update 40 release. Best regards, Christof Am 09.07.2013 um 16:25 schrieb Sergey Bylokhov : > Hi, Christof. > It is already fixed in the jdk7u, which means it will be available in the 7u40. > > JDK 7 Update 40 Early Access Release: > https://jdk7.java.net/download.html > > On 09.07.2013 18:03, Christof Aenderl wrote: >> Hello, >> >> there is this known bug that should be fixed in 8 (b77): >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006 >> >> Is there any chance to get the fix in 7 too? >> >> Apple is closing support for Java 6 more and more and 8 is far away. >> I getting a bit in trouble because I can't really use Java 7 for Mac at the moment. >> >> Thanks and regards, >> Christof >> > > > -- > Best regards, Sergey. > From artem.ananiev at oracle.com Tue Jul 9 07:38:45 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 09 Jul 2013 18:38:45 +0400 Subject: [8] Review request for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread In-Reply-To: <5DF6C263-BEC6-41F0-923E-50ABFC6C065C@oracle.com> References: <51DAE549.1030805@oracle.com> <5DF6C263-BEC6-41F0-923E-50ABFC6C065C@oracle.com> Message-ID: <51DC2075.1000400@oracle.com> On 7/8/2013 8:35 PM, Leonid Romanov wrote: > I encountered the case of unset handlerContext while testing SwingSet3 Web Start app. It is triggered by selecting SwingSet3->About from the global menu bar. Since SwingSet3 doesn't use eAWT, it doesn't register any handlers, so selecting "About" menu item just shows standard Cocoa About dialog. In the code, it is accomplished by the following snippet from _AppEventDispatcher.dispatch: > > if (localHandler == null) { > performDefaultAction(event); > } else { > performUsing(localHandler, event); > } > > _AppEventDispatcher.performDefaultAction() is an abstract method, implemented in _AboutDispacther (shows native about dialog ) and _QuitDispatcher (quits the app). So, in order to display default About dialog we have to do the dispatching, even though handlerContext hasn't been set. Do I get it right, that About and Quit menu handlers are implemented in eAWT code, not in the application code, and in these and only these cases we call performDefaultAction() instead of performUsing()? Could we then write it the following way: > // handler hasn't been set > if (handlerContext == null) { > performDefaultAction(event); > } else { > SunToolkit.invokeLaterOnAppContext(handlerContext, r); > } Thanks, Artem > On Jul 8, 2013, at 8:14 PM, Artem Ananiev wrote: > >> >> The changes look fine, except _AppEventDispatcher.dispatch(). Should we dispatch the event at all, in case handlerContext hasn't been set (or set to null, which should never happen)? I would say no. >> /*= >> Thanks, >> >> Artem >> >> On 7/8/2013 6:28 PM, Leonid Romanov wrote: >>> Hello, >>> Please review a fix for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread, As you aware, recent AppContext usage change in 7u25 exposed a number of AppContext related issues in our code. This particular bug focuses on the incorrect invokeLater() and likes usage on OS X. This issue has been discussed in the following thread: >>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-June/005788.html >>> >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8020038 (might not be available yet) >>> Webrev: http://cr.openjdk.java.net/~leonidr/8020038/webrev.00/ >>> >>> Thanks, >>> Leonid. >>> >>> >>> > From artem.ananiev at oracle.com Tue Jul 9 07:43:03 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 09 Jul 2013 18:43:03 +0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: References: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> <51D3EC77.7000707@oracle.com> Message-ID: <51DC2177.6010008@oracle.com> On 7/7/2013 8:50 PM, Andrew Thompson wrote: > > On Jul 3, 2013, at 5:18 AM, Artem Ananiev wrote: > >> 2. In applet/webstart modes, there may be multiple AppContexts in >> the JVM. All the application code is supposed to run in a single >> AppContext, including all the helper threads running native code. >> If you create a new thread group, it will inherit the current >> AppContext. If you create a new thread group using another (not >> current) thread group as a parent... Well, you should not do that, >> and, actually, untrusted code is not allowed to do that. > > But I can deploy trusted code by signing an applet or a webstart > application and it can create a Thread in another ThreadGroup. > Elsewhere in this thread people mention JNI and RMI threads and > Cocoa's main thread. This is all valid code; there's no prohibitions > against doing any of these things. Even if an applet is signed and has all permissions, I don't think it should create new threads in, say, Java Plugin thread group, right? Note that AppContext is a little bit more complex than a plain Map <-> ThreadGroup mapping. A single AppContext can occupy multiple thread groups, so if you create a thread in a nested thread group, you will be fine. RMI and other issues mentioned in this thread should be fixed, indeed. > I understand it is intended that this AppContext idea is transparent > and ideally it would be. But at the present time it appears that the > abstraction leaks [1] and there is no workarounds possible using > supported code (rather than sun.* classes). Have I misunderstood > something in this thread? > > My feeling is this is something Oracle needs to address. Agree. Thanks, Artem > [1] http://www.joelonsoftware.com/articles/LeakyAbstractions.html > > AndyT (lordpixel - the cat who walks through walls) A little bigger > on the inside > > (see you later space cowboy, you can't take the sky from me) > > From artem.ananiev at oracle.com Tue Jul 9 07:51:05 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 09 Jul 2013 18:51:05 +0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: <379C7587-30F8-458D-B7F0-A9841DC3A20F@blackboard.com> References: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> <51D3EC77.7000707@oracle.com> <379C7587-30F8-458D-B7F0-A9841DC3A20F@blackboard.com> Message-ID: <51DC2359.7080802@oracle.com> On 7/8/2013 7:52 PM, Doug Zwick wrote: > Andrew Thompson wrote: > >> But I can deploy trusted code by signing an applet or a webstart >> application and it can create a Thread in another ThreadGroup. >> Elsewhere in this thread people mention JNI and RMI threads and >> Cocoa's main thread. This is all valid code; there's no >> prohibitions against doing any of these things. > > It may be that the ideal thing for Java to do in this situation is to > have the Thread inherit the AppContext of its creator thread, rather > than that of the ThreadGroup specified in the Thread c'tor. That may > not be practical. Perhaps throwing an Exception in such a > circumstance would be reasonable, or even just a warning message on > System.err. A thread doesn't have an AppContext associated with it. Threads and thread groups are java.lang classes that should not be aware of anything from UI world, e.g. AppContext. So I don't quite understand what you mean by AppContext inheriting here. >> I understand it is intended that this AppContext idea is >> transparent and ideally it would be. But at the present time it >> appears that the abstraction leaks [1] and there is no workarounds >> possible using supported code (rather than sun.* classes). Have I >> misunderstood something in this thread? > > The work-around I came up with was to create my own Thread, in the > right context, that services a queue of Runnables. Then code running > on the AppKit Thread, an RMI Thread, etc. can queue a Runnable to be > run on that Thread (similar to SwingUtilities.invokeLater). It gets > cumbersome to defer things to the Swing thread from such a "bad" > context, as you need to queue a Runnable to the work-around Thread > that then queues yet another Runnable for the Swing Thread. But it > does work. I do not know if invoke-and-wait semantics would be > reasonable, as blocking the AppKit Thread can lead to trouble (i.e. > deadlocks), but may be OK in the RMI case. As I wrote in my previous email, RMI should be fixed in JDK, not workarounded by application developers. A general rule is that all the AppContext machinery should be completely transparent to applications. The only exception can be a library that extends AWT/Swing functionality and should be ready to run on the AppKit thread and work with multiple AppContext. In this case the library will be able to access sun.* APIs, including SunToolkit and AppContext. Java Plugin and Java Web Start can be considered good examples of such libraries. Thanks, Artem > This email and any attachments may contain confidential and > proprietary information of Blackboard that is for the sole use of the > intended recipient. If you are not the intended recipient, > disclosure, copying, re-distribution or other use of any of this > information is strictly prohibited. Please immediately notify the > sender and delete this transmission if you received this email in > error. > From Doug.Zwick at blackboard.com Tue Jul 9 08:49:51 2013 From: Doug.Zwick at blackboard.com (Doug Zwick) Date: Tue, 9 Jul 2013 11:49:51 -0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: <51DC2359.7080802@oracle.com> References: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> <51D3EC77.7000707@oracle.com> <379C7587-30F8-458D-B7F0-A9841DC3A20F@blackboard.com> <51DC2359.7080802@oracle.com> Message-ID: <1B87D2C0-CBFA-4FFD-8C89-1949BA7D71DD@blackboard.com> On 2013-07-09, at 8:51 AM, Artem Ananiev wrote: > On 7/8/2013 7:52 PM, Doug Zwick wrote: >> Andrew Thompson wrote: >> >>> But I can deploy trusted code by signing an applet or a webstart >>> application and it can create a Thread in another ThreadGroup. >>> Elsewhere in this thread people mention JNI and RMI threads and >>> Cocoa's main thread. This is all valid code; there's no >>> prohibitions against doing any of these things. >> >> It may be that the ideal thing for Java to do in this situation is to >> have the Thread inherit the AppContext of its creator thread, rather >> than that of the ThreadGroup specified in the Thread c'tor. That may >> not be practical. Perhaps throwing an Exception in such a >> circumstance would be reasonable, or even just a warning message on >> System.err. > > A thread doesn't have an AppContext associated with it. Threads and > thread groups are java.lang classes that should not be aware of anything > from UI world, e.g. AppContext. So I don't quite understand what you > mean by AppContext inheriting here. I'm not sure how the objects are actually related, but it certainly appears from experimentation (in terms of what EDT invokeLater sends things to) that a given Thread is associated (directly or indirectly) with a particular AppContext, and that that association is fixed for the life of the Thread. >From the discussion, it appears that when a new Thread is created it becomes associated with the AppContext of the ThreadGroup it is assigned to, regardless of the AppContext that was associated with the creating Thread. I was thinking it might make more sense for the new Thread to be associated with the AppContext of the creating Thread, regardless of the AppContext of the ThreadGroup it is placed in. Either that, or forbid such "cross-AppContext" Thread creation operations by throwing an exception. If AppContext is involved at all in security functions, then permitting code to create a Thread associated with some other AppContext would be a violation of the security model, and a potential exploitation path. Even if it is just UI, it is still incorrect for one app/applet to interact with another app/applet's UI, and should be either impossible or forbidden. Just telling developers "don't do that", although necessary, is not sufficient. The JRE needs to enforce it, or at the very least let developers know they've done something wrong (e.g. a console message). >> The work-around I came up with was to create my own Thread, in the >> right context, that services a queue of Runnables. Then code running >> on the AppKit Thread, an RMI Thread, etc. can queue a Runnable to be >> run on that Thread (similar to SwingUtilities.invokeLater). It gets >> cumbersome to defer things to the Swing thread from such a "bad" >> context, as you need to queue a Runnable to the work-around Thread >> that then queues yet another Runnable for the Swing Thread. But it >> does work. I do not know if invoke-and-wait semantics would be >> reasonable, as blocking the AppKit Thread can lead to trouble (i.e. >> deadlocks), but may be OK in the RMI case. > > As I wrote in my previous email, RMI should be fixed in JDK, not > workarounded by application developers. Absolutely. However, for those of us with applications in the field today that are crashing, hanging or otherwise misbehaving, we need to get a fix out to our customers now, and not wait for the next JRE release. A work-around is still needed to cover the immediate-to-short term. Rolling back to a previous version of Java is not an option for some of our customers. This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. From gregg at wonderly.org Wed Jul 10 15:45:34 2013 From: gregg at wonderly.org (Gregg Wonderly) Date: Wed, 10 Jul 2013 17:45:34 -0500 Subject: Local file access change with new Java update In-Reply-To: <15EC04FB-D382-46AC-91F4-839CEDDE37B3@oracle.com> References: <3BBF6C80-748B-4A3B-A8EE-ED163730C557@kaon.com> <938B4B4F-A2D0-4B3C-87A9-57D18347D159@oracle.com> <1E13E777-9118-4D74-BD8E-1CEC02E391B6@wonderly.org> <15EC04FB-D382-46AC-91F4-839CEDDE37B3@oracle.com> Message-ID: <7C19600B-06CE-4DC3-B958-0A384BE73D6B@wonderly.org> It seems rather unfortunate that obscurity is being pushed as a form of security. It isn't, that's why security problems are discovered in the field. You can't obscure problems forever. The subtle implication is that "file:" urls are treated specially by the security manager, in applet mode, compared to network based urls. In the end, everyone is going to jump up and down, and scream and lament about this change for quite some time, and then work around the issue, and try to move on. But, practically, it is exactly this kind of "API usage" change to create security that just amplifies the issue that Sun/Oracle still don't understand the desktop and web use of Java to understand where dependencies are at, and why there is little reason to keep breaking APIs to fix things. For decades (since JDK1.2), people have complained about the in abilities of Java's "shepards" to do an adequate job of creating a stable and productive software development environment. Based on how things are going, visibly to us on the outside, it would seem that some key people who knew what was going on, have left, and now we have all this "discovery" going on with new people trying to figure out what's there, how it works, and still fix problems without breaking things unnecessarily. I'm of the opinion that the edge of the cliff is getting closer rather than far away, even this far into the process of Oracle taking over Java. Adequate training, adequate experience and ultimately acceptable responsibilities for code and the welfare of the developers is what makes a programming language live. Oracle is still painting themselves into a smaller square that is looming closer to the edge of the cliff in my view. Joe, please try and understand, people are making money off of writing software, and if the value is not there, or the dependability and stability doesn't meet the needs of their customers, something will change. You can hold onto "the size of the code base is a huge anchor to keep developers here" for as long as you want. Just understand, that there are non-Java developers creating or recreating all the same software systems on other platforms, in other ways, and at some point, if the weight swings far enough, Java's going to be pushed over the cliff, and that seems like a really stupid event to be a part of? Gregg Wonderly On Jul 8, 2013, at 3:13 PM, Joe McGlynn wrote: > We can't discuss those details, sorry. Fundamentally applets aren't designed for running from the local filesystem. The best practice is to set up a web server deployment environment for development, which gives you a much better approximation of the behavior in actual deployments. > > We will have another mechanism that developers can use to run applets in this more in a controlled way in the near future. > > > > On Jul 8, 2013, at 10:53 AM, Gregg Wonderly wrote: > >> Joe, which security issue does disallowing local access to a filesystem loaded web page address? It seems like a horrible limitation for developers to work around. I appreciate that there are things that the security manager needs to do better in this regard, but I'm not at all sure why this needed to be changed. Is there a bug report or other history/discussion to read about this via? >> >> Gregg Wonderly >> >> On Jul 8, 2013, at 11:59 AM, Joe McGlynn wrote: >> >>> This is the expected behavior. >>> -- >>> On Jul 8, 2013, at 8:16 AM, Joshua Smith wrote: >>> >>>> One of my users likes to test their applets locally by just opening the HTML file from the file system (instead of running a local web server). This worked before the most recent update: >>>> >>>> Java Plug-in 10.25.2.15 >>>> Using JRE version 1.7.0_25-b15 Java HotSpot(TM) 64-Bit Server VM >>>> >>>> It appears that there are two issues. One is that getCodeBase(), when running from the local filesystem, is returning an empty string. getDocumentBase() still gives the right result. >>>> >>>> If I work around that by using getDocumentBase instead of getCodeBase (which, in this particular case is OK because they should be the same), then I get: >>>> >>>> java.security.AccessControlException: access denied ("java.io.FilePermission" "/Other/download/etc..." "read") >>>> >>>> So it appears that with "Medium" security (the lowest available setting), applets will run but they cannot read from the file system, even if that's how they ran. >>>> >>>> Note that I do have the "Disable Local File Restrictions" checkbox set in the Safari Developer Menu, but I'm guessing that Safari doesn't tell Java about that. >>>> >>>> Obviously, the user can just run a local web server, which is what I've told them to do. However, I wanted to make sure that these are both "as designed" security changes, and if not, figure out who I should report the bug to. >>>> >>>> -Joshua >>>> >>> >> > From leonid.romanov at oracle.com Wed Jul 10 19:13:49 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 11 Jul 2013 06:13:49 +0400 Subject: [8] Review request for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread In-Reply-To: <51DC2075.1000400@oracle.com> References: <51DAE549.1030805@oracle.com> <5DF6C263-BEC6-41F0-923E-50ABFC6C065C@oracle.com> <51DC2075.1000400@oracle.com> Message-ID: <9EB56B39-1F5B-4973-8BF9-9BFA305078C4@oracle.com> On Jul 9, 2013, at 6:38 PM, Artem Ananiev wrote: > > On 7/8/2013 8:35 PM, Leonid Romanov wrote: >> I encountered the case of unset handlerContext while testing SwingSet3 Web Start app. It is triggered by selecting SwingSet3->About from the global menu bar. Since SwingSet3 doesn't use eAWT, it doesn't register any handlers, so selecting "About" menu item just shows standard Cocoa About dialog. In the code, it is accomplished by the following snippet from _AppEventDispatcher.dispatch: >> >> if (localHandler == null) { >> performDefaultAction(event); >> } else { >> performUsing(localHandler, event); >> } >> >> _AppEventDispatcher.performDefaultAction() is an abstract method, implemented in _AboutDispacther (shows native about dialog ) and _QuitDispatcher (quits the app). So, in order to display default About dialog we have to do the dispatching, even though handlerContext hasn't been set. > > Do I get it right, that About and Quit menu handlers are implemented in eAWT code, not in the application code, and in these and only these cases we call performDefaultAction() instead of performUsing()? Could we then write it the following way: > >> // handler hasn't been set >> if (handlerContext == null) { >> performDefaultAction(event); >> } else { >> SunToolkit.invokeLaterOnAppContext(handlerContext, r); >> } > Yes, you are right. Done. I've also cleared /_AppEventHandler._AppEventMultiplexor code a bit. Here is the new webrev: http://cr.openjdk.java.net/~leonidr/8020038/webrev.01/ From anthony.petrov at oracle.com Thu Jul 11 04:22:31 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 11 Jul 2013 15:22:31 +0400 Subject: [8] Review request for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread In-Reply-To: <9EB56B39-1F5B-4973-8BF9-9BFA305078C4@oracle.com> References: <51DAE549.1030805@oracle.com> <5DF6C263-BEC6-41F0-923E-50ABFC6C065C@oracle.com> <51DC2075.1000400@oracle.com> <9EB56B39-1F5B-4973-8BF9-9BFA305078C4@oracle.com> Message-ID: <51DE9577.7070502@oracle.com> The fix still looks fine to me. -- best regards, Anthony On 07/11/13 06:13, Leonid Romanov wrote: > > On Jul 9, 2013, at 6:38 PM, Artem Ananiev wrote: > >> >> On 7/8/2013 8:35 PM, Leonid Romanov wrote: >>> I encountered the case of unset handlerContext while testing SwingSet3 Web Start app. It is triggered by selecting SwingSet3->About from the global menu bar. Since SwingSet3 doesn't use eAWT, it doesn't register any handlers, so selecting "About" menu item just shows standard Cocoa About dialog. In the code, it is accomplished by the following snippet from _AppEventDispatcher.dispatch: >>> >>> if (localHandler == null) { >>> performDefaultAction(event); >>> } else { >>> performUsing(localHandler, event); >>> } >>> >>> _AppEventDispatcher.performDefaultAction() is an abstract method, implemented in _AboutDispacther (shows native about dialog ) and _QuitDispatcher (quits the app). So, in order to display default About dialog we have to do the dispatching, even though handlerContext hasn't been set. >> >> Do I get it right, that About and Quit menu handlers are implemented in eAWT code, not in the application code, and in these and only these cases we call performDefaultAction() instead of performUsing()? Could we then write it the following way: >> >>> // handler hasn't been set >>> if (handlerContext == null) { >>> performDefaultAction(event); >>> } else { >>> SunToolkit.invokeLaterOnAppContext(handlerContext, r); >>> } >> > > Yes, you are right. Done. I've also cleared /_AppEventHandler._AppEventMultiplexor code a bit. Here is the new webrev: > http://cr.openjdk.java.net/~leonidr/8020038/webrev.01/ > > From artem.ananiev at oracle.com Thu Jul 11 04:22:04 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 11 Jul 2013 15:22:04 +0400 Subject: [8] Review request for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread In-Reply-To: <51DE9577.7070502@oracle.com> References: <51DAE549.1030805@oracle.com> <5DF6C263-BEC6-41F0-923E-50ABFC6C065C@oracle.com> <51DC2075.1000400@oracle.com> <9EB56B39-1F5B-4973-8BF9-9BFA305078C4@oracle.com> <51DE9577.7070502@oracle.com> Message-ID: <51DE955C.7050304@oracle.com> +1 Thanks, Artem On 7/11/2013 3:22 PM, Anthony Petrov wrote: > The fix still looks fine to me. > > -- > best regards, > Anthony > > On 07/11/13 06:13, Leonid Romanov wrote: >> >> On Jul 9, 2013, at 6:38 PM, Artem Ananiev >> wrote: >> >>> >>> On 7/8/2013 8:35 PM, Leonid Romanov wrote: >>>> I encountered the case of unset handlerContext while testing >>>> SwingSet3 Web Start app. It is triggered by selecting >>>> SwingSet3->About from the global menu bar. Since SwingSet3 doesn't >>>> use eAWT, it doesn't register any handlers, so selecting "About" >>>> menu item just shows standard Cocoa About dialog. In the code, it is >>>> accomplished by the following snippet from >>>> _AppEventDispatcher.dispatch: >>>> >>>> if (localHandler == null) { >>>> performDefaultAction(event); >>>> } else { >>>> performUsing(localHandler, event); >>>> } >>>> >>>> _AppEventDispatcher.performDefaultAction() is an abstract method, >>>> implemented in _AboutDispacther (shows native about dialog ) and >>>> _QuitDispatcher (quits the app). So, in order to display default >>>> About dialog we have to do the dispatching, even though >>>> handlerContext hasn't been set. >>> >>> Do I get it right, that About and Quit menu handlers are implemented >>> in eAWT code, not in the application code, and in these and only >>> these cases we call performDefaultAction() instead of performUsing()? >>> Could we then write it the following way: >>> >>>> // handler hasn't been set >>>> if (handlerContext == null) { >>>> performDefaultAction(event); >>>> } else { >>>> SunToolkit.invokeLaterOnAppContext(handlerContext, r); >>>> } >>> >> >> Yes, you are right. Done. I've also cleared >> /_AppEventHandler._AppEventMultiplexor code a bit. Here is the new >> webrev: >> http://cr.openjdk.java.net/~leonidr/8020038/webrev.01/ >> >> From neugens.limasoftware at gmail.com Thu Jul 11 06:43:10 2013 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 11 Jul 2013 15:43:10 +0200 Subject: Local file access change with new Java update In-Reply-To: <7C19600B-06CE-4DC3-B958-0A384BE73D6B@wonderly.org> References: <3BBF6C80-748B-4A3B-A8EE-ED163730C557@kaon.com> <938B4B4F-A2D0-4B3C-87A9-57D18347D159@oracle.com> <1E13E777-9118-4D74-BD8E-1CEC02E391B6@wonderly.org> <15EC04FB-D382-46AC-91F4-839CEDDE37B3@oracle.com> <7C19600B-06CE-4DC3-B958-0A384BE73D6B@wonderly.org> Message-ID: 2013/7/11 Gregg Wonderly : > It seems rather unfortunate that obscurity is being pushed as a form of security. It isn't, that's why security problems are discovered in the field. You can't obscure problems forever. The subtle implication is that "file:" urls are treated specially by the security manager, in applet mode, compared to network based urls. This is not really security-by-obscurity. The security patch is out, everybody can study it. I'm also sure you can find enough information if you know where to search. Nobody really hopes that not sharing the security details will prevent people from exploiting the unpatched systems. The only reason why details are not discussed in public is to not make it too easy for people to reproduce the issue. Sometimes you also have NDA or other legal matters preventing you from a public discussion. Note, I'm not saying this is the case for this patch, just saying this is how things work usually. Can Security be handled better? Yes, probably. But the discussion on how to improve it should be moved to the Governing Board in my opinion. If you want to have your voice heard, join the Java Community and participate; criticisms welcomed, as long as it's constructive. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From artem.ananiev at oracle.com Fri Jul 12 08:36:15 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 12 Jul 2013 19:36:15 +0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: <1B87D2C0-CBFA-4FFD-8C89-1949BA7D71DD@blackboard.com> References: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> <51D3EC77.7000707@oracle.com> <379C7587-30F8-458D-B7F0-A9841DC3A20F@blackboard.com> <51DC2359.7080802@oracle.com> <1B87D2C0-CBFA-4FFD-8C89-1949BA7D71DD@blackboard.com> Message-ID: <51E0226F.40306@oracle.com> On 7/9/2013 7:49 PM, Doug Zwick wrote: > On 2013-07-09, at 8:51 AM, Artem Ananiev wrote: > >> On 7/8/2013 7:52 PM, Doug Zwick wrote: >>> Andrew Thompson wrote: >>> >>>> But I can deploy trusted code by signing an applet or a >>>> webstart application and it can create a Thread in another >>>> ThreadGroup. Elsewhere in this thread people mention JNI and >>>> RMI threads and Cocoa's main thread. This is all valid code; >>>> there's no prohibitions against doing any of these things. >>> >>> It may be that the ideal thing for Java to do in this situation >>> is to have the Thread inherit the AppContext of its creator >>> thread, rather than that of the ThreadGroup specified in the >>> Thread c'tor. That may not be practical. Perhaps throwing an >>> Exception in such a circumstance would be reasonable, or even >>> just a warning message on System.err. >> >> A thread doesn't have an AppContext associated with it. Threads >> and thread groups are java.lang classes that should not be aware of >> anything from UI world, e.g. AppContext. So I don't quite >> understand what you mean by AppContext inheriting here. > > I'm not sure how the objects are actually related, but it certainly > appears from experimentation (in terms of what EDT invokeLater sends > things to) that a given Thread is associated (directly or indirectly) > with a particular AppContext, and that that association is fixed for > the life of the Thread. From the discussion, it appears that when a Yes, that's correct. > new Thread is created it becomes associated with the AppContext of > the ThreadGroup it is assigned to, regardless of the AppContext that > was associated with the creating Thread. I was thinking it might make > more sense for the new Thread to be associated with the AppContext of > the creating Thread, regardless of the AppContext of the ThreadGroup > it is placed in. Either that, or forbid such "cross-AppContext" Note that all the AppContexts are created from the same code in Java Plugin or Java Web Start... So yes, what you propose indeed can be implemented, but it would be an incompatible change. AppContext association is the same as thread <-> thread group relationship. Right now we allow creating threads in arbitrary thread groups, while your proposal is to always create new threads in the thread group of the calling thread. > Thread creation operations by throwing an exception. If AppContext is > involved at all in security functions, then permitting code to create > a Thread associated with some other AppContext would be a violation > of the security model, and a potential exploitation path. Even if it > is just UI, it is still incorrect for one app/applet to interact with > another app/applet's UI, and should be either impossible or > forbidden. Just telling developers "don't do that", although > necessary, is not sufficient. The JRE needs to enforce it, or at the > very least let developers know they've done something wrong (e.g. a > console message). You're absolutely right, applets should not interact with each other (unless they share the same codebase), and the latest fixes in AppContext management were exactly to enforce that. >>> The work-around I came up with was to create my own Thread, in >>> the right context, that services a queue of Runnables. Then code >>> running on the AppKit Thread, an RMI Thread, etc. can queue a >>> Runnable to be run on that Thread (similar to >>> SwingUtilities.invokeLater). It gets cumbersome to defer things >>> to the Swing thread from such a "bad" context, as you need to >>> queue a Runnable to the work-around Thread that then queues yet >>> another Runnable for the Swing Thread. But it does work. I do not >>> know if invoke-and-wait semantics would be reasonable, as >>> blocking the AppKit Thread can lead to trouble (i.e. deadlocks), >>> but may be OK in the RMI case. If your code is allowed to deal with multiple event dispatch threads from different AppContext, you can then use SunToolkit's methods to find the right EDT/AppContext for a given component. This is not something I would propose as a generic solution, it's code from sun.* after all, but as a temporary workaround, it may work. >> As I wrote in my previous email, RMI should be fixed in JDK, not >> workarounded by application developers. > > Absolutely. However, for those of us with applications in the field > today that are crashing, hanging or otherwise misbehaving, we need to > get a fix out to our customers now, and not wait for the next JRE > release. A work-around is still needed to cover the > immediate-to-short term. Rolling back to a previous version of Java > is not an option for some of our customers. This is understood... Thanks, Artem > This email and any attachments may contain confidential and > proprietary information of Blackboard that is for the sole use of the > intended recipient. If you are not the intended recipient, > disclosure, copying, re-distribution or other use of any of this > information is strictly prohibited. Please immediately notify the > sender and delete this transmission if you received this email in > error. > From Doug.Zwick at blackboard.com Fri Jul 12 09:52:51 2013 From: Doug.Zwick at blackboard.com (Doug Zwick) Date: Fri, 12 Jul 2013 12:52:51 -0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: <51E0226F.40306@oracle.com> References: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> <51D3EC77.7000707@oracle.com> <379C7587-30F8-458D-B7F0-A9841DC3A20F@blackboard.com> <51DC2359.7080802@oracle.com> <1B87D2C0-CBFA-4FFD-8C89-1949BA7D71DD@blackboard.com> <51E0226F.40306@oracle.com> Message-ID: <8DB5008C-D74A-45DC-853B-358223A06D16@blackboard.com> On 2013-07-12, at 9:36 AM, Artem Ananiev wrote: > AppContext association is the same as thread <-> thread group > relationship. Right now we allow creating threads in arbitrary thread > groups, while your proposal is to always create new threads in the > thread group of the calling thread. I was thinking (wishfully, perhaps) that the association of the Thread with an arbitrary ThreadGroup could be maintained, but that the Thread would be associated with the AppContext of the creating Thread. If the AppContext association is tied to the ThreadGroup, then that won't work. I guess my thought was that the association between AppContext and ThreadGroup was only a correlation, and not an actual reference. On the other hand, it is good to know that the relationship between AppContext and ThreadGroup is that tightly bound. It gives me greater confidence that the work-around in our code will solve the problem in all cases. > You're absolutely right, applets should not interact with each other > (unless they share the same codebase), and the latest fixes in > AppContext management were exactly to enforce that. It looks like there is a loophole in the implementation, where creating a Thread with a particular ThreadGroup can still allow such interaction to occur. It would be good to plug that hole. Throwing an exception when this occurs would not change the API, and SecurityException is already documented as potentially being thrown by the applicable Thread constructors. If the JRE can't make it "just work" (i.e. associate the thread with the correct AppContext and the specified ThreadGroup), then it should fail hard and fast. There may be other, possibly better, ways of dealing with this. This is just what came to mind as one way to solve the problem. >>>> The work-around I came up with was to create my own Thread, in >>>> the right context, that services a queue of Runnables. Then code >>>> running on the AppKit Thread, an RMI Thread, etc. can queue a >>>> Runnable to be run on that Thread (similar to >>>> SwingUtilities.invokeLater). It gets cumbersome to defer things >>>> to the Swing thread from such a "bad" context, as you need to >>>> queue a Runnable to the work-around Thread that then queues yet >>>> another Runnable for the Swing Thread. But it does work. I do not >>>> know if invoke-and-wait semantics would be reasonable, as >>>> blocking the AppKit Thread can lead to trouble (i.e. deadlocks), >>>> but may be OK in the RMI case. > > If your code is allowed to deal with multiple event dispatch threads > from different AppContext, you can then use SunToolkit's methods to find > the right EDT/AppContext for a given component. This is not something I > would propose as a generic solution, it's code from sun.* after all, but > as a temporary workaround, it may work. As a temporary work-around to handle the cases where multiple contexts and EDTs intrude on app code due to either JRE or 3rd party library bugs, I think it is probably better to run through a Thread in my own ThreadGroup. It works reliably, even if it adds additional latency. The SunToolkit API is not publicly documented, and there could be hidden gotchas lurking there. In hacks like this, "Keep It Simple" is good advice. A simple hack is also faster to test and deploy when you have paying customers dead in the water. I do still have some concern about the case of JNI callbacks on the toolkit (AppKit) thread. Either JNI needs to handle the AppContext internally, or some public API needs to be made available to JNI developers. I would prefer the former, but would take the latter if the former couldn't be done in a timely manner. A native-side API would be adequate, and not be visible from Java. This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. From terry at trwarren.com Fri Jul 12 10:01:09 2013 From: terry at trwarren.com (terry at trwarren.com) Date: Fri, 12 Jul 2013 10:01:09 -0700 Subject: gui scripting Message-ID: <390a74ab9470d59730d3fe8176248573.squirrel@webmail.trwarren.com> Hi - I apologize in advance if this is not the appropriate forum for my question. I am trying to understand whether the Oracle jdk port of 1.7 supports gui scripting using applescript. I have created a mac os x app via the app bundler from Oracle and the app itself works fine but (with assistive devices enabled in System Preferences) I cannot access the gui elements of the app from applescript even though the application seems to be recognized (eg with if process "app name" exists). Anyone had experience with this? thanks Terry Warren From mik3hall at gmail.com Fri Jul 12 14:01:49 2013 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 12 Jul 2013 16:01:49 -0500 Subject: gui scripting In-Reply-To: <390a74ab9470d59730d3fe8176248573.squirrel@webmail.trwarren.com> References: <390a74ab9470d59730d3fe8176248573.squirrel@webmail.trwarren.com> Message-ID: <83D51F9B-2C49-41F5-98FA-0C8CAF4A4A72@gmail.com> On Jul 12, 2013, at 12:01 PM, terry at trwarren.com wrote: > Hi - I apologize in advance if this is not the appropriate forum for my > question. > > I am trying to understand whether the Oracle jdk port of 1.7 supports gui > scripting using applescript. I have created a mac os x app via the app > bundler from Oracle and the app itself works fine but (with assistive > devices enabled in System Preferences) I cannot access the gui elements of > the app from applescript even though the application seems to be > recognized (eg with if process "app name" exists). Anyone had experience > with this? You might want to check the archives for Apple java-dev list. As I recall there was limited gui scripting through the accessibility(?) a pi's. But it was never talked about much and I never tried it myself. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From kaydell.leavitt at icloud.com Fri Jul 12 15:03:53 2013 From: kaydell.leavitt at icloud.com (Kaydell Leavitt) Date: Fri, 12 Jul 2013 16:03:53 -0600 Subject: gui scripting In-Reply-To: <390a74ab9470d59730d3fe8176248573.squirrel@webmail.trwarren.com> References: <390a74ab9470d59730d3fe8176248573.squirrel@webmail.trwarren.com> Message-ID: Hi Terry, I think that this will be useful to you: http://www.macosxautomation.com/applescript/uiscripting/ I don't think that it matters whether Java supports GUI scripting or not. I believe that GUI scripting is for apps that don't support scriptability through AppleEvents. Going through AppleEvents is like having a second user-interface which is especially made for scripting language such as AppleScript that use AppleEvents to control apps. Using GUI Scripting is resorted too if scripting language needs to control an app that isn't "scriptable". The scripts in the link above, turn on accessibility, enabling GUI scripting for "non-scriptable' applications. So, it's better to go through AppleEvents, but if you have to, you can do GUI Scripting. -- Kaydell kaydell.leavitt at icloud.com http://learnbymac.com On Jul 12, 2013, at 11:01 AM, terry at trwarren.com wrote: > Hi - I apologize in advance if this is not the appropriate forum for my > question. > > I am trying to understand whether the Oracle jdk port of 1.7 supports gui > scripting using applescript. I have created a mac os x app via the app > bundler from Oracle and the app itself works fine but (with assistive > devices enabled in System Preferences) I cannot access the gui elements of > the app from applescript even though the application seems to be > recognized (eg with if process "app name" exists). Anyone had experience > with this? > > thanks > Terry Warren > From terry at trwarren.com Fri Jul 12 15:52:30 2013 From: terry at trwarren.com (Terry Warren) Date: Fri, 12 Jul 2013 15:52:30 -0700 Subject: gui scripting In-Reply-To: References: <390a74ab9470d59730d3fe8176248573.squirrel@webmail.trwarren.com> Message-ID: <308203F4-D607-4A51-9043-7F17DBEFD45F@trwarren.com> thanks Kaydell - this is basically what I am trying to do, but the problem is the following: using this approach (i.e. via "System Events" application) it turns out that I can actually access the java app's ui elements and extract their values and properties as expected but cannot control them. The basic issue seems to be that to control the ui you need to "activate" the app's process in case its not the current active app and the following script snippet does not accomplish this: tell application "System Events" if process "MyJavaApp" exists then log "found my process" set tf to value of text field 1 of window 1 of process "MyJavaApp" log tf tell process "MyJavaApp" activate end tell end if end tell the log messages do get written but the process doesn't activate so, for example, you can't focus to text field 1 and set its value. It appears that the jvm somehow is not letting these types of ui messages to be sent on to the running java app. It might be that the app has to be addressed in a different way? Terry so On Jul 12, 2013, at 3:03 PM, Kaydell Leavitt wrote: > Hi Terry, > > I think that this will be useful to you: > > http://www.macosxautomation.com/applescript/uiscripting/ > > I don't think that it matters whether Java supports GUI scripting or not. I believe that GUI scripting is for apps that don't support scriptability through AppleEvents. Going through AppleEvents is like having a second user-interface which is especially made for scripting language such as AppleScript that use AppleEvents to control apps. > > Using GUI Scripting is resorted too if scripting language needs to control an app that isn't "scriptable". > > The scripts in the link above, turn on accessibility, enabling GUI scripting for "non-scriptable' applications. > > So, it's better to go through AppleEvents, but if you have to, you can do GUI Scripting. > > -- Kaydell > kaydell.leavitt at icloud.com > http://learnbymac.com > > > > > On Jul 12, 2013, at 11:01 AM, terry at trwarren.com wrote: > >> Hi - I apologize in advance if this is not the appropriate forum for my >> question. >> >> I am trying to understand whether the Oracle jdk port of 1.7 supports gui >> scripting using applescript. I have created a mac os x app via the app >> bundler from Oracle and the app itself works fine but (with assistive >> devices enabled in System Preferences) I cannot access the gui elements of >> the app from applescript even though the application seems to be >> recognized (eg with if process "app name" exists). Anyone had experience >> with this? >> >> thanks >> Terry Warren >> > From artem.ananiev at oracle.com Mon Jul 15 02:29:17 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 15 Jul 2013 13:29:17 +0400 Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? In-Reply-To: References: <2B95677E-DA91-4E67-A54B-FEBCC34D6066@blackboard.com> <51D3EC77.7000707@oracle.com> <51DC2177.6010008@oracle.com> Message-ID: <51E3C0ED.4060806@oracle.com> On 7/13/2013 6:18 PM, Andrew Thompson wrote: > > On Jul 9, 2013, at 10:43 AM, Artem Ananiev wrote: > >> >> On 7/7/2013 8:50 PM, Andrew Thompson wrote: >>> >>> But I can deploy trusted code by signing an applet or a webstart >>> application and it can create a Thread in another ThreadGroup. >>> Elsewhere in this thread people mention JNI and RMI threads and >>> Cocoa's main thread. This is all valid code; there's no prohibitions >>> against doing any of these things. >> >> Even if an applet is signed and has all permissions, I don't think it should create new threads in, say, Java Plugin thread group, right? Note that AppContext is a little bit more complex than a plain Map <-> ThreadGroup mapping. A single AppContext can occupy multiple thread groups, so if you create a thread in a nested thread group, you will be fine. >> >> RMI and other issues mentioned in this thread should be fixed, indeed. > > Good to see we agree on this. Yes, creating Threads in random ThreadGroups has always felt wrong to me - I've always taken the view if I do that I deserve to have problems. So while I agree with you it's a bad idea I don't think I've ever seen a document which says explicitly what is and isn't legal: > > 1/ Clearly a sandboxed application that isn't signed is going to have a lot of restrictions - it should expect to be limited to nested ThreadGroups. That's correct. > 2/ A standalone Java application running without a SecurityManager can do whatever it pleases - if it can get a reference to a ThreadGroup it can use it, but fortunately AppContext doesn't apply there. In standalone mode, there is one AppContext for the root thread group (and all the nested groups, unless application explicitly creates more AppContexts). > 3/ The case which seems fuzzy to me is what can a signed and fully permissioned Webstart/Applet application do? Is it like 1/ or 2/ or something in between? I don't believe I've ever found that documented. In this case, application is able to access all the thread groups and do whatever it needs. However, it should be ready to handle cases, when there is no AppContext (no UI) in a thread group, or AppContext is different than application's own AppContext. This is not what we want to clearly document or add specification for, because it's supposed to be completely transparent for applications (unfortunately, sometimes it is not). > I think the important point is actually the RMI/JIN/Cocoa stuff but the question above isn't entirely academic as folks are often required to use 3rd party libraries whose source isn't available to them to modify which may do questionable thing. But in the grand scheme of things if the common cases all work defining the precise rules for 3/ is less important. Thanks, Artem > AndyT (lordpixel - the cat who walks through walls) > A little bigger on the inside > > (see you later space cowboy, you can't take the sky from me) > From mik3hall at gmail.com Mon Jul 15 03:29:24 2013 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 15 Jul 2013 05:29:24 -0500 Subject: Support for Apple Extensions In-Reply-To: References: <59B7CED4-0230-47B0-862F-24C297EA2DD1@gmail.com> <51D67989.5060304@oracle.com> <1BEB5C1F-63EF-4BCC-B1A9-64D14764AF2A@winnall.ch> <51D6899D.9050406@fastmail.fm> <51D68C11.2000900@oracle.com> <369984E4-08C9-4E45-B9B7-0FA9E28B9814@icloud.com> <51D69D72.60201@oracle.com> <51D6B1C8.7060007@oracle.com> Message-ID: <6B53E781-2678-4648-9C37-AECD12B711F0@gmail.com> On Jul 9, 2013, at 5:13 AM, Michael Hall wrote: > On Jul 5, 2013, at 6:45 AM, Alan Bateman wrote: > >> On 05/07/2013 11:18, Artem Ananiev wrote: >>> >>> : >>> >>> What about eIO? Is it used by anybody? >> I'm interesting in hearing about that too as it looks like FileManager defines a few things that might be more appropriate for java.awt.Desktop. Methods to access a file's type/creator codes that could easily be handled via the file system API (I think Michael Hall's FileSystemProvider might already do this). > > > Artem Ananiev > >> All the above is UI related stuff (eAWT). It should work in JDK7/8 as it worked in Apple JDK6, since the code was contributed to OpenJDK by Apple with little or no modifications. Note, however, that it is not as supported as public APIs in java.* and javax.* namespace. We don't have any plans to drop support for eAWT, but all the issues in these classes will be of lower priority by default. >> >> What about eIO? Is it used by anybody? > > If this project is not entirely committed to supporting some of this. I could try to add more of the eio functionality into my trz project. Would licensing be concern if I did some of it more cut and paste initially to get it in place or should I write it from scratch? I could make this project more available to others somehow. How would be best? > > I am not thinking of eawt at this point. Artem says it is more supported and should be through JDK8. Although not at a high priority? That I think requires custom hooks between the api and the jdk so I don't think it could be 3rd partied if anyone wanted to? > > So it still might be wondered where it would be documented? My own opinion is that some of the eawt api's are very important to making java app's work as Mac app's. Would there be a possibility of some of it going into Desktop as was suggested? No response back on this but I did throw something together. Definitely still needs work. Again this is just for eio. Javadoc http://www195.pair.com/mik3hall/doc/us/hall/osx/eio/FileManager.html http://www195.pair.com/mik3hall/doc/us/hall/osx/eio/FileHelper.html It appears Oracle has applied the classpath exception to the java and CFileManager native for FileManager. My understanding is that this is pretty good about allowing copying and relicensing. So for most of the FileManager functionality I did just do a copy and paste. The exception there would be for the file/creator meta data. As was mentioned my trz package already included some nio.2 support for that using a custom Mac filesystemprovider. Actually it supports three different file attribute views, for three different api's. mac_finder with 9 different meta attributes. You didn't think color was file meta data? Set the label finder label attribute for a file to orange. mac_ls launch services api's. redundant for 3 of the finder api's, but still adds 9 of it's own meta attributes. mac_cocoa adds 26 meta attributes, redundant with a lot of what is in finder and ls and probably most of what is in the jdk posix attribute view. FileManager again is supposed to be functionally equivalent to the current Apple class. I added a separate FileHelper class to accomplish two things. First, make the use of the above attributes easier for developers who haven't had a chance to get familiar with the new nio.2 api's. To list available trz attribute views public static String[] getTRZViews() To list meta attributes for that view public static ArrayList listAttributes(String view) to access those attributes public static Object getAttribute(File f,String attr) Will sequentially search all three supported views for the attribute, returning the first found. The methods to actually indicate the view isn't there yet. This a little thrown together yet. The second thing FileHelper tries to do is use the launch services meta data to help on those occasions when you want to work with a file using another application. For example open a html file with the default browser. This is sort of why the mac_ls attribute view is there. To determine applications for files? public static File[] getApplications(File f) The default? public static File getDefaultApplication(File f) It has methods using runtime exec for the open command to pass those files to the application concerned. Open with the default app?. public static void open(File f) Open with preferred app? public static void open(File f,File app) Anyhow, I have the thing on github. https://github.com/mik3hall/trz If you want a project with open source support of the Apple eio.FileManager extension, this could do it. I would also like to think it could add some value of it's own. One possibility if you want to somehow split eawt and eio support. Or how they are handled going forward. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From ekrichardson at gmail.com Mon Jul 15 10:05:22 2013 From: ekrichardson at gmail.com (Eric Richardson) Date: Mon, 15 Jul 2013 10:05:22 -0700 Subject: OT - Selecting a Mac for development Message-ID: Hi All, I have been following this list for a long time so figure this is a great place to ask. I'm trying to get a new computer for Java/Scala development to replace an old iMac. I would like to get a laptop but they are a bit pricey so I'd consider and iMac or Mini. Two questions to help narrow my selection. 1. Is 8GB memory ok or do you recommend 16? 2. Is an SSD drive like on the Macbook Pro a big advantage for compilation over an iMac or Mini? Any help appreciated. Eric From Kustaa.Nyholm at planmeca.com Mon Jul 15 10:53:33 2013 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 15 Jul 2013 20:53:33 +0300 Subject: OT - Selecting a Mac for development In-Reply-To: Message-ID: On 15/07/2013 20:05, "Eric Richardson" wrote: >Hi All, > >I have been following this list for a long time so figure this is a great >place to ask. > >I'm trying to get a new computer for Java/Scala development to replace an >old iMac. I would like to get a laptop but they are a bit pricey so I'd >consider and iMac or Mini. Two questions to help narrow my selection. > >1. Is 8GB memory ok or do you recommend 16? >2. Is an SSD drive like on the Macbook Pro a big advantage for compilation >over an iMac or Mini? Can't say about Scala but I have 8 GB / 512 GB SSD Retina and it is amazing compared to my previous Macbook Pro, my only regret is that I was in such a hurry to get this new machine that I could not wait for 16 GB to be available... SSD is simply great and memory being so cheap why skimp on that, it is not as if you are going to buy a new computer every half year .... Just my 2 snt. br Kusti This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. From kirk at kodewerk.com Mon Jul 15 11:08:45 2013 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 15 Jul 2013 20:08:45 +0200 Subject: OT - Selecting a Mac for development In-Reply-To: References: Message-ID: <6881514F-471F-4597-8026-D59D1A7FEB8A@kodewerk.com> +1, buy the biggest laptop you can afford. Favour memory over processor speed. Regards, Kirk On 2013-07-15, at 7:53 PM, Kustaa Nyholm wrote: > On 15/07/2013 20:05, "Eric Richardson" wrote: > >> Hi All, >> >> I have been following this list for a long time so figure this is a great >> place to ask. >> >> I'm trying to get a new computer for Java/Scala development to replace an >> old iMac. I would like to get a laptop but they are a bit pricey so I'd >> consider and iMac or Mini. Two questions to help narrow my selection. >> >> 1. Is 8GB memory ok or do you recommend 16? >> 2. Is an SSD drive like on the Macbook Pro a big advantage for compilation >> over an iMac or Mini? > > > Can't say about Scala but I have 8 GB / 512 GB SSD Retina and it is > amazing > compared to my previous Macbook Pro, my only regret is that I was in such > a hurry to get this new machine that I could not wait for 16 GB to be > available... > > SSD is simply great and memory being so cheap why skimp on that, it is not > as if you are going to buy a new computer every half year .... > > Just my 2 snt. > > br Kusti > > > This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. From ekrichardson at gmail.com Mon Jul 15 11:12:13 2013 From: ekrichardson at gmail.com (Eric Richardson) Date: Mon, 15 Jul 2013 11:12:13 -0700 Subject: OT - Selecting a Mac for development In-Reply-To: References: Message-ID: Hi Kustaa and Kirk, I was thinking 16GB and Laptop/SSD but they are pretty pricey so I wanted to ask. Eric On Mon, Jul 15, 2013 at 10:53 AM, Kustaa Nyholm wrote: > On 15/07/2013 20:05, "Eric Richardson" wrote: > > >Hi All, > > > >I have been following this list for a long time so figure this is a great > >place to ask. > > > >I'm trying to get a new computer for Java/Scala development to replace an > >old iMac. I would like to get a laptop but they are a bit pricey so I'd > >consider and iMac or Mini. Two questions to help narrow my selection. > > > >1. Is 8GB memory ok or do you recommend 16? > >2. Is an SSD drive like on the Macbook Pro a big advantage for compilation > >over an iMac or Mini? > > > Can't say about Scala but I have 8 GB / 512 GB SSD Retina and it is > amazing > compared to my previous Macbook Pro, my only regret is that I was in such > a hurry to get this new machine that I could not wait for 16 GB to be > available... > > SSD is simply great and memory being so cheap why skimp on that, it is not > as if you are going to buy a new computer every half year .... > > Just my 2 snt. > > br Kusti > > > This e-mail may contain confidential or privileged information. If you are > not the intended recipient (or have received this e-mail in error) please > notify the sender immediately and destroy this e-mail. Any unauthorized > copying, disclosure or distribution of the material in this e-mail is > strictly forbidden. We will not be liable for direct, indirect, special or > consequential damages arising from alteration of the contents of this > message by a third party or as a result of any virus being passed on or as > of transmission of this e-mail in general. > From Fabrizio.Giudici at tidalwave.it Mon Jul 15 11:14:28 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Mon, 15 Jul 2013 20:14:28 +0200 Subject: OT - Selecting a Mac for development In-Reply-To: <6881514F-471F-4597-8026-D59D1A7FEB8A@kodewerk.com> References: <6881514F-471F-4597-8026-D59D1A7FEB8A@kodewerk.com> Message-ID: On Mon, 15 Jul 2013 20:08:45 +0200, Kirk Pepperdine wrote: > +1, buy the biggest laptop you can afford. Favour memory over processor > speed. +1 and for me the SSD has been a life changer. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From paul_t100 at fastmail.fm Mon Jul 15 11:53:55 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Mon, 15 Jul 2013 19:53:55 +0100 Subject: OT - Selecting a Mac for development In-Reply-To: References: Message-ID: <51E44543.2040703@fastmail.fm> On 15/07/2013 19:12, Eric Richardson wrote: > Hi Kustaa and Kirk, > > I was thinking 16GB and Laptop/SSD but they are pretty pricey so I wanted > to ask. > > Eric > > > On Mon, Jul 15, 2013 at 10:53 AM, Kustaa Nyholm > wrote: > >> On 15/07/2013 20:05, "Eric Richardson" wrote: >> >>> Hi All, >>> >>> I have been following this list for a long time so figure this is a great >>> place to ask. >>> >>> I'm trying to get a new computer for Java/Scala development to replace an >>> old iMac. I would like to get a laptop but they are a bit pricey so I'd >>> consider and iMac or Mini. Two questions to help narrow my selection. >>> >>> 1. Is 8GB memory ok or do you recommend 16? >>> 2. Is an SSD drive like on the Macbook Pro a big advantage for compilation >>> over an iMac or Mini? >> My concern would be that the new mac book, only give 15" screen which I think is rather too small for serious devlopment, and its a glossy reflective screen. So Im thinking about upgrading my existing 2009 Macbook Pro 17" which is still working reliably enough as a second machine, albeit a bit slower than I would like Paul From jose.cornado at gmail.com Mon Jul 15 11:58:02 2013 From: jose.cornado at gmail.com (=?ISO-8859-1?Q?Jos=E9_Cornado?=) Date: Mon, 15 Jul 2013 12:58:02 -0600 Subject: OT - Selecting a Mac for development In-Reply-To: References: <6881514F-471F-4597-8026-D59D1A7FEB8A@kodewerk.com> Message-ID: ++Screen size. I have an old mbp (17 inches, 4 gb mem) and I resist to let it go. On Mon, Jul 15, 2013 at 12:14 PM, Fabrizio Giudici < Fabrizio.Giudici at tidalwave.it> wrote: > On Mon, 15 Jul 2013 20:08:45 +0200, Kirk Pepperdine > wrote: > > +1, buy the biggest laptop you can afford. Favour memory over processor >> speed. >> > > > +1 and for me the SSD has been a life changer. > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/**blog - > fabrizio.giudici at tidalwave.it > -- Jos? Cornado -- home: http://www.efekctive.com blog: http://blogging.efekctive.com ---------------------- Everything has been said before, but since nobody listens we have to keep going back and beginning all over again. Andre Gide From Fabrizio.Giudici at tidalwave.it Mon Jul 15 12:01:22 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Mon, 15 Jul 2013 21:01:22 +0200 Subject: OT - Selecting a Mac for development In-Reply-To: <51E44543.2040703@fastmail.fm> References: <51E44543.2040703@fastmail.fm> Message-ID: On Mon, 15 Jul 2013 20:53:55 +0200, Paul Taylor wrote: > My concern would be that the new mac book, only give 15" screen which I > think is rather too small for serious devlopment, and its a glossy > reflective screen. So Im thinking about upgrading my existing 2009 > Macbook Pro 17" which is still working reliably enough as a second > machine, albeit a bit slower than I would like I've been doing serious development for seven years now on macbooks, all 15" ;-) All my previous laptops weren't larger than 15", anyway. I hate the glossy screen, but more for photography than other activities. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From ekrichardson at gmail.com Mon Jul 15 12:48:59 2013 From: ekrichardson at gmail.com (Eric Richardson) Date: Mon, 15 Jul 2013 12:48:59 -0700 Subject: OT - Selecting a Mac for development In-Reply-To: References: <51E44543.2040703@fastmail.fm> Message-ID: I will probably get an external monitor eventually but I agree 15 inch is ok - but backed by one or more large monitors is obviously better. I don't think a 17 in is an option anymore. Eric On Mon, Jul 15, 2013 at 12:01 PM, Fabrizio Giudici < Fabrizio.Giudici at tidalwave.it> wrote: > On Mon, 15 Jul 2013 20:53:55 +0200, Paul Taylor > wrote: > > > My concern would be that the new mac book, only give 15" screen which I >> think is rather too small for serious devlopment, and its a glossy >> reflective screen. So Im thinking about upgrading my existing 2009 Macbook >> Pro 17" which is still working reliably enough as a second machine, albeit >> a bit slower than I would like >> > > I've been doing serious development for seven years now on macbooks, all > 15" ;-) All my previous laptops weren't larger than 15", anyway. I hate the > glossy screen, but more for photography than other activities. > > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/**blog - > fabrizio.giudici at tidalwave.it > From gregg at wonderly.org Mon Jul 15 14:45:40 2013 From: gregg at wonderly.org (Gregg Wonderly) Date: Mon, 15 Jul 2013 16:45:40 -0500 Subject: OT - Selecting a Mac for development In-Reply-To: <51E44543.2040703@fastmail.fm> References: <51E44543.2040703@fastmail.fm> Message-ID: <8C366D60-D7F3-46E5-8FF6-116222C43EB1@wonderly.org> I'm hoping that there will be a 15 inch antiglare 15" retina screen released in the fall but, I am not holding my breath. I would sure like to have 17 inches of retina! Gregg Sent from my iPhone On Jul 15, 2013, at 1:53 PM, Paul Taylor wrote: > On 15/07/2013 19:12, Eric Richardson wrote: >> Hi Kustaa and Kirk, >> >> I was thinking 16GB and Laptop/SSD but they are pretty pricey so I wanted >> to ask. >> >> Eric >> >> >> On Mon, Jul 15, 2013 at 10:53 AM, Kustaa Nyholm >> wrote: >> >>> On 15/07/2013 20:05, "Eric Richardson" wrote: >>> >>>> Hi All, >>>> >>>> I have been following this list for a long time so figure this is a great >>>> place to ask. >>>> >>>> I'm trying to get a new computer for Java/Scala development to replace an >>>> old iMac. I would like to get a laptop but they are a bit pricey so I'd >>>> consider and iMac or Mini. Two questions to help narrow my selection. >>>> >>>> 1. Is 8GB memory ok or do you recommend 16? >>>> 2. Is an SSD drive like on the Macbook Pro a big advantage for compilation >>>> over an iMac or Mini? >>> > My concern would be that the new mac book, only give 15" screen which I think is rather too small for serious devlopment, and its a glossy reflective screen. So Im thinking about upgrading my existing 2009 Macbook Pro 17" which is still working reliably enough as a second machine, albeit a bit slower than I would like > > Paul From gregg at wonderly.org Mon Jul 15 14:46:36 2013 From: gregg at wonderly.org (Gregg Wonderly) Date: Mon, 15 Jul 2013 16:46:36 -0500 Subject: OT - Selecting a Mac for development In-Reply-To: References: <6881514F-471F-4597-8026-D59D1A7FEB8A@kodewerk.com> Message-ID: <465B19B3-5AAE-4189-81C0-F5BF7D4E880E@wonderly.org> I upgraded mine to 8 GB and it does better! Gregg Sent from my iPhone On Jul 15, 2013, at 1:58 PM, Jos? Cornado wrote: > ++Screen size. I have an old mbp (17 inches, 4 gb mem) and I resist to let > it go. > > > On Mon, Jul 15, 2013 at 12:14 PM, Fabrizio Giudici < > Fabrizio.Giudici at tidalwave.it> wrote: > >> On Mon, 15 Jul 2013 20:08:45 +0200, Kirk Pepperdine >> wrote: >> >> +1, buy the biggest laptop you can afford. Favour memory over processor >>> speed. >>> >> >> >> +1 and for me the SSD has been a life changer. >> >> -- >> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. >> "We make Java work. Everywhere." >> http://tidalwave.it/fabrizio/**blog - >> fabrizio.giudici at tidalwave.it >> > > > > -- > Jos? Cornado > > -- > > home: http://www.efekctive.com > blog: http://blogging.efekctive.com > ---------------------- > > Everything has been said before, but since nobody listens we have to keep > going back and beginning all over again. > > Andre Gide From mik3hall at gmail.com Mon Jul 15 18:41:56 2013 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 15 Jul 2013 20:41:56 -0500 Subject: OT - Selecting a Mac for development In-Reply-To: <465B19B3-5AAE-4189-81C0-F5BF7D4E880E@wonderly.org> References: <6881514F-471F-4597-8026-D59D1A7FEB8A@kodewerk.com> <465B19B3-5AAE-4189-81C0-F5BF7D4E880E@wonderly.org> Message-ID: <862848E0-F8D1-4206-B28B-ADD8CA84908A@gmail.com> On Jul 15, 2013, at 4:46 PM, Gregg Wonderly wrote: > I upgraded mine to 8 GB and it does better! I think writing to a smaller screen on a machine with less memory is better. Then think how much better it'll run on the others. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From hs at tagtraum.com Tue Jul 16 00:52:28 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Tue, 16 Jul 2013 09:52:28 +0200 Subject: OT - Selecting a Mac for development In-Reply-To: <862848E0-F8D1-4206-B28B-ADD8CA84908A@gmail.com> References: <6881514F-471F-4597-8026-D59D1A7FEB8A@kodewerk.com> <465B19B3-5AAE-4189-81C0-F5BF7D4E880E@wonderly.org> <862848E0-F8D1-4206-B28B-ADD8CA84908A@gmail.com> Message-ID: <5A76D51F-CECC-46DF-ABD2-5E1B0DDB13EB@tagtraum.com> On Jul 16, 2013, at 3:41 AM, Michael Hall wrote: > On Jul 15, 2013, at 4:46 PM, Gregg Wonderly wrote: > >> I upgraded mine to 8 GB and it does better! > > I think writing to a smaller screen on a machine with less memory is better. Then think how much better it'll run on the others. There is some truth to that: Every time I upgrade my machine, I'm afraid I don't realize some code really sucks on a regular user's machine. -hendrik From Kustaa.Nyholm at planmeca.com Tue Jul 16 02:36:34 2013 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 16 Jul 2013 12:36:34 +0300 Subject: OT - Selecting a Mac for development In-Reply-To: <5A76D51F-CECC-46DF-ABD2-5E1B0DDB13EB@tagtraum.com> Message-ID: On 16/07/2013 10:52, "Hendrik Schreiber" wrote: >>On Jul 15, 2013, at 4:46 PM, Gregg Wonderly wrote: >>>I upgraded mine to 8 GB and it does better! >>I think writing to a smaller screen on a machine with less memory is >>better. Then think how much better it'll run on the others. > >There is some truth to that: > >Every time I upgrade my machine, I'm afraid I don't realize some code >really sucks on a regular user's machine. I second that too, but still, developing on a sub par machine is soooo not satisfying... as to screen size, I think that depends on a lot of things, habits, kind of development, eye sight -- me with bifocals I actually prefer small but crisp Retina display over larger ones. br Kusti This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. From Doug.Zwick at blackboard.com Tue Jul 16 12:40:39 2013 From: Doug.Zwick at blackboard.com (Doug Zwick) Date: Tue, 16 Jul 2013 15:40:39 -0400 Subject: OT - Selecting a Mac for development In-Reply-To: References: Message-ID: <132C34B3-947F-4A4B-A667-C7B511711EC5@blackboard.com> Michael Hall wrote: > On Jul 15, 2013, at 4:46 PM, Gregg Wonderly wrote: > >> I upgraded mine to 8 GB and it does better! > > I think writing to a smaller screen on a machine with less memory is better. Then think how much better it'll run on the others. IIRC, some of the current MacBook Pro models have their memory spec fixed at manufacture -- it is not possible to add memory later. I presume this is because the memory is not socketed, but mounted directly on the main logic board. Check the specs before ordering, otherwise you may limit the usable life of it (at least as a development machine). This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. From ekrichardson at gmail.com Tue Jul 16 15:36:29 2013 From: ekrichardson at gmail.com (Eric Richardson) Date: Tue, 16 Jul 2013 15:36:29 -0700 Subject: OT - Selecting a Mac for development In-Reply-To: <132C34B3-947F-4A4B-A667-C7B511711EC5@blackboard.com> References: <132C34B3-947F-4A4B-A667-C7B511711EC5@blackboard.com> Message-ID: Hi Doug, Yes the MacBook Pro Retina and the Air models are fixed at purchase according to person at the Apple store I talked to. Not sure on the others. I went ahead and got 15 inch retina because that one comes with 16GB memory and 512GB SSD - I think this is plenty of power to get a useful life out of the machine. It is definitely pricey. I'm replacing an old iMac which I certainly got my money out of so I'm hopeful this will be similar experience. BTW, thank-you for all the people working to make the Mac a great Java platform. It is very popular for developers for all the JVM targeted platforms at a minimum. Eric On Tue, Jul 16, 2013 at 12:40 PM, Doug Zwick wrote: > Michael Hall wrote: > > > On Jul 15, 2013, at 4:46 PM, Gregg Wonderly wrote: > > > >> I upgraded mine to 8 GB and it does better! > > > > I think writing to a smaller screen on a machine with less memory is > better. Then think how much better it'll run on the others. > > IIRC, some of the current MacBook Pro models have their memory spec fixed > at manufacture -- it is not possible to add memory later. I presume this is > because the memory is not socketed, but mounted directly on the main logic > board. Check the specs before ordering, otherwise you may limit the usable > life of it (at least as a development machine). > > This email and any attachments may contain confidential and proprietary > information of Blackboard that is for the sole use of the intended > recipient. If you are not the intended recipient, disclosure, copying, > re-distribution or other use of any of this information is strictly > prohibited. Please immediately notify the sender and delete this > transmission if you received this email in error. > From denisl at openscg.com Wed Jul 17 01:30:49 2013 From: denisl at openscg.com (Lussier, Denis) Date: Wed, 17 Jul 2013 04:30:49 -0400 Subject: OT - Selecting a Mac for development In-Reply-To: References: <132C34B3-947F-4A4B-A667-C7B511711EC5@blackboard.com> Message-ID: My everyday laptop is a 15 inch Retina Macbook w/ 512 MB SSD and 16 GB of RAM. It's pricey, but I love it. 8 GB would be fine, but, I like/need the extra memory to run virtual machines in the background. I have an older (now discontinued) 17" Macbook pro that I upgraded myself to 16 GB of RAM. I presently use it as a desktop that is pretty easily portable. Frankly, it's too big to use on an airplane. I usually advise folks who presently want a MacBook for development, and price is an important consideration, to go with an 8 GB, non-retina display MacBook Pro w/ at least a 512 GB spinning rust drive. This is a reasonably priced great machine that will last you for years. The design is a little more old school than the newer retina models (which means it's cheaper and easier to upgrade and thicker and includes an internal DVD drive). --Luss On Tue, Jul 16, 2013 at 6:36 PM, Eric Richardson wrote: > Hi Doug, > > Yes the MacBook Pro Retina and the Air models are fixed at purchase > according to person at the Apple store I talked to. Not sure on the others. > > I went ahead and got 15 inch retina because that one comes with 16GB memory > and 512GB SSD - I think this is plenty of power to get a useful life out of > the machine. It is definitely pricey. > > I'm replacing an old iMac which I certainly got my money out of so I'm > hopeful this will be similar experience. > > BTW, thank-you for all the people working to make the Mac a great Java > platform. It is very popular for developers for all the JVM targeted > platforms at a minimum. > > Eric > > > On Tue, Jul 16, 2013 at 12:40 PM, Doug Zwick >wrote: > > > Michael Hall wrote: > > > > > On Jul 15, 2013, at 4:46 PM, Gregg Wonderly wrote: > > > > > >> I upgraded mine to 8 GB and it does better! > > > > > > I think writing to a smaller screen on a machine with less memory is > > better. Then think how much better it'll run on the others. > > > > IIRC, some of the current MacBook Pro models have their memory spec fixed > > at manufacture -- it is not possible to add memory later. I presume this > is > > because the memory is not socketed, but mounted directly on the main > logic > > board. Check the specs before ordering, otherwise you may limit the > usable > > life of it (at least as a development machine). > > > > This email and any attachments may contain confidential and proprietary > > information of Blackboard that is for the sole use of the intended > > recipient. If you are not the intended recipient, disclosure, copying, > > re-distribution or other use of any of this information is strictly > > prohibited. Please immediately notify the sender and delete this > > transmission if you received this email in error. > > > From Fabrizio.Giudici at tidalwave.it Wed Jul 17 01:44:39 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Wed, 17 Jul 2013 10:44:39 +0200 Subject: OT - Selecting a Mac for development In-Reply-To: References: <132C34B3-947F-4A4B-A667-C7B511711EC5@blackboard.com> Message-ID: On Wed, 17 Jul 2013 10:30:49 +0200, Lussier, Denis wrote: > I usually advise folks who presently want a MacBook for development, and > price is an important consideration, to go with an 8 GB, non-retina > display > MacBook Pro w/ at least a 512 GB spinning rust drive. This is a > reasonably > priced great machine that will last you for years. The design is a > little My additional advice is that people need memory and disk (possibly SSD), but not necessarily the latest model and/or a retina display, even though it's cool. I've replaced by 4.5 years old macbook with a new model, but it is a late 2011 one. I have 16GB of RAM, quad core, I've manually upgraded the disk for a 512GB SSD, I've saved some bucks but above all it's still a laptop where I can replace things on my own, including the battery. Retina apart, I think I'm missing almost nothing (with the exception of USB 3). I hope that in the next three years (expected minimum lifetime of my current laptop) Apple will be able to provide ultra-slim and light stuff, but where you can change components - a computer for an engineer it's something that the engineer must be able to tweak into, IMO. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From denisl at openscg.com Wed Jul 17 01:51:53 2013 From: denisl at openscg.com (Lussier, Denis) Date: Wed, 17 Jul 2013 04:51:53 -0400 Subject: OT - Selecting a Mac for development In-Reply-To: References: <132C34B3-947F-4A4B-A667-C7B511711EC5@blackboard.com> Message-ID: 100% agree. It's really nice to upgrade the older Macbooks yourself, when needed. I've done it myself several times. My strong advise is to be very careful when screwing back in those tiny little screws (don't overtighten and make sure they are in straight). It's very easy to cross-thread and then strip them. You can end up with screws that don't ever seat properly and then they create sharp protusions on the bottom of your laptop and ... On Wed, Jul 17, 2013 at 4:44 AM, Fabrizio Giudici < Fabrizio.Giudici at tidalwave.it> wrote: > > My additional advice is that people need memory and disk (possibly SSD), > but not necessarily the latest model and/or a retina display, even though > it's cool. I've replaced by 4.5 years old macbook with a new model, but it > is a late 2011 one. I have 16GB of RAM, quad core, I've manually upgraded > the disk for a 512GB SSD, I've saved some bucks but above all it's still a > laptop where I can replace things on my own, including the battery. Retina > apart, I think I'm missing almost nothing (with the exception of USB 3). I > hope that in the next three years (expected minimum lifetime of my current > laptop) Apple will be able to provide ultra-slim and light stuff, but where > you can change components - a computer for an engineer it's something that > the engineer must be able to tweak into, IMO. > > From emile.schwarz at yahoo.com Wed Jul 17 04:37:15 2013 From: emile.schwarz at yahoo.com (Emile Schwarz) Date: Wed, 17 Jul 2013 12:37:15 +0100 (BST) Subject: OT - Selecting a Mac for development In-Reply-To: References: Message-ID: <1374061035.5866.YahooMailNeo@web172201.mail.ir2.yahoo.com> Hi all, the subject title is: ?OT - Selecting a Mac for development? That means you have to have some other machine(s) to make your testings else you will fall into the ?developer's syndrome? as I say since the mid-80s. That is: it works fine here: it will work fine everywhere. AS some persons rated: it can looks bad (or slow) on some other machine. As a developer I must have a fast machine (and a large screen), but I have to keep in mind my target customers: they may have a slower machine, their screens can be smaller that my wonderful 23" external monitor (on my glorious MacBook Pro 15"). They also may not understand what is a MBA13, so I will have to write it clear: this is a MacBook Air 13". That said, for some unknown reason, I only realized at the time of the last MacBook Air release the 13" screen resolution: same as my current (from 2011-11) MacBook Pro 15": 1,440 x 900 !!! Less weight (not that this matter much? it matters), les table foot print, less $, less processor speed too? but 2013 machine. I may wait 'till the end of this year before a new purchase. Regards, Emile From Sergey.Bylokhov at oracle.com Wed Jul 17 06:39:34 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 17 Jul 2013 17:39:34 +0400 Subject: [8] Review request for 8010721: [macosx] In JDK7 the menu bar disappears when a Dialog is shown In-Reply-To: <515C0273.8030809@oracle.com> References: <5152F7F0.1020907@oracle.com> <5154607A.90301@oracle.com> <5154666C.3080706@oracle.com> <51598235.7080702@oracle.com> <515AA7F8.10304@oracle.com> <515C0273.8030809@oracle.com> Message-ID: <51E69E96.5080907@oracle.com> Hello. >> Should this call be wrapped in an if (self.javaMenuBar != NULL) check? >> The same question about line 543 and the opposite->javaMenuBar >> correspondingly. > "activate" is a static function and there's a null check inside. We > can pass the parameter without additional null check. Actually it is not true, CMenuBar.activate resets the current menubar if a passed javaMenuBar is null. So we incorrectly reset menubar, if our first parent has no menu bar, but the second have. Caused a regression 8017189 > >> >> Also, are we sure that "opposite" is always non-null? What happens if >> you switch to another app, and then click on the dialog making it a key >> window again? > Agreed. I added a null check for "opposite" variable. > >> >> -- >> best regards, >> Anthony >> >> On 4/1/2013 16:48, Vladislav Karnaukhov wrote: >>> Hello Sergey, all, >>> >>> please review a new version: >>> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.02/ >>> >>> I agree that previous one was too complex and error-prone. The current >>> version is much lighter and addresses various use-cases with different >>> windows types and modality. >>> >>> Regards, >>> - Vlad >>> >>> On 3/28/2013 07:49 PM, Sergey Bylokhov wrote: >>>> Not sure that now it looks better. >>>> >>>> On 3/28/13 7:23 PM, Vladislav Karnaukhov wrote: >>>>> Hello Leonid, all, >>>>> >>>>> thanks for the review and could you please review a new version: >>>>> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.01/ >>>>> >>>>> This version is implemented completely via JNF; I removed all changes >>>>> from Java part. >>>>> >>>>> Regards, >>>>> - Vlad >>>>> >>>>> On 27.03.13 18:10, Leonid Romanov wrote: >>>>>> Hi, >>>>>> For 1, perhaps you could use AWTWindow's javaPlatformWindow to >>>>>> get to >>>>>> corresponding LWWindowPeer, which has peerType field. >>>>>> >>>>>> On Mar 27, 2013, at 5:45 PM, Vladislav >>>>>> Karnaukhov wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> please review a fix for 8010721. >>>>>>> >>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8010721 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.00/ >>>>>>> >>>>>>> This implementation handles a scenario when a modal dialog is >>>>>>> shown: >>>>>>> in this case we dim main window' menu bar items (if any). >>>>>>> >>>>>>> However, there are 2 issues that I'd like to discuss: >>>>>>> 1. Apple JDK always hides the menu bar when a new *form* doesn't >>>>>>> have any. My realization keeps the main form' menu bar if a new >>>>>>> form >>>>>>> is shown. I wasn't able to determine a way to distinguish a Frame >>>>>>> from a Dialog: both of them are AWTWindow. >>>>>>> >>>>>>> 2. Could you please provide ideas for tests (if we need them here)? >>>>>>> When a modal dialog is being shown, can we access the menu bar to >>>>>>> check if items became dimmed? >>>>>>> >>>>>>> Regards, >>>>>>> - Vlad >>>>> >>>> >>>> >>> >>> > > -- Best regards, Sergey. From Fabrizio.Giudici at tidalwave.it Wed Jul 17 09:04:45 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Wed, 17 Jul 2013 18:04:45 +0200 Subject: OT - Selecting a Mac for development In-Reply-To: References: <132C34B3-947F-4A4B-A667-C7B511711EC5@blackboard.com> Message-ID: On Wed, 17 Jul 2013 17:58:54 +0200, Chris Harshman wrote: > On Wednesday, July 17, 2013, Fabrizio Giudici wrote: > >> I hope that in the next three years (expected minimum lifetime of my >> current laptop) Apple will be able to provide ultra-slim and light >> stuff, >> but where you can change components > > > Based on their design direction of late (MBA, Retina MBPs, the new Mac > Pro), I wouldn't hold your breath. I'm not necessarily optimistic, but that is a first generation of compact devices and technology might not be ready, or too expensive, to provide also serviceability. Of course, it's also a politic decision. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From kirk at kodewerk.com Wed Jul 17 22:28:20 2013 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 18 Jul 2013 07:28:20 +0200 Subject: OT - Selecting a Mac for development In-Reply-To: References: <132C34B3-947F-4A4B-A667-C7B511711EC5@blackboard.com> Message-ID: <364CF372-E74E-494B-B574-263AB1218202@kodewerk.com> >> > > I'm not necessarily optimistic, but that is a first generation of compact devices and technology might not be ready, or too expensive, to provide also serviceability. Of course, it's also a politic decision. I think design is now being overly influenced by mobile devices... which is unfortunate in some cases. Mountain Lion does things that are great for the phone but I simply don't want that behaviour on my laptop especially if I'm using it for development work. It suggests that OSX isn't really the platform that I should be using for development work. My feeling is that this question is really very simple. Hardware is a commodity product at this point in our history. Pick a price that fits your budget and survey the market for the laptop that gives you the best spec's for that budget. Apple doesn't do too badly when you take this approach. -- Kirk From Fabrizio.Giudici at tidalwave.it Wed Jul 17 23:37:12 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Thu, 18 Jul 2013 08:37:12 +0200 Subject: OT - Selecting a Mac for development In-Reply-To: <364CF372-E74E-494B-B574-263AB1218202@kodewerk.com> References: <132C34B3-947F-4A4B-A667-C7B511711EC5@blackboard.com> <364CF372-E74E-494B-B574-263AB1218202@kodewerk.com> Message-ID: On Thu, 18 Jul 2013 07:28:20 +0200, Kirk Pepperdine wrote: > especially if I'm using it for development work. It suggests that OSX > isn't really the platform that I should be using for development work. It's partially true, but it's also that when OSX fails you can run a virtual machine - the opposite solution can't be unfortunately done - or install a multi-boot (even though it's getting harder and harder to do with OS X). Unfortunately Windows 8 has taken the same route and I'm constantly screaming when I have to use it (for some projects targeted at it) and I see I'm not alone. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From dcs at gol.com Fri Jul 19 08:03:04 2013 From: dcs at gol.com (Darren Saunders) Date: Sat, 20 Jul 2013 00:03:04 +0900 Subject: OT - Selecting a Mac for development In-Reply-To: References: Message-ID: My java programming setup? FWIW. http://thinklightly.com/wordpress/tech/dell-u2913wm-setup-3/ I really like the extra wide screen but actually I still have to move windows around too much? :-) Darren From Sergey.Bylokhov at oracle.com Fri Jul 19 11:15:37 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 19 Jul 2013 22:15:37 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac Message-ID: <51E98249.80504@oracle.com> Hello, Please review the fix for jdk 8 and 7u40. The fix for JDK-8010906 don't take into account situation then first parent has no menu bar, but the second has. So it introduce the next scenario: #1. Open the window with File menu. #2. Open modal dialog1 =>File menu is disabled #3. Open modal dialog2 =>File menu disappears #4. Close dialog two #5. Close dialog one. File menu reappears, but File still disabled The steps #3. occurred, because CMenuBar.activate resets the current menubar if a passed javaMenuBar is null. The steps #5. occurred, because at step #3 we do not remove our nsmenu from the deleted NSMenuItem, when the appropriate NSMenuItem removed from mainMenu. So at step #5 we got a situation, when our nsmenu was added to the two different nsmenuitems: old(disabled) and new(enabled). Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 Webrev can be found at: http://cr.openjdk.java.net/~serb/8017189/webrev.00 -- Best regards, Sergey. From harshman+javadev at gmail.com Fri Jul 19 16:56:37 2013 From: harshman+javadev at gmail.com (Chris Harshman) Date: Fri, 19 Jul 2013 16:56:37 -0700 Subject: OT - Selecting a Mac for development In-Reply-To: References: Message-ID: On Fri, Jul 19, 2013 at 8:03 AM, Darren Saunders wrote: > My java programming setup? FWIW. > > http://thinklightly.com/wordpress/tech/dell-u2913wm-setup-3/ > > I really like the extra wide screen but actually I still have to move > windows around too much? :-) Nice except for the keyboard. My setup is: Home, Dell WFP2007 (old but still works great) hanging off of an Ergotron Neo-Flex Combo Lift Stand that also has a shelf to hold my Core i5 / 8GB / 128GB 13" MacBook Air at the same level, next to the monitor. Office, Dell U2311H instead of the WFP2007. Both locations have Unicomp Spacesaver Mkeyboards. FTW. =) After the Apple Extended Keyboard II, the Unicomps ( *nee *IBM Model M) are the Best Keyboards Ever Made?. (Both also have Lenovo wired miceessentially identical to the Lenovo Bluetooth laser mousethat travels with my MacBook...) From anthony.petrov at oracle.com Sun Jul 21 23:56:44 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 22 Jul 2013 10:56:44 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51E98249.80504@oracle.com> References: <51E98249.80504@oracle.com> Message-ID: <51ECD7AC.2060408@oracle.com> Hi Sergey, The fix looks good to me. -- best regards, Anthony On 07/19/2013 10:15 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk 8 and 7u40. > The fix for JDK-8010906 don't take into account situation then first > parent has no menu bar, but the second has. > So it introduce the next scenario: > #1. Open the window with File menu. > #2. Open modal dialog1 =>File menu is disabled > #3. Open modal dialog2 =>File menu disappears > #4. Close dialog two > #5. Close dialog one. File menu reappears, but File still disabled > > The steps #3. occurred, because CMenuBar.activate resets the current > menubar if a passed javaMenuBar is null. > The steps #5. occurred, because at step #3 we do not remove our nsmenu > from the deleted NSMenuItem, when the appropriate NSMenuItem removed > from mainMenu. So at step #5 we got a situation, when our nsmenu was > added to the two different nsmenuitems: old(disabled) and new(enabled). > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8017189/webrev.00 > From leonid.romanov at oracle.com Mon Jul 22 05:57:16 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 22 Jul 2013 16:57:16 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51E98249.80504@oracle.com> References: <51E98249.80504@oracle.com> Message-ID: Hi. Here is a test case that, with your patch applied, works differently than JDK 6: 1. Show JFrame with a menu 2. Create a modal dialog with the frame as a parent 3. Dispose the frame 4. Make dialog visible With JDK 6, the dialog's menu will be disabled. With JDK 8, it will be enabled. So, formally, we've got a regression. I'm not sure whether it is worth fixing, because it looks like a corner case, but still. On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk 8 and 7u40. > The fix for JDK-8010906 don't take into account situation then first parent has no menu bar, but the second has. > So it introduce the next scenario: > #1. Open the window with File menu. > #2. Open modal dialog1 =>File menu is disabled > #3. Open modal dialog2 =>File menu disappears > #4. Close dialog two > #5. Close dialog one. File menu reappears, but File still disabled > > The steps #3. occurred, because CMenuBar.activate resets the current menubar if a passed javaMenuBar is null. > The steps #5. occurred, because at step #3 we do not remove our nsmenu from the deleted NSMenuItem, when the appropriate NSMenuItem removed from mainMenu. So at step #5 we got a situation, when our nsmenu was added to the two different nsmenuitems: old(disabled) and new(enabled). > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8017189/webrev.00 > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Mon Jul 22 07:02:57 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 22 Jul 2013 18:02:57 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: References: <51E98249.80504@oracle.com> Message-ID: <51ED3B91.2030809@oracle.com> Hi, Leonid. Is seems to me that this is another issue, and both jdk6jdk8 behave incorrectly. When the window with mainmenubar is disposed, menu should be removed, because it doesn't make sense in this case. So dispose of the window should be fixed. What do you think? On 22.07.2013 16:57, Leonid Romanov wrote: > Hi. > Here is a test case that, with your patch applied, works differently than JDK 6: > 1. Show JFrame with a menu > 2. Create a modal dialog with the frame as a parent > 3. Dispose the frame > 4. Make dialog visible > > With JDK 6, the dialog's menu will be disabled. With JDK 8, it will be enabled. So, formally, we've got a regression. I'm not sure whether it is worth fixing, because it looks like a corner case, but still. > > On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov wrote: > >> Hello, >> Please review the fix for jdk 8 and 7u40. >> The fix for JDK-8010906 don't take into account situation then first parent has no menu bar, but the second has. >> So it introduce the next scenario: >> #1. Open the window with File menu. >> #2. Open modal dialog1 =>File menu is disabled >> #3. Open modal dialog2 =>File menu disappears >> #4. Close dialog two >> #5. Close dialog one. File menu reappears, but File still disabled >> >> The steps #3. occurred, because CMenuBar.activate resets the current menubar if a passed javaMenuBar is null. >> The steps #5. occurred, because at step #3 we do not remove our nsmenu from the deleted NSMenuItem, when the appropriate NSMenuItem removed from mainMenu. So at step #5 we got a situation, when our nsmenu was added to the two different nsmenuitems: old(disabled) and new(enabled). >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >> Webrev can be found at: http://cr.openjdk.java.net/~serb/8017189/webrev.00 >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From gregg at wonderly.org Mon Jul 22 08:08:47 2013 From: gregg at wonderly.org (Gregg Wonderly) Date: Mon, 22 Jul 2013 10:08:47 -0500 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51ED3B91.2030809@oracle.com> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> Message-ID: <51ED4AFF.3060204@wonderly.org> As a user of MACOS-X and Windows and Linux and as a developer, I'd really like to suggest that the issue with MACOS-X, is that the menu is an application thing, not a window thing. The problem with Java on OS-X, is that Java Menus are "window things", not application things. By promoting menus out of windows and onto the menu bar, the single window application has a convenient transformation into an OS-X application. However, as soon as you introduce a modal window, such as a dialog, which would disable the main window access, and thus make the menu bar there, unusable, the OS-X menu bar extraction, from the main window, becomes problematic. It seems to me, that what should actually happen, is that any "window" in java, that is "current", should have it's menu bar pushed in to the OS-X menubar. If I have two or more, non-modal windows, and I click between them, I'd expect to have access to two or more distinct menu bars just like I would on other OSes using Java. A modal window would just cause it's own menu bar to be used, and that would greatly simplify and unify the behavior to work as the application has been designed. Gregg Wonderly On 7/22/2013 9:02 AM, Sergey Bylokhov wrote: > Hi, Leonid. > Is seems to me that this is another issue, and both jdk6jdk8 behave incorrectly. > When the window with mainmenubar is disposed, menu should be removed, because > it doesn't make sense in this case. So dispose of the window should be fixed. > What do you think? > > On 22.07.2013 16:57, Leonid Romanov wrote: >> Hi. >> Here is a test case that, with your patch applied, works differently than JDK 6: >> 1. Show JFrame with a menu >> 2. Create a modal dialog with the frame as a parent >> 3. Dispose the frame >> 4. Make dialog visible >> >> With JDK 6, the dialog's menu will be disabled. With JDK 8, it will be >> enabled. So, formally, we've got a regression. I'm not sure whether it is >> worth fixing, because it looks like a corner case, but still. >> >> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov >> wrote: >> >>> Hello, >>> Please review the fix for jdk 8 and 7u40. >>> The fix for JDK-8010906 don't take into account situation then first parent >>> has no menu bar, but the second has. >>> So it introduce the next scenario: >>> #1. Open the window with File menu. >>> #2. Open modal dialog1 =>File menu is disabled >>> #3. Open modal dialog2 =>File menu disappears >>> #4. Close dialog two >>> #5. Close dialog one. File menu reappears, but File still disabled >>> >>> The steps #3. occurred, because CMenuBar.activate resets the current menubar >>> if a passed javaMenuBar is null. >>> The steps #5. occurred, because at step #3 we do not remove our nsmenu from >>> the deleted NSMenuItem, when the appropriate NSMenuItem removed from >>> mainMenu. So at step #5 we got a situation, when our nsmenu was added to the >>> two different nsmenuitems: old(disabled) and new(enabled). >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>> >>> -- >>> Best regards, Sergey. >>> > > From Sergey.Bylokhov at oracle.com Mon Jul 22 09:01:55 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 22 Jul 2013 20:01:55 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51ED4AFF.3060204@wonderly.org> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> <51ED4AFF.3060204@wonderly.org> Message-ID: <51ED5773.7070503@oracle.com> Hi, Gregg. On 22.07.2013 19:08, Gregg Wonderly wrote: > As a user of MACOS-X and Windows and Linux and as a developer, I'd > really like to suggest that the issue with MACOS-X, is that the menu > is an application thing, not a window thing. The problem with Java on > OS-X, is that Java Menus are "window things", not application things. > By promoting menus out of windows and onto the menu bar, the single > window application has a convenient transformation into an OS-X > application. However, as soon as you introduce a modal window, such > as a dialog, which would disable the main window access, and thus make > the menu bar there, unusable, the OS-X menu bar extraction, from the > main window, becomes problematic. According to documentation of modal dialogs: "Modal dialogs block all input to some top-level windows" including the menu. So this is correct behavior. After the fix for 8010906 the modal dialogs disable parent menubar instead of removing. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010906 This is a small trade-off without violating the specification > It seems to me, that what should actually happen, is that any "window" > in java, that is "current", should have it's menu bar pushed in to the > OS-X menubar. If I have two or more, non-modal windows, and I click > between them, I'd expect to have access to two or more distinct menu > bars just like I would on other OSes using Java. A modal window would > just cause it's own menu bar to be used, and that would greatly > simplify and unify the behavior to work as the application has been > designed. > > Gregg Wonderly > > On 7/22/2013 9:02 AM, Sergey Bylokhov wrote: >> Hi, Leonid. >> Is seems to me that this is another issue, and both jdk6jdk8 behave >> incorrectly. >> When the window with mainmenubar is disposed, menu should be removed, >> because it doesn't make sense in this case. So dispose of the window >> should be fixed. >> What do you think? >> >> On 22.07.2013 16:57, Leonid Romanov wrote: >>> Hi. >>> Here is a test case that, with your patch applied, works differently >>> than JDK 6: >>> 1. Show JFrame with a menu >>> 2. Create a modal dialog with the frame as a parent >>> 3. Dispose the frame >>> 4. Make dialog visible >>> >>> With JDK 6, the dialog's menu will be disabled. With JDK 8, it will >>> be enabled. So, formally, we've got a regression. I'm not sure >>> whether it is worth fixing, because it looks like a corner case, but >>> still. >>> >>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov >>> wrote: >>> >>>> Hello, >>>> Please review the fix for jdk 8 and 7u40. >>>> The fix for JDK-8010906 don't take into account situation then >>>> first parent has no menu bar, but the second has. >>>> So it introduce the next scenario: >>>> #1. Open the window with File menu. >>>> #2. Open modal dialog1 =>File menu is disabled >>>> #3. Open modal dialog2 =>File menu disappears >>>> #4. Close dialog two >>>> #5. Close dialog one. File menu reappears, but File still disabled >>>> >>>> The steps #3. occurred, because CMenuBar.activate resets the >>>> current menubar if a passed javaMenuBar is null. >>>> The steps #5. occurred, because at step #3 we do not remove our >>>> nsmenu from the deleted NSMenuItem, when the appropriate NSMenuItem >>>> removed from mainMenu. So at step #5 we got a situation, when our >>>> nsmenu was added to the two different nsmenuitems: old(disabled) >>>> and new(enabled). >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>>> >>>> -- >>>> Best regards, Sergey. >>>> >> >> > -- Best regards, Sergey. From leonid.romanov at oracle.com Mon Jul 22 12:32:37 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 22 Jul 2013 23:32:37 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51ED3B91.2030809@oracle.com> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> Message-ID: <07D170B0-5131-4768-92B6-E6D3696CA8B5@oracle.com> On Jul 22, 2013, at 6:02 PM, Sergey Bylokhov wrote: > Hi, Leonid. > Is seems to me that this is another issue, and both jdk6jdk8 behave incorrectly. > When the window with mainmenubar is disposed, menu should be removed, because it doesn't make sense in this case. So dispose of the window should be fixed. > What do you think? Well, I'd like us to stay consistent with JDK 6. However, if we decide to fix this issue in some other way, we need to be consistent with other possible cases, like setting frame's menu to null before showing a dialog, making frame invisible, and so on. But as you've said, this issue is not related to 8017189, so let's go back to the fix for 8017189. I've got another question about it. When native window loses focus, we call -(void) deactivate method of CMenuBar class. At first, I thought that it basically removes all the menu items from the menu bar, but then I realized that it is not the case, because your fix depends on the fact that the window gaining focus inherits the menu bar from the window that just lost it. Now, consider step 4 of your scenario. Here, the dialog2 is the window that is loosing focus, and dialog1 is the window that is gaining it. As a result of dialog2 loosing focus, the current menu bar gets marked as not active (sActiveMenuBar in CMenuBar is set to false). When dialog1 gains focus, we do nothing with the current menu, because the opposite window (dialog2) doesn't formally have a menu (opposite->javaMenuBar is NULL). This means that dialog1 now has a menu that is formally inactive. Since I don't really understand the purpose of -(void) deactivate method, I can't say whether the situation I've described above is problematic or not. What do you think? > > On 22.07.2013 16:57, Leonid Romanov wrote: >> Hi. >> Here is a test case that, with your patch applied, works differently than JDK 6: >> 1. Show JFrame with a menu >> 2. Create a modal dialog with the frame as a parent >> 3. Dispose the frame >> 4. Make dialog visible >> >> With JDK 6, the dialog's menu will be disabled. With JDK 8, it will be enabled. So, formally, we've got a regression. I'm not sure whether it is worth fixing, because it looks like a corner case, but still. >> >> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov wrote: >> >>> Hello, >>> Please review the fix for jdk 8 and 7u40. >>> The fix for JDK-8010906 don't take into account situation then first parent has no menu bar, but the second has. >>> So it introduce the next scenario: >>> #1. Open the window with File menu. >>> #2. Open modal dialog1 =>File menu is disabled >>> #3. Open modal dialog2 =>File menu disappears >>> #4. Close dialog two >>> #5. Close dialog one. File menu reappears, but File still disabled >>> >>> The steps #3. occurred, because CMenuBar.activate resets the current menubar if a passed javaMenuBar is null. >>> The steps #5. occurred, because at step #3 we do not remove our nsmenu from the deleted NSMenuItem, when the appropriate NSMenuItem removed from mainMenu. So at step #5 we got a situation, when our nsmenu was added to the two different nsmenuitems: old(disabled) and new(enabled). >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>> >>> -- >>> Best regards, Sergey. >>> > > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Tue Jul 23 03:06:53 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 23 Jul 2013 14:06:53 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <07D170B0-5131-4768-92B6-E6D3696CA8B5@oracle.com> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> <07D170B0-5131-4768-92B6-E6D3696CA8B5@oracle.com> Message-ID: <51EE55BD.8080306@oracle.com> On 22.07.2013 23:32, Leonid Romanov wrote: > Well, I'd like us to stay consistent with JDK 6. However, if we decide to fix this issue in some other way, we need to be consistent with other possible cases, like setting frame's menu to null before showing a dialog, making frame invisible, and so on. > But as you've said, this issue is not related to 8017189, so let's go back to the fix for 8017189. I've got another question about it. When native window loses focus, we call -(void) deactivate method of CMenuBar class. At first, I thought that it basically removes all the menu items from the menu bar, but then I realized that it is not the case, because your fix depends on the fact that the window gaining focus inherits the menu bar from the window that just lost it. Now, consider step 4 of your scenario. Here, the dialog2 is the window that is loosing focus, and dialog1 is the window that is gaining it. As a result of dialog2 loosing focus, the current menu bar gets marked as not active (sActiveMenuBar in CMenuBar is set to false). When dialog1 gains focus, we do nothing with the current menu, because the opposite window (dialog2) doesn't formally have a menu (opposite->javaMenuBar is NULL). This means that dialog1 now has a menu that is formally inactive. > Since I don't really understand the purpose of -(void) deactivate method, I can't say whether the situation I've described above is problematic or not. What do you think? Actually this is not a problem of my fix, this is a problem of 8010906, which was implemented on top of "opposite" property instead of "dialog parent". Probably you know why? I'll try to change it, but not sure is it dangerous to change it now or not. > >> On 22.07.2013 16:57, Leonid Romanov wrote: >>> Hi. >>> Here is a test case that, with your patch applied, works differently than JDK 6: >>> 1. Show JFrame with a menu >>> 2. Create a modal dialog with the frame as a parent >>> 3. Dispose the frame >>> 4. Make dialog visible >>> >>> With JDK 6, the dialog's menu will be disabled. With JDK 8, it will be enabled. So, formally, we've got a regression. I'm not sure whether it is worth fixing, because it looks like a corner case, but still. >>> >>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov wrote: >>> >>>> Hello, >>>> Please review the fix for jdk 8 and 7u40. >>>> The fix for JDK-8010906 don't take into account situation then first parent has no menu bar, but the second has. >>>> So it introduce the next scenario: >>>> #1. Open the window with File menu. >>>> #2. Open modal dialog1 =>File menu is disabled >>>> #3. Open modal dialog2 =>File menu disappears >>>> #4. Close dialog two >>>> #5. Close dialog one. File menu reappears, but File still disabled >>>> >>>> The steps #3. occurred, because CMenuBar.activate resets the current menubar if a passed javaMenuBar is null. >>>> The steps #5. occurred, because at step #3 we do not remove our nsmenu from the deleted NSMenuItem, when the appropriate NSMenuItem removed from mainMenu. So at step #5 we got a situation, when our nsmenu was added to the two different nsmenuitems: old(disabled) and new(enabled). >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>>> >>>> -- >>>> Best regards, Sergey. >>>> >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From leonid.romanov at oracle.com Tue Jul 23 03:37:08 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 23 Jul 2013 14:37:08 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51EE55BD.8080306@oracle.com> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> <07D170B0-5131-4768-92B6-E6D3696CA8B5@oracle.com> <51EE55BD.8080306@oracle.com> Message-ID: <51EE5CD4.9010904@oracle.com> On 7/23/2013 14:06, Sergey Bylokhov wrote: > On 22.07.2013 23:32, Leonid Romanov wrote: >> Well, I'd like us to stay consistent with JDK 6. However, if we >> decide to fix this issue in some other way, we need to be consistent >> with other possible cases, like setting frame's menu to null before >> showing a dialog, making frame invisible, and so on. >> But as you've said, this issue is not related to 8017189, so let's go >> back to the fix for 8017189. I've got another question about it. When >> native window loses focus, we call -(void) deactivate method of >> CMenuBar class. At first, I thought that it basically removes all the >> menu items from the menu bar, but then I realized that it is not the >> case, because your fix depends on the fact that the window gaining >> focus inherits the menu bar from the window that just lost it. Now, >> consider step 4 of your scenario. Here, the dialog2 is the window >> that is loosing focus, and dialog1 is the window that is gaining it. >> As a result of dialog2 loosing focus, the current menu bar gets >> marked as not active (sActiveMenuBar in CMenuBar is set to false). >> When dialog1 gains focus, we do nothing with the current menu, >> because the opposite window (dialog2) doesn't formally have a menu >> (opposite->javaMenuBar is NULL). This means that dialog1 now has a >> menu that is formally inactive. >> Since I don't really understand the purpose of -(void) deactivate >> method, I can't say whether the situation I've described above is >> problematic or not. What do you think? > Actually this is not a problem of my fix, this is a problem of > 8010906, which was implemented on top of "opposite" property instead > of "dialog parent". Probably you know why? > I'll try to change it, but not sure is it dangerous to change it now > or not. I agree, after looking more closely at the original code, it seems that we will get the same deactivation issue in case of showing non modal dialog. I've no idea why 8010906 was implemented on top of the opposite, perhaps it looked like the simplest approach back then. Do you think that traversing windows hierarchy tree from the dialog being shown to an ancestor frame with a menu would have been a better idea? >> >>> On 22.07.2013 16:57, Leonid Romanov wrote: >>>> Hi. >>>> Here is a test case that, with your patch applied, works >>>> differently than JDK 6: >>>> 1. Show JFrame with a menu >>>> 2. Create a modal dialog with the frame as a parent >>>> 3. Dispose the frame >>>> 4. Make dialog visible >>>> >>>> With JDK 6, the dialog's menu will be disabled. With JDK 8, it will >>>> be enabled. So, formally, we've got a regression. I'm not sure >>>> whether it is worth fixing, because it looks like a corner case, >>>> but still. >>>> >>>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov >>>> wrote: >>>> >>>>> Hello, >>>>> Please review the fix for jdk 8 and 7u40. >>>>> The fix for JDK-8010906 don't take into account situation then >>>>> first parent has no menu bar, but the second has. >>>>> So it introduce the next scenario: >>>>> #1. Open the window with File menu. >>>>> #2. Open modal dialog1 =>File menu is disabled >>>>> #3. Open modal dialog2 =>File menu disappears >>>>> #4. Close dialog two >>>>> #5. Close dialog one. File menu reappears, but File still disabled >>>>> >>>>> The steps #3. occurred, because CMenuBar.activate resets the >>>>> current menubar if a passed javaMenuBar is null. >>>>> The steps #5. occurred, because at step #3 we do not remove our >>>>> nsmenu from the deleted NSMenuItem, when the appropriate >>>>> NSMenuItem removed from mainMenu. So at step #5 we got a >>>>> situation, when our nsmenu was added to the two different >>>>> nsmenuitems: old(disabled) and new(enabled). >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>> >>> -- >>> Best regards, Sergey. >>> > > From artem.ananiev at oracle.com Tue Jul 23 03:40:24 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 23 Jul 2013 14:40:24 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51EE5CD4.9010904@oracle.com> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> <07D170B0-5131-4768-92B6-E6D3696CA8B5@oracle.com> <51EE55BD.8080306@oracle.com> <51EE5CD4.9010904@oracle.com> Message-ID: <51EE5D98.1020801@oracle.com> On 7/23/2013 2:37 PM, Leonid Romanov wrote: > On 7/23/2013 14:06, Sergey Bylokhov wrote: >> On 22.07.2013 23:32, Leonid Romanov wrote: >>> Well, I'd like us to stay consistent with JDK 6. However, if we >>> decide to fix this issue in some other way, we need to be consistent >>> with other possible cases, like setting frame's menu to null before >>> showing a dialog, making frame invisible, and so on. >>> But as you've said, this issue is not related to 8017189, so let's go >>> back to the fix for 8017189. I've got another question about it. When >>> native window loses focus, we call -(void) deactivate method of >>> CMenuBar class. At first, I thought that it basically removes all the >>> menu items from the menu bar, but then I realized that it is not the >>> case, because your fix depends on the fact that the window gaining >>> focus inherits the menu bar from the window that just lost it. Now, >>> consider step 4 of your scenario. Here, the dialog2 is the window >>> that is loosing focus, and dialog1 is the window that is gaining it. >>> As a result of dialog2 loosing focus, the current menu bar gets >>> marked as not active (sActiveMenuBar in CMenuBar is set to false). >>> When dialog1 gains focus, we do nothing with the current menu, >>> because the opposite window (dialog2) doesn't formally have a menu >>> (opposite->javaMenuBar is NULL). This means that dialog1 now has a >>> menu that is formally inactive. >>> Since I don't really understand the purpose of -(void) deactivate >>> method, I can't say whether the situation I've described above is >>> problematic or not. What do you think? >> Actually this is not a problem of my fix, this is a problem of >> 8010906, which was implemented on top of "opposite" property instead >> of "dialog parent". Probably you know why? >> I'll try to change it, but not sure is it dangerous to change it now >> or not. > I agree, after looking more closely at the original code, it seems that > we will get the same deactivation issue in case of showing non modal > dialog. I've no idea why 8010906 was implemented on top of the opposite, > perhaps it looked like the simplest approach back then. Do you think > that traversing windows hierarchy tree from the dialog being shown to an > ancestor frame with a menu would have been a better idea? Yes, it sounds more reasonable to me. Thanks, Artem >>>> On 22.07.2013 16:57, Leonid Romanov wrote: >>>>> Hi. >>>>> Here is a test case that, with your patch applied, works >>>>> differently than JDK 6: >>>>> 1. Show JFrame with a menu >>>>> 2. Create a modal dialog with the frame as a parent >>>>> 3. Dispose the frame >>>>> 4. Make dialog visible >>>>> >>>>> With JDK 6, the dialog's menu will be disabled. With JDK 8, it will >>>>> be enabled. So, formally, we've got a regression. I'm not sure >>>>> whether it is worth fixing, because it looks like a corner case, >>>>> but still. >>>>> >>>>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> Please review the fix for jdk 8 and 7u40. >>>>>> The fix for JDK-8010906 don't take into account situation then >>>>>> first parent has no menu bar, but the second has. >>>>>> So it introduce the next scenario: >>>>>> #1. Open the window with File menu. >>>>>> #2. Open modal dialog1 =>File menu is disabled >>>>>> #3. Open modal dialog2 =>File menu disappears >>>>>> #4. Close dialog two >>>>>> #5. Close dialog one. File menu reappears, but File still disabled >>>>>> >>>>>> The steps #3. occurred, because CMenuBar.activate resets the >>>>>> current menubar if a passed javaMenuBar is null. >>>>>> The steps #5. occurred, because at step #3 we do not remove our >>>>>> nsmenu from the deleted NSMenuItem, when the appropriate >>>>>> NSMenuItem removed from mainMenu. So at step #5 we got a >>>>>> situation, when our nsmenu was added to the two different >>>>>> nsmenuitems: old(disabled) and new(enabled). >>>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>>>>> Webrev can be found at: >>>>>> http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >> >> > From Sergey.Bylokhov at oracle.com Tue Jul 23 10:37:30 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 23 Jul 2013 21:37:30 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51EE5CD4.9010904@oracle.com> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> <07D170B0-5131-4768-92B6-E6D3696CA8B5@oracle.com> <51EE55BD.8080306@oracle.com> <51EE5CD4.9010904@oracle.com> Message-ID: <51EEBF5A.3010902@oracle.com> Hello. Please review updated version of the fix: http://cr.openjdk.java.net/~serb/8017189/webrev.01 After the fix, for dialogs we activates a menubar from the first visible and enabled owner. I use awtwindow owner instead of nswindow.parentWindow, because when the windowDidBecomeKey is called for the first time our nswindow still have no parentWindow(it is added later). Any testing are welcome. Thanks. On 23.07.2013 14:37, Leonid Romanov wrote: > On 7/23/2013 14:06, Sergey Bylokhov wrote: >> On 22.07.2013 23:32, Leonid Romanov wrote: >>> Well, I'd like us to stay consistent with JDK 6. However, if we >>> decide to fix this issue in some other way, we need to be consistent >>> with other possible cases, like setting frame's menu to null before >>> showing a dialog, making frame invisible, and so on. >>> But as you've said, this issue is not related to 8017189, so let's >>> go back to the fix for 8017189. I've got another question about it. >>> When native window loses focus, we call -(void) deactivate method of >>> CMenuBar class. At first, I thought that it basically removes all >>> the menu items from the menu bar, but then I realized that it is not >>> the case, because your fix depends on the fact that the window >>> gaining focus inherits the menu bar from the window that just lost >>> it. Now, consider step 4 of your scenario. Here, the dialog2 is the >>> window that is loosing focus, and dialog1 is the window that is >>> gaining it. As a result of dialog2 loosing focus, the current menu >>> bar gets marked as not active (sActiveMenuBar in CMenuBar is set to >>> false). When dialog1 gains focus, we do nothing with the current >>> menu, because the opposite window (dialog2) doesn't formally have a >>> menu (opposite->javaMenuBar is NULL). This means that dialog1 now >>> has a menu that is formally inactive. >>> Since I don't really understand the purpose of -(void) deactivate >>> method, I can't say whether the situation I've described above is >>> problematic or not. What do you think? >> Actually this is not a problem of my fix, this is a problem of >> 8010906, which was implemented on top of "opposite" property instead >> of "dialog parent". Probably you know why? >> I'll try to change it, but not sure is it dangerous to change it now >> or not. > I agree, after looking more closely at the original code, it seems > that we will get the same deactivation issue in case of showing non > modal dialog. I've no idea why 8010906 was implemented on top of the > opposite, perhaps it looked like the simplest approach back then. Do > you think that traversing windows hierarchy tree from the dialog being > shown to an ancestor frame with a menu would have been a better idea? > >>> >>>> On 22.07.2013 16:57, Leonid Romanov wrote: >>>>> Hi. >>>>> Here is a test case that, with your patch applied, works >>>>> differently than JDK 6: >>>>> 1. Show JFrame with a menu >>>>> 2. Create a modal dialog with the frame as a parent >>>>> 3. Dispose the frame >>>>> 4. Make dialog visible >>>>> >>>>> With JDK 6, the dialog's menu will be disabled. With JDK 8, it >>>>> will be enabled. So, formally, we've got a regression. I'm not >>>>> sure whether it is worth fixing, because it looks like a corner >>>>> case, but still. >>>>> >>>>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> Please review the fix for jdk 8 and 7u40. >>>>>> The fix for JDK-8010906 don't take into account situation then >>>>>> first parent has no menu bar, but the second has. >>>>>> So it introduce the next scenario: >>>>>> #1. Open the window with File menu. >>>>>> #2. Open modal dialog1 =>File menu is disabled >>>>>> #3. Open modal dialog2 =>File menu disappears >>>>>> #4. Close dialog two >>>>>> #5. Close dialog one. File menu reappears, but File still disabled >>>>>> >>>>>> The steps #3. occurred, because CMenuBar.activate resets the >>>>>> current menubar if a passed javaMenuBar is null. >>>>>> The steps #5. occurred, because at step #3 we do not remove our >>>>>> nsmenu from the deleted NSMenuItem, when the appropriate >>>>>> NSMenuItem removed from mainMenu. So at step #5 we got a >>>>>> situation, when our nsmenu was added to the two different >>>>>> nsmenuitems: old(disabled) and new(enabled). >>>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>>>>> Webrev can be found at: >>>>>> http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >> >> > -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Jul 23 13:12:19 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 24 Jul 2013 00:12:19 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51EEBF5A.3010902@oracle.com> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> <07D170B0-5131-4768-92B6-E6D3696CA8B5@oracle.com> <51EE55BD.8080306@oracle.com> <51EE5CD4.9010904@oracle.com> <51EEBF5A.3010902@oracle.com> Message-ID: <51EEE3A3.3090503@oracle.com> Hi Sergey, I'll let Leonid test this patch since he has a number of good test cases. As for the code changes, they look good to me overall. The only scenario that concerns me is if we have a hierarchy of a frame and an owned undecorated window (e.g., a toolbar). With your current fix the menu will disappear as soon as the window gets activated because it is not a dialog and its menubar is obviously null: > 546 // Finds appropriate menubar in our hierarchy, > 547 if (self.javaMenuBar != nil || !IS(self.styleBits, IS_DIALOG)) { > 548 // shortpath > 549 [CMenuBar activate:self.javaMenuBar modallyDisabled:NO]; > 550 } IMO, this is undesirable. Can we remove this if/else altogether and instead code this logic as follows: CMenuBar *menu = ; [CMenuBar activate:menu modallyDisabled:!.isEnabled]; ? It seems to me that this should cover all possible use cases. -- best regards, Anthony On 07/23/2013 09:37 PM, Sergey Bylokhov wrote: > Hello. > Please review updated version of the fix: > http://cr.openjdk.java.net/~serb/8017189/webrev.01 > After the fix, for dialogs we activates a menubar from the first visible > and enabled owner. I use awtwindow owner instead of > nswindow.parentWindow, because when the windowDidBecomeKey is called for > the first time our nswindow still have no parentWindow(it is added later). > Any testing are welcome. > Thanks. > > On 23.07.2013 14:37, Leonid Romanov wrote: >> On 7/23/2013 14:06, Sergey Bylokhov wrote: >>> On 22.07.2013 23:32, Leonid Romanov wrote: >>>> Well, I'd like us to stay consistent with JDK 6. However, if we >>>> decide to fix this issue in some other way, we need to be consistent >>>> with other possible cases, like setting frame's menu to null before >>>> showing a dialog, making frame invisible, and so on. >>>> But as you've said, this issue is not related to 8017189, so let's >>>> go back to the fix for 8017189. I've got another question about it. >>>> When native window loses focus, we call -(void) deactivate method of >>>> CMenuBar class. At first, I thought that it basically removes all >>>> the menu items from the menu bar, but then I realized that it is not >>>> the case, because your fix depends on the fact that the window >>>> gaining focus inherits the menu bar from the window that just lost >>>> it. Now, consider step 4 of your scenario. Here, the dialog2 is the >>>> window that is loosing focus, and dialog1 is the window that is >>>> gaining it. As a result of dialog2 loosing focus, the current menu >>>> bar gets marked as not active (sActiveMenuBar in CMenuBar is set to >>>> false). When dialog1 gains focus, we do nothing with the current >>>> menu, because the opposite window (dialog2) doesn't formally have a >>>> menu (opposite->javaMenuBar is NULL). This means that dialog1 now >>>> has a menu that is formally inactive. >>>> Since I don't really understand the purpose of -(void) deactivate >>>> method, I can't say whether the situation I've described above is >>>> problematic or not. What do you think? >>> Actually this is not a problem of my fix, this is a problem of >>> 8010906, which was implemented on top of "opposite" property instead >>> of "dialog parent". Probably you know why? >>> I'll try to change it, but not sure is it dangerous to change it now >>> or not. >> I agree, after looking more closely at the original code, it seems >> that we will get the same deactivation issue in case of showing non >> modal dialog. I've no idea why 8010906 was implemented on top of the >> opposite, perhaps it looked like the simplest approach back then. Do >> you think that traversing windows hierarchy tree from the dialog being >> shown to an ancestor frame with a menu would have been a better idea? >> >>>> >>>>> On 22.07.2013 16:57, Leonid Romanov wrote: >>>>>> Hi. >>>>>> Here is a test case that, with your patch applied, works >>>>>> differently than JDK 6: >>>>>> 1. Show JFrame with a menu >>>>>> 2. Create a modal dialog with the frame as a parent >>>>>> 3. Dispose the frame >>>>>> 4. Make dialog visible >>>>>> >>>>>> With JDK 6, the dialog's menu will be disabled. With JDK 8, it >>>>>> will be enabled. So, formally, we've got a regression. I'm not >>>>>> sure whether it is worth fixing, because it looks like a corner >>>>>> case, but still. >>>>>> >>>>>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov >>>>>> wrote: >>>>>> >>>>>>> Hello, >>>>>>> Please review the fix for jdk 8 and 7u40. >>>>>>> The fix for JDK-8010906 don't take into account situation then >>>>>>> first parent has no menu bar, but the second has. >>>>>>> So it introduce the next scenario: >>>>>>> #1. Open the window with File menu. >>>>>>> #2. Open modal dialog1 =>File menu is disabled >>>>>>> #3. Open modal dialog2 =>File menu disappears >>>>>>> #4. Close dialog two >>>>>>> #5. Close dialog one. File menu reappears, but File still disabled >>>>>>> >>>>>>> The steps #3. occurred, because CMenuBar.activate resets the >>>>>>> current menubar if a passed javaMenuBar is null. >>>>>>> The steps #5. occurred, because at step #3 we do not remove our >>>>>>> nsmenu from the deleted NSMenuItem, when the appropriate >>>>>>> NSMenuItem removed from mainMenu. So at step #5 we got a >>>>>>> situation, when our nsmenu was added to the two different >>>>>>> nsmenuitems: old(disabled) and new(enabled). >>>>>>> >>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>>>>>> Webrev can be found at: >>>>>>> http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>> >>> >> > > From tim.bell at oracle.com Tue Jul 23 15:15:09 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 23 Jul 2013 15:15:09 -0700 Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang compiler" Message-ID: <51EF006D.3060805@oracle.com> Hello everyone- This is a small set of changes to switch from gcc to clang when building on MacOS, and also enable building on MacOS 8.x Here is the bug report: http://bugs.sun.com/view_bug.do?bug_id=8019470 Here are the webrevs: Hotspot only: http://cr.openjdk.java.net/~tbell/8019470/hotspot/webrev.00/ All of the changes: http://cr.openjdk.java.net/~tbell/8019470/webrev.00/ Thanks in advance. Tim From leonid.romanov at oracle.com Tue Jul 23 15:44:57 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 24 Jul 2013 02:44:57 +0400 Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang compiler" In-Reply-To: <51EF006D.3060805@oracle.com> References: <51EF006D.3060805@oracle.com> Message-ID: Just to satisfy my curiosity: what are advantages of using clang instead of gcc? On Jul 24, 2013, at 2:15 AM, Tim Bell wrote: > Hello everyone- > > This is a small set of changes to switch from gcc to clang when building on MacOS, and also enable building on MacOS 8.x > > Here is the bug report: > > http://bugs.sun.com/view_bug.do?bug_id=8019470 > > Here are the webrevs: > > Hotspot only: > > http://cr.openjdk.java.net/~tbell/8019470/hotspot/webrev.00/ > > All of the changes: > > http://cr.openjdk.java.net/~tbell/8019470/webrev.00/ > > Thanks in advance. > > Tim > From tim.bell at oracle.com Tue Jul 23 16:38:11 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 23 Jul 2013 16:38:11 -0700 Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang compiler" In-Reply-To: References: <51EF006D.3060805@oracle.com> Message-ID: <51EF13E3.6060804@oracle.com> Hello Leonid: > Just to satisfy my curiosity: what are advantages of using clang instead of gcc? I am a mere messenger here, but I am told that clang/clang++: - is command line compatible with gcc - is faster - produces better diagnostic messages - clang on MacOS is under active development while gcc is not [citation needed] To others out there - feel free to correct these points, or add more of your own. Tim > On Jul 24, 2013, at 2:15 AM, Tim Bell wrote: > >> Hello everyone- >> >> This is a small set of changes to switch from gcc to clang when building on MacOS, and also enable building on MacOS 8.x >> >> Here is the bug report: >> >> http://bugs.sun.com/view_bug.do?bug_id=8019470 >> >> Here are the webrevs: >> >> Hotspot only: >> >> http://cr.openjdk.java.net/~tbell/8019470/hotspot/webrev.00/ >> >> All of the changes: >> >> http://cr.openjdk.java.net/~tbell/8019470/webrev.00/ >> >> Thanks in advance. >> >> Tim >> From david.katleman at oracle.com Tue Jul 23 17:08:40 2013 From: david.katleman at oracle.com (David Katleman) Date: Tue, 23 Jul 2013 17:08:40 -0700 Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang compiler" In-Reply-To: <51EF006D.3060805@oracle.com> References: <51EF006D.3060805@oracle.com> Message-ID: <51EF1B08.3040709@oracle.com> In toolchain.m4 267 elif test "x$OPENJDK_TARGET_OS" = "xmacosx"; then 268 COMPILER_CHECK_LIST="clang gcc cc" Aren't clang & cc the same? (/usr/bin/cc -> clang) Or are there instances of macosx that do not have the symlink? That's the only question I could find. Pretty simple change. Dave On 7/23/2013 3:15 PM, Tim Bell wrote: > Hello everyone- > > This is a small set of changes to switch from gcc to clang when > building on MacOS, and also enable building on MacOS 8.x > > Here is the bug report: > > http://bugs.sun.com/view_bug.do?bug_id=8019470 > > Here are the webrevs: > > Hotspot only: > > http://cr.openjdk.java.net/~tbell/8019470/hotspot/webrev.00/ > > All of the changes: > > http://cr.openjdk.java.net/~tbell/8019470/webrev.00/ From Sergey.Bylokhov at oracle.com Wed Jul 24 02:54:52 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 24 Jul 2013 13:54:52 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51EEE3A3.3090503@oracle.com> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> <07D170B0-5131-4768-92B6-E6D3696CA8B5@oracle.com> <51EE55BD.8080306@oracle.com> <51EE5CD4.9010904@oracle.com> <51EEBF5A.3010902@oracle.com> <51EEE3A3.3090503@oracle.com> Message-ID: <51EFA46C.4070505@oracle.com> On 24.07.2013 0:12, Anthony Petrov wrote: > Hi Sergey, > > I'll let Leonid test this patch since he has a number of good test > cases. As for the code changes, they look good to me overall. The only > scenario that concerns me is if we have a hierarchy of a frame and an > owned undecorated window (e.g., a toolbar). With your current fix the > menu will disappear as soon as the window gets activated because it is > not a dialog and its menubar is obviously null: > >> 546 // Finds appropriate menubar in our hierarchy, >> 547 if (self.javaMenuBar != nil || !IS(self.styleBits, >> IS_DIALOG)) { >> 548 // shortpath >> 549 [CMenuBar activate:self.javaMenuBar modallyDisabled:NO]; >> 550 } > > IMO, this is undesirable. Can we remove this if/else altogether and > instead code this logic as follows: I just check on SwingSet2, when I drag toolbar out of the main window, the menubar is not disappear. > > CMenuBar *menu = ; > [CMenuBar activate:menu modallyDisabled:!.isEnabled]; > > ? It seems to me that this should cover all possible use cases. > > -- > best regards, > Anthony > > On 07/23/2013 09:37 PM, Sergey Bylokhov wrote: >> Hello. >> Please review updated version of the fix: >> http://cr.openjdk.java.net/~serb/8017189/webrev.01 >> After the fix, for dialogs we activates a menubar from the first visible >> and enabled owner. I use awtwindow owner instead of >> nswindow.parentWindow, because when the windowDidBecomeKey is called for >> the first time our nswindow still have no parentWindow(it is added >> later). >> Any testing are welcome. >> Thanks. >> >> On 23.07.2013 14:37, Leonid Romanov wrote: >>> On 7/23/2013 14:06, Sergey Bylokhov wrote: >>>> On 22.07.2013 23:32, Leonid Romanov wrote: >>>>> Well, I'd like us to stay consistent with JDK 6. However, if we >>>>> decide to fix this issue in some other way, we need to be consistent >>>>> with other possible cases, like setting frame's menu to null before >>>>> showing a dialog, making frame invisible, and so on. >>>>> But as you've said, this issue is not related to 8017189, so let's >>>>> go back to the fix for 8017189. I've got another question about it. >>>>> When native window loses focus, we call -(void) deactivate method of >>>>> CMenuBar class. At first, I thought that it basically removes all >>>>> the menu items from the menu bar, but then I realized that it is not >>>>> the case, because your fix depends on the fact that the window >>>>> gaining focus inherits the menu bar from the window that just lost >>>>> it. Now, consider step 4 of your scenario. Here, the dialog2 is the >>>>> window that is loosing focus, and dialog1 is the window that is >>>>> gaining it. As a result of dialog2 loosing focus, the current menu >>>>> bar gets marked as not active (sActiveMenuBar in CMenuBar is set to >>>>> false). When dialog1 gains focus, we do nothing with the current >>>>> menu, because the opposite window (dialog2) doesn't formally have a >>>>> menu (opposite->javaMenuBar is NULL). This means that dialog1 now >>>>> has a menu that is formally inactive. >>>>> Since I don't really understand the purpose of -(void) deactivate >>>>> method, I can't say whether the situation I've described above is >>>>> problematic or not. What do you think? >>>> Actually this is not a problem of my fix, this is a problem of >>>> 8010906, which was implemented on top of "opposite" property instead >>>> of "dialog parent". Probably you know why? >>>> I'll try to change it, but not sure is it dangerous to change it now >>>> or not. >>> I agree, after looking more closely at the original code, it seems >>> that we will get the same deactivation issue in case of showing non >>> modal dialog. I've no idea why 8010906 was implemented on top of the >>> opposite, perhaps it looked like the simplest approach back then. Do >>> you think that traversing windows hierarchy tree from the dialog being >>> shown to an ancestor frame with a menu would have been a better idea? >>> >>>>> >>>>>> On 22.07.2013 16:57, Leonid Romanov wrote: >>>>>>> Hi. >>>>>>> Here is a test case that, with your patch applied, works >>>>>>> differently than JDK 6: >>>>>>> 1. Show JFrame with a menu >>>>>>> 2. Create a modal dialog with the frame as a parent >>>>>>> 3. Dispose the frame >>>>>>> 4. Make dialog visible >>>>>>> >>>>>>> With JDK 6, the dialog's menu will be disabled. With JDK 8, it >>>>>>> will be enabled. So, formally, we've got a regression. I'm not >>>>>>> sure whether it is worth fixing, because it looks like a corner >>>>>>> case, but still. >>>>>>> >>>>>>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov >>>>>>> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> Please review the fix for jdk 8 and 7u40. >>>>>>>> The fix for JDK-8010906 don't take into account situation then >>>>>>>> first parent has no menu bar, but the second has. >>>>>>>> So it introduce the next scenario: >>>>>>>> #1. Open the window with File menu. >>>>>>>> #2. Open modal dialog1 =>File menu is disabled >>>>>>>> #3. Open modal dialog2 =>File menu disappears >>>>>>>> #4. Close dialog two >>>>>>>> #5. Close dialog one. File menu reappears, but File still disabled >>>>>>>> >>>>>>>> The steps #3. occurred, because CMenuBar.activate resets the >>>>>>>> current menubar if a passed javaMenuBar is null. >>>>>>>> The steps #5. occurred, because at step #3 we do not remove our >>>>>>>> nsmenu from the deleted NSMenuItem, when the appropriate >>>>>>>> NSMenuItem removed from mainMenu. So at step #5 we got a >>>>>>>> situation, when our nsmenu was added to the two different >>>>>>>> nsmenuitems: old(disabled) and new(enabled). >>>>>>>> >>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>>>>>>> Webrev can be found at: >>>>>>>> http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>> >>>> >>> >> >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Jul 24 04:17:35 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 24 Jul 2013 15:17:35 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51EEE3A3.3090503@oracle.com> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> <07D170B0-5131-4768-92B6-E6D3696CA8B5@oracle.com> <51EE55BD.8080306@oracle.com> <51EE5CD4.9010904@oracle.com> <51EEBF5A.3010902@oracle.com> <51EEE3A3.3090503@oracle.com> Message-ID: <51EFB7CF.3080400@oracle.com> Hi, Anthony. Please review the updated version http://cr.openjdk.java.net/~serb/8017189/webrev.02/ In the fix a dependency from the dialog was removed. now we use menubar from the toplvl parent window. On 24.07.2013 0:12, Anthony Petrov wrote: > Hi Sergey, > > I'll let Leonid test this patch since he has a number of good test > cases. As for the code changes, they look good to me overall. The only > scenario that concerns me is if we have a hierarchy of a frame and an > owned undecorated window (e.g., a toolbar). With your current fix the > menu will disappear as soon as the window gets activated because it is > not a dialog and its menubar is obviously null: > >> 546 // Finds appropriate menubar in our hierarchy, >> 547 if (self.javaMenuBar != nil || !IS(self.styleBits, >> IS_DIALOG)) { >> 548 // shortpath >> 549 [CMenuBar activate:self.javaMenuBar modallyDisabled:NO]; >> 550 } > > IMO, this is undesirable. Can we remove this if/else altogether and > instead code this logic as follows: > > CMenuBar *menu = ; > [CMenuBar activate:menu modallyDisabled:!.isEnabled]; > > ? It seems to me that this should cover all possible use cases. > > -- > best regards, > Anthony > > On 07/23/2013 09:37 PM, Sergey Bylokhov wrote: >> Hello. >> Please review updated version of the fix: >> http://cr.openjdk.java.net/~serb/8017189/webrev.01 >> After the fix, for dialogs we activates a menubar from the first visible >> and enabled owner. I use awtwindow owner instead of >> nswindow.parentWindow, because when the windowDidBecomeKey is called for >> the first time our nswindow still have no parentWindow(it is added >> later). >> Any testing are welcome. >> Thanks. >> >> On 23.07.2013 14:37, Leonid Romanov wrote: >>> On 7/23/2013 14:06, Sergey Bylokhov wrote: >>>> On 22.07.2013 23:32, Leonid Romanov wrote: >>>>> Well, I'd like us to stay consistent with JDK 6. However, if we >>>>> decide to fix this issue in some other way, we need to be consistent >>>>> with other possible cases, like setting frame's menu to null before >>>>> showing a dialog, making frame invisible, and so on. >>>>> But as you've said, this issue is not related to 8017189, so let's >>>>> go back to the fix for 8017189. I've got another question about it. >>>>> When native window loses focus, we call -(void) deactivate method of >>>>> CMenuBar class. At first, I thought that it basically removes all >>>>> the menu items from the menu bar, but then I realized that it is not >>>>> the case, because your fix depends on the fact that the window >>>>> gaining focus inherits the menu bar from the window that just lost >>>>> it. Now, consider step 4 of your scenario. Here, the dialog2 is the >>>>> window that is loosing focus, and dialog1 is the window that is >>>>> gaining it. As a result of dialog2 loosing focus, the current menu >>>>> bar gets marked as not active (sActiveMenuBar in CMenuBar is set to >>>>> false). When dialog1 gains focus, we do nothing with the current >>>>> menu, because the opposite window (dialog2) doesn't formally have a >>>>> menu (opposite->javaMenuBar is NULL). This means that dialog1 now >>>>> has a menu that is formally inactive. >>>>> Since I don't really understand the purpose of -(void) deactivate >>>>> method, I can't say whether the situation I've described above is >>>>> problematic or not. What do you think? >>>> Actually this is not a problem of my fix, this is a problem of >>>> 8010906, which was implemented on top of "opposite" property instead >>>> of "dialog parent". Probably you know why? >>>> I'll try to change it, but not sure is it dangerous to change it now >>>> or not. >>> I agree, after looking more closely at the original code, it seems >>> that we will get the same deactivation issue in case of showing non >>> modal dialog. I've no idea why 8010906 was implemented on top of the >>> opposite, perhaps it looked like the simplest approach back then. Do >>> you think that traversing windows hierarchy tree from the dialog being >>> shown to an ancestor frame with a menu would have been a better idea? >>> >>>>> >>>>>> On 22.07.2013 16:57, Leonid Romanov wrote: >>>>>>> Hi. >>>>>>> Here is a test case that, with your patch applied, works >>>>>>> differently than JDK 6: >>>>>>> 1. Show JFrame with a menu >>>>>>> 2. Create a modal dialog with the frame as a parent >>>>>>> 3. Dispose the frame >>>>>>> 4. Make dialog visible >>>>>>> >>>>>>> With JDK 6, the dialog's menu will be disabled. With JDK 8, it >>>>>>> will be enabled. So, formally, we've got a regression. I'm not >>>>>>> sure whether it is worth fixing, because it looks like a corner >>>>>>> case, but still. >>>>>>> >>>>>>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov >>>>>>> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> Please review the fix for jdk 8 and 7u40. >>>>>>>> The fix for JDK-8010906 don't take into account situation then >>>>>>>> first parent has no menu bar, but the second has. >>>>>>>> So it introduce the next scenario: >>>>>>>> #1. Open the window with File menu. >>>>>>>> #2. Open modal dialog1 =>File menu is disabled >>>>>>>> #3. Open modal dialog2 =>File menu disappears >>>>>>>> #4. Close dialog two >>>>>>>> #5. Close dialog one. File menu reappears, but File still disabled >>>>>>>> >>>>>>>> The steps #3. occurred, because CMenuBar.activate resets the >>>>>>>> current menubar if a passed javaMenuBar is null. >>>>>>>> The steps #5. occurred, because at step #3 we do not remove our >>>>>>>> nsmenu from the deleted NSMenuItem, when the appropriate >>>>>>>> NSMenuItem removed from mainMenu. So at step #5 we got a >>>>>>>> situation, when our nsmenu was added to the two different >>>>>>>> nsmenuitems: old(disabled) and new(enabled). >>>>>>>> >>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>>>>>>> Webrev can be found at: >>>>>>>> http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>> >>>> >>> >> >> -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Jul 24 04:36:03 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 24 Jul 2013 15:36:03 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51EFB7CF.3080400@oracle.com> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> <07D170B0-5131-4768-92B6-E6D3696CA8B5@oracle.com> <51EE55BD.8080306@oracle.com> <51EE5CD4.9010904@oracle.com> <51EEBF5A.3010902@oracle.com> <51EEE3A3.3090503@oracle.com> <51EFB7CF.3080400@oracle.com> Message-ID: <51EFBC23.4070206@oracle.com> Looks fine. -- best regards, Anthony On 07/24/13 15:17, Sergey Bylokhov wrote: > Hi, Anthony. > Please review the updated version > http://cr.openjdk.java.net/~serb/8017189/webrev.02/ > In the fix a dependency from the dialog was removed. now we use menubar > from the toplvl parent window. > > On 24.07.2013 0:12, Anthony Petrov wrote: >> Hi Sergey, >> >> I'll let Leonid test this patch since he has a number of good test >> cases. As for the code changes, they look good to me overall. The only >> scenario that concerns me is if we have a hierarchy of a frame and an >> owned undecorated window (e.g., a toolbar). With your current fix the >> menu will disappear as soon as the window gets activated because it is >> not a dialog and its menubar is obviously null: >> >>> 546 // Finds appropriate menubar in our hierarchy, >>> 547 if (self.javaMenuBar != nil || !IS(self.styleBits, IS_DIALOG)) { >>> 548 // shortpath >>> 549 [CMenuBar activate:self.javaMenuBar modallyDisabled:NO]; >>> 550 } >> >> IMO, this is undesirable. Can we remove this if/else altogether and >> instead code this logic as follows: >> >> CMenuBar *menu = ; >> [CMenuBar activate:menu modallyDisabled:!.isEnabled]; >> >> ? It seems to me that this should cover all possible use cases. >> >> -- >> best regards, >> Anthony >> >> On 07/23/2013 09:37 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review updated version of the fix: >>> http://cr.openjdk.java.net/~serb/8017189/webrev.01 >>> After the fix, for dialogs we activates a menubar from the first visible >>> and enabled owner. I use awtwindow owner instead of >>> nswindow.parentWindow, because when the windowDidBecomeKey is called for >>> the first time our nswindow still have no parentWindow(it is added >>> later). >>> Any testing are welcome. >>> Thanks. >>> >>> On 23.07.2013 14:37, Leonid Romanov wrote: >>>> On 7/23/2013 14:06, Sergey Bylokhov wrote: >>>>> On 22.07.2013 23:32, Leonid Romanov wrote: >>>>>> Well, I'd like us to stay consistent with JDK 6. However, if we >>>>>> decide to fix this issue in some other way, we need to be consistent >>>>>> with other possible cases, like setting frame's menu to null before >>>>>> showing a dialog, making frame invisible, and so on. >>>>>> But as you've said, this issue is not related to 8017189, so let's >>>>>> go back to the fix for 8017189. I've got another question about it. >>>>>> When native window loses focus, we call -(void) deactivate method of >>>>>> CMenuBar class. At first, I thought that it basically removes all >>>>>> the menu items from the menu bar, but then I realized that it is not >>>>>> the case, because your fix depends on the fact that the window >>>>>> gaining focus inherits the menu bar from the window that just lost >>>>>> it. Now, consider step 4 of your scenario. Here, the dialog2 is the >>>>>> window that is loosing focus, and dialog1 is the window that is >>>>>> gaining it. As a result of dialog2 loosing focus, the current menu >>>>>> bar gets marked as not active (sActiveMenuBar in CMenuBar is set to >>>>>> false). When dialog1 gains focus, we do nothing with the current >>>>>> menu, because the opposite window (dialog2) doesn't formally have a >>>>>> menu (opposite->javaMenuBar is NULL). This means that dialog1 now >>>>>> has a menu that is formally inactive. >>>>>> Since I don't really understand the purpose of -(void) deactivate >>>>>> method, I can't say whether the situation I've described above is >>>>>> problematic or not. What do you think? >>>>> Actually this is not a problem of my fix, this is a problem of >>>>> 8010906, which was implemented on top of "opposite" property instead >>>>> of "dialog parent". Probably you know why? >>>>> I'll try to change it, but not sure is it dangerous to change it now >>>>> or not. >>>> I agree, after looking more closely at the original code, it seems >>>> that we will get the same deactivation issue in case of showing non >>>> modal dialog. I've no idea why 8010906 was implemented on top of the >>>> opposite, perhaps it looked like the simplest approach back then. Do >>>> you think that traversing windows hierarchy tree from the dialog being >>>> shown to an ancestor frame with a menu would have been a better idea? >>>> >>>>>> >>>>>>> On 22.07.2013 16:57, Leonid Romanov wrote: >>>>>>>> Hi. >>>>>>>> Here is a test case that, with your patch applied, works >>>>>>>> differently than JDK 6: >>>>>>>> 1. Show JFrame with a menu >>>>>>>> 2. Create a modal dialog with the frame as a parent >>>>>>>> 3. Dispose the frame >>>>>>>> 4. Make dialog visible >>>>>>>> >>>>>>>> With JDK 6, the dialog's menu will be disabled. With JDK 8, it >>>>>>>> will be enabled. So, formally, we've got a regression. I'm not >>>>>>>> sure whether it is worth fixing, because it looks like a corner >>>>>>>> case, but still. >>>>>>>> >>>>>>>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> Please review the fix for jdk 8 and 7u40. >>>>>>>>> The fix for JDK-8010906 don't take into account situation then >>>>>>>>> first parent has no menu bar, but the second has. >>>>>>>>> So it introduce the next scenario: >>>>>>>>> #1. Open the window with File menu. >>>>>>>>> #2. Open modal dialog1 =>File menu is disabled >>>>>>>>> #3. Open modal dialog2 =>File menu disappears >>>>>>>>> #4. Close dialog two >>>>>>>>> #5. Close dialog one. File menu reappears, but File still disabled >>>>>>>>> >>>>>>>>> The steps #3. occurred, because CMenuBar.activate resets the >>>>>>>>> current menubar if a passed javaMenuBar is null. >>>>>>>>> The steps #5. occurred, because at step #3 we do not remove our >>>>>>>>> nsmenu from the deleted NSMenuItem, when the appropriate >>>>>>>>> NSMenuItem removed from mainMenu. So at step #5 we got a >>>>>>>>> situation, when our nsmenu was added to the two different >>>>>>>>> nsmenuitems: old(disabled) and new(enabled). >>>>>>>>> >>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>>>>>>>> Webrev can be found at: >>>>>>>>> http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best regards, Sergey. >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>> >>>>> >>>> >>> >>> > > From david.holmes at oracle.com Wed Jul 24 04:43:05 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jul 2013 21:43:05 +1000 Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang compiler" In-Reply-To: <51EF006D.3060805@oracle.com> References: <51EF006D.3060805@oracle.com> Message-ID: <51EFBDC9.4070200@oracle.com> Hi Tim, On 24/07/2013 8:15 AM, Tim Bell wrote: > Hello everyone- > > This is a small set of changes to switch from gcc to clang when building So we already added support for clang as the compiler for hotspot - is this just extending things to allow configure to select clang? > on MacOS, and also enable building on MacOS 8.x Have we already updated all the JPRT queues to have 10.8 macs versus 10.7 ones? > Here is the bug report: > > http://bugs.sun.com/view_bug.do?bug_id=8019470 > > Here are the webrevs: > > Hotspot only: > > http://cr.openjdk.java.net/~tbell/8019470/hotspot/webrev.00/ src/os/bsd/vm/os_bsd.cpp Again I'm confused. We already allowed building via clang so why wasn't this change needed before? Thanks, David > All of the changes: > > http://cr.openjdk.java.net/~tbell/8019470/webrev.00/ > Thanks in advance. > > Tim > From leonid.romanov at oracle.com Wed Jul 24 04:46:52 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 24 Jul 2013 15:46:52 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51EFB7CF.3080400@oracle.com> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> <07D170B0-5131-4768-92B6-E6D3696CA8B5@oracle.com> <51EE55BD.8080306@oracle.com> <51EE5CD4.9010904@oracle.com> <51EEBF5A.3010902@oracle.com> <51EEE3A3.3090503@oracle.com> <51EFB7CF.3080400@oracle.com> Message-ID: <2E0BE06B-595A-4F86-8BB5-D7D434117056@oracle.com> Looks good for me as well. The only thing that is not clear to me is the memory management in AWTWindow: since every child references its parent now, wouldn't it prevent the parent from being deallocated after it has been disposed? On Jul 24, 2013, at 3:17 PM, Sergey Bylokhov wrote: > Hi, Anthony. > Please review the updated version > http://cr.openjdk.java.net/~serb/8017189/webrev.02/ > In the fix a dependency from the dialog was removed. now we use menubar from the toplvl parent window. > > On 24.07.2013 0:12, Anthony Petrov wrote: >> Hi Sergey, >> >> I'll let Leonid test this patch since he has a number of good test cases. As for the code changes, they look good to me overall. The only scenario that concerns me is if we have a hierarchy of a frame and an owned undecorated window (e.g., a toolbar). With your current fix the menu will disappear as soon as the window gets activated because it is not a dialog and its menubar is obviously null: >> >>> 546 // Finds appropriate menubar in our hierarchy, >>> 547 if (self.javaMenuBar != nil || !IS(self.styleBits, IS_DIALOG)) { >>> 548 // shortpath >>> 549 [CMenuBar activate:self.javaMenuBar modallyDisabled:NO]; >>> 550 } >> >> IMO, this is undesirable. Can we remove this if/else altogether and instead code this logic as follows: >> >> CMenuBar *menu = ; >> [CMenuBar activate:menu modallyDisabled:!.isEnabled]; >> >> ? It seems to me that this should cover all possible use cases. >> >> -- >> best regards, >> Anthony >> >> On 07/23/2013 09:37 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review updated version of the fix: >>> http://cr.openjdk.java.net/~serb/8017189/webrev.01 >>> After the fix, for dialogs we activates a menubar from the first visible >>> and enabled owner. I use awtwindow owner instead of >>> nswindow.parentWindow, because when the windowDidBecomeKey is called for >>> the first time our nswindow still have no parentWindow(it is added later). >>> Any testing are welcome. >>> Thanks. >>> >>> On 23.07.2013 14:37, Leonid Romanov wrote: >>>> On 7/23/2013 14:06, Sergey Bylokhov wrote: >>>>> On 22.07.2013 23:32, Leonid Romanov wrote: >>>>>> Well, I'd like us to stay consistent with JDK 6. However, if we >>>>>> decide to fix this issue in some other way, we need to be consistent >>>>>> with other possible cases, like setting frame's menu to null before >>>>>> showing a dialog, making frame invisible, and so on. >>>>>> But as you've said, this issue is not related to 8017189, so let's >>>>>> go back to the fix for 8017189. I've got another question about it. >>>>>> When native window loses focus, we call -(void) deactivate method of >>>>>> CMenuBar class. At first, I thought that it basically removes all >>>>>> the menu items from the menu bar, but then I realized that it is not >>>>>> the case, because your fix depends on the fact that the window >>>>>> gaining focus inherits the menu bar from the window that just lost >>>>>> it. Now, consider step 4 of your scenario. Here, the dialog2 is the >>>>>> window that is loosing focus, and dialog1 is the window that is >>>>>> gaining it. As a result of dialog2 loosing focus, the current menu >>>>>> bar gets marked as not active (sActiveMenuBar in CMenuBar is set to >>>>>> false). When dialog1 gains focus, we do nothing with the current >>>>>> menu, because the opposite window (dialog2) doesn't formally have a >>>>>> menu (opposite->javaMenuBar is NULL). This means that dialog1 now >>>>>> has a menu that is formally inactive. >>>>>> Since I don't really understand the purpose of -(void) deactivate >>>>>> method, I can't say whether the situation I've described above is >>>>>> problematic or not. What do you think? >>>>> Actually this is not a problem of my fix, this is a problem of >>>>> 8010906, which was implemented on top of "opposite" property instead >>>>> of "dialog parent". Probably you know why? >>>>> I'll try to change it, but not sure is it dangerous to change it now >>>>> or not. >>>> I agree, after looking more closely at the original code, it seems >>>> that we will get the same deactivation issue in case of showing non >>>> modal dialog. I've no idea why 8010906 was implemented on top of the >>>> opposite, perhaps it looked like the simplest approach back then. Do >>>> you think that traversing windows hierarchy tree from the dialog being >>>> shown to an ancestor frame with a menu would have been a better idea? >>>> >>>>>> >>>>>>> On 22.07.2013 16:57, Leonid Romanov wrote: >>>>>>>> Hi. >>>>>>>> Here is a test case that, with your patch applied, works >>>>>>>> differently than JDK 6: >>>>>>>> 1. Show JFrame with a menu >>>>>>>> 2. Create a modal dialog with the frame as a parent >>>>>>>> 3. Dispose the frame >>>>>>>> 4. Make dialog visible >>>>>>>> >>>>>>>> With JDK 6, the dialog's menu will be disabled. With JDK 8, it >>>>>>>> will be enabled. So, formally, we've got a regression. I'm not >>>>>>>> sure whether it is worth fixing, because it looks like a corner >>>>>>>> case, but still. >>>>>>>> >>>>>>>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> Please review the fix for jdk 8 and 7u40. >>>>>>>>> The fix for JDK-8010906 don't take into account situation then >>>>>>>>> first parent has no menu bar, but the second has. >>>>>>>>> So it introduce the next scenario: >>>>>>>>> #1. Open the window with File menu. >>>>>>>>> #2. Open modal dialog1 =>File menu is disabled >>>>>>>>> #3. Open modal dialog2 =>File menu disappears >>>>>>>>> #4. Close dialog two >>>>>>>>> #5. Close dialog one. File menu reappears, but File still disabled >>>>>>>>> >>>>>>>>> The steps #3. occurred, because CMenuBar.activate resets the >>>>>>>>> current menubar if a passed javaMenuBar is null. >>>>>>>>> The steps #5. occurred, because at step #3 we do not remove our >>>>>>>>> nsmenu from the deleted NSMenuItem, when the appropriate >>>>>>>>> NSMenuItem removed from mainMenu. So at step #5 we got a >>>>>>>>> situation, when our nsmenu was added to the two different >>>>>>>>> nsmenuitems: old(disabled) and new(enabled). >>>>>>>>> >>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>>>>>>>> Webrev can be found at: >>>>>>>>> http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best regards, Sergey. >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>> >>>>> >>>> >>> >>> > > > -- > Best regards, Sergey. > From tim.bell at oracle.com Wed Jul 24 05:15:40 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 24 Jul 2013 05:15:40 -0700 Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang compiler" In-Reply-To: <51EFBDC9.4070200@oracle.com> References: <51EF006D.3060805@oracle.com> <51EFBDC9.4070200@oracle.com> Message-ID: <51EFC56C.6040304@oracle.com> On 07/24/13 04:43 AM, David Holmes wrote: > Hi Tim, > > On 24/07/2013 8:15 AM, Tim Bell wrote: >> Hello everyone- >> >> This is a small set of changes to switch from gcc to clang when building > > So we already added support for clang as the compiler for hotspot - is > this just extending things to allow configure to select clang? The earlier clang/hotspot activity was centered around Linux x86/x86_64. >> on MacOS, and also enable building on MacOS 8.x > > Have we already updated all the JPRT queues to have 10.8 macs versus > 10.7 ones? Yes, all the queues have 10.8 Macs, which have been test-only up until now. >> Here is the bug report: >> >> http://bugs.sun.com/view_bug.do?bug_id=8019470 >> >> Here are the webrevs: >> >> Hotspot only: >> >> http://cr.openjdk.java.net/~tbell/8019470/hotspot/webrev.00/ > > src/os/bsd/vm/os_bsd.cpp > > Again I'm confused. We already allowed building via clang so why > wasn't this change needed before? This file is not used when building on Linux. Tim > > Thanks, > David > >> All of the changes: >> >> http://cr.openjdk.java.net/~tbell/8019470/webrev.00/ > > >> Thanks in advance. >> >> Tim >> From Sergey.Bylokhov at oracle.com Wed Jul 24 05:28:29 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 24 Jul 2013 16:28:29 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <2E0BE06B-595A-4F86-8BB5-D7D434117056@oracle.com> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> <07D170B0-5131-4768-92B6-E6D3696CA8B5@oracle.com> <51EE55BD.8080306@oracle.com> <51EE5CD4.9010904@oracle.com> <51EEBF5A.3010902@oracle.com> <51EEE3A3.3090503@oracle.com> <51EFB7CF.3080400@oracle.com> <2E0BE06B-595A-4F86-8BB5-D7D434117056@oracle.com> Message-ID: <51EFC86D.2020308@oracle.com> Hi, Leonid. Yes. When the child window is created, it create its parent also. And the owner cannot be deallocated until child window is live, but when the owner is disposed, it dispose all its child windows. On 24.07.2013 15:46, Leonid Romanov wrote: > Looks good for me as well. The only thing that is not clear to me is the memory management in AWTWindow: since every child references its parent now, wouldn't it prevent the parent from being deallocated after it has been disposed? > > On Jul 24, 2013, at 3:17 PM, Sergey Bylokhov wrote: > >> Hi, Anthony. >> Please review the updated version >> http://cr.openjdk.java.net/~serb/8017189/webrev.02/ >> In the fix a dependency from the dialog was removed. now we use menubar from the toplvl parent window. >> >> On 24.07.2013 0:12, Anthony Petrov wrote: >>> Hi Sergey, >>> >>> I'll let Leonid test this patch since he has a number of good test cases. As for the code changes, they look good to me overall. The only scenario that concerns me is if we have a hierarchy of a frame and an owned undecorated window (e.g., a toolbar). With your current fix the menu will disappear as soon as the window gets activated because it is not a dialog and its menubar is obviously null: >>> >>>> 546 // Finds appropriate menubar in our hierarchy, >>>> 547 if (self.javaMenuBar != nil || !IS(self.styleBits, IS_DIALOG)) { >>>> 548 // shortpath >>>> 549 [CMenuBar activate:self.javaMenuBar modallyDisabled:NO]; >>>> 550 } >>> IMO, this is undesirable. Can we remove this if/else altogether and instead code this logic as follows: >>> >>> CMenuBar *menu = ; >>> [CMenuBar activate:menu modallyDisabled:!.isEnabled]; >>> >>> ? It seems to me that this should cover all possible use cases. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 07/23/2013 09:37 PM, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review updated version of the fix: >>>> http://cr.openjdk.java.net/~serb/8017189/webrev.01 >>>> After the fix, for dialogs we activates a menubar from the first visible >>>> and enabled owner. I use awtwindow owner instead of >>>> nswindow.parentWindow, because when the windowDidBecomeKey is called for >>>> the first time our nswindow still have no parentWindow(it is added later). >>>> Any testing are welcome. >>>> Thanks. >>>> >>>> On 23.07.2013 14:37, Leonid Romanov wrote: >>>>> On 7/23/2013 14:06, Sergey Bylokhov wrote: >>>>>> On 22.07.2013 23:32, Leonid Romanov wrote: >>>>>>> Well, I'd like us to stay consistent with JDK 6. However, if we >>>>>>> decide to fix this issue in some other way, we need to be consistent >>>>>>> with other possible cases, like setting frame's menu to null before >>>>>>> showing a dialog, making frame invisible, and so on. >>>>>>> But as you've said, this issue is not related to 8017189, so let's >>>>>>> go back to the fix for 8017189. I've got another question about it. >>>>>>> When native window loses focus, we call -(void) deactivate method of >>>>>>> CMenuBar class. At first, I thought that it basically removes all >>>>>>> the menu items from the menu bar, but then I realized that it is not >>>>>>> the case, because your fix depends on the fact that the window >>>>>>> gaining focus inherits the menu bar from the window that just lost >>>>>>> it. Now, consider step 4 of your scenario. Here, the dialog2 is the >>>>>>> window that is loosing focus, and dialog1 is the window that is >>>>>>> gaining it. As a result of dialog2 loosing focus, the current menu >>>>>>> bar gets marked as not active (sActiveMenuBar in CMenuBar is set to >>>>>>> false). When dialog1 gains focus, we do nothing with the current >>>>>>> menu, because the opposite window (dialog2) doesn't formally have a >>>>>>> menu (opposite->javaMenuBar is NULL). This means that dialog1 now >>>>>>> has a menu that is formally inactive. >>>>>>> Since I don't really understand the purpose of -(void) deactivate >>>>>>> method, I can't say whether the situation I've described above is >>>>>>> problematic or not. What do you think? >>>>>> Actually this is not a problem of my fix, this is a problem of >>>>>> 8010906, which was implemented on top of "opposite" property instead >>>>>> of "dialog parent". Probably you know why? >>>>>> I'll try to change it, but not sure is it dangerous to change it now >>>>>> or not. >>>>> I agree, after looking more closely at the original code, it seems >>>>> that we will get the same deactivation issue in case of showing non >>>>> modal dialog. I've no idea why 8010906 was implemented on top of the >>>>> opposite, perhaps it looked like the simplest approach back then. Do >>>>> you think that traversing windows hierarchy tree from the dialog being >>>>> shown to an ancestor frame with a menu would have been a better idea? >>>>> >>>>>>>> On 22.07.2013 16:57, Leonid Romanov wrote: >>>>>>>>> Hi. >>>>>>>>> Here is a test case that, with your patch applied, works >>>>>>>>> differently than JDK 6: >>>>>>>>> 1. Show JFrame with a menu >>>>>>>>> 2. Create a modal dialog with the frame as a parent >>>>>>>>> 3. Dispose the frame >>>>>>>>> 4. Make dialog visible >>>>>>>>> >>>>>>>>> With JDK 6, the dialog's menu will be disabled. With JDK 8, it >>>>>>>>> will be enabled. So, formally, we've got a regression. I'm not >>>>>>>>> sure whether it is worth fixing, because it looks like a corner >>>>>>>>> case, but still. >>>>>>>>> >>>>>>>>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> Please review the fix for jdk 8 and 7u40. >>>>>>>>>> The fix for JDK-8010906 don't take into account situation then >>>>>>>>>> first parent has no menu bar, but the second has. >>>>>>>>>> So it introduce the next scenario: >>>>>>>>>> #1. Open the window with File menu. >>>>>>>>>> #2. Open modal dialog1 =>File menu is disabled >>>>>>>>>> #3. Open modal dialog2 =>File menu disappears >>>>>>>>>> #4. Close dialog two >>>>>>>>>> #5. Close dialog one. File menu reappears, but File still disabled >>>>>>>>>> >>>>>>>>>> The steps #3. occurred, because CMenuBar.activate resets the >>>>>>>>>> current menubar if a passed javaMenuBar is null. >>>>>>>>>> The steps #5. occurred, because at step #3 we do not remove our >>>>>>>>>> nsmenu from the deleted NSMenuItem, when the appropriate >>>>>>>>>> NSMenuItem removed from mainMenu. So at step #5 we got a >>>>>>>>>> situation, when our nsmenu was added to the two different >>>>>>>>>> nsmenuitems: old(disabled) and new(enabled). >>>>>>>>>> >>>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>>>>>>>>> Webrev can be found at: >>>>>>>>>> http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Best regards, Sergey. >>>>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>> >>>> >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From leonid.romanov at oracle.com Wed Jul 24 05:50:11 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 24 Jul 2013 16:50:11 +0400 Subject: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac In-Reply-To: <51EFC86D.2020308@oracle.com> References: <51E98249.80504@oracle.com> <51ED3B91.2030809@oracle.com> <07D170B0-5131-4768-92B6-E6D3696CA8B5@oracle.com> <51EE55BD.8080306@oracle.com> <51EE5CD4.9010904@oracle.com> <51EEBF5A.3010902@oracle.com> <51EEE3A3.3090503@oracle.com> <51EFB7CF.3080400@oracle.com> <2E0BE06B-595A-4F86-8BB5-D7D434117056@oracle.com> <51EFC86D.2020308@oracle.com> Message-ID: So, there are no memory leaks? I'm OK with the fix, then. On Jul 24, 2013, at 4:28 PM, Sergey Bylokhov wrote: > Hi, Leonid. > Yes. When the child window is created, it create its parent also. And the owner cannot be deallocated until child window is live, but when the owner is disposed, it dispose all its child windows. > > On 24.07.2013 15:46, Leonid Romanov wrote: >> Looks good for me as well. The only thing that is not clear to me is the memory management in AWTWindow: since every child references its parent now, wouldn't it prevent the parent from being deallocated after it has been disposed? >> >> On Jul 24, 2013, at 3:17 PM, Sergey Bylokhov wrote: >> >>> Hi, Anthony. >>> Please review the updated version >>> http://cr.openjdk.java.net/~serb/8017189/webrev.02/ >>> In the fix a dependency from the dialog was removed. now we use menubar from the toplvl parent window. >>> >>> On 24.07.2013 0:12, Anthony Petrov wrote: >>>> Hi Sergey, >>>> >>>> I'll let Leonid test this patch since he has a number of good test cases. As for the code changes, they look good to me overall. The only scenario that concerns me is if we have a hierarchy of a frame and an owned undecorated window (e.g., a toolbar). With your current fix the menu will disappear as soon as the window gets activated because it is not a dialog and its menubar is obviously null: >>>> >>>>> 546 // Finds appropriate menubar in our hierarchy, >>>>> 547 if (self.javaMenuBar != nil || !IS(self.styleBits, IS_DIALOG)) { >>>>> 548 // shortpath >>>>> 549 [CMenuBar activate:self.javaMenuBar modallyDisabled:NO]; >>>>> 550 } >>>> IMO, this is undesirable. Can we remove this if/else altogether and instead code this logic as follows: >>>> >>>> CMenuBar *menu = ; >>>> [CMenuBar activate:menu modallyDisabled:!.isEnabled]; >>>> >>>> ? It seems to me that this should cover all possible use cases. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 07/23/2013 09:37 PM, Sergey Bylokhov wrote: >>>>> Hello. >>>>> Please review updated version of the fix: >>>>> http://cr.openjdk.java.net/~serb/8017189/webrev.01 >>>>> After the fix, for dialogs we activates a menubar from the first visible >>>>> and enabled owner. I use awtwindow owner instead of >>>>> nswindow.parentWindow, because when the windowDidBecomeKey is called for >>>>> the first time our nswindow still have no parentWindow(it is added later). >>>>> Any testing are welcome. >>>>> Thanks. >>>>> >>>>> On 23.07.2013 14:37, Leonid Romanov wrote: >>>>>> On 7/23/2013 14:06, Sergey Bylokhov wrote: >>>>>>> On 22.07.2013 23:32, Leonid Romanov wrote: >>>>>>>> Well, I'd like us to stay consistent with JDK 6. However, if we >>>>>>>> decide to fix this issue in some other way, we need to be consistent >>>>>>>> with other possible cases, like setting frame's menu to null before >>>>>>>> showing a dialog, making frame invisible, and so on. >>>>>>>> But as you've said, this issue is not related to 8017189, so let's >>>>>>>> go back to the fix for 8017189. I've got another question about it. >>>>>>>> When native window loses focus, we call -(void) deactivate method of >>>>>>>> CMenuBar class. At first, I thought that it basically removes all >>>>>>>> the menu items from the menu bar, but then I realized that it is not >>>>>>>> the case, because your fix depends on the fact that the window >>>>>>>> gaining focus inherits the menu bar from the window that just lost >>>>>>>> it. Now, consider step 4 of your scenario. Here, the dialog2 is the >>>>>>>> window that is loosing focus, and dialog1 is the window that is >>>>>>>> gaining it. As a result of dialog2 loosing focus, the current menu >>>>>>>> bar gets marked as not active (sActiveMenuBar in CMenuBar is set to >>>>>>>> false). When dialog1 gains focus, we do nothing with the current >>>>>>>> menu, because the opposite window (dialog2) doesn't formally have a >>>>>>>> menu (opposite->javaMenuBar is NULL). This means that dialog1 now >>>>>>>> has a menu that is formally inactive. >>>>>>>> Since I don't really understand the purpose of -(void) deactivate >>>>>>>> method, I can't say whether the situation I've described above is >>>>>>>> problematic or not. What do you think? >>>>>>> Actually this is not a problem of my fix, this is a problem of >>>>>>> 8010906, which was implemented on top of "opposite" property instead >>>>>>> of "dialog parent". Probably you know why? >>>>>>> I'll try to change it, but not sure is it dangerous to change it now >>>>>>> or not. >>>>>> I agree, after looking more closely at the original code, it seems >>>>>> that we will get the same deactivation issue in case of showing non >>>>>> modal dialog. I've no idea why 8010906 was implemented on top of the >>>>>> opposite, perhaps it looked like the simplest approach back then. Do >>>>>> you think that traversing windows hierarchy tree from the dialog being >>>>>> shown to an ancestor frame with a menu would have been a better idea? >>>>>> >>>>>>>>> On 22.07.2013 16:57, Leonid Romanov wrote: >>>>>>>>>> Hi. >>>>>>>>>> Here is a test case that, with your patch applied, works >>>>>>>>>> differently than JDK 6: >>>>>>>>>> 1. Show JFrame with a menu >>>>>>>>>> 2. Create a modal dialog with the frame as a parent >>>>>>>>>> 3. Dispose the frame >>>>>>>>>> 4. Make dialog visible >>>>>>>>>> >>>>>>>>>> With JDK 6, the dialog's menu will be disabled. With JDK 8, it >>>>>>>>>> will be enabled. So, formally, we've got a regression. I'm not >>>>>>>>>> sure whether it is worth fixing, because it looks like a corner >>>>>>>>>> case, but still. >>>>>>>>>> >>>>>>>>>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> Please review the fix for jdk 8 and 7u40. >>>>>>>>>>> The fix for JDK-8010906 don't take into account situation then >>>>>>>>>>> first parent has no menu bar, but the second has. >>>>>>>>>>> So it introduce the next scenario: >>>>>>>>>>> #1. Open the window with File menu. >>>>>>>>>>> #2. Open modal dialog1 =>File menu is disabled >>>>>>>>>>> #3. Open modal dialog2 =>File menu disappears >>>>>>>>>>> #4. Close dialog two >>>>>>>>>>> #5. Close dialog one. File menu reappears, but File still disabled >>>>>>>>>>> >>>>>>>>>>> The steps #3. occurred, because CMenuBar.activate resets the >>>>>>>>>>> current menubar if a passed javaMenuBar is null. >>>>>>>>>>> The steps #5. occurred, because at step #3 we do not remove our >>>>>>>>>>> nsmenu from the deleted NSMenuItem, when the appropriate >>>>>>>>>>> NSMenuItem removed from mainMenu. So at step #5 we got a >>>>>>>>>>> situation, when our nsmenu was added to the two different >>>>>>>>>>> nsmenuitems: old(disabled) and new(enabled). >>>>>>>>>>> >>>>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189 >>>>>>>>>>> Webrev can be found at: >>>>>>>>>>> http://cr.openjdk.java.net/~serb/8017189/webrev.00 >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Best regards, Sergey. >>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best regards, Sergey. >>>>>>>>> >>>>>>> >>>>> >>> >>> -- >>> Best regards, Sergey. >>> > > > -- > Best regards, Sergey. > From leonid.romanov at oracle.com Wed Jul 24 09:35:07 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 24 Jul 2013 20:35:07 +0400 Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang compiler" In-Reply-To: <6C640F77-71BE-4617-B641-AB1BA264FC82@oracle.com> References: <51EF006D.3060805@oracle.com> <51EF13E3.6060804@oracle.com> <6C640F77-71BE-4617-B641-AB1BA264FC82@oracle.com> Message-ID: <90FE4DD3-7C23-42BD-9EB9-F605595F2D5A@oracle.com> On Jul 24, 2013, at 5:12 PM, David Chase wrote: > > On 2013-07-23, at 7:38 PM, Tim Bell wrote: > >> Hello Leonid: >> >>> Just to satisfy my curiosity: what are advantages of using clang instead of gcc? >> >> I am a mere messenger here, but I am told that clang/clang++: >> >> - is command line compatible with gcc >> - is faster >> - produces better diagnostic messages >> - clang on MacOS is under active development while gcc is not [citation needed] >> >> To others out there - feel free to correct these points, or add more of your own. > > Clang is the default compiler for the next (Mavericks) MacOS release, or so I have heard. > Clang is already more up-to-date than (Apple-packaged) gcc on MacOS -- if you want to access some of the "new" (two years old) intrinsics from C or from the assembler, you need to use clang. > Compilation of hotspot itself is faster with clang; not sure about the performance of hotspot itself. I see? Thanks! Anything that reduces compilation time is good ) > > David > From tim.bell at oracle.com Wed Jul 24 15:48:03 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 24 Jul 2013 15:48:03 -0700 Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang compiler" In-Reply-To: References: <51EF006D.3060805@oracle.com> <51EFBDC9.4070200@oracle.com> <51EFC56C.6040304@oracle.com> Message-ID: <51F059A3.3080403@oracle.com> Christian: > That's not true. I've added Mac OS X support with the same change. For building hotspot only, perhaps. I want to build the entire product, start to finish, using clang. That's why I needed to touch these files: common/autoconf/hotspot-spec.gmk.in common/autoconf/toolchain.m4 make/jprt.properties Tim On 07/24/13 02:59 PM, Christian Thalinger wrote: > On Jul 24, 2013, at 5:15 AM, Tim Bell wrote: > >> On 07/24/13 04:43 AM, David Holmes wrote: >>> Hi Tim, >>> >>> On 24/07/2013 8:15 AM, Tim Bell wrote: >>>> Hello everyone- >>>> >>>> This is a small set of changes to switch from gcc to clang when building >>> So we already added support for clang as the compiler for hotspot - is this just extending things to allow configure to select clang? >> The earlier clang/hotspot activity was centered around Linux x86/x86_64. > That's not true. I've added Mac OS X support with the same change. > > -- Chris > >>>> on MacOS, and also enable building on MacOS 8.x >>> Have we already updated all the JPRT queues to have 10.8 macs versus 10.7 ones? >> Yes, all the queues have 10.8 Macs, which have been test-only up until now. >> >>>> Here is the bug report: >>>> >>>> http://bugs.sun.com/view_bug.do?bug_id=8019470 >>>> >>>> Here are the webrevs: >>>> >>>> Hotspot only: >>>> >>>> http://cr.openjdk.java.net/~tbell/8019470/hotspot/webrev.00/ >>> src/os/bsd/vm/os_bsd.cpp >>> >>> Again I'm confused. We already allowed building via clang so why wasn't this change needed before? >> This file is not used when building on Linux. >> >> Tim >> >>> Thanks, >>> David >>> >>>> All of the changes: >>>> >>>> http://cr.openjdk.java.net/~tbell/8019470/webrev.00/ >>> >>>> Thanks in advance. >>>> >>>> Tim >>>> From david.holmes at oracle.com Wed Jul 24 21:44:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jul 2013 14:44:13 +1000 Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang compiler" In-Reply-To: <51F059A3.3080403@oracle.com> References: <51EF006D.3060805@oracle.com> <51EFBDC9.4070200@oracle.com> <51EFC56C.6040304@oracle.com> <51F059A3.3080403@oracle.com> Message-ID: <51F0AD1D.1080907@oracle.com> On 25/07/2013 8:48 AM, Tim Bell wrote: > Christian: > >> That's not true. I've added Mac OS X support with the same change. > > For building hotspot only, perhaps. I want to build the entire product, > start to finish, using clang. > > That's why I needed to touch these files: > > common/autoconf/hotspot-spec.gmk.in > common/autoconf/toolchain.m4 > make/jprt.properties Yes but that doesn't explain the change now needed to os_bsd.cpp in hotspot. David ----- > > Tim > > > On 07/24/13 02:59 PM, Christian Thalinger wrote: >> On Jul 24, 2013, at 5:15 AM, Tim Bell wrote: >> >>> On 07/24/13 04:43 AM, David Holmes wrote: >>>> Hi Tim, >>>> >>>> On 24/07/2013 8:15 AM, Tim Bell wrote: >>>>> Hello everyone- >>>>> >>>>> This is a small set of changes to switch from gcc to clang when >>>>> building >>>> So we already added support for clang as the compiler for hotspot - >>>> is this just extending things to allow configure to select clang? >>> The earlier clang/hotspot activity was centered around Linux x86/x86_64. >> That's not true. I've added Mac OS X support with the same change. >> >> -- Chris >> >>>>> on MacOS, and also enable building on MacOS 8.x >>>> Have we already updated all the JPRT queues to have 10.8 macs versus >>>> 10.7 ones? >>> Yes, all the queues have 10.8 Macs, which have been test-only up >>> until now. >>> >>>>> Here is the bug report: >>>>> >>>>> http://bugs.sun.com/view_bug.do?bug_id=8019470 >>>>> >>>>> Here are the webrevs: >>>>> >>>>> Hotspot only: >>>>> >>>>> http://cr.openjdk.java.net/~tbell/8019470/hotspot/webrev.00/ >>>> src/os/bsd/vm/os_bsd.cpp >>>> >>>> Again I'm confused. We already allowed building via clang so why >>>> wasn't this change needed before? >>> This file is not used when building on Linux. >>> >>> Tim >>> >>>> Thanks, >>>> David >>>> >>>>> All of the changes: >>>>> >>>>> http://cr.openjdk.java.net/~tbell/8019470/webrev.00/ >>>> >>>>> Thanks in advance. >>>>> >>>>> Tim >>>>> > From krueger at lesspain.de Thu Jul 25 03:12:14 2013 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Thu, 25 Jul 2013 12:12:14 +0200 Subject: Apple service discovery API Message-ID: Hi, just noticed that OpenJDK 8 does not contain dns_sd.jar, which we use with Apple's JDK8 for service discovery. Will this API (stuff like com.apple.dnssd.DNSSDService) be supported in the future or do we have to look for alternatives? Thanks in advance, Robert From leonid.romanov at oracle.com Thu Jul 25 17:54:56 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 26 Jul 2013 04:54:56 +0400 Subject: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working Message-ID: Hi, Please review a fix for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working. It doesn't work because a bunch of code required to make it work is commented out. So, I've uncommented it, but since it isn't enough, I've also done a number of additional minor modifications. Bug: http://bugs.sun.com/view_bug.do?bug_id=8007267 webrev: http://cr.openjdk.java.net/~leonidr/8007267/webrev.00/ Thanks, Leonid. From anthony.petrov at oracle.com Fri Jul 26 01:56:55 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 26 Jul 2013 12:56:55 +0400 Subject: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working In-Reply-To: References: Message-ID: <51F239D7.3050109@oracle.com> Hi Leonid, AWTWindow.m > 568 - (void) windowDidResignKey: (NSNotification *) notification { > 572 [self.javaMenuBar deactivate]; > 574 CMenuBar* defaultMenu = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; > 575 if (defaultMenu != nil) { > 576 [CMenuBar activate:defaultMenu modallyDisabled:NO]; > 577 } Note that this may cause brief menu flickering if the very next event is windowDidBecomeKey for another window with a non-null menu bar. But we really can't predict whether a window belonging to our app will receive focus or not, so there doesn't seem to be a better way to handle this situation anyway. I'd suggest to add a comment here stating that the problem is known. The fix looks fine otherwise. Please consider it approved. -- best regards, Anthony On 07/26/2013 04:54 AM, Leonid Romanov wrote: > Hi, > Please review a fix for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working. It doesn't work because a bunch of code required to make it work is commented out. So, I've uncommented it, but since it isn't enough, I've also done a number of additional minor modifications. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=8007267 > webrev: http://cr.openjdk.java.net/~leonidr/8007267/webrev.00/ > > Thanks, > Leonid. > From Sergey.Bylokhov at oracle.com Fri Jul 26 03:57:19 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 26 Jul 2013 14:57:19 +0400 Subject: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working In-Reply-To: <51F239D7.3050109@oracle.com> References: <51F239D7.3050109@oracle.com> Message-ID: <51F2560F.6080607@oracle.com> Hi, Leonid. Please confirm that flirk is not a problem here. Also looks like in the windowDidBecomeKey: 557 if (menuBar == nil) { 558 menuBar = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; 559 } 560 561 [CMenuBar activate:menuBar modallyDisabled:!awtWindow.isEnabled]; defaultMenuBar should not depends from the awtWindow.isEnabled On 26.07.2013 12:56, Anthony Petrov wrote: > Hi Leonid, > > AWTWindow.m >> 568 - (void) windowDidResignKey: (NSNotification *) notification { >> 572 [self.javaMenuBar deactivate]; >> 574 CMenuBar* defaultMenu = [[ApplicationDelegate >> sharedDelegate] defaultMenuBar]; >> 575 if (defaultMenu != nil) { >> 576 [CMenuBar activate:defaultMenu modallyDisabled:NO]; >> 577 } > > Note that this may cause brief menu flickering if the very next event > is windowDidBecomeKey for another window with a non-null menu bar. But > we really can't predict whether a window belonging to our app will > receive focus or not, so there doesn't seem to be a better way to > handle this situation anyway. I'd suggest to add a comment here > stating that the problem is known. > > The fix looks fine otherwise. Please consider it approved. > > -- > best regards, > Anthony > > On 07/26/2013 04:54 AM, Leonid Romanov wrote: >> Hi, >> Please review a fix for 8007267: [macosx] >> com.apple.eawt.Application.setDefaultMenuBar is not working. It >> doesn't work because a bunch of code required to make it work is >> commented out. So, I've uncommented it, but since it isn't enough, >> I've also done a number of additional minor modifications. >> >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007267 >> webrev: http://cr.openjdk.java.net/~leonidr/8007267/webrev.00/ >> >> Thanks, >> Leonid. >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Jul 26 03:59:51 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 26 Jul 2013 14:59:51 +0400 Subject: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working In-Reply-To: <51F239D7.3050109@oracle.com> References: <51F239D7.3050109@oracle.com> Message-ID: <51F256A7.7080000@oracle.com> Hi, Leonid. Probably it would be easy to change CMenuBar.activate/deactivate? instead of their usage? On 26.07.2013 12:56, Anthony Petrov wrote: > Hi Leonid, > > AWTWindow.m >> 568 - (void) windowDidResignKey: (NSNotification *) notification { >> 572 [self.javaMenuBar deactivate]; >> 574 CMenuBar* defaultMenu = [[ApplicationDelegate >> sharedDelegate] defaultMenuBar]; >> 575 if (defaultMenu != nil) { >> 576 [CMenuBar activate:defaultMenu modallyDisabled:NO]; >> 577 } > > Note that this may cause brief menu flickering if the very next event > is windowDidBecomeKey for another window with a non-null menu bar. But > we really can't predict whether a window belonging to our app will > receive focus or not, so there doesn't seem to be a better way to > handle this situation anyway. I'd suggest to add a comment here > stating that the problem is known. > > The fix looks fine otherwise. Please consider it approved. > > -- > best regards, > Anthony > > On 07/26/2013 04:54 AM, Leonid Romanov wrote: >> Hi, >> Please review a fix for 8007267: [macosx] >> com.apple.eawt.Application.setDefaultMenuBar is not working. It >> doesn't work because a bunch of code required to make it work is >> commented out. So, I've uncommented it, but since it isn't enough, >> I've also done a number of additional minor modifications. >> >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007267 >> webrev: http://cr.openjdk.java.net/~leonidr/8007267/webrev.00/ >> >> Thanks, >> Leonid. >> -- Best regards, Sergey. From leonid.romanov at oracle.com Fri Jul 26 04:02:18 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 26 Jul 2013 15:02:18 +0400 Subject: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working In-Reply-To: <51F239D7.3050109@oracle.com> References: <51F239D7.3050109@oracle.com> Message-ID: <8C279BD8-542B-4B5C-800A-970A76641A5C@oracle.com> On Jul 26, 2013, at 12:56 PM, Anthony Petrov wrote: > Hi Leonid, > > AWTWindow.m >> 568 - (void) windowDidResignKey: (NSNotification *) notification { >> 572 [self.javaMenuBar deactivate]; >> 574 CMenuBar* defaultMenu = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; >> 575 if (defaultMenu != nil) { >> 576 [CMenuBar activate:defaultMenu modallyDisabled:NO]; >> 577 } > > Note that this may cause brief menu flickering if the very next event is windowDidBecomeKey for another window with a non-null menu bar. But we really can't predict whether a window belonging to our app will receive focus or not, so there doesn't seem to be a better way to handle this situation anyway. I'd suggest to add a comment here stating that the problem is known. > > The fix looks fine otherwise. Please consider it approved. > Yeah, I've tried, but couldn't cause any flickering. My guess this is because windowDidBecomeKey/windowDiidResignKey are called within the same internal method, so perhaps all menus redrawing happens only during the next run loop iteration, or may be the interval between windowDidBecomeKey/windowDiidResignKey is too short. > -- > best regards, > Anthony > > On 07/26/2013 04:54 AM, Leonid Romanov wrote: >> Hi, >> Please review a fix for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working. It doesn't work because a bunch of code required to make it work is commented out. So, I've uncommented it, but since it isn't enough, I've also done a number of additional minor modifications. >> >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007267 >> webrev: http://cr.openjdk.java.net/~leonidr/8007267/webrev.00/ >> >> Thanks, >> Leonid. >> From leonid.romanov at oracle.com Fri Jul 26 04:08:14 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 26 Jul 2013 15:08:14 +0400 Subject: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working In-Reply-To: <51F256A7.7080000@oracle.com> References: <51F239D7.3050109@oracle.com> <51F256A7.7080000@oracle.com> Message-ID: Doing this would introduce the dependency between our regular menu code and eawt, which is kinda optional now. I'd like to avoid it. On Jul 26, 2013, at 2:59 PM, Sergey Bylokhov wrote: > Hi, Leonid. > Probably it would be easy to change CMenuBar.activate/deactivate? instead of their usage? > > On 26.07.2013 12:56, Anthony Petrov wrote: >> Hi Leonid, >> >> AWTWindow.m >>> 568 - (void) windowDidResignKey: (NSNotification *) notification { >>> 572 [self.javaMenuBar deactivate]; >>> 574 CMenuBar* defaultMenu = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; >>> 575 if (defaultMenu != nil) { >>> 576 [CMenuBar activate:defaultMenu modallyDisabled:NO]; >>> 577 } >> >> Note that this may cause brief menu flickering if the very next event is windowDidBecomeKey for another window with a non-null menu bar. But we really can't predict whether a window belonging to our app will receive focus or not, so there doesn't seem to be a better way to handle this situation anyway. I'd suggest to add a comment here stating that the problem is known. >> >> The fix looks fine otherwise. Please consider it approved. >> >> -- >> best regards, >> Anthony >> >> On 07/26/2013 04:54 AM, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working. It doesn't work because a bunch of code required to make it work is commented out. So, I've uncommented it, but since it isn't enough, I've also done a number of additional minor modifications. >>> >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007267 >>> webrev: http://cr.openjdk.java.net/~leonidr/8007267/webrev.00/ >>> >>> Thanks, >>> Leonid. >>> > > > -- > Best regards, Sergey. > From anthony.petrov at oracle.com Fri Jul 26 04:22:02 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 26 Jul 2013 15:22:02 +0400 Subject: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working In-Reply-To: <8C279BD8-542B-4B5C-800A-970A76641A5C@oracle.com> References: <51F239D7.3050109@oracle.com> <8C279BD8-542B-4B5C-800A-970A76641A5C@oracle.com> Message-ID: <51F25BDA.9040202@oracle.com> Sounds good then. Thanks. -- best regards, Anthony On 07/26/2013 03:02 PM, Leonid Romanov wrote: > > On Jul 26, 2013, at 12:56 PM, Anthony Petrov wrote: > >> Hi Leonid, >> >> AWTWindow.m >>> 568 - (void) windowDidResignKey: (NSNotification *) notification { >>> 572 [self.javaMenuBar deactivate]; >>> 574 CMenuBar* defaultMenu = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; >>> 575 if (defaultMenu != nil) { >>> 576 [CMenuBar activate:defaultMenu modallyDisabled:NO]; >>> 577 } >> >> Note that this may cause brief menu flickering if the very next event is windowDidBecomeKey for another window with a non-null menu bar. But we really can't predict whether a window belonging to our app will receive focus or not, so there doesn't seem to be a better way to handle this situation anyway. I'd suggest to add a comment here stating that the problem is known. >> >> The fix looks fine otherwise. Please consider it approved. >> > > Yeah, I've tried, but couldn't cause any flickering. My guess this is because windowDidBecomeKey/windowDiidResignKey are called within the same internal method, so perhaps all menus redrawing happens only during the next run loop iteration, or may be the interval between windowDidBecomeKey/windowDiidResignKey is too short. > >> -- >> best regards, >> Anthony >> >> On 07/26/2013 04:54 AM, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working. It doesn't work because a bunch of code required to make it work is commented out. So, I've uncommented it, but since it isn't enough, I've also done a number of additional minor modifications. >>> >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007267 >>> webrev: http://cr.openjdk.java.net/~leonidr/8007267/webrev.00/ >>> >>> Thanks, >>> Leonid. >>> > From leonid.romanov at oracle.com Fri Jul 26 04:45:51 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 26 Jul 2013 15:45:51 +0400 Subject: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working In-Reply-To: <51F2560F.6080607@oracle.com> References: <51F239D7.3050109@oracle.com> <51F2560F.6080607@oracle.com> Message-ID: Here is a second version of the fix which addresses both Anthony and Sergey comments: http://cr.openjdk.java.net/~leonidr/8007267/webrev.01/ On Jul 26, 2013, at 2:57 PM, Sergey Bylokhov wrote: > Hi, Leonid. > Please confirm that flirk is not a problem here. > Also looks like in the windowDidBecomeKey: > 557 if (menuBar == nil) { > 558 menuBar = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; > 559 } > 560 > 561 [CMenuBar activate:menuBar modallyDisabled:!awtWindow.isEnabled]; > > defaultMenuBar should not depends from the awtWindow.isEnabled > > On 26.07.2013 12:56, Anthony Petrov wrote: >> Hi Leonid, >> >> AWTWindow.m >>> 568 - (void) windowDidResignKey: (NSNotification *) notification { >>> 572 [self.javaMenuBar deactivate]; >>> 574 CMenuBar* defaultMenu = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; >>> 575 if (defaultMenu != nil) { >>> 576 [CMenuBar activate:defaultMenu modallyDisabled:NO]; >>> 577 } >> >> Note that this may cause brief menu flickering if the very next event is windowDidBecomeKey for another window with a non-null menu bar. But we really can't predict whether a window belonging to our app will receive focus or not, so there doesn't seem to be a better way to handle this situation anyway. I'd suggest to add a comment here stating that the problem is known. >> >> The fix looks fine otherwise. Please consider it approved. >> >> -- >> best regards, >> Anthony >> >> On 07/26/2013 04:54 AM, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working. It doesn't work because a bunch of code required to make it work is commented out. So, I've uncommented it, but since it isn't enough, I've also done a number of additional minor modifications. >>> >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007267 >>> webrev: http://cr.openjdk.java.net/~leonidr/8007267/webrev.00/ >>> >>> Thanks, >>> Leonid. >>> > > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Fri Jul 26 04:53:16 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 26 Jul 2013 15:53:16 +0400 Subject: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working In-Reply-To: References: <51F239D7.3050109@oracle.com> <51F2560F.6080607@oracle.com> Message-ID: <51F2632C.8000308@oracle.com> Hi, Leonid. As far I understand,shortcuts will not work, if the window without menubar will be active, and defaultMenuBar will be added? On 26.07.2013 15:45, Leonid Romanov wrote: > Here is a second version of the fix which addresses both Anthony and Sergey comments: > > http://cr.openjdk.java.net/~leonidr/8007267/webrev.01/ > > On Jul 26, 2013, at 2:57 PM, Sergey Bylokhov wrote: > >> Hi, Leonid. >> Please confirm that flirk is not a problem here. >> Also looks like in the windowDidBecomeKey: >> 557 if (menuBar == nil) { >> 558 menuBar = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; >> 559 } >> 560 >> 561 [CMenuBar activate:menuBar modallyDisabled:!awtWindow.isEnabled]; >> >> defaultMenuBar should not depends from the awtWindow.isEnabled >> >> On 26.07.2013 12:56, Anthony Petrov wrote: >>> Hi Leonid, >>> >>> AWTWindow.m >>>> 568 - (void) windowDidResignKey: (NSNotification *) notification { >>>> 572 [self.javaMenuBar deactivate]; >>>> 574 CMenuBar* defaultMenu = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; >>>> 575 if (defaultMenu != nil) { >>>> 576 [CMenuBar activate:defaultMenu modallyDisabled:NO]; >>>> 577 } >>> Note that this may cause brief menu flickering if the very next event is windowDidBecomeKey for another window with a non-null menu bar. But we really can't predict whether a window belonging to our app will receive focus or not, so there doesn't seem to be a better way to handle this situation anyway. I'd suggest to add a comment here stating that the problem is known. >>> >>> The fix looks fine otherwise. Please consider it approved. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 07/26/2013 04:54 AM, Leonid Romanov wrote: >>>> Hi, >>>> Please review a fix for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working. It doesn't work because a bunch of code required to make it work is commented out. So, I've uncommented it, but since it isn't enough, I've also done a number of additional minor modifications. >>>> >>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007267 >>>> webrev: http://cr.openjdk.java.net/~leonidr/8007267/webrev.00/ >>>> >>>> Thanks, >>>> Leonid. >>>> >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From anthony.petrov at oracle.com Fri Jul 26 04:54:25 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 26 Jul 2013 15:54:25 +0400 Subject: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working In-Reply-To: References: <51F239D7.3050109@oracle.com> <51F2560F.6080607@oracle.com> Message-ID: <51F26371.2080304@oracle.com> Looks fine. -- best regards, Anthony On 07/26/2013 03:45 PM, Leonid Romanov wrote: > Here is a second version of the fix which addresses both Anthony and Sergey comments: > > http://cr.openjdk.java.net/~leonidr/8007267/webrev.01/ > > On Jul 26, 2013, at 2:57 PM, Sergey Bylokhov wrote: > >> Hi, Leonid. >> Please confirm that flirk is not a problem here. >> Also looks like in the windowDidBecomeKey: >> 557 if (menuBar == nil) { >> 558 menuBar = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; >> 559 } >> 560 >> 561 [CMenuBar activate:menuBar modallyDisabled:!awtWindow.isEnabled]; >> >> defaultMenuBar should not depends from the awtWindow.isEnabled >> >> On 26.07.2013 12:56, Anthony Petrov wrote: >>> Hi Leonid, >>> >>> AWTWindow.m >>>> 568 - (void) windowDidResignKey: (NSNotification *) notification { >>>> 572 [self.javaMenuBar deactivate]; >>>> 574 CMenuBar* defaultMenu = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; >>>> 575 if (defaultMenu != nil) { >>>> 576 [CMenuBar activate:defaultMenu modallyDisabled:NO]; >>>> 577 } >>> >>> Note that this may cause brief menu flickering if the very next event is windowDidBecomeKey for another window with a non-null menu bar. But we really can't predict whether a window belonging to our app will receive focus or not, so there doesn't seem to be a better way to handle this situation anyway. I'd suggest to add a comment here stating that the problem is known. >>> >>> The fix looks fine otherwise. Please consider it approved. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 07/26/2013 04:54 AM, Leonid Romanov wrote: >>>> Hi, >>>> Please review a fix for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working. It doesn't work because a bunch of code required to make it work is commented out. So, I've uncommented it, but since it isn't enough, I've also done a number of additional minor modifications. >>>> >>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007267 >>>> webrev: http://cr.openjdk.java.net/~leonidr/8007267/webrev.00/ >>>> >>>> Thanks, >>>> Leonid. >>>> >> >> >> -- >> Best regards, Sergey. >> > From leonid.romanov at oracle.com Fri Jul 26 04:55:20 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 26 Jul 2013 15:55:20 +0400 Subject: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working In-Reply-To: <51F2632C.8000308@oracle.com> References: <51F239D7.3050109@oracle.com> <51F2560F.6080607@oracle.com> <51F2632C.8000308@oracle.com> Message-ID: Yes, they won't. Same thing for Apple JDK 6. On Jul 26, 2013, at 3:53 PM, Sergey Bylokhov wrote: > Hi, Leonid. > As far I understand,shortcuts will not work, if the window without menubar will be active, and defaultMenuBar will be added? > > On 26.07.2013 15:45, Leonid Romanov wrote: >> Here is a second version of the fix which addresses both Anthony and Sergey comments: >> >> http://cr.openjdk.java.net/~leonidr/8007267/webrev.01/ >> >> On Jul 26, 2013, at 2:57 PM, Sergey Bylokhov wrote: >> >>> Hi, Leonid. >>> Please confirm that flirk is not a problem here. >>> Also looks like in the windowDidBecomeKey: >>> 557 if (menuBar == nil) { >>> 558 menuBar = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; >>> 559 } >>> 560 >>> 561 [CMenuBar activate:menuBar modallyDisabled:!awtWindow.isEnabled]; >>> >>> defaultMenuBar should not depends from the awtWindow.isEnabled >>> >>> On 26.07.2013 12:56, Anthony Petrov wrote: >>>> Hi Leonid, >>>> >>>> AWTWindow.m >>>>> 568 - (void) windowDidResignKey: (NSNotification *) notification { >>>>> 572 [self.javaMenuBar deactivate]; >>>>> 574 CMenuBar* defaultMenu = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; >>>>> 575 if (defaultMenu != nil) { >>>>> 576 [CMenuBar activate:defaultMenu modallyDisabled:NO]; >>>>> 577 } >>>> Note that this may cause brief menu flickering if the very next event is windowDidBecomeKey for another window with a non-null menu bar. But we really can't predict whether a window belonging to our app will receive focus or not, so there doesn't seem to be a better way to handle this situation anyway. I'd suggest to add a comment here stating that the problem is known. >>>> >>>> The fix looks fine otherwise. Please consider it approved. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 07/26/2013 04:54 AM, Leonid Romanov wrote: >>>>> Hi, >>>>> Please review a fix for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working. It doesn't work because a bunch of code required to make it work is commented out. So, I've uncommented it, but since it isn't enough, I've also done a number of additional minor modifications. >>>>> >>>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007267 >>>>> webrev: http://cr.openjdk.java.net/~leonidr/8007267/webrev.00/ >>>>> >>>>> Thanks, >>>>> Leonid. >>>>> >>> >>> -- >>> Best regards, Sergey. >>> > > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Fri Jul 26 04:58:55 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 26 Jul 2013 15:58:55 +0400 Subject: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working In-Reply-To: References: <51F239D7.3050109@oracle.com> <51F2560F.6080607@oracle.com> Message-ID: <51F2647F.2030403@oracle.com> Fix looks fine. On 26.07.2013 15:45, Leonid Romanov wrote: > Here is a second version of the fix which addresses both Anthony and Sergey comments: > > http://cr.openjdk.java.net/~leonidr/8007267/webrev.01/ > > On Jul 26, 2013, at 2:57 PM, Sergey Bylokhov wrote: > >> Hi, Leonid. >> Please confirm that flirk is not a problem here. >> Also looks like in the windowDidBecomeKey: >> 557 if (menuBar == nil) { >> 558 menuBar = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; >> 559 } >> 560 >> 561 [CMenuBar activate:menuBar modallyDisabled:!awtWindow.isEnabled]; >> >> defaultMenuBar should not depends from the awtWindow.isEnabled >> >> On 26.07.2013 12:56, Anthony Petrov wrote: >>> Hi Leonid, >>> >>> AWTWindow.m >>>> 568 - (void) windowDidResignKey: (NSNotification *) notification { >>>> 572 [self.javaMenuBar deactivate]; >>>> 574 CMenuBar* defaultMenu = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; >>>> 575 if (defaultMenu != nil) { >>>> 576 [CMenuBar activate:defaultMenu modallyDisabled:NO]; >>>> 577 } >>> Note that this may cause brief menu flickering if the very next event is windowDidBecomeKey for another window with a non-null menu bar. But we really can't predict whether a window belonging to our app will receive focus or not, so there doesn't seem to be a better way to handle this situation anyway. I'd suggest to add a comment here stating that the problem is known. >>> >>> The fix looks fine otherwise. Please consider it approved. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 07/26/2013 04:54 AM, Leonid Romanov wrote: >>>> Hi, >>>> Please review a fix for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working. It doesn't work because a bunch of code required to make it work is commented out. So, I've uncommented it, but since it isn't enough, I've also done a number of additional minor modifications. >>>> >>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007267 >>>> webrev: http://cr.openjdk.java.net/~leonidr/8007267/webrev.00/ >>>> >>>> Thanks, >>>> Leonid. >>>> >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From brent.christian at oracle.com Fri Jul 26 10:53:05 2013 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 26 Jul 2013 10:53:05 -0700 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X Message-ID: <51F2B781.1050104@oracle.com> Please review my fix for 8011194 : "Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X" http://bugs.sun.com/view_bug.do?bug_id=8011194 In most cases of launching a Java app on Mac (from the cmdline, or from a native .app bundle), reading and displaying UTF-8 characters beyond the standard ASCII range works fine. A notable exception is the launching of an app by double-clicking a .jar file. In this case, file.encoding defaults to US-ASCII, and characters outside of the ASCII range show up as garbage. (FWIW, this is not recommended by Apple as a method for deploying Java apps [1], though OS X does have a Jar Launcher.app to make it work.) It's worth mentioning that this is not something that has ever worked on MacOS X. (Apple's JRE defaulted to "MacRoman" for English and AFAIK most European locales. I believe this is a holdover from the pre-OS X days). Even so, the situation can be improved. When launching, if the standard encoding comes up as US-ASCII, but there are no hints from the environment (e.g. LANG/etc environment variables), it would be sane to instead use UTF-8 as the default encoding on MacOS X. An explicit file.encoding setting by the user is still honored (and can even be set back to US-ASCII). I believe this also fixes the related issue with webstart [2]. Webrev is here: http://cr.openjdk.java.net/~bchristi/8011194/webrev.00/ Thanks, -Brent [1] http://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html [2] http://bugs.sun.com/view_bug.do?bug_id=8011195 From david.dehaven at oracle.com Fri Jul 26 14:34:11 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 26 Jul 2013 14:34:11 -0700 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: <51F2B781.1050104@oracle.com> References: <51F2B781.1050104@oracle.com> Message-ID: <23074B3D-B75B-4568-B32C-15481332FBB3@oracle.com> > Please review my fix for 8011194 : "Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X" > > http://bugs.sun.com/view_bug.do?bug_id=8011194 > > In most cases of launching a Java app on Mac (from the cmdline, or from a native .app bundle), reading and displaying UTF-8 characters beyond the standard ASCII range works fine. > > A notable exception is the launching of an app by double-clicking a .jar file. In this case, file.encoding defaults to US-ASCII, and characters outside of the ASCII range show up as garbage. > > (FWIW, this is not recommended by Apple as a method for deploying Java apps [1], though OS X does have a Jar Launcher.app to make it work.) > > It's worth mentioning that this is not something that has ever worked on MacOS X. (Apple's JRE defaulted to "MacRoman" for English and AFAIK most European locales. I believe this is a holdover from the pre-OS X days). > > Even so, the situation can be improved. When launching, if the standard encoding comes up as US-ASCII, but there are no hints from the environment (e.g. LANG/etc environment variables), it would be sane to instead use UTF-8 as the default encoding on MacOS X. An explicit file.encoding setting by the user is still honored (and can even be set back to US-ASCII). > > I believe this also fixes the related issue with webstart [2]. That'd be wonderful! :) I'm not a "Reviewer" but it looks fine to me. -DrD- From david.holmes at oracle.com Sun Jul 28 22:13:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Jul 2013 15:13:38 +1000 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: <51F2B781.1050104@oracle.com> References: <51F2B781.1050104@oracle.com> Message-ID: <51F5FA02.9020909@oracle.com> On 27/07/2013 3:53 AM, Brent Christian wrote: > Please review my fix for 8011194 : "Apps launched via double-clicked > .jars have file.encoding value of US-ASCII on Mac OS X" > > http://bugs.sun.com/view_bug.do?bug_id=8011194 > > In most cases of launching a Java app on Mac (from the cmdline, or from > a native .app bundle), reading and displaying UTF-8 characters beyond > the standard ASCII range works fine. > > A notable exception is the launching of an app by double-clicking a .jar > file. In this case, file.encoding defaults to US-ASCII, and characters > outside of the ASCII range show up as garbage. Why does this occur? What sets the encoding to US-ASCII? David ----- > (FWIW, this is not recommended by Apple as a method for deploying Java > apps [1], though OS X does have a Jar Launcher.app to make it work.) > > It's worth mentioning that this is not something that has ever worked on > MacOS X. (Apple's JRE defaulted to "MacRoman" for English and AFAIK most > European locales. I believe this is a holdover from the pre-OS X days). > > Even so, the situation can be improved. When launching, if the standard > encoding comes up as US-ASCII, but there are no hints from the > environment (e.g. LANG/etc environment variables), it would be sane to > instead use UTF-8 as the default encoding on MacOS X. An explicit > file.encoding setting by the user is still honored (and can even be set > back to US-ASCII). > > I believe this also fixes the related issue with webstart [2]. > > Webrev is here: > http://cr.openjdk.java.net/~bchristi/8011194/webrev.00/ > > Thanks, > -Brent > > [1] > http://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html > > [2] http://bugs.sun.com/view_bug.do?bug_id=8011195 > From brent.christian at oracle.com Mon Jul 29 12:54:08 2013 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 29 Jul 2013 12:54:08 -0700 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: <51F5FA02.9020909@oracle.com> References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> Message-ID: <51F6C860.4020000@oracle.com> On 7/28/13 10:13 PM, David Holmes wrote: > On 27/07/2013 3:53 AM, Brent Christian wrote: >> Please review my fix for 8011194 : "Apps launched via double-clicked >> .jars have file.encoding value of US-ASCII on Mac OS X" >> >> http://bugs.sun.com/view_bug.do?bug_id=8011194 >> >> In most cases of launching a Java app on Mac (from the cmdline, or from >> a native .app bundle), reading and displaying UTF-8 characters beyond >> the standard ASCII range works fine. >> >> A notable exception is the launching of an app by double-clicking a .jar >> file. In this case, file.encoding defaults to US-ASCII, and characters >> outside of the ASCII range show up as garbage. > > Why does this occur? What sets the encoding to US-ASCII? "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no values for LANG/LC* are set in the environment when double-clicking a .jar. We get "UTF-8" when launching from the command line because the default Terminal.app setup on Mac will setup LANG for you (to "en_US.UTF-8" in the US). -Brent From david.holmes at oracle.com Mon Jul 29 20:10:37 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Jul 2013 13:10:37 +1000 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: <51F6C860.4020000@oracle.com> References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> <51F6C860.4020000@oracle.com> Message-ID: <51F72EAD.7040201@oracle.com> On 30/07/2013 5:54 AM, Brent Christian wrote: > On 7/28/13 10:13 PM, David Holmes wrote: >> On 27/07/2013 3:53 AM, Brent Christian wrote: >>> Please review my fix for 8011194 : "Apps launched via double-clicked >>> .jars have file.encoding value of US-ASCII on Mac OS X" >>> >>> http://bugs.sun.com/view_bug.do?bug_id=8011194 >>> >>> In most cases of launching a Java app on Mac (from the cmdline, or from >>> a native .app bundle), reading and displaying UTF-8 characters beyond >>> the standard ASCII range works fine. >>> >>> A notable exception is the launching of an app by double-clicking a .jar >>> file. In this case, file.encoding defaults to US-ASCII, and characters >>> outside of the ASCII range show up as garbage. >> >> Why does this occur? What sets the encoding to US-ASCII? > > "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no > values for LANG/LC* are set in the environment when double-clicking a .jar. > > We get "UTF-8" when launching from the command line because the default > Terminal.app setup on Mac will setup LANG for you (to "en_US.UTF-8" in > the US). Sounds like a user environment error to me. This isn't my area but I'm not convinced we should be second guessing what we think the encoding should be. What if someone intends for it to be US-ASCII? David ----- > -Brent From Johannes.Schindelin at gmx.de Tue Jul 30 07:14:58 2013 From: Johannes.Schindelin at gmx.de (Johannes Schindelin) Date: Tue, 30 Jul 2013 16:14:58 +0200 (CEST) Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: <51F72EAD.7040201@oracle.com> References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> <51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com> Message-ID: Hi, On Tue, 30 Jul 2013, David Holmes wrote: > On 30/07/2013 5:54 AM, Brent Christian wrote: > > On 7/28/13 10:13 PM, David Holmes wrote: > > > On 27/07/2013 3:53 AM, Brent Christian wrote: > > > > Please review my fix for 8011194 : "Apps launched via double-clicked > > > > .jars have file.encoding value of US-ASCII on Mac OS X" > > > > > > > > http://bugs.sun.com/view_bug.do?bug_id=8011194 > > > > > > > > In most cases of launching a Java app on Mac (from the cmdline, or > > > > from a native .app bundle), reading and displaying UTF-8 > > > > characters beyond the standard ASCII range works fine. > > > > > > > > A notable exception is the launching of an app by double-clicking > > > > a .jar file. In this case, file.encoding defaults to US-ASCII, > > > > and characters outside of the ASCII range show up as garbage. > > > > > > Why does this occur? What sets the encoding to US-ASCII? > > > > "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no > > values for LANG/LC* are set in the environment when double-clicking a > > .jar. > > > > We get "UTF-8" when launching from the command line because the > > default Terminal.app setup on Mac will setup LANG for you (to > > "en_US.UTF-8" in the US). > > Sounds like a user environment error to me. This isn't my area but I'm > not convinced we should be second guessing what we think the encoding > should be. Except that that is not the case here, of course. The user did *not* set any environment variable in this case. So we are not talking about "second guessing" or "user environment error" but about a sensible default. As to US-ASCII, sorry to say: the seventies called and want their character set back. There can be no question that UTF-8 is the best default character encoding, or are you even going to question *that*? > What if someone intends for it to be US-ASCII? Then LANG would not be unset, would it. Hth, Johannes From swpalmer at gmail.com Tue Jul 30 07:56:59 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 30 Jul 2013 10:56:59 -0400 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> <51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com> Message-ID: Then shouldn't you be complaining to Apple that the value returned by nl_langinfo needs to be changed? David's point seems to be that second guessing the character set reported by the OS is likely to cause a different set of problems. Scott On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin < Johannes.Schindelin at gmx.de> wrote: > Hi, > > On Tue, 30 Jul 2013, David Holmes wrote: > > > On 30/07/2013 5:54 AM, Brent Christian wrote: > > > On 7/28/13 10:13 PM, David Holmes wrote: > > > > On 27/07/2013 3:53 AM, Brent Christian wrote: > > > > > Please review my fix for 8011194 : "Apps launched via > double-clicked > > > > > .jars have file.encoding value of US-ASCII on Mac OS X" > > > > > > > > > > http://bugs.sun.com/view_bug.do?bug_id=8011194 > > > > > > > > > > In most cases of launching a Java app on Mac (from the cmdline, or > > > > > from a native .app bundle), reading and displaying UTF-8 > > > > > characters beyond the standard ASCII range works fine. > > > > > > > > > > A notable exception is the launching of an app by double-clicking > > > > > a .jar file. In this case, file.encoding defaults to US-ASCII, > > > > > and characters outside of the ASCII range show up as garbage. > > > > > > > > Why does this occur? What sets the encoding to US-ASCII? > > > > > > "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no > > > values for LANG/LC* are set in the environment when double-clicking a > > > .jar. > > > > > > We get "UTF-8" when launching from the command line because the > > > default Terminal.app setup on Mac will setup LANG for you (to > > > "en_US.UTF-8" in the US). > > > > Sounds like a user environment error to me. This isn't my area but I'm > > not convinced we should be second guessing what we think the encoding > > should be. > > Except that that is not the case here, of course. The user did *not* set > any environment variable in this case. > > So we are not talking about "second guessing" or "user environment error" > but about a sensible default. > > As to US-ASCII, sorry to say: the seventies called and want their > character set back. > > There can be no question that UTF-8 is the best default character > encoding, or are you even going to question *that*? > > > What if someone intends for it to be US-ASCII? > > Then LANG would not be unset, would it. > > Hth, > Johannes > From francis at devrx.org Tue Jul 30 09:05:16 2013 From: francis at devrx.org (Francis Devereux) Date: Tue, 30 Jul 2013 17:05:16 +0100 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> <51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com> Message-ID: <8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org> I suspect that Apple might be unlikely to change the value that nl_langinfo returns when LANG is unset. However, it might be possible to fix this issue without second-guessing the character set reported by the OS by calling [NSLocale currentLocale] (or the CFLocale equivalent) instead of nl_langinfo. I think (although I haven't checked) that that [NSLocale currentLocale] determines the current locale using a mechanism other than environment variables, because LANG is usually be unset for GUI apps on OS X. On 30 Jul 2013, at 15:56, Scott Palmer wrote: > Then shouldn't you be complaining to Apple that the value returned by > nl_langinfo needs to be changed? > David's point seems to be that second guessing the character set reported > by the OS is likely to cause a different set of problems. > > Scott > > > On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin < > Johannes.Schindelin at gmx.de> wrote: > >> Hi, >> >> On Tue, 30 Jul 2013, David Holmes wrote: >> >>> On 30/07/2013 5:54 AM, Brent Christian wrote: >>>> On 7/28/13 10:13 PM, David Holmes wrote: >>>>> On 27/07/2013 3:53 AM, Brent Christian wrote: >>>>>> Please review my fix for 8011194 : "Apps launched via >> double-clicked >>>>>> .jars have file.encoding value of US-ASCII on Mac OS X" >>>>>> >>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011194 >>>>>> >>>>>> In most cases of launching a Java app on Mac (from the cmdline, or >>>>>> from a native .app bundle), reading and displaying UTF-8 >>>>>> characters beyond the standard ASCII range works fine. >>>>>> >>>>>> A notable exception is the launching of an app by double-clicking >>>>>> a .jar file. In this case, file.encoding defaults to US-ASCII, >>>>>> and characters outside of the ASCII range show up as garbage. >>>>> >>>>> Why does this occur? What sets the encoding to US-ASCII? >>>> >>>> "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no >>>> values for LANG/LC* are set in the environment when double-clicking a >>>> .jar. >>>> >>>> We get "UTF-8" when launching from the command line because the >>>> default Terminal.app setup on Mac will setup LANG for you (to >>>> "en_US.UTF-8" in the US). >>> >>> Sounds like a user environment error to me. This isn't my area but I'm >>> not convinced we should be second guessing what we think the encoding >>> should be. >> >> Except that that is not the case here, of course. The user did *not* set >> any environment variable in this case. >> >> So we are not talking about "second guessing" or "user environment error" >> but about a sensible default. >> >> As to US-ASCII, sorry to say: the seventies called and want their >> character set back. >> >> There can be no question that UTF-8 is the best default character >> encoding, or are you even going to question *that*? >> >>> What if someone intends for it to be US-ASCII? >> >> Then LANG would not be unset, would it. >> >> Hth, >> Johannes >> > From swingler at apple.com Tue Jul 30 15:53:30 2013 From: swingler at apple.com (Mike Swingler) Date: Tue, 30 Jul 2013 15:53:30 -0700 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: <8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org> References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> <51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com> <8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org> Message-ID: <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com> Apple is highly unlikely to change the behavior of nl_langinfo(). There is already code in the JDK that calls into JRSCopyPrimaryLanguage(), JRSCopyCanonicalLanguageForPrimaryLanguage(), and JRSSetDefaultLocalization() for exactly this purpose. Please proceed with setting the encoding to UTF-8. It is the de-facto standard for every Cocoa application I have ever seen. US-ASCII is always the wrong choice for a graphical app on OS X. Regards, Mike Swingler Apple Inc. On Jul 30, 2013, at 9:05 AM, Francis Devereux wrote: > I suspect that Apple might be unlikely to change the value that nl_langinfo returns when LANG is unset. > > However, it might be possible to fix this issue without second-guessing the character set reported by the OS by calling [NSLocale currentLocale] (or the CFLocale equivalent) instead of nl_langinfo. I think (although I haven't checked) that that [NSLocale currentLocale] determines the current locale using a mechanism other than environment variables, because LANG is usually be unset for GUI apps on OS X. > > On 30 Jul 2013, at 15:56, Scott Palmer wrote: > >> Then shouldn't you be complaining to Apple that the value returned by >> nl_langinfo needs to be changed? >> David's point seems to be that second guessing the character set reported >> by the OS is likely to cause a different set of problems. >> >> Scott >> >> >> On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin < >> Johannes.Schindelin at gmx.de> wrote: >> >>> Hi, >>> >>> On Tue, 30 Jul 2013, David Holmes wrote: >>> >>>> On 30/07/2013 5:54 AM, Brent Christian wrote: >>>>> On 7/28/13 10:13 PM, David Holmes wrote: >>>>>> On 27/07/2013 3:53 AM, Brent Christian wrote: >>>>>>> Please review my fix for 8011194 : "Apps launched via >>> double-clicked >>>>>>> .jars have file.encoding value of US-ASCII on Mac OS X" >>>>>>> >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011194 >>>>>>> >>>>>>> In most cases of launching a Java app on Mac (from the cmdline, or >>>>>>> from a native .app bundle), reading and displaying UTF-8 >>>>>>> characters beyond the standard ASCII range works fine. >>>>>>> >>>>>>> A notable exception is the launching of an app by double-clicking >>>>>>> a .jar file. In this case, file.encoding defaults to US-ASCII, >>>>>>> and characters outside of the ASCII range show up as garbage. >>>>>> >>>>>> Why does this occur? What sets the encoding to US-ASCII? >>>>> >>>>> "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no >>>>> values for LANG/LC* are set in the environment when double-clicking a >>>>> .jar. >>>>> >>>>> We get "UTF-8" when launching from the command line because the >>>>> default Terminal.app setup on Mac will setup LANG for you (to >>>>> "en_US.UTF-8" in the US). >>>> >>>> Sounds like a user environment error to me. This isn't my area but I'm >>>> not convinced we should be second guessing what we think the encoding >>>> should be. >>> >>> Except that that is not the case here, of course. The user did *not* set >>> any environment variable in this case. >>> >>> So we are not talking about "second guessing" or "user environment error" >>> but about a sensible default. >>> >>> As to US-ASCII, sorry to say: the seventies called and want their >>> character set back. >>> >>> There can be no question that UTF-8 is the best default character >>> encoding, or are you even going to question *that*? >>> >>>> What if someone intends for it to be US-ASCII? >>> >>> Then LANG would not be unset, would it. >>> >>> Hth, >>> Johannes >>> >> > From david.dehaven at oracle.com Tue Jul 30 16:06:42 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 30 Jul 2013 16:06:42 -0700 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com> References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> <51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com> <8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org> <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com> Message-ID: I was about to chime in that UTF-8 has been the preferred encoding for (stored) text on Mac OS X as long as I've been hacking on it (think "Rhapsody"), so why is this even an issue? Judging from the docs, nl_langinfo seems like a Unix portability function (something more likely to be happier with ASCII in a terminal), not something to be used by a native Cocoa application. Set it to UTF-8 and forget about it -DrD- > Apple is highly unlikely to change the behavior of nl_langinfo(). > > There is already code in the JDK that calls into JRSCopyPrimaryLanguage(), JRSCopyCanonicalLanguageForPrimaryLanguage(), and JRSSetDefaultLocalization() for exactly this purpose. > > Please proceed with setting the encoding to UTF-8. It is the de-facto standard for every Cocoa application I have ever seen. US-ASCII is always the wrong choice for a graphical app on OS X. > > Regards, > Mike Swingler > Apple Inc. > > On Jul 30, 2013, at 9:05 AM, Francis Devereux wrote: > >> I suspect that Apple might be unlikely to change the value that nl_langinfo returns when LANG is unset. >> >> However, it might be possible to fix this issue without second-guessing the character set reported by the OS by calling [NSLocale currentLocale] (or the CFLocale equivalent) instead of nl_langinfo. I think (although I haven't checked) that that [NSLocale currentLocale] determines the current locale using a mechanism other than environment variables, because LANG is usually be unset for GUI apps on OS X. >> >> On 30 Jul 2013, at 15:56, Scott Palmer wrote: >> >>> Then shouldn't you be complaining to Apple that the value returned by >>> nl_langinfo needs to be changed? >>> David's point seems to be that second guessing the character set reported >>> by the OS is likely to cause a different set of problems. >>> >>> Scott >>> >>> >>> On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin < >>> Johannes.Schindelin at gmx.de> wrote: >>> >>>> Hi, >>>> >>>> On Tue, 30 Jul 2013, David Holmes wrote: >>>> >>>>> On 30/07/2013 5:54 AM, Brent Christian wrote: >>>>>> On 7/28/13 10:13 PM, David Holmes wrote: >>>>>>> On 27/07/2013 3:53 AM, Brent Christian wrote: >>>>>>>> Please review my fix for 8011194 : "Apps launched via >>>> double-clicked >>>>>>>> .jars have file.encoding value of US-ASCII on Mac OS X" >>>>>>>> >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011194 >>>>>>>> >>>>>>>> In most cases of launching a Java app on Mac (from the cmdline, or >>>>>>>> from a native .app bundle), reading and displaying UTF-8 >>>>>>>> characters beyond the standard ASCII range works fine. >>>>>>>> >>>>>>>> A notable exception is the launching of an app by double-clicking >>>>>>>> a .jar file. In this case, file.encoding defaults to US-ASCII, >>>>>>>> and characters outside of the ASCII range show up as garbage. >>>>>>> >>>>>>> Why does this occur? What sets the encoding to US-ASCII? >>>>>> >>>>>> "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no >>>>>> values for LANG/LC* are set in the environment when double-clicking a >>>>>> .jar. >>>>>> >>>>>> We get "UTF-8" when launching from the command line because the >>>>>> default Terminal.app setup on Mac will setup LANG for you (to >>>>>> "en_US.UTF-8" in the US). >>>>> >>>>> Sounds like a user environment error to me. This isn't my area but I'm >>>>> not convinced we should be second guessing what we think the encoding >>>>> should be. >>>> >>>> Except that that is not the case here, of course. The user did *not* set >>>> any environment variable in this case. >>>> >>>> So we are not talking about "second guessing" or "user environment error" >>>> but about a sensible default. >>>> >>>> As to US-ASCII, sorry to say: the seventies called and want their >>>> character set back. >>>> >>>> There can be no question that UTF-8 is the best default character >>>> encoding, or are you even going to question *that*? >>>> >>>>> What if someone intends for it to be US-ASCII? >>>> >>>> Then LANG would not be unset, would it. >>>> >>>> Hth, >>>> Johannes >>>> >>> >> > From naoto.sato at oracle.com Tue Jul 30 16:28:40 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 30 Jul 2013 16:28:40 -0700 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> <51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com> <8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org> <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com> Message-ID: <51F84C28.3050209@oracle.com> On 7/30/13 4:06 PM, David DeHaven wrote: > > I was about to chime in that UTF-8 has been the preferred encoding for (stored) text on Mac OS X as long as I've been hacking on it (think "Rhapsody"), so why is this even an issue? > > Judging from the docs, nl_langinfo seems like a Unix portability function (something more likely to be happier with ASCII in a terminal), not something to be used by a native Cocoa application. > > > > Set it to UTF-8 and forget about it > +1. Yet another reasoning is that UTF-8 is backward compatible with ASCII, i.e., exact same mapping for 0x0000-0x007F code points. Naoto > > -DrD- > >> Apple is highly unlikely to change the behavior of nl_langinfo(). >> >> There is already code in the JDK that calls into JRSCopyPrimaryLanguage(), JRSCopyCanonicalLanguageForPrimaryLanguage(), and JRSSetDefaultLocalization() for exactly this purpose. >> >> Please proceed with setting the encoding to UTF-8. It is the de-facto standard for every Cocoa application I have ever seen. US-ASCII is always the wrong choice for a graphical app on OS X. >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On Jul 30, 2013, at 9:05 AM, Francis Devereux wrote: >> >>> I suspect that Apple might be unlikely to change the value that nl_langinfo returns when LANG is unset. >>> >>> However, it might be possible to fix this issue without second-guessing the character set reported by the OS by calling [NSLocale currentLocale] (or the CFLocale equivalent) instead of nl_langinfo. I think (although I haven't checked) that that [NSLocale currentLocale] determines the current locale using a mechanism other than environment variables, because LANG is usually be unset for GUI apps on OS X. >>> >>> On 30 Jul 2013, at 15:56, Scott Palmer wrote: >>> >>>> Then shouldn't you be complaining to Apple that the value returned by >>>> nl_langinfo needs to be changed? >>>> David's point seems to be that second guessing the character set reported >>>> by the OS is likely to cause a different set of problems. >>>> >>>> Scott >>>> >>>> >>>> On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin < >>>> Johannes.Schindelin at gmx.de> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Tue, 30 Jul 2013, David Holmes wrote: >>>>> >>>>>> On 30/07/2013 5:54 AM, Brent Christian wrote: >>>>>>> On 7/28/13 10:13 PM, David Holmes wrote: >>>>>>>> On 27/07/2013 3:53 AM, Brent Christian wrote: >>>>>>>>> Please review my fix for 8011194 : "Apps launched via >>>>> double-clicked >>>>>>>>> .jars have file.encoding value of US-ASCII on Mac OS X" >>>>>>>>> >>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011194 >>>>>>>>> >>>>>>>>> In most cases of launching a Java app on Mac (from the cmdline, or >>>>>>>>> from a native .app bundle), reading and displaying UTF-8 >>>>>>>>> characters beyond the standard ASCII range works fine. >>>>>>>>> >>>>>>>>> A notable exception is the launching of an app by double-clicking >>>>>>>>> a .jar file. In this case, file.encoding defaults to US-ASCII, >>>>>>>>> and characters outside of the ASCII range show up as garbage. >>>>>>>> >>>>>>>> Why does this occur? What sets the encoding to US-ASCII? >>>>>>> >>>>>>> "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no >>>>>>> values for LANG/LC* are set in the environment when double-clicking a >>>>>>> .jar. >>>>>>> >>>>>>> We get "UTF-8" when launching from the command line because the >>>>>>> default Terminal.app setup on Mac will setup LANG for you (to >>>>>>> "en_US.UTF-8" in the US). >>>>>> >>>>>> Sounds like a user environment error to me. This isn't my area but I'm >>>>>> not convinced we should be second guessing what we think the encoding >>>>>> should be. >>>>> >>>>> Except that that is not the case here, of course. The user did *not* set >>>>> any environment variable in this case. >>>>> >>>>> So we are not talking about "second guessing" or "user environment error" >>>>> but about a sensible default. >>>>> >>>>> As to US-ASCII, sorry to say: the seventies called and want their >>>>> character set back. >>>>> >>>>> There can be no question that UTF-8 is the best default character >>>>> encoding, or are you even going to question *that*? >>>>> >>>>>> What if someone intends for it to be US-ASCII? >>>>> >>>>> Then LANG would not be unset, would it. >>>>> >>>>> Hth, >>>>> Johannes >>>>> >>>> >>> >> > From david.holmes at oracle.com Tue Jul 30 20:12:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 31 Jul 2013 13:12:38 +1000 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com> References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> <51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com> <8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org> <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com> Message-ID: <51F880A6.3070207@oracle.com> If Mike endorses this approach then I step aside. My point, as Scott noted, is that we get this info from the OS. So either the OS is at fault or we're asking the wrong question. Based on Mike's response we're asking the wrong question - but if the end result will be UTF-8 regardless then fine. David On 31/07/2013 8:53 AM, Mike Swingler wrote: > Apple is highly unlikely to change the behavior of nl_langinfo(). > > There is already code in the JDK that calls into JRSCopyPrimaryLanguage(), JRSCopyCanonicalLanguageForPrimaryLanguage(), and JRSSetDefaultLocalization() for exactly this purpose. > > Please proceed with setting the encoding to UTF-8. It is the de-facto standard for every Cocoa application I have ever seen. US-ASCII is always the wrong choice for a graphical app on OS X. > > Regards, > Mike Swingler > Apple Inc. > > On Jul 30, 2013, at 9:05 AM, Francis Devereux wrote: > >> I suspect that Apple might be unlikely to change the value that nl_langinfo returns when LANG is unset. >> >> However, it might be possible to fix this issue without second-guessing the character set reported by the OS by calling [NSLocale currentLocale] (or the CFLocale equivalent) instead of nl_langinfo. I think (although I haven't checked) that that [NSLocale currentLocale] determines the current locale using a mechanism other than environment variables, because LANG is usually be unset for GUI apps on OS X. >> >> On 30 Jul 2013, at 15:56, Scott Palmer wrote: >> >>> Then shouldn't you be complaining to Apple that the value returned by >>> nl_langinfo needs to be changed? >>> David's point seems to be that second guessing the character set reported >>> by the OS is likely to cause a different set of problems. >>> >>> Scott >>> >>> >>> On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin < >>> Johannes.Schindelin at gmx.de> wrote: >>> >>>> Hi, >>>> >>>> On Tue, 30 Jul 2013, David Holmes wrote: >>>> >>>>> On 30/07/2013 5:54 AM, Brent Christian wrote: >>>>>> On 7/28/13 10:13 PM, David Holmes wrote: >>>>>>> On 27/07/2013 3:53 AM, Brent Christian wrote: >>>>>>>> Please review my fix for 8011194 : "Apps launched via >>>> double-clicked >>>>>>>> .jars have file.encoding value of US-ASCII on Mac OS X" >>>>>>>> >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011194 >>>>>>>> >>>>>>>> In most cases of launching a Java app on Mac (from the cmdline, or >>>>>>>> from a native .app bundle), reading and displaying UTF-8 >>>>>>>> characters beyond the standard ASCII range works fine. >>>>>>>> >>>>>>>> A notable exception is the launching of an app by double-clicking >>>>>>>> a .jar file. In this case, file.encoding defaults to US-ASCII, >>>>>>>> and characters outside of the ASCII range show up as garbage. >>>>>>> >>>>>>> Why does this occur? What sets the encoding to US-ASCII? >>>>>> >>>>>> "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no >>>>>> values for LANG/LC* are set in the environment when double-clicking a >>>>>> .jar. >>>>>> >>>>>> We get "UTF-8" when launching from the command line because the >>>>>> default Terminal.app setup on Mac will setup LANG for you (to >>>>>> "en_US.UTF-8" in the US). >>>>> >>>>> Sounds like a user environment error to me. This isn't my area but I'm >>>>> not convinced we should be second guessing what we think the encoding >>>>> should be. >>>> >>>> Except that that is not the case here, of course. The user did *not* set >>>> any environment variable in this case. >>>> >>>> So we are not talking about "second guessing" or "user environment error" >>>> but about a sensible default. >>>> >>>> As to US-ASCII, sorry to say: the seventies called and want their >>>> character set back. >>>> >>>> There can be no question that UTF-8 is the best default character >>>> encoding, or are you even going to question *that*? >>>> >>>>> What if someone intends for it to be US-ASCII? >>>> >>>> Then LANG would not be unset, would it. >>>> >>>> Hth, >>>> Johannes >>>> >>> >> > From Fabrizio.Giudici at tidalwave.it Wed Jul 31 06:03:58 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Wed, 31 Jul 2013 15:03:58 +0200 Subject: JDK 1.7.0_25: apps launched via double click .app with incorrect file.encoding=US-ASCII Message-ID: This sounds to be a similar issue to "Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X": that discussion actually helped me in sorting out the problem. In short, I have a Mac OS X .app which is created with an embedded JRE. When launched by means of "open .../App.app" by terminal all is fine. I suppose this happens because I have in my termnal env: LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 When launched by double-clicking on the icon, the file.encoding is set to US-ASCII and problems happen. This happens with JDK 1.7.0_25. I can provide more info and code if needed. Is it a problem with JDK 1.7.0_25? With my Info.plist? Or something else? How should I quickly fix the problem? Setting file.encoding and sun.jnu.encoding to UTF-8 in the Info.plist? Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From brent.christian at oracle.com Wed Jul 31 13:43:46 2013 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 31 Jul 2013 13:43:46 -0700 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> <51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com> <8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org> <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com> Message-ID: <51F97702.5090203@oracle.com> On 7/30/13 4:06 PM, David DeHaven wrote: > > Judging from the docs, nl_langinfo seems like a Unix portability > function (something more likely to be happier with ASCII in a > terminal), not something to be used by a native Cocoa application. Exactly - so I think it expects to be called from a cmdline with a shell-style surrounding environment, with LANG/etc variables set. David suggests that calling nl_langinfo() is "asking the wrong question." In the particular context of double-click launching on Mac, you could say that's true (or at least asking the question in the wrong way). But consider - the code in question is shared with other Unix platforms, and when running from the cmdline/shell scripts/etc, nl_langinfo() *is* the right way to ask the question. To ask the right question for this specific context on MacOS X (NSLocale or CFLocale) I suspect would involve a fair amount of code surgery, and the end result would be the same. Given this, I think my proposed change is a good one from a practical standpoint. Thank you, everyone, for your feedback. -Brent >> Apple is highly unlikely to change the behavior of nl_langinfo(). >> >> There is already code in the JDK that calls into JRSCopyPrimaryLanguage(), JRSCopyCanonicalLanguageForPrimaryLanguage(), and JRSSetDefaultLocalization() for exactly this purpose. >> >> Please proceed with setting the encoding to UTF-8. It is the de-facto standard for every Cocoa application I have ever seen. US-ASCII is always the wrong choice for a graphical app on OS X. >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On Jul 30, 2013, at 9:05 AM, Francis Devereux wrote: >> >>> I suspect that Apple might be unlikely to change the value that nl_langinfo returns when LANG is unset. >>> >>> However, it might be possible to fix this issue without second-guessing the character set reported by the OS by calling [NSLocale currentLocale] (or the CFLocale equivalent) instead of nl_langinfo. I think (although I haven't checked) that that [NSLocale currentLocale] determines the current locale using a mechanism other than environment variables, because LANG is usually be unset for GUI apps on OS X. >>> >>> On 30 Jul 2013, at 15:56, Scott Palmer wrote: >>> >>>> Then shouldn't you be complaining to Apple that the value returned by >>>> nl_langinfo needs to be changed? >>>> David's point seems to be that second guessing the character set reported >>>> by the OS is likely to cause a different set of problems. >>>> >>>> Scott >>>> >>>> >>>> On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin < >>>> Johannes.Schindelin at gmx.de> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Tue, 30 Jul 2013, David Holmes wrote: >>>>> >>>>>> On 30/07/2013 5:54 AM, Brent Christian wrote: >>>>>>> On 7/28/13 10:13 PM, David Holmes wrote: >>>>>>>> On 27/07/2013 3:53 AM, Brent Christian wrote: >>>>>>>>> Please review my fix for 8011194 : "Apps launched via >>>>> double-clicked >>>>>>>>> .jars have file.encoding value of US-ASCII on Mac OS X" >>>>>>>>> >>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8011194 >>>>>>>>> >>>>>>>>> In most cases of launching a Java app on Mac (from the cmdline, or >>>>>>>>> from a native .app bundle), reading and displaying UTF-8 >>>>>>>>> characters beyond the standard ASCII range works fine. >>>>>>>>> >>>>>>>>> A notable exception is the launching of an app by double-clicking >>>>>>>>> a .jar file. In this case, file.encoding defaults to US-ASCII, >>>>>>>>> and characters outside of the ASCII range show up as garbage. >>>>>>>> >>>>>>>> Why does this occur? What sets the encoding to US-ASCII? >>>>>>> >>>>>>> "US-ASCII" is the answer we get from nl_langinfo(CODESET) because no >>>>>>> values for LANG/LC* are set in the environment when double-clicking a >>>>>>> .jar. >>>>>>> >>>>>>> We get "UTF-8" when launching from the command line because the >>>>>>> default Terminal.app setup on Mac will setup LANG for you (to >>>>>>> "en_US.UTF-8" in the US). >>>>>> >>>>>> Sounds like a user environment error to me. This isn't my area but I'm >>>>>> not convinced we should be second guessing what we think the encoding >>>>>> should be. >>>>> >>>>> Except that that is not the case here, of course. The user did *not* set >>>>> any environment variable in this case. >>>>> >>>>> So we are not talking about "second guessing" or "user environment error" >>>>> but about a sensible default. >>>>> >>>>> As to US-ASCII, sorry to say: the seventies called and want their >>>>> character set back. >>>>> >>>>> There can be no question that UTF-8 is the best default character >>>>> encoding, or are you even going to question *that*? >>>>> >>>>>> What if someone intends for it to be US-ASCII? >>>>> >>>>> Then LANG would not be unset, would it. >>>>> >>>>> Hth, >>>>> Johannes >>>>> >>>> >>> >> > From mik3hall at gmail.com Wed Jul 31 19:52:39 2013 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 31 Jul 2013 21:52:39 -0500 Subject: JDK 1.7.0_25: apps launched via double click .app with incorrect file.encoding=US-ASCII In-Reply-To: References: Message-ID: <190B6D6C-EB43-4323-9B8F-9D8E6C312262@gmail.com> On Jul 31, 2013, at 8:03 AM, Fabrizio Giudici wrote: > Is it a problem with JDK 1.7.0_25? With my Info.plist? Or something else? How should I quickly fix the problem? Setting file.encoding and sun.jnu.encoding to UTF-8 in the Info.plist? LSEnvrionment to set the environment variables should be an option too in the info.plist. Not finding a real good documentation link at the moment though. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter