Issue 92926 - Java AWT doesn't work (can't start)
Summary: Java AWT doesn't work (can't start)
Alias: None
Product: porting
Classification: Code
Component: MacOSX (show other issues)
Version: OOo 3.0 Beta 2
Hardware: All Mac OS X, all
: P2 Trivial with 14 votes (vote)
Target Milestone: 3.4.1
QA Contact: issues@porting
Keywords: oooqa
: 93076 98979 102106 (view as issue list)
Depends on:
Reported: 2008-08-19 20:43 UTC by jimwhite
Modified: 2011-03-31 11:53 UTC (History)
13 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

move JVM creation to a seperate thread to make awt/swing based stuff work on Mac (5.67 KB, patch)
2009-10-07 20:34 UTC, lohmaier
no flags Details | Diff
proof of concept (2.40 KB, text/plain)
2011-02-17 15:26 UTC, Stephan Bergmann
no flags Details
fix for the BeanShell editor (4.40 KB, text/plain)
2011-02-18 11:16 UTC, Stephan Bergmann
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description jimwhite 2008-08-19 20:43:17 UTC
I know this must be a known issue, but I can't find it anywhere in the tracker so I enter this so I can find 
out how to keep tabs on the status of this part of the port.

While Java is working fine within OOo, no code that needs any Java AWT function can work because the 
JVM can't start it's AWT subsystem because Java is initialized incorrectly for the MacOSX environment.

If you try to do anything that needs AWT this problems appears.  An easy way to reproduce is to try and 
open Tools:Macros:Organize Macros:BeanShell then try to Edit one of the OOo BeanShell macros.  The 
editor will not appear and if you check the console you'll see the relevant error message:

8/19/08 12:19:22 PM soffice.bin[11646] Apple AWT Java VM was loaded on first thread -- can't start 

It isn't easy to find a web-accessible reference to the ADC information on this issue, but this message 
on the Apple Java list is relevant.
Comment 1 h.ilter 2008-08-20 10:54:17 UTC
HI->JSK: Also reproducible with windows. Please have a look.
Comment 2 jimwhite 2008-08-20 18:43:54 UTC
This issue is specific to the MacOSX port (note the error message is "Apple AWT Java VM...").  

If you are having problems with Java and/or AWT on Windows, please open a separate issue.

Also Java AWT in OOo 3.0beta2 works fine for me (WinXP) (as have earlier betas).
Comment 3 joerg.skottke 2008-08-22 05:45:01 UTC
Comment 4 joerg.skottke 2008-08-22 05:46:37 UTC
@JL: Can you please have a look? Thanks
Comment 5 joachim.lingner 2008-08-22 07:36:31 UTC
Comment 6 jimwhite 2008-08-22 15:03:19 UTC
I don't understand how the target can be 3.1.  Surely the MacOSX port isn't at
3.0 (which I would think is a feature complete release) when macros don't work.
Comment 7 joachim.lingner 2008-09-22 16:15:47 UTC
Comment 8 joachim.lingner 2008-10-22 14:46:42 UTC
*** Issue 93076 has been marked as a duplicate of this issue. ***
Comment 9 joachim.lingner 2008-12-09 14:30:15 UTC
Comment 10 jimwhite 2008-12-09 17:30:21 UTC
I renew my complaint about the low priority given to this bug!

AFAIAC OpenOffice isn't even 3.0 without Java.

You've got no macros!  (Obviously BASIC doesn't count).
Comment 11 rvojta 2009-02-06 19:55:52 UTC
*** Issue 98979 has been marked as a duplicate of this issue. ***
Comment 12 tristanm 2009-02-23 09:54:08 UTC
Having reported the duplicate bug using Mac 
OS X 10.5 (Leopard) and OOo 3.0.0 which doesn't crash but doesn't run the attached extension code either 
after a java.awt class is encoutered, I have found that the same version on Mac OS X 10.4 (Tiger) behaves 
differently. If the extension attached to issue 98979 is run on OOo 3.0.0 on Mac OS X 10.4.11, the code 
runs but once complete, OOo crashes.

This was the case with Mac OS X 10.4.11 running java 1.5.0_16 with OOo 3.0.0

