Community
Participate
Working Groups
Preferences->Workbench->Fonts->Change... correctly brings up a font selection menu, but selecting the new font and closing the selection window causes Eclipse to hang. Eclipse 2.1 M4 / Mac OS 10.2.3 / JVM 1.4.1DP8
Adding Chris McLaren as he has seen similar issues.
indeed. i didn't spend much time on reproducing, but i can tell you it hung on I20020115 / OS 10.2.3 / JVM 1.4.1DP8. also, that i moved back to JVM 1.3.1 and it worked correctly. (SWT vs. 1.4.1 may be the problem here.)
This is a known problem in 1.4.1: Cocoa based dialogs don't work in 1.4.1 (which is very strange, because we don't use (or import) any of the Cocoa work Apple did for 1.4.1). BTW the color dialog has the same problem. I've filed a bug for this against Apple. BTW: we should not enter 1.4.1 related issues into Bugzilla because the NDA does not allow this. Please discuss these issues on the java.seed mailing list. Reassigned to SWT
Andre, this is yours to do with what you want. Hope you can get Apple to fix this. Thanks.
Changed to P3 since I'm not able to fix that for 2.1. (and Apple hasn't released an official JVM 1.4.1).
*** Bug 31961 has been marked as a duplicate of this bug. ***
*** Bug 28647 has been marked as a duplicate of this bug. ***
Not likely to get this fixed for 2.1. May be we need a workaround if running on 1.4.1 (or at least disable it).
I think we could disable the dialog for 1.4.1 although we have never done this in the past. Since this is a bug in the VM, what we have done in the past is enter a bug report against the VM which we reference in the bug report and close the bug report as WONTFIX.
*** Bug 32692 has been marked as a duplicate of this bug. ***
Andre, what priority does this bug have with Sun/Apple? We can create a C example that shows the problem if this would help increse the priority. I can change the dialog to pop up an error dialog instead for JDK 1.4.1. We should decide how we wish to handle this.
I don't know the "priority" of the bug report I filed with Apple. However its severity is "Serious Bug". I will check with Apple what the status is. I think its not very important for 2.1 because Eclipse is configured to use 1.3.1 even if 1.4.1 is available. So the problem occurs only if you are running a SWT application that explicitely uses 1.4.1. I suggest to show an error dialog on JVM 1.4.1.
This bug was originally noticed because the fonts on Eclipse 2.1 on Mac appeared to be significantly larger than 2.0 -- a little too large, in any event. Perhaps if font changing will not be an option then a double-check on the default sizes might be in order.
Just to make this clear: the Color and Font dialog will work in Eclipse 2.1 even if you have the (not officially released) JVM 1.4.1 installed. They will stop working (and deadlock Eclipse) if you change the (normally invisible) Info.plist file within the Eclipse application bundle and explicitely switch the JVM to 1.4.1. However, we do not recommend to run Eclipse on 1.4.1.
I think we should just leave this PR open. If we put in an error dialog for 1.4.1, it could still be broken or fixed in 1.4.2. Since there is no way of knowing, we would show the error dialog for ever and never get the fix.
In particular, the bug may yet be fixed for the officially released 1.4.1 version.
I suggest we just add this info to the Eclipse ReadMe then.
I finally had to switch to 1.4.1 as my build environment, which also forced an upgrade to 2.1 (from M4), and I confirmed that this bug is still present. It's a problem that you can't change the fonts, but the more immediate problem is that the default text editing font is Geneva, a non-monospaced font, which on the Mac results in the cursor not being lined up with where the editing is taking place. (Probably a separate bug) It can be as much as two character widths away from where the next character would be inserted. Workaround suggestions: (1) Monaco is probably a better choice for the default font -- being monospaced it won't have the cursor positioning problem. (2) If there is a config file somewhere where the font options are saved, it would be nice to have it mentioned in the readme file beside the bug notification so people can go under the hood if they really need to change the font. As it is I changed the Info.plist entry to start up under 1.3.1 again long enough to make the font change, then restarted back into 1.4.1.
The only reason for running Eclipse on 1.4.1 is if you need 1.4.1 features from within Ant scripts. Does this apply to you? If not, please consider running Eclipse on 1.3.1. You still can develop for 1.4.1 even if Eclipse runs on 1.3.1.
I assume you knew this already, but perhaps it's helpful to somebody: There is System.err output when opening the color dialog with 1.4.1, just before the dialog hangs: 2003-06-08 19:45:43.240 JavaApplicationStub[641] *** _NSAutoreleaseNoPool(): Obj ect 0x73ef830 of class NSCFArray autoreleased with no pool in place - just leaki ng 2003-06-08 19:45:44.300 JavaApplicationStub[641] *** _NSAutoreleaseNoPool(): Obj ect 0xa3086460 of class NSCFString autoreleased with no pool in place - just lea king (Runtime Workbench on 3.0 M1 configured for Java 1.4)
I get some additional errors when running under the I20030611 Integration build of Eclipse 3.0 (using JDK 1.4.1), which might help some more. They are: 2003-06-11 13:13:04.880 JavaApplicationStub[1058] *** _NSAutoreleaseNoPool(): Object 0x14996490 of class NSCFArray autoreleased with no pool in place - just leaking 2003-06-11 13:13:05.292 JavaApplicationStub[1058] An uncaught exception was raised 2003-06-11 13:13:05.295 JavaApplicationStub[1058] *** -[NSCFArray objectAtIndex:]: index (1) beyond bounds (1) 2003-06-11 13:13:05.296 JavaApplicationStub[1058] *** Uncaught exception: < NSRangeException> *** -[NSCFArray objectAtIndex:]: index (1) beyond bounds (1)
OK, I know what the problem is and how to avoid it in the first place. A fix is underway...
That's great news! Can we help?
No, but thanks for your offer. The trick is to launch the Java VM in the "Main thread". So I had to write a "/usr/bin/java" replacement. An new JDT launcher that uses this replacement is already used in the nightly builds (and will be in tomorrows integration build). It is used whenever you launch applications from within Eclipse under Java 1.4.1. (I will try to get this launcher into the platform-launcher, too) A more detailled problem descriptions will follow soon.
That's good news and may also improve performance. It's possible that Apple expects the main thread to be the GUI thread and gives it more cycles. Just guessing here. Will we need to update the FAQ about running SWT stand alone?
Yes, we'll have to update the FAQ about running SWT stand alone. The good thing is that any SWT application now can be started from the command line (by means of java_swt instead of /usr/bin/java). On the other hand, since creating an application bundle in /tmp is no longer a side effect of launching a SWT application from within Eclipse, setting up a double clickable application requires more work. I'm planning to write an Eclipse plugin for this (in fact, the code is already there; just the UI is missing).
BTW: nightly build N20030708 contains my latest code (and works for me). If you want to give it a try, just replace the "1.3.1" in the Info.plist file with a "1.4.1". With this Color and Font dialogs work. In addition, this version runs on Panther (and is pretty fast).
Right, I'll try it. In the mean time, is this PR fixed? Do you want to update the FAQ?
Andre, Let me know when the double-clickable app plugin is ready to try. Also, can you send me a bit more details about running SWT apps on the mac using java_swt? It would be good to put this in the SWT book that Steve and I are working on.
I will close this PR if my fix works for more users than just me. So I will wait at least for a working integration build. [Remember, the fix is only activated if you edit the Info.plist file and change the VM to a path that contains a "1.4.1" ] Yes, I will update the FAQ as soon as I know what the "current story" is.
I've downloaded the nightly build, and made the changes to the Info.plist file. I'm developing a plugin, and now when I try to run it, the new perspective that is in my plugin is not available. Is this a consequence of the new launcher?
No, I don't think so. The fix for this bug didn't touch any Java code.
BTW, I would recommend to use I20030710 instead of the nightly build.
I have confirmed that it now works for me. Thanks for the fix!
Seems to work. Will be in M2. Any productization of java_swt will be done for M3 (see bug #40003)
Here is the story why SWT application needs a special launcher on MacOS X. [I posted this on the SWT mailing list]: The problem is neither SWT nor Eclipse, it's /usr/bin/java (and its bundle cousin "JavaApplicationStub"; the JavaApplicationStub extracts the arguments from the Info.plist file instead of from the command line). /usr/bin/java (and JavaApplicationStub) starts the Java VM in the second thread because it runs an event loop in the first thread (the "Main" thread), and assumes that the Java code (in any thread) behind the scene communicates with the event loop in the Main thread. But this assumption breaks with SWT because it uses code (Carbon and Cocoa natives) that normally runs in the main thread and knows nothing about the fact that another event loop is already running. [BTW, I will file a Radar bug against this behavior of /usr/bin/java since it prevents running Java code in the "main" thread] So the only fix for this is a replacement for /usr/bin/java (and the "JavaApplicationStub") that runs no additional event loop in the main thread but starts the Java VM there. This is java_swt. OK, this was the theory. Some caveats: - for Java 1.3.1 "JavaApplicationStub" contained some workarounds to avoid the deadlocks, so with it Eclipse would run without problems as long as started from the bundle (via JavaApplicationStub ) and not from /usr/bin/java. (that's the reason why the launcher always creates a bundle on the fly instead of using /usr/bin/java) - after installing any version of 1.4.1, the "JavaApplicationStub" was replaced with a version without the workaround (for all VM versions including 1.3.1 !). As a consequence, I had to adapt Eclipse's MacOS X launcher (org.eclipse.jdt.launching.macosx) to continue using the old version of the "JavaApplicationStub" (by shipping a copy of it). - this copy no longer seems to work under Panther. That's the reason why launching Eclipse under 1.3.1 on Panther fails. I haven't tried to find the cause of this, because Panther is scheduled for the end of this year, with 1.4.1 as default VM, and Eclipse will switch to 1.4.1 in September. So there is probably not a great need for running Eclipse on 1.3.1 on Panther. - my new Java VM launcher "java_swt" is only activated if a 1.4.1 VM is selected in the Info.plist file. Otherwise, the old 1.3.1 code is used. This is done because I didn't want to fix something (1.3.1) that wasn't broken in Jaguar. (However, in Panther it is broken...) - I understand that it would make sense to run SWT applications (which don't require 1.4.1) on Panther and a 1.3.1 VM. I believe that my fix (the java_swt launcher) will work under 1.3.1 too. I just have to find the time to verify it.
