https://bugs.documentfoundation.org/show_bug.cgi?id=162429
Albrecht Müller <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |[email protected] Status|UNCONFIRMED |NEW --- Comment #1 from Albrecht Müller <[email protected]> --- Based on my experience with version 7.0.4.2 (x64) running under Windows 7 I think there are issues related to this topic but cannot tell exactly what these issues are. That’s by itself the first issue: The LibreOffice installation directory contains a subdirectory “share\Scripts\java” which contains some examples. I think the intention of these examples is to enable a _human_ to implement something useful but the content is what enables a _computer_ to execute the code. The examples lack any information about underlying concepts, specifications or documentation. A few lines of comment in a readme file or in the source files could specify a starting point that may save many hours of searching, guessing and experimenting. Without any clue what the expected behaviour is it is difficult do tell if something is a bug or not. The way how LibreOffice handles errors aggravates the problem considerably. Therefore I can only describe my current assumptions and observations. First a some information about Java that I consider to be true and relevant in this context: J.1) It is not possible to change the classpath of a running Java Virtual Machine (JVM). It may be possible to change a classpath property but the class loader of the JVM ignores these changes. According to my knowledge this is an intended behaviour for security reasons. J.2) If you want to load some class from some location that is not on the classpath you have to implement your own class loader. I think there are a few exceptions to this rule but in general a class loader has to be implemented. How does LibreOffice handle the JVM? My current hypotheses (which my be wrong) are: LO.1) LibreOffice starts a JVM by need only, i.e. it starts a JVM at the first occasion when some Java code has to be executed. LO.2) LibreOffice runs only a single instance of a JVM. This instance is terminated when LibreOffice terminates. LO.3) When LibreOffice starts a JVM it uses a classpath that can be changed in Tools → Options… → LibreOffice → Advanced → Class Path… (I used the German UI where this path is Extras → Optionen → LibreOffice → Erweitert → Class Path…) What follows from these assumptions: C.1) J.1 and LO.2 imply that the classpath information cannot be related to the actual classpath used by the running instance of the JVM. C.2) Due to J.2 and LO.2 I assume that LibreOffice has some class loader that allows to load classes from locations not contained in the classpath of the running JVM instance. Now my observations. I tried to run a standalone Java application using LibreOffice’s scripting mechanism. For this purpose I added a new class that has a static method that simply calls the main method of this application. It is not necessary to access any parameters provided by LibreOffice as the application is able to run without LibreOffice. I have a spreadsheet that contains a button with an action that points to this extra method. For the first experiment I put the application’s .jar-File into the directory that contains the corresponding parcel-descriptor.xml file. The “functionname” entry contained the qualified Name of the method I added. The “logical name” contained <classname>.<methodname> of the same method. The “classpath” entry contained the name of the jar-File including its extension. The results I got are: 1) The macro did not show up in the Macro Selector dialogue (Tools → Macros → Run Macro…). The reason was that parcel-descriptor.xml contained umlauts that were not coded in UTF-8. This simple bug is difficult to find as LibreOffice does not issue any error message that informs that something is wrong. I would expect that LibreOffice informs the user that it found a defect parcel-descriptor.xml file and gives an error message that describes the problem. In this case this could be something like “Unsupported UTF-8 code in line x, column y”. 2) Having fixed Problem 1) the Macro showed up in the Macro Selector dialogue but I got various “Class not found”-Error messages. I found no way to fix this. I now assume that the cause of the problem is that the class loader can only load a single class in the .jar file namely the class that contains the entry point given as “functionname”. Interestingly all the example .jar files that come with the LibreOffice installation contain only a a single class file! 3) So I tried another approach and added the location of the relevant .jar file to the global class path using Tools → Options… → LibreOffice → Advanced → Class Path… Now I could use the button to start the application and it worked. It worked despite the fact that I deleted the jar file from the script directory that contains parcel-descriptor.xml and therefore its classpath entry pointed to a non existent file. Nevertheless LibreOffice needs this entry for some reason: When I deleted it I could not start my application any more. Some additional remarks: I could start the application using the button on the spreadsheet but I was not able to start it using the Macro Selector dialogue. Probably separate entry points are necessary that depend on the way the macro is called. Is there any documentation that eliminates the need to find out the necessary method signatures by trial and error? The application has a GUI based on the Java Swing classes. Closing the application using the common close button in the upper right corner of its window also closes LibreOffice. At the next start LibreOffice shows its recovery mechanism. This is not a problem when the application is closed using a menu entry. In this case the application closes and LibreOffice continues to run. -- You are receiving this mail because: You are the assignee for the bug.