It would be nice to see this bug being fixed in 3.1, is there a reason why the target is 3.2?
Comment 13 jimwhite 2009-02-23 17:44:49 UTC
The only thing I can figure is that none of the OOo Mac developers use Java, nor
do they care that Java AWT doesn't work.  And this affects not just extensions,
but longstanding OOo features such as the Java-based macros for BeanShell and
JavaScript including their organizer dialogs.

And since NeoOffice 3 is now in early release, I don't suppose I care either
anymore.  Although it is a bit slow at the moment, it obviously will be working
better than OOo 3 for Mac quite soon.
Comment 14 prakashtheone 2009-02-26 09:28:04 UTC

We have developed a openoffice plugin for Sun Glassfish Web Space Server. Visit for more information on this project.

This openoffice plugin largely uses java AWT to render user forms and dialogs.
Because of this bug, the plugin is rendered useless on Mac OS. We would
appreciate if this is fixed as soon as possible since most of the developers
evaluate our product on Mac and it would leave a very bad impression if this
plugin dint work.
Comment 15 tristanm 2009-02-26 09:59:22 UTC
If you are using Mac OS X 10.5, there is a workaround for this problem for extensions at least. If you run 
code that uses java.awt from a Thread that is started from the extension code and use explicit package 
names for java.awt classes (i.e. don't use an import statement on the class) then the code should run. 
Unfortunately this doesn't work on previous version of Mac OS X
Comment 16 edschi 2009-04-09 09:56:13 UTC
I have the same problem with an extension using Java. However, the extension works perfectly with 
NeoOffice 2 and 3. So it seems there is already a solution for that problem in NeoOffice. 
Comment 17 joachim.lingner 2009-07-22 08:57:15 UTC
Ideas and patches are welcome!
Comment 18 stephan_schaefer 2009-08-03 09:52:24 UTC
CCed: ssa
Comment 19 lohmaier 2009-10-07 20:33:56 UTC
Will attach patch that moves creation of the JavaVM to a seperate thread to make
awt/swing work on Mac.

There's still a little quirk though: The rhino-debugger (i.e.
Javascript-Macro-editor that is launched when using Tools|Macros → Organize →
JavaScript → Edit) needs to be resized before its contents display properly.

The simple editor that is invoked when doing the same with beanshell macros
displays properly from the very beginning. 

Also: I use the JNI_CreateJavaVM directly (and link with -framework JavaVM) and
skip manual loading of the library for simplicity. (On Mac, there are no
per-version vm-starters - one vm-creator is used to create VMs of all installed
java versions. For this reason the java-selection in Tools has no effect on Mac
anyway - see also issue 88987)
Comment 20 lohmaier 2009-10-07 20:34:52 UTC
Created attachment 65221 [details]
move JVM creation to a seperate thread to make awt/swing based stuff work on Mac
Comment 21 eric.bachard 2009-10-07 20:39:23 UTC
@cloph : IMHO, the CFRunLoop() has to run in the main thread. Are you sure what yo'll do will keep that 
condition true ? (maybe I misunderstood). 

I remember issue 47888 about that, but that waslong time ago :

Comment 22 lohmaier 2009-10-07 21:01:39 UTC
the CFRunLoop is already created in vcl now - so I don't see the problem.

If I understand correctly, CFRUnLoop didn't exist yet for the main office during
the "X11-days"

But also sad to see that this issue apparently was once fixed already in some
way but crept back in and stayed unfixed for so long.

I din't have a closer look at the patches of the other issue though. I guess the
codebase changed too much to be still useful.

Anyway - the patch above works for me, wizards, the macros themselves work as
before, now the editor/debugger can also be launched. However, I didn't do
excessive testing.
Comment 23 florian 2009-10-07 21:10:44 UTC
You are right that the main run loop (CFRunLoop) must be started in the primordial thread. And I think it 
was because awt/swing's event queue must interact with the main event loop that java needs to be started 
from a separate thread.

What I learned when I played with this issue some time ago is that you can only use the JVM from the 
thread that you created it in. Just in case you experience some issues...
Comment 24 lohmaier 2009-10-08 00:34:54 UTC
*** Issue 102106 has been marked as a duplicate of this issue. ***
Comment 25 Frank Schönheit 2009-10-08 07:17:48 UTC
Transfering target milestone from the just-duplicated issue 102106. "Please
Help" is not really satisfying for an issue like this, the more since there's
now a patch attached.
Comment 26 joachim.lingner 2009-10-09 14:23:39 UTC
I applied the patch to DEV300 m60 and ran it on a mac 10.5.8. I also used debug
output to verify that the startup function was called. Starting the Beanshell or
JScript editor from the macro organize dialog, does not work. There is still the

