Can't get SWT Display on Mac OS X

I'm running Mac OS X Snow Leopard and wan't to access the Display from the activator in an OSGi bundle.

Below is the start method for my activator:

@Override
public void start(BundleContext context) throws Exception {
    ExecutorService service = Executors.newSingleThreadExecutor();
    service.execute(new Runnable() {

        @Override
        public void run() {
            Display display = Display.getDefault();
            Shell shell = new Shell(display);
            Text helloText = new Text(shell, SWT.CENTER);
            helloText.setText("Hello SWT!");
            helloText.pack();
            shell.pack();
            shell.open();
            while (!shell.isDisposed()) {
                if (!display.readAndDispatch())
                    display.sleep();
            }
            display.dispose();
        }
    });
}

Calling this code in a Windows environment works fine, but deploying on Mac OS X I get the following output:

2009-10-14 17:17:54.050 java[2010:10003] *** __NSAutoreleaseNoPool(): Object 0x101620d20 of class NSCFString autoreleased with no pool in place - just leaking
2009-10-14 17:17:54.081 java[2010:10003] *** __NSAutoreleaseNoPool(): Object 0x100119240 of clas开发者_如何学运维s NSCFNumber autoreleased with no pool in place - just leaking
2009-10-14 17:17:54.084 java[2010:10003] *** __NSAutoreleaseNoPool(): Object 0x1001024b0 of class NSCFString autoreleased with no pool in place - just leaking
2009-10-14 17:17:54.086 java[2010:10003] *** __NSAutoreleaseNoPool(): Object 0x7fff701d7f70 of class NSCFString autoreleased with no pool in place - just leaking
2009-10-14 17:17:54.087 java[2010:10003] *** __NSAutoreleaseNoPool(): Object 0x100113330 of class NSCFString autoreleased with no pool in place - just leaking
2009-10-14 17:17:54.092 java[2010:10003] *** __NSAutoreleaseNoPool(): Object 0x101624540 of class NSCFData autoreleased with no pool in place - just leaking
.
.
.

I've used the -XstartOnFirstThread VM argument without any luck. I'm on 64-bit Cocoa but I've also tried 32-bit Cocoa.

When trying on Carbon I get the following error:

Invalid memory access of location 00000020 eip=9012337c

When debugging into the Display class I can see that the Displays[] array only contains null references.

I can confirm that we successfully run SWT Carbon on Mac OS X in its own event loop kicked off by a bundle activation, so it's definitely possible! This is using -XstartOnFirstThread when launching the VM.

But, with Cocoa SWT (64-bit), I see the same error :(

It seems that, although the way we ran Carbon SWT worked, it was probably not kosher: we were driving the event loop through another thread, not the main one as you're supposed to. Under Cocoa SWT, this doesn't work any more, and it was probably dodgy practice anyway.

I can fix the thread pool errors with the following hack before creating the Display (adapted from the Cocoa SWT Device constructor):

  NSAutoreleasePool pool = (NSAutoreleasePool) new NSAutoreleasePool().alloc().init();
  NSThread nsthread = NSThread.currentThread();
  NSMutableDictionary dictionary = nsthread.threadDictionary();
  NSString key = NSString.stringWith("SWT_NSAutoreleasePool");
  id obj = dictionary.objectForKey(key);
  if (obj == null) {
          NSNumber nsnumber = NSNumber.numberWithInteger(pool.id);
          dictionary.setObject(nsnumber, key);
  } else {
          pool.release();
  }

However, the event loop that follows hangs (i.e. the display.readAndDispatch ()/display.sleep () dance). I suspect it's just not reading UI events due not being the main thread.

I'm not sure if there's a kosher way to fix this. In my case, we control the main JVM thread that launches OSGi, so I'm toying with the idea of adding a hook in there that can run the SWT event loop after OSGi launch.

I had the problem that as soon as "display.sleep()" was called the Window freezed the application. If somebody else hace the same problem, the solution that worked for me was to add: -XstartOnFirstThread to the VM at the moment of the execution.

I was trying to make Areca Backup software work on my Mac, and know its working :)

My system is: MacOsX Snow Leopard 10.6.2

Bye, Daniel W.

I had the same issue and resolved it by adding both -d32 and -XstartOnFirstThread

This code looks very strange... is this supposed to be an Eclipse plugin? What are you trying to do? I'll guess that you are trying to create an RCP plugin with a User Interface. If so, here's the answer: Don't do that. Your OSGi Activator is not be responsible for creating the SWT display event loop.

Create an application extension in your plugin.xml to declaratively create the SWT bootstrap. It will look something like this:

   <extension
         id="application"
         point="org.eclipse.core.runtime.applications">
      <application>
         <run
               class="com.yourcompany.foo.Application">
         </run>
      </application>
   </extension>

Then create the Application class (call it whatever you want) to look something like this:

public class Application implements IApplication {

    /* (non-Javadoc)
     * @see org.eclipse.equinox.app.IApplication#start(org.eclipse.equinox.app.IApplicationContext)
     */
    public Object start(IApplicationContext context) {
        Display display = PlatformUI.createDisplay();
        try {
            int returnCode = PlatformUI.createAndRunWorkbench(display, new ApplicationWorkbenchAdvisor());
            if (returnCode == PlatformUI.RETURN_RESTART) {
                return IApplication.EXIT_RESTART;
            }
            return IApplication.EXIT_OK;
        } finally {
            display.dispose();
        }
    }

    /* (non-Javadoc)
     * @see org.eclipse.equinox.app.IApplication#stop()
     */
    public void stop() {
        final IWorkbench workbench = PlatformUI.getWorkbench();
        if (workbench == null)
            return;
        final Display display = workbench.getDisplay();
        display.syncExec(new Runnable() {
            public void run() {
                if (!display.isDisposed())
                    workbench.close();
            }
        });
    }
}

Obviously make sure you have the SWT plugins (org.eclipse.ui) available in your Manifest as well as the runtime.

I hope that helps.