[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Eclipse3.0 M1 on MacOS X Panther DP
|
Thanks for all this good information. Can you paste it into the JDK 1.4
hangs PR? Thanks.
|---------+---------------------------------->
| | Andre Weinand |
| | <weinand@xxxxxxx> |
| | Sent by: |
| | platform-swt-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 07/16/2003 01:14 PM |
| | Please respond to |
| | platform-swt-dev |
| | |
|---------+---------------------------------->
>---------------------------------------------------------------------------------------------------------------------------|
| |
| To: platform-swt-dev@xxxxxxxxxxx |
| cc: |
| Subject: Re: [platform-swt-dev] Eclipse3.0 M1 on MacOS X Panther DP |
| |
>---------------------------------------------------------------------------------------------------------------------------|
Steve,
>Andre, is the problem in SWT or Eclipse? Is there something we need to do
>to run 1.3.1 on Panther?
No, 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.
--andre
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