"Apple AWT Java VM was loaded on first thread -- can't start AWT."

The Java version is 1.5.0. That Java generally works was proved by running the
letter wizard.
Comment 27 lohmaier 2009-10-09 16:33:43 UTC
Hmm. definitely works on 10.4/PPC - also with JRE 1.5.0 - but it is definitely
started in a new thread and I closely followed Apple's simpleJavaLauncher

I don't have access to a 10.5 / Intel machine currently though.
Comment 28 joachim.lingner 2009-10-14 15:21:35 UTC
Setting issue type back to 'defect' because the patch does not seem to work on
MacOS 10.5.8.
Comment 29 gallomimia 2009-10-26 02:18:50 UTC
soffice[4319] Apple AWT Java VM was loaded on first thread -- can't start AWT. 3.1.1
OOO310m19 Build:9420

$ java -version
java version "1.5.0_20"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_20-b02-315)
Java HotSpot(TM) Client VM (build 1.5.0_20-141, mixed mode, sharing)

PPC G4 MacOS X 10.5.8

Someone from mac@porting asked me to have a look at this issue.

I'm not sure what more information I can give to be of help. I want to see this bug squashed. My 
machine under Leopard is at your disposal, and I will do any testing asked. The first was generated by 
console after following the reproduction directions in the OP.
Comment 30 joachim.lingner 2009-10-26 09:40:06 UTC
It could be useful to check if the patch from cloph works on Leopard. You could
try that. Anyhow, since we have a 10.6 around, I can have a look myself in the
next few days.
Comment 31 lohmaier 2009-10-26 22:35:12 UTC
I prepared a PPC build for testing and uploaded it here:

Works fine on Tiger (=the buildhost)

I tried on 10.6/Intel and confirm that the patch doesn't solve the problem,
despite java being in a seperate thread (as also shown by Activity Monitor →
Analyze → show threads)
Comment 32 stoussaint 2010-04-13 15:53:07 UTC
Currently working on a plugin, we've just encounter this issue while trying to
test it on a MacOSX 10.6/Intel Plateform as well as on a MacOSX 10.4/PPC Plateform.

It seem's that nothing was done on this subject since the end of October, when
cloph has released a patch for the PPC environment.

What actions can be done to provide a fix for the Intel environment, and to see
this fix released in a very next version of OpenOffce ?
Comment 33 joachim.lingner 2010-04-13 16:19:32 UTC
>What actions can be done to provide a fix for the Intel environment, and to see
>this fix released in a very next version of OpenOffce ?

Find someone who provides a patch. Cloph already did a good a job, but
unfortunately things changed again in  OS 10.6 which broke the fix.
Comment 34 lohmaier 2010-04-13 16:22:20 UTC
Well, I did my best to follow Apple's documentation.

The patch works fine on 10.4/PPC, but doesn't work on 10.6/Intel

>What actions can be done to provide a fix for the Intel environment,

Point out what Apple did change/why the patched code only works on 10.4/PPC but 
not on (Snow) Leopard.

> and to see this fix released in a very next version of OpenOffce ?

Well, when someone provides a patch that works for both, then integrating it 
into the next release wouldn't be a problem. 
The problem is finding out why it doesn't work (and I don't wanna hunt for 
apple's bugs)
All I can do is offer to provide a current build for PPC with the patch 
applied/ask the provider of "official" PPC builds to include the patch when he 
creates the PPC installsets.

But on intel the patch is of little help, as it unfortunately doesn't solve the 
problem, (well, might work on 10.4 on intel as well, but there hasn't been 
feedback on that in this issue)

One could argue to apply the patch nevertheless, as it solves the problem on 
10.4/PPC and doesn't break anything on other versions (AFAICT)...
Comment 35 stoussaint 2010-04-13 16:35:55 UTC
Ok, I thought that the problem was only between proc environments (PPC/Intel).

To improve the issue's scope, I'm able to test it on a 10.4/Intel if you can
provide me a dmg for this.
Comment 36 joachim.lingner 2010-04-14 07:23:47 UTC
>One could argue to apply the patch nevertheless, as it solves the problem on 
>10.4/PPC and doesn't break anything on other versions (AFAICT)...

