From james.velasco at int.com Tue Oct 1 16:10:56 2013 From: james.velasco at int.com (James Velasco) Date: Tue, 01 Oct 2013 18:10:56 -0500 Subject: Mac OS X Applet DND bug (related to JDK-8020371) Message-ID: <524B5680.7060303@int.com> As per my discussion last week with Dalibor @ JavaOne last week, I was told to post any information I have about DND failing within an applet on Mac OS X to this group. I get the following exception whenever a DND operation is performed, only on Mac OS X: Exception in thread "AWT-EventQueue-2" java.awt.dnd.InvalidDnDOperationException: failed to create native peer: java.awt.dnd.InvalidDnDOperationException: Unsupported platform window implementation at sun.lwawt.macosx.CDragSourceContextPeer.startDrag(CDragSourceContextPeer.java:154) at sun.awt.dnd.SunDragSourceContextPeer.startDrag(SunDragSourceContextPeer.java:135) at sun.lwawt.macosx.CDragSourceContextPeer.startDrag(CDragSourceContextPeer.java:88) at java.awt.dnd.DragSource.startDrag(DragSource.java:321) This has occurred with 1.8.0-ea-b108 and all of the previous 1.7 and 1.8 builds I have tested. Since a signed applet is required to test this out, I have one built and hosted to demonstrate this at http://demo.int.com/dnddropbug/. I can send you the full source code (less our code signing cert !), or post it somewhere if you need it. Feel free to follow up with me on this, James Velasco -- James Velasco Chief Computer Scientist INT, INC, 2901 Wilcrest, Suite 300, Houston, TX 77042 E-mail: james.velasco at int.com Tel: (713) 975-7434 Fax: (713) 975-1120 From mik3hall at gmail.com Tue Oct 1 16:21:36 2013 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 1 Oct 2013 18:21:36 -0500 Subject: Mac OS X Applet DND bug (related to JDK-8020371) In-Reply-To: <524B5680.7060303@int.com> References: <524B5680.7060303@int.com> Message-ID: <40B3C5B4-5CDD-4572-9F96-574B46D445C7@gmail.com> On Oct 1, 2013, at 6:10 PM, James Velasco wrote: > As per my discussion last week with Dalibor @ JavaOne last week, I was told to post any information I have about > DND failing within an applet on Mac OS X to this group. Not sure this is the most up to date information but? Re: Drag-and-drop on applet broken in Safari 5.1 http://lists.apple.com/archives/java-dev/2011/Jul/msg00083.html 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 james.velasco at int.com Wed Oct 2 11:37:06 2013 From: james.velasco at int.com (James Velasco) Date: Wed, 02 Oct 2013 13:37:06 -0500 Subject: Mac OS X Applet DND bug (related to JDK-8020371) References: 524B5680.7060303@int.com Message-ID: <524C67D2.4070604@int.com> Michael, Thanks for the info (http://lists.apple.com/archives/java-dev/2011/Jul/msg00083.html), however it is quite out of date since the "detach an applet" trick from the browser has been broken with the Oracle JDK 7 for quite a while (https://www.java.net//forum/topic/jdk/java-se/os-x-108-java-7-applet-exception-dragstart?force=653) , and is currently open per the new JDK bug DB ( https://bugs.openjdk.java.net/browse/JDK-8013363 ), even though it's just a workaround to get the real issue, broken DND in applets working. I have been following this issue on and off, but we now have customer who needs this to work on Macs, and so I brought it up with some of the Oracle guys at last week's java one. There was an attempt to fix it as shown in the subversion code related to the JDK bug (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020371) from the old bug DB which does not really address the general DND issues related to applets on the mac. From mik3hall at gmail.com Wed Oct 2 15:46:09 2013 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 2 Oct 2013 17:46:09 -0500 Subject: Mac OS X Applet DND bug (related to JDK-8020371) In-Reply-To: <524C67D2.4070604@int.com> References: 524B5680.7060303@int.com <524C67D2.4070604@int.com> Message-ID: On Oct 2, 2013, at 1:37 PM, James Velasco wrote: > > > I have been following this issue on and off, but we now have customer who needs this to work on Macs, and so I brought it up with > some of the Oracle guys at last week's java one. There was an attempt to fix it as shown in the subversion code related to the JDK bug (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020371) from the old bug DB which does not really address the general DND issues related to applets on the mac. I sort of remembered there had been something else on this but sent the link I came up with. Rechecking I also came up with this one? Populating applet text components http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-November/005183.html Which actually was in response to one of mine. Trying to drag and drop text into an applet not working. The response there indicates changes required in the browsers which Scott Kovatch didn't seem to think likely. Still not exactly the answer I thought I remembered but another informed answer anyhow. This google search also turned up this Bug 588455 - Drag and drop onto Java applet not working https://bugzilla.mozilla.org/show_bug.cgi?id=588455 So maybe this will work Firefox at some point. I think one thing I had found was that this functionality would work with appletviewer. Maybe not a nice solution but if your customer really needs to run this applet and has to have drag and drop it might be a work around? 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 > Michael, > > Thanks for the info (http://lists.apple.com/archives/java-dev/2011/Jul/msg00083.html), > however it is quite out of date since the "detach an applet" trick from the browser has been broken > with the Oracle JDK 7 for quite a while (https://www.java.net//forum/topic/jdk/java-se/os-x-108-java-7-applet-exception-dragstart?force=653) , > and is currently open per the new JDK bug DB ( https://bugs.openjdk.java.net/browse/JDK-8013363 ), even though it's just a workaround to get the real issue, > broken DND in applets working. From christopherbrown06 at gmail.com Sat Oct 12 14:00:50 2013 From: christopherbrown06 at gmail.com (Christopher Brown) Date: Sat, 12 Oct 2013 23:00:50 +0200 Subject: JMX / JConsole regression with Attach API using Java 7u40 ? Message-ID: Hello, When I start an application, using Apple Java 1.6.0_51 (with "java -jar application.jar" and no "-D" parameters), I can connect to it using JConsole, using either the Apple Java 6 version or the Oracle Java 7 version. The application registers some MXBeans using the PlatformMBeanServer. Now, when I start that same application, using Oracle Java 1.7.0_40, in the same way, it is still visible using the Java 7 JConsole under "local processes", however connection using JConsole and VisualVM fails. Running JConsole with the "-debug" option, the following stacktrace is displayed when JConsole fails to connect: java.io.IOException: Unable to open socket file: target process not responding or HotSpot VM not loaded at sun.tools.jconsole.LocalVirtualMachine.loadManagementAgent(LocalVirtualMachine.java:238) at sun.tools.jconsole.LocalVirtualMachine.startManagementAgent(LocalVirtualMachine.java:100) at sun.tools.jconsole.ProxyClient.tryConnect(ProxyClient.java:333) at sun.tools.jconsole.ProxyClient.connect(ProxyClient.java:313) at sun.tools.jconsole.VMPanel$2.run(VMPanel.java:292) Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded at sun.tools.attach.BsdVirtualMachine.(BsdVirtualMachine.java:90) at sun.tools.attach.BsdAttachProvider.attachVirtualMachine(BsdAttachProvider.java:63) at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:213) at sun.tools.jconsole.LocalVirtualMachine.loadManagementAgent(LocalVirtualMachine.java:236) ... 4 more JConsole displays the dialog "ConnectionFailedSSL1" and "ConnectionFailedSSL2", with [Cancel] and [Insecure] options. If I click "insecure", it fails in exactly the same with. For a development environment, how can I get things working again so that it "just works" (Oracle Java 7 VM and Java 7 JConsole) ? Thanks, Christopher From matt at thebishops.org Sun Oct 13 12:04:49 2013 From: matt at thebishops.org (Matthew Bishop) Date: Sun, 13 Oct 2013 12:04:49 -0700 Subject: JMX local attach failure Message-ID: >When I start an application, using Apple Java 1.6.0_51 (with "java -jar application.jar" and no "-D" parameters), I can connect to it using JConsole, using either the Apple Java 6 version or the Oracle Java 7 version. The application registers some MXBeans using the PlatformMBeanServer. >Now, when I start that same application, using Oracle Java 1.7.0_40, in the same way, it is still visible using the Java 7 JConsole under "local processes", however connection using JConsole and VisualVM fails. I get this under JDK 1.7.0_25 as well. On three different machines. From staffan.larsen at oracle.com Mon Oct 14 00:58:35 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 14 Oct 2013 09:58:35 +0200 Subject: JMX / JConsole regression with Attach API using Java 7u40 ? In-Reply-To: References: Message-ID: <8D013455-1477-437F-AB43-6C9EDC404544@oracle.com> The ConnectionFailedSSL1 and ConnectionFailedSSL2 messages should read: Secure connection failed. Retry insecurely? The connection to {0} could not be made using SSL. Would you like to try without SSL? (Username and password will be sent in plain text.) Pressing 'Insecure' will then connect without SSL. But form the stack trace you provide this does not look like the problem you are running into. Can try deleting all files called .attach_pidXXX and .java_pidXXX in your $TMPDIR? Also make sure jconsole and java are launched as the same user. Thanks, /Staffan On 12 okt 2013, at 23:00, Christopher Brown wrote: > Hello, > > When I start an application, using Apple Java 1.6.0_51 (with "java -jar > application.jar" and no "-D" parameters), I can connect to it using > JConsole, using either the Apple Java 6 version or the Oracle Java 7 > version. The application registers some MXBeans using the > PlatformMBeanServer. > > Now, when I start that same application, using Oracle Java 1.7.0_40, in the > same way, it is still visible using the Java 7 JConsole under "local > processes", however connection using JConsole and VisualVM fails. > > Running JConsole with the "-debug" option, the following stacktrace is > displayed when JConsole fails to connect: > > java.io.IOException: Unable to open socket file: target process not > responding or HotSpot VM not loaded > at > sun.tools.jconsole.LocalVirtualMachine.loadManagementAgent(LocalVirtualMachine.java:238) > at > sun.tools.jconsole.LocalVirtualMachine.startManagementAgent(LocalVirtualMachine.java:100) > at sun.tools.jconsole.ProxyClient.tryConnect(ProxyClient.java:333) > at sun.tools.jconsole.ProxyClient.connect(ProxyClient.java:313) > at sun.tools.jconsole.VMPanel$2.run(VMPanel.java:292) > Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open > socket file: target process not responding or HotSpot VM not loaded > at sun.tools.attach.BsdVirtualMachine.(BsdVirtualMachine.java:90) > at > sun.tools.attach.BsdAttachProvider.attachVirtualMachine(BsdAttachProvider.java:63) > at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:213) > at > sun.tools.jconsole.LocalVirtualMachine.loadManagementAgent(LocalVirtualMachine.java:236) > ... 4 more > > JConsole displays the dialog "ConnectionFailedSSL1" and > "ConnectionFailedSSL2", with [Cancel] and [Insecure] options. If I click > "insecure", it fails in exactly the same with. > > For a development environment, how can I get things working again so that > it "just works" (Oracle Java 7 VM and Java 7 JConsole) ? > > Thanks, > Christopher From staffan.larsen at oracle.com Mon Oct 14 01:19:04 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 14 Oct 2013 10:19:04 +0200 Subject: JMX / JConsole regression with Attach API using Java 7u40 ? In-Reply-To: <8D013455-1477-437F-AB43-6C9EDC404544@oracle.com> References: <8D013455-1477-437F-AB43-6C9EDC404544@oracle.com> Message-ID: Taking another look, I think this is the same problem as reported in: http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011318.html The bug report is at: https://bugs.openjdk.java.net/browse/JDK-8023786 A workaround may be to run the application with -Xverify:none until an update of JDK7 fixes this. Thanks, /Staffan On 14 okt 2013, at 09:58, Staffan Larsen wrote: > The ConnectionFailedSSL1 and ConnectionFailedSSL2 messages should read: > > Secure connection failed. Retry insecurely? > The connection to {0} could not be made using SSL. > Would you like to try without SSL? > (Username and password will be sent in plain text.) > > Pressing 'Insecure' will then connect without SSL. > > But form the stack trace you provide this does not look like the problem you are running into. Can try deleting all files called .attach_pidXXX and .java_pidXXX in your $TMPDIR? Also make sure jconsole and java are launched as the same user. > > Thanks, > /Staffan > > On 12 okt 2013, at 23:00, Christopher Brown wrote: > >> Hello, >> >> When I start an application, using Apple Java 1.6.0_51 (with "java -jar >> application.jar" and no "-D" parameters), I can connect to it using >> JConsole, using either the Apple Java 6 version or the Oracle Java 7 >> version. The application registers some MXBeans using the >> PlatformMBeanServer. >> >> Now, when I start that same application, using Oracle Java 1.7.0_40, in the >> same way, it is still visible using the Java 7 JConsole under "local >> processes", however connection using JConsole and VisualVM fails. >> >> Running JConsole with the "-debug" option, the following stacktrace is >> displayed when JConsole fails to connect: >> >> java.io.IOException: Unable to open socket file: target process not >> responding or HotSpot VM not loaded >> at >> sun.tools.jconsole.LocalVirtualMachine.loadManagementAgent(LocalVirtualMachine.java:238) >> at >> sun.tools.jconsole.LocalVirtualMachine.startManagementAgent(LocalVirtualMachine.java:100) >> at sun.tools.jconsole.ProxyClient.tryConnect(ProxyClient.java:333) >> at sun.tools.jconsole.ProxyClient.connect(ProxyClient.java:313) >> at sun.tools.jconsole.VMPanel$2.run(VMPanel.java:292) >> Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open >> socket file: target process not responding or HotSpot VM not loaded >> at sun.tools.attach.BsdVirtualMachine.(BsdVirtualMachine.java:90) >> at >> sun.tools.attach.BsdAttachProvider.attachVirtualMachine(BsdAttachProvider.java:63) >> at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:213) >> at >> sun.tools.jconsole.LocalVirtualMachine.loadManagementAgent(LocalVirtualMachine.java:236) >> ... 4 more >> >> JConsole displays the dialog "ConnectionFailedSSL1" and >> "ConnectionFailedSSL2", with [Cancel] and [Insecure] options. If I click >> "insecure", it fails in exactly the same with. >> >> For a development environment, how can I get things working again so that >> it "just works" (Oracle Java 7 VM and Java 7 JConsole) ? >> >> Thanks, >> Christopher > From staffan.larsen at oracle.com Mon Oct 14 01:50:07 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 14 Oct 2013 10:50:07 +0200 Subject: JMX / JConsole regression with Attach API using Java 7u40 ? In-Reply-To: References: <8D013455-1477-437F-AB43-6C9EDC404544@oracle.com> Message-ID: <9F793A38-944F-4A56-B334-3070A2F4C2E2@oracle.com> Another workaround (thanks Alan Bateman) is to run the application with -XX:+StartAttachListener since this avoids the need for signals. /Staffan On 14 okt 2013, at 10:19, Staffan Larsen wrote: > Taking another look, I think this is the same problem as reported in: http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011318.html > > The bug report is at: https://bugs.openjdk.java.net/browse/JDK-8023786 > > A workaround may be to run the application with -Xverify:none until an update of JDK7 fixes this. > > Thanks, > /Staffan > > > On 14 okt 2013, at 09:58, Staffan Larsen wrote: > >> The ConnectionFailedSSL1 and ConnectionFailedSSL2 messages should read: >> >> Secure connection failed. Retry insecurely? >> The connection to {0} could not be made using SSL. >> Would you like to try without SSL? >> (Username and password will be sent in plain text.) >> >> Pressing 'Insecure' will then connect without SSL. >> >> But form the stack trace you provide this does not look like the problem you are running into. Can try deleting all files called .attach_pidXXX and .java_pidXXX in your $TMPDIR? Also make sure jconsole and java are launched as the same user. >> >> Thanks, >> /Staffan >> >> On 12 okt 2013, at 23:00, Christopher Brown wrote: >> >>> Hello, >>> >>> When I start an application, using Apple Java 1.6.0_51 (with "java -jar >>> application.jar" and no "-D" parameters), I can connect to it using >>> JConsole, using either the Apple Java 6 version or the Oracle Java 7 >>> version. The application registers some MXBeans using the >>> PlatformMBeanServer. >>> >>> Now, when I start that same application, using Oracle Java 1.7.0_40, in the >>> same way, it is still visible using the Java 7 JConsole under "local >>> processes", however connection using JConsole and VisualVM fails. >>> >>> Running JConsole with the "-debug" option, the following stacktrace is >>> displayed when JConsole fails to connect: >>> >>> java.io.IOException: Unable to open socket file: target process not >>> responding or HotSpot VM not loaded >>> at >>> sun.tools.jconsole.LocalVirtualMachine.loadManagementAgent(LocalVirtualMachine.java:238) >>> at >>> sun.tools.jconsole.LocalVirtualMachine.startManagementAgent(LocalVirtualMachine.java:100) >>> at sun.tools.jconsole.ProxyClient.tryConnect(ProxyClient.java:333) >>> at sun.tools.jconsole.ProxyClient.connect(ProxyClient.java:313) >>> at sun.tools.jconsole.VMPanel$2.run(VMPanel.java:292) >>> Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open >>> socket file: target process not responding or HotSpot VM not loaded >>> at sun.tools.attach.BsdVirtualMachine.(BsdVirtualMachine.java:90) >>> at >>> sun.tools.attach.BsdAttachProvider.attachVirtualMachine(BsdAttachProvider.java:63) >>> at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:213) >>> at >>> sun.tools.jconsole.LocalVirtualMachine.loadManagementAgent(LocalVirtualMachine.java:236) >>> ... 4 more >>> >>> JConsole displays the dialog "ConnectionFailedSSL1" and >>> "ConnectionFailedSSL2", with [Cancel] and [Insecure] options. If I click >>> "insecure", it fails in exactly the same with. >>> >>> For a development environment, how can I get things working again so that >>> it "just works" (Oracle Java 7 VM and Java 7 JConsole) ? >>> >>> Thanks, >>> Christopher >> > From christopherbrown06 at gmail.com Mon Oct 14 01:56:46 2013 From: christopherbrown06 at gmail.com (Christopher Brown) Date: Mon, 14 Oct 2013 10:56:46 +0200 Subject: JMX / JConsole regression with Attach API using Java 7u40 ? In-Reply-To: <9F793A38-944F-4A56-B334-3070A2F4C2E2@oracle.com> References: <8D013455-1477-437F-AB43-6C9EDC404544@oracle.com> <9F793A38-944F-4A56-B334-3070A2F4C2E2@oracle.com> Message-ID: Hello, Thanks, the -XX:+StartAttachListener option did the trick. I'm assuming that this is a cross-platform switch, with nothing OSX-specific, and so is safe and portable for a common development environment (Ant script...) that runs on OS X, Windows, and Linux? (obviously, we wouldn't use an insecure connection outside of our developement environment!) In any case, you fast and helpful reply is much appreciated! -- Christopher On 14 October 2013 10:50, Staffan Larsen wrote: > Another workaround (thanks Alan Bateman) is to run the application with > -XX:+StartAttachListener since this avoids the need for signals. > > /Staffan > > On 14 okt 2013, at 10:19, Staffan Larsen > wrote: > > > Taking another look, I think this is the same problem as reported in: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011318.html > > > > The bug report is at: https://bugs.openjdk.java.net/browse/JDK-8023786 > > > > A workaround may be to run the application with -Xverify:none until an > update of JDK7 fixes this. > > > > Thanks, > > /Staffan > > > > > > On 14 okt 2013, at 09:58, Staffan Larsen > wrote: > > > >> The ConnectionFailedSSL1 and ConnectionFailedSSL2 messages should read: > >> > >> Secure connection failed. Retry insecurely? > >> The connection to {0} could not be made using SSL. > >> Would you like to try without SSL? > >> (Username and password will be sent in plain text.) > >> > >> Pressing 'Insecure' will then connect without SSL. > >> > >> But form the stack trace you provide this does not look like the > problem you are running into. Can try deleting all files called > .attach_pidXXX and .java_pidXXX in your $TMPDIR? Also make sure jconsole > and java are launched as the same user. > >> > >> Thanks, > >> /Staffan > >> > >> On 12 okt 2013, at 23:00, Christopher Brown < > christopherbrown06 at gmail.com> wrote: > >> > >>> Hello, > >>> > >>> When I start an application, using Apple Java 1.6.0_51 (with "java -jar > >>> application.jar" and no "-D" parameters), I can connect to it using > >>> JConsole, using either the Apple Java 6 version or the Oracle Java 7 > >>> version. The application registers some MXBeans using the > >>> PlatformMBeanServer. > >>> > >>> Now, when I start that same application, using Oracle Java 1.7.0_40, > in the > >>> same way, it is still visible using the Java 7 JConsole under "local > >>> processes", however connection using JConsole and VisualVM fails. > >>> > >>> Running JConsole with the "-debug" option, the following stacktrace is > >>> displayed when JConsole fails to connect: > >>> > >>> java.io.IOException: Unable to open socket file: target process not > >>> responding or HotSpot VM not loaded > >>> at > >>> > sun.tools.jconsole.LocalVirtualMachine.loadManagementAgent(LocalVirtualMachine.java:238) > >>> at > >>> > sun.tools.jconsole.LocalVirtualMachine.startManagementAgent(LocalVirtualMachine.java:100) > >>> at sun.tools.jconsole.ProxyClient.tryConnect(ProxyClient.java:333) > >>> at sun.tools.jconsole.ProxyClient.connect(ProxyClient.java:313) > >>> at sun.tools.jconsole.VMPanel$2.run(VMPanel.java:292) > >>> Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to > open > >>> socket file: target process not responding or HotSpot VM not loaded > >>> at > sun.tools.attach.BsdVirtualMachine.(BsdVirtualMachine.java:90) > >>> at > >>> > sun.tools.attach.BsdAttachProvider.attachVirtualMachine(BsdAttachProvider.java:63) > >>> at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:213) > >>> at > >>> > sun.tools.jconsole.LocalVirtualMachine.loadManagementAgent(LocalVirtualMachine.java:236) > >>> ... 4 more > >>> > >>> JConsole displays the dialog "ConnectionFailedSSL1" and > >>> "ConnectionFailedSSL2", with [Cancel] and [Insecure] options. If I > click > >>> "insecure", it fails in exactly the same with. > >>> > >>> For a development environment, how can I get things working again so > that > >>> it "just works" (Oracle Java 7 VM and Java 7 JConsole) ? > >>> > >>> Thanks, > >>> Christopher > >> > > > > From staffan.larsen at oracle.com Mon Oct 14 02:19:40 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 14 Oct 2013 02:19:40 -0700 (PDT) Subject: JMX / JConsole regression with Attach API using Java 7u40 ? In-Reply-To: References: <8D013455-1477-437F-AB43-6C9EDC404544@oracle.com> <9F793A38-944F-4A56-B334-3070A2F4C2E2@oracle.com> Message-ID: <6706EDA2-B014-4B8A-8B81-9E28E9CE74D9@oracle.com> On 14 okt 2013, at 10:56, Christopher Brown wrote: > Hello, > > Thanks, the -XX:+StartAttachListener option did the trick. > > I'm assuming that this is a cross-platform switch, with nothing OSX-specific, and so is safe and portable for a common development environment (Ant script...) that runs on OS X, Windows, and Linux? Yes. /Staffan > (obviously, we wouldn't use an insecure connection outside of our developement environment!) > > In any case, you fast and helpful reply is much appreciated! > > -- > Christopher > > > On 14 October 2013 10:50, Staffan Larsen wrote: > Another workaround (thanks Alan Bateman) is to run the application with -XX:+StartAttachListener since this avoids the need for signals. > > /Staffan > > On 14 okt 2013, at 10:19, Staffan Larsen wrote: > > > Taking another look, I think this is the same problem as reported in: http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011318.html > > > > The bug report is at: https://bugs.openjdk.java.net/browse/JDK-8023786 > > > > A workaround may be to run the application with -Xverify:none until an update of JDK7 fixes this. > > > > Thanks, > > /Staffan > > > > > > On 14 okt 2013, at 09:58, Staffan Larsen wrote: > > > >> The ConnectionFailedSSL1 and ConnectionFailedSSL2 messages should read: > >> > >> Secure connection failed. Retry insecurely? > >> The connection to {0} could not be made using SSL. > >> Would you like to try without SSL? > >> (Username and password will be sent in plain text.) > >> > >> Pressing 'Insecure' will then connect without SSL. > >> > >> But form the stack trace you provide this does not look like the problem you are running into. Can try deleting all files called .attach_pidXXX and .java_pidXXX in your $TMPDIR? Also make sure jconsole and java are launched as the same user. > >> > >> Thanks, > >> /Staffan > >> > >> On 12 okt 2013, at 23:00, Christopher Brown wrote: > >> > >>> Hello, > >>> > >>> When I start an application, using Apple Java 1.6.0_51 (with "java -jar > >>> application.jar" and no "-D" parameters), I can connect to it using > >>> JConsole, using either the Apple Java 6 version or the Oracle Java 7 > >>> version. The application registers some MXBeans using the > >>> PlatformMBeanServer. > >>> > >>> Now, when I start that same application, using Oracle Java 1.7.0_40, in the > >>> same way, it is still visible using the Java 7 JConsole under "local > >>> processes", however connection using JConsole and VisualVM fails. > >>> > >>> Running JConsole with the "-debug" option, the following stacktrace is > >>> displayed when JConsole fails to connect: > >>> > >>> java.io.IOException: Unable to open socket file: target process not > >>> responding or HotSpot VM not loaded > >>> at > >>> sun.tools.jconsole.LocalVirtualMachine.loadManagementAgent(LocalVirtualMachine.java:238) > >>> at > >>> sun.tools.jconsole.LocalVirtualMachine.startManagementAgent(LocalVirtualMachine.java:100) > >>> at sun.tools.jconsole.ProxyClient.tryConnect(ProxyClient.java:333) > >>> at sun.tools.jconsole.ProxyClient.connect(ProxyClient.java:313) > >>> at sun.tools.jconsole.VMPanel$2.run(VMPanel.java:292) > >>> Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open > >>> socket file: target process not responding or HotSpot VM not loaded > >>> at sun.tools.attach.BsdVirtualMachine.(BsdVirtualMachine.java:90) > >>> at > >>> sun.tools.attach.BsdAttachProvider.attachVirtualMachine(BsdAttachProvider.java:63) > >>> at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:213) > >>> at > >>> sun.tools.jconsole.LocalVirtualMachine.loadManagementAgent(LocalVirtualMachine.java:236) > >>> ... 4 more > >>> > >>> JConsole displays the dialog "ConnectionFailedSSL1" and > >>> "ConnectionFailedSSL2", with [Cancel] and [Insecure] options. If I click > >>> "insecure", it fails in exactly the same with. > >>> > >>> For a development environment, how can I get things working again so that > >>> it "just works" (Oracle Java 7 VM and Java 7 JConsole) ? > >>> > >>> Thanks, > >>> Christopher > >> > > > > From paul_t100 at fastmail.fm Thu Oct 17 12:27:29 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 17 Oct 2013 20:27:29 +0100 Subject: Does Java 7 port support the apple.awt-use-dialog-packages system property Message-ID: <52603A21.7090406@fastmail.fm> Im trying to port an application from Java 6 to Java 7 on Mac does Java 1.7.0_40-b43 support the apple.awt-use-file-dialog-packages option system property so that I can select and application bundle in a FileDialog as if it a file rather than the reality ( a folder), Im having trouble getting existing code to work thanks Paul From anthony.petrov at oracle.com Thu Oct 17 13:03:33 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 18 Oct 2013 00:03:33 +0400 Subject: Does Java 7 port support the apple.awt-use-dialog-packages system property In-Reply-To: <52603A21.7090406@fastmail.fm> References: <52603A21.7090406@fastmail.fm> Message-ID: <52604295.8000204@oracle.com> Hi Paul, Apparently not: $ grep -r "awt-use-file-dialog-packages" jdk/src/* | wc -l 0 Your best bet is to file an RFE at http://bugs.sun.com/ -- best regards, Anthony On 10/17/2013 11:27 PM, Paul Taylor wrote: > Im trying to port an application from Java 6 to Java 7 on Mac does Java > 1.7.0_40-b43 support the apple.awt-use-file-dialog-packages option > system property so that I can select and application bundle in a > FileDialog as if it a file rather than the reality ( a folder), Im > having trouble getting existing code to work > > thanks Paul From paul_t100 at fastmail.fm Thu Oct 17 13:31:22 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 17 Oct 2013 21:31:22 +0100 Subject: Does Java 7 port support the apple.awt-use-dialog-packages system property In-Reply-To: <52604295.8000204@oracle.com> References: <52603A21.7090406@fastmail.fm> <52604295.8000204@oracle.com> Message-ID: <5260491A.7030503@fastmail.fm> On 17/10/2013 21:03, Anthony Petrov wrote: > Hi Paul, > > Apparently not: > > $ grep -r "awt-use-file-dialog-packages" jdk/src/* | wc -l > 0 > > Your best bet is to file an RFE at http://bugs.sun.com/ Oh drat, shame as the similar "apple.awt.fileDialogForDirectories" was added, having said that when I use this in another project it was with an early access release of 1.7.0_40 , now with the final release although I can select folders as required , I can also select files I thought they were hidden or greyed out, or is my memory failing me. I must admit I wasn't aware of the apple.awt-use-dialog-packages property myself, I only found it when I delved into how ApplicationDialog in Mrjadapter project worked https://java.net/projects/mrjadapter/sources/svn/content/trunk/src/net/roydesign/ui/ApplicationDialog.java?rev=35 Paul From Sergey.Bylokhov at oracle.com Thu Oct 17 14:34:01 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 18 Oct 2013 01:34:01 +0400 Subject: Does Java 7 port support the apple.awt-use-dialog-packages system property In-Reply-To: <5260491A.7030503@fastmail.fm> References: <52603A21.7090406@fastmail.fm> <52604295.8000204@oracle.com> <5260491A.7030503@fastmail.fm> Message-ID: <526057C9.3010703@oracle.com> On 18.10.2013 0:31, Paul Taylor wrote: > Oh drat, shame as the similar "apple.awt.fileDialogForDirectories" was > added, having said that when I use this in another project it was with > an early access release of 1.7.0_40 , now with the final release > although I can select folders as required , I can also select files I > thought they were hidden or greyed out, or is my memory failing me. The possibility to select files in this mode is a bug, and it was fixed in jdk 8 https://bugs.openjdk.java.net/browse/JDK-8025503 -- Best regards, Sergey. From paul_t100 at fastmail.fm Fri Oct 18 02:51:51 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 18 Oct 2013 10:51:51 +0100 Subject: Does Java 7 port support the apple.awt-use-dialog-packages system property In-Reply-To: <526057C9.3010703@oracle.com> References: <52603A21.7090406@fastmail.fm> <52604295.8000204@oracle.com> <5260491A.7030503@fastmail.fm> <526057C9.3010703@oracle.com> Message-ID: <526104B7.6010605@fastmail.fm> On 17/10/2013 22:34, Sergey Bylokhov wrote: > On 18.10.2013 0:31, Paul Taylor wrote: >> Oh drat, shame as the similar "apple.awt.fileDialogForDirectories" >> was added, having said that when I use this in another project it was >> with an early access release of 1.7.0_40 , now with the final release >> although I can select folders as required , I can also select files I >> thought they were hidden or greyed out, or is my memory failing me. > The possibility to select files in this mode is a bug, and it was > fixed in jdk 8 > https://bugs.openjdk.java.net/browse/JDK-8025503 > Thanks, but with Java 8 not being released until March 2014 is there no chance of it being fixed in Java 7 ? Ive tries to submit a bug report three times now and each time it fails at the end, and yes I do view it as a bug not an rfe because its a regression from java 6. At least the last time I kept the bug report information in a text file so I post here in case anyone can do anything with it Java 7 on Mac no longer supports apple.awt.use-file-dialog-packages property OSX 10.8 Darwin macbook.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64 java version "1.7.0_40" Java(TM) SE Runtime Environment (build 1.7.0_40-b43) Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode) In Java 6 on OSX the apple.awt.use-file-dialog-packages property is used by FIleDialog to display application bundles as leaf node rather than a folder (which is what they actually are). This allows an application to create a dialog that lets the user pick a bundle as an application i.e to let them configure their browser or Texteditor. This option is no longer available I no longer have that installed but this worked with Apples version of Java Create a FileDialog Navigate to the /Applications folder Applications are listed and cannot be expanded, the same behaviour as using a Finder window Use of the the property can be seen in ApplicationDialog within this project https://java.net/projects/mrjadapter/sources/svn/content/trunk/src/net/roydesign/ui/ApplicationDialog.java?rev=35 The problem is that this issue makes it difficult to update my application to use Java 7 rather than Java 6 as we are being advised to do because it degrades the functionality of my application From alexandr.scherbatiy at oracle.com Fri Oct 18 04:49:44 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 18 Oct 2013 15:49:44 +0400 Subject: Aqua Icons support on HiDPI displays. Message-ID: <52612058.1030502@oracle.com> Hello, The GetIconRef method is used in the CImage.m now to get the system icons on MacOSX. The NSImage + (id)imageNamed:(NSString *)name method can be used directly instead. There are NSImageNameFolder, NSImageNameFolderBurnable, and NSImageNameFolderSmart constants but I can't find the constant for the open folder icon. https://developer.apple.com/library/mac/documentation/cocoa/reference/applicationkit/classes/NSImage_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Toolbar_Named_Images The same is for the alert stop system icon. There are NSImageNameInfo and NSImageNameCaution icons but I can't find the constant for the alert stop icon. Where is it possible to get the open folder and stop icons that are defined as kOpenFolderIcon and kAlertStopIcon for the GetIconRef method? Thanks, Alexandr. From anthony.petrov at oracle.com Fri Oct 18 06:02:01 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 18 Oct 2013 17:02:01 +0400 Subject: Does Java 7 port support the apple.awt-use-dialog-packages system property In-Reply-To: <526104B7.6010605@fastmail.fm> References: <52603A21.7090406@fastmail.fm> <52604295.8000204@oracle.com> <5260491A.7030503@fastmail.fm> <526057C9.3010703@oracle.com> <526104B7.6010605@fastmail.fm> Message-ID: <52613149.1050708@oracle.com> Hi Paul, I've just filed this issue for you: https://bugs.openjdk.java.net/browse/JDK-8026869 It is currently targeted for JDK 9. After it's fixed in the mainline, we can consider porting the fix to 8- and 7-update releases. -- best regards, Anthony On 10/18/2013 01:51 PM, Paul Taylor wrote: > On 17/10/2013 22:34, Sergey Bylokhov wrote: >> On 18.10.2013 0:31, Paul Taylor wrote: >>> Oh drat, shame as the similar "apple.awt.fileDialogForDirectories" >>> was added, having said that when I use this in another project it was >>> with an early access release of 1.7.0_40 , now with the final release >>> although I can select folders as required , I can also select files I >>> thought they were hidden or greyed out, or is my memory failing me. >> The possibility to select files in this mode is a bug, and it was >> fixed in jdk 8 >> https://bugs.openjdk.java.net/browse/JDK-8025503 >> > Thanks, but with Java 8 not being released until March 2014 is there no > chance of it being fixed in Java 7 ? > > Ive tries to submit a bug report three times now and each time it fails > at the end, and yes I do view it as a bug not an rfe because its a > regression from java 6. At least the last time I kept the bug report > information in a text file so I post here in case anyone can do anything > with it > > > > Java 7 on Mac no longer supports apple.awt.use-file-dialog-packages > property > > OSX 10.8 > Darwin macbook.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 > 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64 > > java version "1.7.0_40" > Java(TM) SE Runtime Environment (build 1.7.0_40-b43) > Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode) > > In Java 6 on OSX the apple.awt.use-file-dialog-packages property is used > by FIleDialog to display application bundles as leaf node rather than a > folder (which is what they actually are). This allows an application to > create a dialog that lets the user pick a bundle as an application i.e > to let them configure their browser or Texteditor. > > This option is no longer available > > I no longer have that installed but this worked with Apples version of Java > > Create a FileDialog > Navigate to the /Applications folder > > Applications are listed and cannot be expanded, the same behaviour as > using a Finder window > > Use of the the property can be seen in ApplicationDialog within this > project > https://java.net/projects/mrjadapter/sources/svn/content/trunk/src/net/roydesign/ui/ApplicationDialog.java?rev=35 > > > The problem is that this issue makes it difficult to update my > application to use Java 7 rather than Java 6 as we are being advised to > do because it degrades the functionality of my application > From paul_t100 at fastmail.fm Fri Oct 18 06:26:24 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 18 Oct 2013 14:26:24 +0100 Subject: Does Java 7 port support the apple.awt-use-dialog-packages system property In-Reply-To: <52613149.1050708@oracle.com> References: <52603A21.7090406@fastmail.fm> <52604295.8000204@oracle.com> <5260491A.7030503@fastmail.fm> <526057C9.3010703@oracle.com> <526104B7.6010605@fastmail.fm> <52613149.1050708@oracle.com> Message-ID: <52613700.4040509@fastmail.fm> On 18/10/2013 14:02, Anthony Petrov wrote: > Hi Paul, > > I've just filed this issue for you: > > https://bugs.openjdk.java.net/browse/JDK-8026869 > > It is currently targeted for JDK 9. After it's fixed in the mainline, > we can consider porting the fix to 8- and 7-update releases. Hi, thanks alot -I assume I don't submit bugs straight into that. I was trying to use the bugs database Paul From anthony.petrov at oracle.com Fri Oct 18 06:36:56 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 18 Oct 2013 17:36:56 +0400 Subject: Does Java 7 port support the apple.awt-use-dialog-packages system property In-Reply-To: <52613700.4040509@fastmail.fm> References: <52603A21.7090406@fastmail.fm> <52604295.8000204@oracle.com> <5260491A.7030503@fastmail.fm> <526057C9.3010703@oracle.com> <526104B7.6010605@fastmail.fm> <52613149.1050708@oracle.com> <52613700.4040509@fastmail.fm> Message-ID: <52613978.7070105@oracle.com> On 10/18/2013 05:26 PM, Paul Taylor wrote: > On 18/10/2013 14:02, Anthony Petrov wrote: >> Hi Paul, >> >> I've just filed this issue for you: >> >> https://bugs.openjdk.java.net/browse/JDK-8026869 >> >> It is currently targeted for JDK 9. After it's fixed in the mainline, >> we can consider porting the fix to 8- and 7-update releases. > Hi, thanks alot -I assume I don't submit bugs straight into that. I was > trying to use the bugs database Correct. And you're welcome. And thanks for the report, btw. -- best regards, Anthony From tim.howe at bloodhoundcbc.com Fri Oct 18 11:22:04 2013 From: tim.howe at bloodhoundcbc.com (Tim Howe) Date: Fri, 18 Oct 2013 13:22:04 -0500 Subject: FullScreen (Exclusive) Swing Components Fail to Receive Keyboard Input on Java 7 on Mac OS X (Mountain) Lion In-Reply-To: <30F8933B-FD74-4141-B737-1249B3641881@oracle.com> Message-ID: Has there been any movement on this? We rely on full-screen exclusive mode for our application and this is blocking us from upgrading past Java 1.6. I've just checked and the problem still persists in 1.8.0-ea-b111. Unfortunately the workaround described here doesn't fully solve the problem. Specifically mouse cursor and button highlighting on hover still don't function normally. Thanks, Tim On 11/2/12 5:26 PM, "Leonid Romanov" wrote: >Yep, please fill a bug with your latest findings. > >On Nov 3, 2012, at 1:14 AM, Eric Bailey wrote: > >> Wow, thanks for the response! At least in my test example, this indeed >>restores keyboard input. I initially though I might have to resort to >>invokeLaters on the visibility calls, but immediately after works fine: >> >> dev.setFullScreenWindow(f); >> f.setVisible(false); >> f.setVisible(true); >> >> I have yet to file a bug. Would you like one based on this latest >>information? >> >> Also, I'll be checking my larger app for functionality in a few minutes >>and will report back. >> >> Thank you, >> - Eric >> >> >> On Nov 2, 2012, at 1:36 PM, Leonid Romanov wrote: >> >>> Well, although I'm not 100% sure yet, but it looks like when we enter >>>full screen some other window becomes the first responder, hence the >>>beep. Could you please try the following workaround: after calling >>>setFullScreenWindow() on a frame, call setVisible(false) followed by >>>setVisible(true). This, in theory, should restore the correct first >>>responder. >>> >>> On Nov 2, 2012, at 10:37 PM, Leonid Romanov >>oracle.com> wrote: >>> >>>> Hi, >>>> Confirming that this issue is reproducible on my Mac as well. Have >>>>you filled the bug yet? >>>> >>>> Regards, >>>> Leonid. >>>> >>>> On Nov 1, 2012, at 11:26 PM, Eric Bailey >>>>wrote: >>>> >>>>> Hello, >>>>> >>>>> My company has a Swing application that needs to run in both a >>>>>windowed context and in a fullscreen, kiosk-like mode. >>>>> >>>>> This application has worked fine for years on OS X, most recently >>>>>targeting Java 6. We've been looking to move to Java 7 and to >>>>>incorporate JavaFX elements, driving us to do compatibility testing >>>>>with the latest Mountain Lion release (10.8.2 Supplemental) and >>>>>Oracle's JDK 7u9. >>>>> >>>>> Unfortunately, we noticed a glaring issue while in fullscreen mode: >>>>>mouse movement and clicks work fine, but keyboard input is not >>>>>delivered to the components. Tab also does not work for focus >>>>>traversal, though the focus subsystem appears to work properly >>>>>according to FocusListeners and the KeyboardFocusManager. Most key >>>>>presses produce a system alert beep in response, though registered >>>>>KeyListeners and key bindings receive no events. >>>>> >>>>> I have a detailed issue and focused sample code on StackOverflow (I >>>>>didn't want to burden the message with the 240 line sample): >>>>> >>>>>http://stackoverflow.com/questions/13064607/fullscreen-swing-component >>>>>s-fail-to-receive-keyboard-input-on-java-7-on-mac-os-x >>>>> >>>>> Digging deeper, we identified that the issue was introduced with >>>>>7u6, when JavaFX began its inclusion in the mainline distribution. >>>>>It remains in 7u7 and 7u9, and it affects both Lion 10.7 and Mountain >>>>>Lion 10.8. A coworker attributes this to a switch from an AWTView to >>>>>a NSWindow in 7u6 as the backing for the fullscreen window. >>>>> >>>>> I'll be filing an issue with Oracle soon, but I was hoping to hear >>>>>of possible workarounds in the interim. >>>>> >>>>> One alternative approach I was pursuing was incorporating >>>>>com.apple.eawt.FullScreenUtilities. This option has been included in >>>>>my sample code, but I have found limited kiosking capabilities. In >>>>>particular, I'm hoping to eliminate access to Command-Tab app >>>>>switching, Mission Control, and Launch Pad, effectively locking the >>>>>user into my application (it's an education setting). >>>>>Unfortunately, the prevailing suggestions regarding disabling the >>>>>Dock (which is responsible for those listed capabilities) revealed >>>>>that the Dock also handles fullscreen apps, rendering the >>>>>FullScreenUtilities calls inoperable. >>>>> >>>>> All input is greatly appreciated. >>>>> >>>>> Thank you, >>>>> Eric Bailey >>>>> Director, Content Engineering >>>>> Acuitus >>>> >>> >> This email message, including any attachment(s), is for the sole use of the intended recipient(s) and may contain confidential and legally privileged information. If you believe that you are not an intended recipient of this message, please contact the sender by reply email and destroy all copies of the original message. Any unauthorized use, dissemination, or reproduction of this message by anyone other than an intended recipient is strictly prohibited. BLOODHOUND is a trademark of Constitution Medical, Inc. From tim.howe at bloodhoundcbc.com Fri Oct 18 11:35:58 2013 From: tim.howe at bloodhoundcbc.com (Tim Howe) Date: Fri, 18 Oct 2013 13:35:58 -0500 Subject: InputEvent.CTRL_MASK ignores keyboard layout on OS X Message-ID: Unfortunately there seems to be a regression in key event handling in Java 1.7+ on OS X. Mapping actions to control-chorded keystrokes uses what's printed on the physical key regardless of the selected keyboard layout. Therefore when using any other keyboard layout the specified control keys don't work and other keys have surprising effects. If you add a KeyListener and examine the KeyEvent it is incorrect as well. This only affects CTRL_MASK and only Java 1.7 and so far 1.8. 1.6 works correctly. Here are 2 simple ways to duplicate the problem: * Simple test case: 1. Download and compile http://www.java2s.com/Code/JavaAPI/java.awt.event/InputEventCTRLMASK.htm 2. Select Dvorak keyboard layout ("input source") 4. Run sample code 5. Press Control-U (will appear to be Control-F on keyboard); note caret moves forward 1 character 6. Press Control-G (will appear to be Control-U on keyboard); note word is uppercased If you replace all instances of CTRL_MASK with META_MASK the code works as expected. * Simpler test case: 1. Use Dvorak or some other alternate keyboard layout 2. Run NetBeans 3. Try to use control keys and notice that your source code is munged unpredictably Thanks, Tim This email message, including any attachment(s), is for the sole use of the intended recipient(s) and may contain confidential and legally privileged information. If you believe that you are not an intended recipient of this message, please contact the sender by reply email and destroy all copies of the original message. Any unauthorized use, dissemination, or reproduction of this message by anyone other than an intended recipient is strictly prohibited. BLOODHOUND is a trademark of Constitution Medical, Inc. From leonid.romanov at oracle.com Fri Oct 18 13:14:31 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Sat, 19 Oct 2013 00:14:31 +0400 Subject: InputEvent.CTRL_MASK ignores keyboard layout on OS X In-Reply-To: References: Message-ID: Hello, Do you mean it's a regression against older JDK 7 releases (that is, there is an older JDK 7 release which doesn't have that problem) or it's a regression against JDK 6, meaning that all JDK 7 releases on OS X have that problem? On Oct 18, 2013, at 10:35 PM, Tim Howe wrote: > Unfortunately there seems to be a regression in key event handling in Java > 1.7+ on OS X. > > Mapping actions to control-chorded keystrokes uses what's printed on the > physical key regardless of the selected keyboard layout. Therefore when > using any other keyboard layout the specified control keys don't work and > other keys have surprising effects. If you add a KeyListener and examine > the KeyEvent it is incorrect as well. > > This only affects CTRL_MASK and only Java 1.7 and so far 1.8. 1.6 works > correctly. > > Here are 2 simple ways to duplicate the problem: > > > * Simple test case: > > 1. Download and compile > http://www.java2s.com/Code/JavaAPI/java.awt.event/InputEventCTRLMASK.htm > 2. Select Dvorak keyboard layout ("input source") > 4. Run sample code > 5. Press Control-U (will appear to be Control-F on keyboard); note caret > moves forward 1 character > 6. Press Control-G (will appear to be Control-U on keyboard); note word is > uppercased > > If you replace all instances of CTRL_MASK with META_MASK the code works as > expected. > > > * Simpler test case: > > 1. Use Dvorak or some other alternate keyboard layout > 2. Run NetBeans > 3. Try to use control keys and notice that your source code is munged > unpredictably > > > Thanks, > Tim > > > > This email message, including any attachment(s), is for the sole use of the intended recipient(s) and may contain confidential and legally privileged information. If you believe that you are not an intended recipient of this message, please contact the sender by reply email and destroy all copies of the original message. Any unauthorized use, dissemination, or reproduction of this message by anyone other than an intended recipient is strictly prohibited. BLOODHOUND is a trademark of Constitution Medical, Inc. From tim.howe at bloodhoundcbc.com Fri Oct 18 13:45:49 2013 From: tim.howe at bloodhoundcbc.com (Tim Howe) Date: Fri, 18 Oct 2013 15:45:49 -0500 Subject: InputEvent.CTRL_MASK ignores keyboard layout on OS X In-Reply-To: Message-ID: On 10/18/13 4:14 PM, "Leonid Romanov" wrote: >Do you mean it's a regression against older JDK 7 releases (that is, >there is an older JDK 7 release which doesn't have that problem) or it's >a regression against JDK 6, meaning that all JDK 7 releases on OS X have >that problem? As far as I know it's a regression against JDK 6. That said I've only tested against 1.7.0_40-b43 and 1.8.0-ea-b111. If it will help I'd be happy to see if it works on the oldest available 1.7 JDK or not. >On Oct 18, 2013, at 10:35 PM, Tim Howe wrote: > >>Unfortunately there seems to be a regression in key event handling in >>Java >>1.7+ on OS X. This email message, including any attachment(s), is for the sole use of the intended recipient(s) and may contain confidential and legally privileged information. If you believe that you are not an intended recipient of this message, please contact the sender by reply email and destroy all copies of the original message. Any unauthorized use, dissemination, or reproduction of this message by anyone other than an intended recipient is strictly prohibited. BLOODHOUND is a trademark of Constitution Medical, Inc. From leonid.romanov at oracle.com Fri Oct 18 13:52:53 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Sat, 19 Oct 2013 00:52:53 +0400 Subject: InputEvent.CTRL_MASK ignores keyboard layout on OS X In-Reply-To: References: Message-ID: <4A430130-22D9-48CD-968C-201CF7A2B74B@oracle.com> I see.. I'll check it myself, then: I have all the previous releases on my mac. Meanwhile, please, be sure to file a bug. On Oct 19, 2013, at 12:45 AM, Tim Howe wrote: > On 10/18/13 4:14 PM, "Leonid Romanov" wrote: > >> Do you mean it's a regression against older JDK 7 releases (that is, >> there is an older JDK 7 release which doesn't have that problem) or it's >> a regression against JDK 6, meaning that all JDK 7 releases on OS X have >> that problem? > > As far as I know it's a regression against JDK 6. That said I've only > tested against 1.7.0_40-b43 and 1.8.0-ea-b111. If it will help I'd be > happy to see if it works on the oldest available 1.7 JDK or not. > >> On Oct 18, 2013, at 10:35 PM, Tim Howe wrote: >> >>> Unfortunately there seems to be a regression in key event handling in >>> Java >>> 1.7+ on OS X. > > > > This email message, including any attachment(s), is for the sole use of the intended recipient(s) and may contain confidential and legally privileged information. If you believe that you are not an intended recipient of this message, please contact the sender by reply email and destroy all copies of the original message. Any unauthorized use, dissemination, or reproduction of this message by anyone other than an intended recipient is strictly prohibited. BLOODHOUND is a trademark of Constitution Medical, Inc. From swingler at apple.com Fri Oct 18 15:45:15 2013 From: swingler at apple.com (Mike Swingler) Date: Fri, 18 Oct 2013 15:45:15 -0700 Subject: Aqua Icons support on HiDPI displays. In-Reply-To: <52612058.1030502@oracle.com> References: <52612058.1030502@oracle.com> Message-ID: <8EDD8811-8572-4226-B5E9-13EECF037B6B@apple.com> On Oct 18, 2013, at 4:49 AM, Alexander Scherbatiy wrote: > Hello, > > The GetIconRef method is used in the CImage.m now to get the system icons on MacOSX. > > The NSImage + (id)imageNamed:(NSString *)name method can be used directly instead. > > There are NSImageNameFolder, NSImageNameFolderBurnable, and NSImageNameFolderSmart constants but I can't find > the constant for the open folder icon. > https://developer.apple.com/library/mac/documentation/cocoa/reference/applicationkit/classes/NSImage_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Toolbar_Named_Images > > The same is for the alert stop system icon. There are NSImageNameInfo and NSImageNameCaution icons but I can't find > the constant for the alert stop icon. > > Where is it possible to get the open folder and stop icons that are defined as kOpenFolderIcon and kAlertStopIcon for the GetIconRef method? There are no corresponding constants for +[NSImage imageNamed:], however you can use the same constants you pass into GetIconRef(), and send them into: [[NSWorkspace sharedWorkspace] iconForFileType: NSFileTypeForHFSTypeCode(kOpenFolderIcon)] Regards, Mike Swingler Apple Inc. From hs at tagtraum.com Sat Oct 19 02:21:41 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Sat, 19 Oct 2013 11:21:41 +0200 Subject: Aqua Icons support on HiDPI displays. In-Reply-To: <8EDD8811-8572-4226-B5E9-13EECF037B6B@apple.com> References: <52612058.1030502@oracle.com> <8EDD8811-8572-4226-B5E9-13EECF037B6B@apple.com> Message-ID: <74962867-775B-4A2C-A98D-F120EAB7C8A3@tagtraum.com> On Oct 19, 2013, at 12:45 AM, Mike Swingler wrote: > On Oct 18, 2013, at 4:49 AM, Alexander Scherbatiy wrote: > >> The GetIconRef method is used in the CImage.m now to get the system icons on MacOSX. >> >> The NSImage + (id)imageNamed:(NSString *)name method can be used directly instead. >> >> There are NSImageNameFolder, NSImageNameFolderBurnable, and NSImageNameFolderSmart constants but I can't find >> the constant for the open folder icon. >> https://developer.apple.com/library/mac/documentation/cocoa/reference/applicationkit/classes/NSImage_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Toolbar_Named_Images >> >> The same is for the alert stop system icon. There are NSImageNameInfo and NSImageNameCaution icons but I can't find >> the constant for the alert stop icon. Alexander, may I ask through which API you intend to make the icons available? Also, will there be a way to create custom HiDPI images/icons? If so, how? Thanks, -hendrik From mik3hall at gmail.com Sat Oct 19 15:16:02 2013 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 19 Oct 2013 17:16:02 -0500 Subject: Application LSEnvironment plist entries not in System.getenv Message-ID: <4667E625-029C-41E6-9CBD-51B9D1775E4A@gmail.com> It appears to be true for both the appbundler project and the infinitekind branch of that, that nothing is done to pass these to the launched java application. As near as I can tell, but I'm not 100% sure what I am looking for to pass that on. Something in the launch parameters? While on this, is the appbundler project considered completedt? There has been very little mailing list message traffic for months and none from anyone I know of to be a project person? The reason for asking on this issue is that I was looking to add R language JSR 223 scripting support to my HalfPipe application based on this... rscript - Java to R scripting interface http://www.rforge.net/rscript/index.html which has a dependency on? JRI - Java/R Interface http://rforge.net/JRI/ which works fine from Terminal but doesn't from an application because it doesn't find it's required environment variables and fails. Even though I did set them in the plist so not sure why that is. The code appears OS X savvy to the point of knowing to check for the R framework in the absence of the environmental variable. There then seem to be workarounds like setting the environment variable itself with a setenv native call. Or going directly after the file(s) by absolute path. The failing error is in the native code, not sure why the workarounds don't avoid it. But for now anyhow it appears to be a show stopper for java application use of this code. 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 david.dehaven at oracle.com Sun Oct 20 16:53:23 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Sun, 20 Oct 2013 16:53:23 -0700 Subject: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated Message-ID: CCing: build-dev, macosx-port-dev Request for review of JDK-8016096: https://bugs.openjdk.java.net/browse/JDK-8016096 Proposed changes: http://cr.openjdk.java.net/~ddehaven/8016096/ Significant build system changes for this one so feedback from build-dev is appreciated. Actual functional changes are just ported from the JDK7 changes I made several months ago, less the X11 dependency in jawt_md.h. The autoconf changes also trigger an update of generated-configure.sh in jdk/make/closed, that will need to be pushed too. Please note: These patches will not work alone! You must also apply the patches for 8025673, which I'm also submitting for review. Built and tested on Mac and Linux. I'm in the process of submitting JPRT runs. -DrD- From david.dehaven at oracle.com Sun Oct 20 16:56:13 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Sun, 20 Oct 2013 16:56:13 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit Message-ID: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> CCing: build-dev, macosx-port-dev, hotspot-dev Request for review of JDK-8025673: https://bugs.openjdk.java.net/browse/JDK-8025673 Proposed changes: http://cr.openjdk.java.net/~ddehaven/8025673/ This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. Significant build system changes, build-dev guys are encouraged to comment... I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. Question for the AWT team, we still have this in java_props_md.c: 458 PreferredToolkit prefToolkit = getPreferredToolkit(); 459 if (prefToolkit == CToolkit) { 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; 461 } else { 462 // TODO: do we still need this? 463 sprops.awt_toolkit = "sun.awt.HToolkit"; 464 } Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. -DrD- From artem.ananiev at oracle.com Mon Oct 21 02:35:39 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 21 Oct 2013 13:35:39 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> Message-ID: <5264F56B.6030100@oracle.com> Hi, David, the changes look fine to me. See more comments below. On 10/21/2013 3:56 AM, David DeHaven wrote: > > CCing: build-dev, macosx-port-dev, hotspot-dev > > Request for review of JDK-8025673: > https://bugs.openjdk.java.net/browse/JDK-8025673 > > Proposed changes: > http://cr.openjdk.java.net/~ddehaven/8025673/ > > This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). > > A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. > > Significant build system changes, build-dev guys are encouraged to comment... > > I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. > > The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. > > > Question for the AWT team, we still have this in java_props_md.c: > 458 PreferredToolkit prefToolkit = getPreferredToolkit(); > 459 if (prefToolkit == CToolkit) { > 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; > 461 } else { > 462 // TODO: do we still need this? > 463 sprops.awt_toolkit = "sun.awt.HToolkit"; > 464 } > > Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. This question is for SE embedded team and for people who are responsible for reduced JRE builds, when some native libraries (including libawt_lwawt) are stripped. If these reduced builds are only for Solaris/Linux, then we don't need HToolkit stuff on Mac. Thanks, Artem > I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. > > JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. > > -DrD- > From artem.ananiev at oracle.com Mon Oct 21 03:33:38 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 21 Oct 2013 14:33:38 +0400 Subject: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated In-Reply-To: References: Message-ID: <52650302.2080100@oracle.com> Hi, David, client (AWT, Java2D) part of the fix looks fine. Thanks, Artem On 10/21/2013 3:53 AM, David DeHaven wrote: > > CCing: build-dev, macosx-port-dev > > Request for review of JDK-8016096: > https://bugs.openjdk.java.net/browse/JDK-8016096 > > Proposed changes: > http://cr.openjdk.java.net/~ddehaven/8016096/ > > Significant build system changes for this one so feedback from build-dev is appreciated. Actual functional changes are just ported from the JDK7 changes I made several months ago, less the X11 dependency in jawt_md.h. The autoconf changes also trigger an update of generated-configure.sh in jdk/make/closed, that will need to be pushed too. > > > Please note: > These patches will not work alone! You must also apply the patches for 8025673, which I'm also submitting for review. > > > Built and tested on Mac and Linux. I'm in the process of submitting JPRT runs. > > -DrD- > From anthony.petrov at oracle.com Mon Oct 21 11:13:36 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 21 Oct 2013 18:13:36 +0000 Subject: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated In-Reply-To: References: Message-ID: <52656ED0.8010200@oracle.com> Hi David, The fix looks fine to me. -- best regards, Anthony On 10/20/2013 11:53 PM, David DeHaven wrote: > > CCing: build-dev, macosx-port-dev > > Request for review of JDK-8016096: > https://bugs.openjdk.java.net/browse/JDK-8016096 > > Proposed changes: > http://cr.openjdk.java.net/~ddehaven/8016096/ > > Significant build system changes for this one so feedback from build-dev is appreciated. Actual functional changes are just ported from the JDK7 changes I made several months ago, less the X11 dependency in jawt_md.h. The autoconf changes also trigger an update of generated-configure.sh in jdk/make/closed, that will need to be pushed too. > > > Please note: > These patches will not work alone! You must also apply the patches for 8025673, which I'm also submitting for review. > > > Built and tested on Mac and Linux. I'm in the process of submitting JPRT runs. > > -DrD- > From anthony.petrov at oracle.com Mon Oct 21 11:22:19 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 21 Oct 2013 18:22:19 +0000 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> Message-ID: <526570DB.9070509@oracle.com> This fix looks fine to me as well. -- best regards, Anthony On 10/20/2013 11:56 PM, David DeHaven wrote: > > CCing: build-dev, macosx-port-dev, hotspot-dev > > Request for review of JDK-8025673: > https://bugs.openjdk.java.net/browse/JDK-8025673 > > Proposed changes: > http://cr.openjdk.java.net/~ddehaven/8025673/ > > This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). > > A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. > > Significant build system changes, build-dev guys are encouraged to comment... > > I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. > > The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. > > > Question for the AWT team, we still have this in java_props_md.c: > 458 PreferredToolkit prefToolkit = getPreferredToolkit(); > 459 if (prefToolkit == CToolkit) { > 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; > 461 } else { > 462 // TODO: do we still need this? > 463 sprops.awt_toolkit = "sun.awt.HToolkit"; > 464 } > > Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. > > > I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. > > JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. > > -DrD- > From david.dehaven at oracle.com Mon Oct 21 08:58:36 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 21 Oct 2013 08:58:36 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <526570DB.9070509@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> Message-ID: <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Thanks guys. Anthony, can you sponsor this for me? -DrD- > This fix looks fine to me as well. > > -- > best regards, > Anthony > > On 10/20/2013 11:56 PM, David DeHaven wrote: >> >> CCing: build-dev, macosx-port-dev, hotspot-dev >> >> Request for review of JDK-8025673: >> https://bugs.openjdk.java.net/browse/JDK-8025673 >> >> Proposed changes: >> http://cr.openjdk.java.net/~ddehaven/8025673/ >> >> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >> >> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >> >> Significant build system changes, build-dev guys are encouraged to comment... >> >> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >> >> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >> >> >> Question for the AWT team, we still have this in java_props_md.c: >> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >> 459 if (prefToolkit == CToolkit) { >> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >> 461 } else { >> 462 // TODO: do we still need this? >> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >> 464 } >> >> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >> >> >> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >> >> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >> >> -DrD- >> From david.dehaven at oracle.com Mon Oct 21 12:54:17 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 21 Oct 2013 12:54:17 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Message-ID: I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. -DrD- > Thanks guys. > > Anthony, can you sponsor this for me? > > -DrD- > >> This fix looks fine to me as well. >> >> -- >> best regards, >> Anthony >> >> On 10/20/2013 11:56 PM, David DeHaven wrote: >>> >>> CCing: build-dev, macosx-port-dev, hotspot-dev >>> >>> Request for review of JDK-8025673: >>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>> >>> Proposed changes: >>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>> >>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>> >>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>> >>> Significant build system changes, build-dev guys are encouraged to comment... >>> >>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>> >>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>> >>> >>> Question for the AWT team, we still have this in java_props_md.c: >>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>> 459 if (prefToolkit == CToolkit) { >>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>> 461 } else { >>> 462 // TODO: do we still need this? >>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>> 464 } >>> >>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>> >>> >>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>> >>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>> >>> -DrD- >>> > From david.dehaven at oracle.com Mon Oct 21 20:34:30 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 21 Oct 2013 20:34:30 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Message-ID: Updated webrev for JDK (hotspot change is the same): http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ Changes since last version: - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] -DrD- > I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. > > -DrD- > >> Thanks guys. >> >> Anthony, can you sponsor this for me? >> >> -DrD- >> >>> This fix looks fine to me as well. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>> >>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>> >>>> Request for review of JDK-8025673: >>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>> >>>> Proposed changes: >>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>> >>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>> >>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>> >>>> Significant build system changes, build-dev guys are encouraged to comment... >>>> >>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>> >>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>> >>>> >>>> Question for the AWT team, we still have this in java_props_md.c: >>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>> 459 if (prefToolkit == CToolkit) { >>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>> 461 } else { >>>> 462 // TODO: do we still need this? >>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>> 464 } >>>> >>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>> >>>> >>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>> >>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>> >>>> -DrD- >>>> >> > From artem.ananiev at oracle.com Tue Oct 22 02:23:49 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 22 Oct 2013 13:23:49 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Message-ID: <52664425.4080201@oracle.com> Hi, David, thanks for additional cleanup. I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? Thanks, Artem On 10/22/2013 7:34 AM, David DeHaven wrote: > > Updated webrev for JDK (hotspot change is the same): > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ > > Changes since last version: > - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk > - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] > > -DrD- > > >> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >> >> -DrD- >> >>> Thanks guys. >>> >>> Anthony, can you sponsor this for me? >>> >>> -DrD- >>> >>>> This fix looks fine to me as well. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>> >>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>> >>>>> Request for review of JDK-8025673: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>> >>>>> Proposed changes: >>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>> >>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>> >>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>> >>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>> >>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>> >>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>> >>>>> >>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>> 459 if (prefToolkit == CToolkit) { >>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>> 461 } else { >>>>> 462 // TODO: do we still need this? >>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>> 464 } >>>>> >>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>> >>>>> >>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>> >>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>> >>>>> -DrD- >>>>> >>> >> > From alexandr.scherbatiy at oracle.com Tue Oct 22 02:31:51 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 22 Oct 2013 13:31:51 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays Message-ID: <52664607.2090807@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8011059 webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 The IMAGE_SCALING rendering hint is added to the RenderingHints class. Enabling the image scaling rendering hint forces the SunGraphics2D to use getScaledInstance(width, height, hints) method from Image class with SCALE_DEFAULT hint. By default the image scaling rendering hint is enabled on HiDPI display and disabled for standard displays. User can override the getScaledInstance(width, height, hints) method and return necessary high resolution image according to the given image width and height. For example: --------------------- final Image highResolutionImage = new BufferedImage(2 * WIDTH, 2 * HEIGHT, BufferedImage.TYPE_INT_RGB); Image image = new BufferedImage(WIDTH, HEIGHT, BufferedImage.TYPE_INT_RGB) { @Override public Image getScaledInstance(int width, int height, int hints) { if ((hints & Image.SCALE_DEFAULT) != 0) { return (width <= WIDTH && height <= HEIGHT) ? this : highResolutionImage; } return super.getScaledInstance(width, height, hints); } }; --------------------- The LWCToolkit and ToolkitImage classes are patched to automatically get provided image at 2x.ext images on MacOSX. There are no significant changes in the Java2D demo to make it look perfect on Retina displays. It needs only to put necessary images with the @2x postfix and they will be automatically drawn. Thanks, Alexandr. From anthony.petrov at oracle.com Tue Oct 22 03:16:07 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Oct 2013 14:16:07 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <52664425.4080201@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> Message-ID: <52665067.40102@oracle.com> Artem is correct. On Mac we can't start a GUI session via ssh, for example. Thus we choose the headless mode then. The isInAquaSession() is supposed to perform exactly this check. This logic needs to be preserved. -- best regards, Anthony On 10/22/2013 01:23 PM, Artem Ananiev wrote: > Hi, David, > > thanks for additional cleanup. > > I have only one concern. Before the fix, we checked if there is an > active Aqua session. When no session was found, we falled back to > HToolkit. I think this logic should be preserved, but slightly > corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). > > Otherwise the only way to run headless on Mac will be to force it with > the system property. It works this way on Windows, but on Windows we're > sure that WToolkit can run even without a UI session. Is it also true on > Mac? Did you try to launch AWT without -Djava.awt.headless=true from > remote console with no users logged in? > > Thanks, > > Artem > > On 10/22/2013 7:34 AM, David DeHaven wrote: >> >> Updated webrev for JDK (hotspot change is the same): >> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >> >> Changes since last version: >> - Moved to jdk8/build/jdk to save someone a merge headache, moved >> changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >> - Removed HToolkit option and toolkit selection code from >> java_props_macosx.[ch] >> >> -DrD- >> >> >>> I want to do one more iteration of this. Based on feedback it seems I >>> can remove a bit more code from java_props_macosx.[ch] and make >>> things a bit cleaner. >>> >>> -DrD- >>> >>>> Thanks guys. >>>> >>>> Anthony, can you sponsor this for me? >>>> >>>> -DrD- >>>> >>>>> This fix looks fine to me as well. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>> >>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>> >>>>>> Request for review of JDK-8025673: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>> >>>>>> Proposed changes: >>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>> >>>>>> This change disables building libawt_xawt.dylib and >>>>>> libawt_headless.dylib on Mac since they are not used and not >>>>>> supported. There are too many challenges (and not enough time) in >>>>>> removing all X11 code from the Mac build at this time, so we're >>>>>> deferring complete removal for later (will be covered by >>>>>> JDK-8003900). >>>>>> >>>>>> A small change to hotspot is required as it was looking for >>>>>> libawt_xawt.dylib and if not found would set java.awt.headless to >>>>>> true. Since we don't build a headless only JRE on Mac I just have >>>>>> that method return false. I'm not sure how to handle changes to >>>>>> hotspot, can it be pushed along with the jdk changes? Without that >>>>>> change the Mac builds will be broken. >>>>>> >>>>>> Significant build system changes, build-dev guys are encouraged to >>>>>> comment... >>>>>> >>>>>> I tried excluding all sun/awt/X11 classes in >>>>>> CompileJavaClasses.gmk but that broke JNI header generation on >>>>>> platforms still using X11 and I couldn't use the big list of >>>>>> excluded files on Mac as that resulted in Java compilation errors, >>>>>> so I just added some logic to exclude everything on Mac and left >>>>>> the list in place everywhere else. >>>>>> >>>>>> The changes to CompileNativeLibraries.gmk will port to >>>>>> libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a >>>>>> problem in the jdk8/build workspace where the build cannot find >>>>>> symbols in JNI libs so that issue needs to be resolved first. I've >>>>>> not had time to investigate that problem. >>>>>> >>>>>> >>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>> 459 if (prefToolkit == CToolkit) { >>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>> 461 } else { >>>>>> 462 // TODO: do we still need this? >>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>> 464 } >>>>>> >>>>>> Is that necessary? Since we're now using libawt_lwawt in both >>>>>> headless and headful modes I would think we could remove the >>>>>> HToolkit option, but I'm not 100% certain about that. >>>>>> >>>>>> >>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and >>>>>> both seem to be working fine. >>>>>> >>>>>> JPRT run for Mac is in progress, I will submit one for all other >>>>>> platforms when it finishes building. >>>>>> >>>>>> -DrD- >>>>>> >>>> >>> >> From david.dehaven at oracle.com Tue Oct 22 09:09:31 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 22 Oct 2013 09:09:31 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <52665067.40102@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <52665067.40102@oracle.com> Message-ID: <9CE00A53-DEAC-4BEB-8965-6EA420451B68@oracle.com> Oops, you're right, it definitely crashes. I'll put that code back and take Artem's suggestion. -DrD- > Artem is correct. On Mac we can't start a GUI session via ssh, for example. Thus we choose the headless mode then. The isInAquaSession() is supposed to perform exactly this check. This logic needs to be preserved. > > -- > best regards, > Anthony > > On 10/22/2013 01:23 PM, Artem Ananiev wrote: >> Hi, David, >> >> thanks for additional cleanup. >> >> I have only one concern. Before the fix, we checked if there is an >> active Aqua session. When no session was found, we falled back to >> HToolkit. I think this logic should be preserved, but slightly >> corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >> >> Otherwise the only way to run headless on Mac will be to force it with >> the system property. It works this way on Windows, but on Windows we're >> sure that WToolkit can run even without a UI session. Is it also true on >> Mac? Did you try to launch AWT without -Djava.awt.headless=true from >> remote console with no users logged in? >> >> Thanks, >> >> Artem >> >> On 10/22/2013 7:34 AM, David DeHaven wrote: >>> >>> Updated webrev for JDK (hotspot change is the same): >>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>> >>> Changes since last version: >>> - Moved to jdk8/build/jdk to save someone a merge headache, moved >>> changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>> - Removed HToolkit option and toolkit selection code from >>> java_props_macosx.[ch] >>> >>> -DrD- >>> >>> >>>> I want to do one more iteration of this. Based on feedback it seems I >>>> can remove a bit more code from java_props_macosx.[ch] and make >>>> things a bit cleaner. >>>> >>>> -DrD- >>>> >>>>> Thanks guys. >>>>> >>>>> Anthony, can you sponsor this for me? >>>>> >>>>> -DrD- >>>>> >>>>>> This fix looks fine to me as well. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>> >>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>> >>>>>>> Request for review of JDK-8025673: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>> >>>>>>> Proposed changes: >>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>> >>>>>>> This change disables building libawt_xawt.dylib and >>>>>>> libawt_headless.dylib on Mac since they are not used and not >>>>>>> supported. There are too many challenges (and not enough time) in >>>>>>> removing all X11 code from the Mac build at this time, so we're >>>>>>> deferring complete removal for later (will be covered by >>>>>>> JDK-8003900). >>>>>>> >>>>>>> A small change to hotspot is required as it was looking for >>>>>>> libawt_xawt.dylib and if not found would set java.awt.headless to >>>>>>> true. Since we don't build a headless only JRE on Mac I just have >>>>>>> that method return false. I'm not sure how to handle changes to >>>>>>> hotspot, can it be pushed along with the jdk changes? Without that >>>>>>> change the Mac builds will be broken. >>>>>>> >>>>>>> Significant build system changes, build-dev guys are encouraged to >>>>>>> comment... >>>>>>> >>>>>>> I tried excluding all sun/awt/X11 classes in >>>>>>> CompileJavaClasses.gmk but that broke JNI header generation on >>>>>>> platforms still using X11 and I couldn't use the big list of >>>>>>> excluded files on Mac as that resulted in Java compilation errors, >>>>>>> so I just added some logic to exclude everything on Mac and left >>>>>>> the list in place everywhere else. >>>>>>> >>>>>>> The changes to CompileNativeLibraries.gmk will port to >>>>>>> libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a >>>>>>> problem in the jdk8/build workspace where the build cannot find >>>>>>> symbols in JNI libs so that issue needs to be resolved first. I've >>>>>>> not had time to investigate that problem. >>>>>>> >>>>>>> >>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>> 461 } else { >>>>>>> 462 // TODO: do we still need this? >>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>> 464 } >>>>>>> >>>>>>> Is that necessary? Since we're now using libawt_lwawt in both >>>>>>> headless and headful modes I would think we could remove the >>>>>>> HToolkit option, but I'm not 100% certain about that. >>>>>>> >>>>>>> >>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and >>>>>>> both seem to be working fine. >>>>>>> >>>>>>> JPRT run for Mac is in progress, I will submit one for all other >>>>>>> platforms when it finishes building. >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>> >>>> >>> From leonid.romanov at oracle.com Tue Oct 22 09:22:06 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 22 Oct 2013 20:22:06 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <52664425.4080201@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> Message-ID: <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> There was a discussion why we use HToolkit instead of HeadlessToolkit: http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html So we might want to continue using it. Also, please be aware that there is HToolkit check in GraphicsToolkit.getHeadlessProperty() On Oct 22, 2013, at 1:23 PM, Artem Ananiev wrote: > Hi, David, > > thanks for additional cleanup. > > I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). > > Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? > > Thanks, > > Artem > > On 10/22/2013 7:34 AM, David DeHaven wrote: >> >> Updated webrev for JDK (hotspot change is the same): >> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >> >> Changes since last version: >> - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >> - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] >> >> -DrD- >> >> >>> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >>> >>> -DrD- >>> >>>> Thanks guys. >>>> >>>> Anthony, can you sponsor this for me? >>>> >>>> -DrD- >>>> >>>>> This fix looks fine to me as well. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>> >>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>> >>>>>> Request for review of JDK-8025673: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>> >>>>>> Proposed changes: >>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>> >>>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>>> >>>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>>> >>>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>>> >>>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>>> >>>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>>> >>>>>> >>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>> 459 if (prefToolkit == CToolkit) { >>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>> 461 } else { >>>>>> 462 // TODO: do we still need this? >>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>> 464 } >>>>>> >>>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>>> >>>>>> >>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>>> >>>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>>> >>>>>> -DrD- >>>>>> >>>> >>> >> From steve at weblite.ca Tue Oct 22 09:27:11 2013 From: steve at weblite.ca (Steve Hannah) Date: Tue, 22 Oct 2013 09:27:11 -0700 Subject: Crash on startup in SnowLeopard 1.7.0_45 Message-ID: I have an app that is bundled using appbundler. On Lion the app works fine. On Snow Leopard (10.6.8) it works fine if I bundle it with jdk1.7.0_25 (oracle), but if I bundle it with jdk1.7.0_45 (oracle), it crashes on startup. Crash log pasted at end of this message. Is this a known regression? Steve Just before crashing, the following messages are written in Console: 13-10-22 9:14:08 AM JavaAppLauncher[388] *** NSInvocation: warning: object 0x109714390 of class 'ThreadUtilities' does not implement methodSignatureForSelector: -- trouble ahead 13-10-22 9:14:08 AM JavaAppLauncher[388] *** NSInvocation: warning: object 0x109714390 of class 'ThreadUtilities' does not implement doesNotRecognizeSelector: -- abort Crash log follows: Process: JavaAppLauncher [388] Path: /Volumes/Windows VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community Edition.app/Contents/MacOS/JavaAppLauncher Identifier: ca.weblite.PDFOCRX.CommunityEdition Version: 2.0.0 (2.0.0) Code Type: X86-64 (Native) Parent Process: launchd [104] Date/Time: 2013-10-22 09:14:08.935 -0700 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 0 Thread 0 Crashed: 0 com.apple.CoreFoundation 0x00007fff861a88a1 ___forwarding___ + 673 1 com.apple.CoreFoundation 0x00007fff861a4a38 _CF_forwarding_prep_0 + 232 2 libobjc.A.dylib 0x00007fff83540325 _class_initialize + 384 3 libobjc.A.dylib 0x00007fff8354e52b prepareForMethodLookup + 234 4 libobjc.A.dylib 0x00007fff83546cb9 lookUpMethod + 73 5 libobjc.A.dylib 0x00007fff8353efaa objc_msgSend + 198 6 libosxapp.dylib 0x000000010970ea77 -[NSApplicationAWT registerWithProcessManager] + 124 7 libosxapp.dylib 0x000000010970e493 -[NSApplicationAWT init] + 140 8 com.apple.AppKit 0x00007fff802350fa +[NSApplication sharedApplication] + 149 9 liblwawt.dylib 0x000000010966394a -[AWTStarter starter:] + 266 10 com.apple.Foundation 0x00007fff8676445f __NSThreadPerformPerform + 219 11 com.apple.CoreFoundation 0x00007fff861733d1 __CFRunLoopDoSources0 + 1361 12 com.apple.CoreFoundation 0x00007fff861715c9 __CFRunLoopRun + 873 13 com.apple.CoreFoundation 0x00007fff86170d8f CFRunLoopRunSpecific + 575 14 libjli.dylib 0x000000010003a824 CreateExecutionEnvironment + 871 15 libjli.dylib 0x0000000100034fd0 JLI_Launch + 1952 16 ...te.PDFOCRX.CommunityEdition 0x00000001067af804 launch + 8468 17 ...te.PDFOCRX.CommunityEdition 0x00000001067ad4d6 main + 102 18 ...te.PDFOCRX.CommunityEdition 0x00000001067ad464 start + 52 Thread 1: 0 libSystem.B.dylib 0x00007fff874ebc0a kevent + 10 1 libSystem.B.dylib 0x00007fff874edadd _dispatch_mgr_invoke + 154 2 libSystem.B.dylib 0x00007fff874ed7b4 _dispatch_queue_invoke + 185 3 libSystem.B.dylib 0x00007fff874ed2de _dispatch_worker_thread2 + 252 4 libSystem.B.dylib 0x00007fff874ecc08 _pthread_wqthread + 353 5 libSystem.B.dylib 0x00007fff874ecaa5 start_wqthread + 13 Thread 2: 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 1 libSystem.B.dylib 0x00007fff87534896 pthread_join + 844 2 libjli.dylib 0x0000000100039e24 ContinueInNewThread0 + 102 3 libjli.dylib 0x0000000100035c3b ContinueInNewThread + 201 4 libjli.dylib 0x0000000100039bf9 JVMInit + 315 5 libjli.dylib 0x00000001000359b9 JLI_Launch + 4489 6 ...te.PDFOCRX.CommunityEdition 0x00000001067af804 launch + 8468 7 ...te.PDFOCRX.CommunityEdition 0x00000001067ad4d6 main + 102 8 libjli.dylib 0x000000010003a4b6 apple_main + 92 9 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 10 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 Thread 3: 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + 1286 2 liblwawt.dylib 0x00000001096637b7 +[AWTStarter start:] + 598 3 liblwawt.dylib 0x0000000109663f42 JNI_OnLoad + 480 4 libjava.dylib 0x0000000100604e76 Java_java_lang_ClassLoader_00024NativeLibrary_load + 207 5 ??? 0x0000000102274738 0 + 4331095864 6 ??? 0x0000000102268058 0 + 4331044952 7 ??? 0x0000000102268350 0 + 4331045712 8 ??? 0x0000000102268350 0 + 4331045712 9 ??? 0x0000000102268058 0 + 4331044952 10 ??? 0x0000000102268058 0 + 4331044952 11 ??? 0x00000001022624e7 0 + 4331021543 12 libjvm.dylib 0x0000000101ad6d90 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554 13 libjvm.dylib 0x0000000101ad6b60 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 14 libjvm.dylib 0x0000000101b0a304 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 230 15 libjvm.dylib 0x0000000101b0358b jni_CallStaticVoidMethodV + 156 16 libjava.dylib 0x000000010060bcff JNU_CallStaticMethodByName + 282 17 libawt.dylib 0x000000010953282c AWT_OnLoad + 389 18 libawt.dylib 0x0000000109532873 JNI_OnLoad + 9 19 libjava.dylib 0x0000000100604e76 Java_java_lang_ClassLoader_00024NativeLibrary_load + 207 20 ??? 0x0000000102274738 0 + 4331095864 21 ??? 0x0000000102268058 0 + 4331044952 22 ??? 0x0000000102268350 0 + 4331045712 23 ??? 0x0000000102268350 0 + 4331045712 24 ??? 0x0000000102268058 0 + 4331044952 25 ??? 0x0000000102268058 0 + 4331044952 26 ??? 0x0000000102268058 0 + 4331044952 27 ??? 0x0000000102268233 0 + 4331045427 28 ??? 0x00000001022624e7 0 + 4331021543 29 libjvm.dylib 0x0000000101ad6d90 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554 30 libjvm.dylib 0x0000000101ad6b60 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 31 libjvm.dylib 0x0000000101b2a444 JVM_DoPrivileged + 1041 32 ??? 0x0000000102274738 0 + 4331095864 33 ??? 0x0000000102268233 0 + 4331045427 34 ??? 0x0000000102268058 0 + 4331044952 35 ??? 0x00000001022624e7 0 + 4331021543 36 libjvm.dylib 0x0000000101ad6d90 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554 37 libjvm.dylib 0x0000000101ad6b60 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 38 libjvm.dylib 0x0000000101aac367 instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) + 147 39 libjvm.dylib 0x0000000101aad856 instanceKlass::initialize_impl(instanceKlassHandle, Thread*) + 1484 40 libjvm.dylib 0x0000000101a9fd01 instanceKlass::initialize(Thread*) + 85 41 libjvm.dylib 0x0000000101b9f5ab LinkResolver::resolve_static_call(CallInfo&, KlassHandle&, Symbol*, Symbol*, KlassHandle, bool, bool, Thread*) + 173 42 libjvm.dylib 0x0000000101b9f691 LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle, int, Thread*) + 129 43 libjvm.dylib 0x0000000101ad1f22 InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code) + 550 44 ??? 0x000000010227f828 0 + 4331141160 45 ??? 0x00000001022624e7 0 + 4331021543 46 libjvm.dylib 0x0000000101ad6d90 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554 47 libjvm.dylib 0x0000000101ad6b60 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 48 libjvm.dylib 0x0000000101aac367 instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) + 147 49 libjvm.dylib 0x0000000101aad856 instanceKlass::initialize_impl(instanceKlassHandle, Thread*) + 1484 50 libjvm.dylib 0x0000000101a9fd01 instanceKlass::initialize(Thread*) + 85 51 libjvm.dylib 0x0000000101b23810 find_class_from_class_loader(JNIEnv_*, Symbol*, unsigned char, Handle, Handle, unsigned char, Thread*) + 120 52 libjvm.dylib 0x0000000101b2bf84 JVM_FindClassFromClassLoader + 267 53 libjava.dylib 0x0000000100604baf Java_java_lang_Class_forName0 + 305 54 ??? 0x0000000102274738 0 + 4331095864 55 ??? 0x0000000102268233 0 + 4331045427 56 ??? 0x0000000102268233 0 + 4331045427 57 ??? 0x00000001022624e7 0 + 4331021543 58 libjvm.dylib 0x0000000101ad6d90 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554 59 libjvm.dylib 0x0000000101ad6b60 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 60 libjvm.dylib 0x0000000101aac367 instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) + 147 61 libjvm.dylib 0x0000000101aad856 instanceKlass::initialize_impl(instanceKlassHandle, Thread*) + 1484 62 libjvm.dylib 0x0000000101a9fd01 instanceKlass::initialize(Thread*) + 85 63 libjvm.dylib 0x0000000101b9f5ab LinkResolver::resolve_static_call(CallInfo&, KlassHandle&, Symbol*, Symbol*, KlassHandle, bool, bool, Thread*) + 173 64 libjvm.dylib 0x0000000101b9f691 LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle, int, Thread*) + 129 65 libjvm.dylib 0x0000000101ad1f22 InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code) + 550 66 ??? 0x000000010227f828 0 + 4331141160 67 ??? 0x0000000102268058 0 + 4331044952 68 ??? 0x00000001022624e7 0 + 4331021543 69 libjvm.dylib 0x0000000101ad6d90 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554 70 libjvm.dylib 0x0000000101ad6b60 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 71 libjvm.dylib 0x0000000101aac367 instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) + 147 72 libjvm.dylib 0x0000000101aad856 instanceKlass::initialize_impl(instanceKlassHandle, Thread*) + 1484 73 libjvm.dylib 0x0000000101a9fd01 instanceKlass::initialize(Thread*) + 85 74 libjvm.dylib 0x0000000101b9f5ab LinkResolver::resolve_static_call(CallInfo&, KlassHandle&, Symbol*, Symbol*, KlassHandle, bool, bool, Thread*) + 173 75 libjvm.dylib 0x0000000101b9f691 LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle, int, Thread*) + 129 76 libjvm.dylib 0x0000000101ad1f22 InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code) + 550 77 ??? 0x000000010227f81a 0 + 4331141146 78 ??? 0x00000001022624e7 0 + 4331021543 79 libjvm.dylib 0x0000000101ad6d90 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554 80 libjvm.dylib 0x0000000101ad6b60 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 81 libjvm.dylib 0x0000000101aac367 instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) + 147 82 libjvm.dylib 0x0000000101aad856 instanceKlass::initialize_impl(instanceKlassHandle, Thread*) + 1484 83 libjvm.dylib 0x0000000101a9fd01 instanceKlass::initialize(Thread*) + 85 84 libjvm.dylib 0x0000000101ad2fad InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) + 161 85 ??? 0x00000001022801a5 0 + 4331143589 86 ??? 0x0000000102268058 0 + 4331044952 87 ??? 0x00000001022624e7 0 + 4331021543 88 libjvm.dylib 0x0000000101ad6d90 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554 89 libjvm.dylib 0x0000000101ad6b60 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 90 libjvm.dylib 0x0000000101b0a304 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 230 91 libjvm.dylib 0x0000000101b0349f jni_CallStaticVoidMethod + 267 92 libjli.dylib 0x0000000100036572 JavaMain + 2333 93 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 94 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 Thread 4: 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + 1286 2 libjvm.dylib 0x0000000101c16e29 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x0000000101bf70be ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x0000000101bf78b0 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x0000000101a68e6e GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x0000000101a69d63 GCTaskThread::run() + 349 8 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + 294 9 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 10 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 Thread 5: 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + 1286 2 libjvm.dylib 0x0000000101c16e29 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x0000000101bf70be ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x0000000101bf78b0 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x0000000101a68e6e GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x0000000101a69d63 GCTaskThread::run() + 349 8 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + 294 9 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 10 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 Thread 6: 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + 1286 2 libjvm.dylib 0x0000000101c17ddb os::PlatformEvent::park(long long) + 385 3 libjvm.dylib 0x0000000101bf78b0 Monitor::IWait(Thread*, long long) + 160 4 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, long, bool) + 375 5 libjvm.dylib 0x0000000101d2a8b0 VMThread::loop() + 444 6 libjvm.dylib 0x0000000101d2a35b VMThread::run() + 121 7 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + 294 8 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 9 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 Thread 7: Java: Reference Handler 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + 1286 2 libjvm.dylib 0x0000000101c16e29 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x0000000101c0fe57 ObjectMonitor::wait(long long, bool, Thread*) + 757 4 libjvm.dylib 0x0000000101cbf4a3 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x0000000101b2b0fc JVM_MonitorWait + 156 6 ??? 0x0000000102274738 0 + 4331095864 7 ??? 0x0000000102268058 0 + 4331044952 8 ??? 0x0000000102268058 0 + 4331044952 9 ??? 0x00000001022624e7 0 + 4331021543 10 libjvm.dylib 0x0000000101ad6d90 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554 11 libjvm.dylib 0x0000000101ad72a7 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 283 12 libjvm.dylib 0x0000000101ad73e4 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 13 libjvm.dylib 0x0000000101b263ca thread_entry(JavaThread*, Thread*) + 173 14 libjvm.dylib 0x0000000101cefb47 JavaThread::thread_main_inner() + 155 15 libjvm.dylib 0x0000000101cf124f JavaThread::run() + 419 16 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + 294 17 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 18 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 Thread 8: Java: Finalizer 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + 1286 2 libjvm.dylib 0x0000000101c16e29 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x0000000101c0fe57 ObjectMonitor::wait(long long, bool, Thread*) + 757 4 libjvm.dylib 0x0000000101cbf4a3 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x0000000101b2b0fc JVM_MonitorWait + 156 6 ??? 0x0000000102274738 0 + 4331095864 7 ??? 0x0000000102268058 0 + 4331044952 8 ??? 0x0000000102268233 0 + 4331045427 9 ??? 0x0000000102268233 0 + 4331045427 10 ??? 0x00000001022624e7 0 + 4331021543 11 libjvm.dylib 0x0000000101ad6d90 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554 12 libjvm.dylib 0x0000000101ad72a7 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 283 13 libjvm.dylib 0x0000000101ad73e4 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 14 libjvm.dylib 0x0000000101b263ca thread_entry(JavaThread*, Thread*) + 173 15 libjvm.dylib 0x0000000101cefb47 JavaThread::thread_main_inner() + 155 16 libjvm.dylib 0x0000000101cf124f JavaThread::run() + 419 17 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + 294 18 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 19 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 Thread 9: 0 libSystem.B.dylib 0x00007fff874eca2a __workq_kernreturn + 10 1 libSystem.B.dylib 0x00007fff874ece3c _pthread_wqthread + 917 2 libSystem.B.dylib 0x00007fff874ecaa5 start_wqthread + 13 Thread 10: Java: Signal Dispatcher 0 libSystem.B.dylib 0x00007fff874d2db6 semaphore_wait_trap + 10 1 libjvm.dylib 0x0000000101c194a0 check_pending_signals(bool) + 128 2 libjvm.dylib 0x0000000101c15da8 signal_thread_entry(JavaThread*, Thread*) + 57 3 libjvm.dylib 0x0000000101cefb47 JavaThread::thread_main_inner() + 155 4 libjvm.dylib 0x0000000101cf124f JavaThread::run() + 419 5 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + 294 6 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 7 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 Thread 11: Java: C2 CompilerThread0 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + 1286 2 libjvm.dylib 0x0000000101c16e29 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x0000000101bf70be ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x0000000101bf78b0 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x0000000101bf7a74 Monitor::wait(bool, long, bool) + 222 6 libjvm.dylib 0x00000001019c10ab CompileQueue::get() + 153 7 libjvm.dylib 0x00000001019c1c43 CompileBroker::compiler_thread_loop() + 425 8 libjvm.dylib 0x0000000101cefb47 JavaThread::thread_main_inner() + 155 9 libjvm.dylib 0x0000000101cf124f JavaThread::run() + 419 10 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + 294 11 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 12 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 Thread 12: Java: C2 CompilerThread1 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + 1286 2 libjvm.dylib 0x0000000101c16e29 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x0000000101bf70be ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x0000000101bf78b0 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x0000000101bf7a74 Monitor::wait(bool, long, bool) + 222 6 libjvm.dylib 0x00000001019c10ab CompileQueue::get() + 153 7 libjvm.dylib 0x00000001019c1c43 CompileBroker::compiler_thread_loop() + 425 8 libjvm.dylib 0x0000000101cefb47 JavaThread::thread_main_inner() + 155 9 libjvm.dylib 0x0000000101cf124f JavaThread::run() + 419 10 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + 294 11 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 12 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 Thread 13: Java: Service Thread 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + 1286 2 libjvm.dylib 0x0000000101c16e29 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x0000000101bf70be ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x0000000101bf78b0 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x0000000101c6f1d5 ServiceThread::service_thread_entry(JavaThread*, Thread*) + 109 7 libjvm.dylib 0x0000000101cefb47 JavaThread::thread_main_inner() + 155 8 libjvm.dylib 0x0000000101cf124f JavaThread::run() + 419 9 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + 294 10 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 11 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 Thread 14: 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + 1286 2 libjvm.dylib 0x0000000101c17ddb os::PlatformEvent::park(long long) + 385 3 libjvm.dylib 0x0000000101bf78b0 Monitor::IWait(Thread*, long long) + 160 4 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, long, bool) + 375 5 libjvm.dylib 0x0000000101cf001a WatcherThread::sleep() const + 126 6 libjvm.dylib 0x0000000101cf0edd WatcherThread::run() + 243 7 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + 294 8 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 9 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x00007fff809c8734 rcx: 0x0000000000000000 rdx: 0x00007fff70e7acc0 rdi: 0x000000000000003b rsi: 0x0000000000000001 rbp: 0x00007fff5fbfc740 rsp: 0x00007fff5fbfc6f0 r8: 0x0000000000000001 r9: 0x00000001003266c0 r10: 0x0000000000000001 r11: 0x000000000000003f r12: 0x0000000000000000 r13: 0x0000000109714390 r14: 0x00000001097143b8 r15: 0x0000000109714390 rip: 0x00007fff861a88a1 rfl: 0x0000000000000287 cr2: 0x0000000108cff000 Binary Images: 0x100033000 - 0x10003dfff +libjli.dylib ??? (???) <32A3CEF6-9D91-3B97-9F17-CAD9301081D1> /Volumes/Windows VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/jli/libjli.dylib 0x1000ec000 - 0x1000f4fff +libverify.dylib ??? (???) /Volumes/Windows VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libverify.dylib 0x1002e2000 - 0x1002e7fff +libzip.dylib ??? (???) <50D7966F-6590-3F9A-A42B-7E7EE016493E> /Volumes/Windows VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libzip.dylib 0x1002ee000 - 0x1002f3ff7 com.apple.JavaVM 13.9.8 (13.9.8) /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM 0x100603000 - 0x100624fe7 +libjava.dylib ??? (???) <64871BED-E504-307F-BCEE-EA4CCEA588EA> /Volumes/Windows VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libjava.dylib 0x101800000 - 0x101f45fef +libjvm.dylib ??? (???) <7CBD0F39-332A-3790-B0FF-F5F955C325A6> /Volumes/Windows VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/server/libjvm.dylib 0x1066c6000 - 0x1066d1fef com.apple.java.JavaRuntimeSupport 13.9.8 (13.9.8) <78E0442F-7DF4-5DAA-2DF1-1570AE1AAEC8> /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/JavaRuntimeSupport 0x1066e2000 - 0x1066edfff JavaNativeFoundation ??? (???) <81035866-C9A3-6ADC-920F-A2C02D6DB95B> /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation 0x1066f8000 - 0x1066feff7 JavaLaunching ??? (???) <8A4FFBEC-90DB-3EB1-68E7-4EF8A0F47F52> /System/Library/PrivateFrameworks/JavaLaunching.framework/Versions/A/JavaLaunching 0x1067ac000 - 0x1067affff +ca.weblite.PDFOCRX.CommunityEdition 2.0.0 (2.0.0) <085DD0B7-34B2-3A2D-BFC7-4CA094FC70DE> /Volumes/Windows VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community Edition.app/Contents/MacOS/JavaAppLauncher 0x1094d4000 - 0x10953ffff +libawt.dylib ??? (???) <5F027771-D669-392F-8DD7-CBA3EA5DD87D> /Volumes/Windows VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libawt.dylib 0x109586000 - 0x10964bfff +libmlib_image.dylib ??? (???) <95F6D0B2-3A92-305F-A6AE-822BC990901B> /Volumes/Windows VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libmlib_image.dylib 0x109656000 - 0x1096c6fff +liblwawt.dylib ??? (???) <9875DBAB-B5B6-322C-A085-4651CEDFCBF4> /Volumes/Windows VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/lwawt/liblwawt.dylib 0x10970d000 - 0x109712fff +libosxapp.dylib ??? (???) <8CE761D7-7DAA-36BA-8424-BF74590F8C1D> /Volumes/Windows VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libosxapp.dylib 0x7fff5fc00000 - 0x7fff5fc3be0f dyld 132.1 (???) <29DECB19-0193-2575-D838-CF743F0400B2> /usr/lib/dyld 0x7fff80003000 - 0x7fff80093fff com.apple.SearchKit 1.3.0 (1.3.0) <4175DC31-1506-228A-08FD-C704AC9DF642> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x7fff80094000 - 0x7fff80171fff com.apple.vImage 4.1 (4.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x7fff80172000 - 0x7fff801f7ff7 com.apple.print.framework.PrintCore 6.3 (312.7) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x7fff801f8000 - 0x7fff8020ffff com.apple.ImageCapture 6.1 (6.1) <79AB2131-2A6C-F351-38A9-ED58B25534FD> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x7fff80222000 - 0x7fff80231fff com.apple.NetFS 3.2.2 (3.2.2) <7CCBD70E-BF31-A7A7-DB98-230687773145> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x7fff80232000 - 0x7fff80c2cff7 com.apple.AppKit 6.6.8 (1038.36) <4CFBE04C-8FB3-B0EA-8DDB-7E7D10E9D251> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x7fff80c2d000 - 0x7fff80c34fff com.apple.OpenDirectory 10.6 (10.6) <4FF6AD25-0916-B21C-9E88-2CC42D90EAC7> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 0x7fff80c35000 - 0x7fff80cf2fff com.apple.CoreServices.OSServices 359.2 (359.2) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x7fff80d25000 - 0x7fff80d4aff7 com.apple.CoreVideo 1.6.2 (45.6) /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x7fff80d70000 - 0x7fff80db1fff com.apple.SystemConfiguration 1.10.8 (1.10.2) <78D48D27-A9C4-62CA-2803-D0BBED82855A> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x7fff810ad000 - 0x7fff81162fe7 com.apple.ink.framework 1.3.3 (107) <8C36373C-5473-3A6A-4972-BC29D504250F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x7fff8116f000 - 0x7fff811d9fe7 libvMisc.dylib 268.0.1 (compatibility 1.0.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x7fff81464000 - 0x7fff81504fff com.apple.LaunchServices 362.3 (362.3) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x7fff81505000 - 0x7fff81551fff libauto.dylib ??? (???) /usr/lib/libauto.dylib 0x7fff81552000 - 0x7fff81583fff libGLImage.dylib ??? (???) <562565E1-AA65-FE96-13FF-437410C886D0> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x7fff81584000 - 0x7fff81584ff7 com.apple.Cocoa 6.6 (???) <68B0BE46-6E24-C96F-B341-054CF9E8F3B6> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 0x7fff81be0000 - 0x7fff81cb4fe7 com.apple.CFNetwork 454.12.4 (454.12.4) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x7fff81e7a000 - 0x7fff82576ff7 com.apple.CoreGraphics 1.545.0 (???) <58D597B1-EB3B-710E-0B8C-EC114D54E11B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x7fff82605000 - 0x7fff82628fff com.apple.opencl 12.3.6 (12.3.6) <42FA5783-EB80-1168-4015-B8C68F55842F> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 0x7fff82629000 - 0x7fff826a6fef libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) <35ECA411-2C08-FD7D-11B1-1B7A04921A5C> /usr/lib/libstdc++.6.dylib 0x7fff82a14000 - 0x7fff82a17ff7 libCoreVMClient.dylib ??? (???) <75819794-3B7A-8944-D004-7EA6DD7CE836> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib 0x7fff82a18000 - 0x7fff82a5fff7 com.apple.coreui 2 (114) <923E33CC-83FC-7D35-5603-FB8F348EE34B> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI 0x7fff82a9e000 - 0x7fff82af4fe7 libTIFF.dylib ??? (???) <2DBEC120-DAA7-3789-36A2-A205BCDF2D72> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x7fff83344000 - 0x7fff83359ff7 com.apple.LangAnalysis 1.6.6 (1.6.6) <1AE1FE8F-2204-4410-C94E-0E93B003BEDA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x7fff8335a000 - 0x7fff8335ffff libGIF.dylib ??? (???) <3BAD0DE8-8151-68B0-2244-A4541C738972> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib 0x7fff83360000 - 0x7fff83361fff liblangid.dylib ??? (???) /usr/lib/liblangid.dylib 0x7fff83362000 - 0x7fff833a3fef com.apple.QD 3.36 (???) <5DC41E81-32C9-65B2-5528-B33E934D5BB4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x7fff833a4000 - 0x7fff833a6fff libRadiance.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x7fff833a7000 - 0x7fff83419fef com.apple.CoreSymbolication 2.0 (23) <06F8561E-4B36-7BF6-31BA-64091B3D8058> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication 0x7fff834a4000 - 0x7fff83530fef SecurityFoundation ??? (???) <3F1F2727-C508-3630-E2C1-38361841FCE4> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation 0x7fff8353a000 - 0x7fff835f0ff7 libobjc.A.dylib 227.0.0 (compatibility 1.0.0) <03140531-3B2D-1EBA-DA7F-E12CC8F63969> /usr/lib/libobjc.A.dylib 0x7fff837b2000 - 0x7fff837edfff com.apple.AE 496.5 (496.5) <208DF391-4DE6-81ED-C697-14A2930D1BC6> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x7fff837f8000 - 0x7fff839b6fff libicucore.A.dylib 40.0.0 (compatibility 1.0.0) <97A75BFB-0DB6-6F44-36B0-97B7F7208ABB> /usr/lib/libicucore.A.dylib 0x7fff839b7000 - 0x7fff839bbff7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib 0x7fff839bc000 - 0x7fff839e3ff7 libJPEG.dylib ??? (???) <08758593-6436-B29E-1DA8-F15597835EC1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x7fff83add000 - 0x7fff83ae8ff7 com.apple.speech.recognition.framework 3.11.1 (3.11.1) <3D65E89B-FFC6-4AAF-D5CC-104F967C8131> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0x7fff83c02000 - 0x7fff83c40fef com.apple.DebugSymbols 1.1 (70) /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols 0x7fff83d01000 - 0x7fff83d01ff7 com.apple.CoreServices 44 (44) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x7fff84046000 - 0x7fff8404cff7 IOSurface ??? (???) <8E302BB2-0704-C6AB-BD2F-C2A6C6A2E2C3> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface 0x7fff8404d000 - 0x7fff84095ff7 libvDSP.dylib 268.0.1 (compatibility 1.0.0) <98FC4457-F405-0262-00F7-56119CA107B6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x7fff845e4000 - 0x7fff8460cfff com.apple.DictionaryServices 1.1.2 (1.1.2) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x7fff84615000 - 0x7fff847d4fff com.apple.ImageIO.framework 3.0.6 (3.0.6) <92882FD3-CB3F-D0BE-DDDA-43B4BEE10F58> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x7fff847d5000 - 0x7fff84b72fe7 com.apple.QuartzCore 1.6.3 (227.37) <16DFF6CD-EA58-CE62-A1D7-5F6CE3D066DD> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x7fff84b73000 - 0x7fff84b81ff7 libkxld.dylib ??? (???) <8145A534-95CC-9F3C-B78B-AC9898F38C6F> /usr/lib/system/libkxld.dylib 0x7fff84ca0000 - 0x7fff84ce9fef libGLU.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x7fff84d2c000 - 0x7fff84d4dfff libresolv.9.dylib 41.1.0 (compatibility 1.0.0) <9410EC7F-4D24-6740-AFEE-90405750FAD7> /usr/lib/libresolv.9.dylib 0x7fff84d4e000 - 0x7fff84e64ff7 libxml2.2.dylib 10.3.0 (compatibility 10.0.0) <3814FCF9-92B9-A6AB-E76A-F7021894AA3F> /usr/lib/libxml2.2.dylib 0x7fff84ef7000 - 0x7fff85016ff7 libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) <0CE8D59B-D0C7-1DCE-3654-37F27F61BEFA> /usr/lib/libcrypto.0.9.8.dylib 0x7fff85017000 - 0x7fff85017ff7 com.apple.ApplicationServices 38 (38) <10A0B9E9-4988-03D4-FC56-DDE231A02C63> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x7fff8547c000 - 0x7fff85596fff libGLProgrammability.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib 0x7fff856df000 - 0x7fff856dfff7 com.apple.Carbon 150 (152) <23704665-E9F4-6B43-1115-2E69F161FC45> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x7fff85720000 - 0x7fff85726ff7 com.apple.CommerceCore 1.0 (9.1) <3691E9BA-BCF4-98C7-EFEC-78DA6825004E> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore 0x7fff857dd000 - 0x7fff858c2fef com.apple.DesktopServices 1.5.11 (1.5.11) <39FAA3D2-6863-B5AB-AED9-92D878EA2438> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x7fff858c3000 - 0x7fff858eeff7 libxslt.1.dylib 3.24.0 (compatibility 3.0.0) <3630A97F-55C1-3F34-CA63-3847653C9645> /usr/lib/libxslt.1.dylib 0x7fff8596b000 - 0x7fff85a2dfe7 libFontParser.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib 0x7fff85caa000 - 0x7fff85cbefff libGL.dylib ??? (???) <2ECE3B0F-39E1-3938-BF27-7205C6D0358B> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x7fff85f15000 - 0x7fff85f29ff7 com.apple.speech.synthesis.framework 3.10.35 (3.10.35) <621B7415-A0B9-07A7-F313-36BEEDD7B132> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x7fff86125000 - 0x7fff8629cfe7 com.apple.CoreFoundation 6.6.6 (550.44) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff863a6000 - 0x7fff863b5fef com.apple.opengl 1.6.14 (1.6.14) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x7fff863b6000 - 0x7fff86477fef com.apple.ColorSync 4.6.8 (4.6.8) <7DF1D175-6451-51A2-DBBF-40FCA78C0D2C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x7fff86478000 - 0x7fff86512fff com.apple.ApplicationServices.ATS 275.19 (???) <2DE8987F-4563-4D8E-45C3-2F6F786E120D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x7fff86513000 - 0x7fff86648fff com.apple.audio.toolbox.AudioToolbox 1.6.7 (1.6.7) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 0x7fff86716000 - 0x7fff86716ff7 com.apple.Accelerate.vecLib 3.6 (vecLib 3.6) <4CCE5D69-F1B3-8FD3-1483-E0271DB2CCF3> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff86717000 - 0x7fff8672dfe7 com.apple.MultitouchSupport.framework 207.11 (207.11) <8233CE71-6F8D-8B3C-A0E1-E123F6406163> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport 0x7fff8673c000 - 0x7fff869befff com.apple.Foundation 6.6.8 (751.63) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff869bf000 - 0x7fff869c0ff7 com.apple.TrustEvaluationAgent 1.1 (1) <5952A9FA-BC2B-16EF-91A7-43902A5C07B6> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0x7fff869c1000 - 0x7fff86cbffff com.apple.HIToolbox 1.6.5 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x7fff86cc0000 - 0x7fff86cc3fff com.apple.help 1.3.2 (41.1) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x7fff86d04000 - 0x7fff86d09ff7 com.apple.CommonPanels 1.2.4 (91) <4D84803B-BD06-D80E-15AE-EFBE43F93605> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x7fff86d3b000 - 0x7fff8706ffef com.apple.CoreServices.CarbonCore 861.39 (861.39) <1386A24D-DD15-5903-057E-4A224FAF580B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x7fff87070000 - 0x7fff871aefff com.apple.CoreData 102.1 (251) <9DFE798D-AA52-6A9A-924A-DA73CB94D81A> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData 0x7fff872e4000 - 0x7fff872e4ff7 com.apple.vecLib 3.6 (vecLib 3.6) <96FB6BAD-5568-C4E0-6FA7-02791A58B584> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff872e5000 - 0x7fff872e6ff7 com.apple.audio.units.AudioUnit 1.6.7 (1.6.7) <49B723D1-85F8-F86C-2331-F586C56D68AF> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit 0x7fff873c0000 - 0x7fff873dbff7 com.apple.openscripting 1.3.1 (???) <9D50701D-54AC-405B-CC65-026FCB28258B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x7fff873dc000 - 0x7fff87416fff libcups.2.dylib 2.8.0 (compatibility 2.0.0) <4F2A4397-89BD-DEAC-4971-EE838FFA0964> /usr/lib/libcups.2.dylib 0x7fff87430000 - 0x7fff874affe7 com.apple.audio.CoreAudio 3.2.6 (3.2.6) <79E256EB-43F1-C7AA-6436-124A4FFB02D0> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x7fff874b0000 - 0x7fff874d1fe7 libPng.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x7fff874d2000 - 0x7fff87693fef libSystem.B.dylib 125.2.11 (compatibility 1.0.0) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib 0x7fff87694000 - 0x7fff87696fff com.apple.print.framework.Print 6.1 (237.1) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x7fff876ad000 - 0x7fff876b2fff libGFXShared.dylib ??? (???) <6BBC351E-40B3-F4EB-2F35-05BDE52AF87E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib 0x7fff876b3000 - 0x7fff876c9fef libbsm.0.dylib ??? (???) <42D3023A-A1F7-4121-6417-FCC6B51B3E90> /usr/lib/libbsm.0.dylib 0x7fff8788c000 - 0x7fff8788efef com.apple.ExceptionHandling 1.5 (10) /System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ExceptionHandling 0x7fff8788f000 - 0x7fff8790dff7 com.apple.CoreText 151.13 (???) <5C6214AD-D683-80A8-86EB-328C99B75322> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText 0x7fff8790e000 - 0x7fff8790eff7 com.apple.Accelerate 1.6 (Accelerate 1.6) <15DF8B4A-96B2-CB4E-368D-DEC7DF6B62BB> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x7fff8790f000 - 0x7fff87b98ff7 com.apple.security 6.1.2 (55002) /System/Library/Frameworks/Security.framework/Versions/A/Security 0x7fff88c04000 - 0x7fff88c57ff7 com.apple.HIServices 1.8.3 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x7fff88c59000 - 0x7fff88c72fff com.apple.CFOpenDirectory 10.6 (10.6) <401557B1-C6D1-7E1A-0D7E-941715C37BFA> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory 0x7fff88c97000 - 0x7fff88cecff7 com.apple.framework.familycontrols 2.0.2 (2020) <8807EB96-D12D-8601-2E74-25784A0DE4FF> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls 0x7fff88cfb000 - 0x7fff88db4fff libsqlite3.dylib 9.6.0 (compatibility 9.0.0) <2C5ED312-E646-9ADE-73A9-6199A2A43150> /usr/lib/libsqlite3.dylib 0x7fff88dc7000 - 0x7fff88de7fff com.apple.DirectoryService.Framework 3.6 (621.16) <0ED4A74A-F8FB-366D-6588-F13EA397326F> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService 0x7fff88de8000 - 0x7fff88deeff7 com.apple.DiskArbitration 2.3 (2.3) <857F6E43-1EF4-7D53-351B-10DE0A8F992A> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x7fff89584000 - 0x7fff89d8efe7 libBLAS.dylib 219.0.0 (compatibility 1.0.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x7fff89e94000 - 0x7fff89edeff7 com.apple.Metadata 10.6.3 (507.15) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x7fff89edf000 - 0x7fff89ef0ff7 libz.1.dylib 1.2.3 (compatibility 1.0.0) <97019C74-161A-3488-41EC-A6CA8738418C> /usr/lib/libz.1.dylib 0x7fff89ef1000 - 0x7fff89fa1fff edu.mit.Kerberos 6.5.11 (6.5.11) <085D80F5-C9DC-E252-C21B-03295E660C91> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x7fff89fa2000 - 0x7fff89fb4fe7 libsasl2.2.dylib 3.15.0 (compatibility 3.0.0) <76B83C8D-8EFE-4467-0F75-275648AFED97> /usr/lib/libsasl2.2.dylib 0x7fff8a1ac000 - 0x7fff8a20cfe7 com.apple.framework.IOKit 2.0 (???) <4F071EF0-8260-01E9-C641-830E582FA416> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x7fff8a27a000 - 0x7fff8a27dff7 com.apple.securityhi 4.0 (36638) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x7fff8a27e000 - 0x7fff8a6c1fef libLAPACK.dylib 219.0.0 (compatibility 1.0.0) <0CC61C98-FF51-67B3-F3D8-C5E430C201A9> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x7fff8a6c2000 - 0x7fff8a711ff7 com.apple.DirectoryService.PasswordServerFramework 6.1 (6.1) <0731C40D-71EF-B417-C83B-54C3527A36EA> /System/Library/PrivateFrameworks/PasswordServer.framework/Versions/A/PasswordServer 0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib ??? (???) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib From anthony.petrov at oracle.com Tue Oct 22 10:54:34 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Oct 2013 21:54:34 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> Message-ID: <5266BBDA.2010106@oracle.com> We don't have to. IIRC, the choice of HToolkit on Mac was made by chance. Since we must load the lwawt lib in headless on Mac anyway, we may as well use the CToolkit (properly wrapped in the HeadlessToolkit). But there's no need to continue to use the HToolkit on Mac. -- best regards, Anthony On 10/22/2013 08:22 PM, Leonid Romanov wrote: > There was a discussion why we use HToolkit instead of HeadlessToolkit: > http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html > > So we might want to continue using it. > > Also, please be aware that there is HToolkit check in GraphicsToolkit.getHeadlessProperty() > > On Oct 22, 2013, at 1:23 PM, Artem Ananiev wrote: > >> Hi, David, >> >> thanks for additional cleanup. >> >> I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >> >> Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? >> >> Thanks, >> >> Artem >> >> On 10/22/2013 7:34 AM, David DeHaven wrote: >>> >>> Updated webrev for JDK (hotspot change is the same): >>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>> >>> Changes since last version: >>> - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>> - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] >>> >>> -DrD- >>> >>> >>>> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >>>> >>>> -DrD- >>>> >>>>> Thanks guys. >>>>> >>>>> Anthony, can you sponsor this for me? >>>>> >>>>> -DrD- >>>>> >>>>>> This fix looks fine to me as well. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>> >>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>> >>>>>>> Request for review of JDK-8025673: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>> >>>>>>> Proposed changes: >>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>> >>>>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>>>> >>>>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>>>> >>>>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>>>> >>>>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>>>> >>>>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>>>> >>>>>>> >>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>> 461 } else { >>>>>>> 462 // TODO: do we still need this? >>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>> 464 } >>>>>>> >>>>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>>>> >>>>>>> >>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>>>> >>>>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>> >>>> >>> > From anthony.petrov at oracle.com Tue Oct 22 11:00:09 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Oct 2013 22:00:09 +0400 Subject: Crash on startup in SnowLeopard 1.7.0_45 In-Reply-To: References: Message-ID: <5266BD29.4090305@oracle.com> http://www.java.com/en/download/help/sysreq.xml > Mac OS X > > Intel-based Mac running Mac OS X 10.7.3 (Lion) or later. So, 10.6.8 is simply unsupported. Please consider upgrading your OS. -- best regards, Anthony On 10/22/2013 08:27 PM, Steve Hannah wrote: > I have an app that is bundled using appbundler. On Lion the app works > fine. On Snow Leopard (10.6.8) it works fine if I bundle it with > jdk1.7.0_25 (oracle), but if I bundle it with jdk1.7.0_45 (oracle), it > crashes on startup. Crash log pasted at end of this message. > > Is this a known regression? > > Steve > > > Just before crashing, the following messages are written in Console: > > 13-10-22 9:14:08 AM JavaAppLauncher[388] *** NSInvocation: warning: object > 0x109714390 of class 'ThreadUtilities' does not implement > methodSignatureForSelector: -- trouble ahead > > 13-10-22 9:14:08 AM JavaAppLauncher[388] *** NSInvocation: warning: object > 0x109714390 of class 'ThreadUtilities' does not implement > doesNotRecognizeSelector: -- abort > > Crash log follows: > > Process: JavaAppLauncher [388] > Path: /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community > Edition.app/Contents/MacOS/JavaAppLauncher > Identifier: ca.weblite.PDFOCRX.CommunityEdition > Version: 2.0.0 (2.0.0) > Code Type: X86-64 (Native) > Parent Process: launchd [104] > > Date/Time: 2013-10-22 09:14:08.935 -0700 > OS Version: Mac OS X 10.6.8 (10K549) > Report Version: 6 > > Exception Type: EXC_BREAKPOINT (SIGTRAP) > Exception Codes: 0x0000000000000002, 0x0000000000000000 > Crashed Thread: 0 > > Thread 0 Crashed: > 0 com.apple.CoreFoundation 0x00007fff861a88a1 ___forwarding___ + 673 > 1 com.apple.CoreFoundation 0x00007fff861a4a38 _CF_forwarding_prep_0 > + 232 > 2 libobjc.A.dylib 0x00007fff83540325 _class_initialize + 384 > 3 libobjc.A.dylib 0x00007fff8354e52b prepareForMethodLookup > + 234 > 4 libobjc.A.dylib 0x00007fff83546cb9 lookUpMethod + 73 > 5 libobjc.A.dylib 0x00007fff8353efaa objc_msgSend + 198 > 6 libosxapp.dylib 0x000000010970ea77 -[NSApplicationAWT > registerWithProcessManager] + 124 > 7 libosxapp.dylib 0x000000010970e493 -[NSApplicationAWT > init] + 140 > 8 com.apple.AppKit 0x00007fff802350fa +[NSApplication > sharedApplication] + 149 > 9 liblwawt.dylib 0x000000010966394a -[AWTStarter > starter:] + 266 > 10 com.apple.Foundation 0x00007fff8676445f > __NSThreadPerformPerform + 219 > 11 com.apple.CoreFoundation 0x00007fff861733d1 __CFRunLoopDoSources0 > + 1361 > 12 com.apple.CoreFoundation 0x00007fff861715c9 __CFRunLoopRun + 873 > 13 com.apple.CoreFoundation 0x00007fff86170d8f CFRunLoopRunSpecific > + 575 > 14 libjli.dylib 0x000000010003a824 > CreateExecutionEnvironment + 871 > 15 libjli.dylib 0x0000000100034fd0 JLI_Launch + 1952 > 16 ...te.PDFOCRX.CommunityEdition 0x00000001067af804 launch + 8468 > 17 ...te.PDFOCRX.CommunityEdition 0x00000001067ad4d6 main + 102 > 18 ...te.PDFOCRX.CommunityEdition 0x00000001067ad464 start + 52 > > Thread 1: > 0 libSystem.B.dylib 0x00007fff874ebc0a kevent + 10 > 1 libSystem.B.dylib 0x00007fff874edadd _dispatch_mgr_invoke + > 154 > 2 libSystem.B.dylib 0x00007fff874ed7b4 _dispatch_queue_invoke > + 185 > 3 libSystem.B.dylib 0x00007fff874ed2de > _dispatch_worker_thread2 + 252 > 4 libSystem.B.dylib 0x00007fff874ecc08 _pthread_wqthread + 353 > 5 libSystem.B.dylib 0x00007fff874ecaa5 start_wqthread + 13 > > Thread 2: > 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87534896 pthread_join + 844 > 2 libjli.dylib 0x0000000100039e24 ContinueInNewThread0 > + 102 > 3 libjli.dylib 0x0000000100035c3b ContinueInNewThread + > 201 > 4 libjli.dylib 0x0000000100039bf9 JVMInit + 315 > 5 libjli.dylib 0x00000001000359b9 JLI_Launch + 4489 > 6 ...te.PDFOCRX.CommunityEdition 0x00000001067af804 launch + 8468 > 7 ...te.PDFOCRX.CommunityEdition 0x00000001067ad4d6 main + 102 > 8 libjli.dylib 0x000000010003a4b6 apple_main + 92 > 9 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 > 10 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 > > Thread 3: > 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + > 1286 > 2 liblwawt.dylib 0x00000001096637b7 +[AWTStarter start:] > + 598 > 3 liblwawt.dylib 0x0000000109663f42 JNI_OnLoad + 480 > 4 libjava.dylib 0x0000000100604e76 > Java_java_lang_ClassLoader_00024NativeLibrary_load + 207 > 5 ??? 0x0000000102274738 0 + 4331095864 > 6 ??? 0x0000000102268058 0 + 4331044952 > 7 ??? 0x0000000102268350 0 + 4331045712 > 8 ??? 0x0000000102268350 0 + 4331045712 > 9 ??? 0x0000000102268058 0 + 4331044952 > 10 ??? 0x0000000102268058 0 + 4331044952 > 11 ??? 0x00000001022624e7 0 + 4331021543 > 12 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, > Thread*) + 554 > 13 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 > 14 libjvm.dylib 0x0000000101b0a304 > jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, > _jmethodID*, JNI_ArgumentPusher*, Thread*) + 230 > 15 libjvm.dylib 0x0000000101b0358b > jni_CallStaticVoidMethodV + 156 > 16 libjava.dylib 0x000000010060bcff > JNU_CallStaticMethodByName + 282 > 17 libawt.dylib 0x000000010953282c AWT_OnLoad + 389 > 18 libawt.dylib 0x0000000109532873 JNI_OnLoad + 9 > 19 libjava.dylib 0x0000000100604e76 > Java_java_lang_ClassLoader_00024NativeLibrary_load + 207 > 20 ??? 0x0000000102274738 0 + 4331095864 > 21 ??? 0x0000000102268058 0 + 4331044952 > 22 ??? 0x0000000102268350 0 + 4331045712 > 23 ??? 0x0000000102268350 0 + 4331045712 > 24 ??? 0x0000000102268058 0 + 4331044952 > 25 ??? 0x0000000102268058 0 + 4331044952 > 26 ??? 0x0000000102268058 0 + 4331044952 > 27 ??? 0x0000000102268233 0 + 4331045427 > 28 ??? 0x00000001022624e7 0 + 4331021543 > 29 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, > Thread*) + 554 > 30 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 > 31 libjvm.dylib 0x0000000101b2a444 JVM_DoPrivileged + > 1041 > 32 ??? 0x0000000102274738 0 + 4331095864 > 33 ??? 0x0000000102268233 0 + 4331045427 > 34 ??? 0x0000000102268058 0 + 4331044952 > 35 ??? 0x00000001022624e7 0 + 4331021543 > 36 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, > Thread*) + 554 > 37 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 > 38 libjvm.dylib 0x0000000101aac367 > instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) + > 147 > 39 libjvm.dylib 0x0000000101aad856 > instanceKlass::initialize_impl(instanceKlassHandle, Thread*) + 1484 > 40 libjvm.dylib 0x0000000101a9fd01 > instanceKlass::initialize(Thread*) + 85 > 41 libjvm.dylib 0x0000000101b9f5ab > LinkResolver::resolve_static_call(CallInfo&, KlassHandle&, Symbol*, > Symbol*, KlassHandle, bool, bool, Thread*) + 173 > 42 libjvm.dylib 0x0000000101b9f691 > LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle, int, > Thread*) + 129 > 43 libjvm.dylib 0x0000000101ad1f22 > InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code) + 550 > 44 ??? 0x000000010227f828 0 + 4331141160 > 45 ??? 0x00000001022624e7 0 + 4331021543 > 46 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, > Thread*) + 554 > 47 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 > 48 libjvm.dylib 0x0000000101aac367 > instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) + > 147 > 49 libjvm.dylib 0x0000000101aad856 > instanceKlass::initialize_impl(instanceKlassHandle, Thread*) + 1484 > 50 libjvm.dylib 0x0000000101a9fd01 > instanceKlass::initialize(Thread*) + 85 > 51 libjvm.dylib 0x0000000101b23810 > find_class_from_class_loader(JNIEnv_*, Symbol*, unsigned char, Handle, > Handle, unsigned char, Thread*) + 120 > 52 libjvm.dylib 0x0000000101b2bf84 > JVM_FindClassFromClassLoader + 267 > 53 libjava.dylib 0x0000000100604baf > Java_java_lang_Class_forName0 + 305 > 54 ??? 0x0000000102274738 0 + 4331095864 > 55 ??? 0x0000000102268233 0 + 4331045427 > 56 ??? 0x0000000102268233 0 + 4331045427 > 57 ??? 0x00000001022624e7 0 + 4331021543 > 58 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, > Thread*) + 554 > 59 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 > 60 libjvm.dylib 0x0000000101aac367 > instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) + > 147 > 61 libjvm.dylib 0x0000000101aad856 > instanceKlass::initialize_impl(instanceKlassHandle, Thread*) + 1484 > 62 libjvm.dylib 0x0000000101a9fd01 > instanceKlass::initialize(Thread*) + 85 > 63 libjvm.dylib 0x0000000101b9f5ab > LinkResolver::resolve_static_call(CallInfo&, KlassHandle&, Symbol*, > Symbol*, KlassHandle, bool, bool, Thread*) + 173 > 64 libjvm.dylib 0x0000000101b9f691 > LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle, int, > Thread*) + 129 > 65 libjvm.dylib 0x0000000101ad1f22 > InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code) + 550 > 66 ??? 0x000000010227f828 0 + 4331141160 > 67 ??? 0x0000000102268058 0 + 4331044952 > 68 ??? 0x00000001022624e7 0 + 4331021543 > 69 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, > Thread*) + 554 > 70 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 > 71 libjvm.dylib 0x0000000101aac367 > instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) + > 147 > 72 libjvm.dylib 0x0000000101aad856 > instanceKlass::initialize_impl(instanceKlassHandle, Thread*) + 1484 > 73 libjvm.dylib 0x0000000101a9fd01 > instanceKlass::initialize(Thread*) + 85 > 74 libjvm.dylib 0x0000000101b9f5ab > LinkResolver::resolve_static_call(CallInfo&, KlassHandle&, Symbol*, > Symbol*, KlassHandle, bool, bool, Thread*) + 173 > 75 libjvm.dylib 0x0000000101b9f691 > LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle, int, > Thread*) + 129 > 76 libjvm.dylib 0x0000000101ad1f22 > InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code) + 550 > 77 ??? 0x000000010227f81a 0 + 4331141146 > 78 ??? 0x00000001022624e7 0 + 4331021543 > 79 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, > Thread*) + 554 > 80 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 > 81 libjvm.dylib 0x0000000101aac367 > instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) + > 147 > 82 libjvm.dylib 0x0000000101aad856 > instanceKlass::initialize_impl(instanceKlassHandle, Thread*) + 1484 > 83 libjvm.dylib 0x0000000101a9fd01 > instanceKlass::initialize(Thread*) + 85 > 84 libjvm.dylib 0x0000000101ad2fad > InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) + 161 > 85 ??? 0x00000001022801a5 0 + 4331143589 > 86 ??? 0x0000000102268058 0 + 4331044952 > 87 ??? 0x00000001022624e7 0 + 4331021543 > 88 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, > Thread*) + 554 > 89 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 > 90 libjvm.dylib 0x0000000101b0a304 > jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, > _jmethodID*, JNI_ArgumentPusher*, Thread*) + 230 > 91 libjvm.dylib 0x0000000101b0349f > jni_CallStaticVoidMethod + 267 > 92 libjli.dylib 0x0000000100036572 JavaMain + 2333 > 93 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 > 94 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 > > Thread 4: > 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101bf70be > ParkCommon(ParkEvent*, long long) + 42 > 4 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 5 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, > long, bool) + 375 > 6 libjvm.dylib 0x0000000101a68e6e > GCTaskManager::get_task(unsigned int) + 56 > 7 libjvm.dylib 0x0000000101a69d63 GCTaskThread::run() + > 349 > 8 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + > 294 > 9 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 > 10 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 > > Thread 5: > 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101bf70be > ParkCommon(ParkEvent*, long long) + 42 > 4 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 5 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, > long, bool) + 375 > 6 libjvm.dylib 0x0000000101a68e6e > GCTaskManager::get_task(unsigned int) + 56 > 7 libjvm.dylib 0x0000000101a69d63 GCTaskThread::run() + > 349 > 8 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + > 294 > 9 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 > 10 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 > > Thread 6: > 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c17ddb > os::PlatformEvent::park(long long) + 385 > 3 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 4 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, > long, bool) + 375 > 5 libjvm.dylib 0x0000000101d2a8b0 VMThread::loop() + 444 > 6 libjvm.dylib 0x0000000101d2a35b VMThread::run() + 121 > 7 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + > 294 > 8 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 > 9 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 > > Thread 7: Java: Reference Handler > 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101c0fe57 > ObjectMonitor::wait(long long, bool, Thread*) + 757 > 4 libjvm.dylib 0x0000000101cbf4a3 > ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 > 5 libjvm.dylib 0x0000000101b2b0fc JVM_MonitorWait + 156 > 6 ??? 0x0000000102274738 0 + 4331095864 > 7 ??? 0x0000000102268058 0 + 4331044952 > 8 ??? 0x0000000102268058 0 + 4331044952 > 9 ??? 0x00000001022624e7 0 + 4331021543 > 10 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, > Thread*) + 554 > 11 libjvm.dylib 0x0000000101ad72a7 > JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, > JavaCallArguments*, Thread*) + 283 > 12 libjvm.dylib 0x0000000101ad73e4 > JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, > Thread*) + 74 > 13 libjvm.dylib 0x0000000101b263ca > thread_entry(JavaThread*, Thread*) + 173 > 14 libjvm.dylib 0x0000000101cefb47 > JavaThread::thread_main_inner() + 155 > 15 libjvm.dylib 0x0000000101cf124f JavaThread::run() + > 419 > 16 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + > 294 > 17 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 > 18 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 > > Thread 8: Java: Finalizer > 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101c0fe57 > ObjectMonitor::wait(long long, bool, Thread*) + 757 > 4 libjvm.dylib 0x0000000101cbf4a3 > ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 > 5 libjvm.dylib 0x0000000101b2b0fc JVM_MonitorWait + 156 > 6 ??? 0x0000000102274738 0 + 4331095864 > 7 ??? 0x0000000102268058 0 + 4331044952 > 8 ??? 0x0000000102268233 0 + 4331045427 > 9 ??? 0x0000000102268233 0 + 4331045427 > 10 ??? 0x00000001022624e7 0 + 4331021543 > 11 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, > Thread*) + 554 > 12 libjvm.dylib 0x0000000101ad72a7 > JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, > JavaCallArguments*, Thread*) + 283 > 13 libjvm.dylib 0x0000000101ad73e4 > JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, > Thread*) + 74 > 14 libjvm.dylib 0x0000000101b263ca > thread_entry(JavaThread*, Thread*) + 173 > 15 libjvm.dylib 0x0000000101cefb47 > JavaThread::thread_main_inner() + 155 > 16 libjvm.dylib 0x0000000101cf124f JavaThread::run() + > 419 > 17 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + > 294 > 18 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 > 19 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 > > Thread 9: > 0 libSystem.B.dylib 0x00007fff874eca2a __workq_kernreturn + 10 > 1 libSystem.B.dylib 0x00007fff874ece3c _pthread_wqthread + 917 > 2 libSystem.B.dylib 0x00007fff874ecaa5 start_wqthread + 13 > > Thread 10: Java: Signal Dispatcher > 0 libSystem.B.dylib 0x00007fff874d2db6 semaphore_wait_trap + > 10 > 1 libjvm.dylib 0x0000000101c194a0 > check_pending_signals(bool) + 128 > 2 libjvm.dylib 0x0000000101c15da8 > signal_thread_entry(JavaThread*, Thread*) + 57 > 3 libjvm.dylib 0x0000000101cefb47 > JavaThread::thread_main_inner() + 155 > 4 libjvm.dylib 0x0000000101cf124f JavaThread::run() + > 419 > 5 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + > 294 > 6 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 > 7 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 > > Thread 11: Java: C2 CompilerThread0 > 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101bf70be > ParkCommon(ParkEvent*, long long) + 42 > 4 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 5 libjvm.dylib 0x0000000101bf7a74 Monitor::wait(bool, > long, bool) + 222 > 6 libjvm.dylib 0x00000001019c10ab CompileQueue::get() + > 153 > 7 libjvm.dylib 0x00000001019c1c43 > CompileBroker::compiler_thread_loop() + 425 > 8 libjvm.dylib 0x0000000101cefb47 > JavaThread::thread_main_inner() + 155 > 9 libjvm.dylib 0x0000000101cf124f JavaThread::run() + > 419 > 10 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + > 294 > 11 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 > 12 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 > > Thread 12: Java: C2 CompilerThread1 > 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101bf70be > ParkCommon(ParkEvent*, long long) + 42 > 4 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 5 libjvm.dylib 0x0000000101bf7a74 Monitor::wait(bool, > long, bool) + 222 > 6 libjvm.dylib 0x00000001019c10ab CompileQueue::get() + > 153 > 7 libjvm.dylib 0x00000001019c1c43 > CompileBroker::compiler_thread_loop() + 425 > 8 libjvm.dylib 0x0000000101cefb47 > JavaThread::thread_main_inner() + 155 > 9 libjvm.dylib 0x0000000101cf124f JavaThread::run() + > 419 > 10 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + > 294 > 11 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 > 12 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 > > Thread 13: Java: Service Thread > 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101bf70be > ParkCommon(ParkEvent*, long long) + 42 > 4 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 5 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, > long, bool) + 375 > 6 libjvm.dylib 0x0000000101c6f1d5 > ServiceThread::service_thread_entry(JavaThread*, Thread*) + 109 > 7 libjvm.dylib 0x0000000101cefb47 > JavaThread::thread_main_inner() + 155 > 8 libjvm.dylib 0x0000000101cf124f JavaThread::run() + > 419 > 9 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + > 294 > 10 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 > 11 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 > > Thread 14: > 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c17ddb > os::PlatformEvent::park(long long) + 385 > 3 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 4 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, > long, bool) + 375 > 5 libjvm.dylib 0x0000000101cf001a > WatcherThread::sleep() const + 126 > 6 libjvm.dylib 0x0000000101cf0edd WatcherThread::run() > + 243 > 7 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) + > 294 > 8 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 > 9 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 > > Thread 0 crashed with X86 Thread State (64-bit): > rax: 0x0000000000000000 rbx: 0x00007fff809c8734 rcx: 0x0000000000000000 > rdx: 0x00007fff70e7acc0 > rdi: 0x000000000000003b rsi: 0x0000000000000001 rbp: 0x00007fff5fbfc740 > rsp: 0x00007fff5fbfc6f0 > r8: 0x0000000000000001 r9: 0x00000001003266c0 r10: 0x0000000000000001 > r11: 0x000000000000003f > r12: 0x0000000000000000 r13: 0x0000000109714390 r14: 0x00000001097143b8 > r15: 0x0000000109714390 > rip: 0x00007fff861a88a1 rfl: 0x0000000000000287 cr2: 0x0000000108cff000 > > Binary Images: > 0x100033000 - 0x10003dfff +libjli.dylib ??? (???) > <32A3CEF6-9D91-3B97-9F17-CAD9301081D1> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community > Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/jli/libjli.dylib > 0x1000ec000 - 0x1000f4fff +libverify.dylib ??? (???) > /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community > Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libverify.dylib > 0x1002e2000 - 0x1002e7fff +libzip.dylib ??? (???) > <50D7966F-6590-3F9A-A42B-7E7EE016493E> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community > Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libzip.dylib > 0x1002ee000 - 0x1002f3ff7 com.apple.JavaVM 13.9.8 (13.9.8) > > /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM > 0x100603000 - 0x100624fe7 +libjava.dylib ??? (???) > <64871BED-E504-307F-BCEE-EA4CCEA588EA> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community > Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libjava.dylib > 0x101800000 - 0x101f45fef +libjvm.dylib ??? (???) > <7CBD0F39-332A-3790-B0FF-F5F955C325A6> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community > Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/server/libjvm.dylib > 0x1066c6000 - 0x1066d1fef com.apple.java.JavaRuntimeSupport > 13.9.8 (13.9.8) <78E0442F-7DF4-5DAA-2DF1-1570AE1AAEC8> > /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/JavaRuntimeSupport > 0x1066e2000 - 0x1066edfff JavaNativeFoundation ??? (???) > <81035866-C9A3-6ADC-920F-A2C02D6DB95B> > /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation > 0x1066f8000 - 0x1066feff7 JavaLaunching ??? (???) > <8A4FFBEC-90DB-3EB1-68E7-4EF8A0F47F52> > /System/Library/PrivateFrameworks/JavaLaunching.framework/Versions/A/JavaLaunching > 0x1067ac000 - 0x1067affff > +ca.weblite.PDFOCRX.CommunityEdition 2.0.0 (2.0.0) > <085DD0B7-34B2-3A2D-BFC7-4CA094FC70DE> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community > Edition.app/Contents/MacOS/JavaAppLauncher > 0x1094d4000 - 0x10953ffff +libawt.dylib ??? (???) > <5F027771-D669-392F-8DD7-CBA3EA5DD87D> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community > Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libawt.dylib > 0x109586000 - 0x10964bfff +libmlib_image.dylib ??? (???) > <95F6D0B2-3A92-305F-A6AE-822BC990901B> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community > Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libmlib_image.dylib > 0x109656000 - 0x1096c6fff +liblwawt.dylib ??? (???) > <9875DBAB-B5B6-322C-A085-4651CEDFCBF4> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community > Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/lwawt/liblwawt.dylib > 0x10970d000 - 0x109712fff +libosxapp.dylib ??? (???) > <8CE761D7-7DAA-36BA-8424-BF74590F8C1D> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/PDFOCRX2_Mac/dist/PDF OCR X Community > Edition.app/Contents/PlugIns/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libosxapp.dylib > 0x7fff5fc00000 - 0x7fff5fc3be0f dyld 132.1 (???) > <29DECB19-0193-2575-D838-CF743F0400B2> /usr/lib/dyld > 0x7fff80003000 - 0x7fff80093fff com.apple.SearchKit 1.3.0 (1.3.0) > <4175DC31-1506-228A-08FD-C704AC9DF642> > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit > 0x7fff80094000 - 0x7fff80171fff com.apple.vImage 4.1 (4.1) > > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage > 0x7fff80172000 - 0x7fff801f7ff7 > com.apple.print.framework.PrintCore 6.3 (312.7) > > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore > 0x7fff801f8000 - 0x7fff8020ffff com.apple.ImageCapture 6.1 (6.1) > <79AB2131-2A6C-F351-38A9-ED58B25534FD> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture > 0x7fff80222000 - 0x7fff80231fff com.apple.NetFS 3.2.2 (3.2.2) > <7CCBD70E-BF31-A7A7-DB98-230687773145> > /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS > 0x7fff80232000 - 0x7fff80c2cff7 com.apple.AppKit 6.6.8 (1038.36) > <4CFBE04C-8FB3-B0EA-8DDB-7E7D10E9D251> > /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit > 0x7fff80c2d000 - 0x7fff80c34fff com.apple.OpenDirectory 10.6 > (10.6) <4FF6AD25-0916-B21C-9E88-2CC42D90EAC7> > /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory > 0x7fff80c35000 - 0x7fff80cf2fff com.apple.CoreServices.OSServices > 359.2 (359.2) > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices > 0x7fff80d25000 - 0x7fff80d4aff7 com.apple.CoreVideo 1.6.2 (45.6) > > /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo > 0x7fff80d70000 - 0x7fff80db1fff com.apple.SystemConfiguration > 1.10.8 (1.10.2) <78D48D27-A9C4-62CA-2803-D0BBED82855A> > /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration > 0x7fff810ad000 - 0x7fff81162fe7 com.apple.ink.framework 1.3.3 > (107) <8C36373C-5473-3A6A-4972-BC29D504250F> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink > 0x7fff8116f000 - 0x7fff811d9fe7 libvMisc.dylib 268.0.1 > (compatibility 1.0.0) > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib > 0x7fff81464000 - 0x7fff81504fff com.apple.LaunchServices 362.3 > (362.3) > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices > 0x7fff81505000 - 0x7fff81551fff libauto.dylib ??? (???) > /usr/lib/libauto.dylib > 0x7fff81552000 - 0x7fff81583fff libGLImage.dylib ??? (???) > <562565E1-AA65-FE96-13FF-437410C886D0> > /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib > 0x7fff81584000 - 0x7fff81584ff7 com.apple.Cocoa 6.6 (???) > <68B0BE46-6E24-C96F-B341-054CF9E8F3B6> > /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa > 0x7fff81be0000 - 0x7fff81cb4fe7 com.apple.CFNetwork 454.12.4 > (454.12.4) > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork > 0x7fff81e7a000 - 0x7fff82576ff7 com.apple.CoreGraphics 1.545.0 > (???) <58D597B1-EB3B-710E-0B8C-EC114D54E11B> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics > 0x7fff82605000 - 0x7fff82628fff com.apple.opencl 12.3.6 (12.3.6) > <42FA5783-EB80-1168-4015-B8C68F55842F> > /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL > 0x7fff82629000 - 0x7fff826a6fef libstdc++.6.dylib 7.9.0 > (compatibility 7.0.0) <35ECA411-2C08-FD7D-11B1-1B7A04921A5C> > /usr/lib/libstdc++.6.dylib > 0x7fff82a14000 - 0x7fff82a17ff7 libCoreVMClient.dylib ??? (???) > <75819794-3B7A-8944-D004-7EA6DD7CE836> > /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib > 0x7fff82a18000 - 0x7fff82a5fff7 com.apple.coreui 2 (114) > <923E33CC-83FC-7D35-5603-FB8F348EE34B> > /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI > 0x7fff82a9e000 - 0x7fff82af4fe7 libTIFF.dylib ??? (???) > <2DBEC120-DAA7-3789-36A2-A205BCDF2D72> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib > 0x7fff83344000 - 0x7fff83359ff7 com.apple.LangAnalysis 1.6.6 > (1.6.6) <1AE1FE8F-2204-4410-C94E-0E93B003BEDA> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis > 0x7fff8335a000 - 0x7fff8335ffff libGIF.dylib ??? (???) > <3BAD0DE8-8151-68B0-2244-A4541C738972> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib > 0x7fff83360000 - 0x7fff83361fff liblangid.dylib ??? (???) > /usr/lib/liblangid.dylib > 0x7fff83362000 - 0x7fff833a3fef com.apple.QD 3.36 (???) > <5DC41E81-32C9-65B2-5528-B33E934D5BB4> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD > 0x7fff833a4000 - 0x7fff833a6fff libRadiance.dylib ??? (???) > > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib > 0x7fff833a7000 - 0x7fff83419fef com.apple.CoreSymbolication 2.0 > (23) <06F8561E-4B36-7BF6-31BA-64091B3D8058> > /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication > 0x7fff834a4000 - 0x7fff83530fef SecurityFoundation ??? (???) > <3F1F2727-C508-3630-E2C1-38361841FCE4> > /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation > 0x7fff8353a000 - 0x7fff835f0ff7 libobjc.A.dylib 227.0.0 > (compatibility 1.0.0) <03140531-3B2D-1EBA-DA7F-E12CC8F63969> > /usr/lib/libobjc.A.dylib > 0x7fff837b2000 - 0x7fff837edfff com.apple.AE 496.5 (496.5) > <208DF391-4DE6-81ED-C697-14A2930D1BC6> > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE > 0x7fff837f8000 - 0x7fff839b6fff libicucore.A.dylib 40.0.0 > (compatibility 1.0.0) <97A75BFB-0DB6-6F44-36B0-97B7F7208ABB> > /usr/lib/libicucore.A.dylib > 0x7fff839b7000 - 0x7fff839bbff7 libmathCommon.A.dylib 315.0.0 > (compatibility 1.0.0) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> > /usr/lib/system/libmathCommon.A.dylib > 0x7fff839bc000 - 0x7fff839e3ff7 libJPEG.dylib ??? (???) > <08758593-6436-B29E-1DA8-F15597835EC1> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib > 0x7fff83add000 - 0x7fff83ae8ff7 > com.apple.speech.recognition.framework 3.11.1 (3.11.1) > <3D65E89B-FFC6-4AAF-D5CC-104F967C8131> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition > 0x7fff83c02000 - 0x7fff83c40fef com.apple.DebugSymbols 1.1 (70) > > /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols > 0x7fff83d01000 - 0x7fff83d01ff7 com.apple.CoreServices 44 (44) > > /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices > 0x7fff84046000 - 0x7fff8404cff7 IOSurface ??? (???) > <8E302BB2-0704-C6AB-BD2F-C2A6C6A2E2C3> > /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface > 0x7fff8404d000 - 0x7fff84095ff7 libvDSP.dylib 268.0.1 > (compatibility 1.0.0) <98FC4457-F405-0262-00F7-56119CA107B6> > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib > 0x7fff845e4000 - 0x7fff8460cfff com.apple.DictionaryServices 1.1.2 > (1.1.2) > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices > 0x7fff84615000 - 0x7fff847d4fff com.apple.ImageIO.framework 3.0.6 > (3.0.6) <92882FD3-CB3F-D0BE-DDDA-43B4BEE10F58> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO > 0x7fff847d5000 - 0x7fff84b72fe7 com.apple.QuartzCore 1.6.3 > (227.37) <16DFF6CD-EA58-CE62-A1D7-5F6CE3D066DD> > /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore > 0x7fff84b73000 - 0x7fff84b81ff7 libkxld.dylib ??? (???) > <8145A534-95CC-9F3C-B78B-AC9898F38C6F> /usr/lib/system/libkxld.dylib > 0x7fff84ca0000 - 0x7fff84ce9fef libGLU.dylib ??? (???) > > /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib > 0x7fff84d2c000 - 0x7fff84d4dfff libresolv.9.dylib 41.1.0 > (compatibility 1.0.0) <9410EC7F-4D24-6740-AFEE-90405750FAD7> > /usr/lib/libresolv.9.dylib > 0x7fff84d4e000 - 0x7fff84e64ff7 libxml2.2.dylib 10.3.0 > (compatibility 10.0.0) <3814FCF9-92B9-A6AB-E76A-F7021894AA3F> > /usr/lib/libxml2.2.dylib > 0x7fff84ef7000 - 0x7fff85016ff7 libcrypto.0.9.8.dylib 0.9.8 > (compatibility 0.9.8) <0CE8D59B-D0C7-1DCE-3654-37F27F61BEFA> > /usr/lib/libcrypto.0.9.8.dylib > 0x7fff85017000 - 0x7fff85017ff7 com.apple.ApplicationServices 38 > (38) <10A0B9E9-4988-03D4-FC56-DDE231A02C63> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices > 0x7fff8547c000 - 0x7fff85596fff libGLProgrammability.dylib ??? > (???) > /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib > 0x7fff856df000 - 0x7fff856dfff7 com.apple.Carbon 150 (152) > <23704665-E9F4-6B43-1115-2E69F161FC45> > /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon > 0x7fff85720000 - 0x7fff85726ff7 com.apple.CommerceCore 1.0 (9.1) > <3691E9BA-BCF4-98C7-EFEC-78DA6825004E> > /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore > 0x7fff857dd000 - 0x7fff858c2fef com.apple.DesktopServices 1.5.11 > (1.5.11) <39FAA3D2-6863-B5AB-AED9-92D878EA2438> > /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv > 0x7fff858c3000 - 0x7fff858eeff7 libxslt.1.dylib 3.24.0 > (compatibility 3.0.0) <3630A97F-55C1-3F34-CA63-3847653C9645> > /usr/lib/libxslt.1.dylib > 0x7fff8596b000 - 0x7fff85a2dfe7 libFontParser.dylib ??? (???) > > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib > 0x7fff85caa000 - 0x7fff85cbefff libGL.dylib ??? (???) > <2ECE3B0F-39E1-3938-BF27-7205C6D0358B> > /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib > 0x7fff85f15000 - 0x7fff85f29ff7 > com.apple.speech.synthesis.framework 3.10.35 (3.10.35) > <621B7415-A0B9-07A7-F313-36BEEDD7B132> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis > 0x7fff86125000 - 0x7fff8629cfe7 com.apple.CoreFoundation 6.6.6 > (550.44) > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > 0x7fff863a6000 - 0x7fff863b5fef com.apple.opengl 1.6.14 (1.6.14) > > /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL > 0x7fff863b6000 - 0x7fff86477fef com.apple.ColorSync 4.6.8 (4.6.8) > <7DF1D175-6451-51A2-DBBF-40FCA78C0D2C> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync > 0x7fff86478000 - 0x7fff86512fff com.apple.ApplicationServices.ATS > 275.19 (???) <2DE8987F-4563-4D8E-45C3-2F6F786E120D> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS > 0x7fff86513000 - 0x7fff86648fff > com.apple.audio.toolbox.AudioToolbox 1.6.7 (1.6.7) > > /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox > 0x7fff86716000 - 0x7fff86716ff7 com.apple.Accelerate.vecLib 3.6 > (vecLib 3.6) <4CCE5D69-F1B3-8FD3-1483-E0271DB2CCF3> > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib > 0x7fff86717000 - 0x7fff8672dfe7 > com.apple.MultitouchSupport.framework 207.11 (207.11) > <8233CE71-6F8D-8B3C-A0E1-E123F6406163> > /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport > 0x7fff8673c000 - 0x7fff869befff com.apple.Foundation 6.6.8 > (751.63) > /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation > 0x7fff869bf000 - 0x7fff869c0ff7 com.apple.TrustEvaluationAgent 1.1 > (1) <5952A9FA-BC2B-16EF-91A7-43902A5C07B6> > /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent > 0x7fff869c1000 - 0x7fff86cbffff com.apple.HIToolbox 1.6.5 (???) > > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox > 0x7fff86cc0000 - 0x7fff86cc3fff com.apple.help 1.3.2 (41.1) > > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help > 0x7fff86d04000 - 0x7fff86d09ff7 com.apple.CommonPanels 1.2.4 (91) > <4D84803B-BD06-D80E-15AE-EFBE43F93605> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels > 0x7fff86d3b000 - 0x7fff8706ffef com.apple.CoreServices.CarbonCore > 861.39 (861.39) <1386A24D-DD15-5903-057E-4A224FAF580B> > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore > 0x7fff87070000 - 0x7fff871aefff com.apple.CoreData 102.1 (251) > <9DFE798D-AA52-6A9A-924A-DA73CB94D81A> > /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData > 0x7fff872e4000 - 0x7fff872e4ff7 com.apple.vecLib 3.6 (vecLib 3.6) > <96FB6BAD-5568-C4E0-6FA7-02791A58B584> > /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib > 0x7fff872e5000 - 0x7fff872e6ff7 com.apple.audio.units.AudioUnit > 1.6.7 (1.6.7) <49B723D1-85F8-F86C-2331-F586C56D68AF> > /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit > 0x7fff873c0000 - 0x7fff873dbff7 com.apple.openscripting 1.3.1 > (???) <9D50701D-54AC-405B-CC65-026FCB28258B> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting > 0x7fff873dc000 - 0x7fff87416fff libcups.2.dylib 2.8.0 > (compatibility 2.0.0) <4F2A4397-89BD-DEAC-4971-EE838FFA0964> > /usr/lib/libcups.2.dylib > 0x7fff87430000 - 0x7fff874affe7 com.apple.audio.CoreAudio 3.2.6 > (3.2.6) <79E256EB-43F1-C7AA-6436-124A4FFB02D0> > /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio > 0x7fff874b0000 - 0x7fff874d1fe7 libPng.dylib ??? (???) > > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib > 0x7fff874d2000 - 0x7fff87693fef libSystem.B.dylib 125.2.11 > (compatibility 1.0.0) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> > /usr/lib/libSystem.B.dylib > 0x7fff87694000 - 0x7fff87696fff com.apple.print.framework.Print > 6.1 (237.1) > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print > 0x7fff876ad000 - 0x7fff876b2fff libGFXShared.dylib ??? (???) > <6BBC351E-40B3-F4EB-2F35-05BDE52AF87E> > /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib > 0x7fff876b3000 - 0x7fff876c9fef libbsm.0.dylib ??? (???) > <42D3023A-A1F7-4121-6417-FCC6B51B3E90> /usr/lib/libbsm.0.dylib > 0x7fff8788c000 - 0x7fff8788efef com.apple.ExceptionHandling 1.5 > (10) > /System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ExceptionHandling > 0x7fff8788f000 - 0x7fff8790dff7 com.apple.CoreText 151.13 (???) > <5C6214AD-D683-80A8-86EB-328C99B75322> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText > 0x7fff8790e000 - 0x7fff8790eff7 com.apple.Accelerate 1.6 > (Accelerate 1.6) <15DF8B4A-96B2-CB4E-368D-DEC7DF6B62BB> > /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate > 0x7fff8790f000 - 0x7fff87b98ff7 com.apple.security 6.1.2 (55002) > > /System/Library/Frameworks/Security.framework/Versions/A/Security > 0x7fff88c04000 - 0x7fff88c57ff7 com.apple.HIServices 1.8.3 (???) > > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices > 0x7fff88c59000 - 0x7fff88c72fff com.apple.CFOpenDirectory 10.6 > (10.6) <401557B1-C6D1-7E1A-0D7E-941715C37BFA> > /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory > 0x7fff88c97000 - 0x7fff88cecff7 com.apple.framework.familycontrols > 2.0.2 (2020) <8807EB96-D12D-8601-2E74-25784A0DE4FF> > /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls > 0x7fff88cfb000 - 0x7fff88db4fff libsqlite3.dylib 9.6.0 > (compatibility 9.0.0) <2C5ED312-E646-9ADE-73A9-6199A2A43150> > /usr/lib/libsqlite3.dylib > 0x7fff88dc7000 - 0x7fff88de7fff > com.apple.DirectoryService.Framework 3.6 (621.16) > <0ED4A74A-F8FB-366D-6588-F13EA397326F> > /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService > 0x7fff88de8000 - 0x7fff88deeff7 com.apple.DiskArbitration 2.3 > (2.3) <857F6E43-1EF4-7D53-351B-10DE0A8F992A> > /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration > 0x7fff89584000 - 0x7fff89d8efe7 libBLAS.dylib 219.0.0 > (compatibility 1.0.0) > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib > 0x7fff89e94000 - 0x7fff89edeff7 com.apple.Metadata 10.6.3 (507.15) > > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata > 0x7fff89edf000 - 0x7fff89ef0ff7 libz.1.dylib 1.2.3 (compatibility > 1.0.0) <97019C74-161A-3488-41EC-A6CA8738418C> /usr/lib/libz.1.dylib > 0x7fff89ef1000 - 0x7fff89fa1fff edu.mit.Kerberos 6.5.11 (6.5.11) > <085D80F5-C9DC-E252-C21B-03295E660C91> > /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos > 0x7fff89fa2000 - 0x7fff89fb4fe7 libsasl2.2.dylib 3.15.0 > (compatibility 3.0.0) <76B83C8D-8EFE-4467-0F75-275648AFED97> > /usr/lib/libsasl2.2.dylib > 0x7fff8a1ac000 - 0x7fff8a20cfe7 com.apple.framework.IOKit 2.0 > (???) <4F071EF0-8260-01E9-C641-830E582FA416> > /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit > 0x7fff8a27a000 - 0x7fff8a27dff7 com.apple.securityhi 4.0 (36638) > > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI > 0x7fff8a27e000 - 0x7fff8a6c1fef libLAPACK.dylib 219.0.0 > (compatibility 1.0.0) <0CC61C98-FF51-67B3-F3D8-C5E430C201A9> > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib > 0x7fff8a6c2000 - 0x7fff8a711ff7 > com.apple.DirectoryService.PasswordServerFramework 6.1 (6.1) > <0731C40D-71EF-B417-C83B-54C3527A36EA> > /System/Library/PrivateFrameworks/PasswordServer.framework/Versions/A/PasswordServer > 0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib ??? (???) > <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib > From Sergey.Bylokhov at oracle.com Tue Oct 22 11:01:11 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Oct 2013 22:01:11 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5266BBDA.2010106@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> Message-ID: <5266BD67.4010101@oracle.com> Hello. I suppose we should request from sqe team to run the jck tests in the "true" headless mode via ssh(w/o headless option and w/o access to Aqua session). On 22.10.2013 21:54, Anthony Petrov wrote: > We don't have to. IIRC, the choice of HToolkit on Mac was made by chance. > > Since we must load the lwawt lib in headless on Mac anyway, we may as > well use the CToolkit (properly wrapped in the HeadlessToolkit). But > there's no need to continue to use the HToolkit on Mac. > > -- > best regards, > Anthony > > On 10/22/2013 08:22 PM, Leonid Romanov wrote: >> There was a discussion why we use HToolkit instead of HeadlessToolkit: >> http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html >> >> So we might want to continue using it. >> >> Also, please be aware that there is HToolkit check in >> GraphicsToolkit.getHeadlessProperty() >> >> On Oct 22, 2013, at 1:23 PM, Artem Ananiev >> wrote: >> >>> Hi, David, >>> >>> thanks for additional cleanup. >>> >>> I have only one concern. Before the fix, we checked if there is an >>> active Aqua session. When no session was found, we falled back to >>> HToolkit. I think this logic should be preserved, but slightly >>> corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >>> >>> Otherwise the only way to run headless on Mac will be to force it >>> with the system property. It works this way on Windows, but on >>> Windows we're sure that WToolkit can run even without a UI session. >>> Is it also true on Mac? Did you try to launch AWT without >>> -Djava.awt.headless=true from remote console with no users logged in? >>> >>> Thanks, >>> >>> Artem >>> >>> On 10/22/2013 7:34 AM, David DeHaven wrote: >>>> >>>> Updated webrev for JDK (hotspot change is the same): >>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>>> >>>> Changes since last version: >>>> - Moved to jdk8/build/jdk to save someone a merge headache, moved >>>> changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>>> - Removed HToolkit option and toolkit selection code from >>>> java_props_macosx.[ch] >>>> >>>> -DrD- >>>> >>>> >>>>> I want to do one more iteration of this. Based on feedback it >>>>> seems I can remove a bit more code from java_props_macosx.[ch] and >>>>> make things a bit cleaner. >>>>> >>>>> -DrD- >>>>> >>>>>> Thanks guys. >>>>>> >>>>>> Anthony, can you sponsor this for me? >>>>>> >>>>>> -DrD- >>>>>> >>>>>>> This fix looks fine to me as well. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>>> >>>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>>> >>>>>>>> Request for review of JDK-8025673: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>>> >>>>>>>> Proposed changes: >>>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>>> >>>>>>>> This change disables building libawt_xawt.dylib and >>>>>>>> libawt_headless.dylib on Mac since they are not used and not >>>>>>>> supported. There are too many challenges (and not enough time) >>>>>>>> in removing all X11 code from the Mac build at this time, so >>>>>>>> we're deferring complete removal for later (will be covered by >>>>>>>> JDK-8003900). >>>>>>>> >>>>>>>> A small change to hotspot is required as it was looking for >>>>>>>> libawt_xawt.dylib and if not found would set java.awt.headless >>>>>>>> to true. Since we don't build a headless only JRE on Mac I just >>>>>>>> have that method return false. I'm not sure how to handle >>>>>>>> changes to hotspot, can it be pushed along with the jdk >>>>>>>> changes? Without that change the Mac builds will be broken. >>>>>>>> >>>>>>>> Significant build system changes, build-dev guys are encouraged >>>>>>>> to comment... >>>>>>>> >>>>>>>> I tried excluding all sun/awt/X11 classes in >>>>>>>> CompileJavaClasses.gmk but that broke JNI header generation on >>>>>>>> platforms still using X11 and I couldn't use the big list of >>>>>>>> excluded files on Mac as that resulted in Java compilation >>>>>>>> errors, so I just added some logic to exclude everything on Mac >>>>>>>> and left the list in place everywhere else. >>>>>>>> >>>>>>>> The changes to CompileNativeLibraries.gmk will port to >>>>>>>> libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a >>>>>>>> problem in the jdk8/build workspace where the build cannot find >>>>>>>> symbols in JNI libs so that issue needs to be resolved first. >>>>>>>> I've not had time to investigate that problem. >>>>>>>> >>>>>>>> >>>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>>> 461 } else { >>>>>>>> 462 // TODO: do we still need this? >>>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>>> 464 } >>>>>>>> >>>>>>>> Is that necessary? Since we're now using libawt_lwawt in both >>>>>>>> headless and headful modes I would think we could remove the >>>>>>>> HToolkit option, but I'm not 100% certain about that. >>>>>>>> >>>>>>>> >>>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and >>>>>>>> both seem to be working fine. >>>>>>>> >>>>>>>> JPRT run for Mac is in progress, I will submit one for all >>>>>>>> other platforms when it finishes building. >>>>>>>> >>>>>>>> -DrD- >>>>>>>> >>>>>> >>>>> >>>> >> -- Best regards, Sergey. From steve at weblite.ca Tue Oct 22 11:09:31 2013 From: steve at weblite.ca (Steve Hannah) Date: Tue, 22 Oct 2013 11:09:31 -0700 Subject: Crash on startup in SnowLeopard 1.7.0_45 In-Reply-To: <5266BD29.4090305@oracle.com> References: <5266BD29.4090305@oracle.com> Message-ID: Thanks for the reply. Yes, I'm aware of that but: https://wiki.openjdk.java.net/display/MacOSXPort/Main > Note that only Mac OS X 10.7.3 and higher will be an Oracle-supported > platform. It should continue to run on 10.6.8+ but that is not guaranteed. > As of 1-Jan-2012 there are no plans to introduce 10.7-only APIs into the > codebase. I'm worried about backwards compatibility. The current version of my app in the app store works on Snow Leopard and higher. I don't want to issue an "upgrade" that will alienate 40% of my user base ( http://www.pcworld.com/article/2026872/windows-8-adoption-worse-than-vista-better-than-os-x-mountain-lion.html) . I think we probably have a couple more years before we can just ignore the Snow Leopard user base. For now I will just continue to use 1.7.0_25, but I was curious if this was a known regression or not, and whether or not it is possible to fix it in future versions of Java. Steve On Tue, Oct 22, 2013 at 11:00 AM, Anthony Petrov wrote: > http://www.java.com/en/**download/help/sysreq.xml > > Mac OS X >> >> Intel-based Mac running Mac OS X 10.7.3 (Lion) or later. >> > > So, 10.6.8 is simply unsupported. Please consider upgrading your OS. > > -- > best regards, > Anthony > > > On 10/22/2013 08:27 PM, Steve Hannah wrote: > >> I have an app that is bundled using appbundler. On Lion the app works >> fine. On Snow Leopard (10.6.8) it works fine if I bundle it with >> jdk1.7.0_25 (oracle), but if I bundle it with jdk1.7.0_45 (oracle), it >> crashes on startup. Crash log pasted at end of this message. >> >> Is this a known regression? >> >> Steve >> >> >> Just before crashing, the following messages are written in Console: >> >> 13-10-22 9:14:08 AM JavaAppLauncher[388] *** NSInvocation: warning: object >> 0x109714390 of class 'ThreadUtilities' does not implement >> methodSignatureForSelector: -- trouble ahead >> >> 13-10-22 9:14:08 AM JavaAppLauncher[388] *** NSInvocation: warning: object >> 0x109714390 of class 'ThreadUtilities' does not implement >> doesNotRecognizeSelector: -- abort >> >> Crash log follows: >> >> Process: JavaAppLauncher [388] >> Path: /Volumes/Windows >> VMS/NetbeansProjects/PDFOCRX2/**PDFOCRX2_Mac/dist/PDF OCR X Community >> Edition.app/Contents/MacOS/**JavaAppLauncher >> Identifier: ca.weblite.PDFOCRX.**CommunityEdition >> Version: 2.0.0 (2.0.0) >> Code Type: X86-64 (Native) >> Parent Process: launchd [104] >> >> Date/Time: 2013-10-22 09:14:08.935 -0700 >> OS Version: Mac OS X 10.6.8 (10K549) >> Report Version: 6 >> >> Exception Type: EXC_BREAKPOINT (SIGTRAP) >> Exception Codes: 0x0000000000000002, 0x0000000000000000 >> Crashed Thread: 0 >> >> Thread 0 Crashed: >> 0 com.apple.CoreFoundation 0x00007fff861a88a1 ___forwarding___ + >> 673 >> 1 com.apple.CoreFoundation 0x00007fff861a4a38 >> _CF_forwarding_prep_0 >> + 232 >> 2 libobjc.A.dylib 0x00007fff83540325 _class_initialize + >> 384 >> 3 libobjc.A.dylib 0x00007fff8354e52b >> prepareForMethodLookup >> + 234 >> 4 libobjc.A.dylib 0x00007fff83546cb9 lookUpMethod + 73 >> 5 libobjc.A.dylib 0x00007fff8353efaa objc_msgSend + 198 >> 6 libosxapp.dylib 0x000000010970ea77 -[NSApplicationAWT >> registerWithProcessManager] + 124 >> 7 libosxapp.dylib 0x000000010970e493 -[NSApplicationAWT >> init] + 140 >> 8 com.apple.AppKit 0x00007fff802350fa +[NSApplication >> sharedApplication] + 149 >> 9 liblwawt.dylib 0x000000010966394a -[AWTStarter >> starter:] + 266 >> 10 com.apple.Foundation 0x00007fff8676445f >> __NSThreadPerformPerform + 219 >> 11 com.apple.CoreFoundation 0x00007fff861733d1 >> __CFRunLoopDoSources0 >> + 1361 >> 12 com.apple.CoreFoundation 0x00007fff861715c9 __CFRunLoopRun + 873 >> 13 com.apple.CoreFoundation 0x00007fff86170d8f CFRunLoopRunSpecific >> + 575 >> 14 libjli.dylib 0x000000010003a824 >> CreateExecutionEnvironment + 871 >> 15 libjli.dylib 0x0000000100034fd0 JLI_Launch + 1952 >> 16 ...te.PDFOCRX.CommunityEdition 0x00000001067af804 launch + 8468 >> 17 ...te.PDFOCRX.CommunityEdition 0x00000001067ad4d6 main + 102 >> 18 ...te.PDFOCRX.CommunityEdition 0x00000001067ad464 start + 52 >> >> Thread 1: >> 0 libSystem.B.dylib 0x00007fff874ebc0a kevent + 10 >> 1 libSystem.B.dylib 0x00007fff874edadd _dispatch_mgr_invoke >> + >> 154 >> 2 libSystem.B.dylib 0x00007fff874ed7b4 >> _dispatch_queue_invoke >> + 185 >> 3 libSystem.B.dylib 0x00007fff874ed2de >> _dispatch_worker_thread2 + 252 >> 4 libSystem.B.dylib 0x00007fff874ecc08 _pthread_wqthread + >> 353 >> 5 libSystem.B.dylib 0x00007fff874ecaa5 start_wqthread + 13 >> >> Thread 2: >> 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 >> 1 libSystem.B.dylib 0x00007fff87534896 pthread_join + 844 >> 2 libjli.dylib 0x0000000100039e24 ContinueInNewThread0 >> + 102 >> 3 libjli.dylib 0x0000000100035c3b ContinueInNewThread >> + >> 201 >> 4 libjli.dylib 0x0000000100039bf9 JVMInit + 315 >> 5 libjli.dylib 0x00000001000359b9 JLI_Launch + 4489 >> 6 ...te.PDFOCRX.CommunityEdition 0x00000001067af804 launch + 8468 >> 7 ...te.PDFOCRX.CommunityEdition 0x00000001067ad4d6 main + 102 >> 8 libjli.dylib 0x000000010003a4b6 apple_main + 92 >> 9 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 >> 10 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 >> >> Thread 3: >> 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 >> 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + >> 1286 >> 2 liblwawt.dylib 0x00000001096637b7 +[AWTStarter start:] >> + 598 >> 3 liblwawt.dylib 0x0000000109663f42 JNI_OnLoad + 480 >> 4 libjava.dylib 0x0000000100604e76 >> Java_java_lang_ClassLoader_**00024NativeLibrary_load + 207 >> 5 ??? 0x0000000102274738 0 + 4331095864 >> 6 ??? 0x0000000102268058 0 + 4331044952 >> 7 ??? 0x0000000102268350 0 + 4331045712 >> 8 ??? 0x0000000102268350 0 + 4331045712 >> 9 ??? 0x0000000102268058 0 + 4331044952 >> 10 ??? 0x0000000102268058 0 + 4331044952 >> 11 ??? 0x00000001022624e7 0 + 4331021543 >> 12 libjvm.dylib 0x0000000101ad6d90 >> JavaCalls::call_helper(**JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 554 >> 13 libjvm.dylib 0x0000000101ad6b60 >> JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + >> 40 >> 14 libjvm.dylib 0x0000000101b0a304 >> jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, >> _jmethodID*, JNI_ArgumentPusher*, Thread*) + 230 >> 15 libjvm.dylib 0x0000000101b0358b >> jni_CallStaticVoidMethodV + 156 >> 16 libjava.dylib 0x000000010060bcff >> JNU_CallStaticMethodByName + 282 >> 17 libawt.dylib 0x000000010953282c AWT_OnLoad + 389 >> 18 libawt.dylib 0x0000000109532873 JNI_OnLoad + 9 >> 19 libjava.dylib 0x0000000100604e76 >> Java_java_lang_ClassLoader_**00024NativeLibrary_load + 207 >> 20 ??? 0x0000000102274738 0 + 4331095864 >> 21 ??? 0x0000000102268058 0 + 4331044952 >> 22 ??? 0x0000000102268350 0 + 4331045712 >> 23 ??? 0x0000000102268350 0 + 4331045712 >> 24 ??? 0x0000000102268058 0 + 4331044952 >> 25 ??? 0x0000000102268058 0 + 4331044952 >> 26 ??? 0x0000000102268058 0 + 4331044952 >> 27 ??? 0x0000000102268233 0 + 4331045427 >> 28 ??? 0x00000001022624e7 0 + 4331021543 >> 29 libjvm.dylib 0x0000000101ad6d90 >> JavaCalls::call_helper(**JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 554 >> 30 libjvm.dylib 0x0000000101ad6b60 >> JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + >> 40 >> 31 libjvm.dylib 0x0000000101b2a444 JVM_DoPrivileged + >> 1041 >> 32 ??? 0x0000000102274738 0 + 4331095864 >> 33 ??? 0x0000000102268233 0 + 4331045427 >> 34 ??? 0x0000000102268058 0 + 4331044952 >> 35 ??? 0x00000001022624e7 0 + 4331021543 >> 36 libjvm.dylib 0x0000000101ad6d90 >> JavaCalls::call_helper(**JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 554 >> 37 libjvm.dylib 0x0000000101ad6b60 >> JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + >> 40 >> 38 libjvm.dylib 0x0000000101aac367 >> instanceKlass::call_class_**initializer_impl(**instanceKlassHandle, >> Thread*) + >> 147 >> 39 libjvm.dylib 0x0000000101aad856 >> instanceKlass::initialize_**impl(instanceKlassHandle, Thread*) + 1484 >> 40 libjvm.dylib 0x0000000101a9fd01 >> instanceKlass::initialize(**Thread*) + 85 >> 41 libjvm.dylib 0x0000000101b9f5ab >> LinkResolver::resolve_static_**call(CallInfo&, KlassHandle&, Symbol*, >> Symbol*, KlassHandle, bool, bool, Thread*) + 173 >> 42 libjvm.dylib 0x0000000101b9f691 >> LinkResolver::resolve_**invokestatic(CallInfo&, constantPoolHandle, int, >> Thread*) + 129 >> 43 libjvm.dylib 0x0000000101ad1f22 >> InterpreterRuntime::resolve_**invoke(JavaThread*, Bytecodes::Code) + 550 >> 44 ??? 0x000000010227f828 0 + 4331141160 >> 45 ??? 0x00000001022624e7 0 + 4331021543 >> 46 libjvm.dylib 0x0000000101ad6d90 >> JavaCalls::call_helper(**JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 554 >> 47 libjvm.dylib 0x0000000101ad6b60 >> JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + >> 40 >> 48 libjvm.dylib 0x0000000101aac367 >> instanceKlass::call_class_**initializer_impl(**instanceKlassHandle, >> Thread*) + >> 147 >> 49 libjvm.dylib 0x0000000101aad856 >> instanceKlass::initialize_**impl(instanceKlassHandle, Thread*) + 1484 >> 50 libjvm.dylib 0x0000000101a9fd01 >> instanceKlass::initialize(**Thread*) + 85 >> 51 libjvm.dylib 0x0000000101b23810 >> find_class_from_class_loader(**JNIEnv_*, Symbol*, unsigned char, Handle, >> Handle, unsigned char, Thread*) + 120 >> 52 libjvm.dylib 0x0000000101b2bf84 >> JVM_FindClassFromClassLoader + 267 >> 53 libjava.dylib 0x0000000100604baf >> Java_java_lang_Class_forName0 + 305 >> 54 ??? 0x0000000102274738 0 + 4331095864 >> 55 ??? 0x0000000102268233 0 + 4331045427 >> 56 ??? 0x0000000102268233 0 + 4331045427 >> 57 ??? 0x00000001022624e7 0 + 4331021543 >> 58 libjvm.dylib 0x0000000101ad6d90 >> JavaCalls::call_helper(**JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 554 >> 59 libjvm.dylib 0x0000000101ad6b60 >> JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + >> 40 >> 60 libjvm.dylib 0x0000000101aac367 >> instanceKlass::call_class_**initializer_impl(**instanceKlassHandle, >> Thread*) + >> 147 >> 61 libjvm.dylib 0x0000000101aad856 >> instanceKlass::initialize_**impl(instanceKlassHandle, Thread*) + 1484 >> 62 libjvm.dylib 0x0000000101a9fd01 >> instanceKlass::initialize(**Thread*) + 85 >> 63 libjvm.dylib 0x0000000101b9f5ab >> LinkResolver::resolve_static_**call(CallInfo&, KlassHandle&, Symbol*, >> Symbol*, KlassHandle, bool, bool, Thread*) + 173 >> 64 libjvm.dylib 0x0000000101b9f691 >> LinkResolver::resolve_**invokestatic(CallInfo&, constantPoolHandle, int, >> Thread*) + 129 >> 65 libjvm.dylib 0x0000000101ad1f22 >> InterpreterRuntime::resolve_**invoke(JavaThread*, Bytecodes::Code) + 550 >> 66 ??? 0x000000010227f828 0 + 4331141160 >> 67 ??? 0x0000000102268058 0 + 4331044952 >> 68 ??? 0x00000001022624e7 0 + 4331021543 >> 69 libjvm.dylib 0x0000000101ad6d90 >> JavaCalls::call_helper(**JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 554 >> 70 libjvm.dylib 0x0000000101ad6b60 >> JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + >> 40 >> 71 libjvm.dylib 0x0000000101aac367 >> instanceKlass::call_class_**initializer_impl(**instanceKlassHandle, >> Thread*) + >> 147 >> 72 libjvm.dylib 0x0000000101aad856 >> instanceKlass::initialize_**impl(instanceKlassHandle, Thread*) + 1484 >> 73 libjvm.dylib 0x0000000101a9fd01 >> instanceKlass::initialize(**Thread*) + 85 >> 74 libjvm.dylib 0x0000000101b9f5ab >> LinkResolver::resolve_static_**call(CallInfo&, KlassHandle&, Symbol*, >> Symbol*, KlassHandle, bool, bool, Thread*) + 173 >> 75 libjvm.dylib 0x0000000101b9f691 >> LinkResolver::resolve_**invokestatic(CallInfo&, constantPoolHandle, int, >> Thread*) + 129 >> 76 libjvm.dylib 0x0000000101ad1f22 >> InterpreterRuntime::resolve_**invoke(JavaThread*, Bytecodes::Code) + 550 >> 77 ??? 0x000000010227f81a 0 + 4331141146 >> 78 ??? 0x00000001022624e7 0 + 4331021543 >> 79 libjvm.dylib 0x0000000101ad6d90 >> JavaCalls::call_helper(**JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 554 >> 80 libjvm.dylib 0x0000000101ad6b60 >> JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + >> 40 >> 81 libjvm.dylib 0x0000000101aac367 >> instanceKlass::call_class_**initializer_impl(**instanceKlassHandle, >> Thread*) + >> 147 >> 82 libjvm.dylib 0x0000000101aad856 >> instanceKlass::initialize_**impl(instanceKlassHandle, Thread*) + 1484 >> 83 libjvm.dylib 0x0000000101a9fd01 >> instanceKlass::initialize(**Thread*) + 85 >> 84 libjvm.dylib 0x0000000101ad2fad >> InterpreterRuntime::_new(**JavaThread*, constantPoolOopDesc*, int) + 161 >> 85 ??? 0x00000001022801a5 0 + 4331143589 >> 86 ??? 0x0000000102268058 0 + 4331044952 >> 87 ??? 0x00000001022624e7 0 + 4331021543 >> 88 libjvm.dylib 0x0000000101ad6d90 >> JavaCalls::call_helper(**JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 554 >> 89 libjvm.dylib 0x0000000101ad6b60 >> JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + >> 40 >> 90 libjvm.dylib 0x0000000101b0a304 >> jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, >> _jmethodID*, JNI_ArgumentPusher*, Thread*) + 230 >> 91 libjvm.dylib 0x0000000101b0349f >> jni_CallStaticVoidMethod + 267 >> 92 libjli.dylib 0x0000000100036572 JavaMain + 2333 >> 93 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 >> 94 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 >> >> Thread 4: >> 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 >> 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + >> 1286 >> 2 libjvm.dylib 0x0000000101c16e29 >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x0000000101bf70be >> ParkCommon(ParkEvent*, long long) + 42 >> 4 libjvm.dylib 0x0000000101bf78b0 >> Monitor::IWait(Thread*, long long) + 160 >> 5 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, >> long, bool) + 375 >> 6 libjvm.dylib 0x0000000101a68e6e >> GCTaskManager::get_task(**unsigned int) + 56 >> 7 libjvm.dylib 0x0000000101a69d63 GCTaskThread::run() >> + >> 349 >> 8 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) >> + >> 294 >> 9 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 >> 10 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 >> >> Thread 5: >> 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 >> 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + >> 1286 >> 2 libjvm.dylib 0x0000000101c16e29 >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x0000000101bf70be >> ParkCommon(ParkEvent*, long long) + 42 >> 4 libjvm.dylib 0x0000000101bf78b0 >> Monitor::IWait(Thread*, long long) + 160 >> 5 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, >> long, bool) + 375 >> 6 libjvm.dylib 0x0000000101a68e6e >> GCTaskManager::get_task(**unsigned int) + 56 >> 7 libjvm.dylib 0x0000000101a69d63 GCTaskThread::run() >> + >> 349 >> 8 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) >> + >> 294 >> 9 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 >> 10 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 >> >> Thread 6: >> 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 >> 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + >> 1286 >> 2 libjvm.dylib 0x0000000101c17ddb >> os::PlatformEvent::park(long long) + 385 >> 3 libjvm.dylib 0x0000000101bf78b0 >> Monitor::IWait(Thread*, long long) + 160 >> 4 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, >> long, bool) + 375 >> 5 libjvm.dylib 0x0000000101d2a8b0 VMThread::loop() + >> 444 >> 6 libjvm.dylib 0x0000000101d2a35b VMThread::run() + >> 121 >> 7 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) >> + >> 294 >> 8 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 >> 9 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 >> >> Thread 7: Java: Reference Handler >> 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 >> 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + >> 1286 >> 2 libjvm.dylib 0x0000000101c16e29 >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x0000000101c0fe57 >> ObjectMonitor::wait(long long, bool, Thread*) + 757 >> 4 libjvm.dylib 0x0000000101cbf4a3 >> ObjectSynchronizer::wait(**Handle, long long, Thread*) + 203 >> 5 libjvm.dylib 0x0000000101b2b0fc JVM_MonitorWait + >> 156 >> 6 ??? 0x0000000102274738 0 + 4331095864 >> 7 ??? 0x0000000102268058 0 + 4331044952 >> 8 ??? 0x0000000102268058 0 + 4331044952 >> 9 ??? 0x00000001022624e7 0 + 4331021543 >> 10 libjvm.dylib 0x0000000101ad6d90 >> JavaCalls::call_helper(**JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 554 >> 11 libjvm.dylib 0x0000000101ad72a7 >> JavaCalls::call_virtual(**JavaValue*, KlassHandle, Symbol*, Symbol*, >> JavaCallArguments*, Thread*) + 283 >> 12 libjvm.dylib 0x0000000101ad73e4 >> JavaCalls::call_virtual(**JavaValue*, Handle, KlassHandle, Symbol*, >> Symbol*, >> Thread*) + 74 >> 13 libjvm.dylib 0x0000000101b263ca >> thread_entry(JavaThread*, Thread*) + 173 >> 14 libjvm.dylib 0x0000000101cefb47 >> JavaThread::thread_main_inner(**) + 155 >> 15 libjvm.dylib 0x0000000101cf124f JavaThread::run() + >> 419 >> 16 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) >> + >> 294 >> 17 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 >> 18 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 >> >> Thread 8: Java: Finalizer >> 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 >> 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + >> 1286 >> 2 libjvm.dylib 0x0000000101c16e29 >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x0000000101c0fe57 >> ObjectMonitor::wait(long long, bool, Thread*) + 757 >> 4 libjvm.dylib 0x0000000101cbf4a3 >> ObjectSynchronizer::wait(**Handle, long long, Thread*) + 203 >> 5 libjvm.dylib 0x0000000101b2b0fc JVM_MonitorWait + >> 156 >> 6 ??? 0x0000000102274738 0 + 4331095864 >> 7 ??? 0x0000000102268058 0 + 4331044952 >> 8 ??? 0x0000000102268233 0 + 4331045427 >> 9 ??? 0x0000000102268233 0 + 4331045427 >> 10 ??? 0x00000001022624e7 0 + 4331021543 >> 11 libjvm.dylib 0x0000000101ad6d90 >> JavaCalls::call_helper(**JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 554 >> 12 libjvm.dylib 0x0000000101ad72a7 >> JavaCalls::call_virtual(**JavaValue*, KlassHandle, Symbol*, Symbol*, >> JavaCallArguments*, Thread*) + 283 >> 13 libjvm.dylib 0x0000000101ad73e4 >> JavaCalls::call_virtual(**JavaValue*, Handle, KlassHandle, Symbol*, >> Symbol*, >> Thread*) + 74 >> 14 libjvm.dylib 0x0000000101b263ca >> thread_entry(JavaThread*, Thread*) + 173 >> 15 libjvm.dylib 0x0000000101cefb47 >> JavaThread::thread_main_inner(**) + 155 >> 16 libjvm.dylib 0x0000000101cf124f JavaThread::run() + >> 419 >> 17 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) >> + >> 294 >> 18 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 >> 19 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 >> >> Thread 9: >> 0 libSystem.B.dylib 0x00007fff874eca2a __workq_kernreturn + >> 10 >> 1 libSystem.B.dylib 0x00007fff874ece3c _pthread_wqthread + >> 917 >> 2 libSystem.B.dylib 0x00007fff874ecaa5 start_wqthread + 13 >> >> Thread 10: Java: Signal Dispatcher >> 0 libSystem.B.dylib 0x00007fff874d2db6 semaphore_wait_trap + >> 10 >> 1 libjvm.dylib 0x0000000101c194a0 >> check_pending_signals(bool) + 128 >> 2 libjvm.dylib 0x0000000101c15da8 >> signal_thread_entry(**JavaThread*, Thread*) + 57 >> 3 libjvm.dylib 0x0000000101cefb47 >> JavaThread::thread_main_inner(**) + 155 >> 4 libjvm.dylib 0x0000000101cf124f JavaThread::run() + >> 419 >> 5 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) >> + >> 294 >> 6 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 >> 7 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 >> >> Thread 11: Java: C2 CompilerThread0 >> 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 >> 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + >> 1286 >> 2 libjvm.dylib 0x0000000101c16e29 >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x0000000101bf70be >> ParkCommon(ParkEvent*, long long) + 42 >> 4 libjvm.dylib 0x0000000101bf78b0 >> Monitor::IWait(Thread*, long long) + 160 >> 5 libjvm.dylib 0x0000000101bf7a74 Monitor::wait(bool, >> long, bool) + 222 >> 6 libjvm.dylib 0x00000001019c10ab CompileQueue::get() >> + >> 153 >> 7 libjvm.dylib 0x00000001019c1c43 >> CompileBroker::compiler_**thread_loop() + 425 >> 8 libjvm.dylib 0x0000000101cefb47 >> JavaThread::thread_main_inner(**) + 155 >> 9 libjvm.dylib 0x0000000101cf124f JavaThread::run() + >> 419 >> 10 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) >> + >> 294 >> 11 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 >> 12 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 >> >> Thread 12: Java: C2 CompilerThread1 >> 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 >> 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + >> 1286 >> 2 libjvm.dylib 0x0000000101c16e29 >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x0000000101bf70be >> ParkCommon(ParkEvent*, long long) + 42 >> 4 libjvm.dylib 0x0000000101bf78b0 >> Monitor::IWait(Thread*, long long) + 160 >> 5 libjvm.dylib 0x0000000101bf7a74 Monitor::wait(bool, >> long, bool) + 222 >> 6 libjvm.dylib 0x00000001019c10ab CompileQueue::get() >> + >> 153 >> 7 libjvm.dylib 0x00000001019c1c43 >> CompileBroker::compiler_**thread_loop() + 425 >> 8 libjvm.dylib 0x0000000101cefb47 >> JavaThread::thread_main_inner(**) + 155 >> 9 libjvm.dylib 0x0000000101cf124f JavaThread::run() + >> 419 >> 10 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) >> + >> 294 >> 11 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 >> 12 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 >> >> Thread 13: Java: Service Thread >> 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 >> 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + >> 1286 >> 2 libjvm.dylib 0x0000000101c16e29 >> os::PlatformEvent::park() + 173 >> 3 libjvm.dylib 0x0000000101bf70be >> ParkCommon(ParkEvent*, long long) + 42 >> 4 libjvm.dylib 0x0000000101bf78b0 >> Monitor::IWait(Thread*, long long) + 160 >> 5 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, >> long, bool) + 375 >> 6 libjvm.dylib 0x0000000101c6f1d5 >> ServiceThread::service_thread_**entry(JavaThread*, Thread*) + 109 >> 7 libjvm.dylib 0x0000000101cefb47 >> JavaThread::thread_main_inner(**) + 155 >> 8 libjvm.dylib 0x0000000101cf124f JavaThread::run() + >> 419 >> 9 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) >> + >> 294 >> 10 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 >> 11 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 >> >> Thread 14: >> 0 libSystem.B.dylib 0x00007fff8750da6a __semwait_signal + 10 >> 1 libSystem.B.dylib 0x00007fff87511881 _pthread_cond_wait + >> 1286 >> 2 libjvm.dylib 0x0000000101c17ddb >> os::PlatformEvent::park(long long) + 385 >> 3 libjvm.dylib 0x0000000101bf78b0 >> Monitor::IWait(Thread*, long long) + 160 >> 4 libjvm.dylib 0x0000000101bf7b0d Monitor::wait(bool, >> long, bool) + 375 >> 5 libjvm.dylib 0x0000000101cf001a >> WatcherThread::sleep() const + 126 >> 6 libjvm.dylib 0x0000000101cf0edd WatcherThread::run() >> + 243 >> 7 libjvm.dylib 0x0000000101c1b1c6 java_start(Thread*) >> + >> 294 >> 8 libSystem.B.dylib 0x00007fff8750bfd6 _pthread_start + 331 >> 9 libSystem.B.dylib 0x00007fff8750be89 thread_start + 13 >> >> Thread 0 crashed with X86 Thread State (64-bit): >> rax: 0x0000000000000000 rbx: 0x00007fff809c8734 rcx: >> 0x0000000000000000 >> rdx: 0x00007fff70e7acc0 >> rdi: 0x000000000000003b rsi: 0x0000000000000001 rbp: >> 0x00007fff5fbfc740 >> rsp: 0x00007fff5fbfc6f0 >> r8: 0x0000000000000001 r9: 0x00000001003266c0 r10: >> 0x0000000000000001 >> r11: 0x000000000000003f >> r12: 0x0000000000000000 r13: 0x0000000109714390 r14: >> 0x00000001097143b8 >> r15: 0x0000000109714390 >> rip: 0x00007fff861a88a1 rfl: 0x0000000000000287 cr2: >> 0x0000000108cff000 >> >> Binary Images: >> 0x100033000 - 0x10003dfff +libjli.dylib ??? (???) >> <32A3CEF6-9D91-3B97-9F17-**CAD9301081D1> /Volumes/Windows >> VMS/NetbeansProjects/PDFOCRX2/**PDFOCRX2_Mac/dist/PDF OCR X Community >> Edition.app/Contents/PlugIns/**jdk1.7.0_45.jdk/Contents/Home/** >> jre/lib/jli/libjli.dylib >> 0x1000ec000 - 0x1000f4fff +libverify.dylib ??? (???) >> /Volumes/Windows >> VMS/NetbeansProjects/PDFOCRX2/**PDFOCRX2_Mac/dist/PDF OCR X Community >> Edition.app/Contents/PlugIns/**jdk1.7.0_45.jdk/Contents/Home/** >> jre/lib/libverify.dylib >> 0x1002e2000 - 0x1002e7fff +libzip.dylib ??? (???) >> <50D7966F-6590-3F9A-A42B-**7E7EE016493E> /Volumes/Windows >> VMS/NetbeansProjects/PDFOCRX2/**PDFOCRX2_Mac/dist/PDF OCR X Community >> Edition.app/Contents/PlugIns/**jdk1.7.0_45.jdk/Contents/Home/** >> jre/lib/libzip.dylib >> 0x1002ee000 - 0x1002f3ff7 com.apple.JavaVM 13.9.8 (13.9.8) >> >> /System/Library/Frameworks/**JavaVM.framework/Versions/A/**JavaVM >> 0x100603000 - 0x100624fe7 +libjava.dylib ??? (???) >> <64871BED-E504-307F-BCEE-**EA4CCEA588EA> /Volumes/Windows >> VMS/NetbeansProjects/PDFOCRX2/**PDFOCRX2_Mac/dist/PDF OCR X Community >> Edition.app/Contents/PlugIns/**jdk1.7.0_45.jdk/Contents/Home/** >> jre/lib/libjava.dylib >> 0x101800000 - 0x101f45fef +libjvm.dylib ??? (???) >> <7CBD0F39-332A-3790-B0FF-**F5F955C325A6> /Volumes/Windows >> VMS/NetbeansProjects/PDFOCRX2/**PDFOCRX2_Mac/dist/PDF OCR X Community >> Edition.app/Contents/PlugIns/**jdk1.7.0_45.jdk/Contents/Home/** >> jre/lib/server/libjvm.dylib >> 0x1066c6000 - 0x1066d1fef com.apple.java.** >> JavaRuntimeSupport >> 13.9.8 (13.9.8) <78E0442F-7DF4-5DAA-2DF1-**1570AE1AAEC8> >> /System/Library/Frameworks/**JavaVM.framework/Frameworks/** >> JavaRuntimeSupport.framework/**JavaRuntimeSupport >> 0x1066e2000 - 0x1066edfff JavaNativeFoundation ??? (???) >> <81035866-C9A3-6ADC-920F-**A2C02D6DB95B> >> /System/Library/Frameworks/**JavaVM.framework/Versions/A/**Frameworks/** >> JavaNativeFoundation.**framework/Versions/A/**JavaNativeFoundation >> 0x1066f8000 - 0x1066feff7 JavaLaunching ??? (???) >> <8A4FFBEC-90DB-3EB1-68E7-**4EF8A0F47F52> >> /System/Library/**PrivateFrameworks/**JavaLaunching.framework/** >> Versions/A/JavaLaunching >> 0x1067ac000 - 0x1067affff >> +ca.weblite.PDFOCRX.**CommunityEdition 2.0.0 (2.0.0) >> <085DD0B7-34B2-3A2D-BFC7-**4CA094FC70DE> /Volumes/Windows >> VMS/NetbeansProjects/PDFOCRX2/**PDFOCRX2_Mac/dist/PDF OCR X Community >> Edition.app/Contents/MacOS/**JavaAppLauncher >> 0x1094d4000 - 0x10953ffff +libawt.dylib ??? (???) >> <5F027771-D669-392F-8DD7-**CBA3EA5DD87D> /Volumes/Windows >> VMS/NetbeansProjects/PDFOCRX2/**PDFOCRX2_Mac/dist/PDF OCR X Community >> Edition.app/Contents/PlugIns/**jdk1.7.0_45.jdk/Contents/Home/** >> jre/lib/libawt.dylib >> 0x109586000 - 0x10964bfff +libmlib_image.dylib ??? (???) >> <95F6D0B2-3A92-305F-A6AE-**822BC990901B> /Volumes/Windows >> VMS/NetbeansProjects/PDFOCRX2/**PDFOCRX2_Mac/dist/PDF OCR X Community >> Edition.app/Contents/PlugIns/**jdk1.7.0_45.jdk/Contents/Home/** >> jre/lib/libmlib_image.dylib >> 0x109656000 - 0x1096c6fff +liblwawt.dylib ??? (???) >> <9875DBAB-B5B6-322C-A085-**4651CEDFCBF4> /Volumes/Windows >> VMS/NetbeansProjects/PDFOCRX2/**PDFOCRX2_Mac/dist/PDF OCR X Community >> Edition.app/Contents/PlugIns/**jdk1.7.0_45.jdk/Contents/Home/** >> jre/lib/lwawt/liblwawt.dylib >> 0x10970d000 - 0x109712fff +libosxapp.dylib ??? (???) >> <8CE761D7-7DAA-36BA-8424-**BF74590F8C1D> /Volumes/Windows >> VMS/NetbeansProjects/PDFOCRX2/**PDFOCRX2_Mac/dist/PDF OCR X Community >> Edition.app/Contents/PlugIns/**jdk1.7.0_45.jdk/Contents/Home/** >> jre/lib/libosxapp.dylib >> 0x7fff5fc00000 - 0x7fff5fc3be0f dyld 132.1 (???) >> <29DECB19-0193-2575-D838-**CF743F0400B2> /usr/lib/dyld >> 0x7fff80003000 - 0x7fff80093fff com.apple.SearchKit 1.3.0 >> (1.3.0) >> <4175DC31-1506-228A-08FD-**C704AC9DF642> >> /System/Library/Frameworks/**CoreServices.framework/** >> Versions/A/Frameworks/**SearchKit.framework/Versions/**A/SearchKit >> 0x7fff80094000 - 0x7fff80171fff com.apple.vImage 4.1 (4.1) >> >> /System/Library/Frameworks/**Accelerate.framework/Versions/** >> A/Frameworks/vImage.framework/**Versions/A/vImage >> 0x7fff80172000 - 0x7fff801f7ff7 >> com.apple.print.framework.**PrintCore 6.3 (312.7) >> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/**PrintCore.framework/Versions/**A/PrintCore >> 0x7fff801f8000 - 0x7fff8020ffff com.apple.ImageCapture 6.1 (6.1) >> <79AB2131-2A6C-F351-38A9-**ED58B25534FD> >> /System/Library/Frameworks/**Carbon.framework/Versions/A/** >> Frameworks/ImageCapture.**framework/Versions/A/**ImageCapture >> 0x7fff80222000 - 0x7fff80231fff com.apple.NetFS 3.2.2 (3.2.2) >> <7CCBD70E-BF31-A7A7-DB98-**230687773145> >> /System/Library/Frameworks/**NetFS.framework/Versions/A/**NetFS >> 0x7fff80232000 - 0x7fff80c2cff7 com.apple.AppKit 6.6.8 (1038.36) >> <4CFBE04C-8FB3-B0EA-8DDB-**7E7D10E9D251> >> /System/Library/Frameworks/**AppKit.framework/Versions/C/**AppKit >> 0x7fff80c2d000 - 0x7fff80c34fff com.apple.OpenDirectory 10.6 >> (10.6) <4FF6AD25-0916-B21C-9E88-**2CC42D90EAC7> >> /System/Library/Frameworks/**OpenDirectory.framework/** >> Versions/A/OpenDirectory >> 0x7fff80c35000 - 0x7fff80cf2fff com.apple.CoreServices.** >> OSServices >> 359.2 (359.2) >> /System/Library/Frameworks/**CoreServices.framework/** >> Versions/A/Frameworks/**OSServices.framework/Versions/**A/OSServices >> 0x7fff80d25000 - 0x7fff80d4aff7 com.apple.CoreVideo 1.6.2 (45.6) >> >> /System/Library/Frameworks/**CoreVideo.framework/Versions/**A/CoreVideo >> 0x7fff80d70000 - 0x7fff80db1fff com.apple.SystemConfiguration >> 1.10.8 (1.10.2) <78D48D27-A9C4-62CA-2803-**D0BBED82855A> >> /System/Library/Frameworks/**SystemConfiguration.framework/** >> Versions/A/SystemConfiguration >> 0x7fff810ad000 - 0x7fff81162fe7 com.apple.ink.framework 1.3.3 >> (107) <8C36373C-5473-3A6A-4972-**BC29D504250F> >> /System/Library/Frameworks/**Carbon.framework/Versions/A/** >> Frameworks/Ink.framework/**Versions/A/Ink >> 0x7fff8116f000 - 0x7fff811d9fe7 libvMisc.dylib 268.0.1 >> (compatibility 1.0.0) >> /System/Library/Frameworks/**Accelerate.framework/Versions/** >> A/Frameworks/vecLib.framework/**Versions/A/libvMisc.dylib >> 0x7fff81464000 - 0x7fff81504fff com.apple.LaunchServices 362.3 >> (362.3) >> /System/Library/Frameworks/**CoreServices.framework/** >> Versions/A/Frameworks/**LaunchServices.framework/** >> Versions/A/LaunchServices >> 0x7fff81505000 - 0x7fff81551fff libauto.dylib ??? (???) >> /usr/lib/libauto.dylib >> 0x7fff81552000 - 0x7fff81583fff libGLImage.dylib ??? (???) >> <562565E1-AA65-FE96-13FF-**437410C886D0> >> /System/Library/Frameworks/**OpenGL.framework/Versions/A/** >> Libraries/libGLImage.dylib >> 0x7fff81584000 - 0x7fff81584ff7 com.apple.Cocoa 6.6 (???) >> <68B0BE46-6E24-C96F-B341-**054CF9E8F3B6> >> /System/Library/Frameworks/**Cocoa.framework/Versions/A/**Cocoa >> 0x7fff81be0000 - 0x7fff81cb4fe7 com.apple.CFNetwork 454.12.4 >> (454.12.4) >> /System/Library/Frameworks/**CoreServices.framework/** >> Versions/A/Frameworks/**CFNetwork.framework/Versions/**A/CFNetwork >> 0x7fff81e7a000 - 0x7fff82576ff7 com.apple.CoreGraphics 1.545.0 >> (???) <58D597B1-EB3B-710E-0B8C-**EC114D54E11B> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/**CoreGraphics.framework/**Versions/A/CoreGraphics >> 0x7fff82605000 - 0x7fff82628fff com.apple.opencl 12.3.6 (12.3.6) >> <42FA5783-EB80-1168-4015-**B8C68F55842F> >> /System/Library/Frameworks/**OpenCL.framework/Versions/A/**OpenCL >> 0x7fff82629000 - 0x7fff826a6fef libstdc++.6.dylib 7.9.0 >> (compatibility 7.0.0) <35ECA411-2C08-FD7D-11B1-**1B7A04921A5C> >> /usr/lib/libstdc++.6.dylib >> 0x7fff82a14000 - 0x7fff82a17ff7 libCoreVMClient.dylib ??? (???) >> <75819794-3B7A-8944-D004-**7EA6DD7CE836> >> /System/Library/Frameworks/**OpenGL.framework/Versions/A/** >> Libraries/libCoreVMClient.**dylib >> 0x7fff82a18000 - 0x7fff82a5fff7 com.apple.coreui 2 (114) >> <923E33CC-83FC-7D35-5603-**FB8F348EE34B> >> /System/Library/**PrivateFrameworks/CoreUI.**framework/Versions/A/CoreUI >> 0x7fff82a9e000 - 0x7fff82af4fe7 libTIFF.dylib ??? (???) >> <2DBEC120-DAA7-3789-36A2-**A205BCDF2D72> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/ImageIO.**framework/Versions/A/** >> Resources/libTIFF.dylib >> 0x7fff83344000 - 0x7fff83359ff7 com.apple.LangAnalysis 1.6.6 >> (1.6.6) <1AE1FE8F-2204-4410-C94E-**0E93B003BEDA> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/**LangAnalysis.framework/**Versions/A/LangAnalysis >> 0x7fff8335a000 - 0x7fff8335ffff libGIF.dylib ??? (???) >> <3BAD0DE8-8151-68B0-2244-**A4541C738972> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/ImageIO.**framework/Versions/A/** >> Resources/libGIF.dylib >> 0x7fff83360000 - 0x7fff83361fff liblangid.dylib ??? (???) >> /usr/lib/liblangid.dylib >> 0x7fff83362000 - 0x7fff833a3fef com.apple.QD 3.36 (???) >> <5DC41E81-32C9-65B2-5528-**B33E934D5BB4> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/QD.**framework/Versions/A/QD >> 0x7fff833a4000 - 0x7fff833a6fff libRadiance.dylib ??? (???) >> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/ImageIO.**framework/Versions/A/** >> Resources/libRadiance.dylib >> 0x7fff833a7000 - 0x7fff83419fef com.apple.CoreSymbolication 2.0 >> (23) <06F8561E-4B36-7BF6-31BA-**64091B3D8058> >> /System/Library/**PrivateFrameworks/**CoreSymbolication.framework/** >> Versions/A/CoreSymbolication >> 0x7fff834a4000 - 0x7fff83530fef SecurityFoundation ??? (???) >> <3F1F2727-C508-3630-E2C1-**38361841FCE4> >> /System/Library/Frameworks/**SecurityFoundation.framework/** >> Versions/A/SecurityFoundation >> 0x7fff8353a000 - 0x7fff835f0ff7 libobjc.A.dylib 227.0.0 >> (compatibility 1.0.0) <03140531-3B2D-1EBA-DA7F-**E12CC8F63969> >> /usr/lib/libobjc.A.dylib >> 0x7fff837b2000 - 0x7fff837edfff com.apple.AE 496.5 (496.5) >> <208DF391-4DE6-81ED-C697-**14A2930D1BC6> >> /System/Library/Frameworks/**CoreServices.framework/** >> Versions/A/Frameworks/AE.**framework/Versions/A/AE >> 0x7fff837f8000 - 0x7fff839b6fff libicucore.A.dylib 40.0.0 >> (compatibility 1.0.0) <97A75BFB-0DB6-6F44-36B0-**97B7F7208ABB> >> /usr/lib/libicucore.A.dylib >> 0x7fff839b7000 - 0x7fff839bbff7 libmathCommon.A.dylib 315.0.0 >> (compatibility 1.0.0) <95718673-FEEE-B6ED-B127-**BCDBDB60D4E5> >> /usr/lib/system/libmathCommon.**A.dylib >> 0x7fff839bc000 - 0x7fff839e3ff7 libJPEG.dylib ??? (???) >> <08758593-6436-B29E-1DA8-**F15597835EC1> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/ImageIO.**framework/Versions/A/** >> Resources/libJPEG.dylib >> 0x7fff83add000 - 0x7fff83ae8ff7 >> com.apple.speech.recognition.**framework 3.11.1 (3.11.1) >> <3D65E89B-FFC6-4AAF-D5CC-**104F967C8131> >> /System/Library/Frameworks/**Carbon.framework/Versions/A/** >> Frameworks/SpeechRecognition.**framework/Versions/A/**SpeechRecognition >> 0x7fff83c02000 - 0x7fff83c40fef com.apple.DebugSymbols 1.1 (70) >> >> /System/Library/**PrivateFrameworks/**DebugSymbols.framework/** >> Versions/A/DebugSymbols >> 0x7fff83d01000 - 0x7fff83d01ff7 com.apple.CoreServices 44 (44) >> >> /System/Library/Frameworks/**CoreServices.framework/** >> Versions/A/CoreServices >> 0x7fff84046000 - 0x7fff8404cff7 IOSurface ??? (???) >> <8E302BB2-0704-C6AB-BD2F-**C2A6C6A2E2C3> >> /System/Library/Frameworks/**IOSurface.framework/Versions/**A/IOSurface >> 0x7fff8404d000 - 0x7fff84095ff7 libvDSP.dylib 268.0.1 >> (compatibility 1.0.0) <98FC4457-F405-0262-00F7-**56119CA107B6> >> /System/Library/Frameworks/**Accelerate.framework/Versions/** >> A/Frameworks/vecLib.framework/**Versions/A/libvDSP.dylib >> 0x7fff845e4000 - 0x7fff8460cfff com.apple.DictionaryServices >> 1.1.2 >> (1.1.2) >> /System/Library/Frameworks/**CoreServices.framework/** >> Versions/A/Frameworks/**DictionaryServices.framework/** >> Versions/A/DictionaryServices >> 0x7fff84615000 - 0x7fff847d4fff com.apple.ImageIO.framework >> 3.0.6 >> (3.0.6) <92882FD3-CB3F-D0BE-DDDA-**43B4BEE10F58> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/ImageIO.**framework/Versions/A/ImageIO >> 0x7fff847d5000 - 0x7fff84b72fe7 com.apple.QuartzCore 1.6.3 >> (227.37) <16DFF6CD-EA58-CE62-A1D7-**5F6CE3D066DD> >> /System/Library/Frameworks/**QuartzCore.framework/Versions/**A/QuartzCore >> 0x7fff84b73000 - 0x7fff84b81ff7 libkxld.dylib ??? (???) >> <8145A534-95CC-9F3C-B78B-**AC9898F38C6F> /usr/lib/system/libkxld.dylib >> 0x7fff84ca0000 - 0x7fff84ce9fef libGLU.dylib ??? (???) >> >> /System/Library/Frameworks/**OpenGL.framework/Versions/A/** >> Libraries/libGLU.dylib >> 0x7fff84d2c000 - 0x7fff84d4dfff libresolv.9.dylib 41.1.0 >> (compatibility 1.0.0) <9410EC7F-4D24-6740-AFEE-**90405750FAD7> >> /usr/lib/libresolv.9.dylib >> 0x7fff84d4e000 - 0x7fff84e64ff7 libxml2.2.dylib 10.3.0 >> (compatibility 10.0.0) <3814FCF9-92B9-A6AB-E76A-**F7021894AA3F> >> /usr/lib/libxml2.2.dylib >> 0x7fff84ef7000 - 0x7fff85016ff7 libcrypto.0.9.8.dylib 0.9.8 >> (compatibility 0.9.8) <0CE8D59B-D0C7-1DCE-3654-**37F27F61BEFA> >> /usr/lib/libcrypto.0.9.8.dylib >> 0x7fff85017000 - 0x7fff85017ff7 com.apple.ApplicationServices 38 >> (38) <10A0B9E9-4988-03D4-FC56-**DDE231A02C63> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/ApplicationServices >> 0x7fff8547c000 - 0x7fff85596fff libGLProgrammability.dylib ??? >> (???) >> /System/Library/Frameworks/**OpenGL.framework/Versions/A/**Libraries/** >> libGLProgrammability.dylib >> 0x7fff856df000 - 0x7fff856dfff7 com.apple.Carbon 150 (152) >> <23704665-E9F4-6B43-1115-**2E69F161FC45> >> /System/Library/Frameworks/**Carbon.framework/Versions/A/**Carbon >> 0x7fff85720000 - 0x7fff85726ff7 com.apple.CommerceCore 1.0 (9.1) >> <3691E9BA-BCF4-98C7-EFEC-**78DA6825004E> >> /System/Library/**PrivateFrameworks/CommerceKit.**framework/Versions/A/** >> Frameworks/CommerceCore.**framework/Versions/A/**CommerceCore >> 0x7fff857dd000 - 0x7fff858c2fef com.apple.DesktopServices 1.5.11 >> (1.5.11) <39FAA3D2-6863-B5AB-AED9-**92D878EA2438> >> /System/Library/**PrivateFrameworks/**DesktopServicesPriv.framework/** >> Versions/A/DesktopServicesPriv >> 0x7fff858c3000 - 0x7fff858eeff7 libxslt.1.dylib 3.24.0 >> (compatibility 3.0.0) <3630A97F-55C1-3F34-CA63-**3847653C9645> >> /usr/lib/libxslt.1.dylib >> 0x7fff8596b000 - 0x7fff85a2dfe7 libFontParser.dylib ??? (???) >> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/ATS.**framework/Versions/A/** >> Resources/libFontParser.dylib >> 0x7fff85caa000 - 0x7fff85cbefff libGL.dylib ??? (???) >> <2ECE3B0F-39E1-3938-BF27-**7205C6D0358B> >> /System/Library/Frameworks/**OpenGL.framework/Versions/A/** >> Libraries/libGL.dylib >> 0x7fff85f15000 - 0x7fff85f29ff7 >> com.apple.speech.synthesis.**framework 3.10.35 (3.10.35) >> <621B7415-A0B9-07A7-F313-**36BEEDD7B132> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/**SpeechSynthesis.framework/** >> Versions/A/SpeechSynthesis >> 0x7fff86125000 - 0x7fff8629cfe7 com.apple.CoreFoundation 6.6.6 >> (550.44) >> /System/Library/Frameworks/**CoreFoundation.framework/** >> Versions/A/CoreFoundation >> 0x7fff863a6000 - 0x7fff863b5fef com.apple.opengl 1.6.14 (1.6.14) >> >> /System/Library/Frameworks/**OpenGL.framework/Versions/A/**OpenGL >> 0x7fff863b6000 - 0x7fff86477fef com.apple.ColorSync 4.6.8 >> (4.6.8) >> <7DF1D175-6451-51A2-DBBF-**40FCA78C0D2C> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/**ColorSync.framework/Versions/**A/ColorSync >> 0x7fff86478000 - 0x7fff86512fff com.apple.ApplicationServices.* >> *ATS >> 275.19 (???) <2DE8987F-4563-4D8E-45C3-**2F6F786E120D> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/ATS.**framework/Versions/A/ATS >> 0x7fff86513000 - 0x7fff86648fff >> com.apple.audio.toolbox.**AudioToolbox 1.6.7 (1.6.7) >> >> /System/Library/Frameworks/**AudioToolbox.framework/** >> Versions/A/AudioToolbox >> 0x7fff86716000 - 0x7fff86716ff7 com.apple.Accelerate.vecLib 3.6 >> (vecLib 3.6) <4CCE5D69-F1B3-8FD3-1483-**E0271DB2CCF3> >> /System/Library/Frameworks/**Accelerate.framework/Versions/** >> A/Frameworks/vecLib.framework/**Versions/A/vecLib >> 0x7fff86717000 - 0x7fff8672dfe7 >> com.apple.MultitouchSupport.**framework 207.11 (207.11) >> <8233CE71-6F8D-8B3C-A0E1-**E123F6406163> >> /System/Library/**PrivateFrameworks/**MultitouchSupport.framework/** >> Versions/A/MultitouchSupport >> 0x7fff8673c000 - 0x7fff869befff com.apple.Foundation 6.6.8 >> (751.63) >> /System/Library/Frameworks/**Foundation.framework/Versions/**C/Foundation >> 0x7fff869bf000 - 0x7fff869c0ff7 com.apple.TrustEvaluationAgent >> 1.1 >> (1) <5952A9FA-BC2B-16EF-91A7-**43902A5C07B6> >> /System/Library/**PrivateFrameworks/**TrustEvaluationAgent.** >> framework/Versions/A/**TrustEvaluationAgent >> 0x7fff869c1000 - 0x7fff86cbffff com.apple.HIToolbox 1.6.5 (???) >> >> /System/Library/Frameworks/**Carbon.framework/Versions/A/** >> Frameworks/HIToolbox.**framework/Versions/A/HIToolbox >> 0x7fff86cc0000 - 0x7fff86cc3fff com.apple.help 1.3.2 (41.1) >> >> /System/Library/Frameworks/**Carbon.framework/Versions/A/** >> Frameworks/Help.framework/**Versions/A/Help >> 0x7fff86d04000 - 0x7fff86d09ff7 com.apple.CommonPanels 1.2.4 >> (91) >> <4D84803B-BD06-D80E-15AE-**EFBE43F93605> >> /System/Library/Frameworks/**Carbon.framework/Versions/A/** >> Frameworks/CommonPanels.**framework/Versions/A/**CommonPanels >> 0x7fff86d3b000 - 0x7fff8706ffef com.apple.CoreServices.** >> CarbonCore >> 861.39 (861.39) <1386A24D-DD15-5903-057E-**4A224FAF580B> >> /System/Library/Frameworks/**CoreServices.framework/** >> Versions/A/Frameworks/**CarbonCore.framework/Versions/**A/CarbonCore >> 0x7fff87070000 - 0x7fff871aefff com.apple.CoreData 102.1 (251) >> <9DFE798D-AA52-6A9A-924A-**DA73CB94D81A> >> /System/Library/Frameworks/**CoreData.framework/Versions/A/**CoreData >> 0x7fff872e4000 - 0x7fff872e4ff7 com.apple.vecLib 3.6 (vecLib >> 3.6) >> <96FB6BAD-5568-C4E0-6FA7-**02791A58B584> >> /System/Library/Frameworks/**vecLib.framework/Versions/A/**vecLib >> 0x7fff872e5000 - 0x7fff872e6ff7 com.apple.audio.units.** >> AudioUnit >> 1.6.7 (1.6.7) <49B723D1-85F8-F86C-2331-**F586C56D68AF> >> /System/Library/Frameworks/**AudioUnit.framework/Versions/**A/AudioUnit >> 0x7fff873c0000 - 0x7fff873dbff7 com.apple.openscripting 1.3.1 >> (???) <9D50701D-54AC-405B-CC65-**026FCB28258B> >> /System/Library/Frameworks/**Carbon.framework/Versions/A/** >> Frameworks/OpenScripting.**framework/Versions/A/**OpenScripting >> 0x7fff873dc000 - 0x7fff87416fff libcups.2.dylib 2.8.0 >> (compatibility 2.0.0) <4F2A4397-89BD-DEAC-4971-**EE838FFA0964> >> /usr/lib/libcups.2.dylib >> 0x7fff87430000 - 0x7fff874affe7 com.apple.audio.CoreAudio 3.2.6 >> (3.2.6) <79E256EB-43F1-C7AA-6436-**124A4FFB02D0> >> /System/Library/Frameworks/**CoreAudio.framework/Versions/**A/CoreAudio >> 0x7fff874b0000 - 0x7fff874d1fe7 libPng.dylib ??? (???) >> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/ImageIO.**framework/Versions/A/** >> Resources/libPng.dylib >> 0x7fff874d2000 - 0x7fff87693fef libSystem.B.dylib 125.2.11 >> (compatibility 1.0.0) <9AB4F1D1-89DC-0E8A-DC8E-**A4FE4D69DB69> >> /usr/lib/libSystem.B.dylib >> 0x7fff87694000 - 0x7fff87696fff com.apple.print.framework.** >> Print >> 6.1 (237.1) >> /System/Library/Frameworks/**Carbon.framework/Versions/A/** >> Frameworks/Print.framework/**Versions/A/Print >> 0x7fff876ad000 - 0x7fff876b2fff libGFXShared.dylib ??? (???) >> <6BBC351E-40B3-F4EB-2F35-**05BDE52AF87E> >> /System/Library/Frameworks/**OpenGL.framework/Versions/A/** >> Libraries/libGFXShared.dylib >> 0x7fff876b3000 - 0x7fff876c9fef libbsm.0.dylib ??? (???) >> <42D3023A-A1F7-4121-6417-**FCC6B51B3E90> /usr/lib/libbsm.0.dylib >> 0x7fff8788c000 - 0x7fff8788efef com.apple.ExceptionHandling 1.5 >> (10) >> /System/Library/Frameworks/**ExceptionHandling.framework/** >> Versions/A/ExceptionHandling >> 0x7fff8788f000 - 0x7fff8790dff7 com.apple.CoreText 151.13 (???) >> <5C6214AD-D683-80A8-86EB-**328C99B75322> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/**CoreText.framework/Versions/A/**CoreText >> 0x7fff8790e000 - 0x7fff8790eff7 com.apple.Accelerate 1.6 >> (Accelerate 1.6) <15DF8B4A-96B2-CB4E-368D-**DEC7DF6B62BB> >> /System/Library/Frameworks/**Accelerate.framework/Versions/**A/Accelerate >> 0x7fff8790f000 - 0x7fff87b98ff7 com.apple.security 6.1.2 (55002) >> >> /System/Library/Frameworks/**Security.framework/Versions/A/**Security >> 0x7fff88c04000 - 0x7fff88c57ff7 com.apple.HIServices 1.8.3 (???) >> >> /System/Library/Frameworks/**ApplicationServices.framework/** >> Versions/A/Frameworks/**HIServices.framework/Versions/**A/HIServices >> 0x7fff88c59000 - 0x7fff88c72fff com.apple.CFOpenDirectory 10.6 >> (10.6) <401557B1-C6D1-7E1A-0D7E-**941715C37BFA> >> /System/Library/Frameworks/**OpenDirectory.framework/** >> Versions/A/Frameworks/**CFOpenDirectory.framework/** >> Versions/A/CFOpenDirectory >> 0x7fff88c97000 - 0x7fff88cecff7 com.apple.framework.** >> familycontrols >> 2.0.2 (2020) <8807EB96-D12D-8601-2E74-**25784A0DE4FF> >> /System/Library/**PrivateFrameworks/**FamilyControls.framework/** >> Versions/A/FamilyControls >> 0x7fff88cfb000 - 0x7fff88db4fff libsqlite3.dylib 9.6.0 >> (compatibility 9.0.0) <2C5ED312-E646-9ADE-73A9-**6199A2A43150> >> /usr/lib/libsqlite3.dylib >> 0x7fff88dc7000 - 0x7fff88de7fff >> com.apple.DirectoryService.**Framework 3.6 (621.16) >> <0ED4A74A-F8FB-366D-6588-**F13EA397326F> >> /System/Library/Frameworks/**DirectoryService.framework/** >> Versions/A/DirectoryService >> 0x7fff88de8000 - 0x7fff88deeff7 com.apple.DiskArbitration 2.3 >> (2.3) <857F6E43-1EF4-7D53-351B-**10DE0A8F992A> >> /System/Library/Frameworks/**DiskArbitration.framework/** >> Versions/A/DiskArbitration >> 0x7fff89584000 - 0x7fff89d8efe7 libBLAS.dylib 219.0.0 >> (compatibility 1.0.0) >> /System/Library/Frameworks/**Accelerate.framework/Versions/** >> A/Frameworks/vecLib.framework/**Versions/A/libBLAS.dylib >> 0x7fff89e94000 - 0x7fff89edeff7 com.apple.Metadata 10.6.3 >> (507.15) >> >> /System/Library/Frameworks/**CoreServices.framework/** >> Versions/A/Frameworks/**Metadata.framework/Versions/A/**Metadata >> 0x7fff89edf000 - 0x7fff89ef0ff7 libz.1.dylib 1.2.3 >> (compatibility >> 1.0.0) <97019C74-161A-3488-41EC-**A6CA8738418C> /usr/lib/libz.1.dylib >> 0x7fff89ef1000 - 0x7fff89fa1fff edu.mit.Kerberos 6.5.11 (6.5.11) >> <085D80F5-C9DC-E252-C21B-**03295E660C91> >> /System/Library/Frameworks/**Kerberos.framework/Versions/A/**Kerberos >> 0x7fff89fa2000 - 0x7fff89fb4fe7 libsasl2.2.dylib 3.15.0 >> (compatibility 3.0.0) <76B83C8D-8EFE-4467-0F75-**275648AFED97> >> /usr/lib/libsasl2.2.dylib >> 0x7fff8a1ac000 - 0x7fff8a20cfe7 com.apple.framework.IOKit 2.0 >> (???) <4F071EF0-8260-01E9-C641-**830E582FA416> >> /System/Library/Frameworks/**IOKit.framework/Versions/A/**IOKit >> 0x7fff8a27a000 - 0x7fff8a27dff7 com.apple.securityhi 4.0 (36638) >> >> /System/Library/Frameworks/**Carbon.framework/Versions/A/** >> Frameworks/SecurityHI.**framework/Versions/A/**SecurityHI >> 0x7fff8a27e000 - 0x7fff8a6c1fef libLAPACK.dylib 219.0.0 >> (compatibility 1.0.0) <0CC61C98-FF51-67B3-F3D8-**C5E430C201A9> >> /System/Library/Frameworks/**Accelerate.framework/Versions/** >> A/Frameworks/vecLib.framework/**Versions/A/libLAPACK.dylib >> 0x7fff8a6c2000 - 0x7fff8a711ff7 >> com.apple.DirectoryService.**PasswordServerFramework 6.1 (6.1) >> <0731C40D-71EF-B417-C83B-**54C3527A36EA> >> /System/Library/**PrivateFrameworks/**PasswordServer.framework/** >> Versions/A/PasswordServer >> 0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib ??? (???) >> <9AB4F1D1-89DC-0E8A-DC8E-**A4FE4D69DB69> /usr/lib/libSystem.B.dylib >> >> -- Steve Hannah Web Lite Solutions Corp. From Johannes.Schindelin at gmx.de Tue Oct 22 11:12:44 2013 From: Johannes.Schindelin at gmx.de (Johannes Schindelin) Date: Tue, 22 Oct 2013 20:12:44 +0200 (CEST) Subject: Crash on startup in SnowLeopard 1.7.0_45 In-Reply-To: <5266BD29.4090305@oracle.com> References: <5266BD29.4090305@oracle.com> Message-ID: Hi Anthony, On Tue, 22 Oct 2013, Anthony Petrov wrote: > http://www.java.com/en/download/help/sysreq.xml > > > Mac OS X > > > > Intel-based Mac running Mac OS X 10.7.3 (Lion) or later. > > So, 10.6.8 is simply unsupported. Please consider upgrading your OS. I have to admit that this makes me very sad. I work in an academic environment (read: financially restricted unless you happen to work on the NIH campus in DC) where upgrading is often simply not an option. It would have been so nice if OpenJDK had made it possible to finally upgrade Java even on those old machines where even 10.7 just does not run properly. Thank you for your hard work nevertheless, Johannes From david.dehaven at oracle.com Tue Oct 22 11:15:31 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 22 Oct 2013 11:15:31 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5266BD67.4010101@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> Message-ID: <7F14B1EF-457C-45F3-8AAA-19DC365EB065@oracle.com> [removing hotspot-dev and build-dev..] I can't look at the code at the moment as I'm focused on something else... Does the wrapping happen automagically at some point based on java.awt.headless? It doesn't look trivial to do this from within the scope of java_props_md.c, it seems the best I could do from there is trigger java.awt.headless=true if we're not in a headful login session. It would be fairly simple to have it set java.awt.headless if the logic is there to do the HeadlessToolkit wrapping, and that's something that could be done for all platforms (though only Mac would use it for the moment). Otherwise I can just revert it back to my original version and we can continue using HToolkit for now. With the current code, JTREG fails massively in headless mode (due to most calls throwing a HeadlessException) and JPRT performs horribly when running the jdk_awt tests due to it not running in an Aqua session. Is there some reliable way of testing headless mode? -DrD- > Hello. > I suppose we should request from sqe team to run the jck tests in the "true" headless mode via ssh(w/o headless option and w/o access to Aqua session). > > On 22.10.2013 21:54, Anthony Petrov wrote: >> We don't have to. IIRC, the choice of HToolkit on Mac was made by chance. >> >> Since we must load the lwawt lib in headless on Mac anyway, we may as well use the CToolkit (properly wrapped in the HeadlessToolkit). But there's no need to continue to use the HToolkit on Mac. >> >> -- >> best regards, >> Anthony >> >> On 10/22/2013 08:22 PM, Leonid Romanov wrote: >>> There was a discussion why we use HToolkit instead of HeadlessToolkit: >>> http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html >>> >>> So we might want to continue using it. >>> >>> Also, please be aware that there is HToolkit check in GraphicsToolkit.getHeadlessProperty() >>> >>> On Oct 22, 2013, at 1:23 PM, Artem Ananiev wrote: >>> >>>> Hi, David, >>>> >>>> thanks for additional cleanup. >>>> >>>> I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >>>> >>>> Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 10/22/2013 7:34 AM, David DeHaven wrote: >>>>> >>>>> Updated webrev for JDK (hotspot change is the same): >>>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>>>> >>>>> Changes since last version: >>>>> - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>>>> - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] >>>>> >>>>> -DrD- >>>>> >>>>> >>>>>> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >>>>>> >>>>>> -DrD- >>>>>> >>>>>>> Thanks guys. >>>>>>> >>>>>>> Anthony, can you sponsor this for me? >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>>>>> This fix looks fine to me as well. >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>>>> >>>>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>>>> >>>>>>>>> Request for review of JDK-8025673: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>>>> >>>>>>>>> Proposed changes: >>>>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>>>> >>>>>>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>>>>>> >>>>>>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>>>>>> >>>>>>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>>>>>> >>>>>>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>>>>>> >>>>>>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>>>>>> >>>>>>>>> >>>>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>>>> 461 } else { >>>>>>>>> 462 // TODO: do we still need this? >>>>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>>>> 464 } >>>>>>>>> >>>>>>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>>>>>> >>>>>>>>> >>>>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>>>>>> >>>>>>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>>>>>> >>>>>>>>> -DrD- >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> > > > -- > Best regards, Sergey. > From anthony.petrov at oracle.com Tue Oct 22 11:19:45 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Oct 2013 22:19:45 +0400 Subject: Crash on startup in SnowLeopard 1.7.0_45 In-Reply-To: References: <5266BD29.4090305@oracle.com> Message-ID: <5266C1C1.7010301@oracle.com> I assume you bundle the JDK with your application? If there's no bugs in JDK 7u25 that bother you, then you can safely keep using it. Security is not a concern with bundled JDKs because they don't run arbitrary code, but only code of your own application that users trust already anyway. So you simply don't have to upgrade the bundled JDK. And I'm sorry to state, but we don't have plans to support 10.6.8 with newer JDKs. (Though if you need to, you can always check out the OpenJDK sources, rewrite components that rely on 10.7+ APIs, and then bundle a custom build of such modified JDK with your app.) -- best regards, Anthony On 10/22/2013 10:09 PM, Steve Hannah wrote: > Thanks for the reply. Yes, I'm aware of that but: > > https://wiki.openjdk.java.net/display/MacOSXPort/Main > > Note that only Mac OS X 10.7.3 and higher will be an > Oracle-supported platform. It should continue to run on 10.6.8+ but > that is not guaranteed. As of 1-Jan-2012 there are no plans to > introduce 10.7-only APIs into the codebase. > > > I'm worried about backwards compatibility. The current version of my > app in the app store works on Snow Leopard and higher. I don't want to > issue an "upgrade" that will alienate 40% of my user base > (http://www.pcworld.com/article/2026872/windows-8-adoption-worse-than-vista-better-than-os-x-mountain-lion.html) > . > > I think we probably have a couple more years before we can just ignore > the Snow Leopard user base. > > For now I will just continue to use 1.7.0_25, but I was curious if this > was a known regression or not, and whether or not it is possible to fix > it in future versions of Java. > > Steve > > > On Tue, Oct 22, 2013 at 11:00 AM, Anthony Petrov > > wrote: > > http://www.java.com/en/__download/help/sysreq.xml > > > Mac OS X > > Intel-based Mac running Mac OS X 10.7.3 (Lion) or later. > > > So, 10.6.8 is simply unsupported. Please consider upgrading your OS. > > -- > best regards, > Anthony > > > On 10/22/2013 08:27 PM, Steve Hannah wrote: > > I have an app that is bundled using appbundler. On Lion the app > works > fine. On Snow Leopard (10.6.8) it works fine if I bundle it with > jdk1.7.0_25 (oracle), but if I bundle it with jdk1.7.0_45 > (oracle), it > crashes on startup. Crash log pasted at end of this message. > > Is this a known regression? > > Steve > > > Just before crashing, the following messages are written in Console: > > 13-10-22 9:14:08 AM JavaAppLauncher[388] *** NSInvocation: > warning: object > 0x109714390 of class 'ThreadUtilities' does not implement > methodSignatureForSelector: -- trouble ahead > > 13-10-22 9:14:08 AM JavaAppLauncher[388] *** NSInvocation: > warning: object > 0x109714390 of class 'ThreadUtilities' does not implement > doesNotRecognizeSelector: -- abort > > Crash log follows: > > Process: JavaAppLauncher [388] > Path: /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/__PDFOCRX2_Mac/dist/PDF OCR X > Community > Edition.app/Contents/MacOS/__JavaAppLauncher > Identifier: ca.weblite.PDFOCRX.__CommunityEdition > Version: 2.0.0 (2.0.0) > Code Type: X86-64 (Native) > Parent Process: launchd [104] > > Date/Time: 2013-10-22 09:14:08.935 -0700 > OS Version: Mac OS X 10.6.8 (10K549) > Report Version: 6 > > Exception Type: EXC_BREAKPOINT (SIGTRAP) > Exception Codes: 0x0000000000000002, 0x0000000000000000 > Crashed Thread: 0 > > Thread 0 Crashed: > 0 com.apple.CoreFoundation 0x00007fff861a88a1 > ___forwarding___ + 673 > 1 com.apple.CoreFoundation 0x00007fff861a4a38 > _CF_forwarding_prep_0 > + 232 > 2 libobjc.A.dylib 0x00007fff83540325 > _class_initialize + 384 > 3 libobjc.A.dylib 0x00007fff8354e52b > prepareForMethodLookup > + 234 > 4 libobjc.A.dylib 0x00007fff83546cb9 > lookUpMethod + 73 > 5 libobjc.A.dylib 0x00007fff8353efaa > objc_msgSend + 198 > 6 libosxapp.dylib 0x000000010970ea77 > -[NSApplicationAWT > registerWithProcessManager] + 124 > 7 libosxapp.dylib 0x000000010970e493 > -[NSApplicationAWT > init] + 140 > 8 com.apple.AppKit 0x00007fff802350fa > +[NSApplication > sharedApplication] + 149 > 9 liblwawt.dylib 0x000000010966394a -[AWTStarter > starter:] + 266 > 10 com.apple.Foundation 0x00007fff8676445f > __NSThreadPerformPerform + 219 > 11 com.apple.CoreFoundation 0x00007fff861733d1 > __CFRunLoopDoSources0 > + 1361 > 12 com.apple.CoreFoundation 0x00007fff861715c9 > __CFRunLoopRun + 873 > 13 com.apple.CoreFoundation 0x00007fff86170d8f > CFRunLoopRunSpecific > + 575 > 14 libjli.dylib 0x000000010003a824 > CreateExecutionEnvironment + 871 > 15 libjli.dylib 0x0000000100034fd0 JLI_Launch > + 1952 > 16 ...te.PDFOCRX.CommunityEdition 0x00000001067af804 launch + 8468 > 17 ...te.PDFOCRX.CommunityEdition 0x00000001067ad4d6 main + 102 > 18 ...te.PDFOCRX.CommunityEdition 0x00000001067ad464 start + 52 > > Thread 1: > 0 libSystem.B.dylib 0x00007fff874ebc0a kevent + 10 > 1 libSystem.B.dylib 0x00007fff874edadd > _dispatch_mgr_invoke + > 154 > 2 libSystem.B.dylib 0x00007fff874ed7b4 > _dispatch_queue_invoke > + 185 > 3 libSystem.B.dylib 0x00007fff874ed2de > _dispatch_worker_thread2 + 252 > 4 libSystem.B.dylib 0x00007fff874ecc08 > _pthread_wqthread + 353 > 5 libSystem.B.dylib 0x00007fff874ecaa5 > start_wqthread + 13 > > Thread 2: > 0 libSystem.B.dylib 0x00007fff8750da6a > __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87534896 > pthread_join + 844 > 2 libjli.dylib 0x0000000100039e24 > ContinueInNewThread0 > + 102 > 3 libjli.dylib 0x0000000100035c3b > ContinueInNewThread + > 201 > 4 libjli.dylib 0x0000000100039bf9 JVMInit + 315 > 5 libjli.dylib 0x00000001000359b9 JLI_Launch > + 4489 > 6 ...te.PDFOCRX.CommunityEdition 0x00000001067af804 launch + 8468 > 7 ...te.PDFOCRX.CommunityEdition 0x00000001067ad4d6 main + 102 > 8 libjli.dylib 0x000000010003a4b6 apple_main > + 92 > 9 libSystem.B.dylib 0x00007fff8750bfd6 > _pthread_start + 331 > 10 libSystem.B.dylib 0x00007fff8750be89 > thread_start + 13 > > Thread 3: > 0 libSystem.B.dylib 0x00007fff8750da6a > __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 > _pthread_cond_wait + > 1286 > 2 liblwawt.dylib 0x00000001096637b7 > +[AWTStarter start:] > + 598 > 3 liblwawt.dylib 0x0000000109663f42 JNI_OnLoad > + 480 > 4 libjava.dylib 0x0000000100604e76 > Java_java_lang_ClassLoader___00024NativeLibrary_load + 207 > 5 ??? 0x0000000102274738 0 + 4331095864 > 6 ??? 0x0000000102268058 0 + 4331044952 > 7 ??? 0x0000000102268350 0 + 4331045712 > 8 ??? 0x0000000102268350 0 + 4331045712 > 9 ??? 0x0000000102268058 0 + 4331044952 > 10 ??? 0x0000000102268058 0 + 4331044952 > 11 ??? 0x00000001022624e7 0 + 4331021543 > 12 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(__JavaValue*, methodHandle*, > JavaCallArguments*, > Thread*) + 554 > 13 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, > Thread*) + 40 > 14 libjvm.dylib 0x0000000101b0a304 > jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, > _jmethodID*, JNI_ArgumentPusher*, Thread*) + 230 > 15 libjvm.dylib 0x0000000101b0358b > jni_CallStaticVoidMethodV + 156 > 16 libjava.dylib 0x000000010060bcff > JNU_CallStaticMethodByName + 282 > 17 libawt.dylib 0x000000010953282c AWT_OnLoad > + 389 > 18 libawt.dylib 0x0000000109532873 JNI_OnLoad + 9 > 19 libjava.dylib 0x0000000100604e76 > Java_java_lang_ClassLoader___00024NativeLibrary_load + 207 > 20 ??? 0x0000000102274738 0 + 4331095864 > 21 ??? 0x0000000102268058 0 + 4331044952 > 22 ??? 0x0000000102268350 0 + 4331045712 > 23 ??? 0x0000000102268350 0 + 4331045712 > 24 ??? 0x0000000102268058 0 + 4331044952 > 25 ??? 0x0000000102268058 0 + 4331044952 > 26 ??? 0x0000000102268058 0 + 4331044952 > 27 ??? 0x0000000102268233 0 + 4331045427 > 28 ??? 0x00000001022624e7 0 + 4331021543 > 29 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(__JavaValue*, methodHandle*, > JavaCallArguments*, > Thread*) + 554 > 30 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, > Thread*) + 40 > 31 libjvm.dylib 0x0000000101b2a444 > JVM_DoPrivileged + > 1041 > 32 ??? 0x0000000102274738 0 + 4331095864 > 33 ??? 0x0000000102268233 0 + 4331045427 > 34 ??? 0x0000000102268058 0 + 4331044952 > 35 ??? 0x00000001022624e7 0 + 4331021543 > 36 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(__JavaValue*, methodHandle*, > JavaCallArguments*, > Thread*) + 554 > 37 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, > Thread*) + 40 > 38 libjvm.dylib 0x0000000101aac367 > instanceKlass::call_class___initializer_impl(__instanceKlassHandle, > Thread*) + > 147 > 39 libjvm.dylib 0x0000000101aad856 > instanceKlass::initialize___impl(instanceKlassHandle, Thread*) + > 1484 > 40 libjvm.dylib 0x0000000101a9fd01 > instanceKlass::initialize(__Thread*) + 85 > 41 libjvm.dylib 0x0000000101b9f5ab > LinkResolver::resolve_static___call(CallInfo&, KlassHandle&, > Symbol*, > Symbol*, KlassHandle, bool, bool, Thread*) + 173 > 42 libjvm.dylib 0x0000000101b9f691 > LinkResolver::resolve___invokestatic(CallInfo&, > constantPoolHandle, int, > Thread*) + 129 > 43 libjvm.dylib 0x0000000101ad1f22 > InterpreterRuntime::resolve___invoke(JavaThread*, > Bytecodes::Code) + 550 > 44 ??? 0x000000010227f828 0 + > 4331141160 > 45 ??? 0x00000001022624e7 0 + 4331021543 > 46 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(__JavaValue*, methodHandle*, > JavaCallArguments*, > Thread*) + 554 > 47 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, > Thread*) + 40 > 48 libjvm.dylib 0x0000000101aac367 > instanceKlass::call_class___initializer_impl(__instanceKlassHandle, > Thread*) + > 147 > 49 libjvm.dylib 0x0000000101aad856 > instanceKlass::initialize___impl(instanceKlassHandle, Thread*) + > 1484 > 50 libjvm.dylib 0x0000000101a9fd01 > instanceKlass::initialize(__Thread*) + 85 > 51 libjvm.dylib 0x0000000101b23810 > find_class_from_class_loader(__JNIEnv_*, Symbol*, unsigned char, > Handle, > Handle, unsigned char, Thread*) + 120 > 52 libjvm.dylib 0x0000000101b2bf84 > JVM_FindClassFromClassLoader + 267 > 53 libjava.dylib 0x0000000100604baf > Java_java_lang_Class_forName0 + 305 > 54 ??? 0x0000000102274738 0 + 4331095864 > 55 ??? 0x0000000102268233 0 + 4331045427 > 56 ??? 0x0000000102268233 0 + 4331045427 > 57 ??? 0x00000001022624e7 0 + 4331021543 > 58 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(__JavaValue*, methodHandle*, > JavaCallArguments*, > Thread*) + 554 > 59 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, > Thread*) + 40 > 60 libjvm.dylib 0x0000000101aac367 > instanceKlass::call_class___initializer_impl(__instanceKlassHandle, > Thread*) + > 147 > 61 libjvm.dylib 0x0000000101aad856 > instanceKlass::initialize___impl(instanceKlassHandle, Thread*) + > 1484 > 62 libjvm.dylib 0x0000000101a9fd01 > instanceKlass::initialize(__Thread*) + 85 > 63 libjvm.dylib 0x0000000101b9f5ab > LinkResolver::resolve_static___call(CallInfo&, KlassHandle&, > Symbol*, > Symbol*, KlassHandle, bool, bool, Thread*) + 173 > 64 libjvm.dylib 0x0000000101b9f691 > LinkResolver::resolve___invokestatic(CallInfo&, > constantPoolHandle, int, > Thread*) + 129 > 65 libjvm.dylib 0x0000000101ad1f22 > InterpreterRuntime::resolve___invoke(JavaThread*, > Bytecodes::Code) + 550 > 66 ??? 0x000000010227f828 0 + > 4331141160 > 67 ??? 0x0000000102268058 0 + 4331044952 > 68 ??? 0x00000001022624e7 0 + 4331021543 > 69 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(__JavaValue*, methodHandle*, > JavaCallArguments*, > Thread*) + 554 > 70 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, > Thread*) + 40 > 71 libjvm.dylib 0x0000000101aac367 > instanceKlass::call_class___initializer_impl(__instanceKlassHandle, > Thread*) + > 147 > 72 libjvm.dylib 0x0000000101aad856 > instanceKlass::initialize___impl(instanceKlassHandle, Thread*) + > 1484 > 73 libjvm.dylib 0x0000000101a9fd01 > instanceKlass::initialize(__Thread*) + 85 > 74 libjvm.dylib 0x0000000101b9f5ab > LinkResolver::resolve_static___call(CallInfo&, KlassHandle&, > Symbol*, > Symbol*, KlassHandle, bool, bool, Thread*) + 173 > 75 libjvm.dylib 0x0000000101b9f691 > LinkResolver::resolve___invokestatic(CallInfo&, > constantPoolHandle, int, > Thread*) + 129 > 76 libjvm.dylib 0x0000000101ad1f22 > InterpreterRuntime::resolve___invoke(JavaThread*, > Bytecodes::Code) + 550 > 77 ??? 0x000000010227f81a 0 + > 4331141146 > 78 ??? 0x00000001022624e7 0 + 4331021543 > 79 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(__JavaValue*, methodHandle*, > JavaCallArguments*, > Thread*) + 554 > 80 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, > Thread*) + 40 > 81 libjvm.dylib 0x0000000101aac367 > instanceKlass::call_class___initializer_impl(__instanceKlassHandle, > Thread*) + > 147 > 82 libjvm.dylib 0x0000000101aad856 > instanceKlass::initialize___impl(instanceKlassHandle, Thread*) + > 1484 > 83 libjvm.dylib 0x0000000101a9fd01 > instanceKlass::initialize(__Thread*) + 85 > 84 libjvm.dylib 0x0000000101ad2fad > InterpreterRuntime::_new(__JavaThread*, constantPoolOopDesc*, > int) + 161 > 85 ??? 0x00000001022801a5 0 + > 4331143589 > 86 ??? 0x0000000102268058 0 + 4331044952 > 87 ??? 0x00000001022624e7 0 + 4331021543 > 88 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(__JavaValue*, methodHandle*, > JavaCallArguments*, > Thread*) + 554 > 89 libjvm.dylib 0x0000000101ad6b60 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, > Thread*) + 40 > 90 libjvm.dylib 0x0000000101b0a304 > jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, > _jmethodID*, JNI_ArgumentPusher*, Thread*) + 230 > 91 libjvm.dylib 0x0000000101b0349f > jni_CallStaticVoidMethod + 267 > 92 libjli.dylib 0x0000000100036572 JavaMain + > 2333 > 93 libSystem.B.dylib 0x00007fff8750bfd6 > _pthread_start + 331 > 94 libSystem.B.dylib 0x00007fff8750be89 > thread_start + 13 > > Thread 4: > 0 libSystem.B.dylib 0x00007fff8750da6a > __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 > _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101bf70be > ParkCommon(ParkEvent*, long long) + 42 > 4 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 5 libjvm.dylib 0x0000000101bf7b0d > Monitor::wait(bool, > long, bool) + 375 > 6 libjvm.dylib 0x0000000101a68e6e > GCTaskManager::get_task(__unsigned int) + 56 > 7 libjvm.dylib 0x0000000101a69d63 > GCTaskThread::run() + > 349 > 8 libjvm.dylib 0x0000000101c1b1c6 > java_start(Thread*) + > 294 > 9 libSystem.B.dylib 0x00007fff8750bfd6 > _pthread_start + 331 > 10 libSystem.B.dylib 0x00007fff8750be89 > thread_start + 13 > > Thread 5: > 0 libSystem.B.dylib 0x00007fff8750da6a > __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 > _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101bf70be > ParkCommon(ParkEvent*, long long) + 42 > 4 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 5 libjvm.dylib 0x0000000101bf7b0d > Monitor::wait(bool, > long, bool) + 375 > 6 libjvm.dylib 0x0000000101a68e6e > GCTaskManager::get_task(__unsigned int) + 56 > 7 libjvm.dylib 0x0000000101a69d63 > GCTaskThread::run() + > 349 > 8 libjvm.dylib 0x0000000101c1b1c6 > java_start(Thread*) + > 294 > 9 libSystem.B.dylib 0x00007fff8750bfd6 > _pthread_start + 331 > 10 libSystem.B.dylib 0x00007fff8750be89 > thread_start + 13 > > Thread 6: > 0 libSystem.B.dylib 0x00007fff8750da6a > __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 > _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c17ddb > os::PlatformEvent::park(long long) + 385 > 3 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 4 libjvm.dylib 0x0000000101bf7b0d > Monitor::wait(bool, > long, bool) + 375 > 5 libjvm.dylib 0x0000000101d2a8b0 > VMThread::loop() + 444 > 6 libjvm.dylib 0x0000000101d2a35b > VMThread::run() + 121 > 7 libjvm.dylib 0x0000000101c1b1c6 > java_start(Thread*) + > 294 > 8 libSystem.B.dylib 0x00007fff8750bfd6 > _pthread_start + 331 > 9 libSystem.B.dylib 0x00007fff8750be89 > thread_start + 13 > > Thread 7: Java: Reference Handler > 0 libSystem.B.dylib 0x00007fff8750da6a > __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 > _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101c0fe57 > ObjectMonitor::wait(long long, bool, Thread*) + 757 > 4 libjvm.dylib 0x0000000101cbf4a3 > ObjectSynchronizer::wait(__Handle, long long, Thread*) + 203 > 5 libjvm.dylib 0x0000000101b2b0fc > JVM_MonitorWait + 156 > 6 ??? 0x0000000102274738 0 + 4331095864 > 7 ??? 0x0000000102268058 0 + 4331044952 > 8 ??? 0x0000000102268058 0 + 4331044952 > 9 ??? 0x00000001022624e7 0 + 4331021543 > 10 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(__JavaValue*, methodHandle*, > JavaCallArguments*, > Thread*) + 554 > 11 libjvm.dylib 0x0000000101ad72a7 > JavaCalls::call_virtual(__JavaValue*, KlassHandle, Symbol*, Symbol*, > JavaCallArguments*, Thread*) + 283 > 12 libjvm.dylib 0x0000000101ad73e4 > JavaCalls::call_virtual(__JavaValue*, Handle, KlassHandle, > Symbol*, Symbol*, > Thread*) + 74 > 13 libjvm.dylib 0x0000000101b263ca > thread_entry(JavaThread*, Thread*) + 173 > 14 libjvm.dylib 0x0000000101cefb47 > JavaThread::thread_main_inner(__) + 155 > 15 libjvm.dylib 0x0000000101cf124f > JavaThread::run() + > 419 > 16 libjvm.dylib 0x0000000101c1b1c6 > java_start(Thread*) + > 294 > 17 libSystem.B.dylib 0x00007fff8750bfd6 > _pthread_start + 331 > 18 libSystem.B.dylib 0x00007fff8750be89 > thread_start + 13 > > Thread 8: Java: Finalizer > 0 libSystem.B.dylib 0x00007fff8750da6a > __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 > _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101c0fe57 > ObjectMonitor::wait(long long, bool, Thread*) + 757 > 4 libjvm.dylib 0x0000000101cbf4a3 > ObjectSynchronizer::wait(__Handle, long long, Thread*) + 203 > 5 libjvm.dylib 0x0000000101b2b0fc > JVM_MonitorWait + 156 > 6 ??? 0x0000000102274738 0 + 4331095864 > 7 ??? 0x0000000102268058 0 + 4331044952 > 8 ??? 0x0000000102268233 0 + 4331045427 > 9 ??? 0x0000000102268233 0 + 4331045427 > 10 ??? 0x00000001022624e7 0 + 4331021543 > 11 libjvm.dylib 0x0000000101ad6d90 > JavaCalls::call_helper(__JavaValue*, methodHandle*, > JavaCallArguments*, > Thread*) + 554 > 12 libjvm.dylib 0x0000000101ad72a7 > JavaCalls::call_virtual(__JavaValue*, KlassHandle, Symbol*, Symbol*, > JavaCallArguments*, Thread*) + 283 > 13 libjvm.dylib 0x0000000101ad73e4 > JavaCalls::call_virtual(__JavaValue*, Handle, KlassHandle, > Symbol*, Symbol*, > Thread*) + 74 > 14 libjvm.dylib 0x0000000101b263ca > thread_entry(JavaThread*, Thread*) + 173 > 15 libjvm.dylib 0x0000000101cefb47 > JavaThread::thread_main_inner(__) + 155 > 16 libjvm.dylib 0x0000000101cf124f > JavaThread::run() + > 419 > 17 libjvm.dylib 0x0000000101c1b1c6 > java_start(Thread*) + > 294 > 18 libSystem.B.dylib 0x00007fff8750bfd6 > _pthread_start + 331 > 19 libSystem.B.dylib 0x00007fff8750be89 > thread_start + 13 > > Thread 9: > 0 libSystem.B.dylib 0x00007fff874eca2a > __workq_kernreturn + 10 > 1 libSystem.B.dylib 0x00007fff874ece3c > _pthread_wqthread + 917 > 2 libSystem.B.dylib 0x00007fff874ecaa5 > start_wqthread + 13 > > Thread 10: Java: Signal Dispatcher > 0 libSystem.B.dylib 0x00007fff874d2db6 > semaphore_wait_trap + > 10 > 1 libjvm.dylib 0x0000000101c194a0 > check_pending_signals(bool) + 128 > 2 libjvm.dylib 0x0000000101c15da8 > signal_thread_entry(__JavaThread*, Thread*) + 57 > 3 libjvm.dylib 0x0000000101cefb47 > JavaThread::thread_main_inner(__) + 155 > 4 libjvm.dylib 0x0000000101cf124f > JavaThread::run() + > 419 > 5 libjvm.dylib 0x0000000101c1b1c6 > java_start(Thread*) + > 294 > 6 libSystem.B.dylib 0x00007fff8750bfd6 > _pthread_start + 331 > 7 libSystem.B.dylib 0x00007fff8750be89 > thread_start + 13 > > Thread 11: Java: C2 CompilerThread0 > 0 libSystem.B.dylib 0x00007fff8750da6a > __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 > _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101bf70be > ParkCommon(ParkEvent*, long long) + 42 > 4 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 5 libjvm.dylib 0x0000000101bf7a74 > Monitor::wait(bool, > long, bool) + 222 > 6 libjvm.dylib 0x00000001019c10ab > CompileQueue::get() + > 153 > 7 libjvm.dylib 0x00000001019c1c43 > CompileBroker::compiler___thread_loop() + 425 > 8 libjvm.dylib 0x0000000101cefb47 > JavaThread::thread_main_inner(__) + 155 > 9 libjvm.dylib 0x0000000101cf124f > JavaThread::run() + > 419 > 10 libjvm.dylib 0x0000000101c1b1c6 > java_start(Thread*) + > 294 > 11 libSystem.B.dylib 0x00007fff8750bfd6 > _pthread_start + 331 > 12 libSystem.B.dylib 0x00007fff8750be89 > thread_start + 13 > > Thread 12: Java: C2 CompilerThread1 > 0 libSystem.B.dylib 0x00007fff8750da6a > __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 > _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101bf70be > ParkCommon(ParkEvent*, long long) + 42 > 4 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 5 libjvm.dylib 0x0000000101bf7a74 > Monitor::wait(bool, > long, bool) + 222 > 6 libjvm.dylib 0x00000001019c10ab > CompileQueue::get() + > 153 > 7 libjvm.dylib 0x00000001019c1c43 > CompileBroker::compiler___thread_loop() + 425 > 8 libjvm.dylib 0x0000000101cefb47 > JavaThread::thread_main_inner(__) + 155 > 9 libjvm.dylib 0x0000000101cf124f > JavaThread::run() + > 419 > 10 libjvm.dylib 0x0000000101c1b1c6 > java_start(Thread*) + > 294 > 11 libSystem.B.dylib 0x00007fff8750bfd6 > _pthread_start + 331 > 12 libSystem.B.dylib 0x00007fff8750be89 > thread_start + 13 > > Thread 13: Java: Service Thread > 0 libSystem.B.dylib 0x00007fff8750da6a > __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 > _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c16e29 > os::PlatformEvent::park() + 173 > 3 libjvm.dylib 0x0000000101bf70be > ParkCommon(ParkEvent*, long long) + 42 > 4 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 5 libjvm.dylib 0x0000000101bf7b0d > Monitor::wait(bool, > long, bool) + 375 > 6 libjvm.dylib 0x0000000101c6f1d5 > ServiceThread::service_thread___entry(JavaThread*, Thread*) + 109 > 7 libjvm.dylib 0x0000000101cefb47 > JavaThread::thread_main_inner(__) + 155 > 8 libjvm.dylib 0x0000000101cf124f > JavaThread::run() + > 419 > 9 libjvm.dylib 0x0000000101c1b1c6 > java_start(Thread*) + > 294 > 10 libSystem.B.dylib 0x00007fff8750bfd6 > _pthread_start + 331 > 11 libSystem.B.dylib 0x00007fff8750be89 > thread_start + 13 > > Thread 14: > 0 libSystem.B.dylib 0x00007fff8750da6a > __semwait_signal + 10 > 1 libSystem.B.dylib 0x00007fff87511881 > _pthread_cond_wait + > 1286 > 2 libjvm.dylib 0x0000000101c17ddb > os::PlatformEvent::park(long long) + 385 > 3 libjvm.dylib 0x0000000101bf78b0 > Monitor::IWait(Thread*, long long) + 160 > 4 libjvm.dylib 0x0000000101bf7b0d > Monitor::wait(bool, > long, bool) + 375 > 5 libjvm.dylib 0x0000000101cf001a > WatcherThread::sleep() const + 126 > 6 libjvm.dylib 0x0000000101cf0edd > WatcherThread::run() > + 243 > 7 libjvm.dylib 0x0000000101c1b1c6 > java_start(Thread*) + > 294 > 8 libSystem.B.dylib 0x00007fff8750bfd6 > _pthread_start + 331 > 9 libSystem.B.dylib 0x00007fff8750be89 > thread_start + 13 > > Thread 0 crashed with X86 Thread State (64-bit): > rax: 0x0000000000000000 rbx: 0x00007fff809c8734 rcx: > 0x0000000000000000 > rdx: 0x00007fff70e7acc0 > rdi: 0x000000000000003b rsi: 0x0000000000000001 rbp: > 0x00007fff5fbfc740 > rsp: 0x00007fff5fbfc6f0 > r8: 0x0000000000000001 r9: 0x00000001003266c0 r10: > 0x0000000000000001 > r11: 0x000000000000003f > r12: 0x0000000000000000 r13: 0x0000000109714390 r14: > 0x00000001097143b8 > r15: 0x0000000109714390 > rip: 0x00007fff861a88a1 rfl: 0x0000000000000287 cr2: > 0x0000000108cff000 > > Binary Images: > 0x100033000 - 0x10003dfff +libjli.dylib ??? (???) > <32A3CEF6-9D91-3B97-9F17-__CAD9301081D1> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/__PDFOCRX2_Mac/dist/PDF OCR X > Community > Edition.app/Contents/PlugIns/__jdk1.7.0_45.jdk/Contents/Home/__jre/lib/jli/libjli.dylib > 0x1000ec000 - 0x1000f4fff +libverify.dylib ??? (???) > /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/__PDFOCRX2_Mac/dist/PDF OCR X > Community > Edition.app/Contents/PlugIns/__jdk1.7.0_45.jdk/Contents/Home/__jre/lib/libverify.dylib > 0x1002e2000 - 0x1002e7fff +libzip.dylib ??? (???) > <50D7966F-6590-3F9A-A42B-__7E7EE016493E> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/__PDFOCRX2_Mac/dist/PDF OCR X > Community > Edition.app/Contents/PlugIns/__jdk1.7.0_45.jdk/Contents/Home/__jre/lib/libzip.dylib > 0x1002ee000 - 0x1002f3ff7 com.apple.JavaVM > 13.9.8 (13.9.8) > > /System/Library/Frameworks/__JavaVM.framework/Versions/A/__JavaVM > 0x100603000 - 0x100624fe7 +libjava.dylib ??? (???) > <64871BED-E504-307F-BCEE-__EA4CCEA588EA> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/__PDFOCRX2_Mac/dist/PDF OCR X > Community > Edition.app/Contents/PlugIns/__jdk1.7.0_45.jdk/Contents/Home/__jre/lib/libjava.dylib > 0x101800000 - 0x101f45fef +libjvm.dylib ??? (???) > <7CBD0F39-332A-3790-B0FF-__F5F955C325A6> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/__PDFOCRX2_Mac/dist/PDF OCR X > Community > Edition.app/Contents/PlugIns/__jdk1.7.0_45.jdk/Contents/Home/__jre/lib/server/libjvm.dylib > 0x1066c6000 - 0x1066d1fef > com.apple.java.__JavaRuntimeSupport > 13.9.8 (13.9.8) <78E0442F-7DF4-5DAA-2DF1-__1570AE1AAEC8> > /System/Library/Frameworks/__JavaVM.framework/Frameworks/__JavaRuntimeSupport.framework/__JavaRuntimeSupport > 0x1066e2000 - 0x1066edfff JavaNativeFoundation > ??? (???) > <81035866-C9A3-6ADC-920F-__A2C02D6DB95B> > /System/Library/Frameworks/__JavaVM.framework/Versions/A/__Frameworks/__JavaNativeFoundation.__framework/Versions/A/__JavaNativeFoundation > 0x1066f8000 - 0x1066feff7 JavaLaunching ??? (???) > <8A4FFBEC-90DB-3EB1-68E7-__4EF8A0F47F52> > /System/Library/__PrivateFrameworks/__JavaLaunching.framework/__Versions/A/JavaLaunching > 0x1067ac000 - 0x1067affff > +ca.weblite.PDFOCRX.__CommunityEdition 2.0.0 (2.0.0) > <085DD0B7-34B2-3A2D-BFC7-__4CA094FC70DE> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/__PDFOCRX2_Mac/dist/PDF OCR X > Community > Edition.app/Contents/MacOS/__JavaAppLauncher > 0x1094d4000 - 0x10953ffff +libawt.dylib ??? (???) > <5F027771-D669-392F-8DD7-__CBA3EA5DD87D> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/__PDFOCRX2_Mac/dist/PDF OCR X > Community > Edition.app/Contents/PlugIns/__jdk1.7.0_45.jdk/Contents/Home/__jre/lib/libawt.dylib > 0x109586000 - 0x10964bfff +libmlib_image.dylib > ??? (???) > <95F6D0B2-3A92-305F-A6AE-__822BC990901B> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/__PDFOCRX2_Mac/dist/PDF OCR X > Community > Edition.app/Contents/PlugIns/__jdk1.7.0_45.jdk/Contents/Home/__jre/lib/libmlib_image.dylib > 0x109656000 - 0x1096c6fff +liblwawt.dylib ??? (???) > <9875DBAB-B5B6-322C-A085-__4651CEDFCBF4> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/__PDFOCRX2_Mac/dist/PDF OCR X > Community > Edition.app/Contents/PlugIns/__jdk1.7.0_45.jdk/Contents/Home/__jre/lib/lwawt/liblwawt.dylib > 0x10970d000 - 0x109712fff +libosxapp.dylib ??? (???) > <8CE761D7-7DAA-36BA-8424-__BF74590F8C1D> /Volumes/Windows > VMS/NetbeansProjects/PDFOCRX2/__PDFOCRX2_Mac/dist/PDF OCR X > Community > Edition.app/Contents/PlugIns/__jdk1.7.0_45.jdk/Contents/Home/__jre/lib/libosxapp.dylib > 0x7fff5fc00000 - 0x7fff5fc3be0f dyld 132.1 (???) > <29DECB19-0193-2575-D838-__CF743F0400B2> /usr/lib/dyld > 0x7fff80003000 - 0x7fff80093fff com.apple.SearchKit > 1.3.0 (1.3.0) > <4175DC31-1506-228A-08FD-__C704AC9DF642> > /System/Library/Frameworks/__CoreServices.framework/__Versions/A/Frameworks/__SearchKit.framework/Versions/__A/SearchKit > 0x7fff80094000 - 0x7fff80171fff com.apple.vImage 4.1 > (4.1) > > /System/Library/Frameworks/__Accelerate.framework/Versions/__A/Frameworks/vImage.framework/__Versions/A/vImage > 0x7fff80172000 - 0x7fff801f7ff7 > com.apple.print.framework.__PrintCore 6.3 (312.7) > > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/__PrintCore.framework/Versions/__A/PrintCore > 0x7fff801f8000 - 0x7fff8020ffff > com.apple.ImageCapture 6.1 (6.1) > <79AB2131-2A6C-F351-38A9-__ED58B25534FD> > /System/Library/Frameworks/__Carbon.framework/Versions/A/__Frameworks/ImageCapture.__framework/Versions/A/__ImageCapture > 0x7fff80222000 - 0x7fff80231fff com.apple.NetFS 3.2.2 > (3.2.2) > <7CCBD70E-BF31-A7A7-DB98-__230687773145> > /System/Library/Frameworks/__NetFS.framework/Versions/A/__NetFS > 0x7fff80232000 - 0x7fff80c2cff7 com.apple.AppKit > 6.6.8 (1038.36) > <4CFBE04C-8FB3-B0EA-8DDB-__7E7D10E9D251> > /System/Library/Frameworks/__AppKit.framework/Versions/C/__AppKit > 0x7fff80c2d000 - 0x7fff80c34fff > com.apple.OpenDirectory 10.6 > (10.6) <4FF6AD25-0916-B21C-9E88-__2CC42D90EAC7> > /System/Library/Frameworks/__OpenDirectory.framework/__Versions/A/OpenDirectory > 0x7fff80c35000 - 0x7fff80cf2fff > com.apple.CoreServices.__OSServices > 359.2 (359.2) > /System/Library/Frameworks/__CoreServices.framework/__Versions/A/Frameworks/__OSServices.framework/Versions/__A/OSServices > 0x7fff80d25000 - 0x7fff80d4aff7 com.apple.CoreVideo > 1.6.2 (45.6) > > /System/Library/Frameworks/__CoreVideo.framework/Versions/__A/CoreVideo > 0x7fff80d70000 - 0x7fff80db1fff > com.apple.SystemConfiguration > 1.10.8 (1.10.2) <78D48D27-A9C4-62CA-2803-__D0BBED82855A> > /System/Library/Frameworks/__SystemConfiguration.framework/__Versions/A/SystemConfiguration > 0x7fff810ad000 - 0x7fff81162fe7 > com.apple.ink.framework 1.3.3 > (107) <8C36373C-5473-3A6A-4972-__BC29D504250F> > /System/Library/Frameworks/__Carbon.framework/Versions/A/__Frameworks/Ink.framework/__Versions/A/Ink > 0x7fff8116f000 - 0x7fff811d9fe7 libvMisc.dylib 268.0.1 > (compatibility 1.0.0) > /System/Library/Frameworks/__Accelerate.framework/Versions/__A/Frameworks/vecLib.framework/__Versions/A/libvMisc.dylib > 0x7fff81464000 - 0x7fff81504fff > com.apple.LaunchServices 362.3 > (362.3) > /System/Library/Frameworks/__CoreServices.framework/__Versions/A/Frameworks/__LaunchServices.framework/__Versions/A/LaunchServices > 0x7fff81505000 - 0x7fff81551fff libauto.dylib ??? (???) > /usr/lib/libauto.dylib > 0x7fff81552000 - 0x7fff81583fff libGLImage.dylib ??? > (???) > <562565E1-AA65-FE96-13FF-__437410C886D0> > /System/Library/Frameworks/__OpenGL.framework/Versions/A/__Libraries/libGLImage.dylib > 0x7fff81584000 - 0x7fff81584ff7 com.apple.Cocoa 6.6 (???) > <68B0BE46-6E24-C96F-B341-__054CF9E8F3B6> > /System/Library/Frameworks/__Cocoa.framework/Versions/A/__Cocoa > 0x7fff81be0000 - 0x7fff81cb4fe7 com.apple.CFNetwork > 454.12.4 > (454.12.4) > /System/Library/Frameworks/__CoreServices.framework/__Versions/A/Frameworks/__CFNetwork.framework/Versions/__A/CFNetwork > 0x7fff81e7a000 - 0x7fff82576ff7 > com.apple.CoreGraphics 1.545.0 > (???) <58D597B1-EB3B-710E-0B8C-__EC114D54E11B> > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/__CoreGraphics.framework/__Versions/A/CoreGraphics > 0x7fff82605000 - 0x7fff82628fff com.apple.opencl > 12.3.6 (12.3.6) > <42FA5783-EB80-1168-4015-__B8C68F55842F> > /System/Library/Frameworks/__OpenCL.framework/Versions/A/__OpenCL > 0x7fff82629000 - 0x7fff826a6fef libstdc++.6.dylib 7.9.0 > (compatibility 7.0.0) <35ECA411-2C08-FD7D-11B1-__1B7A04921A5C> > /usr/lib/libstdc++.6.dylib > 0x7fff82a14000 - 0x7fff82a17ff7 libCoreVMClient.dylib > ??? (???) > <75819794-3B7A-8944-D004-__7EA6DD7CE836> > /System/Library/Frameworks/__OpenGL.framework/Versions/A/__Libraries/libCoreVMClient.__dylib > 0x7fff82a18000 - 0x7fff82a5fff7 com.apple.coreui 2 (114) > <923E33CC-83FC-7D35-5603-__FB8F348EE34B> > /System/Library/__PrivateFrameworks/CoreUI.__framework/Versions/A/CoreUI > 0x7fff82a9e000 - 0x7fff82af4fe7 libTIFF.dylib ??? (???) > <2DBEC120-DAA7-3789-36A2-__A205BCDF2D72> > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/ImageIO.__framework/Versions/A/__Resources/libTIFF.dylib > 0x7fff83344000 - 0x7fff83359ff7 > com.apple.LangAnalysis 1.6.6 > (1.6.6) <1AE1FE8F-2204-4410-C94E-__0E93B003BEDA> > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/__LangAnalysis.framework/__Versions/A/LangAnalysis > 0x7fff8335a000 - 0x7fff8335ffff libGIF.dylib ??? (???) > <3BAD0DE8-8151-68B0-2244-__A4541C738972> > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/ImageIO.__framework/Versions/A/__Resources/libGIF.dylib > 0x7fff83360000 - 0x7fff83361fff liblangid.dylib ??? (???) > /usr/lib/liblangid.dylib > 0x7fff83362000 - 0x7fff833a3fef com.apple.QD 3.36 (???) > <5DC41E81-32C9-65B2-5528-__B33E934D5BB4> > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/QD.__framework/Versions/A/QD > 0x7fff833a4000 - 0x7fff833a6fff libRadiance.dylib ??? > (???) > > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/ImageIO.__framework/Versions/A/__Resources/libRadiance.dylib > 0x7fff833a7000 - 0x7fff83419fef > com.apple.CoreSymbolication 2.0 > (23) <06F8561E-4B36-7BF6-31BA-__64091B3D8058> > /System/Library/__PrivateFrameworks/__CoreSymbolication.framework/__Versions/A/CoreSymbolication > 0x7fff834a4000 - 0x7fff83530fef SecurityFoundation > ??? (???) > <3F1F2727-C508-3630-E2C1-__38361841FCE4> > /System/Library/Frameworks/__SecurityFoundation.framework/__Versions/A/SecurityFoundation > 0x7fff8353a000 - 0x7fff835f0ff7 libobjc.A.dylib 227.0.0 > (compatibility 1.0.0) <03140531-3B2D-1EBA-DA7F-__E12CC8F63969> > /usr/lib/libobjc.A.dylib > 0x7fff837b2000 - 0x7fff837edfff com.apple.AE > 496.5 (496.5) > <208DF391-4DE6-81ED-C697-__14A2930D1BC6> > /System/Library/Frameworks/__CoreServices.framework/__Versions/A/Frameworks/AE.__framework/Versions/A/AE > 0x7fff837f8000 - 0x7fff839b6fff libicucore.A.dylib 40.0.0 > (compatibility 1.0.0) <97A75BFB-0DB6-6F44-36B0-__97B7F7208ABB> > /usr/lib/libicucore.A.dylib > 0x7fff839b7000 - 0x7fff839bbff7 libmathCommon.A.dylib > 315.0.0 > (compatibility 1.0.0) <95718673-FEEE-B6ED-B127-__BCDBDB60D4E5> > /usr/lib/system/libmathCommon.__A.dylib > 0x7fff839bc000 - 0x7fff839e3ff7 libJPEG.dylib ??? (???) > <08758593-6436-B29E-1DA8-__F15597835EC1> > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/ImageIO.__framework/Versions/A/__Resources/libJPEG.dylib > 0x7fff83add000 - 0x7fff83ae8ff7 > com.apple.speech.recognition.__framework 3.11.1 (3.11.1) > <3D65E89B-FFC6-4AAF-D5CC-__104F967C8131> > /System/Library/Frameworks/__Carbon.framework/Versions/A/__Frameworks/SpeechRecognition.__framework/Versions/A/__SpeechRecognition > 0x7fff83c02000 - 0x7fff83c40fef > com.apple.DebugSymbols 1.1 (70) > > /System/Library/__PrivateFrameworks/__DebugSymbols.framework/__Versions/A/DebugSymbols > 0x7fff83d01000 - 0x7fff83d01ff7 > com.apple.CoreServices 44 (44) > > /System/Library/Frameworks/__CoreServices.framework/__Versions/A/CoreServices > 0x7fff84046000 - 0x7fff8404cff7 IOSurface ??? (???) > <8E302BB2-0704-C6AB-BD2F-__C2A6C6A2E2C3> > /System/Library/Frameworks/__IOSurface.framework/Versions/__A/IOSurface > 0x7fff8404d000 - 0x7fff84095ff7 libvDSP.dylib 268.0.1 > (compatibility 1.0.0) <98FC4457-F405-0262-00F7-__56119CA107B6> > /System/Library/Frameworks/__Accelerate.framework/Versions/__A/Frameworks/vecLib.framework/__Versions/A/libvDSP.dylib > 0x7fff845e4000 - 0x7fff8460cfff > com.apple.DictionaryServices 1.1.2 > (1.1.2) > /System/Library/Frameworks/__CoreServices.framework/__Versions/A/Frameworks/__DictionaryServices.framework/__Versions/A/DictionaryServices > 0x7fff84615000 - 0x7fff847d4fff > com.apple.ImageIO.framework 3.0.6 > (3.0.6) <92882FD3-CB3F-D0BE-DDDA-__43B4BEE10F58> > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/ImageIO.__framework/Versions/A/ImageIO > 0x7fff847d5000 - 0x7fff84b72fe7 com.apple.QuartzCore > 1.6.3 > (227.37) <16DFF6CD-EA58-CE62-A1D7-__5F6CE3D066DD> > /System/Library/Frameworks/__QuartzCore.framework/Versions/__A/QuartzCore > 0x7fff84b73000 - 0x7fff84b81ff7 libkxld.dylib ??? (???) > <8145A534-95CC-9F3C-B78B-__AC9898F38C6F> > /usr/lib/system/libkxld.dylib > 0x7fff84ca0000 - 0x7fff84ce9fef libGLU.dylib ??? (???) > > /System/Library/Frameworks/__OpenGL.framework/Versions/A/__Libraries/libGLU.dylib > 0x7fff84d2c000 - 0x7fff84d4dfff libresolv.9.dylib 41.1.0 > (compatibility 1.0.0) <9410EC7F-4D24-6740-AFEE-__90405750FAD7> > /usr/lib/libresolv.9.dylib > 0x7fff84d4e000 - 0x7fff84e64ff7 libxml2.2.dylib 10.3.0 > (compatibility 10.0.0) <3814FCF9-92B9-A6AB-E76A-__F7021894AA3F> > /usr/lib/libxml2.2.dylib > 0x7fff84ef7000 - 0x7fff85016ff7 libcrypto.0.9.8.dylib > 0.9.8 > (compatibility 0.9.8) <0CE8D59B-D0C7-1DCE-3654-__37F27F61BEFA> > /usr/lib/libcrypto.0.9.8.dylib > 0x7fff85017000 - 0x7fff85017ff7 > com.apple.ApplicationServices 38 > (38) <10A0B9E9-4988-03D4-FC56-__DDE231A02C63> > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/ApplicationServices > 0x7fff8547c000 - 0x7fff85596fff > libGLProgrammability.dylib ??? > (???) > /System/Library/Frameworks/__OpenGL.framework/Versions/A/__Libraries/__libGLProgrammability.dylib > 0x7fff856df000 - 0x7fff856dfff7 com.apple.Carbon 150 > (152) > <23704665-E9F4-6B43-1115-__2E69F161FC45> > /System/Library/Frameworks/__Carbon.framework/Versions/A/__Carbon > 0x7fff85720000 - 0x7fff85726ff7 > com.apple.CommerceCore 1.0 (9.1) > <3691E9BA-BCF4-98C7-EFEC-__78DA6825004E> > /System/Library/__PrivateFrameworks/CommerceKit.__framework/Versions/A/__Frameworks/CommerceCore.__framework/Versions/A/__CommerceCore > 0x7fff857dd000 - 0x7fff858c2fef > com.apple.DesktopServices 1.5.11 > (1.5.11) <39FAA3D2-6863-B5AB-AED9-__92D878EA2438> > /System/Library/__PrivateFrameworks/__DesktopServicesPriv.framework/__Versions/A/DesktopServicesPriv > 0x7fff858c3000 - 0x7fff858eeff7 libxslt.1.dylib 3.24.0 > (compatibility 3.0.0) <3630A97F-55C1-3F34-CA63-__3847653C9645> > /usr/lib/libxslt.1.dylib > 0x7fff8596b000 - 0x7fff85a2dfe7 libFontParser.dylib > ??? (???) > > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/ATS.__framework/Versions/A/__Resources/libFontParser.dylib > 0x7fff85caa000 - 0x7fff85cbefff libGL.dylib ??? (???) > <2ECE3B0F-39E1-3938-BF27-__7205C6D0358B> > /System/Library/Frameworks/__OpenGL.framework/Versions/A/__Libraries/libGL.dylib > 0x7fff85f15000 - 0x7fff85f29ff7 > com.apple.speech.synthesis.__framework 3.10.35 (3.10.35) > <621B7415-A0B9-07A7-F313-__36BEEDD7B132> > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/__SpeechSynthesis.framework/__Versions/A/SpeechSynthesis > 0x7fff86125000 - 0x7fff8629cfe7 > com.apple.CoreFoundation 6.6.6 > (550.44) > /System/Library/Frameworks/__CoreFoundation.framework/__Versions/A/CoreFoundation > 0x7fff863a6000 - 0x7fff863b5fef com.apple.opengl > 1.6.14 (1.6.14) > > /System/Library/Frameworks/__OpenGL.framework/Versions/A/__OpenGL > 0x7fff863b6000 - 0x7fff86477fef com.apple.ColorSync > 4.6.8 (4.6.8) > <7DF1D175-6451-51A2-DBBF-__40FCA78C0D2C> > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/__ColorSync.framework/Versions/__A/ColorSync > 0x7fff86478000 - 0x7fff86512fff > com.apple.ApplicationServices.__ATS > 275.19 (???) <2DE8987F-4563-4D8E-45C3-__2F6F786E120D> > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/ATS.__framework/Versions/A/ATS > 0x7fff86513000 - 0x7fff86648fff > com.apple.audio.toolbox.__AudioToolbox 1.6.7 (1.6.7) > > /System/Library/Frameworks/__AudioToolbox.framework/__Versions/A/AudioToolbox > 0x7fff86716000 - 0x7fff86716ff7 > com.apple.Accelerate.vecLib 3.6 > (vecLib 3.6) <4CCE5D69-F1B3-8FD3-1483-__E0271DB2CCF3> > /System/Library/Frameworks/__Accelerate.framework/Versions/__A/Frameworks/vecLib.framework/__Versions/A/vecLib > 0x7fff86717000 - 0x7fff8672dfe7 > com.apple.MultitouchSupport.__framework 207.11 (207.11) > <8233CE71-6F8D-8B3C-A0E1-__E123F6406163> > /System/Library/__PrivateFrameworks/__MultitouchSupport.framework/__Versions/A/MultitouchSupport > 0x7fff8673c000 - 0x7fff869befff com.apple.Foundation > 6.6.8 > (751.63) > /System/Library/Frameworks/__Foundation.framework/Versions/__C/Foundation > 0x7fff869bf000 - 0x7fff869c0ff7 > com.apple.TrustEvaluationAgent 1.1 > (1) <5952A9FA-BC2B-16EF-91A7-__43902A5C07B6> > /System/Library/__PrivateFrameworks/__TrustEvaluationAgent.__framework/Versions/A/__TrustEvaluationAgent > 0x7fff869c1000 - 0x7fff86cbffff com.apple.HIToolbox > 1.6.5 (???) > > /System/Library/Frameworks/__Carbon.framework/Versions/A/__Frameworks/HIToolbox.__framework/Versions/A/HIToolbox > 0x7fff86cc0000 - 0x7fff86cc3fff com.apple.help 1.3.2 > (41.1) > > /System/Library/Frameworks/__Carbon.framework/Versions/A/__Frameworks/Help.framework/__Versions/A/Help > 0x7fff86d04000 - 0x7fff86d09ff7 > com.apple.CommonPanels 1.2.4 (91) > <4D84803B-BD06-D80E-15AE-__EFBE43F93605> > /System/Library/Frameworks/__Carbon.framework/Versions/A/__Frameworks/CommonPanels.__framework/Versions/A/__CommonPanels > 0x7fff86d3b000 - 0x7fff8706ffef > com.apple.CoreServices.__CarbonCore > 861.39 (861.39) <1386A24D-DD15-5903-057E-__4A224FAF580B> > /System/Library/Frameworks/__CoreServices.framework/__Versions/A/Frameworks/__CarbonCore.framework/Versions/__A/CarbonCore > 0x7fff87070000 - 0x7fff871aefff com.apple.CoreData > 102.1 (251) > <9DFE798D-AA52-6A9A-924A-__DA73CB94D81A> > /System/Library/Frameworks/__CoreData.framework/Versions/A/__CoreData > 0x7fff872e4000 - 0x7fff872e4ff7 com.apple.vecLib 3.6 > (vecLib 3.6) > <96FB6BAD-5568-C4E0-6FA7-__02791A58B584> > /System/Library/Frameworks/__vecLib.framework/Versions/A/__vecLib > 0x7fff872e5000 - 0x7fff872e6ff7 > com.apple.audio.units.__AudioUnit > 1.6.7 (1.6.7) <49B723D1-85F8-F86C-2331-__F586C56D68AF> > /System/Library/Frameworks/__AudioUnit.framework/Versions/__A/AudioUnit > 0x7fff873c0000 - 0x7fff873dbff7 > com.apple.openscripting 1.3.1 > (???) <9D50701D-54AC-405B-CC65-__026FCB28258B> > /System/Library/Frameworks/__Carbon.framework/Versions/A/__Frameworks/OpenScripting.__framework/Versions/A/__OpenScripting > 0x7fff873dc000 - 0x7fff87416fff libcups.2.dylib 2.8.0 > (compatibility 2.0.0) <4F2A4397-89BD-DEAC-4971-__EE838FFA0964> > /usr/lib/libcups.2.dylib > 0x7fff87430000 - 0x7fff874affe7 > com.apple.audio.CoreAudio 3.2.6 > (3.2.6) <79E256EB-43F1-C7AA-6436-__124A4FFB02D0> > /System/Library/Frameworks/__CoreAudio.framework/Versions/__A/CoreAudio > 0x7fff874b0000 - 0x7fff874d1fe7 libPng.dylib ??? (???) > > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/ImageIO.__framework/Versions/A/__Resources/libPng.dylib > 0x7fff874d2000 - 0x7fff87693fef libSystem.B.dylib > 125.2.11 > (compatibility 1.0.0) <9AB4F1D1-89DC-0E8A-DC8E-__A4FE4D69DB69> > /usr/lib/libSystem.B.dylib > 0x7fff87694000 - 0x7fff87696fff > com.apple.print.framework.__Print > 6.1 (237.1) > /System/Library/Frameworks/__Carbon.framework/Versions/A/__Frameworks/Print.framework/__Versions/A/Print > 0x7fff876ad000 - 0x7fff876b2fff libGFXShared.dylib > ??? (???) > <6BBC351E-40B3-F4EB-2F35-__05BDE52AF87E> > /System/Library/Frameworks/__OpenGL.framework/Versions/A/__Libraries/libGFXShared.dylib > 0x7fff876b3000 - 0x7fff876c9fef libbsm.0.dylib ??? (???) > <42D3023A-A1F7-4121-6417-__FCC6B51B3E90> /usr/lib/libbsm.0.dylib > 0x7fff8788c000 - 0x7fff8788efef > com.apple.ExceptionHandling 1.5 > (10) > /System/Library/Frameworks/__ExceptionHandling.framework/__Versions/A/ExceptionHandling > 0x7fff8788f000 - 0x7fff8790dff7 com.apple.CoreText > 151.13 (???) > <5C6214AD-D683-80A8-86EB-__328C99B75322> > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/__CoreText.framework/Versions/A/__CoreText > 0x7fff8790e000 - 0x7fff8790eff7 com.apple.Accelerate 1.6 > (Accelerate 1.6) <15DF8B4A-96B2-CB4E-368D-__DEC7DF6B62BB> > /System/Library/Frameworks/__Accelerate.framework/Versions/__A/Accelerate > 0x7fff8790f000 - 0x7fff87b98ff7 com.apple.security > 6.1.2 (55002) > > /System/Library/Frameworks/__Security.framework/Versions/A/__Security > 0x7fff88c04000 - 0x7fff88c57ff7 com.apple.HIServices > 1.8.3 (???) > > /System/Library/Frameworks/__ApplicationServices.framework/__Versions/A/Frameworks/__HIServices.framework/Versions/__A/HIServices > 0x7fff88c59000 - 0x7fff88c72fff > com.apple.CFOpenDirectory 10.6 > (10.6) <401557B1-C6D1-7E1A-0D7E-__941715C37BFA> > /System/Library/Frameworks/__OpenDirectory.framework/__Versions/A/Frameworks/__CFOpenDirectory.framework/__Versions/A/CFOpenDirectory > 0x7fff88c97000 - 0x7fff88cecff7 > com.apple.framework.__familycontrols > 2.0.2 (2020) <8807EB96-D12D-8601-2E74-__25784A0DE4FF> > /System/Library/__PrivateFrameworks/__FamilyControls.framework/__Versions/A/FamilyControls > 0x7fff88cfb000 - 0x7fff88db4fff libsqlite3.dylib 9.6.0 > (compatibility 9.0.0) <2C5ED312-E646-9ADE-73A9-__6199A2A43150> > /usr/lib/libsqlite3.dylib > 0x7fff88dc7000 - 0x7fff88de7fff > com.apple.DirectoryService.__Framework 3.6 (621.16) > <0ED4A74A-F8FB-366D-6588-__F13EA397326F> > /System/Library/Frameworks/__DirectoryService.framework/__Versions/A/DirectoryService > 0x7fff88de8000 - 0x7fff88deeff7 > com.apple.DiskArbitration 2.3 > (2.3) <857F6E43-1EF4-7D53-351B-__10DE0A8F992A> > /System/Library/Frameworks/__DiskArbitration.framework/__Versions/A/DiskArbitration > 0x7fff89584000 - 0x7fff89d8efe7 libBLAS.dylib 219.0.0 > (compatibility 1.0.0) > /System/Library/Frameworks/__Accelerate.framework/Versions/__A/Frameworks/vecLib.framework/__Versions/A/libBLAS.dylib > 0x7fff89e94000 - 0x7fff89edeff7 com.apple.Metadata > 10.6.3 (507.15) > > /System/Library/Frameworks/__CoreServices.framework/__Versions/A/Frameworks/__Metadata.framework/Versions/A/__Metadata > 0x7fff89edf000 - 0x7fff89ef0ff7 libz.1.dylib 1.2.3 > (compatibility > 1.0.0) <97019C74-161A-3488-41EC-__A6CA8738418C> > /usr/lib/libz.1.dylib > 0x7fff89ef1000 - 0x7fff89fa1fff edu.mit.Kerberos > 6.5.11 (6.5.11) > <085D80F5-C9DC-E252-C21B-__03295E660C91> > /System/Library/Frameworks/__Kerberos.framework/Versions/A/__Kerberos > 0x7fff89fa2000 - 0x7fff89fb4fe7 libsasl2.2.dylib 3.15.0 > (compatibility 3.0.0) <76B83C8D-8EFE-4467-0F75-__275648AFED97> > /usr/lib/libsasl2.2.dylib > 0x7fff8a1ac000 - 0x7fff8a20cfe7 > com.apple.framework.IOKit 2.0 > (???) <4F071EF0-8260-01E9-C641-__830E582FA416> > /System/Library/Frameworks/__IOKit.framework/Versions/A/__IOKit > 0x7fff8a27a000 - 0x7fff8a27dff7 com.apple.securityhi > 4.0 (36638) > > /System/Library/Frameworks/__Carbon.framework/Versions/A/__Frameworks/SecurityHI.__framework/Versions/A/__SecurityHI > 0x7fff8a27e000 - 0x7fff8a6c1fef libLAPACK.dylib 219.0.0 > (compatibility 1.0.0) <0CC61C98-FF51-67B3-F3D8-__C5E430C201A9> > /System/Library/Frameworks/__Accelerate.framework/Versions/__A/Frameworks/vecLib.framework/__Versions/A/libLAPACK.dylib > 0x7fff8a6c2000 - 0x7fff8a711ff7 > com.apple.DirectoryService.__PasswordServerFramework 6.1 (6.1) > <0731C40D-71EF-B417-C83B-__54C3527A36EA> > /System/Library/__PrivateFrameworks/__PasswordServer.framework/__Versions/A/PasswordServer > 0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib ??? > (???) > <9AB4F1D1-89DC-0E8A-DC8E-__A4FE4D69DB69> /usr/lib/libSystem.B.dylib > > > > > -- > Steve Hannah > Web Lite Solutions Corp. From anthony.petrov at oracle.com Tue Oct 22 11:39:22 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Oct 2013 22:39:22 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <7F14B1EF-457C-45F3-8AAA-19DC365EB065@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <7F14B1EF-457C-45F3-8AAA-19DC365EB065@oracle.com> Message-ID: <5266C65A.6070403@oracle.com> I think that triggering java.awt.headless=true is enough. The class instance wrapping will be done automatically in java.awt.Toolkit.getDefaultToolkit(). A reliable way to test it is, I guess, as follows: log out of your GUI session, ssh to the Mac box, and try running a headless app (e.g. a printing jtreg test.) -- best regards, Anthony On 10/22/2013 10:15 PM, David DeHaven wrote: > > [removing hotspot-dev and build-dev..] > > I can't look at the code at the moment as I'm focused on something else... Does the wrapping happen automagically at some point based on java.awt.headless? It doesn't look trivial to do this from within the scope of java_props_md.c, it seems the best I could do from there is trigger java.awt.headless=true if we're not in a headful login session. It would be fairly simple to have it set java.awt.headless if the logic is there to do the HeadlessToolkit wrapping, and that's something that could be done for all platforms (though only Mac would use it for the moment). > > Otherwise I can just revert it back to my original version and we can continue using HToolkit for now. > > With the current code, JTREG fails massively in headless mode (due to most calls throwing a HeadlessException) and JPRT performs horribly when running the jdk_awt tests due to it not running in an Aqua session. Is there some reliable way of testing headless mode? > > -DrD- > >> Hello. >> I suppose we should request from sqe team to run the jck tests in the "true" headless mode via ssh(w/o headless option and w/o access to Aqua session). >> >> On 22.10.2013 21:54, Anthony Petrov wrote: >>> We don't have to. IIRC, the choice of HToolkit on Mac was made by chance. >>> >>> Since we must load the lwawt lib in headless on Mac anyway, we may as well use the CToolkit (properly wrapped in the HeadlessToolkit). But there's no need to continue to use the HToolkit on Mac. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/22/2013 08:22 PM, Leonid Romanov wrote: >>>> There was a discussion why we use HToolkit instead of HeadlessToolkit: >>>> http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html >>>> >>>> So we might want to continue using it. >>>> >>>> Also, please be aware that there is HToolkit check in GraphicsToolkit.getHeadlessProperty() >>>> >>>> On Oct 22, 2013, at 1:23 PM, Artem Ananiev wrote: >>>> >>>>> Hi, David, >>>>> >>>>> thanks for additional cleanup. >>>>> >>>>> I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >>>>> >>>>> Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 10/22/2013 7:34 AM, David DeHaven wrote: >>>>>> >>>>>> Updated webrev for JDK (hotspot change is the same): >>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>>>>> >>>>>> Changes since last version: >>>>>> - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>>>>> - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] >>>>>> >>>>>> -DrD- >>>>>> >>>>>> >>>>>>> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>>>>> Thanks guys. >>>>>>>> >>>>>>>> Anthony, can you sponsor this for me? >>>>>>>> >>>>>>>> -DrD- >>>>>>>> >>>>>>>>> This fix looks fine to me as well. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> best regards, >>>>>>>>> Anthony >>>>>>>>> >>>>>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>>>>> >>>>>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>>>>> >>>>>>>>>> Request for review of JDK-8025673: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>>>>> >>>>>>>>>> Proposed changes: >>>>>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>>>>> >>>>>>>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>>>>>>> >>>>>>>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>>>>>>> >>>>>>>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>>>>>>> >>>>>>>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>>>>>>> >>>>>>>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>>>>> 461 } else { >>>>>>>>>> 462 // TODO: do we still need this? >>>>>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>>>>> 464 } >>>>>>>>>> >>>>>>>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>>>>>>> >>>>>>>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>>>>>>> >>>>>>>>>> -DrD- >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> >> >> -- >> Best regards, Sergey. >> > From david.dehaven at oracle.com Tue Oct 22 11:51:08 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 22 Oct 2013 11:51:08 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5266C65A.6070403@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <7F14B1EF-457C-45F3-8AAA-19DC365EB065@oracle.com> <5266C65A.6070403@oracle.com> Message-ID: <59A52BE2-ED57-4E3F-BD0E-4F61C1A1899E@oracle.com> You can also just "ssh otheruser at localhost", the login session will have no Aqua session associated with the other user. That might even work with the current user... -DrD- > I think that triggering java.awt.headless=true is enough. The class instance wrapping will be done automatically in java.awt.Toolkit.getDefaultToolkit(). > > A reliable way to test it is, I guess, as follows: log out of your GUI session, ssh to the Mac box, and try running a headless app (e.g. a printing jtreg test.) > > -- > best regards, > Anthony > > On 10/22/2013 10:15 PM, David DeHaven wrote: >> >> [removing hotspot-dev and build-dev..] >> >> I can't look at the code at the moment as I'm focused on something else... Does the wrapping happen automagically at some point based on java.awt.headless? It doesn't look trivial to do this from within the scope of java_props_md.c, it seems the best I could do from there is trigger java.awt.headless=true if we're not in a headful login session. It would be fairly simple to have it set java.awt.headless if the logic is there to do the HeadlessToolkit wrapping, and that's something that could be done for all platforms (though only Mac would use it for the moment). >> >> Otherwise I can just revert it back to my original version and we can continue using HToolkit for now. >> >> With the current code, JTREG fails massively in headless mode (due to most calls throwing a HeadlessException) and JPRT performs horribly when running the jdk_awt tests due to it not running in an Aqua session. Is there some reliable way of testing headless mode? >> >> -DrD- >> >>> Hello. >>> I suppose we should request from sqe team to run the jck tests in the "true" headless mode via ssh(w/o headless option and w/o access to Aqua session). >>> >>> On 22.10.2013 21:54, Anthony Petrov wrote: >>>> We don't have to. IIRC, the choice of HToolkit on Mac was made by chance. >>>> >>>> Since we must load the lwawt lib in headless on Mac anyway, we may as well use the CToolkit (properly wrapped in the HeadlessToolkit). But there's no need to continue to use the HToolkit on Mac. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/22/2013 08:22 PM, Leonid Romanov wrote: >>>>> There was a discussion why we use HToolkit instead of HeadlessToolkit: >>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html >>>>> >>>>> So we might want to continue using it. >>>>> >>>>> Also, please be aware that there is HToolkit check in GraphicsToolkit.getHeadlessProperty() >>>>> >>>>> On Oct 22, 2013, at 1:23 PM, Artem Ananiev wrote: >>>>> >>>>>> Hi, David, >>>>>> >>>>>> thanks for additional cleanup. >>>>>> >>>>>> I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >>>>>> >>>>>> Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>> On 10/22/2013 7:34 AM, David DeHaven wrote: >>>>>>> >>>>>>> Updated webrev for JDK (hotspot change is the same): >>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>>>>>> >>>>>>> Changes since last version: >>>>>>> - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>>>>>> - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>>>> >>>>>>>> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >>>>>>>> >>>>>>>> -DrD- >>>>>>>> >>>>>>>>> Thanks guys. >>>>>>>>> >>>>>>>>> Anthony, can you sponsor this for me? >>>>>>>>> >>>>>>>>> -DrD- >>>>>>>>> >>>>>>>>>> This fix looks fine to me as well. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> best regards, >>>>>>>>>> Anthony >>>>>>>>>> >>>>>>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>>>>>> >>>>>>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>>>>>> >>>>>>>>>>> Request for review of JDK-8025673: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>>>>>> >>>>>>>>>>> Proposed changes: >>>>>>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>>>>>> >>>>>>>>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>>>>>>>> >>>>>>>>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>>>>>>>> >>>>>>>>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>>>>>>>> >>>>>>>>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>>>>>>>> >>>>>>>>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>>>>>> 461 } else { >>>>>>>>>>> 462 // TODO: do we still need this? >>>>>>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>>>>>> 464 } >>>>>>>>>>> >>>>>>>>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>>>>>>>> >>>>>>>>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>>>>>>>> >>>>>>>>>>> -DrD- >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> From david.dehaven at oracle.com Tue Oct 22 20:27:32 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 22 Oct 2013 20:27:32 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5266C65A.6070403@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <7F14B1EF-457C-45F3-8AAA-19DC365EB065@oracle.com> <5266C65A.6070403@oracle.com> Message-ID: Ok, I tried: PreferredToolkit prefToolkit = getPreferredToolkit(); if (prefToolkit == HToolkit) { sprops.awt_headless = "true"; } after adding awt_headless to the props struct and it works OK. The only issue is that in a non-GUI login there's a big fat warning: 2013-10-22 20:25:08.489 java[12267:707] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode. You don't see that if you specify java.awt.headless on the command line. It seems to be benign, not sure if there will be any long term impact or not. I'll update the webrev and post it. -DrD- > I think that triggering java.awt.headless=true is enough. The class instance wrapping will be done automatically in java.awt.Toolkit.getDefaultToolkit(). > > A reliable way to test it is, I guess, as follows: log out of your GUI session, ssh to the Mac box, and try running a headless app (e.g. a printing jtreg test.) > > -- > best regards, > Anthony > > On 10/22/2013 10:15 PM, David DeHaven wrote: >> >> [removing hotspot-dev and build-dev..] >> >> I can't look at the code at the moment as I'm focused on something else... Does the wrapping happen automagically at some point based on java.awt.headless? It doesn't look trivial to do this from within the scope of java_props_md.c, it seems the best I could do from there is trigger java.awt.headless=true if we're not in a headful login session. It would be fairly simple to have it set java.awt.headless if the logic is there to do the HeadlessToolkit wrapping, and that's something that could be done for all platforms (though only Mac would use it for the moment). >> >> Otherwise I can just revert it back to my original version and we can continue using HToolkit for now. >> >> With the current code, JTREG fails massively in headless mode (due to most calls throwing a HeadlessException) and JPRT performs horribly when running the jdk_awt tests due to it not running in an Aqua session. Is there some reliable way of testing headless mode? >> >> -DrD- >> >>> Hello. >>> I suppose we should request from sqe team to run the jck tests in the "true" headless mode via ssh(w/o headless option and w/o access to Aqua session). >>> >>> On 22.10.2013 21:54, Anthony Petrov wrote: >>>> We don't have to. IIRC, the choice of HToolkit on Mac was made by chance. >>>> >>>> Since we must load the lwawt lib in headless on Mac anyway, we may as well use the CToolkit (properly wrapped in the HeadlessToolkit). But there's no need to continue to use the HToolkit on Mac. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/22/2013 08:22 PM, Leonid Romanov wrote: >>>>> There was a discussion why we use HToolkit instead of HeadlessToolkit: >>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html >>>>> >>>>> So we might want to continue using it. >>>>> >>>>> Also, please be aware that there is HToolkit check in GraphicsToolkit.getHeadlessProperty() >>>>> >>>>> On Oct 22, 2013, at 1:23 PM, Artem Ananiev wrote: >>>>> >>>>>> Hi, David, >>>>>> >>>>>> thanks for additional cleanup. >>>>>> >>>>>> I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >>>>>> >>>>>> Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>> On 10/22/2013 7:34 AM, David DeHaven wrote: >>>>>>> >>>>>>> Updated webrev for JDK (hotspot change is the same): >>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>>>>>> >>>>>>> Changes since last version: >>>>>>> - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>>>>>> - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>>>> >>>>>>>> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >>>>>>>> >>>>>>>> -DrD- >>>>>>>> >>>>>>>>> Thanks guys. >>>>>>>>> >>>>>>>>> Anthony, can you sponsor this for me? >>>>>>>>> >>>>>>>>> -DrD- >>>>>>>>> >>>>>>>>>> This fix looks fine to me as well. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> best regards, >>>>>>>>>> Anthony >>>>>>>>>> >>>>>>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>>>>>> >>>>>>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>>>>>> >>>>>>>>>>> Request for review of JDK-8025673: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>>>>>> >>>>>>>>>>> Proposed changes: >>>>>>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>>>>>> >>>>>>>>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>>>>>>>> >>>>>>>>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>>>>>>>> >>>>>>>>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>>>>>>>> >>>>>>>>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>>>>>>>> >>>>>>>>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>>>>>> 461 } else { >>>>>>>>>>> 462 // TODO: do we still need this? >>>>>>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>>>>>> 464 } >>>>>>>>>>> >>>>>>>>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>>>>>>>> >>>>>>>>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>>>>>>>> >>>>>>>>>>> -DrD- >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> From paul_t100 at fastmail.fm Wed Oct 23 03:00:46 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 23 Oct 2013 11:00:46 +0100 Subject: Is OSX JTable and JList selection color incorrect Message-ID: <52679E4E.2050602@fastmail.fm> On OSX Java 1.7.0_40-b43 the selection colour appears correct ( a light blue) but JTable and JList selection colour is dark blue like on Windows Am I doing something wrong, or is this a bug , or is it meant to be like this ? Paul From alexandr.scherbatiy at oracle.com Wed Oct 23 08:24:05 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 23 Oct 2013 19:24:05 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays In-Reply-To: <52664607.2090807@oracle.com> References: <52664607.2090807@oracle.com> Message-ID: <5267EA15.1080103@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/ The JCK failures has been resolved: - Some tests tries to draw an image with Integer.MAX_VALUE width or height. Passing large values to image.getScaledImage(width, height, hints). leads that an Image filter is not able to create necessary arrays. The fix uses the original image if width or height are equal to Integer.MAX_VALUE. - Using Image.SCALE_DEFAULT hint for the getScaledImage(width, height, hints) method to get the high resolution image interferes with JCK tests that expect that the scaled image by certain algorithm is returned. This is fixed by invoking the super.getScaledImage(width, height, hints) method in ToolkitImage in case if a high resolution image is not set. Thanks, Alexandr. On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8011059 > webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 > > The IMAGE_SCALING rendering hint is added to the RenderingHints class. > Enabling the image scaling rendering hint forces the SunGraphics2D > to use getScaledInstance(width, height, hints) method > from Image class with SCALE_DEFAULT hint. > > By default the image scaling rendering hint is enabled on HiDPI > display and disabled for standard displays. > > User can override the getScaledInstance(width, height, hints) method > and return necessary high resolution image > according to the given image width and height. > > For example: > --------------------- > final Image highResolutionImage = > new BufferedImage(2 * WIDTH, 2 * HEIGHT, > BufferedImage.TYPE_INT_RGB); > Image image = new BufferedImage(WIDTH, HEIGHT, > BufferedImage.TYPE_INT_RGB) { > > @Override > public Image getScaledInstance(int width, int height, int > hints) { > if ((hints & Image.SCALE_DEFAULT) != 0) { > return (width <= WIDTH && height <= HEIGHT) > ? this : highResolutionImage; > } > return super.getScaledInstance(width, height, hints); > } > }; > --------------------- > > The LWCToolkit and ToolkitImage classes are patched to automatically > get provided image at 2x.ext images on MacOSX. > > There are no significant changes in the Java2D demo to make it look > perfect on Retina displays. > It needs only to put necessary images with the @2x postfix and they > will be automatically drawn. > > Thanks, > Alexandr. > From alexandr.scherbatiy at oracle.com Wed Oct 23 08:38:33 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 23 Oct 2013 19:38:33 +0400 Subject: Aqua Icons support on HiDPI displays. In-Reply-To: <74962867-775B-4A2C-A98D-F120EAB7C8A3@tagtraum.com> References: <52612058.1030502@oracle.com> <8EDD8811-8572-4226-B5E9-13EECF037B6B@apple.com> <74962867-775B-4A2C-A98D-F120EAB7C8A3@tagtraum.com> Message-ID: <5267ED79.1090602@oracle.com> On 10/19/2013 1:21 PM, Hendrik Schreiber wrote: > On Oct 19, 2013, at 12:45 AM, Mike Swingler wrote: > >> On Oct 18, 2013, at 4:49 AM, Alexander Scherbatiy wrote: >> >>> The GetIconRef method is used in the CImage.m now to get the system icons on MacOSX. >>> >>> The NSImage + (id)imageNamed:(NSString *)name method can be used directly instead. >>> >>> There are NSImageNameFolder, NSImageNameFolderBurnable, and NSImageNameFolderSmart constants but I can't find >>> the constant for the open folder icon. >>> https://developer.apple.com/library/mac/documentation/cocoa/reference/applicationkit/classes/NSImage_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Toolbar_Named_Images >>> >>> The same is for the alert stop system icon. There are NSImageNameInfo and NSImageNameCaution icons but I can't find >>> the constant for the alert stop icon. > Alexander, > > may I ask through which API you intend to make the icons available? There is a way to load system images and icons on MacOS X in Java by using: Toolkit.getDefaultToolkit().getImage("NSImage://NSImageName") method: https://developer.apple.com/library/mac/documentation/java/conceptual/java14development/04-JavaUIToolkits/JavaUIToolkits.html This method calls [NSImage imageNamed: "NSImageName"] and we are going to reuse it for the system icons loading. > Also, will there be a way to create custom HiDPI images/icons? > If so, how? There is the fix that has been recently sent to review: http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html A user needs to override the getScaledInstance(width, height, hints) method in Image class and returns images with necessary resolution according to the given width and height. Images with @2x postfix should be automatically loaded into the ToolkitImage on MacOS X. Thanks, Alexandr. > > Thanks, > > -hendrik From hs at tagtraum.com Wed Oct 23 08:43:07 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Wed, 23 Oct 2013 17:43:07 +0200 Subject: Aqua Icons support on HiDPI displays. In-Reply-To: <5267ED79.1090602@oracle.com> References: <52612058.1030502@oracle.com> <8EDD8811-8572-4226-B5E9-13EECF037B6B@apple.com> <74962867-775B-4A2C-A98D-F120EAB7C8A3@tagtraum.com> <5267ED79.1090602@oracle.com> Message-ID: <43F4F10A-F8F6-4056-989B-D666B13344BA@tagtraum.com> On Oct 23, 2013, at 5:38 PM, Alexander Scherbatiy wrote: >> >> may I ask through which API you intend to make the icons available? > > There is a way to load system images and icons on MacOS X in Java by using: Toolkit.getDefaultToolkit().getImage("NSImage://NSImageName") method: > https://developer.apple.com/library/mac/documentation/java/conceptual/java14development/04-JavaUIToolkits/JavaUIToolkits.html > This method calls [NSImage imageNamed: "NSImageName"] and we are going to reuse it for the system icons loading. > >> Also, will there be a way to create custom HiDPI images/icons? >> If so, how? > > There is the fix that has been recently sent to review: http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html > A user needs to override the getScaledInstance(width, height, hints) method in Image class and returns images with necessary resolution according to > the given width and height. Images with @2x postfix should be automatically loaded into the ToolkitImage on MacOS X. Very nice! Any idea whether this will be backported to Java7 (assuming this is for 8)? -hendrik From swingler at apple.com Fri Oct 25 00:30:16 2013 From: swingler at apple.com (Mike Swingler) Date: Fri, 25 Oct 2013 00:30:16 -0700 Subject: Is OSX JTable and JList selection color incorrect In-Reply-To: <52679E4E.2050602@fastmail.fm> References: <52679E4E.2050602@fastmail.fm> Message-ID: On Oct 23, 2013, at 3:00 AM, Paul Taylor wrote: > On OSX Java 1.7.0_40-b43 the selection colour appears correct ( a light blue) but JTable and JList selection colour is dark blue like on Windows > Am I doing something wrong, or is this a bug , or is it meant to be like this ? Does it adapt if you change your selection color the General pref-pane? Tables, lists, and outline views in Cocoa use a selection color which is different from the text highlight color. Regards, Mike Swingler Apple Inc. From magnus.ihse.bursie at oracle.com Fri Oct 25 04:37:12 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 Oct 2013 13:37:12 +0200 Subject: Freetype on Mac OS X? Message-ID: <526A57E8.2080609@oracle.com> Hi there mac porters :-) When I fiddled with the build system for using freetype in the OpenJDK builds, it turned out a couple of inconsistencies regarding freetype on macosx. The current build system actually requires freetype to be present when building. When building libfontmanager, we include freetypeScaler.c (which I think is the only consumer of freetype) and link with -lfreetype, on macosx as well as on linux and solaris. However, I'm not entirely sure this is correct. Evidence (like the build documentation :)) seems to indicate that freetype is not/should not be used on macosx, not even for OpenJDK. (It's never used when building the closed product.) I tried out a simple patch which excludes freetypeScaler.c when building on macosx, and stops linking with freetype. It compiles without issues, but I have no readily access to a "headful" Mac to try this on, nor do I really know what tests to run to check of libfontmanager works as expected. I'd appreciate some input on this. Here is the patch I used: diff --git a/makefiles/lib/Awt2dLibraries.gmk b/makefiles/lib/Awt2dLibraries.gmk --- a/makefiles/lib/Awt2dLibraries.gmk +++ b/makefiles/lib/Awt2dLibraries.gmk @@ -777,9 +777,13 @@ BUILD_LIBFONTMANAGER_MAPFILE := $(JDK_TOPDIR)/makefiles/mapfiles/libfontmanager/mapfile-vers LIBFONTMANAGER_EXCLUDE_FILES += freetypeScaler.c else - FONT_HEADERS := $(FREETYPE_CFLAGS) BUILD_LIBFONTMANAGER_MAPFILE := $(JDK_TOPDIR)/makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk - BUILD_LIBFONTMANAGER_FONTLIB := $(FREETYPE_LIBS) + ifneq ($(OPENJDK_TARGET_OS), macosx) + FONT_HEADERS := $(FREETYPE_CFLAGS) + BUILD_LIBFONTMANAGER_FONTLIB := $(FREETYPE_LIBS) + else + LIBFONTMANAGER_EXCLUDE_FILES += freetypeScaler.c + endif endif LIBFONTMANAGER_OPTIMIZATION := HIGH /Magnus From alexandr.scherbatiy at oracle.com Fri Oct 25 06:18:47 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 25 Oct 2013 17:18:47 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays In-Reply-To: <5267EA15.1080103@oracle.com> References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com> Message-ID: <526A6FB7.7000800@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/ - Scaled image width and height are transformed according to the AffineTransform type. - ToolkitImage subclass is used to hold @2x image instance. Thanks, Alexandr. On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/ > > The JCK failures has been resolved: > - Some tests tries to draw an image with Integer.MAX_VALUE width > or height. Passing large values to image.getScaledImage(width, height, > hints). > leads that an Image filter is not able to create necessary > arrays. The fix uses the original image if width or height are equal > to Integer.MAX_VALUE. > - Using Image.SCALE_DEFAULT hint for the getScaledImage(width, > height, hints) method to get the high resolution image interferes with > JCK tests that expect that the scaled image by certain > algorithm is returned. This is fixed by invoking the > super.getScaledImage(width, height, hints) > method in ToolkitImage in case if a high resolution image is > not set. > > Thanks, > Alexandr. > > > > On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8011059 >> webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 >> >> The IMAGE_SCALING rendering hint is added to the RenderingHints class. >> Enabling the image scaling rendering hint forces the SunGraphics2D >> to use getScaledInstance(width, height, hints) method >> from Image class with SCALE_DEFAULT hint. >> >> By default the image scaling rendering hint is enabled on HiDPI >> display and disabled for standard displays. >> >> User can override the getScaledInstance(width, height, hints) >> method and return necessary high resolution image >> according to the given image width and height. >> >> For example: >> --------------------- >> final Image highResolutionImage = >> new BufferedImage(2 * WIDTH, 2 * HEIGHT, >> BufferedImage.TYPE_INT_RGB); >> Image image = new BufferedImage(WIDTH, HEIGHT, >> BufferedImage.TYPE_INT_RGB) { >> >> @Override >> public Image getScaledInstance(int width, int height, int >> hints) { >> if ((hints & Image.SCALE_DEFAULT) != 0) { >> return (width <= WIDTH && height <= HEIGHT) >> ? this : highResolutionImage; >> } >> return super.getScaledInstance(width, height, hints); >> } >> }; >> --------------------- >> >> The LWCToolkit and ToolkitImage classes are patched to >> automatically get provided image at 2x.ext images on MacOSX. >> >> There are no significant changes in the Java2D demo to make it look >> perfect on Retina displays. >> It needs only to put necessary images with the @2x postfix and they >> will be automatically drawn. >> >> Thanks, >> Alexandr. >> > From philip.race at oracle.com Fri Oct 25 08:49:09 2013 From: philip.race at oracle.com (Phil Race) Date: Fri, 25 Oct 2013 08:49:09 -0700 Subject: Freetype on Mac OS X? In-Reply-To: <526A57E8.2080609@oracle.com> References: <526A57E8.2080609@oracle.com> Message-ID: <526A92F5.1000106@oracle.com> You might have managed to build, but there will be some things that do not run without freetype. You could try using java.awt.Font.createFont(..) with a Postscript Type 1 font - this doesn't need a head if you pass in -Djava.awt.headless=true - and I am 99.999% sure you'll get an unsatisfied link error or similar. The strictures about freetype on Mac is coming from the X11 install. No one could produce a build based on using that which is guaranteed to work on any one else's system Many months ago - based on someone else's work - I had a patch to allow you to use a pre-built one and bundle it in the build but it was around the time there was a "hold" on all build changes, and its likely stale even if could find it. I also remember it was a *pain* building a freetype dylib that didn't bake in the location it should be found into referencing dylibs. Can't remember if I completely solved that. So in summary what is needed is that people are told how to go get freetype, build it into one that can be used anywhere, and that the build be changed to provide a way to not always use 'system freetype' on OS X, but instead to copy in your pre-built copy. -phil. On 10/25/2013 4:37 AM, Magnus Ihse Bursie wrote: > Hi there mac porters :-) > > When I fiddled with the build system for using freetype in the OpenJDK > builds, it turned out a couple of inconsistencies regarding freetype > on macosx. > > The current build system actually requires freetype to be present when > building. When building libfontmanager, we include freetypeScaler.c > (which I think is the only consumer of freetype) and link with > -lfreetype, on macosx as well as on linux and solaris. > > However, I'm not entirely sure this is correct. Evidence (like the > build documentation :)) seems to indicate that freetype is not/should > not be used on macosx, not even for OpenJDK. (It's never used when > building the closed product.) > > I tried out a simple patch which excludes freetypeScaler.c when > building on macosx, and stops linking with freetype. It compiles > without issues, but I have no readily access to a "headful" Mac to try > this on, nor do I really know what tests to run to check of > libfontmanager works as expected. > > I'd appreciate some input on this. > > Here is the patch I used: > > diff --git a/makefiles/lib/Awt2dLibraries.gmk > b/makefiles/lib/Awt2dLibraries.gmk > --- a/makefiles/lib/Awt2dLibraries.gmk > +++ b/makefiles/lib/Awt2dLibraries.gmk > @@ -777,9 +777,13 @@ > BUILD_LIBFONTMANAGER_MAPFILE := > $(JDK_TOPDIR)/makefiles/mapfiles/libfontmanager/mapfile-vers > LIBFONTMANAGER_EXCLUDE_FILES += freetypeScaler.c > else > - FONT_HEADERS := $(FREETYPE_CFLAGS) > BUILD_LIBFONTMANAGER_MAPFILE := > $(JDK_TOPDIR)/makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk > - BUILD_LIBFONTMANAGER_FONTLIB := $(FREETYPE_LIBS) > + ifneq ($(OPENJDK_TARGET_OS), macosx) > + FONT_HEADERS := $(FREETYPE_CFLAGS) > + BUILD_LIBFONTMANAGER_FONTLIB := $(FREETYPE_LIBS) > + else > + LIBFONTMANAGER_EXCLUDE_FILES += freetypeScaler.c > + endif > endif > > LIBFONTMANAGER_OPTIMIZATION := HIGH > > /Magnus > From david.dehaven at oracle.com Fri Oct 25 09:13:54 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 25 Oct 2013 09:13:54 -0700 Subject: Freetype on Mac OS X? In-Reply-To: <526A57E8.2080609@oracle.com> References: <526A57E8.2080609@oracle.com> Message-ID: > Hi there mac porters :-) > > When I fiddled with the build system for using freetype in the OpenJDK builds, it turned out a couple of inconsistencies regarding freetype on macosx. > > The current build system actually requires freetype to be present when building. When building libfontmanager, we include freetypeScaler.c (which I think is the only consumer of freetype) and link with -lfreetype, on macosx as well as on linux and solaris. > > However, I'm not entirely sure this is correct. Evidence (like the build documentation :)) seems to indicate that freetype is not/should not be used on macosx, not even for OpenJDK. (It's never used when building the closed product.) I was wondering the same thing, since the native toolkit has all the fontmanager methods and is (now) used in all combinations of open or closed and headless or headful. > I tried out a simple patch which excludes freetypeScaler.c when building on macosx, and stops linking with freetype. It compiles without issues, but I have no readily access to a "headful" Mac to try this on, nor do I really know what tests to run to check of libfontmanager works as expected. > > I'd appreciate some input on this. > > Here is the patch I used: I'll give it a try when I get a chance, probably early next week at this point :( We have some more cleanup to do now that X11 is disabled. It would be really wonderful to completely remove all the X11 dependencies, perhaps this can be done as part of JDK-8003900. https://bugs.openjdk.java.net/browse/JDK-8003900 I've no idea if this can be done for the first release of jdk8 now since we're officially past ZBB. -DrD- From david.dehaven at oracle.com Fri Oct 25 09:20:51 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 25 Oct 2013 09:20:51 -0700 Subject: Freetype on Mac OS X? In-Reply-To: <526A92F5.1000106@oracle.com> References: <526A57E8.2080609@oracle.com> <526A92F5.1000106@oracle.com> Message-ID: <6CDDBDFF-FEB8-4318-906E-8CB28664960E@oracle.com> > You might have managed to build, but there will be some things that do not run > without freetype. > > You could try using java.awt.Font.createFont(..) with a Postscript Type 1 font - this > doesn't need a head if you pass in -Djava.awt.headless=true - and I am 99.999% > sure you'll get an unsatisfied link error or similar. > > The strictures about freetype on Mac is coming from the X11 install. > No one could produce a build based on using that which is guaranteed > to work on any one else's system The X11 toolkit is no longer built, as of last night: https://bugs.openjdk.java.net/browse/JDK-8025673 Now LWCToolkit is used in both headless and headful modes, there are no other native toolkits to choose from. I'm wondering if there's a code path that is broken now... do we have headless font tests lingering around somewhere? -DrD- From philip.race at oracle.com Fri Oct 25 09:26:53 2013 From: philip.race at oracle.com (Phil Race) Date: Fri, 25 Oct 2013 09:26:53 -0700 Subject: Freetype on Mac OS X? In-Reply-To: <6CDDBDFF-FEB8-4318-906E-8CB28664960E@oracle.com> References: <526A57E8.2080609@oracle.com> <526A92F5.1000106@oracle.com> <6CDDBDFF-FEB8-4318-906E-8CB28664960E@oracle.com> Message-ID: <526A9BCD.5070002@oracle.com> Its not headless vs headful. Its both. JDK by specification requires support of Type 1 fonts. There are APIs that explicitly accept them. OS X has no native support for these. Without freetype (or in the case of Oracle JDK) you can't pass JCK and APIs would be broken. -phil. On 10/25/2013 9:20 AM, David DeHaven wrote: >> You might have managed to build, but there will be some things that do not run >> without freetype. >> >> You could try using java.awt.Font.createFont(..) with a Postscript Type 1 font - this >> doesn't need a head if you pass in -Djava.awt.headless=true - and I am 99.999% >> sure you'll get an unsatisfied link error or similar. >> >> The strictures about freetype on Mac is coming from the X11 install. >> No one could produce a build based on using that which is guaranteed >> to work on any one else's system > The X11 toolkit is no longer built, as of last night: > https://bugs.openjdk.java.net/browse/JDK-8025673 > > Now LWCToolkit is used in both headless and headful modes, there are no other native toolkits to choose from. > > I'm wondering if there's a code path that is broken now... do we have headless font tests lingering around somewhere? > > -DrD- > From leonid.romanov at oracle.com Fri Oct 25 10:33:07 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 25 Oct 2013 21:33:07 +0400 Subject: [8] Review request for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow Message-ID: <9A8388F2-3F39-42BB-84D8-0268625F3858@oracle.com> Hello, Please review a fix for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow The problem here is that NSView's -enterFullScreenMode: withOptions: we currently use for entering exclusive full screen mode does it by creating a NSFullScreenWindow instance and moving the view from its window to that newly created full screen window. Since we do not control NSFullScreenWindow creation, we do not get any focus and other notifications from it. The fix is to stop using -enterFullScreenMode: withOptions: and just achieve the exclusive full screen mode manually. Bug: https://bugs.openjdk.java.net/browse/JDK-8013581 Webrev: http://cr.openjdk.java.net/~leonidr/8013581/webrev.00/ Regards, Leonid. From Sergey.Bylokhov at oracle.com Fri Oct 25 11:28:06 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Oct 2013 22:28:06 +0400 Subject: [8] Review request for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow In-Reply-To: <9A8388F2-3F39-42BB-84D8-0268625F3858@oracle.com> References: <9A8388F2-3F39-42BB-84D8-0268625F3858@oracle.com> Message-ID: <526AB836.3000805@oracle.com> Hi, Leonid. The fix looks good. But can you update the test to check all devices in the system? On 25.10.2013 21:33, Leonid Romanov wrote: > Hello, > Please review a fix for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow > The problem here is that NSView's -enterFullScreenMode: withOptions: we currently use for entering exclusive full screen mode does it by creating a NSFullScreenWindow instance and moving the view from its window to that newly created full screen window. Since we do not control NSFullScreenWindow creation, we do not get any focus and other notifications from it. > The fix is to stop using -enterFullScreenMode: withOptions: and just achieve the exclusive full screen mode manually. > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8013581 > Webrev:http://cr.openjdk.java.net/~leonidr/8013581/webrev.00/ > > Regards, > Leonid. -- Best regards, Sergey. From paul_t100 at fastmail.fm Sat Oct 26 12:36:56 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sat, 26 Oct 2013 20:36:56 +0100 Subject: Possible regressionn, popupmenus not appearing to work correctly with cntl-click Message-ID: <526C19D8.2060003@fastmail.fm> Just moved from Java 6 with Quaqua and Feel to Java 7 with Aqua look and feel so not 100% sure where the problem lies but previously if I have some fields selected in a table and then invoked popup menu by either 1. Right click on two button mouse 2. Left Click whilst pressing Cntl Key it would display the popup menu. Now with Java 7 Right click on two button mouse works correctly Left Click whilst pressing Cntl key displays the popup menu BUT also deselects all fields that was selected except the one the mouse is currently over. Is this a known problem, seeing as macs are still sold with one-button mice this looks like a major regression Paul From hs at tagtraum.com Sun Oct 27 01:06:27 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Sun, 27 Oct 2013 09:06:27 +0100 Subject: Possible regressionn, popupmenus not appearing to work correctly with cntl-click In-Reply-To: <526C19D8.2060003@fastmail.fm> References: <526C19D8.2060003@fastmail.fm> Message-ID: <33714D41-2083-4B02-93AD-9B315C162837@tagtraum.com> On Oct 26, 2013, at 9:36 PM, Paul Taylor wrote: > Just moved from Java 6 with Quaqua and Feel to Java 7 with Aqua look and feel so not 100% sure where the problem lies but previously if I have some fields selected in a table and then invoked popup menu by either > > 1. Right click on two button mouse > 2. Left Click whilst pressing Cntl Key > > it would display the popup menu. > > Now with Java 7 > > Right click on two button mouse works correctly > Left Click whilst pressing Cntl key displays the popup menu BUT also deselects all fields that was selected except the one the mouse is currently over. > > Is this a known problem, seeing as macs are still sold with one-button mice this looks like a major regression Command-click starts editing.. (yeah, I know). Does setting table.putClientProperty("JTable.autoStartsEdit", Boolean.FALSE) on the JTable make a difference? -hendrik From falcon.sheep at gmail.com Sun Oct 27 22:07:26 2013 From: falcon.sheep at gmail.com (Abu Abdullah) Date: Mon, 28 Oct 2013 09:07:26 +0400 Subject: Compile specific Apple API (com.apple.eawt) on Windows Message-ID: Hi, Windows port of Oracle JDK 7 does not include com.apple.eawt.* classes preventing compiling the code on Windows. Is there any way to overcome this. My main development platform is Windows and rarely I'm able to test the code on Mac machine. From steve at weblite.ca Sun Oct 27 22:14:22 2013 From: steve at weblite.ca (Steve Hannah) Date: Sun, 27 Oct 2013 22:14:22 -0700 Subject: Compile specific Apple API (com.apple.eawt) on Windows In-Reply-To: References: Message-ID: Apple made a jar file with stubs that you can use to make your app compile on Windows. This stack overflow thread provides a link and more discussion on it. http://stackoverflow.com/questions/2151174/how-can-i-develop-apple-java-extensions-on-windows I believe this should work fine in JDK7 also. Steve On Sun, Oct 27, 2013 at 10:07 PM, Abu Abdullah wrote: > Hi, > > Windows port of Oracle JDK 7 does not include com.apple.eawt.* classes > preventing compiling the code on Windows. Is there any way to overcome > this. My main development platform is Windows and rarely I'm able to test > the code on Mac machine. > -- Steve Hannah Web Lite Solutions Corp. From falcon.sheep at gmail.com Sun Oct 27 23:18:29 2013 From: falcon.sheep at gmail.com (Abu Abdullah) Date: Mon, 28 Oct 2013 10:18:29 +0400 Subject: Compile specific Apple API (com.apple.eawt) on Windows In-Reply-To: References: Message-ID: Thanks for the link, AppleJavaExtensions.jar is working fine with me as well. On the other hand, I was trying to get rid of this jar and use the one with Oracle JRE. by this i will make sure that these classes will work properly with Oracle java and any new MAC OS. also the compiler will complain in case of deprecation. On Mon, Oct 28, 2013 at 9:14 AM, Steve Hannah wrote: > Apple made a jar file with stubs that you can use to make your app compile > on Windows. This stack overflow thread provides a link and more discussion > on it. > > http://stackoverflow.com/questions/2151174/how-can-i-develop-apple-java-extensions-on-windows > > I believe this should work fine in JDK7 also. > > Steve > > > On Sun, Oct 27, 2013 at 10:07 PM, Abu Abdullah wrote: > >> Hi, >> >> Windows port of Oracle JDK 7 does not include com.apple.eawt.* classes >> preventing compiling the code on Windows. Is there any way to overcome >> this. My main development platform is Windows and rarely I'm able to test >> the code on Mac machine. >> > > > > -- > Steve Hannah > Web Lite Solutions Corp. > From paul_t100 at fastmail.fm Mon Oct 28 02:30:31 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Mon, 28 Oct 2013 09:30:31 +0000 Subject: Possible regressionn, popupmenus not appearing to work correctly with cntl-click In-Reply-To: <33714D41-2083-4B02-93AD-9B315C162837@tagtraum.com> References: <526C19D8.2060003@fastmail.fm> <33714D41-2083-4B02-93AD-9B315C162837@tagtraum.com> Message-ID: <526E2EB7.9060504@fastmail.fm> On 27/10/2013 08:06, Hendrik Schreiber wrote: > On Oct 26, 2013, at 9:36 PM, Paul Taylor wrote: > >> Just moved from Java 6 with Quaqua and Feel to Java 7 with Aqua look and feel so not 100% sure where the problem lies but previously if I have some fields selected in a table and then invoked popup menu by either >> >> 1. Right click on two button mouse >> 2. Left Click whilst pressing Cntl Key >> >> it would display the popup menu. >> >> Now with Java 7 >> >> Right click on two button mouse works correctly >> Left Click whilst pressing Cntl key displays the popup menu BUT also deselects all fields that was selected except the one the mouse is currently over. >> >> Is this a known problem, seeing as macs are still sold with one-button mice this looks like a major regression > Command-click starts editing.. (yeah, I know). Does setting > > table.putClientProperty("JTable.autoStartsEdit", Boolean.FALSE) > > on the JTable make a difference? > No, that doesnt make any difference. Actually the problem is not to do with editing (these fields aren't even editable). The problem is that with Cntl-Left Click instead of Right-Click it correctly show the popups, but it also resets selection, so basically it is doing a right-click and a left-click, i.e not realizing that it shouldn't do the left click action because the cntl key was pressed. Looking at https://java.net/projects/quaqua/sources/svn/content/trunk/Quaqua/src/ch/randelshofer/quaqua/QuaquaTableUI.java?rev=460 maybe the shouldIgnore() method in line 790 is handling a case that Java 7 is not Paul From artem.ananiev at oracle.com Mon Oct 28 03:33:25 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 28 Oct 2013 14:33:25 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays In-Reply-To: <526A6FB7.7000800@oracle.com> References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com> <526A6FB7.7000800@oracle.com> Message-ID: <526E3D75.5070308@oracle.com> Hi, Alexander, a few comments: 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here? 2. I'm not sure that the proposed getScaledImageName() implementation in ScalableToolkitImage works perfectly for URLs like this: http://www.exampmle.com/dir/image In this case it will try to find 2x image here: http://www.example at 2x.com/dir/image which doesn't look correct. 3. RenderingHints spec references Retina or non-Retina displays, which should be removed. Thanks, Artem On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/ > > - Scaled image width and height are transformed according to the > AffineTransform type. > - ToolkitImage subclass is used to hold @2x image instance. > > Thanks, > Alexandr. > > On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/ >> >> The JCK failures has been resolved: >> - Some tests tries to draw an image with Integer.MAX_VALUE width >> or height. Passing large values to image.getScaledImage(width, height, >> hints). >> leads that an Image filter is not able to create necessary >> arrays. The fix uses the original image if width or height are equal >> to Integer.MAX_VALUE. >> - Using Image.SCALE_DEFAULT hint for the getScaledImage(width, >> height, hints) method to get the high resolution image interferes with >> JCK tests that expect that the scaled image by certain >> algorithm is returned. This is fixed by invoking the >> super.getScaledImage(width, height, hints) >> method in ToolkitImage in case if a high resolution image is >> not set. >> >> Thanks, >> Alexandr. >> >> >> >> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8011059 >>> webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 >>> >>> The IMAGE_SCALING rendering hint is added to the RenderingHints class. >>> Enabling the image scaling rendering hint forces the SunGraphics2D >>> to use getScaledInstance(width, height, hints) method >>> from Image class with SCALE_DEFAULT hint. >>> >>> By default the image scaling rendering hint is enabled on HiDPI >>> display and disabled for standard displays. >>> >>> User can override the getScaledInstance(width, height, hints) >>> method and return necessary high resolution image >>> according to the given image width and height. >>> >>> For example: >>> --------------------- >>> final Image highResolutionImage = >>> new BufferedImage(2 * WIDTH, 2 * HEIGHT, >>> BufferedImage.TYPE_INT_RGB); >>> Image image = new BufferedImage(WIDTH, HEIGHT, >>> BufferedImage.TYPE_INT_RGB) { >>> >>> @Override >>> public Image getScaledInstance(int width, int height, int >>> hints) { >>> if ((hints & Image.SCALE_DEFAULT) != 0) { >>> return (width <= WIDTH && height <= HEIGHT) >>> ? this : highResolutionImage; >>> } >>> return super.getScaledInstance(width, height, hints); >>> } >>> }; >>> --------------------- >>> >>> The LWCToolkit and ToolkitImage classes are patched to >>> automatically get provided image at 2x.ext images on MacOSX. >>> >>> There are no significant changes in the Java2D demo to make it look >>> perfect on Retina displays. >>> It needs only to put necessary images with the @2x postfix and they >>> will be automatically drawn. >>> >>> Thanks, >>> Alexandr. >>> >> > From leonid.romanov at oracle.com Mon Oct 28 05:29:20 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 28 Oct 2013 16:29:20 +0400 Subject: Possible regressionn, popupmenus not appearing to work correctly with cntl-click In-Reply-To: <526E2EB7.9060504@fastmail.fm> References: <526C19D8.2060003@fastmail.fm> <33714D41-2083-4B02-93AD-9B315C162837@tagtraum.com> <526E2EB7.9060504@fastmail.fm> Message-ID: <19E8D1FE-5F02-4498-9443-054080C75E9D@oracle.com> Hello, I've filed a bug: https://bugs.openjdk.java.net/browse/JDK-8027374 On 28.10.2013, at 13:30, Paul Taylor wrote: > On 27/10/2013 08:06, Hendrik Schreiber wrote: >> On Oct 26, 2013, at 9:36 PM, Paul Taylor wrote: >> >>> Just moved from Java 6 with Quaqua and Feel to Java 7 with Aqua look and feel so not 100% sure where the problem lies but previously if I have some fields selected in a table and then invoked popup menu by either >>> >>> 1. Right click on two button mouse >>> 2. Left Click whilst pressing Cntl Key >>> >>> it would display the popup menu. >>> >>> Now with Java 7 >>> >>> Right click on two button mouse works correctly >>> Left Click whilst pressing Cntl key displays the popup menu BUT also deselects all fields that was selected except the one the mouse is currently over. >>> >>> Is this a known problem, seeing as macs are still sold with one-button mice this looks like a major regression >> Command-click starts editing.. (yeah, I know). Does setting >> >> table.putClientProperty("JTable.autoStartsEdit", Boolean.FALSE) >> >> on the JTable make a difference? >> > > No, that doesnt make any difference. Actually the problem is not to do with editing (these fields aren't even editable). The problem is that with Cntl-Left Click instead of Right-Click it correctly show the popups, but it also resets selection, so basically it is doing a right-click and a left-click, i.e not realizing that it shouldn't do the left click action because the cntl key was pressed. > > Looking at https://java.net/projects/quaqua/sources/svn/content/trunk/Quaqua/src/ch/randelshofer/quaqua/QuaquaTableUI.java?rev=460 maybe the shouldIgnore() method in line 790 is handling a case that Java 7 is not > > Paul From anthony.petrov at oracle.com Mon Oct 28 06:29:58 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 28 Oct 2013 17:29:58 +0400 Subject: [8] Review request for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow In-Reply-To: <9A8388F2-3F39-42BB-84D8-0268625F3858@oracle.com> References: <9A8388F2-3F39-42BB-84D8-0268625F3858@oracle.com> Message-ID: <526E66D6.7060208@oracle.com> Hi Leonid, The fix looks somewhat risky so late in the release. But I talked with Sergey and I see that it resolves a lot of real problems. So I'm sort of OK with it. A few comments: src/macosx/native/sun/awt/AWTWindow.m > 255 self.preFullScreenLevel = [self.nsWindow level]; The alwaysOnTop state may be changed dynamically, and thus the value stored in this property might get stale. Either, we don't need this initializer altogether since we need to store the level only after a window enters the full screen mode and don't care about it after we exit the mode, or we should update it dynamically (in -setPropertiesForStyleBits, I suppose). src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java In this View implementation we explicitly made enter/exitFSM() methods no-ops. What are the LWViews used for, and do they now allow entering the full screen mode after your fix? If yes, I think we should find a way to disable that. -- best regards, Anthony On 10/25/2013 09:33 PM, Leonid Romanov wrote: > Hello, > Please review a fix for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow > The problem here is that NSView's -enterFullScreenMode: withOptions: we currently use for entering exclusive full screen mode does it by creating a NSFullScreenWindow instance and moving the view from its window to that newly created full screen window. Since we do not control NSFullScreenWindow creation, we do not get any focus and other notifications from it. > The fix is to stop using -enterFullScreenMode: withOptions: and just achieve the exclusive full screen mode manually. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8013581 > Webrev: http://cr.openjdk.java.net/~leonidr/8013581/webrev.00/ > > Regards, > Leonid. > From paul_t100 at fastmail.fm Tue Oct 29 04:14:13 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 29 Oct 2013 11:14:13 +0000 Subject: Possible regressionn, popupmenus not appearing to work correctly with cntl-click In-Reply-To: <19E8D1FE-5F02-4498-9443-054080C75E9D@oracle.com> References: <526C19D8.2060003@fastmail.fm> <33714D41-2083-4B02-93AD-9B315C162837@tagtraum.com> <526E2EB7.9060504@fastmail.fm> <19E8D1FE-5F02-4498-9443-054080C75E9D@oracle.com> Message-ID: <526F9885.5040109@fastmail.fm> On 28/10/2013 12:29, Leonid Romanov wrote: > Hello, > I've filed a bug: > https://bugs.openjdk.java.net/browse/JDK-8027374 > Hi, Ive think Ive found the issue for me , I created this test case and it works correctly as you say import javax.swing.*; public class TableTest { public static void main(String[] args) throws Exception { JPopupMenu popup = new JPopupMenu("Popup"); popup.add(new JMenuItem("Copy")); JTable test = new JTable(5,5); test.setComponentPopupMenu(popup); test.setRowSelectionAllowed(true); test.setColumnSelectionAllowed(true); UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName()); JFrame frame = new JFrame(); frame.add(test); frame.pack(); frame.setVisible(true); } } But if you comment out the line test.setComponentPopupMenu(popup); so that there is no popup menu then it doesn't work, CntlClick will change the selection. Whether this is a bug, or correct behaviour Im not sure ? But the reason why this is causing an issue for me in my current code is that Im not using setComponentPopupMenu()instead I'm adding a mouse handler to the table that then decides whether or not to show a popup menu so I guess the logic for Jtable must not detect that it has a popup menu in this case. I've checked and the method was not added to JTable until Java 1.5 and my code was started before then so hopefully I can just update my code to use the method and the problem will go away for me. Paul From alexandr.scherbatiy at oracle.com Tue Oct 29 09:45:48 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 29 Oct 2013 20:45:48 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays In-Reply-To: <526E3D75.5070308@oracle.com> References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com> <526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com> Message-ID: <526FE63C.1020408@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8011059/webrev.03 On 10/28/2013 2:33 PM, Artem Ananiev wrote: > Hi, Alexander, > > a few comments: > > 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here? The isHiDPIImage() method is used to check that the drawHiDPIImage should be called like: if (isHiDPIImage(img)) { return drawHiDPIImage(...); } > 2. I'm not sure that the proposed getScaledImageName() implementation > in ScalableToolkitImage works perfectly for URLs like this: > > http://www.exampmle.com/dir/image > > In this case it will try to find 2x image here: > > http://www.example at 2x.com/dir/image > > which doesn't look correct. Fixed. Only path part of a URL is converted to path2x. > 3. RenderingHints spec references Retina or non-Retina displays, which > should be removed. Fixed. - devScale is used instead of transform parsing in the drawHiDPIImage() method just to not have performance regression more than 2 times on HiDPI displays - LWCToolkit.ScalableToolkitImage is made public for the fix 8024926 [macosx] AquaIcon HiDPI support. Thanks, Alexandr. > > Thanks, > > Artem > > On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/ >> >> - Scaled image width and height are transformed according to the >> AffineTransform type. >> - ToolkitImage subclass is used to hold @2x image instance. >> >> Thanks, >> Alexandr. >> >> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/ >>> >>> The JCK failures has been resolved: >>> - Some tests tries to draw an image with Integer.MAX_VALUE width >>> or height. Passing large values to image.getScaledImage(width, height, >>> hints). >>> leads that an Image filter is not able to create necessary >>> arrays. The fix uses the original image if width or height are equal >>> to Integer.MAX_VALUE. >>> - Using Image.SCALE_DEFAULT hint for the getScaledImage(width, >>> height, hints) method to get the high resolution image interferes with >>> JCK tests that expect that the scaled image by certain >>> algorithm is returned. This is fixed by invoking the >>> super.getScaledImage(width, height, hints) >>> method in ToolkitImage in case if a high resolution image is >>> not set. >>> >>> Thanks, >>> Alexandr. >>> >>> >>> >>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8011059 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 >>>> >>>> The IMAGE_SCALING rendering hint is added to the RenderingHints >>>> class. >>>> Enabling the image scaling rendering hint forces the SunGraphics2D >>>> to use getScaledInstance(width, height, hints) method >>>> from Image class with SCALE_DEFAULT hint. >>>> >>>> By default the image scaling rendering hint is enabled on HiDPI >>>> display and disabled for standard displays. >>>> >>>> User can override the getScaledInstance(width, height, hints) >>>> method and return necessary high resolution image >>>> according to the given image width and height. >>>> >>>> For example: >>>> --------------------- >>>> final Image highResolutionImage = >>>> new BufferedImage(2 * WIDTH, 2 * HEIGHT, >>>> BufferedImage.TYPE_INT_RGB); >>>> Image image = new BufferedImage(WIDTH, HEIGHT, >>>> BufferedImage.TYPE_INT_RGB) { >>>> >>>> @Override >>>> public Image getScaledInstance(int width, int height, int >>>> hints) { >>>> if ((hints & Image.SCALE_DEFAULT) != 0) { >>>> return (width <= WIDTH && height <= HEIGHT) >>>> ? this : highResolutionImage; >>>> } >>>> return super.getScaledInstance(width, height, hints); >>>> } >>>> }; >>>> --------------------- >>>> >>>> The LWCToolkit and ToolkitImage classes are patched to >>>> automatically get provided image at 2x.ext images on MacOSX. >>>> >>>> There are no significant changes in the Java2D demo to make it look >>>> perfect on Retina displays. >>>> It needs only to put necessary images with the @2x postfix and they >>>> will be automatically drawn. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >> From alexandr.scherbatiy at oracle.com Tue Oct 29 09:47:55 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 29 Oct 2013 20:47:55 +0400 Subject: [8] Review request for 8024926 [macosx] AquaIcon HiDPI support Message-ID: <526FE6BB.3010109@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8024926 webrev: http://cr.openjdk.java.net/~alexsch/8024926/webrev.00 The fix returns a high resolution system icon in the overridden getScaledInstance(width, height, hints) method. The fix relies on the fix for the issue JDK-8011059 [macosx] Make JDK demos look perfect on retina displays: http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html - getScaledInstance(width, height, hints) method is used for the image drawing when IMAGE_SCALING hints are enabled - LWCToolkit.ScalableToolkitImage class is public Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Tue Oct 29 12:08:30 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 Oct 2013 23:08:30 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays In-Reply-To: <526FE63C.1020408@oracle.com> References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com> <526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com> <526FE63C.1020408@oracle.com> Message-ID: <527007AE.6000401@oracle.com> Hi, Alexander. The fix looks fine to me in general. But there is at least one issue. I build you fix and test it: - Consuming of cpu increased by 500 times Java2Demo on images tab. - FPS is dropped from 220(jdk8)/35(jdk7u40) to 15 in guimark2. Note that jdk6 has the same FPS(15) on my system. On 29.10.2013 20:45, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8011059/webrev.03 > > On 10/28/2013 2:33 PM, Artem Ananiev wrote: >> Hi, Alexander, >> >> a few comments: >> >> 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here? > The isHiDPIImage() method is used to check that the > drawHiDPIImage should be called like: > if (isHiDPIImage(img)) { > return drawHiDPIImage(...); > } > >> 2. I'm not sure that the proposed getScaledImageName() implementation >> in ScalableToolkitImage works perfectly for URLs like this: >> >> http://www.exampmle.com/dir/image >> >> In this case it will try to find 2x image here: >> >> http://www.example at 2x.com/dir/image >> >> which doesn't look correct. > Fixed. Only path part of a URL is converted to path2x. > >> 3. RenderingHints spec references Retina or non-Retina displays, >> which should be removed. > Fixed. > > - devScale is used instead of transform parsing in the > drawHiDPIImage() method just to not have performance regression more > than 2 times on HiDPI displays > - LWCToolkit.ScalableToolkitImage is made public for the fix > 8024926 [macosx] AquaIcon HiDPI support. > > Thanks, > Alexandr. > >> >> Thanks, >> >> Artem >> >> On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/ >>> >>> - Scaled image width and height are transformed according to the >>> AffineTransform type. >>> - ToolkitImage subclass is used to hold @2x image instance. >>> >>> Thanks, >>> Alexandr. >>> >>> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/ >>>> >>>> The JCK failures has been resolved: >>>> - Some tests tries to draw an image with Integer.MAX_VALUE width >>>> or height. Passing large values to image.getScaledImage(width, height, >>>> hints). >>>> leads that an Image filter is not able to create necessary >>>> arrays. The fix uses the original image if width or height are equal >>>> to Integer.MAX_VALUE. >>>> - Using Image.SCALE_DEFAULT hint for the getScaledImage(width, >>>> height, hints) method to get the high resolution image interferes with >>>> JCK tests that expect that the scaled image by certain >>>> algorithm is returned. This is fixed by invoking the >>>> super.getScaledImage(width, height, hints) >>>> method in ToolkitImage in case if a high resolution image is >>>> not set. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> >>>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8011059 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 >>>>> >>>>> The IMAGE_SCALING rendering hint is added to the RenderingHints >>>>> class. >>>>> Enabling the image scaling rendering hint forces the SunGraphics2D >>>>> to use getScaledInstance(width, height, hints) method >>>>> from Image class with SCALE_DEFAULT hint. >>>>> >>>>> By default the image scaling rendering hint is enabled on HiDPI >>>>> display and disabled for standard displays. >>>>> >>>>> User can override the getScaledInstance(width, height, hints) >>>>> method and return necessary high resolution image >>>>> according to the given image width and height. >>>>> >>>>> For example: >>>>> --------------------- >>>>> final Image highResolutionImage = >>>>> new BufferedImage(2 * WIDTH, 2 * HEIGHT, >>>>> BufferedImage.TYPE_INT_RGB); >>>>> Image image = new BufferedImage(WIDTH, HEIGHT, >>>>> BufferedImage.TYPE_INT_RGB) { >>>>> >>>>> @Override >>>>> public Image getScaledInstance(int width, int height, int >>>>> hints) { >>>>> if ((hints & Image.SCALE_DEFAULT) != 0) { >>>>> return (width <= WIDTH && height <= HEIGHT) >>>>> ? this : highResolutionImage; >>>>> } >>>>> return super.getScaledInstance(width, height, hints); >>>>> } >>>>> }; >>>>> --------------------- >>>>> >>>>> The LWCToolkit and ToolkitImage classes are patched to >>>>> automatically get provided image at 2x.ext images on MacOSX. >>>>> >>>>> There are no significant changes in the Java2D demo to make it look >>>>> perfect on Retina displays. >>>>> It needs only to put necessary images with the @2x postfix and they >>>>> will be automatically drawn. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>> > -- Best regards, Sergey. From wjherrmann at gmail.com Tue Oct 29 13:41:48 2013 From: wjherrmann at gmail.com (Will Herrmann) Date: Tue, 29 Oct 2013 15:41:48 -0500 Subject: Where Can I Find the Javadocs for Apple Extensions? Message-ID: <9FE884CB-4264-474C-B24E-5CD0F4F4E7B7@gmail.com> A while back, I'd asked if Java 7 and onwards would continue to include the Apple Extensions (e.g. com.apple.eawt). I was told that they would indeed remain, but I don't think I ever got an answer about where I can find the Javadocs for them. They used to be hosted on Apple's website (at http://bit.ly/1939ShE), but it now results in a Page Not Found error. The OpenJDK site doesn't seem to have them and they're not in the standard Java 7 Javadocs either. Where can I find these Javadocs? Thanks in Advance, -Will Herrmann From paul_t100 at fastmail.fm Wed Oct 30 05:13:50 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 30 Oct 2013 12:13:50 +0000 Subject: Moving around Jtable with cursor key balnks out values In-Reply-To: <33714D41-2083-4B02-93AD-9B315C162837@tagtraum.com> References: <526C19D8.2060003@fastmail.fm> <33714D41-2083-4B02-93AD-9B315C162837@tagtraum.com> Message-ID: <5270F7FE.9000604@fastmail.fm> With Java 7 on OSX I find that as I move around my JTable cells with cursor keys it causes it to blank out every field in goes into. Adding: table.putClientProperty("JTable.autoStartsEdit", Boolean.FALSE) stops that issue happening, but then I have to press 'Enter' key to start editing. What I want to happen is that cursor keys just move the cursor without editing, and pressing any other key will start editing in that field. i.e I move to a field and press 'd', then will be displayed in the field. This is what happened in Java 6 on OSX (Quaqua) and with Java 7 on Windows. Paul From paul_t100 at fastmail.fm Wed Oct 30 05:24:34 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 30 Oct 2013 12:24:34 +0000 Subject: Moving around Jtable with cursor key balnks out values In-Reply-To: <5270F7FE.9000604@fastmail.fm> References: <526C19D8.2060003@fastmail.fm> <33714D41-2083-4B02-93AD-9B315C162837@tagtraum.com> <5270F7FE.9000604@fastmail.fm> Message-ID: <5270FA82.10401@fastmail.fm> On 30/10/2013 12:13, Paul Taylor wrote: > With Java 7 on OSX I find that as I move around my JTable cells with > cursor keys it causes it to blank out every field in goes into. > Adding: > table.putClientProperty("JTable.autoStartsEdit", Boolean.FALSE) > > stops that issue happening, but then I have to press 'Enter' key to > start editing. > > What I want to happen is that cursor keys just move the cursor without > editing, and pressing any other key will start editing in that field. > i.e I move to a field and press 'd', then will be displayed in the > field. This is what happened in Java 6 on OSX (Quaqua) and with Java 7 > on Windows. > > > Paul > > Apparently a bug was submitted for this, see http://stackoverflow.com/questions/11553197/spurious-calls-to-setvalueat-with-jtables-in-java-7-on-os-x-lion but seems to have disappeared without being fixed, is it still in JIRA ? Paul From Sergey.Bylokhov at oracle.com Wed Oct 30 08:20:16 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 30 Oct 2013 19:20:16 +0400 Subject: Where Can I Find the Javadocs for Apple Extensions? In-Reply-To: <9FE884CB-4264-474C-B24E-5CD0F4F4E7B7@gmail.com> References: <9FE884CB-4264-474C-B24E-5CD0F4F4E7B7@gmail.com> Message-ID: <527123B0.3010105@oracle.com> Hi, Will. I suggest to file a bug for this at http://bugreport.sun.com/bugreport As a workaround you can generate javadoc ourself from the source code: http://hg.openjdk.java.net/jdk8/awt/jdk/file/db2838f25a85/src/macosx/classes/com/apple/eawt On 30.10.2013 0:41, Will Herrmann wrote: > A while back, I'd asked if Java 7 and onwards would continue to include the Apple Extensions (e.g. com.apple.eawt). I was told that they would indeed remain, but I don't think I ever got an answer about where I can find the Javadocs for them. They used to be hosted on Apple's website (at http://bit.ly/1939ShE), but it now results in a Page Not Found error. The OpenJDK site doesn't seem to have them and they're not in the standard Java 7 Javadocs either. Where can I find these Javadocs? > > Thanks in Advance, > -Will Herrmann -- Best regards, Sergey. From leonid.romanov at oracle.com Wed Oct 30 10:05:48 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 30 Oct 2013 21:05:48 +0400 Subject: FullScreen (Exclusive) Swing Components Fail to Receive Keyboard Input on Java 7 on Mac OS X (Mountain) Lion In-Reply-To: References: Message-ID: <6397C2AB-0364-4DEB-810D-82A7336F0B8C@oracle.com> I've just pushed the fix for this issue. Should appear in main JDK 8 repo after a while. Regards, Leonid. On 18.10.2013, at 22:22, Tim Howe wrote: > Has there been any movement on this? > > We rely on full-screen exclusive mode for our application and this is > blocking us from upgrading past Java 1.6. I've just checked and the > problem still persists in 1.8.0-ea-b111. > > Unfortunately the workaround described here doesn't fully solve the > problem. Specifically mouse cursor and button highlighting on hover still > don't function normally. > > Thanks, > Tim > > > On 11/2/12 5:26 PM, "Leonid Romanov" wrote: > >> Yep, please fill a bug with your latest findings. >> >> On Nov 3, 2012, at 1:14 AM, Eric Bailey wrote: >> >>> Wow, thanks for the response! At least in my test example, this indeed >>> restores keyboard input. I initially though I might have to resort to >>> invokeLaters on the visibility calls, but immediately after works fine: >>> >>> dev.setFullScreenWindow(f); >>> f.setVisible(false); >>> f.setVisible(true); >>> >>> I have yet to file a bug. Would you like one based on this latest >>> information? >>> >>> Also, I'll be checking my larger app for functionality in a few minutes >>> and will report back. >>> >>> Thank you, >>> - Eric >>> >>> >>> On Nov 2, 2012, at 1:36 PM, Leonid Romanov wrote: >>> >>>> Well, although I'm not 100% sure yet, but it looks like when we enter >>>> full screen some other window becomes the first responder, hence the >>>> beep. Could you please try the following workaround: after calling >>>> setFullScreenWindow() on a frame, call setVisible(false) followed by >>>> setVisible(true). This, in theory, should restore the correct first >>>> responder. >>>> >>>> On Nov 2, 2012, at 10:37 PM, Leonid Romanov >>> oracle.com> wrote: >>>> >>>>> Hi, >>>>> Confirming that this issue is reproducible on my Mac as well. Have >>>>> you filled the bug yet? >>>>> >>>>> Regards, >>>>> Leonid. >>>>> >>>>> On Nov 1, 2012, at 11:26 PM, Eric Bailey >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> My company has a Swing application that needs to run in both a >>>>>> windowed context and in a fullscreen, kiosk-like mode. >>>>>> >>>>>> This application has worked fine for years on OS X, most recently >>>>>> targeting Java 6. We've been looking to move to Java 7 and to >>>>>> incorporate JavaFX elements, driving us to do compatibility testing >>>>>> with the latest Mountain Lion release (10.8.2 Supplemental) and >>>>>> Oracle's JDK 7u9. >>>>>> >>>>>> Unfortunately, we noticed a glaring issue while in fullscreen mode: >>>>>> mouse movement and clicks work fine, but keyboard input is not >>>>>> delivered to the components. Tab also does not work for focus >>>>>> traversal, though the focus subsystem appears to work properly >>>>>> according to FocusListeners and the KeyboardFocusManager. Most key >>>>>> presses produce a system alert beep in response, though registered >>>>>> KeyListeners and key bindings receive no events. >>>>>> >>>>>> I have a detailed issue and focused sample code on StackOverflow (I >>>>>> didn't want to burden the message with the 240 line sample): >>>>>> >>>>>> http://stackoverflow.com/questions/13064607/fullscreen-swing-component >>>>>> s-fail-to-receive-keyboard-input-on-java-7-on-mac-os-x >>>>>> >>>>>> Digging deeper, we identified that the issue was introduced with >>>>>> 7u6, when JavaFX began its inclusion in the mainline distribution. >>>>>> It remains in 7u7 and 7u9, and it affects both Lion 10.7 and Mountain >>>>>> Lion 10.8. A coworker attributes this to a switch from an AWTView to >>>>>> a NSWindow in 7u6 as the backing for the fullscreen window. >>>>>> >>>>>> I'll be filing an issue with Oracle soon, but I was hoping to hear >>>>>> of possible workarounds in the interim. >>>>>> >>>>>> One alternative approach I was pursuing was incorporating >>>>>> com.apple.eawt.FullScreenUtilities. This option has been included in >>>>>> my sample code, but I have found limited kiosking capabilities. In >>>>>> particular, I'm hoping to eliminate access to Command-Tab app >>>>>> switching, Mission Control, and Launch Pad, effectively locking the >>>>>> user into my application (it's an education setting). >>>>>> Unfortunately, the prevailing suggestions regarding disabling the >>>>>> Dock (which is responsible for those listed capabilities) revealed >>>>>> that the Dock also handles fullscreen apps, rendering the >>>>>> FullScreenUtilities calls inoperable. >>>>>> >>>>>> All input is greatly appreciated. >>>>>> >>>>>> Thank you, >>>>>> Eric Bailey >>>>>> Director, Content Engineering >>>>>> Acuitus >>>>> >>>> >>> > > > > This email message, including any attachment(s), is for the sole use of the intended recipient(s) and may contain confidential and legally privileged information. If you believe that you are not an intended recipient of this message, please contact the sender by reply email and destroy all copies of the original message. Any unauthorized use, dissemination, or reproduction of this message by anyone other than an intended recipient is strictly prohibited. BLOODHOUND is a trademark of Constitution Medical, Inc. From wjherrmann at gmail.com Wed Oct 30 13:37:06 2013 From: wjherrmann at gmail.com (Will Herrmann) Date: Wed, 30 Oct 2013 15:37:06 -0500 Subject: Where Can I Find the Javadocs for Apple Extensions? In-Reply-To: <527123B0.3010105@oracle.com> References: <9FE884CB-4264-474C-B24E-5CD0F4F4E7B7@gmail.com> <527123B0.3010105@oracle.com> Message-ID: I filed a bug using the link you provided and received an e-mail back saying that it was accepted as bug #9007897. However, when I try to search for it in the bug database, I am told "This bug is not available. More information is available here." Clicking on the word "here" brings me to a blank page. So I'm not sure what I did wrong or if there are internal server problems with the bug database. -Will Herrmann On Oct 30, 2013, at 10:20 AM, Sergey Bylokhov wrote: > Hi, Will. > I suggest to file a bug for this at http://bugreport.sun.com/bugreport > > As a workaround you can generate javadoc ourself from the source code: > http://hg.openjdk.java.net/jdk8/awt/jdk/file/db2838f25a85/src/macosx/classes/com/apple/eawt > > On 30.10.2013 0:41, Will Herrmann wrote: >> A while back, I'd asked if Java 7 and onwards would continue to include the Apple Extensions (e.g. com.apple.eawt). I was told that they would indeed remain, but I don't think I ever got an answer about where I can find the Javadocs for them. They used to be hosted on Apple's website (at http://bit.ly/1939ShE), but it now results in a Page Not Found error. The OpenJDK site doesn't seem to have them and they're not in the standard Java 7 Javadocs either. Where can I find these Javadocs? >> Thanks in Advance, >> -Will Herrmann > > > -- > Best regards, Sergey. > From paul_t100 at fastmail.fm Wed Oct 30 14:38:02 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 30 Oct 2013 21:38:02 +0000 Subject: Java 7 Application built on OSX 10.9 crashing on startup on 10.7.5 Message-ID: <52717C3A.9030404@fastmail.fm> Ive built a Java 7 bundle for my application on OSX10.9, all appears well but when I try it on OSX 10.7 it crashes on startup But Java 7 is supported on OSX 10.7.3 and later, right ? Details below: Process: launchd [229] Path: /Applications/Jaikoz.app/Contents/MacOS/Jaikoz Identifier: com.jthink.jaikoz Version: ??? (???) Code Type: X86-64 (Native) Parent Process: launchd [110] Date/Time: 2013-10-30 21:10:32.986 +0000 OS Version: Mac OS X 10.7.5 (11G56) Report Version: 9 Interval Since Last Report: 9929716 sec Crashes Since Last Report: 15 Per-App Crashes Since Last Report: 1 Anonymous UUID: 9162B9F6-4E51-4991-9437-5E6CB7C3A73D Crashed Thread: Unknown Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fff5fc01028 Backtrace not available Unknown thread crashed with X86 Thread State (64-bit): rax: 0x0000000000000055 rbx: 0x0000000000000000 rcx: 0x0000000000000000 rdx: 0x0000000000000000 rdi: 0x0000000000000000 rsi: 0x0000000000000000 rbp: 0x0000000000000000 rsp: 0x0000000000000000 r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000000 r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000 rip: 0x00007fff5fc01028 rfl: 0x0000000000010203 cr2: 0x00007fff5fc01028 Logical CPU: 0 Binary images description not available External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 2 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: 312 thread_create: 0 thread_set_state: 0 Model: Macmini2,1, BootROM MM21.009A.B00, 2 processors, Intel Core 2 Duo, 1.83 GHz, 2 GB, SMC 1.19f2 Graphics: Intel GMA 950, GMA 950, Built-In, spdisplays_integrated_vram Memory Module: BANK 0/DIMM0, 1 GB, DDR2 SDRAM, 667 MHz, 0xAD00000000000000, 0x48594D503531325336344350382D59352020 Memory Module: BANK 1/DIMM1, 1 GB, DDR2 SDRAM, 667 MHz, 0xAD00000000000000, 0x48594D503531325336344350382D59352020 AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x86), Atheros 5424: 2.1.14.9 Bluetooth: Version 4.0.8f17, 2 service, 18 devices, 1 incoming serial ports Network Service: Ethernet, Ethernet, en0 Serial ATA Device: Hitachi HTS541680J9SA00, 80.03 GB Parallel ATA Device: MATSHITACD-RW CW-8124 USB Device: Keyboard Hub, apple_vendor_id, 0x1006, 0xfd500000 / 2 USB Device: Apple Keyboard, apple_vendor_id, 0x0221, 0xfd520000 / 3 USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x8205, 0x7d100000 / 2 USB Device: IR Receiver, apple_vendor_id, 0x8240, 0x7d200000 / 3 USB Device: Microsoft Wireless Optical Mouse? 1.00, 0x045e (Microsoft Corporation), 0x00e1, 0x5d200000 / 2 From leonid.romanov at oracle.com Thu Oct 31 04:11:53 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 31 Oct 2013 15:11:53 +0400 Subject: Possible regressionn, popupmenus not appearing to work correctly with cntl-click In-Reply-To: <526F9885.5040109@fastmail.fm> References: <526C19D8.2060003@fastmail.fm> <33714D41-2083-4B02-93AD-9B315C162837@tagtraum.com> <526E2EB7.9060504@fastmail.fm> <19E8D1FE-5F02-4498-9443-054080C75E9D@oracle.com> <526F9885.5040109@fastmail.fm> Message-ID: I see.. While it might pose an inconvenience in some scenarios on OS X, I don't think it's an issue, since Apple JDK 6 behaves the same way, so I'm going to close the bug. On 29.10.2013, at 15:14, Paul Taylor wrote: > On 28/10/2013 12:29, Leonid Romanov wrote: >> Hello, >> I've filed a bug: >> https://bugs.openjdk.java.net/browse/JDK-8027374 >> > Hi, Ive think Ive found the issue for me , I created this test case and it works correctly as you say > > import javax.swing.*; > > public class TableTest > { > public static void main(String[] args) throws Exception > { > JPopupMenu popup = new JPopupMenu("Popup"); > popup.add(new JMenuItem("Copy")); > JTable test = new JTable(5,5); > test.setComponentPopupMenu(popup); > test.setRowSelectionAllowed(true); > test.setColumnSelectionAllowed(true); > UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName()); > JFrame frame = new JFrame(); > frame.add(test); > frame.pack(); > frame.setVisible(true); > } > } > > But if you comment out the line > > test.setComponentPopupMenu(popup); > > so that there is no popup menu then it doesn't work, CntlClick will change the selection. > > Whether this is a bug, or correct behaviour Im not sure ? > > But the reason why this is causing an issue for me in my current code is that Im not using setComponentPopupMenu()instead I'm adding a mouse handler to the table that then decides whether or not to show a popup menu so I guess the logic for Jtable must not detect that it has a popup menu in this case. I've checked and the method was not added to JTable until Java 1.5 and my code was started before then so hopefully I can just update my code to use the method and the problem will go away for me. > > Paul > > From paul_t100 at fastmail.fm Thu Oct 31 04:27:32 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 31 Oct 2013 11:27:32 +0000 Subject: Possible regressionn, popupmenus not appearing to work correctly with cntl-click In-Reply-To: References: <526C19D8.2060003@fastmail.fm> <33714D41-2083-4B02-93AD-9B315C162837@tagtraum.com> <526E2EB7.9060504@fastmail.fm> <19E8D1FE-5F02-4498-9443-054080C75E9D@oracle.com> <526F9885.5040109@fastmail.fm> Message-ID: <52723EA4.6090408@fastmail.fm> On 31/10/2013 11:11, Leonid Romanov wrote: > I see.. While it might pose an inconvenience in some scenarios on OS > X, I don't think it's an issue, since Apple JDK 6 behaves the same > way, so I'm going to close the bug. > Okay no problem, I now have it working for me since using setComponentPopup(). The only thing I would say is that is if Cntl-Click is meant to work the same as Right-Click on OSX in all situations it does seem there is a minor issue that it breaks my old code but this is no longer a problem for me. > On 29.10.2013, at 15:14, Paul Taylor > wrote: > >> On 28/10/2013 12:29, Leonid Romanov wrote: >>> Hello, >>> I've filed a bug: >>> https://bugs.openjdk.java.net/browse/JDK-8027374 >>> >> Hi, Ive think Ive found the issue for me , I created this test case >> and it works correctly as you say >> >> import javax.swing.*; >> >> public class TableTest >> { >> public static void main(String[] args) throws Exception >> { >> JPopupMenu popup = new JPopupMenu("Popup"); >> popup.add(new JMenuItem("Copy")); >> JTable test = new JTable(5,5); >> test.setComponentPopupMenu(popup); >> test.setRowSelectionAllowed(true); >> test.setColumnSelectionAllowed(true); >> UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName()); >> JFrame frame = new JFrame(); >> frame.add(test); >> frame.pack(); >> frame.setVisible(true); >> } >> } >> >> But if you comment out the line >> >> test.setComponentPopupMenu(popup); >> >> so that there is no popup menu then it doesn't work, CntlClick will >> change the selection. >> >> Whether this is a bug, or correct behaviour Im not sure ? >> >> But the reason why this is causing an issue for me in my current code >> is that Im not using setComponentPopupMenu()instead I'm adding a >> mouse handler to the table that then decides whether or not to show a >> popup menu so I guess the logic for Jtable must not detect that it >> has a popup menu in this case. I've checked and the method was not >> added to JTable until Java 1.5 and my code was started before then so >> hopefully I can just update my code to use the method and the >> problem will go away for me. >> >> Paul >> >> > From paul_t100 at fastmail.fm Thu Oct 31 04:50:54 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 31 Oct 2013 11:50:54 +0000 Subject: Default heap memory size allocated with Java 7 on OSX Message-ID: <5272441E.7090100@fastmail.fm> How does Java 7 decide on the max value of heap memory allocated (-Xmx) if not specified on an OSX bundle, I've read the manual page and it gave no indication. It seems to be allocated more than the default on Java 6 and I wonder if it varies with the memory available on the machine, that would be very useful to me because my application is memory bound, but I cannot set the default too high because then the application would fail to run at all on lower specification machines. Paul From krueger at lesspain.de Thu Oct 31 05:43:42 2013 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Thu, 31 Oct 2013 13:43:42 +0100 Subject: Possible regressionn, popupmenus not appearing to work correctly with cntl-click In-Reply-To: References: <526C19D8.2060003@fastmail.fm> <33714D41-2083-4B02-93AD-9B315C162837@tagtraum.com> <526E2EB7.9060504@fastmail.fm> <19E8D1FE-5F02-4498-9443-054080C75E9D@oracle.com> <526F9885.5040109@fastmail.fm> Message-ID: On Thu, Oct 31, 2013 at 12:11 PM, Leonid Romanov wrote: > I see.. While it might pose an inconvenience in some scenarios on OS X, I don't think it's an issue, since Apple JDK 6 behaves the same way, so I'm going to close the bug. yes, I have run into this as well already with Apple's JDK 6 and have yet to see an explanation why it is not a bug there already. In some situations one will have to reorganize code in a hackish way, e.g. when the menu is based on the current selection, when using setComponentPopup() one would have to remove/add menu items in an overridden setVisible method or something like that. From Sergey.Bylokhov at oracle.com Thu Oct 31 06:18:08 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 31 Oct 2013 17:18:08 +0400 Subject: Where Can I Find the Javadocs for Apple Extensions? In-Reply-To: References: <9FE884CB-4264-474C-B24E-5CD0F4F4E7B7@gmail.com> <527123B0.3010105@oracle.com> Message-ID: <52725890.7070203@oracle.com> Hi, Will. You can find your bug here: https://bugs.openjdk.java.net/browse/JI-9007897 On 31.10.2013 0:37, Will Herrmann wrote: > I filed a bug using the link you provided and received an e-mail back saying that it was accepted as bug #9007897. However, when I try to search for it in the bug database, I am told "This bug is not available. More information is available here." Clicking on the word "here" brings me to a blank page. So I'm not sure what I did wrong or if there are internal server problems with the bug database. > > -Will Herrmann > > On Oct 30, 2013, at 10:20 AM, Sergey Bylokhov wrote: > >> Hi, Will. >> I suggest to file a bug for this at http://bugreport.sun.com/bugreport >> >> As a workaround you can generate javadoc ourself from the source code: >> http://hg.openjdk.java.net/jdk8/awt/jdk/file/db2838f25a85/src/macosx/classes/com/apple/eawt >> >> On 30.10.2013 0:41, Will Herrmann wrote: >>> A while back, I'd asked if Java 7 and onwards would continue to include the Apple Extensions (e.g. com.apple.eawt). I was told that they would indeed remain, but I don't think I ever got an answer about where I can find the Javadocs for them. They used to be hosted on Apple's website (at http://bit.ly/1939ShE), but it now results in a Page Not Found error. The OpenJDK site doesn't seem to have them and they're not in the standard Java 7 Javadocs either. Where can I find these Javadocs? >>> Thanks in Advance, >>> -Will Herrmann >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From wjherrmann at gmail.com Thu Oct 31 07:24:10 2013 From: wjherrmann at gmail.com (Will Herrmann) Date: Thu, 31 Oct 2013 09:24:10 -0500 Subject: Where Can I Find the Javadocs for Apple Extensions? In-Reply-To: <52725890.7070203@oracle.com> References: <9FE884CB-4264-474C-B24E-5CD0F4F4E7B7@gmail.com> <527123B0.3010105@oracle.com> <52725890.7070203@oracle.com> Message-ID: <10112AC7-6A7C-4F66-8398-ED98865501CD@gmail.com> I had filed the bug report on bugs.sun.com, but I see that it's now on bugs.openjdk.com, so that may have been part of my confusion. Thanks for providing me with the info and for fixing my bug report. -Will Herrmann On Oct 31, 2013, at 8:18 AM, Sergey Bylokhov wrote: > Hi, Will. > You can find your bug here: > https://bugs.openjdk.java.net/browse/JI-9007897 > > On 31.10.2013 0:37, Will Herrmann wrote: >> I filed a bug using the link you provided and received an e-mail back saying that it was accepted as bug #9007897. However, when I try to search for it in the bug database, I am told "This bug is not available. More information is available here." Clicking on the word "here" brings me to a blank page. So I'm not sure what I did wrong or if there are internal server problems with the bug database. >> >> -Will Herrmann >> >> On Oct 30, 2013, at 10:20 AM, Sergey Bylokhov wrote: >> >>> Hi, Will. >>> I suggest to file a bug for this at http://bugreport.sun.com/bugreport >>> >>> As a workaround you can generate javadoc ourself from the source code: >>> http://hg.openjdk.java.net/jdk8/awt/jdk/file/db2838f25a85/src/macosx/classes/com/apple/eawt >>> >>> On 30.10.2013 0:41, Will Herrmann wrote: >>>> A while back, I'd asked if Java 7 and onwards would continue to include the Apple Extensions (e.g. com.apple.eawt). I was told that they would indeed remain, but I don't think I ever got an answer about where I can find the Javadocs for them. They used to be hosted on Apple's website (at http://bit.ly/1939ShE), but it now results in a Page Not Found error. The OpenJDK site doesn't seem to have them and they're not in the standard Java 7 Javadocs either. Where can I find these Javadocs? >>>> Thanks in Advance, >>>> -Will Herrmann >>> >>> -- >>> Best regards, Sergey. >>> > > > -- > Best regards, Sergey. > From alexandr.scherbatiy at oracle.com Thu Oct 31 09:19:14 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 31 Oct 2013 20:19:14 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays In-Reply-To: <527007AE.6000401@oracle.com> References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com> <526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com> <526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com> Message-ID: <52728302.406@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8011059/webrev.04/ The reflection is used to skip the Image.getScaledInstance() method call if it is not overridden by a user. On 10/29/2013 11:08 PM, Sergey Bylokhov wrote: > Hi, Alexander. > The fix looks fine to me in general. But there is at least one issue. > I build you fix and test it: > - Consuming of cpu increased by 500 times Java2Demo on images tab. > - FPS is dropped from 220(jdk8)/35(jdk7u40) to 15 in guimark2. Note > that jdk6 has the same FPS(15) on my system. The main problem is that the Image.SCALE_DEFAULT hint is used to retrieve a scaled image from Image.getScaledInstance() method. It always uses the ReplicateScaleFilter for images which getScaledInstance() method has not been overridden. The ReplicateScaleFilter creates a lot of arrays and consumes the CPU during the image parsing. The better fix would be to introduce the new Image.SCALE_CUSTOM hint which could be used to get a scaled image and does not use filters by default. But it should be a separated bug with a new CCC request. Thanks, Alexandr. > > On 29.10.2013 20:45, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8011059/webrev.03 >> >> On 10/28/2013 2:33 PM, Artem Ananiev wrote: >>> Hi, Alexander, >>> >>> a few comments: >>> >>> 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here? >> The isHiDPIImage() method is used to check that the >> drawHiDPIImage should be called like: >> if (isHiDPIImage(img)) { >> return drawHiDPIImage(...); >> } >> >>> 2. I'm not sure that the proposed getScaledImageName() >>> implementation in ScalableToolkitImage works perfectly for URLs like >>> this: >>> >>> http://www.exampmle.com/dir/image >>> >>> In this case it will try to find 2x image here: >>> >>> http://www.example at 2x.com/dir/image >>> >>> which doesn't look correct. >> Fixed. Only path part of a URL is converted to path2x. >> >>> 3. RenderingHints spec references Retina or non-Retina displays, >>> which should be removed. >> Fixed. >> >> - devScale is used instead of transform parsing in the >> drawHiDPIImage() method just to not have performance regression more >> than 2 times on HiDPI displays >> - LWCToolkit.ScalableToolkitImage is made public for the fix >> 8024926 [macosx] AquaIcon HiDPI support. >> >> Thanks, >> Alexandr. >> >>> >>> Thanks, >>> >>> Artem >>> >>> On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/ >>>> >>>> - Scaled image width and height are transformed according to the >>>> AffineTransform type. >>>> - ToolkitImage subclass is used to hold @2x image instance. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/ >>>>> >>>>> The JCK failures has been resolved: >>>>> - Some tests tries to draw an image with Integer.MAX_VALUE width >>>>> or height. Passing large values to image.getScaledImage(width, >>>>> height, >>>>> hints). >>>>> leads that an Image filter is not able to create necessary >>>>> arrays. The fix uses the original image if width or height are equal >>>>> to Integer.MAX_VALUE. >>>>> - Using Image.SCALE_DEFAULT hint for the getScaledImage(width, >>>>> height, hints) method to get the high resolution image interferes >>>>> with >>>>> JCK tests that expect that the scaled image by certain >>>>> algorithm is returned. This is fixed by invoking the >>>>> super.getScaledImage(width, height, hints) >>>>> method in ToolkitImage in case if a high resolution image is >>>>> not set. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>> >>>>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8011059 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 >>>>>> >>>>>> The IMAGE_SCALING rendering hint is added to the RenderingHints >>>>>> class. >>>>>> Enabling the image scaling rendering hint forces the SunGraphics2D >>>>>> to use getScaledInstance(width, height, hints) method >>>>>> from Image class with SCALE_DEFAULT hint. >>>>>> >>>>>> By default the image scaling rendering hint is enabled on HiDPI >>>>>> display and disabled for standard displays. >>>>>> >>>>>> User can override the getScaledInstance(width, height, hints) >>>>>> method and return necessary high resolution image >>>>>> according to the given image width and height. >>>>>> >>>>>> For example: >>>>>> --------------------- >>>>>> final Image highResolutionImage = >>>>>> new BufferedImage(2 * WIDTH, 2 * HEIGHT, >>>>>> BufferedImage.TYPE_INT_RGB); >>>>>> Image image = new BufferedImage(WIDTH, HEIGHT, >>>>>> BufferedImage.TYPE_INT_RGB) { >>>>>> >>>>>> @Override >>>>>> public Image getScaledInstance(int width, int height, >>>>>> int >>>>>> hints) { >>>>>> if ((hints & Image.SCALE_DEFAULT) != 0) { >>>>>> return (width <= WIDTH && height <= HEIGHT) >>>>>> ? this : highResolutionImage; >>>>>> } >>>>>> return super.getScaledInstance(width, height, >>>>>> hints); >>>>>> } >>>>>> }; >>>>>> --------------------- >>>>>> >>>>>> The LWCToolkit and ToolkitImage classes are patched to >>>>>> automatically get provided image at 2x.ext images on MacOSX. >>>>>> >>>>>> There are no significant changes in the Java2D demo to make it >>>>>> look >>>>>> perfect on Retina displays. >>>>>> It needs only to put necessary images with the @2x postfix and >>>>>> they >>>>>> will be automatically drawn. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>> >>>> >> > > From paul_t100 at fastmail.fm Thu Oct 31 10:30:36 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 31 Oct 2013 17:30:36 +0000 Subject: How do I make my Java 7 OSX App draggable on toolbar only ? Message-ID: <527293BC.3020308@fastmail.fm> Things were working okay with Java 6 ( and some custom libs) but now by default a Java 7 application is only movable on Mac if you click near the top of the window (like on Windows), however if I set toolbar.getRootPane().putClientProperty("apple.awt.draggableWindowBackground") I can then move the window by dragging on the toolbar. Unfortunately because this property is applied to the rootpane, and then is just one rootpane for the frame that the whole applications is a part of the window moves where-ever I drag on it, I only want to be able to drag on it in the toolbar. The main part of my application is a JTable and I really don't want the window to be moved when I dragclick here because it causes lots of problems such as I can now no longer reorder by table columns by dragging the table headers because that just moves the whole window. How can I limit movement to either: 1. Only the JToolbar 2. Everywhere except the Jtable whichever is easiest. thanks Paul From swingler at apple.com Thu Oct 31 11:38:32 2013 From: swingler at apple.com (Mike Swingler) Date: Thu, 31 Oct 2013 11:38:32 -0700 Subject: Java 7 Application built on OSX 10.9 crashing on startup on 10.7.5 In-Reply-To: <52717C3A.9030404@fastmail.fm> References: <52717C3A.9030404@fastmail.fm> Message-ID: <496DFFF6-9420-4463-AA1C-9AA82D470726@apple.com> Is this the full crash log? Are there no thread stacks? Regards, Mike Swingler Apple Inc. From paul_t100 at fastmail.fm Thu Oct 31 12:28:12 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 31 Oct 2013 19:28:12 +0000 Subject: Java 7 Application built on OSX 10.9 crashing on startup on 10.7.5 In-Reply-To: <496DFFF6-9420-4463-AA1C-9AA82D470726@apple.com> References: <52717C3A.9030404@fastmail.fm> <496DFFF6-9420-4463-AA1C-9AA82D470726@apple.com> Message-ID: <5272AF4C.4030308@fastmail.fm> On 31/10/2013 18:38, Mike Swingler wrote: > Is this the full crash log? Are there no thread stacks? > > Regards, > Mike Swingler > Apple Inc. > Thats all that comes up with the Crash reporter, Ive now tried another application that definitently was working on OSX 10.7 with an earlier version of Java 7 but now crashes in the same way, you can download both, they have both been released because they do work on 10.8 and 10.9 http://www.jthink.net/jaikoz/jsp/manualdownload/jaikoz-osx.dmg?val=125 http://www.jthink.net/songkong/downloads/songkong-osx.dmg?val=15 Paul From mik3hall at gmail.com Thu Oct 31 14:49:15 2013 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 31 Oct 2013 16:49:15 -0500 Subject: Java 7 Application built on OSX 10.9 crashing on startup on 10.7.5 In-Reply-To: <52717C3A.9030404@fastmail.fm> References: <52717C3A.9030404@fastmail.fm> Message-ID: <5F1AEAA7-F082-4877-AAE7-EE05ABBB567C@gmail.com> On Oct 30, 2013, at 4:38 PM, Paul Taylor wrote: > /Applications/Jaikoz.app/Contents/MacOS/Jaikoz I'm assuming this is the appbundler JavaAppLauncher. Which branch? java.net project or infinitekind? Which OS version was it built on? Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From paul_t100 at fastmail.fm Thu Oct 31 17:10:19 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 01 Nov 2013 00:10:19 +0000 Subject: Java 7 Application built on OSX 10.9 crashing on startup on 10.7.5 In-Reply-To: <5F1AEAA7-F082-4877-AAE7-EE05ABBB567C@gmail.com> References: <52717C3A.9030404@fastmail.fm> <5F1AEAA7-F082-4877-AAE7-EE05ABBB567C@gmail.com> Message-ID: <5272F16B.8020500@fastmail.fm> On 31/10/2013 21:49, Michael Hall wrote: > On Oct 30, 2013, at 4:38 PM, Paul Taylor wrote: > >> /Applications/Jaikoz.app/Contents/MacOS/Jaikoz > I'm assuming this is the appbundler JavaAppLauncher. Which branch? java.net project or infinitekind? Which OS version was it built on? Ah, I think you have it. It was the latest version of infinitekind on mavericks, and now I remember change something in the appbundler build file because it couldn't find some 10.7 files, is it possible these files on 10.9 Paul > 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 Thu Oct 31 18:41:49 2013 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 31 Oct 2013 20:41:49 -0500 Subject: Java 7 Application built on OSX 10.9 crashing on startup on 10.7.5 In-Reply-To: <5272F16B.8020500@fastmail.fm> References: <52717C3A.9030404@fastmail.fm> <5F1AEAA7-F082-4877-AAE7-EE05ABBB567C@gmail.com> <5272F16B.8020500@fastmail.fm> Message-ID: On Oct 31, 2013, at 7:10 PM, Paul Taylor wrote: > On 31/10/2013 21:49, Michael Hall wrote: >> On Oct 30, 2013, at 4:38 PM, Paul Taylor wrote: >> >>> /Applications/Jaikoz.app/Contents/MacOS/Jaikoz >> I'm assuming this is the appbundler JavaAppLauncher. Which branch? java.net project or infinitekind? Which OS version was it built on? > Ah, I think you have it. > > It was the latest version of infinitekind on mavericks, and now I remember change something in the appbundler build file because it couldn't find some 10.7 files, is it possible these files on 10.9 is it possible these files are not on 10.9? I would think some incompatibility is possible. You could maybe try building the native executable on 10.7 instead of 10.9. If it works, you have one executable that works for all. Otherwise you might have to resolve the incompatibility. For infinitekind, or both JavaAppLauncher projects, figuring out what the incompatibility is might be appreciated anyhow. 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