Reports won't open

[Michael Sharman]

Reports that were working as of June this year (I haven't opened them since then) now are failing with the following error:

Can not activate the factory for org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory

I tried creating a fresh report to see if its some kind of out of date file format but I get the same error:
  1. select "Create Report in Design View..."
  2. select "Save"
  3. Double click report
  4. Same error as above

Of course I'm expecting the report to open without an error.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: libreoffice-report-builder 1:6.0.6-0ubuntu0.18.04.1
ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
Uname: Linux 4.15.0-38-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Nov 8 12:16:08 2018
InstallationDate: Installed on 2018-02-17 (263 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
PackageArchitecture: all
SourcePackage: libreoffice
UpgradeStatus: Upgraded to bionic on 2018-05-01 (190 days ago)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Olivier Tilloy (osomon)]

I can reliably reproduce the issue when creating a new report, closing it and double-clicking it to open it again.

[Olivier Tilloy (osomon)]

Neither the debs from libreoffice.org nor the snap package seem to be affected. Only the packages in the ubuntu repositories.

[Olivier Tilloy (osomon)]

Libreoffice 5.1.6.2 on xenial (1:5.1.6~rc2-0ubuntu1~xenial4) is also affected.

Libreoffice 4.2.8.2 on trusty (1:4.2.8-0ubuntu5.3) is not affected.

[Olivier Tilloy (osomon)]

Copying over reportbuilder.jar AND reportbuilderwizard.jar from the upstream build or from the snap "fixes" the issue.

The obvious difference is that those files were built with OpenJDK 11 in the Ubuntu packages, whereas the upstream build uses version 8.

[Olivier Tilloy (osomon)]

debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913641

[Olivier Tilloy (osomon)]

cosmic and disco are not (yet) affected, because S8195874 (Improve jar specification adherence) was not backported to openjdk there.

bionic and xenial are affected.

[Olivier Tilloy (osomon)]

I rebuilt libreoffice 6.0.7 for bionic with the debian patch that sets jdk.net.URLClassPath.disableClassPathURLCheck to true, and verified that this was built against a version of the JDK that has the patch to honour that flag, but this hasn't fixed the issue.

[Tony Arnold (tony-arnold)]

This problem affected me after upgrading to Ubuntu 18.10. However, setting the Java version to use to OpenJDK 11 fixed this issue for me.

[Olivier Tilloy (osomon)]

That's because OpenJDK 11 in 18.10 doesn't have S8195874 (Improve jar specification adherence) yet.

[Jan-Marek Glogowski (jmglogow)]

When OpenJDK tried to enforce stricter class path URL checks without previous announcement, things started to break left and right. This included failing LibreOffice JUnitTest checks, since the dependency classpath in our generated Jars doesn't pass the stricter URL checks and therefore is ignored.

The check was disabled later in http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8513ac27b651, but I still think it's worthwhile to fix our Jars and then disable jdk.net.URLClassPath.disableClassPathURLCheck when running the tests.

More info is also in https://gerrit.libreoffice.org/#/c/63118/2

[Sbergman (sbergman)]

quoting my 2018-11-12 10:34 comment at <https://gerrit.libreoffice.org/#/c/63118> "Simplify and fix Java UNO API test makefiles":

"With Java moving away from supporting absolute file URLs in jar manifest Class-Paths, we need a new solution for what we currently do with gb_Jar_add_manifest_classpath/gb_Helper_make_url. We use that in unotest/Jar_test.mk (which is the subject of this change), but also in gb_Jar_use_system_jar as used in various places in RepositoryExternal.mk. (Note how we already have issues with file URLs in all of these places with recent Java on Windows, see <https://lists.freedesktop.org/archives/libreoffice/2018-September/080884.html> 'Re: make check fails in [build JCS]'.)

"However, from <https://docs.oracle.com/cd/E15289_01/JRRLN/newchanged.htm#GUID-CDE1F31D-EDEA-4FBF-B8CB-F555D09C084C> and the details of <http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1c1392d7c546> '8195874: Improve jar specification adherence', it looks like support for relative paths starting with '..' in jar manifest Class-Paths is also going away. We currently use such at least in bridges/Jar_java_uno.mk, connectivity/Jar_sdbc_hsqldb.mk, and javaunohelper/Jar_juh.mk."

[Jan-Marek Glogowski (jmglogow)]

From reading the current URLClassPath.java code, it seem you can set "jdk.net.URLClassPath.disableClassPathURLCheck" to "debug", and the loader will print the ignored class path entries, which can help debugging.

But it doesn't look like there is a way to get the default value, which could be checked by configure or even our jars to want people of failures.

[Libreoffice-commits (libreoffice-commits)]

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/905c107cde4a0a7059b1e11b5f23a0a59188cb0c%5E%21

tdf#121925 test for URLClassPath.ClassPathURLCheck

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Libreoffice-commits (libreoffice-commits)]

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/c9de94c65b8ab8bf6073400eda5ba848ba22af47%5E%21

tdf#121925 test for URLClassPath.ClassPathURLCheck

