Sorry, typo in version number: with the Intel architecture versions, the sample works up to version 7.3.3.2 (not 7.3.2.2) and starts failing beginning with 7.3.4.1

How is this code supposed to be run ? Do I just download the sample code, add a .java extension to the file name and try and run it from the command line ?

FWIW, the many of the people who do bug triaging within the project are not developers/programmers, and this is almost exclusively so on macOS.

There are certainly no paid developers working on macOS specific LO issues, to my knowledge.

In order for it to be tested, we would generally need a greater degree of detail on how to reproduce.

Thank you for your reply - sorry my description was not precise enough.

Prerequisites for test case:
* M1 Mac (e.g. MacBook Pro)
* Java JDK installation (I used version 17)


Assumptions for the following steps:
* LibreOffice is installed in the standard location (/Applications/LibreOffice.app)
* Java is installed an can be executed from Terminal


Steps to reproduce behavior:
* Download attachment, rename file to Test.java
* Open Terminal, go to folder containing Test.java
* execute command to compile test case (all in one line):

javac -cp /Applications/LibreOffice.app/Contents/Resources/java/libreoffice.jar Test.java

* Execution of previous step should result in creation of file Test.class
* execute command to run test case (all in one line):

java -classpath /Applications/LibreOffice.app/Contents/MacOS/:/Applications/LibreOffice.app/Contents/Resources/java/libreoffice.jar:/Applications/LibreOffice.app/Contents/Resources/java/unoloader.jar:. -Djava.library.path=/Applications/LibreOffice.app/Contents/Frameworks Test


Result:
LibreOffice window opens, but no Writer document is started. LO window stays grayed out. Process has to be terminated.

Expected Result:
LO window opens, a new Writer document is started. After 15 seconds, Writer document/window will be closed. Test case exits.

