HI->JSK: Also reproducible with windows. Please have a look.

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

New

@JL: Can you please have a look? Thanks

.

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.

@self: http://developer.apple.com/technotes/tn2005/tn2147.html#TNTAG25

*** Issue 93076 has been marked as a duplicate of this issue. ***

Retargeting.

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

*** Issue 98979 has been marked as a duplicate of this issue. ***

Having reported the duplicate bug http://www.openoffice.org/issues/show_bug.cgi?id=98979 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?

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.

Hi,

We have developed a openoffice plugin for Sun Glassfish Web Space Server. Visit
https://webspace.dev.java.net/ 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.

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

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. 

Ideas and patches are welcome!

CCed: ssa

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)

Created attachment 65221 [details]
move JVM creation to a seperate thread to make awt/swing based stuff work on Mac

@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 : http://www.openoffice.org/issues/show_bug.cgi?id=47888

 

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.

@ericb:
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.

@cloph:
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...

*** Issue 102106 has been marked as a duplicate of this issue. ***

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.

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
message:

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

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

I don't have access to a 10.5 / Intel machine currently though.

Setting issue type back to 'defect' because the patch does not seem to work on
MacOS 10.5.8.

soffice[4319] Apple AWT Java VM was loaded on first thread -- can't start AWT. 

OpenOffice.org 3.1.1
OOO310m19 Build:9420
OOo_3.1.1rc2_20090827_MacOSXPowerPC_install_en-GB.dmg

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

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.

I prepared a PPC build for testing and uploaded it here:

http://users2.ooodev.org/~cloph/OOo_m61_92926.dmg

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)

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 ?

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

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

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.

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

Installsets for Intel and PPC with the patch included are available here:

http://buildbot.projects.ooodev.org/i92926/

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

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.

10.4/Intel,
10.5/Intel

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 
http://download.services.openoffice.org/files/extended/developer/DEV300_m76/OOo-
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 ?

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
businesses! 

    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:

   <http://developer.apple.com/library/mac/#technotes/tn2005/tn2147.html>
  
<http://developer.apple.com/library/mac/#samplecode/simpleJavaLauncher/Introduction/Intro.html>

  
<http://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/07-NativePlatformIntegration/NativePlatformIntegration.html>
  
<http://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/04-JavaUIToolkits/JavaUIToolkits.html#//apple_ref/doc/uid/TP40001901-SW1>

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"?

cc-ing myself.

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

Created attachment 75862 [details]
proof of concept

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);
+#endif
                     // necessary to make debugging work; this thread will be
                     // suspended when the destructor of detach returns
                 m_xVirtualMachine = new jvmaccess::VirtualMachine(

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

Stephan,

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):

    com.sun.star.script.framework.provider.oorexx.PlainSourceView.java
    com.sun.star.script.framework.provider.oorexx.ScriptEditorForooRexx.java

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 Console.app) 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? 

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

Created attachment 75872 [details]
fix for the BeanShell editor

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.

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!

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

fixed as <http://hg.services.openoffice.org/cws/sb141/rev/43bea9e7a54b>; 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).

@tbo: please verify

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

set target 3.4