On Sep 7, 2008, at 1:08 PM, Michael Franz wrote:

This is because OpenJDK7 does not have a Cocoa-based AWT that must start on thread 0 to receive events from the OS. If you simply remove the -XstartOnFirstThread argument, or apply a patch to OpenJDK (which I believe SoyLatte did) to ignore this "VM flag", everything should start fine.

I changed the startup to not pass the flag. I was running this from inside eclipse, but eclipse must somehow pass the option as it did not show up in the command.

I am now getting an unsatisfiedlinkerror.

When I run from the command line using the Apple 1.5 JVM and then using the OpenJDK. The Apple version works. The OpenJDK produces: Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt- cocoa-3448 or swt-cocoa in swt.library.path, java.library.path or the jar file at org.eclipse.swt.internal.Library.loadLibrary(Library.java:233) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:151) at org.eclipse.swt.internal.C.<clinit>(C.java:21) at org.eclipse.swt.widgets.Display.createDisplay(Display.java:620) at org.eclipse.swt.widgets.Display.create(Display.java:613) at org.eclipse.swt.graphics.Device.<init>(Device.java:113) at org.eclipse.swt.widgets.Display.<init>(Display.java:536) at org.eclipse.swt.widgets.Display.<init>(Display.java:527) at org .eclipse .swt.examples.controlexample.ControlExample.main(ControlExample.java: 202)

The command I execute

/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/ java -Djava.library.path=/Users/mfranz/Documents/eclipse-3.4/ workspace/org.eclipse.swt.cocoa.macosx -Dfile.encoding=MacRoman - classpath /Users/mfranz/Documents/eclipse-3.4/workspace/ org.eclipse.swt.examples/bin:/Users/mfranz/Documents/eclipse-3.4/ workspace/org.eclipse.swt/bin:/Users/mfranz/Documents/eclipse-3.4/ workspace/org.eclipse.swt/extra_jars/exceptions.jar:/Applications/ eclipse-3.4/plugins/org.eclipse.swt.carbon.macosx_3.4.0.v3448f.jar org.eclipse.swt.examples.controlexample.ControlExample

/Users/mfranz/developer/openjdk-bsd/openjdk7-darwin-i386-20080820/ bin/java -Djava.library.path=/Users/mfranz/Documents/eclipse-3.4/ workspace/org.eclipse.swt.cocoa.macosx -Dfile.encoding=MacRoman - classpath /Users/mfranz/Documents/eclipse-3.4/workspace/ org.eclipse.swt.examples/bin:/Users/mfranz/Documents/eclipse-3.4/ workspace/org.eclipse.swt/bin:/Users/mfranz/Documents/eclipse-3.4/ workspace/org.eclipse.swt/extra_jars/exceptions.jar:/Applications/ eclipse-3.4/plugins/org.eclipse.swt.carbon.macosx_3.4.0.v3448f.jar org.eclipse.swt.examples.controlexample.ControlExample

Sounds like OpenJDK is not recognizing .jnilib files as valid native libraries. Another patch to SoyLatte also allowed it to recognize both .dylib and .jnilib. We also made changes to Java in Mac OS X 10.5 Leopard to recognize .dylib as well as .jnilib. I know it's sounds super-hacky, but I bet if you renamed all your .jnilib's to .dylib's, it will probably work. Best of luck, Mike Swingler Java Runtime Engineer Apple Inc.

Hi, Do any other platforms support multiple dynamically load library extensions? I was thinking that the JNI_LIB_SUFFIX could be defined as a space (or comma) delimited list of extensions and then change Java_java_lang_System_mapLibraryName in jdk/src/share/native/java/lang/System.c to be able to handle the parsing of the JNI_LIB_SUFFIX string. The order in the list would specify the search order. Thoughts? Michael

Sounds like OpenJDK is not recognizing .jnilib files as valid native libraries. Another patch to SoyLatte also allowed it to recognize both .dylib and .jnilib. We also made changes to Java in Mac OS X 10.5 Leopard to recognize .dylib as well as .jnilib.

I know it's sounds super-hacky, but I bet if you renamed all your .jnilib's to .dylib's, it will probably work.

Best of luck, Mike Swingler Java Runtime Engineer Apple Inc.

On Sep 7, 2008, at 1:08 PM, Michael Franz wrote:

I changed the startup to not pass the flag. I was running this from inside eclipse, but eclipse must somehow pass the option as it did not show up in the command.