Maybe we should do this as long as there is no other solution in sight. However,
I am not sure what is more frustrating to users: knowing that it does not work
altogether or only on particular versions.
Comment 37 lohmaier 2010-04-14 12:04:04 UTC
Installsets for Intel and PPC with the patch included are available here:

They are based on DEV300_m76 - the intel one was built on Snow Leopard Server 
(but against the 10.4u SDK), the PPC one Tiger
Comment 38 stoussaint 2010-04-22 08:14:50 UTC
Here come some tests results based on the patch released by Cloph :

- On a 10.4/PPC : OK, the patch fix the issue (as expected)
- On a 10.6/Intel : KO, the fix seems not to be of any help (as expected)

- To see if it is an 10.6 or an Intel environment issue, I try to test others 
platforms but I encounter another problem.


The JRE is not detected when using the very same patched version of OO and if 
the JRE is manually set, no macros are available for test at all.

To check whether it is a problem with the build machine only, or a general 
problem of the version, I try with
Dev_DEV300_m76_MacOSXIntel_install_en-US.dmg - i.e. a build that is provided by 
Sun/Oracle as proposed by cloph.

With this build, OpenOffice detect the JRE just well, and macros 
(BeanShell/Javascript) are available.

@cloph : Could you please apply your patch on this build ?
Comment 39 ronyf 2011-02-16 10:57:21 UTC
This should be a priority "P1", a showstopper-bug all along: 

    The scripting framework of OOo is of strategic, tactical and operational
importance, like it or not! Not having it function properly on MacOSX *cripples*
OOo bad time on that platform! 

    It is only because of the possibilities to write macros/scripts that also
allow non-professional programmers ("end-user programmers") to become able to
drive/program OOo. Employing this infrastructure also locks such
users/businesses into the OOo environment. 

    Plus only macros/scripts allow professional OOo developers to easily create
applications, useful functionalities for their customers in an easy way
(development and deployment alike)! Doing so, they get locked into OOo as well.

    Not being able to edit existing macros at all on MacOSX because of this
(stupid) error, renders that part inaccessible and as a result totally useless
to business users of OOo on MacOSX!

    Not having such a showstopper error fixed is therefore not understandable
for me as this hints that those who allot resources to fixing issues have no
clues about the impact and importance of the scripting framework on users and

    What are the reasons that the OOo developers ignore this unbelievable error
for so long? Why hasn't it been solved long ago once and forever ?


Whoever starts to work with Java on MacOSX using JNI will immediately be drawn
to this very MacOSX issue of the CFRunLoop in the main thread and the JVM to
have to be loaded in a separate thread if awt gets excercised. Apple has been
very open and informative about this very issue (see links below), since 2005!

In OOo it is a base feature, that awt/swing must work. Therefore I am totally
stunned that this unbelievable defect has not been fixed long ago! It not only
affects the scripting framework, but any Java code that employs awt/swing.

Here a few links to (quite old!) Mac-documentation about this:



Oh, once started on a separate thread it is possible to attach to the JVM from
other threads as well, AFAICT.

[BTW: judging from the OpenJDK-wiki OpenJDK will exhibit the very same behaviour
as the Apple ports of Java. So the problem won't go away, if someone would be
speculating in that direction. Plus it seems, that the Apple changes to Java in
the awt/swing area are being taken over as well by OpenJDK.]


    *Again, I consider this a showstopper error which should stop branching OOo
3.4, until it is fixed!*

    How could I increase the priority of this issue to "P1"?

Comment 40 kai.sommerfeld 2011-02-16 13:19:51 UTC
cc-ing myself.
Comment 41 Stephan Bergmann 2011-02-17 15:25:47 UTC
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 <> "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).
Comment 42 Stephan Bergmann 2011-02-17 15:26:58 UTC
Created attachment 75862 [details]
proof of concept
Comment 43 lohmaier 2011-02-17 15:39:10 UTC
thanks for the alternative patch, I'll try it later on PPC/10.4, just one 
question regarding my patch:

> 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.

Yes, but only to detach it right away, so the patch just skips that step:

What am I missing? (feel free to reply by mail instead of commenting here)
--- stoc/source/javavm/javavm.cxx	(revision 276725)
+++ stoc/source/javavm/javavm.cxx	(working copy)
@@ -950,7 +950,9 @@
         if (bStarted)
