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
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."
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.
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.
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.
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.
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?
(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.)
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.
(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.
(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.
(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.
(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]
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.