Bug#912221: jabref: incompatible with openjdk 11
Hi Tony, Le 06/11/2018 à 21:12, tony mancill a écrit : > XJC="java -cp > /usr/share/java/xml-resolver.jar:/usr/share/java/jaxb-api.jar:/usr/share/java/jaxb-core.jar:/usr/share/java/jaxb-impl.jar:/usr/share/java/jaxb-jxc.jar:/usr/share/java/jaxb-xjc.jar > -jar /usr/share/java/jaxb-xjc.jar" > > And it dies with this exception stack, despite the xml-resolver being on > the classpath: The -cp parameter doesn't work with -jar, that's why you keep getting the ClassNotFoundException. Either all the jar files are specified behind -cp and the main class is specified on the command line (i.e. com.sun.tools.xjc.XJCFacade for xjc), or the jar executed has a proper Class-Path attribute in its manifest (and indeed xml-resolver.jar isn't listed in jaxb-xjc.jar). > Can you help me understand why this patch > (https://salsa.debian.org/java-team/jaxb/blob/master/debian/patches/04-xml-resolver-compatibility.patch) > was necessary? Perhaps it's related to the failure I'm seeing? I don't think it's related. We simply use a different version of xml-resolver. There is this rule in debian/maven.rules: s/com.sun.org.apache.xml.internal/xml-resolver/ s/resolver/xml-resolver/ Sun/Oracle had to change the namespace of the libraries they embedded in the JDK to avoid conflicts. But now that JAXB is no longer in the JDK it's not needed, and we can directly use the original library instead. > I've also started looking at updating jaxb 2.3.1, but it will > take me a bit of time. I've also started digging into jaxb to address the compatibility with Java 11. I've considered upgrading to the version 2.3.1 but it didn't look that straightforward despite the minor version increment. I'm not sure the upgrade is still compatible with Java 8 for example. So I think I'll rather aim at a minor update simply adding the dependency on libactivation-java, and later look at an upgrade. Emmanuel Bourg
Bug#912221: jabref: incompatible with openjdk 11
On Thu, Nov 01, 2018 at 02:22:26PM +0100, Emmanuel Bourg wrote: > On 01/11/2018 01:54, tony mancill wrote: > > > I am definitely open to (and appreciative of) your suggestions. > > Hi Tony, even if the jaxb package doesn't yet provide the xjc executable > (#905357), you can invoke it with: > > java -jar /usr/share/java/jaxb-xjc.jar Hi Emmanuel, It doesn't seem to be quite that straight-forward. I've spend a fair amount of time trying to build up proper classpath, but actually trying to use XJC to compile anything fails with classloader exceptions. For example, I build up a command like the following: XJC="java -cp /usr/share/java/xml-resolver.jar:/usr/share/java/jaxb-api.jar:/usr/share/java/jaxb-core.jar:/usr/share/java/jaxb-impl.jar:/usr/share/java/jaxb-jxc.jar:/usr/share/java/jaxb-xjc.jar -jar /usr/share/java/jaxb-xjc.jar" And it dies with this exception stack, despite the xml-resolver being on the classpath: > parsing a schema... > Exception in thread "main" java.lang.AssertionError: > javax.xml.bind.JAXBException: Implementation of JAXB-API has not been found > on module path or classpath. > - with linked exception: > [java.lang.ClassNotFoundException: > com.sun.xml.internal.bind.v2.ContextFactory] > at > com.sun.tools.xjc.reader.xmlschema.bindinfo.BindInfo.getCustomizationContext(BindInfo.java:356) > at > com.sun.tools.xjc.reader.xmlschema.bindinfo.BindInfo.getCustomizationUnmarshaller(BindInfo.java:362) > at > com.sun.tools.xjc.reader.xmlschema.bindinfo.AnnotationParserFactoryImpl$1.(AnnotationParserFactoryImpl.java:85) > at > com.sun.tools.xjc.reader.xmlschema.bindinfo.AnnotationParserFactoryImpl.create(AnnotationParserFactoryImpl.java:84) > at > com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.createAnnotationParser(NGCCRuntimeEx.java:401) > at > com.sun.xml.xsom.impl.parser.state.annotation.action0(annotation.java:89) > at > com.sun.xml.xsom.impl.parser.state.annotation.enterElement(annotation.java:114) > at > com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCRuntime.java:422) > at > com.sun.xml.xsom.impl.parser.state.NGCCHandler.spawnChildFromEnterElement(NGCCHandler.java:114) > at > com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:317) > at > com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCRuntime.java:422) > at > com.sun.xml.xsom.impl.parser.state.NGCCHandler.revertToParentFromEnterElement(NGCCHandler.java:151) > at > com.sun.xml.xsom.impl.parser.state.foreignAttributes.enterElement(foreignAttributes.java:91) > at > com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCRuntime.java:422) > at > com.sun.xml.xsom.impl.parser.state.NGCCHandler.spawnChildFromEnterElement(NGCCHandler.java:114) > at > com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:229) > at > com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCRuntime.java:422) > at > com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:273) > at > com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCRuntime.java:422) > at > com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:309) > at > com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCRuntime.java:422) > at > com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:293) > at > com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCRuntime.java:422) > at > com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:221) > at > com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCRuntime.java:422) > at > com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:257) > at > com.sun.xml.xsom.impl.parser.state.NGCCRuntime.startElement(NGCCRuntime.java:263) > at > java.xml/org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:551) > at > com.sun.tools.xjc.util.SubtreeCutter.startElement(SubtreeCutter.java:108) > at > com.sun.tools.xjc.reader.ExtensionBindingChecker.startElement(ExtensionBindingChecker.java:150) > at > java.xml/org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:551) > at > com.sun.tools.xjc.reader.xmlschema.parser.IncorrectNamespaceURIChecker.startElement(IncorrectNamespaceURIChecker.java:128) > at > java.xml/org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:551) > at > com.sun.tools.xjc.reader.xmlschema.parser.CustomizationContextChecker.startElement(CustomizationContextChecker.java:193) > at > java.xml/org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:551) > at > com.sun.tools.xjc.ModelLoader$SpeculationChecker.startElement(ModelLoader.java:455) > at > java.xml/org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:551) > at
Bug#912221: jabref: incompatible with openjdk 11
On 01/11/2018 01:54, tony mancill wrote: > I am definitely open to (and appreciative of) your suggestions. Hi Tony, even if the jaxb package doesn't yet provide the xjc executable (#905357), you can invoke it with: java -jar /usr/share/java/jaxb-xjc.jar Emmanuel Bourg
Bug#912221: jabref: incompatible with openjdk 11
On Tue, Oct 30, 2018 at 12:31:29PM +0100, Markus Koschany wrote: > Am 30.10.18 um 01:15 schrieb Emmanuel Bourg: > > Le 30/10/2018 à 00:41, gregor herrmann a écrit : > > > >> I guess we need to make sure that we build with openjdk-8. > >> (You know this better than me but I seem to remember that the plan > >> was to keep openjdk-8 in buster for building packages?) > > > > No please don't built with openjdk-8 if there is a workaround with > > openjdk-11. Building with openjdk-8 is really a last resort solution, > > and very few cases justify its use (see lombok for a good example). > > If it is too complicated, too intrusive or takes too much of your time > away I find it OK to build-depend on openjdk-8. Just ensure that > upstream knows about this issue because in the next cycle OpenJDK 8 will > be definitely removed. It is more important that jabref works with > OpenJDK 11 at runtime. Hi Markus, hi Emmanuel - Thank you both for contributing to this thread. For the time-being, the package will build-depend on openjdk-8 to leverage xjc until we have a suitable recipe for gradle-based builds. So far, the only plugins I've found are either wrappers for the xjc command-line tools or the ant task. I'm hoping there is something out there that we can use in conjunction with the maven-jaxb2-plugin, but haven't found anything yet. Note that Debian's gradle in unstable won't run against openjdk-8, so right now jabref depends on both default-jdk AND openjdk-8. The build is with default-jdk and openjdk-8 is only for the xjc binary. I am definitely open to (and appreciative of) your suggestions. Cheers, tony signature.asc Description: PGP signature
Bug#912221: jabref: incompatible with openjdk 11
Am 30.10.18 um 01:15 schrieb Emmanuel Bourg: > Le 30/10/2018 à 00:41, gregor herrmann a écrit : > >> I guess we need to make sure that we build with openjdk-8. >> (You know this better than me but I seem to remember that the plan >> was to keep openjdk-8 in buster for building packages?) > > No please don't built with openjdk-8 if there is a workaround with > openjdk-11. Building with openjdk-8 is really a last resort solution, > and very few cases justify its use (see lombok for a good example). If it is too complicated, too intrusive or takes too much of your time away I find it OK to build-depend on openjdk-8. Just ensure that upstream knows about this issue because in the next cycle OpenJDK 8 will be definitely removed. It is more important that jabref works with OpenJDK 11 at runtime. Markus signature.asc Description: OpenPGP digital signature
Bug#912221: jabref: incompatible with openjdk 11
Le 30/10/2018 à 00:41, gregor herrmann a écrit : > I guess we need to make sure that we build with openjdk-8. > (You know this better than me but I seem to remember that the plan > was to keep openjdk-8 in buster for building packages?) No please don't built with openjdk-8 if there is a workaround with openjdk-11. Building with openjdk-8 is really a last resort solution, and very few cases justify its use (see lombok for a good example). Emmanuel Bourg
Bug#912221: jabref: incompatible with openjdk 11
On Mon, 29 Oct 2018 16:33:54 -0700, tony mancill wrote: > On Mon, Oct 29, 2018 at 11:44:36PM +0100, Emmanuel Bourg wrote: > > jabref should no longer use the java.se.ee module, it was a temporary > > module in Java 9 & 10 now removed in Java 11. jabref should add jaxb to > > its classpath instead. > Thanks Emmanuel. Yes, I was able to get things working during the bus > ride in this morning, :) Great, thanks Tony. > just need to finish up the wrapper script logic > so it can start on Java 8, 9, 10, > 10 without the user having to worry > with it... Awesome. > I'll look at the FTBFS as well. I guess we need to make sure that we build with openjdk-8. (You know this better than me but I seem to remember that the plan was to keep openjdk-8 in buster for building packages?) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Janis Joplin: Cry Baby (live) signature.asc Description: Digital Signature
Bug#912221: jabref: incompatible with openjdk 11
On Mon, Oct 29, 2018 at 11:44:36PM +0100, Emmanuel Bourg wrote: > Le 29/10/2018 à 13:54, gregor herrmann a écrit : > > > Now that openjdk 11 is the default, jabref won't start without some > > help: > > > > % jabref > > Error occurred during initialization of boot layer > > java.lang.module.FindException: Module java.se.ee not found > > jabref should no longer use the java.se.ee module, it was a temporary > module in Java 9 & 10 now removed in Java 11. jabref should add jaxb to > its classpath instead. Thanks Emmanuel. Yes, I was able to get things working during the bus ride in this morning, just need to finish up the wrapper script logic so it can start on Java 8, 9, 10, > 10 without the user having to worry with it... I'll look at the FTBFS as well. signature.asc Description: PGP signature
Bug#912221: jabref: incompatible with openjdk 11
Le 29/10/2018 à 13:54, gregor herrmann a écrit : > Now that openjdk 11 is the default, jabref won't start without some > help: > > % jabref > Error occurred during initialization of boot layer > java.lang.module.FindException: Module java.se.ee not found jabref should no longer use the java.se.ee module, it was a temporary module in Java 9 & 10 now removed in Java 11. jabref should add jaxb to its classpath instead. Emmanuel Bourg
Bug#912221: jabref: incompatible with openjdk 11
Control: tag -1 + ftbfs On Mon, 29 Oct 2018 13:54:26 +0100, gregor herrmann wrote: > Package: jabref > Version: 3.8.2+ds-7 > Severity: important > > Now that openjdk 11 is the default, jabref won't start without some > help: > > % jabref > Error occurred during initialization of boot layer > java.lang.module.FindException: Module java.se.ee not found And it also FTBFS: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jabref.html (Thanks to Adrian for already raising the severity.) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Simon and Garfunkel: American Tune signature.asc Description: Digital Signature
Bug#912221: jabref: incompatible with openjdk 11
Package: jabref
Version: 3.8.2+ds-7
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Now that openjdk 11 is the default, jabref won't start without some
help:
% jabref
Error occurred during initialization of boot layer
java.lang.module.FindException: Module java.se.ee not found
(java.se.ee is required by the /usr/bin/jabref wrapper).
With JAVA_HOME set, all is fine: Both
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ jabref
and
JAVA_HOME=/usr/lib/jvm/java-10-openjdk-amd64/ jabref
still work.
Seems like we need some fiddling with /usr/bin/jabref and/or the
runtime dependencies to make sure we use openjdk {8,9,10} but not 11.
Or better a way to make it work with 11, if that's the default for
buster …
This is also
https://bugs.launchpad.net/bugs/1799106
which brought me to check the situation in Debian.
Cheers,
gregor
- -- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500,
'oldoldstable'), (500, 'experimental'), (500, 'testing'), (500, 'stable'),
(500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages jabref depends on:
ii java-wrappers 0.3
ii libandroid-json-java8.1.0+r23-2
ii libantlr3-runtime-java 3.5.2-9
ii libantlr4-runtime-java 4.6-2
ii libbcprov-java 1.60-1
ii libcommons-cli-java 1.4-1
ii libcommons-lang3-java 3.8-1
ii libcommons-logging-java 1.2-2
ii libglazedlists-java 1.9.1-2
ii libguava-java 19.0-1
ii libhttpasyncclient-java 4.1.4-1
ii libhttpclient-java 4.5.6-1
ii libhttpmime-java4.5.6-1
ii libjava-string-similarity-java 0.24-1
ii libjempbox-java 1:1.8.16-1
ii libjgoodies-common-java 1.8.1-2
ii libjgoodies-forms-java 1.9.0-3
ii libjgoodies-looks-java 2.7.0-3
ii libjhlabs-filters-java 2.0.235-3
ii libjsoup-java 1.10.2-2
ii liblog4j2-java 2.11.1-1
ii libmicroba-java 1:0.4.4.3-5
ii libpdfbox-java 1:1.8.16-1
ii libreoffice-java-common 1:6.1.3~rc1-2
ii libspin-java1.5+dfsg-8
ii libswing-layout-java1.0.4-4
ii libswingx-java 1:1.6.2-3
ii libunirest-java-java1.4.8-2
Versions of packages jabref recommends:
ii libmysql-java5.1.45-1
ii libpostgresql-jdbc-java 42.2.5-1
ii libreoffice-writer 1:6.1.3~rc1-2
ii xdg-utils1.1.3-1
Versions of packages jabref suggests:
ii acroread [pdf-viewer] 9.5.5-dmo5
ii epdfview [pdf-viewer] 0.1.8-3
ii evince [postscript-viewer]3.30.1-1
ii ghostscript [postscript-viewer] 9.25~dfsg-4
ii gv [postscript-viewer]1:3.7.4-1+b1
ii mupdf [pdf-viewer]1.14.0+ds1-1
ii xpdf [pdf-viewer] 3.04-9
ii zathura-pdf-poppler [pdf-viewer] 0.2.9-1
- -- no debconf information
-BEGIN PGP SIGNATURE-
iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlvXAwJfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbPUg//UmAPUuWvMDng/dD5NHbMPJ1ARz0ZDMdSk2cjdnER4E9VtHUE42FdoNda
O7zXgSAMaEazyKQFVyahymdr9boqcRojVwqlSS1K+zfqs7iPFqBeZV9fhwGkhWrF
jzMeA4efO2zs5gLY7Uievu+xpzSQ8UHMmYZ+lXYhgRD7enU9t+2hcFUoF785YFCy
rxJtAN/Ah1kucC4Gzf3NagfPUL+pJbiWDa96dSdUzbKyrrusJf2GoUVAXr22Wm1M
xTy+cam60nc5acvcDjIxh7gp9SyRzytu/3NHXzITurw+tN4e6eDHcWlCqwpvoulK
srLgA33K86Ts8J9HIlJuK+Aje4f5OQ4kIXjyNNBT0uTN4ApAcrw3a7HjdSED1c2v
Q7r3P5rXSKklvwT3p+iyrJPrNr42+CUL8MjJ8mA7dM19t1WD/3voY7bN0C7NrDQ2
zuiR40jH1T5klP6XXhM/0JkBhyiu9+f5vE0u2PuvXJSyf2oVFiTuQ5FocdFmVUVA
bFU/YLmzC0yAbKMlZLCJ+vbRtoPP5bGV1+oUcQ+1Ng+Ra39PCFimoLy5bHTh2dY/
+aZEfnASvAaS6Asn2+vYAUWhNvIIf9AGcJIa5qVAimLl0p3xoQwcKBnh1ra2cIUg
GKeHSLvgeWVL+nqJicYnsBiJJiND8EG9hQiqSTWjO1mmqZhDSeM=
=VcD9
-END PGP SIGNATURE-