There are two small patches from SoyLatte that need to be re- implemented for OpenJDK, both of which you have run into: -XstartOnFirstThread: Soylatte by starts a Cocoa runloop on the first thread, and then run the JVM main() function again on a separate thread Setting -XstartOnFirstThread has the same behavior on Mac OS X, in that Java is started directly on the first thread. dylib vs. jnilib (your current issue): Soylatte first searched for dylib, then fell back to jnilib. OpenJDK only searches for .dylib, with no fallback. Apologies for radio silence on my part, I've been nose down on an iPhone development contract these past two weeks. -landonf

For the -XstartOnFirstThread patch, was files are relevant for the change? I started to look at src/os/bsd/launcher/java_md.c but not sure that is the correct place Michael On Sun, Sep 7, 2008 at 9:22 PM, Landon Fuller <landonf@plausiblelabs.com>wrote:

On Sep 7, 2008, at 1:08 PM, Michael Franz wrote:

I changed the startup to not pass the flag. I was running this from

...

inside eclipse, but eclipse must somehow pass the option as it did not show up in the command.

There are two small patches from SoyLatte that need to be re-implemented for OpenJDK, both of which you have run into:

-XstartOnFirstThread:

Soylatte by starts a Cocoa runloop on the first thread, and then run the JVM main() function again on a separate thread Setting -XstartOnFirstThread has the same behavior on Mac OS X, in that Java is started directly on the first thread.

dylib vs. jnilib (your current issue):

Soylatte first searched for dylib, then fell back to jnilib. OpenJDK only searches for .dylib, with no fallback.

Apologies for radio silence on my part, I've been nose down on an iPhone development contract these past two weeks.

-landonf

On Oct 11, 2008, at 6:14 PM, Michael Franz wrote:

Hi,

On Sun, Sep 7, 2008 at 9:22 PM, Landon Fuller <landonf@plausiblelabs.com

...

wrote:

On Sep 7, 2008, at 1:08 PM, Michael Franz wrote:

I changed the startup to not pass the flag. I was running this from inside eclipse, but eclipse must somehow pass the option as it did not show up in the command.

There are two small patches from SoyLatte that need to be re- implemented for OpenJDK, both of which you have run into:

-XstartOnFirstThread:

Soylatte by starts a Cocoa runloop on the first thread, and then run the JVM main() function again on a separate thread Setting -XstartOnFirstThread has the same behavior on Mac OS X, in that Java is started directly on the first thread.

Reading through the code and finding a few bugs on primordial threads and this blog entry[1] , I wonder if -XstartOnFirstThread is really OS X specific (I assumed it was).

I was also reading through the Cocoa reference I have, my understanding is that it is possible to create a runloop on other threads, not just the first thread.

You can create runloops on other threads, but their sources will be setup by you. Only the runloop on Thread 0 receives keyboard and mouse events, which is why -XstartOnFirstThread is necessary when user-space code wants to pump the event loop. Otherwise, Thread 0 needs to be parked until it's time for the AWT to startup, and start running the show. Cheers, Mike Swingler Java Runtime Engineer Apple Inc.

On Oct 12, 2008, at 12:26 PM, Michael Franz wrote:

On Sun, Oct 12, 2008 at 11:21 AM, Mike Swingler <swingler@apple.com> wrote:

On Oct 11, 2008, at 6:14 PM, Michael Franz wrote:

...

Hi,

On Sun, Sep 7, 2008 at 9:22 PM, Landon Fuller <landonf@plausiblelabs.com

...

wrote:

On Sep 7, 2008, at 1:08 PM, Michael Franz wrote:

I changed the startup to not pass the flag. I was running this from inside eclipse, but eclipse must somehow pass the option as it did not show up in the command.

There are two small patches from SoyLatte that need to be re- implemented for OpenJDK, both of which you have run into:

-XstartOnFirstThread:

Soylatte by starts a Cocoa runloop on the first thread, and then run the JVM main() function again on a separate thread Setting -XstartOnFirstThread has the same behavior on Mac OS X, in that Java is started directly on the first thread.

Reading through the code and finding a few bugs on primordial threads and this blog entry[1] , I wonder if -XstartOnFirstThread is really OS X specific (I assumed it was).

I was also reading through the Cocoa reference I have, my understanding is that it is possible to create a runloop on other threads, not just the first thread.

You can create runloops on other threads, but their sources will be setup by you. Only the runloop on Thread 0 receives keyboard and mouse events, which is why -XstartOnFirstThread is necessary when user-space code wants to pump the event loop. Otherwise, Thread 0 needs to be parked until it's time for the AWT to startup, and start running the show.

Is it possible to find Thread 0 from other threads?

