To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=92926


User sb changed the following:

                What    |Old value                 |New value
================================================================================
                      CC|'cloph,ericb,fs,kso,macpor|'cd,cloph,ericb,fs,kso,mac
                        |t,ronyf,ssa,wijngaarde'   |port,pl,ronyf,sb,ssa,wijng
                        |                          |aarde'
--------------------------------------------------------------------------------




------- Additional comments from [email protected] Thu Feb 17 15:25:47 +0000 
2011 -------
I think I now understand what happens, more or less.  The "Apple AWT Java VM was
loaded on first thread -- can't start AWT." message appears to be a red herring.
 What is relevant is apparently not the thread on which the VM was created (via
JNI_CreateJavaVM), but rather the thread on which any Java AWT/Swing
functionality is actually triggered.  This interpretation would be in line with
what <http://developer.apple.com/library/mac/#technotes/tn2005/tn2147.html> "JNI
Development on Mac OS X - Thread-Safe JNI Programming - Calling AWT/Swing From
AppKit" says---the AppKit thread (i.e., the OOo main thread) must call AWT/Swing
only asynchronously (e.g., via javax.swing.SwingUtilities.inovkeLater).

As a proof of concept, the attached SvxScriptOrgDialog.patch (against
DEV300_m100) modifies the "Tools - Macros - Organize Macros - BeanShell... -
Edit" button so that it does its work asynchronously in a new thread, instead of
synchronously on the OOo main thread (i.e., the AppKit thread).  With the patch
applied, at least with a DEV300_m100 unxmacxi non-pro OOo and Java 1.5.0_26 on
Mac OS X 10.5.8, the editor window appears.

The java_seperate_thread.diff patch appears not to be necessary after all.  Also
note that that patch is not correct, as the code in
stoc/source/javavm/javavm.cxx expects the JNIEnv* returned from jfw_startVM to
be attached to the current thread, which it no longer would be.

In the above proof of concept, it was easy to asynchronously offload the "edit"
code to a new thread (as the surrounding code does not expect any response back
from the "edit" code, anyway, and lets it progress in parallel).  However, I do
not think that it is possible to automatically offload from the OOo main thread
all work that might involve Java AWT/Swing functionality (maybe cd or pl can
give input here).  I think this rather needs to be seen the other way around: 
Java code executed in OOo cannot make assumptions about the thread it is running
on; thus, to work cross platform (incl. Mac OS X), this code must assume that it
might run on the AppKit thread and take the necessary measures when calling
AWT/Swing (e.g., via invokeLater).

---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to