(In reply to Simon Muschel from comment #0)
> Created attachment 183279 [details]
> Sample Code
> 
> Problem: LibreOffice freezes/becomes unresponsive when started (or being
> controlled) from a Java Application using UNO API (libreoffice.jar). This
> reproducibly happens for calls to loadComponentFromURL but also on
> dispose-Calls (lines 17 and 19 in sample).
> 
> The attached sample code was used to demonstrate this behavior.
> 
> Hardware/OS info: M1 MacBook Pro, both Monterey and Ventura were used.
> LibreOffice versions: multiple versions from 7.2.x, 7.3.x and latest 7.4;
> all M1 architecture
> 
> Test cases:
> 
> 1. LibreOffice is not running. The attached test class is executed and tries
> to open an empty Writer document. The call to
> 'loader.loadComponentFromURL(...)' creates an empty LibreOffice window, but
> not the Writer content (only a gray window is displayed, LibreOffice is
> unresponsive). Have to kill the process.
> 
> 2. LibreOffice is started manually, a Writer document is opened manually.
> The test class successfully opens another empty Writer window. In this case,
> the sample fails on the dispose call (LibreOffice becomse unresponsive, have
> to kill process)
> 
> Additional info:
> Same code works on an Intel MacMini with an older version of LibreOffice
> (7.0.x, Intel architecture).
> 
> I also tried several Intel-architecture versions on the M1 MacBook Pro -
> until version 7.3.2.2, I could make the sample work. It starts failing from
> version 7.3.4.1 onwards.

Do I need to download and configure the OpenOffice SDK as I am getting in Eclipse "The import com.sun.star" cannot be resolved...

(In reply to Mike Little from comment #5)
> (In reply to Simon Muschel from comment #0)
> > Created attachment 183279 [details]
> > Sample Code
> > 
> > Problem: LibreOffice freezes/becomes unresponsive when started (or being
> > controlled) from a Java Application using UNO API (libreoffice.jar). This
> > reproducibly happens for calls to loadComponentFromURL but also on
> > dispose-Calls (lines 17 and 19 in sample).
> > 
> > The attached sample code was used to demonstrate this behavior.
> > 
> > Hardware/OS info: M1 MacBook Pro, both Monterey and Ventura were used.
> > LibreOffice versions: multiple versions from 7.2.x, 7.3.x and latest 7.4;
> > all M1 architecture
> > 
> > Test cases:
> > 
> > 1. LibreOffice is not running. The attached test class is executed and tries
> > to open an empty Writer document. The call to
> > 'loader.loadComponentFromURL(...)' creates an empty LibreOffice window, but
> > not the Writer content (only a gray window is displayed, LibreOffice is
> > unresponsive). Have to kill the process.
> > 
> > 2. LibreOffice is started manually, a Writer document is opened manually.
> > The test class successfully opens another empty Writer window. In this case,
> > the sample fails on the dispose call (LibreOffice becomse unresponsive, have
> > to kill process)
> > 
> > Additional info:
> > Same code works on an Intel MacMini with an older version of LibreOffice
> > (7.0.x, Intel architecture).
> > 
> > I also tried several Intel-architecture versions on the M1 MacBook Pro -
> > until version 7.3.2.2, I could make the sample work. It starts failing from
> > version 7.3.4.1 onwards.
> 
> Do I need to download and configure the OpenOffice SDK as I am getting in
> Eclipse "The import com.sun.star" cannot be resolved...

I did not install the SDK. I guess you'd have to add libreoffice.jar and unoloader.jar from LibreOffice installation to your Eclipse project. If it's easier for you, I can try to provide the test case as a Maven project.

Something that requires setting up a Java build environment to build and run a test case is not trivial for the majority of QA triagers, who are volunteers. I don't have such a build setup, so unfortunately can not help here.

(In reply to Mike Little from comment #5)


> 
> Do I need to download and configure the OpenOffice SDK as I am getting in
> Eclipse "The import com.sun.star" cannot be resolved...

Same here, and as I don't program or build in any kind of Java environment, this is out of my scope.

 I have downloaded the SDK and configured it, but I cannot find the relevant .jar files for the build path [project>build path> Configure Build Path ...

import com.sun.star.beans.PropertyValue;
import com.sun.star.comp.helper.Bootstrap;
import com.sun.star.frame.XComponentLoader;
import com.sun.star.lang.XComponent;
import com.sun.star.lang.XMultiComponentFactory;
import com.sun.star.uno.UnoRuntime;
import com.sun.star.uno.XComponentContext;

That I can point to in  Eclipse...

I did find some apache open office .jar files and that mostly fixed most of the problems with these, but that is not LibreOffice.... can some one provide a path or download where I can obtain these?

Notes.. and an update... 
1.	Used Eclipse as the IDE. 
2.	Set up the build path external class paths [external JARs] as:
a.	Applications/LibreOffice.app/Contents/Resources/java/libreoffice.jar;
b.	/Applications/LibreOffice.app/Contents/Resources/java/unoloader.jar;
3.	Got a warning message …

“warning: com.sun.star.lib.util.NativeLibraryLoader must be loaded by com.sun.star.lib.unoloader.UnoClassLoader for java_uno bridge to work (not a problem if this is using Java remote bridge or unit test)”
com.sun.star.comp.helper.BootstrapException: no office executable found!

Added ‘import com.sun.star.lib.util.NativeLibraryLoader;” 

But does not appear to being used

4.	I need to provide the path to the application, added the following to the class path in Eclipse… 

/Applications/LibreOffice.app/Contents/MacOS/

5.	Application starts and loads the LibreOffice canvas, but then freezes, no UI elements loaded... I will check this through the Eclipse debugger. Still working on it…

(In reply to Simon Muschel from comment #4)
> Thank you for your reply - sorry my description was not precise enough.
> 
> Prerequisites for test case:
> * M1 Mac (e.g. MacBook Pro)
> * Java JDK installation (I used version 17)
> 
> 
> Assumptions for the following steps:
> * LibreOffice is installed in the standard location
> (/Applications/LibreOffice.app)
> * Java is installed an can be executed from Terminal
> 
> 
> Steps to reproduce behavior:
> * Download attachment, rename file to Test.java
> * Open Terminal, go to folder containing Test.java
> * execute command to compile test case (all in one line):
> 
> javac -cp
> /Applications/LibreOffice.app/Contents/Resources/java/libreoffice.jar
> Test.java
> 
> * Execution of previous step should result in creation of file Test.class
> * execute command to run test case (all in one line):
> 
> java -classpath
> /Applications/LibreOffice.app/Contents/MacOS/:/Applications/LibreOffice.app/
> Contents/Resources/java/libreoffice.jar:/Applications/LibreOffice.app/
> Contents/Resources/java/unoloader.jar:.
> -Djava.library.path=/Applications/LibreOffice.app/Contents/Frameworks Test
> 
> 
> Result:
> LibreOffice window opens, but no Writer document is started. LO window stays
> grayed out. Process has to be terminated.
> 
> Expected Result:
> LO window opens, a new Writer document is started. After 15 seconds, Writer
> document/window will be closed. Test case exits.


I can confirm the issue in question, and I can confirm the result (I did as described above to reproduce the issue).



LibreOffice:
------------
Version: 7.4.3.1 / LibreOffice Community
Build ID: 3793858a34d8fef5b92f8fee233f97766f05e281
CPU threads: 10; OS: Mac OS X 13.0.1; UI render: default; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded

Hardware:
---------
% /usr/sbin/system_profiler SPHardwareDataType | grep "Model Name"
      Model Name: MacBook Pro
% /usr/sbin/system_profiler SPHardwareDataType | grep "Model Identifier"
      Model Identifier: MacBookPro18,3
% /usr/sbin/system_profiler SPHardwareDataType | grep "Chip"            
      Chip: Apple M1 Pro

OS:
---
% uname -a
Darwin xyz.local 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct  9 20:15:09 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T6000 arm64

% uname -m
arm64

% machine                                                                                  
arm64e

% sw_vers                
ProductName:		macOS
ProductVersion:		13.0.1
BuildVersion:		22A400

Java JDK:
---------
% java --version
java 19.0.1 2022-10-18
Java(TM) SE Runtime Environment (build 19.0.1+10-21)
Java HotSpot(TM) 64-Bit Server VM (build 19.0.1+10-21, mixed mode, sharing)

% /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home

resp.

% JAVA_HOME=$(/usr/libexec/java_home); echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home

I am fairly certain that this is a duplicate of tdf#145127 since your Java program runs on the main thread of its process.

LibreOffice is a native GUI application so, on macOS, all that GUI code must run on the main thread. However, your Java program never starts the native event queue or allows LibreOffice's GUI event loop to run on the main thread.

Realistically, embedding LibreOffice in another application is likely not feasible unless someone funds and implements a "headless mode" like Windows and Linux both have. More details about macOS and the lack of a headless mode is in the following comment:

https://bugs.documentfoundation.org/show_bug.cgi?id=145127#c4

*** This bug has been marked as a duplicate of bug 145127 ***

(In reply to Patrick (volunteer) from comment #13)


If this worked up to version 7.3.3.2, then wouldn't this be a regression, cf. #c1 ? 

Did the move to a native GUI application cause this problem ?

(In reply to Alex Thurgood from comment #14)
> (In reply to Patrick (volunteer) from comment #13)
> 
> 
> If this worked up to version 7.3.3.2, then wouldn't this be a regression,
> cf. #c1 ? 
> 
> Did the move to a native GUI application cause this problem ?

LibreOffice has always been a native GUI application. Most of the native code was written by OpenOffice shortly before LibreOffice was created.

If it worked in the past, then I'd assume that it worked because their Java call  didn't trigger any timers or blocking waiting for an event in the event queue. 

If LibreOffice starts the event queue in the Java call, LibreOffice will never return. Hence the "LibreOffice becomes unresponsive" notes in comment #0. The bug filer hasn't provided any stack trace but I'd bet that it would show LibreOffice stuck in its event processing loop.

Feel free to reopen this bug but I just don't see how a Java application can make synchronous calls in the main thread. With a headless mode like Windows, Linux, and iOS, the LibreOffice main thread can be moved to a secondary thread.

(In reply to Patrick (volunteer) from comment #15)
> Feel free to reopen this bug but I just don't see how a Java application can
> make synchronous calls in the main thread. With a headless mode like
> Windows, Linux, and iOS, the LibreOffice main thread can be moved to a
> secondary thread.

So the only way I can this working is that the Java code implicitly launches LibreOffice as a separate process and uses interprocess communication (i.e. a socket connection) to send load document messages.

If that is the case, take an Activity Monitor sample of the LibreOffice process would be the next debugging step. Or, better yet, use a LibreOffice nightly build and you can connect lldb to the running LibreOffice to see what the stack trace. That might give you a clue why LibreOffice is becoming unresponsive.

My first guess is that LibreOffice is either blocked waiting for the next native event (it is a GUI application) or spending all its time in its "idle timers" (i.e. drawing updates to a window, spellchecking). I'd imagine that if you open a lengthy Writer document and automatic spellchecking is enabled, LibreOffice can appear to be stuck until you do some key or mouse event in LibreOffice to interrupt that "idle task".

(In reply to Patrick (volunteer) from comment #16)
> (In reply to Patrick (volunteer) from comment #15)
> > Feel free to reopen this bug but I just don't see how a Java application can
> > make synchronous calls in the main thread. With a headless mode like
> > Windows, Linux, and iOS, the LibreOffice main thread can be moved to a
> > secondary thread.
> 
> So the only way I can this working is that the Java code implicitly launches
> LibreOffice as a separate process and uses interprocess communication (i.e.
> a socket connection) to send load document messages.
> 
> If that is the case, take an Activity Monitor sample of the LibreOffice
> process would be the next debugging step. Or, better yet, use a LibreOffice
> nightly build and you can connect lldb to the running LibreOffice to see
> what the stack trace. That might give you a clue why LibreOffice is becoming
> unresponsive.
> 
> My first guess is that LibreOffice is either blocked waiting for the next
> native event (it is a GUI application) or spending all its time in its "idle
> timers" (i.e. drawing updates to a window, spellchecking). I'd imagine that
> if you open a lengthy Writer document and automatic spellchecking is
> enabled, LibreOffice can appear to be stuck until you do some key or mouse
> event in LibreOffice to interrupt that "idle task".

First of all thank you for looking into this. It's been a few years, so my memory is not very accurate. But as far as I understand my own sample, the call to Bootstrap.bootstrap is intended to launch a separate Libreoffice process and communication between our application and LO should happen via a named pipe or some IPC mechanism.
Here's some code from class Bootstrap:
String sPipeName = "uno" + Long.toString(randomPipeName.nextLong() & Long.MAX_VALUE);
String[] cmdArray = new String[argArray.length + 2];
cmdArray[0] = fOffice.getPath();
cmdArray[1] = "--accept=pipe,name=" + sPipeName + ";urp;";
System.arraycopy(argArray, 0, cmdArray, 2, argArray.length);
Process p = Runtime.getRuntime().exec(cmdArray);

I'll have to look into this when I find the time, maybe I can provide additional information

(In reply to Simon Muschel from comment #17)
> First of all thank you for looking into this. It's been a few years, so my
> memory is not very accurate. But as far as I understand my own sample, the
> call to Bootstrap.bootstrap is intended to launch a separate Libreoffice
> process and communication between our application and LO should happen via a
> named pipe or some IPC mechanism.

Reopening as I was confused about this bug being a duplicate of tdf#145127. That bug is in LibreOfficeKit which is what LibreOffice and Collabora Online use in their headless server.

The "--accept=pipe" is definitely something else entirely.