+#ifndef MACOSX // Mac creates the JVM in a seperate thread already
                 DetachCurrentThread detach(m_pJavaVm);
                     // necessary to make debugging work; this thread will be
                     // suspended when the destructor of detach returns
                 m_xVirtualMachine = new jvmaccess::VirtualMachine(
Comment 44 Stephan Bergmann 2011-02-17 15:44:37 UTC
@cloph:  The call to setUpUnoVirtualMachine(pMainThreadEnv); expects
pMainThreadEnv to be attached to the current thread.  (Note that
DetachCurrentThread only does its work in the destructor, i.e., after the call
to setUpUnoVirtualMachine.)
Comment 45 ronyf 2011-02-17 17:52:03 UTC

thank you *very much* for tackling this!

Changed the code to use SwingUtilities.invokeLater() instead of synchroneously
calling "initUI()" in the classes (originally copied from the bash scripting
framework implementation, if my memory serves well, just creating an
oorexx-directory and adapting the Java code copied from bash to ooRexx accordingly):

Tested the code under Windows (the Tools -> Macros -> ... -> Edit is still
functional ;) ).

Unfortunately, the editor does still not show up on MacOSX. (The scripts
execute, it is possible to create a new script from the supplied template.)

The Mac logs (using the does not show any messages from OOo nor
from Java (enabling tracing and logging using the Java Preference utility in
Application/Utilities), so I am not sure how to get at that information. 

Is it possible to activate tracing/debugging from the release version of OOo 3.3
for MacOSX somehow to become able to learn more about what happens in detail? 
Comment 46 Stephan Bergmann 2011-02-17 20:00:50 UTC
@ronyf:  I will see whether I can come up with a proper patch for the BeanShell case (that does not hack the 
C++ SvxScriptOrgDialog but rather modifies the involved Java code).
Comment 47 Stephan Bergmann 2011-02-18 11:16:13 UTC
Created attachment 75872 [details]
fix for the BeanShell editor
Comment 48 Stephan Bergmann 2011-02-18 11:23:02 UTC
The remaining problem was that merely calling SwingUtilities.invokeLater already
triggers the dreaded "Apple AWT Java VM was loaded on first thread -- can't
start AWT." failure.  So, the solution is to wrap the call to
SwingUtilities.invokeLater in a fresh thread, to avoid calling invokeLater on
the AppKit thread.  (Note that the invokeLater part is necessary on all
platforms, to conform to the Swing threading requirements.  It was erroneously
missing from the ScriptEditorForBeanShell code.)

The attached ScriptEditorForBeanShell.patch fixes this for the BeanShell editor.
 The JavaScript editor apparently has the same problem and will need to be
fixed, too.
Comment 49 ronyf 2011-02-18 14:56:35 UTC
Stephan, thank you *very much* for your efforts and solution! Studying your
patch allowed me to change ScriptEditorForooRexx accordingly and it works as
well! Again, thank you very much!
Comment 50 lohmaier 2011-02-18 16:36:16 UTC
Results: plain DEV300_m100 on PPC/10.4: Invoking "Edit" from Tools|Macros → 
Organize Beanshell/Javascript results in a crash (Bus Error)

with the ScriptEditorForBeanShell.patch applied, using "Edit" for beanshell 
macros works.

That being said, a solution that would require each and every extension author to 
add special code to avoid this problem is not really helpful...
Comment 51 Stephan Bergmann 2011-02-18 19:58:53 UTC
fixed as <>; on Mac OS X only, it turned 
out the JavaScript editor still has a different problem, see issue 117015

@cloph: "a solution that would require each and every extension author to add special code [...] is not 
really helpful":  Agreed.  However, (a) as I already wrote, I don't see a better solution, (b) only extensions 
that use Java AWT/Swing are affected, and (c) using AWT/Swing in extensions was never encouraged (yes, 
lame excuse, I know---but still).
Comment 52 Stephan Bergmann 2011-02-28 12:59:59 UTC
@tbo: please verify
Comment 53 2011-03-03 11:54:35 UTC
verified in cws sb141 by using the Hello World examples for JavaScript, BeanShell  and Python where available by 
- opening an writer document
- Tools - Macros - Organize - (Prog. language)
- Use 'Edit' and 'Run' buttons

No crash anymore on MacOs 10.4 and 10.6 Intel, also checked that it still works on win32
Comment 54 Martin Hollmichel 2011-03-07 11:43:34 UTC
set target 3.4