Currently Being ModeratedOct 30, 2012 2:31 AM (in response to katzlbt)
Adding High Resolition Capable without Xcode must have done something strange to the plist so I had to restore both apps from TimeMachine, edited the plist with xcode this time, copied the apps to refresh the plists, and it seems to work finally.
Just for curiosity, I made a diff between the old plists and the new ones, but I do not see any difference in the new plists that should warrant malfunction like that. Hmmm.
Currently Being ModeratedOct 30, 2012 2:45 AM (in response to katzlbt)
I reinstalled a new jEdit stable V4.5.2 and the problem started again. The plists of the new bad and old working versions of jEdit are identical, except for version information.
< <string>jEdit 4.3.2, Copyright © 1998-2010 Contributors</string>
> <string>jEdit 4.5.2, Copyright © 1998-2012 Contributors</string>
< <key>VMOptions</key> < <string>-Xmx192M</string>
Currently Being ModeratedJan 23, 2013 8:39 AM (in response to katzlbt)
I've had the same issue with not being able to run Freemind (1.0.0_beta9) and jEdit 5.0 at the same time on OS X 10.8. Once one is running it trying to start the other just brings the first one to the front.
However, if I start one from a disk image I can run both. The plist on the disk image and the one in the application folder(s) are identical.
Trying to start one from a terminal with "open" results in the same behavior.
Starting Freemind as the second application by directly executing the JavaApplicationStub from a terminal does work.
Not exactly an elegant work around, but it will have to do until I can take a break and do some more debugging. Or someone else provides and answer.
Currently Being ModeratedJun 5, 2013 2:04 PM (in response to gary_s)
I think I have the answer to this particular issue.
Take a look at the actual executable in the MacOS folder of the app bundles for the affected applications. If they are both symlinks to /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaAppl icationStub, then you need to replace the symlink with a copy of the executable it links to.
The reason this is a problem is that the core services database (when it's seeded) caches an exec inode for the executable. Since both these Java apps symlink to the same executable, they get the same exec inode. So if one is running, and you try to launch the other, Mac OS X thinks the app is already running.
Another solution to this problem might be to try opening the app in a terminal window using both -n -a "<App name>" - this forces the OS to start a 'new' copy of the app.
Hope this helps anyone else that has this problem...
PS: You can rebuild the core services database by following the instructions here . Also, use the -dump option to get a full dump of the database itself.