Java Macro NoClassDefFound Error after switching versions

Hello,
I have a document template, that has an embedded Java Macro. The Template/Macro works fine in LibreOffice 5.4.3, but after updating to 7.1.6.2 (I also tried 7.1.4), I suddenly get a NoClassDefFound exception when trying to open the same template. The Jar is of course in the template, it did not change, all classes are in there.
Also, the first class and the method to call, which is defined in the parcel-descriptor.xml in the template are apparently found and executed. I can debug that, it is executed. Only when another class in the same jar is called, that’s when the trouble starts. The classpath is defined in the parcel descriptor.



Did something change in between the versions and this definition needs an update? Some hint why the classpath seems not to be valid anymore would be appreciated. I tried to find something about possible changes, but all examples I found seem to use the same notation…
Thank you!

I created a small Demo based on the Hello World example delivered with LO 7, in case anyone is interested. In this case I had to use the older file version to bundle the jar with the document, otherwise I could not upload the jar. However, the jar in the file could also replace the one in LO install folder
share\Scripts\java\HelloWorld
then one can execute the macro in writer via Tools-> Macros → Run Macros dialog, under the LibreOffice macros.
With this document it should run automatically
text.odt (11.5 KB)
.
The Macro gets executed, it still writes its Hello World in the Document. However, after that I attempt to load the other class in the same package, and NoClassDefFound Error appears.
I am on Win10 and a Java 8 environment here.

After debugging what happens, I found it works to just replace
%LO_Install_Path%\program\classes\ScriptProviderForJava.jar
with the same jar from LO version 5. All classes are found again.
Hacks like this are not a proper solution! Still this may be interesting for someone having similar problems.
If LO is build from source, it may be of interest that the the issue most likely is in ScriptProviderForJava.java. I see there was a change in declaration from ClassLoader to URLClassLoader, but it could be something different I completely overlooked…