Monday, April 23, 2007

Equinox launcher & Swing

The equinox launcher starts the Java VM using the JNI invocation API. Because we are such good friends with SWT (and also because it is easier) the VM was always started on the first thread. This turns out not to be so good when you want to run Swing on the Mac. There was a conversation about it over on EclipseZone.

So I fixed the bug (181698) today by adding a new option to the launcher "--launcher.secondThread". Use it if you want swing to work. This option can be compared to the -XstartOnFirstThread for the java launcher.

4 comments:

Saxon said...

I'm using the Eclipse 3.3.1 IDE with a 3.3.1 target platform. If I add the --launcher.secondThread as an argument to my application launcher it gets passed straight through to my application, unlike the other eclipse options like -debug or -consoleLog, and my application still hangs. Can this flag be used when launching Swing RCP applications through the Eclipse IDE?

Unknown said...

The --launcher.second thread argument applies only to the eclipse launcher. When you are launching from within the IDE the java launcher is used instead, so this argument has no affect. See bug 186464 and bug 133072.

The -ws argument implicitly adds a -XstartOnFirstThread when launching from the IDE. Things should work better if you remove that.

Nikhil said...

hi andrew ,
I am using equinox launcher to launch my eclipse application ,
for some reason I am using
osgi.instance.area.default=@user.home/appdata

coz the data at
user.home/appdata will be used by one of my another application ...
the thing is , my first application is installed as a windows service using wrapper , and it creates a appdata directory on c:\ of my hard drive and not on osgi.instance.area.default=@user.home/appdataall i need is a way in which i can configure my application so that it creates a directory structure at osgi.instance.area.default=@user.home/appdata

Unknown said...

@user.home is translated using the java system property "user.home" which should be set by the vm. Perhaps when you run as a windows service this property is not set? I don't know if services run as any particular user.