I'm not sure what you mean by "find"? Like, with the pthread API? Once a runloop is pumping on it, most other API can deliver work to it via - performSelectorOnMainThread:, or other CFRunLoop API - but if user- space code never starts a runloop on Thread 0, those API's in AppKit, Carbon, etc will not work. Mike Swingler Java Runtime Engineer Apple Inc.

On Oct 12, 2008, at 2:25 PM, Michael Franz wrote:

On Sun, Oct 12, 2008 at 3:38 PM, Mike Swingler <swingler@apple.com> wrote:

On Oct 12, 2008, at 12:26 PM, Michael Franz wrote:

...

On Sun, Oct 12, 2008 at 11:21 AM, Mike Swingler <swingler@apple.com> wrote:

On Oct 11, 2008, at 6:14 PM, Michael Franz wrote:

...

Hi,

On Sun, Sep 7, 2008 at 9:22 PM, Landon Fuller <landonf@plausiblelabs.com

...

wrote:

On Sep 7, 2008, at 1:08 PM, Michael Franz wrote:

I changed the startup to not pass the flag. I was running this from inside eclipse, but eclipse must somehow pass the option as it did not show up in the command.

There are two small patches from SoyLatte that need to be re- implemented for OpenJDK, both of which you have run into:

-XstartOnFirstThread:

Soylatte by starts a Cocoa runloop on the first thread, and then run the JVM main() function again on a separate thread Setting -XstartOnFirstThread has the same behavior on Mac OS X, in that Java is started directly on the first thread.

Reading through the code and finding a few bugs on primordial threads and this blog entry[1] , I wonder if -XstartOnFirstThread is really OS X specific (I assumed it was).

I was also reading through the Cocoa reference I have, my understanding is that it is possible to create a runloop on other threads, not just the first thread.

You can create runloops on other threads, but their sources will be setup by you. Only the runloop on Thread 0 receives keyboard and mouse events, which is why -XstartOnFirstThread is necessary when user-space code wants to pump the event loop. Otherwise, Thread 0 needs to be parked until it's time for the AWT to startup, and start running the show.

Is it possible to find Thread 0 from other threads?

I'm not sure what you mean by "find"? Like, with the pthread API? Once a runloop is pumping on it, most other API can deliver work to it via -performSelectorOnMainThread:, or other CFRunLoop API - but if user-space code never starts a runloop on Thread 0, those API's in AppKit, Carbon, etc will not work.

What I meant, is can thread 1 find thread 0 where find is obtain a reference to it. That is probably not necessary as you state work can be assigned to thread 0 from other threads.

What I see the current startup logic doing is creating the JVM in a new thread and waiting for that thread to die. If we need thread 0 to create the runloop, how does it know when the JVM has exited? I was thinking that maybe the jvm creation thread could send a message to the runloop that when it finishes. This would mean that there would be no need to -XstartOnFirstThread as thread 0 would always create the runloop.

Perhaps the SWT guys could chime in here, since their plans might be changing for SWT/Cocoa, but for the current implementation, the SWT main() has to be run on Thread 0. As I understand the architecture, they don't actually create a permanent runloop, but rather pump events themselves. Since Thread 0 is the only place these events get delivered, their main() has a hard requirement to be run on Thread 0, at least on the Mac. When we know the AWT is running the show, we do send a shutdown message to the Cocoa runloop when JVM has detected it is exiting naturally. Since SWT controls their own lifecycle we know not to shutdown the runloop from under them (which is just like the embedded case, like plugins inside say, Safari). Cheers, Mike Swingler Java Runtime Engineer Apple Inc.

On Oct 27, 2008, at 6:43 PM, Michael Franz wrote:

Mike,

If the runloop is running on Thread 0, can a thread that is not thread 0 pull events off the runloop by using NSApplication.sharedApplication(). nextEventMatchingMask() ? Where events are the keyboard and mouse events.

Sorry, nope. I'm pretty sure this method has been tried by the SWT folks.

How does one 'park' thread 0?

pthread_mutex_lock()/pthread_cond_wait()/pthread_cond_signal(). When we load the AWT, we simply signal Thread 0, to continue and start pumping the event loop. If the AWT never comes up, the thread stays parked indefinitely. This is actually just a modification to how the JVM starts when you request a custom thread stack size for the main thread.

Michael

On Sun, Oct 12, 2008 at 11:21 AM, Mike Swingler <swingler@apple.com> wrote:

You can create runloops on other threads, but their sources will be setup by you. Only the runloop on Thread 0 receives keyboard and mouse events, which is why -XstartOnFirstThread is necessary when user-space code wants to pump the event loop. Otherwise, Thread 0 needs to be parked until it's time for the AWT to startup, and start running the show.

Cheers, Mike Swingler Java Runtime Engineer Apple Inc.