It will be available in 6.2.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Jan-Marek Glogowski (jmglogow)]

These patches are no fixes, but will detect the failing JDK setup during configure as an early warning! They should be reverted after a real fix is merged.

[Olivier Tilloy (osomon)]

This appears to have been fixed in an OpenJDK update.
Successfully tested on xenial, bionic and disco.

[Villeroy (villeroy)]

I don't understand the details of this issue. Is this the reason why https://adoptopenjdk.net is not recognized as a valid JDK?
Is it true that someone works on it?
No need to file another issue?

[Sbergman (sbergman)]

(In reply to Andreas Säger from comment #6)
> Is this the reason why
> https://adoptopenjdk.net is not recognized as a valid JDK?

That should work with <https://gerrit.libreoffice.org/#/c/66634/> "Support AdoptOpenJDK" (and its backports to the various release branches, see there). (And if you have further issues with that specific JDK, please file a new issue. It is most likely completely unrelated to this issue.)

[Iplaw67-h (iplaw67-h)]

Would this bug also affect use of Oracle OpenJDK 12 when trying to call an external hsqldb.jar, e.g. when a user has what is known as a split database (no embedded hsqldb) ? If so, then it would be a regression for those users.

[Sbergman (sbergman)]

(In reply to Alex Thurgood from comment #8)
> Would this bug also affect use of Oracle OpenJDK 12 when trying to call an
> external hsqldb.jar, e.g. when a user has what is known as a split database
> (no embedded hsqldb) ? If so, then it would be a regression for those users.

Hard to tell without further information about such failures. If there is a bug about that, please give a link to it here, so we can discuss that issue there instead of speculating here.

[Iplaw67-h (iplaw67-h)]

(In reply to Stephan Bergmann from comment #9)

> Hard to tell without further information about such failures. If there is a
> bug about that, please give a link to it here, so we can discuss that issue
> there instead of speculating here.

Opened bug 125882 with regard to embedded hsqldb ODB files.

[Sbergman (sbergman)]

(In reply to Jan-Marek Glogowski from comment #0)
> When OpenJDK tried to enforce stricter class path URL checks without
> previous announcement, things started to break left and right. This included
> failing LibreOffice JUnitTest checks, since the dependency classpath in our
> generated Jars doesn't pass the stricter URL checks and therefore is ignored.

It would have been useful to document exactly what failed. At least with java-latest-openjdk-headless-13.0.0.33-1.rolling.fc31.x86_64, the testurlcheck program in configure.ac reports "false", but (when you convert the corresponding AC_MSG_ERROR into a AC_MSG_RESULT to not make configure fail) a full `make check screenshot` works fine for me.

[Sbergman (sbergman)]

(In reply to Stephan Bergmann from comment #11)
> It would have been useful to document exactly what failed. At least with
> java-latest-openjdk-headless-13.0.0.33-1.rolling.fc31.x86_64, the
> testurlcheck program in configure.ac reports "false", but (when you convert
> the corresponding AC_MSG_ERROR into a AC_MSG_RESULT to not make configure
> fail) a full `make check screenshot` works fine for me.

As discussed on freenode #libreoffice-dev now:
> Sep 27 11:37:54 <sberg> jmux, do you remember the exact failure you got in tdf#121925?
> Sep 27 11:39:58 <jmux> sberg: I think it simply reported missing classes. But that is just a guess based on my original report.
> Sep 27 11:40:44 <sberg> jmux, I'm pondering reverting your commit again, given my findings with Java 13 on Fedora 31
> Sep 27 11:41:18 <sberg> ...and wait for a fresh actual failure report
> Sep 27 11:44:35 <jmux> sberg: no real objection. The configure test was just an "extension" of commit 86f5f598a2bdd71f95921c20e0361dee54b266c1
> Sep 27 11:44:37 <IZBot> core - Drop juh.jar dependency from Java UNO tests - http://cgit.freedesktop.org/libreoffice/core/commit/?id=86f5f598a2bdd71f95921c20e0361dee54b266c1
> Sep 27 11:45:39 <jmux> sberg: the whole thing was about these Java dependencies. Maybe that was fixed somehow?
> Sep 27 11:47:20 <jmux> sberg: and that was done, after I added juh.jar to the Java tests in commit 84286ac443ea8978743d281efeaa7ddb46199558
> Sep 27 11:47:22 <IZBot> core - Simplify and fix Java UNO API test makefiles - http://cgit.freedesktop.org/libreoffice/core/commit/?id=84286ac443ea8978743d281efeaa7ddb46199558
> Sep 27 11:48:53 <jmux> sberg: from https://gerrit.libreoffice.org/#/c/62203/ commit message: java.lang.NoClassDefFoundError: com/sun/star/comp/helper/Bootstrap
> Sep 27 11:48:53 <IZBot> gerrit: »add missing juh dependencies to JunitTests« by Rene Engelhard for master [ABANDONED]

[Libreoffice-commits (libreoffice-commits)]

Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/52f16d1f1d3d2712313fb50014474f43a1528c32

Revert "tdf#121925 test for URLClassPath.ClassPathURLCheck"

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.